Die Datenreisenden – Neues aus dem Web

Objektorientierte Programmierung ist auch mit WordPress-Themes möglich, allerdings gibt es eine Reihe Stolperfallen und Unterschiede zur normalen OOP mit Plugins zu beachten. Bei mehreren meiner Kunden sind inzwischen rein objektorientiert programmierte Themes im Einsatz. Natürlich greift man hierbei i.d.R. noch auf gängige WP-eigene Funktionen zurück, versucht aber, das Theme möglichst als Helferklasse anzulegen.

Problem: Nicht-globale Objekte

Da WordPress offenbar bei jedem eingebundenen Template die jeweilige Umgebung neu initialisiert (teils auch weil diese per Funktionsaufruf eingebunden werden und somit externe Variablen nicht mit übernommen werden), muß man wohl oder übel entweder auf Superglobals oder das global-Schlüsselwort zurückgreifen, um das Theme-Objekt überall nutzen zu können.

Problem: Theme-Installation / -deinstallation

Für WordPress-Themes existieren nicht dieselben ausgefeilten install- und deinstall-Action Hooks wie für Plugins, daher führe ich hier folgend auf, was stattdessen zu benutzen ist.

Hinweis: Die Initialisierung stellt dagegen keine Hürde dar. Hier läuft alles wie von der Pluginprogrammierung her gewohnt ab

Action Hook: Theme-Installation

Da es für Themes keine (direkte) Aktivierungs-Funktion a la register_activation_hook gibt, nutze ich in meiner Theme-Klasse folgendes Codeschnipsel in der Constructor-Methode:

/**
 * Workaround for missing theme register_activation_hook
 */
if ( is_admin() && isset($_GET['activated'] ) && $pagenow == "themes.php" ) {
	$this->MyTheme_install_hook();
}

Es wird also abgefragt, ob der Benutzer Adminrechte besitzt, das Theme gerade aktiviert werden soll UND wir uns auf der Theme-Auswahl-Seite befinden. Falls ja, wird die von mir angelegte Theme-Installations-Methode MyTheme_install_hook aufgerufen. Eine einfachere Möglichkeit hierfür ist mir leider nicht bekannt.

Action Hook: Theme-Deinstallation

/**
 * Workaround for missing theme register_deactivation_hook
 */

add_action('switch_theme', array(&$this, 'CtrlTheme_uninstall_hook'));

Wird das Theme gewechselt, wird logischerweise ein ANDERES als das aktuelle aufgerufen und somit können wir nun unsere Deinstallations-Routine ablaufen lassen.

Stolperfalle: Eigene CSS-Definitionen und Javascripts für Theme-Einstellungen

Meiner Erfahrung nach werden entgegen den im WordPress-Codex aufgestellten Behauptungen bestimmte Action Hooks im Admin-Bereich NICHT (bzw. nicht rechtzeitig) ausgeführt, vor allen Dingen, was seperate Scripts und CSS-Dateien anbelangt. Daher habe ich mich darauf verlegt, CSS- und JS-Aufrufe am Ende der jeweiligen Settings Page einzufügen. Das funktioniert bis dato sehr gut, während der “normale” Aufruf über Action Hooks manchmal sehr verwirrend sein kann. Beispielsweise werden die genutzten Hooks entweder gar nicht oder zu spät initialisiert, wodurch die Darstellung gerne mal “hüpft”. Im schlimmsten Fall darf man sogar den !important-Override-Parameter einsetzen, da sich das CSS-Weighting bei dynamisch eingefügten Inhalten extrem unzuverlässig verhält.

Soweit zu den mir bekannten größeren Problemfällen.
Fragen? Verbesserungsvorschläge? Dann immer her damit