WordPress-Glossar

Ein Schatten-Admin ist ein Benutzerkonto mit Administratorrechten, das in der WordPress-Benutzerliste nicht auftaucht. Angreifer erzeugen es nach einer Kompromittierung, um auch nach dem Passwortwechsel weiter Zugriff zu haben.

Versteckt wird es meist über einen Filter auf pre_user_query oder einen direkten Eintrag in wp_usermeta. Wer nur die Oberfläche prüft, sieht nichts. Sichtbar wird das Konto erst beim direkten Blick in die Datenbank oder über einen Scan.

Ein IOC ist eine konkrete, prüfbare Spur, die auf eine Kompromittierung hindeutet: eine Datei, ein Dateiname, ein Hash, ein Datenbankeintrag, ein ausgehender Verbindungsversuch.

Der Unterschied zum Bauchgefühl ist die Prüfbarkeit. „Die Seite ist langsam“ ist kein IOC. Eine wp-includes/-Datei mit Änderungsdatum von letzter Woche und base64-kodiertem Inhalt schon.

Nulled Plugins sind kostenpflichtige Plugins oder Themes, bei denen die Lizenzprüfung entfernt wurde und die kostenlos weiterverbreitet werden.

Der Preis ist kein Geld, sondern Kontrolle: In der Regel wurde beim Entfernen der Lizenzprüfung gleich noch Code ergänzt. Dazu kommt der strukturelle Schaden, dass es keine Sicherheitsupdates gibt.

Hardening bezeichnet alle Maßnahmen, die die Angriffsfläche einer WordPress-Installation verkleinern, bevor etwas passiert – im Gegensatz zu Malware-Scannern, die erst danach greifen.

Die wirksamen Maßnahmen sind unspektakulär: aktuelle Versionen, wenige Plugins, korrekte Dateiberechtigungen, deaktivierter Dateieditor, Zwei-Faktor für Redaktionskonten, abgeschaltetes XML-RPC. Ein Security-Plugin ersetzt keinen dieser Punkte.

XML-RPC ist die alte Fernzugriffs-Schnittstelle von WordPress unter /xmlrpc.php, seit der REST API praktisch überflüssig.

Relevant ist sie heute vor allem als Angriffsfläche: Über system.multicall lassen sich hunderte Login-Versuche in einer einzigen Anfrage bündeln, was klassische Login-Limits umgeht. Wer keine Jetpack-Altlast und keine externe App im Einsatz hat, blockiert die Datei auf Serverebene.

Salts und Keys sind acht Zufallszeichenketten in der wp-config.php, mit denen WordPress Login-Cookies und Sessions signiert.

Neu erzeugen (über den offiziellen Salt-Generator) macht alle bestehenden Sessions ungültig und wirft jeden angemeldeten Benutzer hinaus – gewollt, denn genau das ist der erste Schritt nach jedem Sicherheitsvorfall, noch vor dem Passwortwechsel.

Dateien gehören auf 644, Ordner auf 755, die wp-config.php auf 640 oder 600. Das ist der Normalzustand, nicht die Härtung.

777 ist nie eine Lösung, sondern immer ein Symptom: Wenn eine Datei Schreibrechte für alle braucht, läuft der Webserver unter dem falschen Benutzer. Das gehört beim Hoster geklärt, nicht per chmod übertüncht.

Die Core Web Vitals sind drei von Google definierte Messwerte für Ladeerlebnis, visuelle Stabilität und Reaktionsfähigkeit einer Seite: LCP, CLS und INP.

Gewertet werden Felddaten echter Besucher aus dem Chrome-Nutzererfahrungsbericht, nicht der Lighthouse-Wert aus dem eigenen Browser. Deshalb kann eine Seite mit Score 98 im Labortest im Feld durchfallen.

LCP (Largest Contentful Paint) misst, wann das größte sichtbare Element geladen ist. Richtwert: unter 2,5 Sekunden.

CLS (Cumulative Layout Shift) misst, wie stark das Layout während des Ladens springt. Richtwert: unter 0,1. Typische Ursache sind Bilder ohne Breiten- und Höhenangabe.

INP (Interaction to Next Paint) misst, wie lange die Seite auf eine Eingabe braucht. Richtwert: unter 200 Millisekunden. INP hat 2024 den alten Wert FID abgelöst und ist bei WordPress fast immer ein JavaScript-Problem.

TTFB ist die Zeit zwischen Anfrage und erstem empfangenen Byte der Antwort. Der Wert beschreibt den Server, nicht das Design.

Bei WordPress liegen die Ursachen fast immer in PHP-Laufzeit, Datenbankabfragen oder Hosting – nicht im Theme. Richtwert: unter 600 Millisekunden, mit funktionierendem Page-Cache unter 200. Wer bei schlechtem TTFB Bilder optimiert, behandelt das falsche Problem.

Als Page-Builder-Overhead bezeichnet man das zusätzliche HTML, CSS und JavaScript, das ein visueller Editor wie Elementor, WPBakery oder Divi in jede Seite schreibt.

Der Aufwand entsteht nicht durch die Inhalte, sondern durch die verschachtelte Container-Struktur und die global geladenen Assets. Das ist messbar und teilweise beherrschbar, aber es verschwindet nicht durch ein Caching-Plugin.

WooCommerce-Performance ist ein anderes Problem als WordPress-Performance, weil Warenkorb, Kasse und Konto grundsätzlich nicht cachebar sind und jede Anfrage voll durch PHP und Datenbank läuft.

Die Hebel liegen deshalb woanders: Object Cache, aufgeräumte Produktattribute, weniger Varianten pro Produkt, HPOS statt Postmeta, kontrollierte AJAX-Aufrufe im Warenkorb.

Autoloaded Options sind Einträge in der Tabelle wp_options mit autoload = yes. Sie werden bei jedem einzelnen Seitenaufruf komplett in den Speicher geladen, ob sie gebraucht werden oder nicht.

Deinstallierte Plugins lassen dort regelmäßig Datenreste zurück. Richtwert für die Gesamtgröße: unter 800 KB. Messen mit SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload = 'yes';

Ein Transient ist ein zwischengespeicherter Wert mit Ablaufdatum. Der Object Cache ist der Ort, an dem er liegt.

Ohne persistenten Object Cache landen Transients in der Datenbank – der Cache erzeugt dann genau die Abfragen, die er sparen soll. Erst mit Redis oder Memcached im Arbeitsspeicher wird daraus eine Beschleunigung. Das ist der Grund, warum dieselbe Optimierung auf zwei Hostings gegenteilige Ergebnisse liefert.

WP-Cron ist der eingebaute Zeitplaner von WordPress – und kein echter Cron-Job. Geplante Aufgaben laufen nicht zur eingestellten Zeit, sondern beim nächsten Seitenaufruf danach.

Daraus folgen beide Fehlerbilder: Auf Seiten ohne Traffic laufen Backups und Updates gar nicht, auf Seiten mit viel Traffic wird bei jedem Aufruf geprüft. Sauber ist define('DISABLE_WP_CRON', true); plus ein echter Server-Cron alle fünf Minuten auf wp-cron.php.

Bei Headless WordPress dient WordPress nur noch als Redaktionssystem und Datenquelle. Die Ausgabe im Browser übernimmt ein eigenes Frontend, das die Inhalte über die REST API oder GraphQL abruft.

Gewonnen wird Geschwindigkeit und Unabhängigkeit vom Theme-Ökosystem. Bezahlt wird mit Vorschau, Formularen, Plugin-Kompatibilität und laufender Wartung an zwei Stellen statt einer.

Ein Plugin-Friedhof ist eine WordPress-Installation, in der über Jahre Plugins für Einzelprobleme installiert und nie wieder entfernt wurden – inklusive der deaktivierten, die trotzdem noch Datenbankeinträge und Dateien hinterlassen.

Die Folgen sind kumulativ: mehr Angriffsfläche, mehr Autoloaded Options, längere Ladezeit, und irgendwann traut sich niemand mehr, etwas zu deaktivieren.

Hooks sind die Stellen, an denen sich WordPress erweitern lässt, ohne Core-Dateien zu ändern. Es gibt zwei Sorten.

Eine Action führt an einem bestimmten Punkt Code aus und gibt nichts zurück. Ein Filter bekommt einen Wert, verändert ihn und muss ihn zurückgeben. Merksatz: Action macht etwas, Filter gibt etwas zurück. Ein vergessenes return im Filter ist die häufigste Ursache für plötzlich leere Inhalte.

Ein Child Theme erbt alle Templates und Funktionen eines anderen Themes und überschreibt nur einzelne davon. Zweck ist Updatesicherheit: Das Eltern-Theme kann aktualisiert werden, ohne eigene Anpassungen zu überschreiben.

Nötig ist es nur bei Änderungen an Templates oder functions.php. Für reines CSS reicht heute der Customizer oder ein kleines eigenes Plugin – ein Child Theme für drei Zeilen CSS ist überflüssige Wartung.

Ein Custom Post Type ist ein eigener Inhaltstyp neben Beitrag und Seite, angelegt über register_post_type() – etwa Referenzen, Termine oder Rezepte.

Wichtigste Praxisregel: im Plugin registrieren, nicht in der functions.php des Themes. Sonst sind bei einem Theme-Wechsel alle Inhalte aus dem Backend verschwunden, obwohl sie noch in der Datenbank stehen.

Die WordPress REST API liefert Inhalte unter /wp-json/ als JSON aus. Sie ist die Grundlage für den Block-Editor, für Apps und für Headless-Setups.

Ein Detail mit Sicherheitsbezug: /wp-json/wp/v2/users gibt standardmäßig Benutzernamen aus – die halbe Arbeit für einen Brute-Force-Angriff. Die Schnittstelle pauschal zu deaktivieren ist trotzdem falsch, weil das Backend sie braucht. Gezielt einschränken statt abschalten.

Staging ist eine Kopie der Website zum Testen, Deployment der kontrollierte Weg von Änderungen nach Live.

Der Knackpunkt bei WordPress ist, dass Code und Inhalte in entgegengesetzte Richtungen wandern: Templates und Plugins von Staging nach Live, Beiträge und Bestellungen von Live nach Staging. Wer die Datenbank pauschal in eine Richtung kopiert, verliert genau die Daten, die währenddessen entstanden sind.

Eine Multisite ist ein Netzwerk mehrerer Websites auf einer WordPress-Installation mit gemeinsamer Codebasis und geteilter Benutzertabelle.

Sinnvoll bei gleichem Betreiber und gleichem Stack, etwa Sprachversionen oder Standortseiten. Riskant bei getrennten Kundenprojekten: Ein fehlerhaftes Update trifft alle Seiten gleichzeitig, und einzelne Seiten sauber herauszulösen ist deutlich aufwendiger, als sie getrennt zu betreiben.