Die 10 häufigsten Fehler, die WordPress-Entwickler machen

Wir sind nur Menschen, und eine der Eigenschaften des Menschseins ist, dass wir Fehler machen. Andererseits sind wir auch selbstkorrigierend, das heißt, wir neigen dazu, aus unseren Fehlern zu lernen und dadurch hoffentlich vermeiden zu können, die gleichen Fehler zweimal zu machen. Viele der Fehler, die ich im WordPress-Bereich gemacht habe, stammen von dem Versuch, bei der Implementierung von Lösungen Zeit zu sparen. Diese würden jedoch in der Regel ihren Kopf erheben, wenn aufgrund dieses Ansatzes Probleme auftauchen würden. Fehler zu machen ist unvermeidlich. Aus den Versäumnissen anderer (und natürlich aus Ihren eigenen!) zu lernen, ist jedoch ein Weg, den Sie proaktiv einschlagen sollten.

Häufiger Fehler Nr. 1: Debugging ausschalten

Warum sollte ich das Debuggen verwenden, wenn mein Code einwandfrei funktioniert? Debugging ist eine in WordPress integrierte Funktion, die dazu führt, dass alle PHP-Fehler, Warnungen und Hinweise (über veraltete Funktionen usw.) angezeigt werden. Wenn das Debuggen deaktiviert ist, werden möglicherweise wichtige Warnungen oder Hinweise generiert, die wir nie sehen, die aber später Probleme verursachen können, wenn wir uns nicht rechtzeitig darum kümmern. Wir möchten, dass unser Code gut mit allen anderen Elementen unserer Website zusammenspielt. Wenn Sie also neuen benutzerdefinierten Code zu WordPress hinzufügen, sollten Sie Ihre Entwicklungsarbeit immer mit aktiviertem Debugging durchführen (aber stellen Sie sicher, dass Sie es deaktivieren, bevor Sie die Website für die Produktion bereitstellen!).

Um diese Funktion zu aktivieren, musst du die Datei wp-config.php im Stammverzeichnis deiner WordPress-Installation bearbeiten. Hier ist ein Ausschnitt einer typischen Datei:

 // Enable debugging define('WP_DEBUG', true); // Log all errors to a text file located at /wp-content/debug.log define('WP_DEBUG_LOG', true); // Don't display error messages write them to the log file /wp-content/debug.log define('WP_DEBUG_DISPLAY', false); // Ensure all PHP errors are written to the log file and not displayed on screen @ini_set('display_errors', 0);

Dies ist keine vollständige Liste der verwendbaren Konfigurationsoptionen, aber diese vorgeschlagene Einrichtung sollte für die meisten Debugging-Anforderungen ausreichen.

Häufiger Fehler Nr. 2: Hinzufügen von Skripten und Stilen mit wp_head Hook

Was ist falsch daran, die Skripte in meine Header-Vorlage einzufügen? WordPress enthält bereits eine Fülle beliebter Skripte. Dennoch werden viele Entwickler zusätzliche Skripte hinzufügen, indem sie den wp_head Hook verwenden. Dies kann dazu führen, dass dasselbe Skript, aber eine andere Version, mehrmals geladen wird.

Das Einreihen in die Warteschlange hier kommt zur Rettung, das ist die WordPress-freundliche Art, Skripte und Stile zu unserer Website hinzuzufügen. Wir verwenden Enqueuing, um Plugin-Konflikte zu verhindern und alle Abhängigkeiten zu behandeln, die ein Skript haben könnte. Dies wird erreicht, indem die eingebauten Funktionen wp_enqueue_script oder wp_enqueue_style verwendet werden, um Skripte bzw. Stile einzureihen. Der Hauptunterschied zwischen den beiden Funktionen besteht darin, dass wir mit wp_enqueue_script einen zusätzlichen Parameter haben, der es uns ermöglicht, das Skript in die Fußzeile der Seite zu verschieben.

 wp_register_script( $handle, $src, $deps = array(), $ver = false, $in_footer = false ) wp_enqueue_script( $handle, $src = false, $deps = array(), $ver = false, $in_footer = false ) wp_register_style( $handle, $src, $deps = array(), $ver = false, $media = 'all' ) wp_enqueue_style( $handle, $src = false, $deps = array(), $ver = false, $media = 'all' )

Wenn das Skript den Inhalt „above the fold“ nicht rendern muss, können wir es sicher in die Fußzeile verschieben, um sicherzustellen, dass der Inhalt „above the fold“ schnell geladen wird. Es empfiehlt sich, das Skript zuerst zu registrieren, bevor Sie es in die Warteschlange stellen, da dies anderen ermöglicht, Ihr Skript über das Handle in ihren eigenen Plugins abzumelden, ohne den Kerncode Ihres Plugins zu ändern. Wenn darüber hinaus das Handle eines registrierten Skripts im Array von Abhängigkeiten eines anderen in die Warteschlange eingereihten Skripts aufgeführt ist, wird dieses Skript automatisch vor dem Laden des hervorgehobenen in die Warteschlange eingereihten Skripts geladen.

Häufiger Fehler Nr. 3: Child-Themes vermeiden und WordPress-Core-Dateien modifizieren

Erstellen Sie immer ein untergeordnetes Design, wenn Sie vorhaben, ein Design zu ändern. Einige Entwickler nehmen Änderungen an den Dateien des übergeordneten Designs vor, nur um nach einem Upgrade des Designs festzustellen, dass ihre Änderungen überschrieben wurden und für immer verloren sind.

Um ein Child-Theme zu erstellen, platzieren Sie eine style.css -Datei mit folgendem Inhalt in einem Unterverzeichnis des Ordners des Child-Themes:

 /* Theme Name: Twenty Sixteen Child Theme URI: http://example.com/twenty-fifteen-child/ Description: Twenty Fifteen Child Theme Author: John Doe Author URI: http://example.com Template: twentysixteen Version: 1.0.0 License: GNU General Public License v2 or later License URI: http://www.gnu.org/licenses/gpl-2.0.html Tags: light, dark, two-columns, right-sidebar, responsive-layout, accessibility-ready Text Domain: twenty-sixteen-child */

Das obige Beispiel erstellt ein untergeordnetes Design basierend auf dem standardmäßigen WordPress-Design Twenty Sixteen . Die wichtigste Zeile dieses Codes ist diejenige, die das Wort „Template“ enthält, das mit dem Verzeichnisnamen des übergeordneten Designs übereinstimmen muss, aus dem Sie das untergeordnete Design klonen.

Die gleichen Prinzipien gelten für WordPress-Core-Dateien: Gehen Sie nicht den einfachen Weg, indem Sie die Core-Dateien modifizieren. Geben Sie sich zusätzliche Mühe, indem Sie WordPress-Plug-in-Funktionen und -Filter verwenden, um zu verhindern, dass Ihre Änderungen nach einem WordPress-Upgrade überschrieben werden. Mit austauschbaren Funktionen können Sie einige Kernfunktionen überschreiben, aber diese Methode wird langsam eingestellt und durch Filter ersetzt. Filter erzielen dasselbe Endergebnis und werden am Ende von WordPress-Funktionen eingefügt, damit ihre Ausgabe geändert werden kann. Ein Trick besteht immer darin, Ihre Funktionen mit if ( !function_exists() ) zu umschließen, wenn Sie austauschbare Funktionen verwenden, da mehrere Plugins, die versuchen, dieselbe austauschbare Funktion ohne diesen Wrapper zu überschreiben, einen schwerwiegenden Fehler erzeugen.

Häufiger Fehler Nr. 4: Hardcoding-Werte

Oft sieht es schneller aus, einen Wert (z. B. eine URL) einfach irgendwo im Code fest zu codieren, aber der Zeitaufwand für das Debuggen und Beheben von Problemen, die daraus resultieren, ist viel größer. Indem wir mit der entsprechenden Funktion die gewünschte Ausgabe dynamisch erzeugen, vereinfachen wir die spätere Wartung und das Debuggen unseres Codes erheblich. Wenn Sie beispielsweise Ihre Website mit fest codierten URLs von einer Testumgebung in eine Produktionsumgebung migrieren, werden Sie plötzlich feststellen, dass Ihre Website nicht funktioniert. Aus diesem Grund sollten wir Funktionen wie die unten aufgeführte zum Generieren von Dateipfaden und Links verwenden:

 // Get child theme directory uri stylesheet_directory_uri(); // Get parent theme directory get_template_directory_uri(); // Retrieves url for the current site site_url();

Ein weiteres schlechtes Beispiel für Hardcoding ist das Schreiben benutzerdefinierter Abfragen. Als Sicherheitsmaßnahme ändern wir beispielsweise das standardmäßige WordPress-Datentabellenpräfix von wp_ in etwas Einzigartigeres wie wp743_ . Unsere Abfragen schlagen fehl, wenn wir die WordPress-Installation jemals verschieben, da sich die Tabellenpräfixe zwischen den Umgebungen ändern können. Um dies zu verhindern, können wir auf die Tabelleneigenschaften der Klasse wpdb :

 global $wpdb; $user_count = $wpdb->get_var( "SELECT COUNT(*) FROM $wpdb->users" );

Beachten Sie, dass ich nicht den Wert wp_users für den Tabellennamen verwende, sondern WordPress es regeln lasse. Die Verwendung dieser Eigenschaften zum Generieren der Tabellennamen trägt dazu bei, dass wir die richtigen Ergebnisse zurückgeben.

Häufiger Fehler Nr. 5: Die Indizierung Ihrer Website wird nicht verhindert

Warum möchte ich nicht, dass Suchmaschinen meine Website indizieren? Indizieren ist gut, oder? Nun, wenn Sie eine Website erstellen, möchten Sie nicht, dass Suchmaschinen Ihre Website indizieren, bis Sie sie fertig erstellt und eine Permalink-Struktur eingerichtet haben. Wenn Sie außerdem einen Staging-Server haben, auf dem Sie Website-Upgrades testen, möchten Sie nicht, dass Suchmaschinen wie Google diese doppelten Seiten indizieren. Wenn es mehrere Teile von nicht unterscheidbarem Inhalt gibt, ist es für Suchmaschinen schwierig zu entscheiden, welche Version für eine Suchanfrage relevanter ist. Suchmaschinen strafen in solchen Fällen Seiten mit Duplicate Content ab und Ihre Seite leidet darunter in den Suchergebnissen.

Wie unten gezeigt, haben die WordPress-Leseeinstellungen ein Kontrollkästchen mit der Aufschrift „Suchmaschinen davon abhalten, diese Website zu indizieren“, obwohl darunter ein wichtiger Hinweis steht, der besagt, dass „Es Sache der Suchmaschinen ist, dieser Anfrage nachzukommen“.

Bedenken Sie, dass Suchmaschinen dieser Aufforderung oft nicht nachkommen. Wenn Sie also zuverlässig verhindern möchten, dass Suchmaschinen Ihre Seite indexieren, bearbeiten Sie Ihre .htaccess -Datei und fügen Sie folgende Zeile ein:

 Header set X-Robots-Tag "noindex, nofollow"

Häufiger Fehler Nr. 6: Nicht prüfen, ob ein Plugin aktiv ist

Warum sollte ich prüfen, ob eine Plugin-Funktion vorhanden ist, wenn mein Plugin immer eingeschaltet ist? Sicherlich wird Ihr Plugin zu 99% der Zeit aktiv sein. Was ist jedoch mit dem 1% der Zeit, in dem es aus irgendeinem Grund deaktiviert wurde? In diesem Fall wird Ihre Website wahrscheinlich einige hässliche PHP-Fehler anzeigen. Um dies zu verhindern, können wir prüfen, ob das Plugin aktiv ist, bevor wir seine Funktionen aufrufen. Wenn die Plugin-Funktion über das Frontend aufgerufen wird, müssen wir die Bibliothek plugin.php , um die Funktion is_plugin_active() :

 include_once( ABSPATH . 'wp-admin/includes/plugin.php' ); if ( is_plugin_active( 'plugin-folder/plugin-main-file.php' ) ) { // Run plugin code }

Diese Technik ist normalerweise ziemlich zuverlässig. Es kann jedoch Fälle geben, in denen der Autor den Namen des Hauptverzeichnisses des Plugins geändert hat. Eine robustere Methode wäre, die Existenz einer Klasse im Plugin zu prüfen:

 if( class_exists( 'WooCommerce' ) ) { // The plugin WooCommerce is turned on }

Es ist weniger wahrscheinlich, dass Autoren den Namen der Klasse eines Plugins ändern, daher würde ich im Allgemeinen empfehlen, diese Methode zu verwenden.

Häufiger Fehler Nr. 7: Zu viele Ressourcen laden

Warum sollten wir beim Laden von Plugin-Ressourcen für Seiten selektiv vorgehen? Es gibt keinen triftigen Grund, Stile und Skripte für ein Plugin zu laden, wenn dieses Plugin nicht auf der Seite verwendet wird, zu der der Benutzer navigiert ist. Indem wir Plugin-Dateien nur bei Bedarf laden, können wir die Ladezeit unserer Seite verkürzen, was zu einer verbesserten Endbenutzererfahrung führt. Nehmen wir zum Beispiel eine WooCommerce-Seite, wo wir nur wollen, dass das Plugin auf unseren Einkaufsseiten geladen wird. In einem solchen Fall können wir selektiv alle Dateien aus dem Laden auf allen Seiten der anderen Sites entfernen, um das Aufblähen zu reduzieren. Wir können den folgenden Code zur Datei functions.php des Themes oder Plugins hinzufügen:

 function load_woo_scripts_styles(){ if( function_exists( 'is_woocommerce' ) ){ // Only load styles/scripts on Woocommerce pages if(! is_woocommerce() && ! is_cart() && ! is_checkout() ) { // Dequeue scripts. wp_dequeue_script('woocommerce'); wp_dequeue_script('wc-add-to-cart'); wp_dequeue_script('wc-cart-fragments'); // Dequeue styles. wp_dequeue_style('woocommerce-general'); wp_dequeue_style('woocommerce-layout'); wp_dequeue_style('woocommerce-smallscreen'); } } } add_action( 'wp_enqueue_scripts', 'load_woo_scripts_styles');

Skripte können mit der Funktion wp_dequeue_script($handle) über das Handle entfernt werden, mit dem sie registriert wurden. Ebenso verhindert wp_dequeue_style($handle) das Laden von Stylesheets. Wenn Ihnen die Implementierung jedoch zu schwierig ist, können Sie den Plugin-Organizer installieren, der die Möglichkeit bietet, Plugins basierend auf bestimmten Kriterien, wie z. B. einem Beitragstyp oder Seitennamen, selektiv zu laden. Es ist eine gute Idee, alle Caching-Plugins wie W3Cache zu deaktivieren, die Sie möglicherweise eingeschaltet haben, um zu verhindern, dass Sie den Cache ständig aktualisieren müssen, um alle von Ihnen vorgenommenen Änderungen widerzuspiegeln.

Häufiger Fehler Nr. 8: Beibehalten der Admin-Leiste

Kann ich die WordPress Admin Bar nicht einfach für alle sichtbar lassen? Nun, ja, Sie könnten Ihren Benutzern Zugriff auf die Admin-Seiten gewähren. Diese Seiten lassen sich jedoch sehr oft nicht visuell in Ihr ausgewähltes Thema integrieren und bieten keine nahtlose Integration. Wenn Sie möchten, dass Ihre Website professionell aussieht, sollten Sie die Admin-Leiste deaktivieren und eine eigene Front-End-Kontoverwaltungsseite bereitstellen:

 add_action('after_setup_theme', 'remove_admin_bar'); function remove_admin_bar() { if (!current_user_can('administrator') && !is_admin()) { show_admin_bar(false); } }

Wenn der obige Code in die Datei functions.php Ihres Themes kopiert wird, wird die Admin-Leiste nur für Administratoren der Website angezeigt. Sie können jede der WordPress-Benutzerrollen oder -Funktionen zur Funktion current_user_can($capability) hinzufügen, um Benutzer von der Anzeige der Admin-Leiste auszuschließen.

Häufiger Fehler Nr. 9: Den GetText-Filter nicht verwenden

Ich kann CSS oder JavaScript verwenden, um die Beschriftung einer Schaltfläche zu ändern, was ist daran falsch? Nun, ja, das kannst du. Sie fügen jedoch überflüssigen Code und zusätzliche Zeit zum Rendern der Schaltfläche hinzu, wenn Sie stattdessen einen der praktischsten Filter in WordPress verwenden können, genannt gettext . In Verbindung mit der textdomain eines Plugins, einer eindeutigen Kennung, die sicherstellt, dass WordPress zwischen allen geladenen Übersetzungen unterscheiden kann, können wir den gettext -Filter verwenden, um den Text zu ändern, bevor die Seite gerendert wird. Wenn Sie den Quellcode nach der Funktion load_plugin_textdomain($domain) , erhalten Sie den Domainnamen, den wir zum Überschreiben des betreffenden Textes benötigen. Jedes seriöse Plug-in stellt sicher, dass die textdomain für ein Plug-in bei der Initialisierung des Plug-ins festgelegt wird. Wenn Sie Text in einem Design ändern möchten, suchen Sie nach der load_theme_textdomain($domain) . Am Beispiel von WooCommerce können wir den Text ändern, der für die Überschrift „Verwandte Produkte“ angezeigt wird. Fügen Sie den folgenden Code in die Datei functions.php Ihres Themes ein:

 function translate_string( $translated_text, $untranslated_text, $domain ) { if ( $translated_text == 'Related Products') { $translated_text = __( 'Other Great Products', 'woocommerce' ); } return $translated_text; } add_filter( 'gettext', 'translate_string', 15, 3 );

Dieser Filter-Hook wird von den Internationalisierungsfunktionen __() und _e() auf den übersetzten Text angewendet, sofern die textdomain über die oben genannten Funktionen gesetzt wird.

 _e( 'Related Products', 'woocommerce' );

Durchsuchen Sie Ihre Plugins nach diesen Internationalisierungsfunktionen, um zu sehen, welche anderen Zeichenfolgen Sie anpassen können.

Häufiger Fehler Nr. 10: Beibehaltung der Standard-Permalinks

Standardmäßig verwendet WordPress eine Abfragezeichenfolge mit der ID des Beitrags, um den angegebenen Inhalt zurückzugeben. Dies ist jedoch nicht benutzerfreundlich und Benutzer können relevante Teile der URL entfernen, wenn sie sie kopieren. Noch wichtiger ist, dass diese Standard-Permalinks keine suchmaschinenfreundliche Struktur verwenden. Durch die Aktivierung sogenannter „hübscher“ Permalinks wird sichergestellt, dass unsere URLs relevante Schlüsselwörter aus dem Beitragstitel enthalten, um die Leistung in Suchmaschinen-Rankings zu verbessern. Es kann eine ziemlich entmutigende Aufgabe sein, Ihre Permalinks nachträglich zu ändern, insbesondere wenn Ihre Website über einen längeren Zeitraum läuft und Sie Hunderte von Beiträgen haben, die bereits von Suchmaschinen indiziert wurden. Stellen Sie also nach der Installation von WordPress sicher, dass Sie Ihre Permalink-Struktur umgehend in etwas suchmaschinenfreundlicheres als nur eine Post-ID ändern. Ich verwende im Allgemeinen den Beitragsnamen für die meisten von mir erstellten Websites, aber Sie können den Permalink mithilfe der verfügbaren Permalink-Struktur-Tags an ein beliebiges Format anpassen.

Fazit

Dieser Artikel ist keineswegs eine vollständige Liste von Fehlern, die von WordPress-Entwicklern gemacht wurden. Wenn Sie jedoch eines aus diesem Artikel mitnehmen sollten, sollten Sie niemals Abkürzungen nehmen (und das gilt für jede Entwicklungsplattform, nicht nur für WordPress!). Die jetzt durch schlechte Programmierpraktiken eingesparte Zeit wird Sie später heimsuchen. Fühlen Sie sich frei, uns einige Fehler mitzuteilen, die Sie in der Vergangenheit gemacht haben – und, was noch wichtiger ist, alle Lektionen, die Sie gelernt haben – indem Sie unten einen Kommentar hinterlassen.