für Evy 🙂

Was ich mit PageBuildern bisher verbinde

Shortcodes statt Text, kein Zugang zum Quellcode, dafür aufgeblähtes Markup in x Ebenen mit ellenlangen Klassenbezeichnungen, redaktioneller Mehraufwand, Wartezeiten beim Laden im Dashboard, chaotisches CSS, zusammengeklatschtes Undesign, das Fehlen inhaltlicher Konzepte und Abhängigkeit sind, was mir zu PageBuildern einfällt. Es bedeutet nicht, dass wer sich mit der Materie auskennt, keine tollen Websites mit PageBuildern bauen kann (eine einwandfrei gesetzte Landingpage kann einen durchaus ein paar Stunden beschäftigen). Alleine weil man sich ein tolle Produktionsmaschine gekauft hat, besitzt man allerdings nicht automatisch auch gleich die Fähigkeit, sie vor fehlendem Hintergrundwissen gekonnt zu bedienen.

Und dann stellt sich immer noch die Frage: welche dieser Maschinen haben auf Dauer eine Zukunft mit WordPress?

Es gibt viele PageBuilder, mit unterschiedlichen Konzepten, als Plugins oder in Themes integriert, die nicht kompatibel zueinander sind. Will man wechseln oder einen loswerden, ist die ganze Website nicht selten nur noch Shortcode-Müll. Glück hat, wer nur seine Seiten mit einem PageBuilder baute, und nicht auch noch jeden einzelnen seiner 1000 Blogbeiträge.

So praktisch Shortcodes in WordPress auch sein mögen, den Haupt-Inhalt abzubilden kann ihr Zweck einfach nicht sein (noch dazu bei all den Folgewirkungen die das hat). PageBuilder für WordPress sind eben nur aufgesetzt, nicht integriert. Genau das wird sich mit Gutenberg ändern. Ich kann nicht anders, als das zu begrüßen. Und wenn es schon ein PageBuilder sein muss, dann doch wenigstens einer, an dem sich alle (künftigen) Theme- und Plugin-Entwicklungen orientieren.

Neues Design? – Kein Problem mehr

Das Wechseln eines Themes kann damit wieder so einfach sein, wie es früher einmal war, bevor die Alleskönner-Features-Tonnen damit begannen, um das Geld quellcodeunaffiner Kundschaft zu buhlen und sich dabei zu benehmen, als hätte es die Trennung zwischen Funktionalität, Inhalten und Layout nie gegeben.

Das einzige was mich an der Idee von Gutenberg stört, ist das Timing. Eigentlich hätte es ihn schon viel früher gebraucht, bevor der Wildwuchs sich ausbreitete und Millionen von Sites zu einer Bastion der Inkompatibilität machte, deren Betreiber und Entwickler nun vor Herausforderungen stehen, die sie sich verständlicherweise nicht wünschen. Entsprechend gespalten ist die Community aktuell auch. Ich frage mich, was die Webwelt 2018 am Ende mehr aufgemischt haben wird – die DSGVO oder Gutenberg?

In einer sauberen aktuellen WordPress-Umgebung ohne PageBuilder wird die Aktivierung von Gutenberg in den meisten Fällen kein Problem sein. Benutzerdefinierte Felder werden noch funktionieren, und Shortcodes ebenfalls (diese werden günstigerweise irgendwann zu Blöcken). Trotzdem vorher ein Backup der Datenbank machen. Die aktuelle Gutenberg-Version ist immer noch zum Testen und nicht für den Wirkbetrieb vorgesehen.

Nach dem Aktivieren von Gutenberg

Seit meinem ersten Test hat sich viel getan, und eine Menge Bugs sind bereits behoben. Bisher habe ich die Gutenberg auf sieben Installationen testweise aktiviert, auch mit WooCommerce (an der Bearbeitung der Produkte änderte sich damit bisher allerdings noch nichts). Bestehende Inhalte blieben zugänglich und editierbar. In Gutenberg Editor findet man Seiten- oder Beitragsinhalte in einem „Classic Editor-Block“ zusammengefasst (was im visuellen Editor nicht gleich sichtbar ist, zeigt sich dort durch einen Wechsel in den Code-Editor und wieder zurück), der wie er ist beibehalten oder in Blöcke umgewandelt werden kann.
Achtung, nach der Umwandlung ist jede Zwischenüberschrift, jedes Bild, jeder Absatz ein eigener Block, und vorher manuell eingepflegtes Markup dahin.

Für HTML-Konstruktionen die unverändert erhalten bleiben sollen, gibt es den HTML-Block (Codemirror), mit Zeilennummern und Validator.

Was früher teilweise durch Buttons initialisiert wurde (z.B. Listen oder Zitate) oder Shortcodes brauchte, kann nun ein Block sein. Übergang und Integration finde ich bisher schön gelungen, weil sich die Arbeit mit Gutenberg an das anlehnt, was einem an WordPress bereits vertraut ist. Ohne die noch nicht behobenen Bugs wäre das Arbeiten mit Gutenberg allerdings schöner. Das lässt mich an WordPress 3.0 denken – offenbar haben es die ungeraden großen Updates in sich.

Herausforderung für Entwickler

Wer übrigens seine eigenen Metaboxen nicht ans Ende der Seite verbannt sehen will, braucht einen Block dafür. Gutenberg Hooks und Filter sind allerdings nicht PHP, sondern Javascript. Für PHP-Entwickler, die mit Javascript weniger am Hut haben, bedeutet die Entwicklung von Blöcken also eine weitere neue Herausforderung.

Auch die Umsetzung von Shortcodes zahlreicher Plugins in Blöcke wird einige Zeit beanspruchen, und vielleicht werden manche auch an diesem Punkt haltmachen. Aktuell ist es schwer darüber zu befinden, worauf man bei Projekten die grade in Entwicklung sind, setzen soll (ich tendiere eher dazu, bereits das Neue einzubeziehen). WordPress 5.0 befindet sich nach wie vor im Alpha-Stadium, und der August ist bereits halb durch.

Gutenberg-Links

Combining WooCommerce & Gutenberg
Converting a shortcode to a block
The State of ACF in a Gutenberg World
Build for Gutenberg: How Plugin and Theme Authors Are Addressing the Transition to Gutenberg
How to Adapt Your Plugin for Gutenberg: Part 1 (Block API)
The Complete Anatomy Of The Gutenberg WordPress Editor
Gutenberg Hub

Fork ohne Gutenberg