Effiziente Theme und Plugin Entwicklung und der digitale Fußabdruck

Plugin und Theme Autoren hinterlassen Fussabdruecke

Auch in (Web)APPs und Content Management System wie WordPress gibt es so etwas wie einen ökologischen Fußabdruck. Nur ist dieser eben digital und betrifft den globalen Namensraum und den Speicherverbrauch pro Request.

Das heißt, dass alles was einfach bei jedem Seitenaufruf mal eben so geladen und definiert wird entweder Auswirkungen auf den Speicherverbrauch hat, oder eine potentielle Fehlerquelle darstellt.

Was sind Potentielle Fehlerquellen

Ich bin mir sicher, dass der eine oder andere schon einmal folgende Fehlermeldung bekommen hat, wenn er ein Plugin oder Theme installiert hat:

                
PHP Notice/Warning/Error: 
function/Variable/Constant ____ already defined in /var/www/______.php on line XY

         

Das bedeutet dann einfach, dass eine Konstante verwendet wurde, die schon einmal woanders definiert wurde. Keine schöne Sache und als nicht programmierender User natürlich erstmal ein kleiner Schock „Das Plugin ist kaputt! Mein WordPress funktioniert nicht mehr!“. Noch schlimmer ist das natürlich, wenn der User dann auch kein Error reporting eingeschalten hat und einfach nur eine weiße Seite sieht.

Das definieren von Konstanten oder Variablen im globalen Namensraum ist ungefähr so, als würde man seine User in ein Minenfeld schicken und sagen „Wird schon nichts passieren!“.

Dasselbe gilt natürlich auch für Funktionen. Alles ohne „Prefix“ ist gefährlich für den User und seine Installation.

Was wirkt sich das auf die Performance aus

Performance und Plugins

Eine andere Fehlermeldung, die man (vor allem bei shared hosting) auch immer wieder einmal sieht ist folgendes:



PHP Fatal error: 
Allowed memory size of __________ bytes exhausted

                      

Natürlich unschön. Vor allem, weil man dann erstmal wissen muss, wie man das Plugin (das über den internen Admin-UserInterface Installer geladen hat) wieder los wird. Sonst geht nämlich gar nichts mehr.

Jetzt muss man sich die Frage stellen: „Warum passiert das eigentlich?“. So einfach, wie die Frage ist, ist dann aber auch die Antwort: Weil alles überall geladen wird und dann im Speicher sitzt. Besonders fatal ist schleissige Programmierung vor allem, wenn Plugin Code unnötig im Administrations-UI auf dem Dashboard oder in den Pluginseiten aufgerufen wird. Dort ist der Speicherverbrauch nämlich schon von Haus aus hoch und außerdem wird der User nach dem Login in’s Dashboard weiter geleitet, bzw. der Admin-User nach der Installation/Aktivierung wieder auf einer Plugin(sub)seite landen.

So reduziere ich als Entwickler den digitalen Fußabdruck

Ein paar kleine Regeln für Variablen, Konstante und Funktionen:

  • Setze keine Variablen im globalen Namensraum.
  • Definiere Konstante nicht im globalen Namensraum.
  • Verwende einen Prefix für alle(!) Funktionen.

Solltest Du wirklich keinen Weg um die Definition einer globalen Konstanten oder das setzen einer globalen Variablen finden, dann verwende bitte wenigstens auch hierfür einen Prefix.

Wie reduziere ich als Entwickler den Speicherverbrauch meines Themes oder Plugins

nimm nur das mit was du brauchst

In einem Satz: Lade Dinge nur dann wenn Du sie brauchst.

Nun aber zum „wie“: WordPress hat sowohl für das Front-End (Theme) als auch für das Admin-Userinterface eine ganze Reihe an Helferlein parat.

Im Theme kann man ganz einfach „Conditional Tags“ nutzen. Also einfach zB innerhalb einer function abbrechen, wenn man mit seinem Plugin eigentlich nichts zu tun hat:


function texto_conditional_tags_example()
{
	if ( ! is_single() )
		return;

	echo 'Hallo! Ich bin nur auf Artikelseiten sichtbar!';
}
add_action( 'the_content', 'texto_conditional_tags_example' );

Man kann natürlich noch einen Schritt weiter gehen und den Check, ob man sich auf einer Artikelseite befindet um add_action() herum legen, damit das globale $wp_filters Array kleiner bleibt.

Im Admin-Userinterface gibt es solche Checks keine Conditional Tags. Hier muss man mit dem $current_screen Objekt arbeiten. Oder noch besser: Mit dem API Wrapper get_current_screen().

Ein nettes anderes Feature im Admin-UI sind kontextuelle Hooks. Das sind hooks, die nur auf bestimmten Seiten vorhanden sind, oder ihren Namen pro Seite ändern. Ein Beispiel ist der admin_head-{$hook_suffix} hook, der zum Beispiel folgendermaßen im Dashboard aussieht: admin_head-post-new.php. Das bedeutet, dass alles was daran gehookt wird, nur beim Neuerstellen von Artikeln geladen wird.

Wie mache ich mir als Entwickler das Leben leichter

Entwickler machen sich das Leben leichter

Natürlich ist es relativ mühsam sich all die Informationen was denn wo vorhanden ist und wogegen man Checks ausführen kann zu merken. Dann muss man suchen (z.B. auf queryposts.com), etliche var_dump( $foo );s hinlegen, Seiten neu laden, usw. Keine prickelnde Vorstellung. Im Core suchen, Dump hinzufügen, löschen, ändern, löschen, ändern (…).

Da ich als Plugin- und Themeentwickler auch permanent mit diesem Problem konfrontiert bin, habe ich mir eine Lösung überlegt, die mir mein Leben einfacher macht:

Ein Plugin zur Plugin-/Themeentwicklung, dass mir all diese Screenabhängigen Informationen im Admin-UI immer zur Verfügung stellt.

Derzeit umfasst es Admin-UI Seiten und lässt sich über den „Help/Hilfe“ Karteireiter rechts oben im Eck aufrufen und gibt Auskunft über kontextuelle Hooks, vorhandene Globalen und deren Inhalt, sowie über das current screen Objekt… mit nur zwei Mausklicks hat man alle Informationen parat.

Das Plugin ist als gratis Download auf GitHub verfügbar. Entwickler können das Plugin gerne „forken“ und mir Pull-Requests für Erweiterungen schicken. Wer es sich genauer ansieht, wird merken, dass das ganz einfach ist.

Eine wichtige Anmerkung noch zum Schluss:

das Plugin ist nicht für den Einsatz in einer Live-Installation gedacht, sondern für die lokale Entwicklung. Der Grund dafür ist simpel. Um die notwendigen Daten zu sammeln, läuft ein Teil des Plugins im all-Hook, was bedeutet, dass es während jedes Hooks aufgerufen wird. Das kann die Ladezeit einer Live-Installation unangenehm ausdehnen.

Ist das alles genug

Natürlich gibt es noch hunderte andere Dinge zu beachten, wenn man Plugins/Themes entwickelt. Das würde aber den Umfang eines Artikels bei weitem sprengen. Dieses Plugin ist lediglich der Anfang einer größeren Initiative an der ich derzeit arbeite. Mehr dazu in nächster Bälde vermutlich auch hier auf Texto.

Download

» Current Admin Info« Plugin Download

Fragen

Wenn Ihr detailierte Fragen habt, kontaktiert mich über das Kontaktformular meiner Homepage, oder addet mich auf Google+ und tretet so in Kontakt mit mir. Die Kommentare hier, werde ich natürlich auch verfolgen und Rede und Antwort stehen.

1

Ein Beitrag zu “Effiziente Theme und Plugin Entwicklung und der digitale Fußabdruck