WordPress-Konfiguration: Die 5 wichtigsten Entwickler-Einstellungen, bevor die Tastatur glüht
Die Konfigurationsdatei nennt sich bei WordPress wp-config.php und ist auf der ersten Ebene des Installation-Verzeichnisses zu finden. Diese Konfigurationsdatei ist global und birgt alle grundsätzlichen Einstellungen. Unter anderem ist in der Datei auch die Datenbank-Verknüpfung hinterlegt.
In den folgenden fünf Punkten will ich euch die wichtigsten Einstellungen der wp-config zeigen, die während der Theme- oder Plugin-Entwicklung interessant und wichtig sein können.
1. Auto-Update deaktivieren
WordPress besitzt seit der Version 3.7 eine automatische Core-Update-Funktionalität. Dabei wird WordPress im Hintergrund mit Minor-Updates versorgt. Das ist natürlich sinnvoll, um die Sicherheit einer WordPress-Webseite zu gewährleisten. In der Entwicklungsphase aber ist es eher hinderlich, wenn sich deshalb der WP-Core ändert und somit gegebenenfalls Fehler am Theme oder Plugin entstehen können. Doch das Update könnt ihr auch ganz einfach deaktivieren:
define( 'WP_AUTO_UPDATE_CORE', false );
2. WordPress-Debugging aktivieren
Um ein Theme oder Plugin erfolgreich zu entwickeln, braucht es natürlich auch eine Fehlerausgabe. Mit den folgenden Befehlen wird das komplette Debugging bei WordPress aktiviert und zusätzlich geloggt. Alle Fehler werden in einer Log-Datei gespeichert und direkt ausgegeben. Zusätzlich sind die Datenbank-Abfragen noch mal in einem PHP-Objekt gespeichert.
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', true );
define( 'SCRIPT_DEBUG', true );
define( 'SAVEQUERIES', true );
3. Site- und Home-URL festlegen
Die Site- und Home-URL kann natürlich auch über das Backend bearbeitet werden (Einstellungen > Allgemein). Hierbei ist die Definition auch eher eine Vorsichtsmaßnahme. Sobald WP_SITEURL und WP_HOME gesetzt sind, können die Seiten-Adresse und WordPress-Adresse über das Backend nicht mehr verändert werden. Somit ist es ausgeschlossen, dass aus Versehen die URL der WordPress-Installation oder des Blogs verändert wird und die ganze Seite abschmiert. Diese Einstellung kann natürlich auch nach der Entwicklung weiterhin interessant sein, damit unerfahrene Nutzer die Seite nicht abschießen.
define( 'WP_SITEURL', 'https://t3n.de/' );
define( 'WP_HOME', 'https://t3n.de/news' );
4. WordPress-Lokalisierung angeben
Natürlich darf die Angabe der Lokalisierung auch nicht fehlen. WordPress erhält damit die Anweisung, welche Sprachdateien benutzt werden sollen. WPLANG erhält den Ländercode des jeweiligen Landes und wählt somit die richtige Sprachdatei, wenn vorhanden, im Ordner „/wp-includes/languages“ aus. Ab der WordPress-Version 4 kann die Sprache auch über das Backend ausgewählt werden (Einstellungen > Allgemein).
define( 'WPLANG', 'de_DE' );
5. Datei-Modifikation deaktivieren
Mit dieser Einstellung werden alle Funktionen im Backend deaktiviert, die dafür sorgen, dass Dateien aktualisiert, gelöscht oder hinzugefügt werden können. Somit sind die Inline-Editoren für Plugins und Themen deaktiviert, es können keine Updates durchgeführt und natürlich auch keine Plugins und Themes installiert werden. Diese Einstellung ermöglicht die Sicherstellung einer nicht modifizierten Datenbasis, die wiederum auch interessant für den Live-Betrieb sein kann.
define( 'DISALLOW_FILE_MODS', true );
Zusammenfassung
Wichtig ist immer, dass ihr den Überblick nicht verliert. Es muss klar verständlich sein, welche Konfiguration und Möglichkeiten aktuell eingestellt sind. Legt euch notfalls eine Vorlage mit einer fertigen wp-config.php-Datei an, die nur kopiert werden muss.
Zudem können in der wp-config noch viele weitere Einstellungen vorgenommen werden – beispielsweise das Aktivieren von SSL oder der Multisite. All diese Möglichkeiten könnt ihr im WordPress-Codex nachschlagen.
Vielleicht auch interessant: Hier findet ihr eine Liste der beliebtesten Plugins für WordPress
Mal ganz, ganz ernsthaft:
Wie schafft es ein Artikel, der als erstes empfiehlt, die update-funktion auszuschalten, weil sie „beim entwickeln stören könnte“ im Jahr 2015 noch durch die QS eines sich halbwegs selbst ernstnehmenden Magazins der IT-Branche?
Hallo? Das Jahr 2000 hat angeläutet und möchte seine Frickler zurück. Heutzutage nutzt man clean code, Softwarearchitektur und Tests nicht ohne Grund!
Oder weniger plakativ: Wenn ihr so programmiert, dass euch das update nervt,liegt das nicht an dem update. Sondern an euch. In 99,99% der Fälle ist ein Update der WP-Version sinnvoll, nicht zuletzt wegen sowas hier: http://klikki.fi/adv/wordpress2.html – aber nein, das stört mich beim rumfrickeln, das stell ich lieber aus, damit sich veraltete WP-Versionen auch 2015 noch weiter verbreiten?
Bei aller Liebe, ich habe gerade „so’n Hals“ ob das so ein Tip in so einem reichweitenstarken Magazin erscheint.
Und ja, mir ist bewusst, dass da „in der Entwicklungsphase“ steht. Aber hey, wir wissen doch alle aus der Realität, dass (leider) der bug dann halt auf „kurz vor schluss“ verschoben würde und damit quasi ungefixt mit nem veralteten WP ausgeliefert wird. Um dann im Zweifelsfall, wenn der Kunde updaten möchte, wieder abzukassieren. So was widerspricht einfach meinem Qualitätsgedanken.
Gruß,
Dominik
+1
Und die Redaktion so: „wir brauchen noch einen reißerischen Artikel zu WordPress“
Und der Autor so: „Kenne da fünf total coole Hacker Funktionen, die kein normales WordPress benutzt“
Beide: „Jo, das machen wir“
Echt Leute…
Hallo und noch ernsthafter:
wieso WordPress? Bei 90% aller Plugins/Themes überkommt einen halbwegs guten Entwickler das pure Grauen… Echt jetzt.
Dass dann der Tipp kommt, die Update-Funktion auszuschalten ist nur nachvollziehbar….
Deshalb setzt ein halbwegs guter Entwickler 90 % aller Plugins/Themes gar nicht erst ein ;)
Ein schönes abschreckendes WordPress-Beispiel. Die bekommen es nicht mal hin ihre Konstanten konsistent zu benennen. WP-Prefix oder nicht? Mit Unterstrichen getrennt oder nicht? Da sieht jede Konstante anders aus.
Es heißt ja auch t3n und nicht wpn. >:-)
nun ja, ihr lieben. natuerlich hat die deaktivierung des „auto“ updates Sinn !
Dann hat wohl niemand von euch gelesen / erlebt das ab und an wp-updates raus kamen die a) bugs b) sicherheitsluecke c)das theme zerschossen haben usw. Kommt vieleicht selten vor, aber passiert ! Wie kommt der erste Redner auf die Idee zu behaupten: jedes update ist toll , ist sicher, muss sein. selbst bei einem OS ist nicht jedes update: toll
Hallo Rainer,
Vielen dank für Ihren Kommentar. Ich habe eine Gegenfrage bzw. eine Bitte zu Ihrer Frage, wie ich denn „auf die Idee komme zu behaupten, dass…“:
Es ist ja nun einmal so, dass Updates im Zweifelsfall einen Mehrwert bringen. Ich denke, da stimmen wir überein – siehe auch mein Link im letzten Post (Hint an die t3n-redaktion: DAS wäre m.E. einen Artikel wert).
Jedenfalls:
Da Updates grundsätzlich sinnvoll sind, Sie aber dies verneinen, bitte ich Sie, mir anhand von Fakten(!) zu belegen, dass eine relevante Menge (sagen wir, was… >1%? >5%? >10%? Suchen Sie es sich ruhig aus) an (WP-)updates der letzten Jahre schwerwiegende Bugs enthält oder eine Sicherheitslücke „dazuimplementiert“.
Und auch hier wieder das Argument „Das Theme zerschossen“ von Ihnen – Dieses Argument ist aus naheliegenden Gründen nicht valide.
Oder, plakativer: „Tja, Schön. Und?“
Als Entwickler sollte Ihnen genau an dieser Stelle klar sein, dass Sie ihr Theme wohl an den neuen WP-Core anpassen müssen, da sich dort etwas geändert hat – im Zweifelsfall aber zum Besseren, s. Beispiel im Link oben.
Wir reden ja nicht von Endkunden hier. Es hat schlichtweg einen Grund, warum u.A. einige (die besseren m.E.) Hoster und Player wie Envato (sollte auch im deutschen Agenturumfeld bekannt sein, auch wenn’s kaum jemand zugibt) gestern an alle Kunden eine Mail geschickt habenmit der Bitte, upzudaten.
Aber hey. Nein. Wir stellen das Autoupdate aus. Könnte das Theme zerschießen. Geht nicht. No way!
Nun, sollten Sie es nicht schaffen, die validen Argumente ihrerseits mit Fakten zu untermauern, ist Ihr Kommentar hier für mich leider nur eine Rechtfertigung für Sie selbst, mit einigermaßen beruhigtem Gewissen so weiterzumachen wie bisher. Hat aber mit der Faktenlage leider wenig zu tun.
Beste Grüße,
Dominik
p.s: Das hier ist nicht persönlich gemeint – aber wenn ich mit solcherart Denkmustern zu tun bekomme, kriege ich immer wieder eine Gänsehaut, da das leider zu nichts anderem als Gefrickel führt. Und für dieses Gefrickel wird teilweise eine absolute Unsumme an Geld verlangt.
Das widerspricht wie schon erwähnt meinem Qualitätsgedanken, weshalb sich wohl meine Beißreflexe nicht zurückhalten lassen.
Auch ich weiß, dass die Realität durchaus einmal nichts anderes übrig lässt, als irgendwo Kompromisse zu finden – aber einen solchen Kompromiss für einen Randfall aus Zigtausend hier groß als „wichtigste Entwickler-Einstellung“, die jeder Entwickler vorm entwickeln tun sollte, zu promoten – DAS geht schlicht gar nicht.
p.p.s: Sollten Sie aus Gründen verletzten Stolzes o.Ä. Schmonsens den Spieß umdrehen wollen, schauen Sie sich einfach die letzten Patchnotes von WordPress an. Ich kann aber auch gerne etwas heraussuchen :-) erstes Beispiel im Link meines Ausgangsposts.
Updates machen Sinn ! Sehe ich genauso . Es ist nur so, das man vieleicht selbst entscheiden möchte „wann“ / „welches“ Update. Internetentwicklung = schneller als das Beispiel mit einem OS, daher auch schnellere Zyklen. Nichts desto trotz warum JEDES update mitmachen ?
Der Features wegen ? Der Sicherheit wegen ? Sicherheit bedeutet nicht nur WP core, sonder auch deren Plugins sowie der Hoster bei dem die Engine läuft. Keiner hier kann ja garantieren, das ein nächstes Update „keine“ kl. Fehler enthält. Daher finde ich es ratsam „selbst“ zu bestimmen, nachdem man „erst“ getestet hat.
Wenn die Site (theme / plugin) durch ein WP-core update nicht mehr funktioniert, ist das schon schlimm. Damit meine ich das tolle Auto-Update. Bei einem manuellem Update besteht die Möglichkeit, die Zeit zu haben es kontrolliert anzupassen. Heißt, die Site funktioniert immer. Wenn Auto-Update & Theme / Plugin sich nicht vertragen = Site für unbestimmte Zeit nicht funktionsfähig. Erst wenn angepasst wird , Anpassung da ist (was dauern kann, denn man schaut sich seine 10? Sites nicht jeden Tag an) läuft die Seite „wieder“. imho…
Das sehe ich genau so! Ich möchte Herr über die Updates sein.
Automatische Updates sind dann teilweise mit Plugins nicht kompatibel, und dann zerhauts einem den kompletten Internetauftritt – ein NoGo!
Also selbst bestimmen wann das Update installiert wird, sich per Mail über neue Updates informieren lassen, dann das Update testen, und wenn alles funktioniert auf die Echtumgebung aufspielen.
Nur so kann es sinnvoll sein!
Dem kann ich mich auch nur anschließen. Generell sind Updates sinnvoll und von WP auch gut, aber die Kontrolle sollte man selbst haben und auch den Zeitpunkt selbst bestimmen.
Manuelle Updates haben den Vorteil, dass man sich vorab über mögliche Auswirkungen informieren und vorbereiten kann. Auch bei der Arbeit mit Plugins hat man so Zeit auf entsprechende Updates der Plugins zu warten.
Updates sind wichtig aber Tipp 2 und 3 (Debugging und Home-URL) sind gut.