Übersetzung, Performance & Debugging

Übersetzung, Performance und Debugging

Begriffe vorab

• i18n: Internationalisierung – Vorbereitung auf Übersetzung.
• Text Domain: Kennung, die Übersetzungen einem Plugin oder Theme zuordnet.
• Object Cache: Zwischenspeicher für Abfrageergebnisse im Arbeitsspeicher.
• Debug-Log: Datei, in der Fehler protokolliert werden.

Professionelle WordPress-Entwicklung berücksichtigt Mehrsprachigkeit, Geschwindigkeit und saubere Fehlersuche von Anfang an.

Internationalisierung (i18n)

• __( 'Text', 'textdomain' ) gibt die Übersetzung zurück.
• _e() gibt sie direkt aus.
• esc_html__() und esc_attr__() übersetzen und escapen in einem Schritt.
• _n( 'Ein Beitrag', '%d Beiträge', $anzahl, 'textdomain' ) behandelt Singular und Plural.

Die Text Domain muss ein fester String sein, keine Variable, und mit dem Slug des Plugins oder Themes übereinstimmen. Für JavaScript nutzt du wp_set_script_translations(). Bei Plugins und Themes aus dem WordPress.org-Verzeichnis werden Übersetzungen automatisch geladen.

Performance

• Skripte und Styles nur dort laden, wo sie gebraucht werden, mit Bedingungen wie is_singular( 'book' ).
• Teure Ergebnisse mit Transients zwischenspeichern:

$daten = get_transient( 'meinpraefix_api_daten' );
if ( false === $daten ) {
	$daten = meinpraefix_teure_abfrage();
	set_transient( 'meinpraefix_api_daten', $daten, HOUR_IN_SECONDS );
}

• Mit einem persistenten Object Cache (etwa Redis) werden Transients und wp_cache_get() deutlich schneller.
• Keine Datenbankabfragen innerhalb von Schleifen, stattdessen Daten gebündelt laden.
• Bilder in passender Größe ausliefern, WordPress erzeugt dafür mehrere Bildgrößen und srcset.

Debugging

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Diese Konstanten in wp-config.php schreiben Fehler nach wp-content/debug.log, ohne sie Besuchern anzuzeigen. Nützliche Werkzeuge sind das Plugin Query Monitor, SCRIPT_DEBUG für unminifizierte Core-Skripte und WP-CLI für Automatisierung.

Coding Standards

Die WordPress Coding Standards (WPCS) definieren Einrückung mit Tabs, Yoda-Bedingungen und Namensregeln. Mit PHP_CodeSniffer lassen sie sich automatisch prüfen.

Lasse WP_DEBUG_DISPLAY auf Live-Seiten niemals aktiv. Fehlermeldungen können Pfade und sensible Informationen preisgeben.

Ein Beispiel: langsame Seite analysieren

Eine Seite lädt träge. Mit einem Werkzeug wie Query Monitor siehst du, welche Datenbankabfragen und Hooks lange dauern. Häufig findet man eine Abfrage innerhalb einer Schleife, die hundertfach wiederholt wird. Sie einmalig zu bündeln, kann mehr bringen als jede Serveroptimierung.

Reihenfolge der Maßnahmen

1. Messen, bevor man optimiert.
2. Teure Abfragen bündeln oder zwischenspeichern.
3. Assets nur dort laden, wo sie gebraucht werden.
4. Bilder passend skalieren und Caching nutzen.

Debugging ohne Risiko

Fehler werden in die Logdatei geschrieben, aber nicht im Frontend angezeigt. Auf Live-Seiten die Anzeige abschalten, weil Fehlermeldungen Pfade und interne Details verraten können.

Zum Selbermachen: eine Seite messen

1. Installiere Query Monitor in einer Testumgebung.
2. Rufe eine Seite auf und notiere die Anzahl und Dauer der Datenbankabfragen.
3. Suche die langsamste Abfrage und finde heraus, welcher Code sie auslöst.
4. Beseitige eine Ursache und miss erneut.

Prüfstatus: Belegt (Stand 1. Oktober 2026): Jahreszahlen, Zahlen, Namen und Quellenangaben dieser Lektion, soweit die Quellenliste sie nennt, wurden gegen Primärquellen geprüft. Nicht einzeln belegt: erklärende Darstellung nach Lehrbuchstand und Quellen, die in der Liste als „allgemeine Referenz“ markiert sind. Codebeispiele sind nur auf Syntax geprüft, nicht in WordPress ausgeführt.

Quellen

• WordPress Developer Resources – „Internationalization“ (developer.wordpress.org/apis/internationalization/) (allgemeine Referenz, nicht Zeile für Zeile geprüft)
• WordPress Developer Resources – „Debugging in WordPress“ (WP_DEBUG, WP_DEBUG_LOG, WP_DEBUG_DISPLAY) (allgemeine Referenz, nicht Zeile für Zeile geprüft)