WordPress Snippets 101: mein Standard-Repertoir
Veröffentlicht am 28.09.2018, zuletzt aktualisiert am 08.10.2020
Wenn man sich WordPress-Themes und der Modifikation von Themes und WordPress selbst beschäftigt, kommt man immer wieder an kleinen Code-Snippets vorbei. Was können sie und was steckt dahinter? Eine Übersicht.
Im Grunde sind diese kleinen Code-Schnipsel nichts anderes als Funktionen oder Einstellungen. Manche davon haben größeren Einfluss, andere sind eher im Hintergrund tätig. Nachfolgend möchte ich ein paar einfache Snippets aufzeigen.
Dabei muss man zwischen Einstellungen, die die WordPress-Installation betreffen und solchen, die nur für ein Plugin oder Theme gültig sind unterscheiden. Angesprochen werden erstere über die wp-config.php-Datei, die im Root-Verzeichnis der WordPress-Installation zu finden ist. Plugin- oder Theme-spezifische Einstellungen werden über die functions.php definiert, die (standardmäßig) unter wp-content/themes/<theme-name>/ liegt. WordPress nutzt immer nur die functions.php des aktivierten Themes. Die wp-config.php ist hingegen immer aktiv. Plugin- oder Theme-spezifische Snippets können auch als separates Plugin angelegt werden – dann bleiben sie auch bei einem Theme-Wechsel aktiv. Prinzipiell ist das der „saubere“ Weg.
Einstellungen über wp-config.php
Die in der wp-config.php vorgenommenen Einstellungen betreffen eine komplette WordPress-Installation. Je nach Konfiguration kann das auch eine Multisite-Installation sein. In jeder Installation ist eine wp-config-sample.php als Beispiel angelegt. Darin finden sich bereits Einstellungen u.a. zur Datenbank. Nachfolgend zeige ich ein paar meiner üblichen Config-Einstellungen, die immer oder zumindest üblicherweise zum Einsatz kommen.
define( 'AUTOSAVE_INTERVAL', 60 );Der Autosave-Interval legt fest, wie oft WordPress beim Schreiben oder Bearbeiten eines Beitrages immer Hintergrund die Änderungen automatisch abspeichert. Der Standardwert liegt bei 60 Sekunden. Bei einer schlechten Internetverbindung kann dieser Wert höher gesetzt werden. Wenn man sicher gehen will, keine Änderungen zu verlieren, kann man ihn heruntersetzen. Dies entscheide ich meist je nach Seite bzw. Kunde.
define( 'WP_POST_REVISIONS', 3 );
define( 'WP_POST_REVISIONS', false );WP_POST_REVISIONS legt fest, wie viele Versionen eines Posts WordPress speichern bzw. behalten soll, die man später z.B. wieder herstellen kann. Man kann hier eine Ganzzahl angeben, um die Anzahl festzulegen, oder false setzen, um die Versionierung komplett zu deaktivieren. Letzteres führt zu einer saubereren Datenbank und ggfs. zu weniger Verwirrung beim Kunden, weshalb ich manchmal diese Möglichkeit nutze.
define( 'EMPTY_TRASH_DAYS', 30 );Über EMPTY_TRASH_DAYS lässt sich festlegen, nach wie vielen Tagen Beiträge im Papierkorb endgültig gelöscht werden soll. Der Standardwert ist 30 Tage. Wenn man den Papierkorb komplett deaktivieren möchte, kann man auch 0 angeben. Dann werden Nutzer allerdings auch nicht gefragt, ob sie Beiträge endgültig löschen möchten – Löschen erfolgt dann unmittelbar. Je nach Art und geplanter Nutzung der Seite setze ich hier meist einen Wert von 7 oder 14.
define( 'DISALLOW_FILE_EDIT', true );DISALLOW_FILE_EDIT gehört ebenfalls zu meinem Standard-Repertoir. Es deaktiviert den Datei-Editor im Backend, was meines Erachtens meistens Sinn macht, um übereifrige Nutzer von den Theme- und Plugin-Dateien fern zu halten. Ebenfalls ist es eine weitere Sicherheitsmaßnahme, falls ein Benutzer-Zugang in die falschen Hände gerät.
define( 'AUTOMATIC_UPDATER_DISABLED', true );Sehr speziell, aber in meinem Fall absolut sinnvoll, ist die Deaktivierung von automatischen Updates. Dies deaktiviert die automatischen Updates von jeglichen Inhalten, also Core, Plugins, Themes und sogar Sprachpaketen. Dies macht für mich Sinn, da ich ManageWP verwende, um alle meine WordPress-Seiten von einem Ort aus zu verwalten. Updates führe ich von dort aus, nachdem ich mir z.B. Changelogs angesehen habe. Dadurch habe ich feinere Kontrolle über den Status meiner verwalteten Seiten.
Wer sich für das komplette „Leistungsspektrum“ der Config interessiert, sollte sich den Codex-Artikel Editing wp-config.php zu Gemüte führen. Von Debug über Cache bis Multisite-Konfiguration ist noch einiges mehr möglich als hier angesprochen.
Basics in der functions.php
Disclaimer: Das Internet ist voller Anleitungen von WordPress-Modifikationen, die allesamt in die functions.php geschoben werden sollen. Das ist meistens falsch. Die functions.php sollte nur Code enthalten, der für das jeweilige Theme nötig ist, nicht jedoch generelle Modifikationen. Man sollte sich daher immer die Frage stellen: Hängt diese Modifikation wirklich nur mit meinem aktuellen Theme zusammen? Nur wenn man dies deutlich mit Ja beantworten kann, gehört der Code in die functions.php, ansonsten sollte man fix ein kleines Plugin erstellen, das den Code-Schnipsel enthält. Das Plugin bleibt dann auch bei einem Theme-Wechsel aktiv und die Modifikationen erhalten.
Nachfolgend möchte ich nun ein paar Snippets zeigen, die ich oft verwende – teils als Teil des Themes, teils in einem dauerhaften Plugin. Die ersten zwei Filter beziehen sich auf die Login-Seite. Bei beiden kann man sich fragen: Theme-abhängig? Meines Erachtens eine Frage des Inhalts. Setzt man hier spezifische Inhalte mit Bezug auf das Theme, gehört es in die functions.php, setzt man allgemeine Werte um das Branding zu reduzieren, sollte man sie in ein Plugin verschieben.
function set_login_url(){
return get_bloginfo( 'url' );
}
add_filter( 'login_headerurl', 'set_login_url' );Über login_headerurl wird die URL angegeben, die bei Klick auf das (standardmäßig) WordPress-Logo auf der Login-Seite erreicht wird. Hier setze ich meist die Website-URL.
function set_login_title(){
return get_option( 'blogname' );
}
add_filter( 'login_headertitle', 'set_login_title' );login_headertitle setzt zugehörig das title-Attribut des WordPress-Logos auf der Login-Seite. Hier setze ich ganz einfach den Namen der Website. Weitere Modifikations-Möglichkeiten der Login-Seite finden sich übrigens im WordPress-Codex-Artikel Customizing the Login Form.
function set_footer_text(){
return false;
}
add_filter( 'admin_footer_text', 'set_footer_text' );Dieser Filter erlaubt es, den Footer-Text im Backend selbst zu setzen. Standardmäßig wird hier ein Dank für die Nutzung von WordPress angezeigt. Man kann hier entweder einen eigenen Text ausgeben (auch mit Links oder JS-Funktionen), oder ihn wie im obigen Beispiel einfach deaktivieren.
function cr_custom_excerpt_length( $length ){
return 20;
}
add_filter( 'excerpt_length', 'cr_custom_excerpt_length' );Eine Variable, die ich während der Theme-Entwicklung sehr gerne anpasse, ist die excerpt_length, also die Länge des Post-Auszugs. Dies ist meines Erachtens absolut Theme-abhängig einzusetzen und ist bei mir daher Bestandteil der functions.php. Der Standardwert von 55 Wörtern ist oftmals zu lang, ich kürze gern auf 20-30.
function cr_search_query( $query ){
if( $query->is_search() && !is_admin() ){
$query->set( 'post_type', array( 'product', 'post', 'page' ) );
}
}
add_action( 'pre_get_posts', 'cr_search_query' );Wenn man mit Custom Post Types arbeitet, also eigenen Inhaltstypen, bietet es sich an, diese auch in der Suche auffindbar zu machen. Dazu nutze ich obenstehendes Snippet, was sich in pre_get_posts einklinkt und insofern eine Suchanfrage vorliegt die gewünschten Inhaltsarten inkludiert.
Das war’s – ein Auszug meiner WordPress-Code-Schnipsel, wie ich sie meist als Standard-Set verwende. Es führen sicher viele Wege nach Rom, und jeder mag sein WordPress-Setup anders pflegen. Wer Input geben mag: comment below 🙂