WordPress und die PHP-Version

Auf WP Tavern wurde kürzlich ein Artikel zur neuen Initiative des WordPress Core PHP-Teams veröffentlicht, die sich zum Ziel gesetzt hat, die Nutzerzahlen von WordPress auf unterstützten PHP-Versionen zu erhöhen. Damit hat die Bewegung nun erstmals außerhalb von make.wordpress.org/core/ einen Artikel gewidmet bekommen – Grund genug, all das also mal etwas genauer anzusehen.

[lightgrey_box]Vor dem eigentlichen Artikel eine kurze Einleitung zu mir, denn ich bin nicht Hans-Helge: Mein Name ist Felix Arntz, ich entwickle Plugins für WordPress und bin seit knapp einem Jahr Core Committer. Ich bin mitverantwortlich dafür, dass das neue PHP-Team ins Leben gerufen wurde und möchte hier ein bisschen genauer erklären, worum es uns eigentlich geht.[/lightgrey_box]

Wie alles begann

Am besten fangen wir ganz vorne an: Es begann mit einer Unterhaltung am WordCamp Europe in Paris dieses Jahr, an der Alain Schlesser, Boone Gorges, Jonny Harris und ich beteiligt waren. Es ging darum, dass wir im WordPress Multisite-Team (was für Jonny und mich die Hauptbeschäftigung unseres Core-Daseins darstellt) immer wieder an Punkte kommen, wo wir neue PHP-Funktionen hinzufügen wollen, die in anderen Core-Bereichen bereits äquivalente Gegenstücke besitzen. Wenn diese aber grundlegende Probleme in ihrem Verhalten haben, ist es unklar, wie damit umgegangen werden soll: Fügen wir die neue Funktion einfach nach unseren besseren Ideen ein und ignorieren das Problem der daraus resultierenden Inkonsistenz zu den existierenden Funktionen? Oder ist Konsistenz doch wichtiger und wir nehmen dafür weiterhin schlechteren Code in Kauf? Während dieses Gesprächs kam vor allem zur Sprache, dass es im Core zwischen den unterschiedlichen Komponenten viel zu wenig übergreifenden Dialog gibt. Innerhalb finden zwar (teils) wöchentliche Diskussionen statt, aber ansonsten macht jede Komponente weitgehend ihr Ding (mit Ausnahme größerer Projekte, die im wöchentlichen „dev-chat“ besprochen werden). Resultat des Gesprächs war, dass wir einen Ort brauchen, wo wir über generelle Patterns in WordPress sprechen können, die den gesamten Core betreffen.

Gesagt, getan, kurze Zeit nach dem WordCamp hatte ich einen Chat mit Gary Pendergast, in dem ich ihm unsere Idee mitteilte. Da es seit kurzem einen #core-js Channel bei Slack gab zur weiteren Planung zur Nutzung von JavaScript im Core, wäre es doch ganz lustig, einen #core-php Channel als Gegenstück zu haben. Am nächsten Morgen war der Channel da und ein paar Leute hatten sich schon über Gott und die Welt ausgelassen. Was auch verständlich war, denn es war ja bisher kein Rahmen vorgegeben. Es schien offensichtlich, dass schnell das Thema eines vollständigen Rewrites der WordPress-Codebase aufkommen würde. Und so lang hat es auch gar nicht gedauert:

Well, we had a good run. 6 hours, 19 minutes before rewriting the entire codebase came up.
Gary Pendergast

So ein Rewrite ist aber ein unrealistisches Unterfangen für den Core. WordPress ist Open Source und steht für Forks offen, das Projekt selbst sollte sich lieber damit beschäftigen, wie man sukzessive in die richtige Richtung arbeitet. Selbst wenn es einmal zu einem größeren Refactoring kommen sollte, müssten die existierenden Strukturen erst einmal erhalten bleiben und die moderne Variante durch Wrapper und Abstraktionsschichten damit verbunden werden.

Die neue Initiative des Core PHP-Teams

Was hat denn das alles mit der PHP-Version zu tun? Einen Moment noch, wir sind fast da. Kurze Zeit nach Eröffnung des Channels wurden dann erste wöchentliche Meetings angekündigt, wobei zuerst einmal diskutiert werden sollte, woran überhaupt gearbeitet werden soll. Während die WordPress-Codebase selbst im Hinblick auf PHP 5.2 nicht gerade hervorragend ist, war der allgemeine Konsens beim ersten Treffen, dass es deutlich sinnvoller wäre, für solche Verbesserungen auf moderneren PHP-Code zu setzen. Vor allem die bei PHP 5.2 fehlende Unterstützung von Namespaces und später statischer Bindung wurden als Faktoren angebracht, die für bessere Patterns im Core unabdingbar wären. Und so kam man dann zur allgegenwärtigen Frage nach der PHP-Version, die WordPress minimal erfordert – praktisch der Running Gag, der auf jeder Q&A auf WordCamps in der ganzen Welt für Unklarheit sorgt. Wann erhöht WordPress seine Minimalanforderung? Scheinbar will es jeder, aber es gibt durchaus Bedenken, zu denen ich gleich kommen werde. Wie auch immer, damit wir uns überhaupt unseren ursprünglichen Zielen zuwenden könnten, mussten wir uns also erstmal das Ziel setzen, in Richtung PHP-Versionsanforderung zu arbeiten.

Der Grund, warum WordPress nicht die minimal erforderliche PHP-Version erhöht, ist weitgehend bekannt: Es gibt noch zu viele Nutzer, die auf der aktuellen Minimalversion PHP 5.2 sind, und diese würde man zurücklassen (aktuell sind es 4,3%). Der prozentuale Wert erscheint natürlich niedrig, aber bei der Popularität von WordPress sind das immer noch Millionen Websites. Die Diskussionen, ob das nun richtig oder falsch ist, wollten wir aber nicht wieder aufrollen, denn das hat auch bisher nichts genützt. Und auch hier möchte ich mich nicht damit beschäftigen. Außer soviel zu sagen, dass es aus Sicht des Massenprodukts WordPress meiner Meinung nach eine verständliche Einstellung ist. Klar wäre mir trotzdem lieber, wenn WordPress PHP 5.6 oder sogar 7 erfordern würde. Aber ich bin nicht der durchschnittliche WordPress-Nutzer, genauso wenig wie du, der/die diesen Artikel liest. Gewöhnliche WordPress-Nutzer und Nutzerinnen haben das Wort PHP vielleicht noch nie gehört. Außer einmal am Anfang, wenn sie sich durch den Stress mit FTP, MySQL, wp-config.php etc gequält haben, wobei auch die Anzahl dieser Fälle durch von Hostern angebotene One-Click Installationen immer geringer wird.

Das Ziel, was wir also seither verfolgen, ist es, die Anzahl von WordPress-Nutzern und Nutzerinnen, welche (wahrscheinlich unbewusst) nicht mehr unterstützte PHP-Versionen verwenden, zu reduzieren. Es geht hier auch gar nicht um PHP 5.2 speziell, sondern um alle veralteten Versionen (bis PHP 5.5). Unserer Meinung nach sollte ein Projekt der Dimension WordPress in der Verantwortung stehen, für ein sicheres Web zu sorgen. Würde man einfach die erforderliche Version erhöhen, würde eine große Menge der Anwenderschaft zurückbleiben bzw. sogar noch weiter zurückfallen, weil dann nicht mal mehr WordPress-Sicherheitsaktualisierungen kommen würden. Es schien uns also logischer, es auf dem weniger brachialen, sozialeren Weg zu versuchen, Administratoren und Administratorinnen über die Probleme aufzuklären, die aus Verwendung veralteter PHP-Versionen resultieren können, und, noch wichtiger, die Vorteile aufzuzeigen, die die Nutzung einer aktuellen Version mit sich bringt. Ein weiterer Grund für diese Entscheidung war, dass es schon Bestrebungen gab, die PHP-Version zu pushen, kurz bevor das neue Core PHP-Team über die PHP-Versions-Thematik diskutierte: Joost de Valk hatte schon vorher sowohl ein Ticket zur offiziellen Unterstützung einer minimal erforderlichen PHP-Version für Plugins (welche ihr übrigens ab sofort angeben könnt) geöffnet als auch eines, welches eine generelle Benachrichtigung im Admin-Bereich einfügen will, die Nutzern und Nutzerinnen gezeigt werden soll, welche eine veraltete PHP-Version einsetzen. Vor allem die pluginbezogene Geschichte befindet sich in stetiger Bewegung, und in naher Zukunft wird wahrscheinlich auch der Core darauf hinweisen, wenn man ein Plugin installieren oder aktualisieren möchte, welches eine zu hohe PHP-Version erfordert, und diese Änderung verhindern. Das führt uns nun endlich zu unserem Hauptprojekt des neuen Core PHP-Teams, über das auch WP Tavern berichtet hat: Denn wenn man im Admin-Bereich auf Probleme mit PHP hingewiesen wird, hilft das in der Regel nicht, sondern frustriert nur.

Unser Plan ist es also, eine Seite im Web zu erstellen, auf die Leute verwiesen werden können, wenn sie auf ein solches Problem stoßen. Aber auch allgemein sollte die Seite einen Mehrwert bieten, in dem sie über PHP-Versionen und die Vorteile der Verwendung einer aktuellen Version aufzeigt. Als temporären „Codenamen“ für dieses Vorhaben haben wir uns für „Serve Happy“ entschieden, äquivalent zur existierenden Browse Happy-Initiative.

Das primäre Ziel der Seite soll sein, nicht- oder wenig-technische Nutzer und Nutzerinnen davon zu überzeugen, die (mehr oder weniger großen) Strapazen auf sich zu nehmen, um die PHP-Version zu aktualisieren. Wir planen, eng mit dem Marketing Team von WordPress zusammenzuarbeiten, denn im Prinzip soll die Seite genau dies tun, das Upgrade einer PHP-Version an oben genannte Gruppe vermarkten. Wir legen das Augenmerk also auf kurze präzise Angaben sowie Vermeidung technischen Jargons und zu vieler Details. Natürlich muss minimal erklärt werden, was denn PHP überhaupt ist, wichtiger ist aber, aufzuzeigen, welche Vorteile sich durch das Upgrade bieten, wobei vor allem solche Vorteile betont werden sollen, die nicht ausschließlich mit der Entwicklung oder schwer nachzuvollziehenden technischen Gegebenheiten zu tun haben. Ein Auszug an Ideen, die wir in diese Richtung entwickelt haben:

• Eine moderne PHP-Version verbessert die Performance der Website (vor allem ab PHP 7+).
• Eine moderne PHP-Version verringert die Wahrscheinlichkeit, dass die Website durch Angreifer kompromittiert werden kann.
• Eine moderne PHP-Version gibt Zugriff auf mehr qualitativ hochwertige Plugins, da viele gute Plugins höhere PHP-Versionen erfordern. Im Umkehrschluss verringert sie die Wahrscheinlichkeit auf nicht mehr weiterentwickelte Plugins, da die häufig Probleme mit neuen PHP-Versionen verursachen.
• Eine moderne PHP-Version hält WordPress am Leben. Das klingt zugegebenermaßen etwas dick aufgebauscht, aber je weiter WordPress technisch zurückfällt, desto mehr Entwickler und Entwicklerinnen werden sich vom Projekt abwenden im Laufe der Zeit. Somit wird auch immer weniger Drittanbieter-Inhalt wie Plugins und Themes verfügbar sein.

Zusätzlich soll versucht werden, das Upgrade durch Einbindung oder Links zu passenden Tutorials so einfach wie möglich zu gestalten. So können Besucher und Besucherinnen, nachdem sie hoffentlich von der Umstellung überzeugt worden sind, sofort fortfahren. Hierzu wurde darüber nachgedacht, beispielsweise GET-Parameter zu unterstützen. So könnte WordPress Core versuchen, über die Serverinformationen den Hoster zu ermitteln und diesen per Parameter an den Link zur Webseite anhängen, sodass diese dann präzise Informationen liefern kann. Natürlich wird das nur für renommierte Hosts funktionieren, ganz abhängig davon, was für eine Datenbank wir da zusammenkriegen können. Aber selbst für den allgemeinen Fall sollte genügend Hilfestellung vorhanden sein, mindestens aber eine vorgefertigte Email, die Administratoren und Administratorinnen an ihren Hoster senden können.

Die Seite sollte in jedem Fall an offizieller Stelle zu finden sein, zum Beispiel als Unterseite von wordpress.org oder aber als eigene Website mit Kennzeichnung des Bezugs zum WordPress-Projekt. Ein solcher Ort für die Seite ist wichtig, damit sie bei Bedarf direkt aus dem WP-Admin-Bereich verlinkt werden kann. Ich möchte allerdings betonen, dass nichts von all dem in trockenen Tüchern ist. Wir haben bisher hauptsächlich positives Feedback bekommen und sind überzeugt davon, dass das Projekt erfolgreich sein wird. WP Tavern hat nur etwas verfrüht betont, dass die Seite auf wordpress.org zu finden sein wird – solche Details sind noch lange nicht klar. Wir sind zwar eine Core-Initiative und haben schon jetzt auch einige Unterstützung durch verschiedene Langzeit-Core-Entwickler erhalten, im Endeffekt wird es aber darum gehen, die gesamte Core Leadership von den Vorteilen der Bewegung zu überzeugen, vor allem, wenn wir an dem Punkt sind, die Seite an offizieller Stelle veröffentlichen zu können und in den Core einzubinden. Eine besonders positive Entwicklung in diesem Sinne gab es diese Woche aber auch schon: Während wir zuerst eine eigene GitHub-Organisation für das Core PHP-Team ins Leben gerufen hatten, sind nun beide zu der Initiative gehörenden Repositories auf Wunsch von Matt Mullenweg in die offizielle WordPress-Organisation auf GitHub umgezogen worden. Eine solche Bestätigung zu erhalten zeigt uns, dass wir hoffentlich auf dem richtigen Weg sind.

Nachwort

Was ich oben bewusst nicht weiter erwähnt habe, ist der PHP-Versionssprung von WordPress Core selbst. Denn der ist aktuell kein Thema unserer Bemühungen. Natürlich schielen wir alle in diese Richtung, aber momentan möchten wir einfach nur die Nutzerzahlen auf unterstützten PHP-Versionen erhöhen. Wir haben keinen „fixen Breakpoint“, wann WordPress die Minimalanforderung erhöht. Aber das brauchen wir für die „Serve Happy“-Seite und die Messung deren Erfolgs auch nicht, denn dieser wird nur durch die Statistiken gemessen. Mal abgesehen davon gehen wir davon aus, dass WordPress zuerst bestimmt nur von PHP 5.2 auf PHP 5.3 als Mindestanforderung springen wird. Dies aber für die „Serve Happy“-Seite anzuwenden, wäre falsch, denn wir wollen das Web auf eine wirklich aktuelle PHP-Version bringen. Und entscheiden können wir über den Versionssprung ebenfalls nicht – wir können nur unser bestes tun, um das WordPress-Projekt in die richtige Richtung zu lenken, um eine mögliche Entscheidung zu gegebenem Punkt zu begünstigen.

Was ich ganz persönlich an all dem so interessant finde, ist, dass mir das PHP-Versions-Projekt vor Augen hält, wie kompliziert manche Sachverhalte doch sind. Eigentlich wollten wir uns „nur“ mit PHP-Patterns im WordPress Core beschäftigen. Jetzt werden wir aber wahrscheinlich noch die nächsten Wochen und Monate damit verbringen, eine Seite für nichttechnische Nutzer und Nutzerinnen auf die Beine zu stellen. Heißt also, wir werden nicht nur nicht programmieren, nein, wir werden nicht einmal über Programmierung reden! Das finde ich eine angenehme Abwechslung im Core-Dasein (obwohl ich es natürlich liebe zu programmieren). Dass es unser ursprüngliches Vorhaben weit zurückwirft, stößt mir gar nicht so übel auf, denn wenn wir dann zu gegebenem Zeitpunkt auf PHP 5.3+ Basis anfangen können, über Patterns zu diskutieren, ist schon mal eine deutlich bessere Grundlage gegeben. Außerdem bestätigt es wieder einmal: Nichts ist so leicht, wie es aussieht. Klar ist das eine abgedroschene Phrase und nervt eher, wenn man sie hört, aber für mich zeigt sie hier, dass daraus auch etwas anderes großes entstehen kann. Mit besseren PHP-Patterns hätten wir den typischen WordPress-Anwendern und Anwenderinnen nicht wirklich bzw. nur indirekt geholfen, jetzt aber unterstützen wir sie durch die geplante „Serve Happy“-Seite direkt.

Zu guter Letzt habe ich natürlich noch eine Bitte: Wir freuen uns über jeden Input und Hilfe bei der Gestaltung der Seite! Aktuell diskutieren wir (in Englisch) in GitHub-Issues im „servehappy“-Repository über die einzelnen Abschnitte der Seite und die aufzuzeigenden Vorteile, während zusätzlich im „servehappy-resources“-Repository Drittanbieter-Quellen gesammelt werden, beispielsweise Artikel zur Inspiration für unsere eigene Seite und umgebungsspezifische Tutorials für PHP-Versionsaktualisierungen. Das wöchentliche Meeting findet jeden Montag um 20:00 deutscher Zeit im #core-php Channel bei Slack statt und dauert etwa eine Stunde. Es wäre schön, wenn sich unser Team noch vergrößern würde.