Teilen Sie:
){kind=small}
Als ausgebildeter Schauspieler mit einer Dissertation in Standup-Comedy bin ich über die Meetup-Szene zur PHP-Entwicklung gekommen. Man findet mich, wenn ich über Technik spreche oder schreibe, oder wenn ich seltsame Platten aus meiner Vinylsammlung spiele oder kaufe.
PHP wird 31 und Vonage beobachtet die PHP-Szene
Lesedauer: 12 Minuten
Es ist schon bemerkenswert, dass PHP im Juni seinen 31. Geburtstag gefeiert hat. Von den Anfängen als einfache Skriptsprache, die einem einzelnen Entwickler helfen sollte, bis hin zu einem Open-Source-Giganten des Webs – das war eine ganz schöne Reise. Wenn Sie neugierig sind, wie der aktuelle Stand von PHP aussieht und wohin die Reise geht, erhalten Sie durch die Lektüre dieser Zusammenfassung einen guten Überblick.
In meiner täglichen Arbeit bin ich im Herzen immer noch PHP-Entwickler. Alles, was ich entwickle – von Demos bis hin zu Open-Source-Beiträgen – dreht sich um PHP-SDK von Vonage. Das ist ein zentraler Bestandteil unserer Arbeit; einzelne Programmiersprachen und ihre Communities sind wichtig, mit ihnen in Verbindung zu bleiben.
Im Anschluss an mein Interview mit dem Geschäftsführer der PHP Foundation kündigte JetBrains eine weitere Ausgabe von PHPVerse an, einer ausschließlich online stattfindenden eintägigen Konferenz für PHP-Entwickler. Wie schon im letzten Jahr bot die Veranstaltung auch dieses Jahr ein hochkarätiges Line-up aus bekannten Gesichtern der Open-Source-Szene, die zu verschiedenen Themen aus der Community referierten. In diesem Artikel werde ich die Hälfte der Vorträge mit Kommentaren durchgehen, um entweder Ihr PHP-Wissen auf den neuesten Stand zu bringen oder – falls Sie kein PHP-Entwickler sind – Ihnen einen Einblick zu geben, warum PHP nach wie vor so beliebt ist. Teil zwei folgt in Kürze.
Ich habe eingangs erwähnt, dass Vonage mit Elizabeth gesprochen hat, daher ist es wohl sinnvoll, mit diesem Vortrag zu beginnen. Seit ihrer Gründung ist es erfrischend, über eine Open-Source-Governance-Infrastruktur für PHP zu verfügen. Die Stiftung wurde in die Linux Foundation aufgenommen, erhielt erhebliche finanzielle Unterstützung von der deutschen Bundesregierung und verfügt nun über ein Team aus internen, voll bezahlten Entwicklern auf der ganzen Welt.
Im Mittelpunkt dieses Vortrags stand, in welche Richtung sie die Stiftung seit ihrer Gründung gelenkt hat, welche Planungen derzeit laufen und welche Gedanken sie zur Zukunft hat. Ich werde diese Punkte daher in diese drei Bereiche unterteilen.
Zu Beginn beschloss Elizabeth, zuzuhören. Dazu waren sehr, sehr viele Telefonate (etwa 60, darunter auch eines mit dem Verfasser dieses Artikels) nötig, um die Meinungen von PHP-Entwicklern darüber einzuholen, wo die Sprache derzeit steht. Das Ergebnis waren vier verschiedene Bereiche, die besondere Aufmerksamkeit erfordern:
· Transparenz
· Die Wahrnehmung von PHP außerhalb unserer Community
· Mangel an neuen Entwicklern für das Wachstum
· Interne Abläufe und der Abstimmungsprozess
Aufgrund dieser Erkenntnisse wurden unter dem Oberbegriff „Special Interest Groups“ (SIG) folgende Initiativen ins Leben gerufen:
· SIG „Ecosystem Security Team“
· SIG „PHP Outreach Ambassador Program“
· SIG „Onboarding“
· SIG Kryptografie
· SIG für Gemeinschaftsveranstaltungen
· SIG Barrierefreiheit
Wer daran interessiert ist, diesen Gruppen beizutreten, findet weitere Informationen dazu im Blog der PHP Foundation.
Das größte Problem, mit dem PHP zu kämpfen hat, ist eine Wahrnehmungsproblem , kein technisches. Sie kam zu dem Schluss, dass die Sprache stabil und die Community groß und engagiert ist – also gibt es Grund zur Freude.
Nach der diesjährigen Ankündigung der Einrichtung eines „Ecosystem Security“-Teams bei der PHP Foundation erscheint es nur folgerichtig, dass Nils nun über die Sicherheit in der Lieferkette sprach. In den letzten fünf Jahren gab es mehrere viel beachtete Fälle, wie beispielsweise den Angriff auf XZ Utils, bei dem es einem böswilligen Betreuer gelang, eine Hintertür in die Release-Tarballs von XZ Utils einzuschleusen – ein Tool, das in vielen großen Linux-Distributionen zum Einsatz kommt. Auch Angriffe auf lokale Rechner haben zugenommen, was nicht verwunderlich ist, da KI-Tools sowie IDEs wie VSCode und PHPStorm mittlerweile zahlreiche externe Aufrufe zum Schreiben von Code durchführen. Diese Tools verfügen zudem über Open-Source-Plugin-Marktplätze, was dazu führt, dass der Zugriff auf GitHub-Repositorys zu den häufigsten Angriffszielen bei den meisten großen Paketmanagern zählt.
Das Veröffentlichungsmodell von Composer hatte schon immer einen strukturellen Vorteil: Wenn man eine Veröffentlichung auf GitHub mit einem Tag versieht, speichert Packagist eine URL, die auf die GitHub-API verweist, welche dann direkt aus dem Quellcode dynamisch eine ZIP-Datei generiert.
Der Nachteil ist, dass diese dynamisch generierten ZIP-Dateien nicht stabil sind. Sie ändern sich im Laufe der Zeit, was bedeutet, dass man sie nicht sicher signieren kann. Zwar fixiert die Lock-Datei von Composer einen Commit für ein bestimmtes Tag, doch bedeutet dies, dass Entwickler im Rahmen von Audits Entwickler die Lock-Dateien sorgfältig prüfen müssen. Ich weiß nicht, ob Sie schon einmal an einem großen Projekt gearbeitet haben, aber diese können richtig groß werden. Packagist (das Unternehmen hinter Composer) bietet jedoch eine Funktion zur Überprüfung von Updates an, sodass es Werkzeuge gibt, die diese Aufgabe etwas erleichtern.
Es wurden bereits eine Reihe von Sicherheitsmaßnahmen eingeführt, um Angriffe auf die Lieferkette abzuwehren.
· Unveränderlichkeit der stabilen Version
· Das Rahmenwerk für Abhängigkeitsrichtlinien
· Die Ausweichoption für den Quellcode bei fehlgeschlagenem ZIP-Download ist nun standardmäßig deaktiviert
· Automatische Scans von Aikido Security
· Öffentliches Transparenzprotokoll
· Zentrale Sicherheitskontrolle des Paketportfolios für größere Projekte, z. B. Symfony
· Abklingzeit für den Abwurf, um automatisches Scannen zu ermöglichen
· Vorbereitungsumgebungen für die Veröffentlichung
· Vorgeschriebene Multi-Faktor-Authentifizierung (MFA)
· Unveränderliches Artifact-Hosting durch Packagist, um das Vertrauen in den Paketmanager zu stärken
Zunächst einmal gibt es einige Maßnahmen, die Sie bereits jetzt ergreifen können, um Ihre Sicherheit zu verbessern. Dazu gehören
· MFA aktivieren
· Verwenden Sie Tools wie Zizmor für die Sicherheit Ihrer CI-Pipeline
· Stellen Sie sicher, dass Sie Composer 2.0 verwenden
· Nutzen Sie das Hosting von Private Packagist für individuelle Sicherheitsanforderungen.
Noch wichtiger ist jedoch, dass Entwickler und Organisationen die Statistiken hinter etwas außer Acht lassen können, das im Grunde kostenlos ist. Packagist verzeichnet 4.800 Anfragen pro Sekunde, ist de facto der einzige PHP-Paketmanager und stellt 450.000 Pakete bereit, die monatlich rund 4 Milliarden Mal installiert werden. Zwar stammen einige Mittel für neue Funktionen von der PHP Foundation, doch ist es unerlässlich, dass Packagist die notwendigen Mittel erhält, um diese Infrastruktur aufrechtzuerhalten. In diesem Monat wird ein offizielles Sponsoring-Programm ins Leben gerufen; wenn Ihre Organisation auf diese Infrastruktur angewiesen ist, ist es von entscheidender Bedeutung, dass sie die benötigten Mittel erhält.
Diejenigen, die mich kennen, haben vielleicht schon bemerkt, dass ich gewissermaßen einen Kreuzzug gegen einen berühmten Satz führe, den die Leute immer wieder hervorholen, der aber nicht stimmt. Wenn das auf PHP zutrifft, kann man mit Fug und Recht sagen, dass WordPress mit genau denselben unbegründeten Vorurteilen konfrontiert wird. Die Sache ist die: Man würde nicht immer noch 40 % des Internets betreiben, wenn es sich nicht lohnen würde, es zu nutzen.
Jonathan konzentrierte sich auf eine Reihe von Mythen, die es zu widerlegen galt; daher finden Sie hier zehn übersichtlich geordnete Mythen, über die er sprach.
Es war für mich eine ziemliche Überraschung zu erfahren, dass alle neuen WordPress-Installationen PHP 8.3 verwenden und nun über Typdeklarationen, Schnittstellen und Namespaces verfügen – nachdem ab 2020 verstärkt daran gearbeitet wurde, die Codebasis zu modernisieren.
Block-Themes verwenden nun Block Markup, eine auf HTML-Kommentaren basierende Vorlagensprache. Die PHP-Tags aus alten Zeiten (hat jemand noch Nostalgie für die mit PHP-Code übersäten HTML-Seiten?) sind verschwunden, also ja: Das funktioniert jetzt.
Ein weiterer Vorwurf, der in der Vergangenheit allgemein gegen PHP erhoben wurde. WordPress verfügt nun über das Plugin „Performance Lab“, das die Geschwindigkeit misst und optimiert. Das „Speculative Loading“ wurde in den WordPress-Kern ab Version 6.8 integriert und sorgt für eine Leistungssteigerung von 98,2 %.
Blöcke verfügen nun über eigenständige Zustände, wodurch der Frontend- und der Backend-Bereich voneinander getrennt werden können. Vorbei ist die bisherige Verwendung von the_post() und anderer solcher Schrecknisse, an die ich mich noch aus längst vergangenen Zeiten bei WordPress erinnere
Durch die Einführung der Block-Bindings-API ist es nun nicht mehr erforderlich, dass benutzerdefinierte Felder fast immer eine Reihe von Plugins von Drittanbietern benötigen, um zu funktionieren.
Matt Mullenweg hat sich damit vielleicht ein kleines Eigentor geschossen, als das Gutenberg-Projekt an den Start ging. Nachdem er angemerkt hatte, dass Entwickler JavaScript als unverzichtbare Fähigkeit erlernen müssten, waren vielleicht einige PHP-Entwickler beunruhigt. Ich meine, ich wäre es jedenfalls, da ich eine ziemlich irrationale Abneigung gegen React habe. Entwickler, die sich nicht mit dem Frontend beschäftigen wollen, können die Interactivity-API nutzen, um dies zu erreichen, sodass die Interaktion über dynamische Blöcke erfolgt.
Ein weiteres häufiges Problem: Es wurden zahlreiche Maßnahmen ergriffen, um sicherzustellen, dass Entwickler über die notwendigen Werkzeuge verfügen, damit dies nicht der Fall ist. Automatische Updates für Plugins und Themes, Rollback-Schutz und bcrypt-Passwort-Hashing wurden bereits implementiert, und WordPress selbst weist keine ungepatchten kritischen Sicherheitslücken auf.
Zwar bietet WordPress standardmäßig keine Composer-Unterstützung, doch das Roots-Bedrock-Projekt macht dies möglich. Dasselbe Team hat kürzlich „WP Packages“ ins Leben gerufen, ein Composer-Repository für alle kostenlosen Plugins und Themes von wordpress.org.
Das Developer-Relations-Team von Attomatic war sehr fleißig, was sich an dem großen Aufwand zeigt, den es in den Entwickler-Blog gesteckt hat, indem es Tutorials und die Videoserie „Learn WordPress“ veröffentlicht hat. Das Entwicklerportal wurde komplett überarbeitet, sodass nun Themes, Plugins, der Block-Editor und die REST-API umfassend behandelt werden.
Zwar verfügte WordPress in der Vergangenheit über ein eigenes Exception-Objekt, WP_Error. Diese Einschränkung wurde nun aufgehoben, sodass Entwickler ihre eigene benutzerdefinierte Ausnahmebehandlung erstellen können. Das Kernteam selbst diskutiert derzeit die Möglichkeit, WP_Error aus dem Code zu entfernen.
Genau wie Entwickler, die PHP vielleicht anhand ihrer Erfahrungen von vor 20 Jahren beurteilen, lohnt es sich, einen neuen Blick darauf zu werfen. Tatsache ist, dass moderne WordPress-Entwickler Tools wie PHPStan, PHPUnit, Composer usw. nutzen, was der breiteren Community jedoch einfach nicht bewusst ist. Vor diesem Hintergrund fordert Jonathan WordPress-Entwickler dazu auf, über moderne Entwicklung auf der Plattform zu schreiben, und Nicht-WordPress-Entwickler, der Plattform eine weitere Chance zu geben.
Symfony war das erste PHP-Framework, das ich je verwendet habe. Als ich noch Ad-hoc-Schulungen durchführte, habe ich sogar Kurse zu Symfony 2 gegeben. Seit damals ist das Projekt enorm gewachsen. Fabien steht seit über 20 Jahren an der Spitze des Projekts.
Welche Wartungsaufgaben muss Fabien erledigen? Nun, es gibt mehr als dreihundert Repositorys mit 5.000 getaggten Releases pro Jahr. 25 % aller Downloads auf Composer Packagist stammen von Symfony (wobei Fabien jedoch schnell anmerkt, dass Downloadzahlen aufgrund von Pipeline-Downloads eher eine „Vanity Metric“ sind).
Ein Aspekt, den ich an Symfony besonders interessant finde, ist die Struktur des Frameworks: Es ist sowohl ein vollwertiges Framework als auch gleichzeitig eine Reihe eigenständiger Komponenten. Aufgrund dieses Aufbaus wird es als Basis für andere große Projekte wie beispielsweise Joomla! und Drupal, aber auch als Komponenten, die von Projekten wie Laravel und Magento genutzt werden – all diese werden von Fabien erwähnt.
Zu Beginn meiner Karriere tobte viele Jahre lang die Debatte um „Mikroservices“ versus Monorepo. Interessanterweise berichtet Fabien nun von seiner bewussten Entscheidung gleich zu Beginn von Symfony 2, dass alles im selben Repository unter symfony/symfony. Ein von ihm entwickeltes Tool namens Splitsh übernimmt die Installation. Es überwacht GitHub-Webhooks und zieht daraufhin alle während der Installation angeforderten Pakete unter dem Symfony-Namespace ein, darunter Symfony AI, Twig, Symfony UX und Symfony Console, um nur einige zu nennen. Diese werden als „Sub-Splits“ bezeichnet.
Fabien nennt vier Kernbereiche, die Symfony dahin gebracht haben, wo es heute steht.
Erstens, Stabilität innerhalb des Kernteams. Fabien an der Spitze, 30 Kernentwickler, von denen viele schon lange dabei sind.
Als Nächstes eine eindeutiges Framework. Ich bin ein sehr, sehr großer Fan dieses Ansatzes, denn wenn ich in der Node-Welt arbeiten muss, bin ich ständig verwirrt von den vielen, vielen Optionen, die man beim Programmieren wählen kann. Es gibt einen einheitlichen Codestil („Die Symfony-Art“ Way“) und offene Standards (PSR).
Für Ihre Kunden, die auf das Framework angewiesen sind, ist Konsistenz ist entscheidend. Symfony sieht zwei Minor-Releases pro Jahr und alle zwei Jahre ein LTS-Release vor.
Zum Schluss noch etwas, das mir aufgrund der Wartungsarbeiten, die wir am Vonage PHP SDK durchführen müssen, besonders am Herzen liegt: semantische Versionierung. Ich kann gar nicht nachvollziehen, wie wir früher Software veröffentlicht haben, ohne semantisches Versioning zu verwenden.
Ein kniffliger Aspekt bei der Pflege eines Open-Source- Projekts dieser Größenordnung besteht darin, dass man die richtigen Prozesse und damit die richtigen Werkzeuge benötigt, um dies zu erreichen. Während des größten Teils der Existenz von Symfony waren viele manuelle Schritte erforderlich. KI hat dies jedoch verändert.
Fabien hat benutzerdefinierte Agenten erstellt, um den Großteil der massenhaften und sich wiederholenden Aufgaben zu bewältigen. Dazu gehört die Aufarbeitung schwieriger Merge-Konflikte, zumal Symfony derzeit sechs mit Tags versehene Zweige verwalten muss.
Der Release-Prozess selbst wird nun von einem PHP-Agenten gesteuert, den Fabien selbst geschrieben hat. Dieser Agent nimmt den Release-Befehl entgegen, fragt dann nach der Art des Releases, gibt einen Release-Plan zur Überprüfung zurück und kann den Vorgang nach Erhalt der Bestätigung ausführen. Er verfügt sogar über eine Funktion, mit der sich Entwürfe für Blogbeiträge zu den Releases erstellen lassen.
Vielleicht liegt es an dem rasanten Tempo, mit dem wir uns im Zeitalter der KI bewegen, aber die Nachteile werden nicht immer so offen diskutiert. Fabien erzählt uns, dass sie früher einmal im Monat ein Audit erhielten. Jetzt findet täglich eine statt. Erst kürzlich haben sie eine Symfony-Version veröffentlicht, mit der 50 bekannte Sicherheitslücken (CVEs) behoben wurden.
Diese schiere Menge an hoher Kadenz wird von einer Sache angetrieben: LLMs. Der Grund, warum ich sage, dass es meiner Meinung nach Vor- und Nachteile gibt, ist, dass das Symfony-Team nun im Grunde genommen gezwungen ist , LLMs einzusetzen, um diese Menge an Code zu korrigieren; denn wenn das Symfony-Team dies nicht tut, wird jemand anderes über ein LLM eine CVE finden. Ein weiterer Nachteil besteht darin, die Antworten auf Fehlalarme überprüfen zu müssen, aber insgesamt ist es ein positiver Schritt, dass Fabien darauf abzielt, diese Tools zu nutzen, um von vornherein abgesicherte Releases zu veröffentlichen, anstatt sie erst nachträglich zu patchen.
Im Grunde genommen entwickelt sich Symfony immer weiter, und Fabien und das Kernteam nutzen jedes ihnen zur Verfügung stehende Werkzeug, um bei einem PHP-Framework, das einige der schwersten Aufgaben in der gesamten Branche bewältigt, immer auf dem neuesten Stand zu bleiben. Ich persönlich habe so viele Veränderungen miterlebt (ich glaube, die Veröffentlichung von Symfony Flex fiel ungefähr in die Zeit, als ich zu anderen Frameworks gewechselt bin) und bin nun zu einer schwindelerregenden Vielfalt an Funktionen mit hervorragender Dokumentation zurückgekehrt.
Insgesamt gab es acht Vorträge, also seid gespannt auf die zweite Runde, in der ich mit Ashley Hindle und Jeffrey Way über KI, mit Mike Merchel über Drupal und mit Larry Garfield über PHP-RFCs sprechen werde.
Haben Sie eine Frage oder möchten Sie uns mitteilen, was Sie gerade bauen?
Abonnieren Sie den Entwickler-Newsletter
Folgen Sie uns auf X (früher Twitter) für Updates
Lieber ein Video? Schau dir Tutorials auf unserem YouTube-Kanal an
Verbinden Sie sich mit uns auf der Vonage Entwickler-Seite auf LinkedIn
Helfen Sie uns, unsere Entwicklererfahrung zu verbessern, indem Sie unser Feedback-Formular „Voice of the Developer“ aus.
Bleiben Sie auf dem Laufenden und halten Sie sich über die neuesten Nachrichten, Tipps und Veranstaltungen für Entwickler auf dem Laufenden.
Teilen Sie:
Als ausgebildeter Schauspieler mit einer Dissertation in Standup-Comedy bin ich über die Meetup-Szene zur PHP-Entwicklung gekommen. Man findet mich, wenn ich über Technik spreche oder schreibe, oder wenn ich seltsame Platten aus meiner Vinylsammlung spiele oder kaufe.