Die 12 schlimmsten Fehler fortgeschrittener WordPress-Entwickler

WordPress ist eine sehr beliebte Methode, um eine Website schnell zum Laufen zu bringen. In ihrer Eile treffen jedoch viele Entwickler schreckliche Entscheidungen. Einige Fehler, wie das Belassen von WP_DEBUG auf true , können leicht gemacht werden. Andere, wie das Zusammenfassen Ihres gesamten JavaScripts in einer einzigen Datei, sind so üblich wie faule Ingenieure. Welchen Fehler Sie auch immer machen, lesen Sie weiter, um die 12 häufigsten WordPress-Fehler herauszufinden, die neue und erfahrene Entwickler machen. Wenn Sie feststellen, dass Sie einen dieser Fehler begehen, verzweifeln Sie nicht. Jeder Fehler ist eine Chance zu lernen.

1. Platzieren des JavaScript-Codes des WordPress-Themes in einer Hauptdatei

Als ich einmal die Seitengeschwindigkeit für die Websites eines Kunden optimierte, bemerkte ich, dass sie ein Premium-Theme verwendeten, das alle verwendeten Bibliotheken, einschließlich des benutzerdefinierten Codes, in einer einzigen Datei namens main.js , theme.js oder custom.js . Diese Praxis ist aus folgenden Gründen schlecht:

1. Die Datei kann mit der Zeit sehr groß werden, da das Thema, das aktiv entwickelt wird, an Funktionen zunimmt und manchmal Dateien mit einer Größe von bis zu 1 MB angezeigt werden. Die Datei wird auf der gesamten Website geladen, auch wenn auf einigen Seiten nur 10 % des Codes aus der Datei benötigt werden. Dadurch dauert das Herunterladen von Seiten länger und das Rendern wird langsamer, insbesondere wenn es sich um Code zum Blockieren des Renderns im Head-Bereich der Seite handelt.
2. Es erschwert die Verwaltung des Codes in der Datei, da Sie Funktionen wie wp_dequeue_script() nicht verwenden können, um einen Teil des Codes auf einigen Seiten zu entladen, um entweder die Seitengeschwindigkeit zu verbessern oder einen möglichen Konflikt mit anderem JavaScript-Code zu verhindern von einem der aktiven Plugins geladen. Sicher, die Datei kann in mehrere aufgeteilt und in WordPress eingereiht werden, aber wenn der Website-Administrator zu einem späteren Zeitpunkt ein Update der main.js -Datei des Themes durchführt, muss der gesamte Prozess von vorne beginnen.

2. Verwendung von Namen, die für Variablen, Funktionen, Konstanten oder Klassen zu gebräuchlich sind

Bei der Entwicklung eines Plugins ist es besser, eine Namenskonvention zu verwenden, die Codekonflikte verhindert, falls andere Plugins denselben Namen verwenden. Aus diesem Grund stellen viele Entwickler ihren Variablen- und Funktionsnamen etwas Einzigartiges voran, das sich auf das Plugin selbst bezieht. Neben der Eliminierung von Codekonflikten erleichtert es auch die Suche, wenn Sie viele Plugins aktiviert haben.

Auf der anderen Seite gibt es Entwickler, die es vorziehen, PHP-Namespaces zu verwenden, um Elemente zu kapseln und die beiden Probleme zu lösen, auf die Autoren von Bibliotheken und Anwendungen stoßen, wenn sie wiederverwendbare Codeelemente wie Klassen oder Funktionen erstellen:

1. Namenskollisionen zwischen dem von ihnen erstellten Code und internen Klassen, Funktionen oder Konstanten von PHP oder Drittanbietern
2. Fähigkeit, Extra_Long_Names zu aliasieren (oder zu verkürzen), um das erste Problem zu beheben oder die Lesbarkeit des Quellcodes zu verbessern. Dies ist mein Favorit, da ich oft Themen oder Plugins entwickle, die viel Code enthalten. Damit kann ich den Code einfach lesen und verwalten, ohne mir große Gedanken über lange eindeutige Namen machen zu müssen.

Ich empfehle ein gutes Verständnis von Namespaces, bevor Sie sie verwenden, da sie oft falsch verwendet werden können.

Abhängig von dem Projekt, das Sie an Bord nehmen, müssen Sie wahrscheinlich beim vorhandenen Programmierstil bleiben, es sei denn, Ihre Arbeit ist größtenteils von dem vorhandenen getrennt. Falls Sie ein vorhandenes Plugin oder Theme erweitern müssen, das bereits den PHP-Codierungsstandards für WordPress folgt, dann ist es am besten, sich an diese zu halten, um einen einheitlichen Stil zu haben, damit der Code sauber und leicht lesbar wird. Beachten Sie, dass einige Regeln universell angewendet werden, um die Leistung zu verbessern, unabhängig vom Codierungsstil. Beispielsweise ist es immer am besten, einfache Anführungszeichen (anstelle von doppelten) zu verwenden, wenn Sie nichts in der Zeichenfolge auswerten. Außerdem muss der Code eingerückt werden, damit er gelesen werden kann, insbesondere wenn er verschachtelten Code enthält (z. B. IF s in IF s, verschachtelte FOREACH s und FOR s).

3. Die vorhandene WordPress-Kernfunktionalität nicht zu ihrem wahren Potenzial nutzen

Da WordPress mit einer Reihe regelmäßig aktualisierter Bibliotheken geliefert wird, die einfach in unseren Plugins und Themes aufgerufen werden können, ist es am besten, so viel wie möglich von der vorhandenen Kernfunktionalität zu nutzen. Ich habe WordPress-Themes und Plugins gesehen, die Dateien in ihrem Assets-Verzeichnis hatten, die bereits in den WordPress-Core-Dateien enthalten waren (z. B. jQuery oder Color Picker). Abgesehen davon, dass das Paket größer wird und das Laden über das Netzwerk länger dauert, müssen Sie auch sicherstellen, dass alle Bibliotheken von Drittanbietern regelmäßig aktualisiert werden, was nur eine weitere Sache ist, um die Sie sich kümmern müssen.

Nutzen Sie das, was WordPress bereits zu bieten hat, da die Bibliotheken bereits vom WordPress-Entwicklungskernteam aktualisiert werden und Sie ein schlankes und einfacher zu wartendes Projekt haben können. Indem Sie regelmäßig WordPress-Updates durchführen, erhalten Sie Zugriff auf mehr Funktionen (ob es sich um ein Plugin, ein Design oder den WordPress-Kern selbst handelt, da das Dashboard ständig verbessert wird) und machen die Website sicherer, falls Schwachstellen in den alten Code-Versionen gefunden werden.

4. Das Plugin oder Theme nicht durch Aktionen und Filter leicht änderbar zu machen

Das direkte Bearbeiten eines WordPress-Plugins oder -Themes ist eine schlechte Idee, es sei denn, Sie sind natürlich direkt an der Entwicklung dieses Pakets beteiligt und tragen zu seinem Code bei. Wenn ein automatisches Update des Plugins oder des Designs durchgeführt wird, gehen alle direkten Änderungen am Paket verloren und Sie müssen die Dateien erneut bearbeiten.

Aus diesem Grund sind die Verwendung von Aktionen und Filtern sowie das Erstellen eines untergeordneten Designs (das das übergeordnete Design erweitert) die effektivsten Ansätze zum Ändern eines Designs, da Sie die vorhandene Funktionalität ändern können, ohne das übergeordnete Design oder das Plugin selbst zu bearbeiten. Wenn Sie außerdem ein Plugin zum kostenlosen Download auf WordPress.org anbieten und später eine Premium-Erweiterung erstellen möchten, die vom übergeordneten Plugin abhängt, sollten Sie das kostenlose Plugin so entwickeln, dass dies der Fall ist einfach zu erweitern und Premium-Erweiterungen hinzuzufügen.

5. Entwickeln mit WP_DEBUG Auf „ false “ setzen

Standardmäßig ist die Konstante WP_DEBUG auf „false“ gesetzt, um das Drucken von PHP-Fehlern, Warnungen und Hinweisen zu vermeiden. In einer Live-Umgebung ist dies eine empfohlene Wahl, da private Serverpfade und Skripte vor der Öffentlichkeit verborgen bleiben, was aus Sicherheitsgründen großartig ist. Während der Entwicklungsphase ist es jedoch am besten, es auf "true" zu setzen, da es uns über alle Fehler in unserem Code informiert. Auch wenn sich die Fehler nicht direkt auf die Funktionalität auswirken, werden Sie oft gezwungen, besseren Code zu schreiben und bessere Programmiergewohnheiten zu entwickeln. Es ist mir passiert. Dadurch wird auch sichergestellt, dass das von Ihnen entwickelte Plugin oder Design in keiner WordPress-Installation PHP-Fehler generiert.

Während dies etwas ist, was die meisten erfahrenen Entwickler tun, passiert es, besonders in Eile. Egal wie dringend der Job ist, Entwickler sollten immer versuchen, die WordPress-Codierungsstandards einzuhalten, mit einem offensichtlichen Auge auf die Best Practices von PHP.

6. PHP-Code schreiben, ohne zu bedenken, dass die Seite eines Tages zwischengespeichert werden könnte

Dies ist ein häufiger PHP-Fehler und wie der vorherige relativ einfach zu vermeiden, wenn Sie sich an die PHP-Codierungsstandards halten.

Einige Entwickler haben die Angewohnheit, PHP-Snippets in Themes und Plugins zu implementieren, die nur gültig sind, wenn der PHP-Code die ganze Zeit ausgelöst wird. Beispielsweise sollte eine PHP-Funktion, die mit bestimmten Aktionen auf den HTTP-Benutzeragenten antwortet, ausgeführt werden oder nicht (z. B. das Einreihen von Skripts, die nur für mobile Benutzer gedacht sind).

Wenn Ihr Client ein Plugin installiert, das die Seite zwischenspeichert (z. B. W3 Total Cache oder WP Rocket), ohne die Bedingungen in Ihrem Design oder Ihren Plugins auszulösen, wird Ihr PHP-Code unbrauchbar. Wenn die Seiten responsive gemacht werden sollen, dann sollte dies auf der Frontend-Seite durch Medienabfragen und JavaScript geschehen. Letzteres nur, wenn es wirklich erforderlich ist. Idealerweise möchten Sie die Verwendung von JavaScript vermeiden, um Ihre Website reaktionsfähig zu machen.

7. Nicht professionell vorgenommene Änderungen über ein Versionskontrollsystem wie Git nachverfolgen

Dateien, die kundenspezifisch codiert sind, wie z. B. ein untergeordnetes Design oder ein benutzerdefiniertes Plugin, sollten idealerweise unter Versionskontrolle stehen. Git erstellt eine Aufzeichnung der Änderungen und ermöglicht es Entwicklern, gemeinsam am selben WordPress-Projekt zu arbeiten oder einfach zu einer früheren Version zurückzukehren, wenn etwas mit der Website schief geht. Darüber hinaus können Kunden Git verwenden, um den gesamten Arbeitsverlauf aller Entwickler zu verfolgen, die für dieses bestimmte Projekt eingestellt wurden, insbesondere wenn es sich um eine große, langfristige benutzerdefinierte WordPress-Website handelt.

Obwohl es am Anfang einschüchternd sein kann, besonders für Junior-Entwickler, wird es sich lohnen, Git zu verstehen, und eine Git-GUI-Software wie SourceTree (einer meiner Favoriten) wäre einfach die Art und Weise, wie Sie mit Ihren Git-Repositories interagieren und das Ganze machen Lernkurve angenehmer. Sobald Sie verstanden haben, wie es funktioniert, sollten Sie sich die Best Practices und Tipps für Git von Toptal-Entwicklern ansehen, die einige Möglichkeiten der Verwendung von Git ausführlicher erläutern.

8. Einreihen von CSS- und JavaScript-Dateien in die Warteschlange, wenn sie nicht benötigt werden

Viele HTTP-Anfragen würden das Laden der Website verlangsamen und somit eine niedrigere Punktzahl in Google PageSpeed ​​haben, was sich wahrscheinlich auf das Suchranking auswirken würde. Es könnte auch zu JavaScript-Fehlern aufgrund von Konflikten zwischen Plugins führen. Beispielsweise könnten zwei Plugins eine gemeinsame jQuery-Bibliothek verwenden, die möglicherweise zweimal geladen wird und Probleme verursachen kann. Und das ist wirklich das beste Beispiel, da jQuery sehr häufig mehrfach auf Live-Websites geladen wird. Dies geschieht wahrscheinlich aufgrund schlecht geschriebener Plugins oder Designs.

9. Verwendung .php Dateien zur Ausgabe von CSS- oder JavaScript-Code anstelle von statischen .css und .js Dateien

Ich habe Themen und sogar WordPress-Plugins gesehen, die Dateien wie style.php hatten, die nur zum Generieren von benutzerdefiniertem CSS-Code und zum Drucken verwendet wurden. Dinge wie Farben, Schriftgrößen und Abstände um Elemente herum wurden in den Einstellungen des Themas festgelegt und dann in der Datenbank gespeichert. Dann wird die style.php ausgelesen (zB <link rel='stylesheet' type='text/css' href='css/style.php?ver=1' /> ) und den CSS-Code anhand der benutzerdefinierten Einstellungen daraus generiert wurden im Dashboard aktualisiert.

Dies ist wirklich eine schlechte Praxis in Bezug auf die Leistung von WordPress. Hier sind die wichtigsten Nachteile, die damit einhergehen:

1. Da die CSS-Datei innerhalb des head -Tags geladen wird (was normal ist und die meisten von ihnen so geladen werden), gibt es ein Leistungsproblem, das damit einhergeht, da der Browser die Datei vollständig herunterladen muss, bevor die Seite gerendert wird. Wenn die WordPress-Umgebung aufgrund einiger Plugins langsam ist, verzögert dies die Ladezeit erheblich. Auch wenn Caching-Techniken verwendet werden oder nur ein Teil der WordPress-Umgebung geladen wird, um die Werte aus der Datenbank abzurufen. Verwenden Sie stattdessen am besten eine statische .css-Datei.
2. In der PHP-Datei ist der Code (CSS-Regeln gemischt mit PHP-Variablen und Bedingungsklauseln) für Entwickler schwieriger zu lesen, wenn sie etwas auschecken müssen. Sicher, die Datei kann im Browser ausgeführt werden (obwohl ich sicher bin, dass sie beim Drucken nicht einmal eingerückt ist oder gut aussieht), aber wenn Sie eine lokale Kopie des Projekts haben und den Code des Themas durchsuchen und Sie brauchen um eine CSS- oder JavaScript-Syntax zu finden (falls script.php verwendet würde), würde dies die Lesbarkeit erschweren.

Die Lösung: Speichern Sie jedes benutzerdefinierte CSS außerhalb des Plugin-Verzeichnisses. Beispiel: /wp-content/uploads/theme-name-custom-css/style-5.css . Auf diese Weise geht die benutzerdefinierte Datei nicht verloren, falls das Design oder Plugin aktualisiert wird.

10. Nicht die richtige Architektur (Code-Organisation) für die WordPress-Plugins und -Themes verwenden

Je nach Größe und Art des Plugins (z. B. ein eigenständiges Plugin oder eine Plugin-Erweiterung, die nur funktioniert, wenn ein Haupt-Plugin aktiviert ist, wie z. B. WooCommerce), muss die richtige Architektur und Code-Organisation eingerichtet werden.

Wenn Sie ein WordPress-Plugin für einen einzigen Zweck für einen Kunden erstellen müssen und es nur eine begrenzte Interaktion mit dem WordPress-Kern, Themen und anderen Plugins hat, ist es nicht effektiv, komplexe Klassen zu entwickeln, es sei denn, Sie sind sich sicher, dass das Plugin später erheblich erweitert wird an.

Wenn das Plugin reich an Code sein soll, dann wäre die Verwendung eines OOP-Codierungsansatzes (Objected Oriented Programming) (mit vielen Klassen) sinnvoll. Wenn Sie beispielsweise viele Shortcodes haben, können Sie sie alle in einer separaten Klassendatei wie class.shortcodes.php oder wenn CSS- und JavaScript-Dateien vorhanden sind, die in das Dashboard und die Frontend-Ansicht geladen werden sollen dann kann eine Klasse wie class.scripts.php verwendet werden und die Frontend-Dateien innerhalb einer Methode wie enqueue_public_scripts() in die Warteschlange stellen, während die Dateien, die in den Admin-Bereich geladen werden sollen, innerhalb der enqueue_admin_scripts() Methode in die Warteschlange gestellt werden.

Anstatt den HTML-Code mit dem PHP-Code zu mischen, ist es besser, ihn getrennt zu halten, indem das MVC-Muster in die Plugins und Themes implementiert wird. Ein gutes Beispiel ist das WooCommerce-Plugin. Es hat Vorlagen für verschiedene Layouts, die auch einfach durch das Thema oder verschiedene Filter überschrieben werden können, nur weil die Logik vom Design getrennt ist. Die Vorlage, die das HTML-Layout enthält, wird meistens zum Drucken der bereits verarbeiteten Informationen verwendet. HTML-Code innerhalb von PHP-Methoden zu haben, ist normalerweise eine schlechte Praxis (es gibt natürlich Ausnahmen für kleine Teile von HTML-Code), insbesondere für ein Plugin, das von mehr als einem Entwickler gepflegt wird, wenn es an Größe zunimmt.

Laut dem WordPress Plugin Handbook gibt es zwar eine Reihe möglicher Architekturmuster, diese können jedoch grob in drei Varianten eingeteilt werden:

• Einzelne Plugin-Datei, die Funktionen enthält
• Einzelne Plugin-Datei, die eine Klasse, ein instanziiertes Objekt und optional Funktionen enthält
• Haupt-Plugin-Datei, dann eine oder mehrere Klassendateien

11. WordPress-Sicherheit beim Schreiben von Code nicht ernst nehmen

Sicherheit wird in der WordPress-Entwicklung oft nicht ernst genommen, da sich viele unerfahrene Entwickler mehr auf die Ergebnisse konzentrieren, die der Kunde will. Alles ist in Ordnung, bis die Website des Kunden gehackt wird oder Ihr auf WordPress.org veröffentlichtes Plugin eine Schwachstelle aufweist, wodurch Tausende von Websites betroffen sind. Diese Dinge passieren manchmal und sogar der WordPress-Kern hat sich seit den Anfängen des CMS mit einer ganzen Reihe von Sicherheitslücken befasst. Es liegt in unserer Verantwortung, es so sicher wie möglich zu machen und, falls etwas passiert, umgehend zu handeln und sicherzustellen, dass wir einen soliden, gut getesteten Patch veröffentlichen.

Einige der wichtigsten Sicherheitstipps sind:

XSS-Schwachstellen: Um dies zu vermeiden, müssen zwei Dinge getan werden: Dateneingabe bereinigen und Ausgabedaten bereinigen. Abhängig von den Daten und dem Kontext, in dem sie verwendet werden, gibt es in WordPress mehrere Methoden, um Code zu bereinigen. Man sollte weder Eingabedaten vertrauen, noch Daten, die gedruckt werden sollen. Eine gängige Funktion zum Bereinigen von Dateneingaben ist sanitize_text_field() . Es prüft auf ungültige UTF-8-Zeichen, konvertiert einzelne <-Zeichen in HTML-Einheiten, entfernt alle Tags, entfernt Zeilenumbrüche, Tabulatoren und zusätzliche Leerzeichen und entfernt Oktette. Was das Drucken von Daten betrifft, so ist ein gutes Beispiel für die Ausgabe von Links die Funktion esc_url() , die ungültige URLs zurückweist, ungültige Zeichen eliminiert und gefährliche Zeichen entfernt.

Verhindern Sie den direkten Zugriff auf Ihre Dateien: Auf Dateien kann direkt zugegriffen werden, da die meisten Hosts dies zulassen. Wenn dies jedoch passiert und der Code nicht richtig geschrieben ist, um damit umzugehen, werden möglicherweise einige Fehler ausgegeben (z. B. fehlende Funktionen oder nicht deklarierte Variablen), die für potenzielle Angreifer wertvolle Informationen enthalten würden. Ein gängiges Code-Snippet, das Sie oft in Plugins und Themes sehen, ist:

 // Exit if accessed directly if ( ! defined( 'ABSPATH' ) ) exit;

Wenn die Konstante ABSPATH nicht definiert ist (was für jede WordPress-Installation gelten sollte), wird das Skript beendet und nichts gedruckt.

Verwenden Sie Nonces: Wie in der WordPress-Dokumentation angegeben, ist eine Nonce eine „einmal verwendete Nummer“, um URLs und Formulare vor bestimmten Arten von Missbrauch zu schützen, ob böswillig oder anderweitig.

Beispielsweise würde die folgende URL im Dashboard verwendet, um einen Beitrag zu löschen: http://example.com/wp-admin/post.php?post=123&action=trash – Beim Zugriff auf diese URL validiert WordPress die Authentifizierungs-Cookie-Informationen und wenn Sie die richtige Berechtigung haben (z. B. wenn Sie ein Administrator mit allen Rechten sind), wird dieser Beitrag gelöscht.

Ein Angreifer könnte Ihren Browser ohne Ihr Wissen auf diese URL zugreifen lassen, indem er einen Link auf einer Drittanbieterseite erstellt, wie im folgenden Beispiel: <img src="http://example.com/wp-admin/post.php?post=123&action=trash" /> Wenn Sie diese Anfrage an WordPress stellen, wird der Browser automatisch Ihr Authentifizierungs-Cookie anhängen und WordPress würde die Anfrage als gültig betrachten.

An diesem Punkt kommt ein Nonce zum Einsatz, da der Angreifer den Nonce-Wert (der für den Administrator generiert wird, der tatsächlich bei WordPress angemeldet ist) nicht so einfach erhalten kann. Die neue Anforderungs-URL würde wie folgt aussehen: http://example.com/wp-admin/post.php?post=123&action=trash&_wpnonce=b192fc4204

Ohne gültige Nonce würde WordPress eine 403 Forbidden Response mit der bekannten Fehlermeldung: „Are you sure you want to do this?“ an den Browser senden.

Obwohl die meisten Leute die WordPress-Sicherheit nicht ernst nehmen, denken sie, dass ihre Website niemals gehackt werden würde, vertrauen dem Hosting (was hilfreich sein kann, aber nur bis zu einem gewissen Punkt) und der Tatsache, dass sie kommerzielle Plugins/Themes gekauft haben (was oft dazu führt in der Annahme, dass sie sehr sicher sind), sollten wir immer Penetrationstests für unsere Websites durchführen, um ausnutzbare Schwachstellen zu identifizieren, bevor ein Hacker sie identifizieren und ausnutzen kann.

Beachten Sie, dass eine große Anzahl von Hacks da draußen nicht einmal von einer Person mit der Absicht durchgeführt werden, Ihre Website gezielt zu hacken. Oftmals gibt es Bots, die WordPress-Websites regelmäßig und automatisch scannen, und in dem Moment, in dem eine bekannte Sicherheitslücke gefunden wird, wird sie ausgenutzt und der Server zum Spammen verwendet, um private Informationen aus der Datenbank zu erhalten und versteckte Links auf bestimmten Seiten der Website zu platzieren würde zu allen Arten von zwielichtigen Websites führen (z. B. Pornografie, illegale Drogen). Manchmal sind die Hacks so gut versteckt, dass Sie Ihre Website gründlich scannen und das Datum sehen müssen, an dem bestimmte Dateien aktualisiert wurden, um den gehackten Code zu erkennen. Aus diesem Grund ist es gut, WordPress sogar neu zu installieren (ja, die gleiche Version, wenn Sie die letzte haben), damit alle gehackten Dateien von den echten WordPress-Kerndateien überschrieben werden.

12. Verwenden von WordPress-Funktionen und Code-Snippets, ohne sie zu verstehen

Wenn Entwickler an Orten wie StackOverflow stecken bleiben und eine Lösung finden, sind sie oft einfach zufrieden mit der Tatsache, dass sie es geschafft haben, etwas zum Laufen zu bringen, ohne sich die Mühe zu machen, die Logik hinter diesem Code zu verstehen oder ob dieser Code geändert werden kann, um schneller zu laden oder weniger zu haben Zeilen von Code.

Ich habe diese Praxis so oft gesehen, wenn Codeschnipsel in PHP-Skripte kopiert werden, wenn nur ein Drittel dieses Codes tatsächlich verwendet wird.

Dies kann einige Nachteile haben, darunter:

1. Der Code verwendet nicht denselben Stil wie der vorhandene Projektcode. Ja, es ist bequem, einfach Snippets zu kopieren und einzufügen, die sofort einsatzbereit sind, und obwohl sie für ein kleines persönliches Projekt in Ordnung sind (es könnte eines Tages zu einem großen Projekt werden, wer weiß), ist diese Praxis oft nicht gut, wenn es darum geht bis hin zu kommerziellen Arbeiten, bei denen eine Stilkonsistenz eingehalten werden muss.
2. Obwohl der Code seine Aufgabe erfüllt, könnte er unwirksame Funktionen enthalten, die für die zu erfüllende Aufgabe nicht empfohlen werden. Wenn der Code nicht optimiert ist, kann diese „Kopieren und Einfügen“-Praxis zu einer langsamen und schwieriger zu wartenden Website führen, insbesondere wenn mehr als ein Snippet an verschiedenen Stellen innerhalb des Projekts verwendet wird.
3. Der Code darf nicht zur Wiederverwendung lizenziert werden, und die Aufnahme des Codes in das Projekt eines Kunden kann zu vielen rechtlichen Problemen führen.

Ständige Verbesserung

Jeder macht Fehler und jeder Fehler ist eine Gelegenheit, sich zu verbessern. Als WordPress-Entwickler bewegt sich unsere Branche sehr schnell, und es gibt nie den einen „richtigen Weg“, Dinge zu tun. Je mehr Sie jedoch üben und lernen, desto besser werden Sie.

Sind Sie mit einem der Fehler, auf die ich hingewiesen habe, nicht einverstanden oder glauben Sie, ich habe einen übersehen? Lass es mich in den Kommentaren wissen und wir diskutieren.