Eigenen Code in WordPress einbauen: Welcher Weg wofür passt

Ein Rechner, ein Skript, ein kleiner Effekt: Früher oder später soll etwas auf Ihre WordPress-Website, das kein Plugin genau so kann. Der Code selbst ist dabei oft das kleinere Problem. Entscheidend ist, wo er liegt, denn manche Orte überstehen das nächste Update nicht.

Code für eine einzelne Seite gehört in den Block „Individuelles HTML“. Kleiner Code für die ganze Website gehört in ein Snippet-Plugin oder ein Child-Theme, größerer in ein eigenes Plugin. Nie in die functions.php eines fertigen Themes: Das nächste Theme-Update löscht ihn ohne Warnung.

Getestet habe ich jeden Weg auf einer Testinstallation mit WordPress 7.1.4 auf Deutsch und PHP 8.4, auch mit absichtlich fehlerhaftem Code.

Welcher Weg passt für Ihren Code in WordPress?

• Ein Element auf einer einzelnen Seite (Rechner, Karte, Einbettung): der Block „Individuelles HTML“ oder das Code-Modul Ihres Page-Builders.
• Ein paar Zeilen für die ganze Website, ohne FTP: ein Snippet-Plugin.
• Änderungen, die zum Aussehen gehören und mit dem Theme auch wieder gehen sollen, falls es einmal durch ein anderes Theme ersetzt werden sollte: ein Child-Theme.
• Funktionen, die jeden Theme-Wechsel überleben sollen: ein eigenes kleines Plugin.
• Code, der immer laufen muss und den niemand versehentlich abschalten darf: ein Must-Use-Plugin.

Wenn Sie Code nur zeigen, nicht ausführen wollen, ist das ein anderes Thema, das ich schon in folgendem Artikel im Detail beschrieben habe: Code-Beispiele auf der WordPress-Website.

Bevor Sie etwas ändern: Ein falscher Handgriff kann mehr Schaden anrichten als der Fehler selbst. Ein Tippfehler in der wp-config.php legt die ganze Website lahm, ein falscher Befehl in der Datenbank oder auf der Kommandozeile lässt sich oft nicht zurücknehmen. Mit diesen Regeln bleibt jeder Schritt umkehrbar:

• Zuerst eine vollständige Sicherung von Dateien und Datenbank, abgelegt außerhalb Ihres Webspace. Viele Hoster bieten dafür eine eigene Funktion an. Fragen Sie im Zweifel nach, wie Sie die Sicherung wieder einspielen.
• Vor jeder Bearbeitung eine Kopie der Datei auf Ihren eigenen Rechner laden. Eine Kopie auf dem Server darf nicht wp-config.php.bak heißen, denn so kann sie jeder samt Datenbank-Passwort im Browser abrufen. Nennen Sie sie wp-config-kopie.php, und löschen Sie sie am Ende.
• Immer nur eine Änderung, dann testen. Hat sie nicht geholfen, machen Sie sie rückgängig, bevor Sie die nächste versuchen.
• Eine Testkopie (Staging) nutzen, wenn Ihr Hoster eine anbietet: Dort darf alles schiefgehen.
• Aufhören ist eine gute Option: wenn Sie nicht mehr wissen, was Sie geändert haben, wenn ein Schritt anders aussieht als hier beschrieben oder wenn die Website täglich Geld verdient. Dann schreiben Sie mir, das Angebot steht am Ende dieses Beitrags.

Code für eine einzelne WordPress-Seite: der Block „Individuelles HTML“

Der einfachste Weg kommt ohne Plugin aus: Im Block-Editor fügen Sie den Block „Individuelles HTML“ ein und schreiben den Code hinein. Er gilt nur für diese eine Seite. In Divi heißt das Gegenstück Code-Modul.

Ein Haken kann Sie Stunden kosten: Ob ein Skript gespeichert wird, hängt von Ihrer Benutzerrolle ab. Ich habe denselben Block mit einem script und einem iframe unter jeder Rolle gespeichert:

• Administrator und Redakteur: Beides bleibt drin.
• Autor und Mitarbeiter: Beides verschwindet beim Speichern, ohne jede Meldung.

Das ist Absicht und schützt Ihre Website. Wenn Ihr Code also nicht erhalten bleibt, prüfen Sie zuerst die Rolle Ihres Benutzers (die Rollen in WordPress im Überblick). Wenn in der wp-config.php die Zeile define( 'DISALLOW_UNFILTERED_HTML', true ); steht, hat im Test auch der Administrator keine Skripte mehr speichern können.

Dieser Weg eignet sich für kleine Dinge. Längere Skripte sind besser in einer eigenen Datei aufgehoben, die Sie einbinden. So lade ich die Beispiele in der Website-Werkstatt: Jedes liegt in einem eigenen Ordner und läuft in einem iframe auf der Seite, und bis ein Besucher in seine Nähe scrollt, lädt der Beitrag davon nichts.

Warum eigener Code nicht in die functions.php des Themes gehört

Viele Anleitungen sagen: „Fügen Sie das in die functions.php ein.“ Bei einem fertig installierten Theme hält das bis zum nächsten Update. Ich habe eine Zeile an die functions.php eines Standard-Themes angehängt und das Theme dann über WordPress aktualisiert: Die Zeile war danach weg, ohne Rückfrage und ohne Hinweis.

Die Lösung ist ein Child-Theme, ein kleines Theme, das auf Ihrem bisherigen aufbaut und nur zwei Dateien braucht: eine style.css mit dem Namen des Eltern-Themes und Ihre eigene functions.php. Im selben Test hat das Eltern-Theme das Update bekommen, die Datei des Child-Themes ist unverändert geblieben, und der Code ist weitergelaufen.

Zwei Grenzen sollten Sie kennen:

• Ein Child-Theme hängt am Theme. Wenn Sie das Theme wechseln, läuft sein Code nicht mehr, auch wenn der Ordner noch da ist. Das ist bei Code richtig, der zum Aussehen gehört, und falsch bei allem anderen, etwa einem Formular oder einer Statistik.
• Ein Tippfehler trifft die ganze Website. Was dann zu tun ist, beschreibe ich in meinem Artikel „Auf dieser Website ist ein kritischer Fehler aufgetreten“.

WordPress-Code ohne FTP einfügen: das Snippet-Plugin

Ein Snippet-Plugin speichert Code in der Datenbank und führt ihn aus, als stünde er in der functions.php. Sie brauchen keinen FTP-Zugang, und der Code überlebt Theme-Updates und Theme-Wechsel. Die zwei bekanntesten sind Code Snippets und WPCode, beide aktuell gepflegt und für WordPress 7.1.4 ausgewiesen, mit laut wordpress.org mehr als einer und mehr als drei Millionen aktiven Installationen.

Code Snippets 4.1.0 habe ich absichtlich mit fehlerhaftem Code gefüttert, und zwar über die Funktionen des Plugins, nicht über seine Oberfläche. Das Ergebnis ist interessant:

• Ein Tippfehler oder eine unbekannte Funktion, die sofort beim Laden läuft: Die Website ist normal weitergelaufen. Das Plugin fängt diese Fehler ab.
• Derselbe Fehler in Code, der erst später läuft, in meinem Test beim Ausgeben der Fußzeile: Die Seite hat an dieser Stelle einfach aufgehört, ohne Fehlermeldung und ohne Fußzeile, mit Status 200. Die Anmeldeseite ist erreichbar geblieben.

Der zweite Fall ist tückisch, denn ein Monitor, der nur den Status prüft, sieht nichts. Die Abhilfe steht in der Dokumentation des Plugins: Mit define( 'CODE_SNIPPETS_SAFE_MODE', true ); in der wp-config.php führt es keinen Code mehr aus, und im Test war die Seite sofort wieder vollständig. Dann können Sie das Snippet korrigieren und die Zeile wieder entfernen.

WPCode habe ich nicht getestet. Für beide gilt: Wer im Dashboard Administrator ist, kann damit beliebigen Code ausführen. Das ist kein Argument gegen sie, aber ein weiterer Grund, Administrator-Konten sparsam zu vergeben.

Das eigene WordPress-Plugin: ohne Theme, mit einer einzigen Datei

Ein Plugin klingt groß, ist aber im einfachsten Fall eine PHP-Datei mit einem Kommentar am Anfang:

<?php
/*
Plugin Name: Mein Betrieb – eigene Funktionen
*/

Diese Datei legen Sie in einen Ordner unter wp-content/plugins, aktivieren sie wie jedes andere Plugin, und Ihr Code folgt darunter. Er ist vom Theme unabhängig, und Sie können ihn mit einem Klick abschalten. Was ein Plugin überhaupt ist, erkläre ich in meinem Artikel WordPress-Plugins, einfach erklärt.

Für Elemente, die Sie an mehreren Stellen brauchen, gibt das Plugin Ihnen einen eigenen Shortcode. So bleibt der Code an einem Ort, und auf der Seite steht nur noch eine kurze Zeile in eckigen Klammern. Genau so bette ich die Beispiele in der Website-Werkstatt ein.

Must-Use-Plugins in WordPress: Code, der immer läuft

Eine PHP-Datei direkt im Ordner wp-content/mu-plugins läuft ohne Aktivierung und lässt sich im Dashboard nicht abschalten. Im Test ist sie auch nach einem Theme-Wechsel weitergelaufen. Unter den Plugins erscheint sie nur in einer eigenen Ansicht „Must-Use“. Den Ordner müssen Sie anlegen, falls es ihn noch nicht gibt.

Das ist praktisch für alles, was nie ausfallen darf, und gefährlich aus demselben Grund. Ein Fehler in einem Must-Use-Plugin hat im Test die ganze Website lahmgelegt, Anmeldeseite eingeschlossen, jeweils mit Status 500. Das Dashboard hilft Ihnen dann nicht mehr. Erst das Umbenennen der Datei per FTP oder Dateimanager hat die Website sofort zurückgebracht. Für den Anfang ist ein normales Plugin deshalb die bessere Wahl.

Bevor eigener Code auf die WordPress-Website kommt

Drei Gewohnheiten ersparen den größten Teil des Ärgers:

• Eine Änderung nach der anderen, und danach die Website im privaten Browserfenster öffnen. Ganz nach unten scrollen: Der abgeschnittene Fall von oben fällt sonst nicht auf.
• Kein fremdes Skript ungeprüft. Wenn Ihr Code etwas von einem anderen Server lädt, erfährt dieser Server die Adresse Ihrer Besucher. Das hat Folgen für Ihre Datenschutzerklärung und oft für den Cookie-Banner (was Ihre Website rechtlich braucht). Dateien auf dem eigenen Server ersparen Ihnen diese Frage.
• Den Code außerhalb der Website aufheben. Eine Kopie in einer Textdatei rettet Sie, wenn ein Snippet verloren geht oder Sie einen Fehler zurücknehmen müssen.

Konkrete Beispiele für eigenen Code finden Sie in der Website-Werkstatt: Rechner, Effekte und Visualisierungen zum Ausprobieren, jeweils mit dem, was sie an Ladezeit kosten.