WordPress 4.9 im Rückblick: die Version vor Gutenberg

WordPress 4.9 “Tipton” (erschienen 2017) war ein besonderes Release. Es war die letzte große Version vor WordPress 5.0, das Gutenberg zum Standard-Editor machte.

Mehr über unsere WordPress-Entwicklung bei WPPoland.

Kurz gesagt: WordPress 4.9 ist wichtig, weil es die tatsächlichen Arbeitsabläufe von Redaktionen und Entwicklern verbesserte, kurz bevor Gutenberg das gesamte Bearbeitungsmodell veränderte. Dieser Rückblick hält sich an das, was die offizielle Release-Ankündigung, der Field Guide zu 4.9 auf make.wordpress.org und die Versionsseite in der WordPress-Dokumentation tatsächlich sagen, mit Links, damit Sie jeden Punkt nachprüfen können.

#Wann WordPress 4.9 erschien und wer es leitete

WordPress 4.9 “Tipton”, benannt nach dem Jazzmusiker und Bandleader Billy Tipton, wurde am 16. November 2017 in der offiziellen Release-Ankündigung vorgestellt. Die Versionsseite in der WordPress-Dokumentation datiert das Release auf den 15. November, also denselben Zeitpunkt aus Sicht einer US-Zeitzone. Es war die letzte große Version, in der der klassische Editor Standard war.

Laut Ankündigung wurde das Release von Mel Choyce und Weston Ruter geleitet. Genannt werden 443 Mitwirkende, davon 185 zum ersten Mal, und zum Start war WordPress 4.9 vollständig in 43 Sprachen übersetzt. Die Dokumentationsseite ergänzt zwei Werte, die beim Untersuchen einer alten Installation helfen: Die Datenbankversion blieb bei 38590, und das Release entspricht der Trac-Revision 42195.

Der Field Guide zu 4.9, vor dem Release veröffentlicht, zählt rund 400 Bugs, 181 Verbesserungen, 7 Feature-Requests und 42 Aufgaben, die im Zyklus geschlossen wurden.

Warum 4.9 im Rückblick zählt:

• es war die letzte Version mit dem klassischen Editor als Standard,
• es brachte CodeMirror in den Core, und diese Bibliothek steckt bis heute hinter den Code-Feldern im Dashboard,
• es vollendete die Changeset-Arbeit am Customizer, die mit 4.7 begonnen hatte,
• die Ankündigung selbst wurde in Gutenberg geschrieben und bat die Leser, den neuen Editor zu testen.

#Was sich im Customizer von WordPress 4.9 änderte

#Entwürfe und geplante Änderungen im Customizer

Zum ersten Mal ließen sich Designänderungen (Farben, CSS, Widgets, Menüs) als Entwurf speichern und später fortsetzen, ohne etwas live zu veröffentlichen.

Die Technik dahinter war älter als der Button. Changesets, eine Möglichkeit, ausstehende Customizer-Änderungen als Beitrag vom Typ customize_changeset mit einer UUID zu speichern, kamen mit WordPress 4.7. Wie Weston Ruter in der Entwicklernotiz zu Changesets in 4.9 erklärt, hatte 4.7 dafür keine Oberfläche. Ein Changeset lag in einem auto-draft-Beitrag, der nach einer Woche aufgeräumt wurde, wenn man ihn nicht erneut anfasste.

WordPress 4.9 lieferte die Oberfläche. Nach der ersten Änderung erscheint neben dem Veröffentlichen-Button ein Zahnrad, das die Veröffentlichungseinstellungen öffnet: veröffentlichen, als Entwurf speichern oder planen. Ein Link zum Verwerfen setzt den Customizer auf den zuletzt veröffentlichten Stand zurück.

Vor 4.9 bedeuteten Designänderungen:

• direkt auf der Live-Seite arbeiten (riskant),
• eine Staging-Umgebung nutzen (mehr Einrichtung),
• CSS von Hand einfügen (schwer rückgängig zu machen).

Die Zeitplanung funktioniert, weil ein Changeset live geht, sobald sein Beitrag in den Status publish wechselt. Die Notiz zeigt, dass der Mechanismus schon vor der Oberfläche existierte, mit einem WP-CLI-Befehl, der eine Änderung des Seitentitels plant:

wp post create \
    --post_type=customize_changeset \
    --post_name=$( uuidgen ) \
    --post_status=future \
    --post_date="2018-01-01 00:00:00" \
    --post_content='{"blogname":{"value":"Happy New Year!"}}'

Ein praktischer Hinweis aus derselben Notiz gilt weiterhin. Geplante Changesets werden über WP-Cron veröffentlicht, normalerweise innerhalb einer Minute nach dem geplanten Zeitpunkt. Auf einer Seite mit wenigen Besuchern läuft Cron womöglich nicht rechtzeitig, und die Notiz empfiehlt einen System-Cronjob, der wp-cron.php jede Minute aufruft, wenn der Zeitpunkt wichtig ist.

#Vorschaulinks für Kunden

Die Vorschau eines Changesets ist ein reiner Lesezugriff. Wer die UUID kennt, sieht die Seite mit den ausstehenden Änderungen, angemeldet oder nicht. WordPress 4.9 machte daraus einen Vorschaulink, den man an Kollegen und Kunden schicken kann. Die Ankündigung beschreibt ihn als Weg, Feedback einzusammeln, bevor die Änderungen geplant live gehen, und so haben Agenturen ihn auch genutzt.

#Design-Sperre und automatisches Speichern im Customizer

Da ein gespeicherter Entwurf jetzt für jeden Nutzer geladen wird, der den Customizer öffnet, konnten sich zwei Personen gegenseitig überschreiben. Die Antwort in 4.9 war die Changeset-Sperre nach dem Vorbild der Beitragssperre: Ein zweiter Nutzer sieht einen Sperrhinweis und kann zurückgehen oder übernehmen, und der Customizer hält die Sperre über WP Heartbeat aktiv.

Auch das automatische Speichern wurde besser. Wer den Browser versehentlich schloss, bekam beim nächsten Öffnen des Customizers angeboten, den letzten Auto-Draft wiederherzustellen. Seiten oder Beiträge, die während eines Entwurfs im Customizer angelegt wurden, erschienen in der Admin-Liste als Customizer-Entwürfe markiert.

#Lineare und verzweigte Changesets

Der Core arbeitet im sogenannten linearen Modus: Es kann immer nur ein Changeset als Entwurf gespeichert oder geplant sein. Wer eine Titeländerung für nächste Woche plant, kann heute keine unabhängige Änderung des Untertitels veröffentlichen, ohne beides zu verwerfen oder gemeinsam zu veröffentlichen. Auch der Theme-Wechsel ist gesperrt, solange ein Changeset als Entwurf oder geplant existiert.

Seiten mit mehreren intensiven Customizer-Nutzern können das frühere Verhalten, bei dem jede Sitzung ein eigenes Changeset bekommt, mit einem Filter zurückholen:

add_filter( 'customize_changeset_branching', '__return_true' );

#Themes im Customizer suchen und wechseln

Der Customizer bekam einen neuen Theme-Browser. Laut Ankündigung ließen sich über 2600 Themes direkt im Customizer suchen, durchstöbern und in der Vorschau ansehen, mit Filtern nach Thema, Funktionen und Layout. Der Field Guide merkt an, dass man dabei zum ersten Mal Themes von WordPress.org im selben Ablauf installieren konnte.

Auch der Theme-Wechsel wurde weniger zerstörerisch. Die Dokumentation nennt eine Zuordnung von Menüs und Widgets nach bestem Schätzen (Trac #39692), sodass Menüs und Widgets im neuen Theme eher an einer sinnvollen Stelle landeten. Der Ablauf zum Anlegen von Menüs im Customizer wurde ebenfalls überarbeitet, mit neuen Hinweisen zum Erstellen eines Menüs und zum Zuweisen einer Position.

#Wie CodeMirror die Code-Bearbeitung in WordPress 4.9 veränderte

Die Code-Editoren im Dashboard bekamen endlich Syntaxhervorhebung, Linting und Autovervollständigung. Die Entwicklernotiz zur Code-Bearbeitung nennt vier Stellen mit CodeMirror: Zusätzliches CSS im Customizer, das HTML-Widget sowie die Theme- und Plugin-Dateieditoren.

Es war der zweite Anlauf. Syntaxhervorhebung in den Dateieditoren gab es schon in WordPress 2.8 mit einer Bibliothek namens CodePress, sie wurde aber in 2.8.1 wegen Browser-Kompatibilitätsproblemen wieder entfernt. Die Funktion wurde in Trac-Ticket #12423 erneut vorgeschlagen und brauchte acht Jahre für die Rückkehr.

Was CodeMirror in 4.9 brachte:

• Syntaxhervorhebung mit mitgelieferten Modi, darunter css, htmlmixed, javascript, php, sql, markdown und yaml.
• Automatisches Schließen und Zuordnen von Klammern und Tags.
• Linting mit CSSLint, JSHint, HTMLHint und JSONLint.
• Autovervollständigung für CSS-Eigenschaften, HTML-Tags und JavaScript-DOM-Objekte.

Findet ein Linter einen Fehler, verlangt WordPress eine Korrektur vor dem Speichern. Im Bereich Zusätzliches CSS und im HTML-Widget bleibt das Speichern blockiert, bis der Code gültig ist; in den Dateieditoren kann man die Warnung übergehen und trotzdem speichern. In 4.7 zählte Zusätzliches CSS nur geschweifte und eckige Klammern, was zu Fehlalarmen führte, wenn eine Klammer in einem Kommentar stand. Diese serverseitige Prüfung wurde zugunsten von CSSLint entfernt.

Zwei Details zeigen, wie sorgfältig der Umfang gewählt wurde. CodeMirror kam nicht in den Text-Tab des Beitragseditors, wegen Bedenken zur Barrierefreiheit für Screenreader-Nutzer und weil Gutenberg diesen Editor ohnehin ersetzen sollte. Und jeder Nutzer bekam im Profil eine Option, die Syntaxhervorhebung abzuschalten.

#Abgesicherte PHP-Änderungen in Theme- und Plugin-Editor

Die Ankündigung fasst es als Schutz vor dem gefürchteten weißen Bildschirm zusammen. Der Mechanismus aus Trac #21622 ist ein Rollback. Beim Speichern einer PHP-Datei im Theme- oder Plugin-Editor behält WordPress eine Kopie des alten Inhalts, schreibt die Änderung und schickt dann eine Loopback-Anfrage mit Ihren Cookies an die Editor-Seite. Löst diese Anfrage einen fatalen Fehler aus, wird die alte Datei wiederhergestellt. Andernfalls prüft eine zweite Loopback-Anfrage die Startseite. Bei jedem fatalen Fehler bekommen Sie die Meldung, und Ihre Änderung bleibt im Editor, damit Sie sie korrigieren können. Können die Loopback-Anfragen nicht abgeschlossen werden, wird die Änderung zurückgenommen und Sie werden auf SFTP verwiesen.

Gespeichert wird jetzt per Ajax, und wer die Seite mit ungespeicherten Änderungen verlässt, bekommt einen Bestätigungsdialog. Vor 4.9 versuchte der Plugin-Editor, fatale Fehler durch Deaktivieren und erneutes Aktivieren des Plugins zu erkennen, was ein kritisches Plugin abgeschaltet zurücklassen konnte. Themes hatten gar keinen Schutz.

Auch rund um die Editoren änderte sich einiges. Beim ersten Besuch erscheint eine Warnung, dass das direkte Bearbeiten von Dateien riskant ist, und der Theme-Editor verweist auf den Bereich Zusätzliches CSS. Mehr Dateitypen wurden bearbeitbar (darunter js, json, scss, md, svg und yml), Dateien tiefer als zwei Verzeichnisebenen ließen sich öffnen, und die Dateiliste wurde zu einem aufklappbaren Baum.

#Den WordPress-Code-Editor im eigenen Plugin nutzen

CodeMirror ist in 4.9 auch eine API. Die Funktion wp_enqueue_code_editor() nimmt einen Datei-type, einen file-Namen oder ein codemirror-Einstellungsarray entgegen, wählt passende Standardwerte für die Sprache und gibt die Einstellungen zurück, oder false, wenn der Nutzer die Syntaxhervorhebung abgeschaltet hat. Das Beispiel aus der Notiz macht das Biografie-Feld im Profil zu einem HTML-Editor:

add_action( 'admin_enqueue_scripts', function() {
	if ( 'profile' !== get_current_screen()->id ) {
		return;
	}

	// Code-Editor und Einstellungen für HTML laden.
	$settings = wp_enqueue_code_editor( array( 'type' => 'text/html' ) );

	// Abbrechen, wenn der Nutzer CodeMirror deaktiviert hat.
	if ( false === $settings ) {
		return;
	}

	wp_add_inline_script(
		'code-editor',
		sprintf(
			'jQuery( function() { wp.codeEditor.initialize( "description", %s ); } );',
			wp_json_encode( $settings )
		)
	);
} );

Bevor die Einstellungen zurückkommen, laufen sie durch den Filter wp_code_editor_settings, mit dem sich Optionen wie lineWrapping global ändern lassen. Der Core registriert die Bibliothek unter dem Handle wp-codemirror und stellt sie als wp.CodeMirror bereit statt als globales CodeMirror-Objekt, damit sie nicht mit Plugins kollidiert, die eine eigene Kopie mitbringen. Im Customizer steht derselbe Editor als Control über WP_Customize_Code_Editor_Control zur Verfügung.

#Änderungen an Widgets in WordPress 4.9

#Galerie-Widget und Medien im Text-Widget

Fotogalerien in der Seitenleiste wurden zur Kernfunktion. Das Galerie-Widget folgte auf die Bild- und Medien-Widgets aus WordPress 4.8, die Dokumentation führt es als Trac #41914.

Auch das Text-Widget änderte sich. Es bekam einen Button zum Hinzufügen von Medien (Bilder, Video und Audio) und führte erstmals Shortcodes aus. Dieser Wunsch (Trac #10457) war über acht Jahre offen, und Plugins und Themes brauchten danach kein add_filter( 'widget_text', 'do_shortcode' ) mehr. Text-Widgets akzeptieren zudem oEmbeds, eine YouTube-URL im Widget wird also zum eingebetteten Player, und das Video-Widget lernte Anbieter außer YouTube und Vimeo.

Auf der Widget-Seite im Admin zeigt ein neuer Änderungsstatus, ob ein Widget gespeichert wurde, und fragt nach, wenn man die Seite mit ungespeicherten Änderungen verlassen will.

#Sicherheit, Rollen und Entwickler-Änderungen in WordPress 4.9

#Neue Berechtigungen und Kontosicherheit

Dokumentationsseite und Field Guide nennen mehrere Änderungen, die für die Benutzerverwaltung wichtig sind:

• die einzelnen Berechtigungen activate_plugin und deactivate_plugin, geprüft gegen ein bestimmtes Plugin, sodass eine Rolle manche Plugins schalten darf und andere nicht,
• eigene Berechtigungen zum Installieren und Aktualisieren von Sprachdateien,
• ein Bestätigungslink per E-Mail, wenn ein Nutzer seine E-Mail-Adresse ändern will (Trac #16470),
• eine zuverlässigere Initialisierung von Rollen und Berechtigungen, wenn Code in Multisite zwischen Websites wechselt, dazu die neue Funktion get_site_by().

#Customizer-JS-API, MediaElement und Entfernungen

Für Entwickler verlor die JavaScript-API des Customizers viele Ärgernisse, die der Field Guide aufzählt: Standardparameter für Konstrukte, Basis-Templates für Controls, ein Datum-und-Uhrzeit-Control sowie Benachrichtigungen auf globaler, Panel- und Sektionsebene. MediaElement.js wurde auf 4.2.6 aktualisiert, was laut Ankündigung die Abhängigkeit von jQuery entfernt, die Barrierefreiheit verbessert und viele Fehler behebt.

Manches verließ den Core. SWFUpload wurde entfernt, und Press This wanderte in ein separates Plugin. Die REST API verlangt seitdem benannte URL-Parameter in den regulären Ausdrücken der Routen, numerische Treffer funktionieren nicht mehr. Die Dokumentation vermerkt außerdem, dass Core und Unit-Test-Suite vollständig mit dem damals kommenden PHP 7.2 kompatibel waren.

#Von WordPress 4.9 zu 5.0 und Gutenberg

#Zeitleiste von WordPress 4.9 bis 6.x

2017 (4.9):

• Letzte Version mit dem klassischen Editor als Standard
• Gutenberg in Entwicklung als Plugin, die Ankündigung suchte Tester
• CodeMirror blieb aus dem Beitragseditor heraus, weil Gutenberg ihn ersetzen sollte

2018 (5.0):

• Gutenberg wurde als Standard-Editor eingeführt
• Das Classic-Editor-Plugin stand für Seiten bereit, die den alten Bildschirm behalten wollten

2019 bis 2021:

• Gutenberg reifte mit jedem Update
• Block-Patterns wurden eingeführt
• Full Site Editing (FSE) nahm Gestalt an

Ab 2022:

• Block-Themes und Website-Editor im Core
• Klassische Themes und der Customizer werden weiter unterstützt

#Classic Editor und Gutenberg nach 4.9

Nur ein Jahr nach 4.9 kam WordPress 5.0 mit Gutenberg. Die Community teilte sich in zwei Lager:

Traditionalisten:

• Blieben beim Plugin “Classic Editor”
• Nutzten weiterhin PHP-basierte Themes
• Bevorzugten Page Builder (Elementor, Divi, WPBakery)
• Das Classic-Editor-Plugin hat noch immer Millionen aktiver Installationen

Moderne Gestalter:

• Setzten auf das Modell des Full Site Editing (FSE)
• Alles, einschließlich Header und Footer, mit Blöcken gebaut
• Übernahmen Block-Themes wie Twenty Twenty-Three und Twenty Twenty-Four
• Nutzten Block-Patterns und Templates

#Welche Funktionen aus WordPress 4.9 noch relevant sind

#CodeMirror und Customizer-Entwürfe heute

CodeMirror:

• Weiterhin in den Theme- und Plugin-Dateieditoren und im Bereich Zusätzliches CSS im Einsatz
• Für Plugins weiterhin über wp_enqueue_code_editor() verfügbar

Customizer-Entwürfe:

• Weiterhin in klassischen Themes verfügbar, die den Customizer nutzen
• Die Zeitplanung hängt weiterhin an WP-Cron, der Cron-Hinweis von 2017 gilt also noch
• Block-Themes nutzen stattdessen den Website-Editor mit eigenen Revisionen und eigener Vorschau

Sicherheit im Dateieditor:

• Der Loopback-Rollback aus 4.9 ist bis heute der Grund, warum eine kaputte PHP-Änderung im Dashboard die Seite meist nicht lahmlegt
• Die Konstante DISALLOW_FILE_EDIT in der wp-config.php schaltet die Dateieditoren auf Produktion weiterhin komplett ab

#Unterschiede zwischen WordPress 4.9 und WordPress 6.x

#Wie sich die Theme-Entwicklung seit WordPress 4.9 verändert hat

Theme-Entwicklung:

• 4.9: PHP-Templates, functions.php, Hooks und Filter
• 6.x: Block-Themes, theme.json, Website-Editor

In der 4.9-Ära verlangte ein Theme gute Kenntnisse in PHP, der Template-Hierarchie von WordPress und dem Hook-System. Block-Themes werden vor allem über theme.json und HTML-Templates definiert, PHP bleibt für einzelne Funktionen.

Inhaltsbearbeitung:

• 4.9: Klassischer Editor, Shortcodes, Widgets
• 6.x: Gutenberg-Blöcke, Patterns, Templates

Anpassung:

• 4.9: Customizer, Theme-Optionen
• 6.x: Website-Editor, Block-Einstellungen

Entwicklerwerkzeuge:

• 4.9: CodeMirror, WP_DEBUG
• 6.x: Werkzeuge für die Block-Entwicklung wie @wordpress/scripts

#Ersetzte und neue Funktionen seit WordPress 4.9

Ersetzt oder optional:

• Klassischer Editor (als optionales Plugin verfügbar)
• Viele Customizer-Funktionen (in Block-Themes durch den Website-Editor ersetzt)
• Widget-Bildschirme (blockbasierte Widget-Bereiche)

Weiterhin vorhanden:

• CodeMirror in Code-Feldern
• Abgesicherte PHP-Änderungen in den Dateieditoren

Neu:

• Gutenberg-Block-Editor
• Full Site Editing
• Block-Patterns
• theme.json für die Theme-Konfiguration
• React-basierte Editor-Entwicklung

#Was Entwickler aus WordPress 4.9 lernen können

#1. Erst die Infrastruktur, dann die Oberfläche

Changesets kamen in 4.7 ohne Oberfläche, 4.9 setzte Entwürfe, Zeitplanung und Sperren darauf. Die Trennung von Speicherung und Oberfläche erlaubte es, die Funktion über zwei Releases auszuliefern, ohne bestehende Seiten zu brechen.

#2. Abwärtskompatibilität in WordPress

WordPress blieb auch bei großen Änderungen abwärtskompatibel. Das Classic-Editor-Plugin hielt alte Seiten nach 5.0 am Laufen, und die Shortcode-Unterstützung im Text-Widget machte einen Filter überflüssig, den Themes und Plugins von Hand ergänzt hatten.

#3. Sicherheitsnetze für alle, die auf Produktion bearbeiten

Der Loopback-Rollback, das Linting, das Speichern blockiert, und die Warnung in den Dateieditoren gehen davon aus, dass Menschen Live-Seiten bearbeiten. Sich darauf einzustellen, erwies sich als nützlicher, als so zu tun, als käme es nicht vor.

#Zusammenfassung von WordPress 4.9 und seinen wichtigsten Neuerungen

WordPress 4.9 “Tipton” war die letzte Version des “klassischen” WordPress vor dem Gutenberg-Editor.

Wichtigste Neuerungen:

• Entwürfe, Zeitplanung, Sperren und Vorschaulinks im Customizer
• CodeMirror mit Linting im Bereich Zusätzliches CSS, im HTML-Widget und in den Dateieditoren
• Abgesicherte PHP-Änderungen, die fatale Fehler zurückrollen
• Galerie-Widget, Shortcodes und Medien im Text-Widget
• Neue Berechtigungen und Bestätigung bei E-Mail-Änderungen

Für Entwickler:

• Lesen Sie den Field Guide zu 4.9, wenn Sie ein klassisches Theme pflegen, denn ein Großteil der Customizer- und Code-Editor-API stammt von dort
• Nutzen Sie wp_enqueue_code_editor(), statt eine eigene CodeMirror-Kopie mitzuliefern
• Richten Sie einen echten Cron ein, wenn Sie sich auf geplante Changesets verlassen