WP21: Technische Ankündigung
(ma.tt)- WordPress ist nun 21 Jahre alt, seit Matt Mullenweg und Mike Little b2/cafélog geforkt und die erste Version veröffentlicht haben; auch die künftige Entwicklung sollte sich wieder auf die Bedingungen besinnen, die den frühen Erfolg ermöglicht haben
- Die Produktrichtung folgt dem Prinzip: Einfache Dinge sollen intuitiv sein, komplexe Dinge aber ebenfalls möglich
- Dynamische Webfunktionen wie Blogging, Kommentare und Pingbacks machen Websites interessanter; dynamischen Websites wird ein größerer Wert beigemessen als statischen Websites
- Das Plugin- und Theme-Ökosystem sollte über eine Entwicklungsinfrastruktur auf dem Niveau des WordPress-Core verfügen; sich 2024 auf ZIP-Uploads zu verlassen, passt nicht mehr
- Feedback-Loops nah an den Nutzern, Community-orientierte Foren, gute Theme-Vorschauen und Playground werden die künftige WordPress-Erfahrung prägen
21 Jahre WordPress und Produktprinzipien
- WordPress ist nun 21 Jahre alt, seit Matt Mullenweg und Mike Little Michels Arbeit an b2/cafélog geforkt und die erste Version veröffentlicht haben
- Auch bei der künftigen Entwicklung sollten die Faktoren, die zum frühen Erfolg von WordPress beigetragen haben, weiter berücksichtigt werden
- Das zentrale Produktprinzip lautet, dass Einfache Dinge leicht und intuitiv sein sollten, komplexe Dinge aber möglich bleiben müssen
Blogs, Dokumentation und Community-Funktionen
- Blogging, Kommentare und Pingbacks sollten Spaß machen
- Statische Websites sind in Ordnung, aber die Haltung ist, dass dynamische Websites besser sind
- Fast jede Website kann durch ein gutes Blog besser werden
- Dokumentation sollte sich so leicht wie ein Wiki bearbeiten lassen
- Wikis werden als „erstaunliche“ Werkzeuge eingeschätzt
- In Communities sollten Foren im Mittelpunkt stehen
- bbPress und BuddyPress brauchen mehr Aufmerksamkeit
Plugin- und Theme-Ökosystem
- Alle Plugins und Themes sollten über eine Entwicklungsinfrastruktur auf dem Niveau verfügen, das auch für die Entwicklung von WordPress selbst genutzt wird
- Versionsverwaltung
- Bugtracker
- Foren
- Dokumentation
- Internationalisierung
- Chaträume
- P2
- Ein einfacher Weg hin zu Beiträgen und Community
- Plugins und Themes im Jahr 2024 per ZIP-Upload zu handhaben, ist nicht angemessen
- Theme-Vorschauen sollten hervorragend sein
- Eine Sammlung nichtkommerzieller Themes mit unterschiedlicher Ästhetik und Funktionalität ist wichtig
Feedback-Loops und Transparenz statt Regeln
- Man sollte sich nicht zu stark auf Richtlinien und Anforderungen versteifen
- Besser ist es, gute Marktplatzdynamiken, automatisierte Feedback-Loops und Transparenz gegenüber den Nutzern zu gestalten
- Die Grenzen von Funktionalität und Design sollten weiter verschoben werden
- Gegen Spam und spamartiges Verhalten braucht es Nulltoleranz
- Feedback-Loops sollten nicht von Gatekeepern abhängen, sondern mit Nutzung und der gesamten Community skalieren
Charakter des Core und Kontaktpunkte zu Nutzern
- Der WordPress-Core sollte meinungsstark und unverwechselbar sein
- Easter Eggs
- Eine Sprache mit Persönlichkeit, auch wenn sie schwer zu übersetzen ist
- Ein jazzartiger Charakter
- Alle, die Software entwickeln und Entscheidungen über sie treffen, sollten diese Software auch selbst nutzen
- Entwickler und Entscheider sollten durch Support-Arbeit, Meetups, Events und andere mögliche Aktivitäten nah an normalen Endnutzern sein
Playground und die erste Erfahrung
- Es wird erwartet, dass Playground alles verändern wird
- Am 27. Mai 2003, dem Tag der ersten WordPress-Veröffentlichung, schrieb Matt Mullenweg in einem 953 Wörter langen Blogbeitrag auf der Veranda seines Elternhauses den Satz: „Ich habe WordPress veröffentlicht, und es fühlte sich gut an“
- In derselben Nacht richtete er WP für seinen Freund Ramie Speight ein und leistete telefonischen technischen Support für Mike Tremoulet, den er bei einem lokalen Blogger-Treffen kennengelernt hatte
- Freunde aus der Highschool nutzten WordPress jeweils auf ihren eigenen Domains, und dieser Feedback-Loop spielte eine große Rolle dabei, die Software zu formen
1 Kommentare
Meinungen auf Hacker News
Es ist enttäuschend, dass WordPress offenbar nicht nur Entwicklungsstandards nicht einhält, sondern sie aktiv brechen will.
Erst wurden überall globale Variablen verwendet und mit klassischen Themes Spaghetti-Code gefördert, und bei den neuen Themes soll man nun JSON in HTML-Kommentare stecken, was keine Editor-Unterstützung bietet, leicht Fehler verursacht und einfach ein seltsames Design ist.
Man fragt sich ernsthaft, ob Senior Engineers wirklich entschieden haben, JSON-Templates in HTML-Kommentare zu packen; verschwörungstheoretisch betrachtet wirkt es sogar so, als wolle man den Markt für Freelancer und Digitalagenturen abwürgen und alle in den WYSIWYG-Site-Builder von WP.com drängen.
Es ist HTML in PHP, darin JS, darin CSS und so weiter, und es verlässt sich auf eine implizite Struktur dafür, welche Dateien in welcher Reihenfolge gelesen werden, um eine ganze Seite zu erzeugen.
Anfangs wirkt das bequem, aber es führt dazu, dass HTML-Elemente nicht sauber in derselben Datei geschlossen, sondern in einer anderen Datei beendet werden, wodurch Wiederverwendung praktisch unmöglich wird.
Das sieht aus wie ein Anfängerfehler, aber Tausende Themes hängen davon ab, also ist man inzwischen daran gefesselt; im Kontrast dazu steht die Art, wie Jinja2-Templates Blöcke und Makros rendern.
WordPress existiert für Kunden ohne Budget und Billigkunden, die der Illusion unterliegen, sie bräuchten nur eine einfache Website; und die Vorstellung einer solchen einfachen Site ist meiner Meinung nach ohnehin längst tot.
https://timber.github.io/docs/v2/
Sobald man auf einen neuen Server mit nur leicht anderem Installationspfad umziehen wollte, ging alles sofort kaputt.
Leider könnte das dem Marketing-Satz „Unsere Plattform betreibt 43,4 % aller Websites“ schaden.
Es ist schade, dass schnelle Urteile und starke Meinungen Teil der Community geworden sind.
Nachdem ich in den letzten zwei bis drei Monaten viel WordPress-Entwicklung gemacht habe, möchte ich sagen: Die Code-Isolation, die Blocks (Gutenberg) bieten, ist hervorragend.
Als eigenständiges Plugin oder zusammen mit Advanced Custom Fields kann man vollständig modulare Websites und Entwicklungsabläufe, also Designsysteme, bauen und dabei sogar das HTML zu 100 % selbst kontrollieren.
Ich empfehle jedem, WordPress wirklich zu verstehen und zu lernen. Ich habe keinerlei Beziehung oder Verbindung zu WordPress.
Seit heute geraten Gutenberg und ACF Blocks irgendwo beim Parsen von Inhalten verschachtelter Medienfelder aneinander.
Die Ursache könnte sein, dass „der Nutzer eine Bildbeschreibung eingegeben hat, die er nicht hätte eingeben dürfen“, oder dass „ein globales Objekt eines Plugins ein anderes globales Objekt verunreinigt hat, das an
acf_register_block_type()übergeben wird“.Vielleicht muss ich einen ohnehin schon verärgerten Kunden anrufen und ihm sagen, er solle schnelle Urteile und starke Meinungen vermeiden.
Das mag heute anders sein, aber Skepsis ist nachvollziehbar. In den Updates, die ich jede Woche prüfe, sehe ich ziemlich viele CVEs; vielleicht sind sie alle mit geringem Risiko verbunden oder betreffen kaum genutzte Plugins.
index.phpvon WordPress zu öffnen, um zu verstehen, wie es funktioniert.Ich erinnere mich, dass ich außer dem Kommentar „code is poetry“ ganz oben in der Datei nichts verstanden habe.
Dadurch hat sich meine Denkweise über Code verändert, und ich bin noch tiefer ins Programmieren eingestiegen.
Braucht ein Beitrag Metadaten, installiert man ACF; will man nach diesen Metadaten filtern, laufen SQL-Abfragen schon bei ein paar gleichzeitig aktiven Filtern ins Timeout. Wenn man das seltsame Schema von WP sieht, versteht man warum.
Gutenberg verspricht per WYSIWYG editierbare React-Komponenten, trifft aber die seltsame Entscheidung, Attribute im HTML zu speichern, gerendertes HTML in die Datenbank zu schreiben und Komponentenentwickler bei jeder Änderung ein Array mit Deprecated-Änderungen pflegen zu lassen.
Es gibt auch Versuche, WordPress zu refaktorisieren und Laravel daran anzudocken, um es zu entwirren[1], aber jede Schicht ist ein Albtraum, und selbst die Autoren der verschiedenen Teile scheinen kaum beurteilen zu können, warum zufällig etwas kaputtgeht.
Das Plugin-Ökosystem mag attraktiv sein, aber die Plugin-Implementierungen sind völlig uneinheitlich, sodass man Nutzern sehr wahrscheinlich aufgeblähte CSS- und JS-Brocken ausliefert.
Ich bin zu Directus und Astro gewechselt; für ein allgemeineres PHP-Deployment würde ich wohl ein Laravel-basiertes CMS wie October oder Statamic nutzen.
[1]: https://roots.io/
Ich habe mich 2009 bis 2011 recht viel damit beschäftigt, einschließlich Schreiben und Anpassen von Plugins, hatte aber nie das Gefühl, es wirklich verstanden zu haben; ich habe es eher grob verstanden oder einfach hingenommen.
Ich mag WordPress. Leute installieren es selbst, packen Dutzende nutzlose, unsichere und fehlerhafte Plugins drauf, und wenn die Website mit der Zeit kaputtgeht, kann man ihnen eine sicherere und robustere Lösung in Rechnung stellen.
Es wirkte wie ein nie fertig gewordenes Wochenendprojekt, das viel zu lange vor sich hin geschleppt und dann veröffentlicht wurde: ein fünf Bildschirme langer
for-Loop, der über einer riesigen globalen Variable kreiste, war dupliziert und verarbeitete auf diese Weise irgendetwas.WordPress ist mein Lieblingsbeispiel für „Es muss nicht perfekt sein, es muss nur funktionieren“.
Viele großartige Projekte sterben daran, dass sie den ersten Schritt zu kompliziert machen. Wenn die Leute es erst einmal nutzen, kann man später jederzeit verbessern – aber zuerst muss man es veröffentlichen.
Es ist so schlimm, dass selbst die PHP-Sprachentwickler manche Funktionen oder Korrekturen nicht umsetzen können, weil das WordPress-Team den Code nicht migrieren will und WordPress einen großen Teil der PHP-Nutzung ausmacht.
WP ist für 95 % der Aufgaben das perfekte Werkzeug, aber die letzten 5 % anzupassen ist unglaublich frustrierend.
Ich habe es viel genutzt, und dass es so lange überlebt hat, sehe ich als Beleg für seine Nützlichkeit. Ich hoffe, es hält noch weitere 21 Jahre durch.
Ehrlich gesagt habe ich WordPress nie als einfach zu benutzen empfunden. Es wirkt nur so lange rosig, wie man gute Themes und Plugins finden kann; sobald man auch nur eine kleine Anpassung braucht, fängt es an, sich zu verheddern.
Sobald ich dann die Seite samt Plugin-/Theme-Code und CSS-Dateien öffnete, rang ich stundenlang damit, den gewünschten Effekt zu erzielen, und selbst wenn es klappte, machte ich oft andere Teile der Website kaputt.
Die abwertende Anekdote mal beiseite: Matt hat das gut gemacht, und die letzte Geschichte war auch schön.
Updates erfordern manuelle Eingriffe, Themes müssen repariert werden, Plugins werden aufgegeben. Weil ich diese Last nicht mehr tragen wollte, habe ich ab etwa 2017 alle Sites auf Hugo/Jekyll/MkDocs usw. umgezogen.
Für einen Blog würde ich lieber Ghost als WP verwenden, und ich bevorzuge JS auch gegenüber PHP.
Interessant ist, dass mehrere Leute sagen können: „Ich bin WordPress-Entwickler“, damit aber tatsächlich völlig unterschiedliche Erfahrungen und Skill-Sets meinen.
Für manche bedeutet es, im WordPress-Admin Themes und Plugins zu installieren und Seiteninhalte zu schreiben.
Für andere bedeutet es alten PHP-Code, also klassische Themes, bei denen man HTML in PHP-Templates schreibt und das Verhalten von WordPress anpasst.
Für wieder andere bedeutet es neue Block-Themes, bei denen man JS+React zusammen mit Docker und CI/CD schreibt.
Ich wünschte, mehr Unternehmen würden Automattics Sabbatical-Regelung übernehmen.
https://automattic.com/benefits/sabbatical/
Dass man sich alt fühlt, merkt man daran, dass man bei „WP“ nicht an WordPress, sondern an WordPerfect(https://en.wikipedia.org/wiki/WordPerfect) denkt.
WordPress ist inzwischen alt genug, um selbst in den konservativsten Ländern als volljährig zu gelten, und WordPerfect kommt jetzt ins Alter der Midlife-Crisis.
Beeindruckend an WordPress ist, dass Web-Nerds selbstverständlich erwarten, es müsse einfach sein, und wütend werden, wenn es das nicht ist.
Wie alles andere muss man auch WordPress lernen, und es hat seine eigene Sichtweise.
Es hat auch eine seltsame Geschichte, und besonders die Art, wie es mit Medienobjekten umgeht, gefällt mir wirklich nicht, aber es gibt trotzdem eine Methodik.
Wenn ich sagen würde, ich kenne Go, JS, Perl, Java, Ruby und C, und mich dann darüber ärgern würde, dass Rust schwer zu lernen ist, würde man mir zu Recht widersprechen.
WordPress sieht so aus, als erledige es einfache Dinge, ist tatsächlich aber eine ziemlich breite Plattform. Vielleicht muss man ein bisschen Dokumentation lesen.
Wenn man eine Website mit Elementor geerbt hat, kann es helfen, die Person, die sie gebaut hat, zu fragen, wie man einfache Änderungen vornimmt.
Wenn man eine Website mit Visual Composer oder Divi geerbt hat, möchte man die Leute, die sie gebaut haben, am liebsten erschießen.
Wenn man Gutenberg für schlecht hält: Das ist es heute überhaupt nicht mehr. Wenn man an die Divi-Zeiten zurückdenkt, war das wirklich schlimm.
Wenn in dieser schrecklichen, auf WordPress aufgesetzten JavaScript-UI-Ausführung auch nur irgendwo ein Timeout auftritt, kann schon das Speichern eines Blogposts die gesamte Website in einen nicht wiederherstellbaren Zustand versetzen.
Die italienische und französische Lokalisierung ist so miserabel wie japanische Spiele aus den 90ern, und die Responsive-Optionen funktionieren praktisch nicht – es sei denn, man nennt es „responsive“, Inhalte an bestimmten Breakpoints ein- und auszublenden.
Alles ist extrem fragil, weil das Frontend-„Theme“ eher einem unlesbaren Dump von JavaScript aus der jQuery-Ära gleicht.
Ich bin zu 100 % sicher, dass niemand es benutzen würde, wenn Elegant Themes nicht Unsummen für Werbung ausgeben würde.