Fast jeder, der einen Blog auf WordPress betreibt und ihn selbst pflegt, weiß von der Existenz einer magischen Datei „functions.php“. Oftmals wird es komplett zweckentfremdet, was zu erheblichen Problemen führen kann. Schauen wir uns dieses Thema gemeinsam genauer an.

Ich versichere Ihnen, dass Sie nach dem Lesen dieses Artikels Ihre Einstellung gegenüber Plugins ändern und aufhören werden, Ihrer Functions.php ein weiteres Code-Snippet hinzuzufügen.

Viele WordPress-Seitenbesitzer sind fest davon überzeugt, dass Plugins den Blog mit Sicherheit laden und verlangsamen. Und wenn Sie den Code einfach zu „functions.php“ hinzufügen, hat dies keinerlei Auswirkungen auf die Auslastung. Leider stimmt das nicht ganz...

Tatsache ist, dass die Belastung nicht speziell durch das Plugin verursacht wird, sondern durch seinen falsch geschriebenen Code, der leicht in der Datei „functions.php“ aus dem nächsten Handbuch landen kann.

Schauen wir uns die Hauptunterschiede zwischen dem Plugin und Functions.php an.

Der grundlegende Unterschied zwischen einem Plugin und der Datei „functions.php“ besteht in seinem Zweck und seiner Ausführungsreihenfolge.

Es ist auch unbegründet zu glauben, dass der Code in „functions.php“ schneller ausgeführt wird als im Plugin. Der gleiche Code im Plugin und in der Functions.php wird mit der gleichen Geschwindigkeit und Last ausgeführt.

Sehr oft treten Probleme mit hoher Auslastung aufgrund der zusätzlichen Funktionalität von Plugins auf, und die Ladegeschwindigkeit der Website leidet unter Skripten, die ihre eigenen Stile, Skripte und andere Inhalte verbinden. Daher ist es wichtig, auf die Wahl des Plugins zu achten, um zukünftige Probleme zu vermeiden.

Wenn Sie ein gewöhnlicher Blogger sind und weit von der Webentwicklung entfernt sind, achten Sie bei der Auswahl eines Plugins unbedingt auf die Bewertungen im WordPress-Repository und in den Blogs von Autoren oder Webentwicklern.

Wenn Sie immer noch Zweifel haben, kochen Sie eine Tasse Kaffee und lesen Sie unbedingt den Artikel von Konstantin Kovshenin im WP Magazine – „Die ganze Wahrheit über Functions.php“. Der erste Teil erklärt einfach und klar, warum Sie nicht an Mythen über Functions.php glauben sollten.

Alle Ergänzungen, die Sie an den Vorlagendateien vornehmen (Skripte, Zähler, Funktionen), gehen möglicherweise verloren, wenn Sie das aktive Design ändern oder Updates darauf anwenden. Um dies zu vermeiden und kein Chaos in der Functions.php zu verursachen, empfehle ich Ihnen, Ihr eigenes persönliches Plugin zu verwenden.

Lassen Sie uns unser eigenes Plugin erstellen – eine Alternative zur Datei „functions.php“. Haben Sie keine Angst, es wird genauso aussehen wie Ihre Lieblings-functions.php :) Sie müssen lediglich ein leeres Plugin zu Ihrer Site hinzufügen. Und dann können Sie dort den nötigen Code einfügen, wie Sie es früher mit der Functions.php gemacht haben.

Zunächst müssen wir auf unserem Computer eine Datei namens „functionsphp.php“ erstellen und den folgenden Code hinzufügen:

// ... Anstelle dieser Zeile den Zählercode einfügen... .

Das Exec-PHP-Plugin befindet sich im Repository und wird über das Menü im Engine-Admin-Panel installiert.

Von den Einstellungen gibt es nur eine – Erlaubnis/Verbot der Codeausführung in einem Text-Widget, es gibt keine Möglichkeit, die Arbeit in Beiträgen und auf Seiten zu deaktivieren, wenn Sie es entfernen müssen, deaktivieren Sie das Plugin.

Um PHP-Code in einen Artikel einzufügen, muss dieser in den HTML-Modus (Registerkarte Text) umgeschaltet werden. Der visuelle Modus wird höchstwahrscheinlich den Code verderben.

Analog zu Widgets können wir das Plugin durch eine spezielle Funktion ersetzen, die die Ausführung von PHP-Skripten im Inhalt ermöglicht. Leider konnte ich keine Option finden, bei der der Code wie bei einem Plugin automatisch funktioniert und auf Tags reagiert. Erfordert die Verwendung eines Shortcodes. Meine PHP-Kenntnisse reichten nicht aus, um die erforderliche Funktion selbst zu schreiben, daher präsentiere ich sie so, wie sie ist. Die Arbeit mit einem Shortcode hat einen erheblichen Nachteil, der die Arbeit erschwert, auf den ich weiter unten eingehen werde.

So verwenden Sie die folgende Funktion

Funktion:

/* PHP in WordPress-Artikeln und -Seiten ausführen: Code */ function start_php($matches)( eval("ob_start();".$matches."$inline_execute_output = ob_get_contents();ob_end_clean();"); return $inline_execute_output ; ) function inline_php($content)( $content = preg_replace_callback("/\((.|\n)*?)\[\/startphp\]/", "start_php", $content); $content = preg_replace( "/\((.|\n)*?)\[\/startphp\]/", "$1", $content); return $content; ) add_filter("the_content", "inline_php");

Wenn der eingefügte PHP-Code HTML-Einfügungen oder Text enthält, funktioniert er nicht. Jeglicher Text oder Tags müssen mit dem Echo-Befehl eingefügt werden, was nicht immer praktisch ist. Das heißt, der Code muss reiner PHP-Code mit 100 korrekten Formaten sein.

Rechts

Echo „So wird es funktionieren“;

Falsch

Echo „Diese Zeile ist korrekt“; So wird es nicht funktionieren

Im Exec-PHP-Plugin gibt es kein solches Problem – sowohl Text als auch HTML werden ausgeführt, aber alle Elemente des PHP-Codes müssen in die entsprechenden Tags eingerahmt werden.

Für viele Webmaster eröffnet das in diesem Artikel beschriebene Thema endlose Möglichkeiten der Kreativität – Sie können etwas umsetzen, was vorher nicht möglich war, und außerdem auf viele Plugins verzichten und diese durch andere Filter, Funktionen und Hooks ersetzen.

Plugins sind eine Möglichkeit, die Funktionalität einer Anwendung zu erweitern, ohne deren Quellcode zu ändern. Die vom Plugin implementierten Funktionen funktionieren auch nach der Installation von Anwendungsupdates weiter, wenn ihre Dateien überschrieben werden. Der Quellcode des Plugins wird in unabhängige Dateien kompiliert, die nur mit der Anwendung verbunden sind.

Die Plugin-Lokalisierung wird auf völlig ähnliche Weise wie die Anwendungslokalisierung (Dokumentation) implementiert. Im Locale-Ordner sollten Sie die Übersetzungsdateien *.po und *.mo ablegen und die Schlüssel wie folgt in den Code einbinden:

• _wp("string") in PHP (anstelle der _w()-Methode, die nur mit der Anwendungslokalisierung funktioniert, sollten Sie die _wp()-Methode verwenden, die die Plugin-Lokalisierung lädt),
• [`string`] in Smarty-Vorlagen (hier gibt es keine Unterschiede zur Anwendungslokalisierung).

Der Name und die Beschreibung des Plugins (Name und Beschreibung in der Konfigurationsdatei) werden mithilfe der Standard-Plugin-Lokalisierung übersetzt, sodass keine Angabe von „name“ => _wp(„PLUGIN NAME“) erforderlich ist – geben Sie einfach „name“ = an > „PLUGIN-NAME“ .

Beim Aufruf öffentlicher statischer Methoden von Plugin-Klassen in einer externen Umgebung, beispielsweise im Theme-Code, wird die Plugin-Lokalisierung nicht automatisch verbunden und die Funktion _wp() gibt nicht wie erwartet einen Zeilenumbruch zurück. Um die Plugin-Lokalisierung in solchen Methoden zu verwenden, müssen Sie alle Aufrufe der Funktion _wp() in einem speziellen Konstrukt platzieren, das im folgenden Beispiel fett dargestellt ist:

Die Klasse appMyPlugin erweitert waPlugin ( öffentliche statische Funktion displayData() ( // Geben Sie in beiden Zeilen die ID der Anwendung und Ihres Plugins an waLocale::loadByDomain(array("app_id", "plugin_id")); waSystem::pushActivePlugin("plugin_id ", " app_id"); $result = _wp("..."); waSystem::popActivePlugin(); return $result; ) )

Wenn das Plugin eigene Tabellen in der Datenbank verwendet, sollten die Tabellennamen mit einem Fragment wie __ beginnen, zum Beispiel: shop_ebay_ Tabellenname.

Damit das geschriebene Plugin funktioniert, müssen Sie es in der Konfigurationsdatei des Anwendungssystems wa-config/apps/APP_ID/plugins.php verbinden und die Zeile hinzufügen:

"plugin_id" => true

Ein Beispiel dieser Datei für die Blog-Anwendung (wa-config/apps/blog/plugins.php):