Visuelle Editoren und PageBuilder, und warum es für mich nur Gutenberg geben kann

Meine ersten HTML-Schritte machte ich mit Tools wie Frontpage und Frontpage-Express oder Dreamweaver, mit dem ich nicht gerne arbeitete. Von der Umsetzung in der visuellen Ansicht kam ich damals sehr schnell ab. Nicht nur, dass viel zu viel Quellcode generiert wurde, sondern dieser war auch noch fehlerhaft / nicht valide. Frontpage genoss diesbezüglich nicht von ungefähr einen schlechten Ruf. .

Also suchte und fand ich mein Heil in Texteditoren und schrieb HTML-Seiten weiterhin komplett selbst. Nicht lange, und die Entwicklung dynamischer Websites mit ASP, .NET und schließlich PHP folgte. Hierfür waren Texteditoren auch nützlich. Die Kontrolle erfolgte umgehend im Browser. Designs gestaltete ich immer direkt in HTML und CSS. Daneben setzte ich um, was an grafischen Vorlagen vom Designer kam.

Mit CMS wie Drupal und WordPress galt ohnedies die Trennung zwischen Funktionalität, Design und Inhalt. Auch hier bevorzugte ich beim Schreiben von Inhalten die reine Textansicht und schrieb Tags ggf. aus. Das Tab für visuelles Editieren in WordPress existierte für mich praktisch nicht.

Externe PageBuilder erfüllten Erfordernisse

Mittlerweile arbeiten Designer und Agenturen vielfach auch ohne Umwege über PDF-Vorlagen, AI- oder PSD-Dateien zu schicken mit PageBuildern. Es war eben so. Um in WordPress eine Landingpage zu bauen, ohne programmieren zu müssen, kam man um einen PageBuilder nicht herum.

Ich baute lieber Templates, denn ich fand die Arbeit mit PageBuildern mühsam und teilweise zu kompliziert, da man über einzeln formatierte Elemente nun mal keine globale Kontrolle hat, mit der man schnell Anpassungen des Designs der ganzen Website vornehmen kann.

Der beliebte Divi-Builder, der in meinen Augen einfach nur mords Popanz um enttäuschend wenig Funktionalität bietet, zwang so manches Shared Hosting in die Knie (und speicherte dann keine Änderungen mehr). Visual Bakery sprach mich auch nicht besonders an, mit dem hatte ich allerdings nur ein Mal zu tun. Elementor? – Wenn, dann hätte ich am ehesten noch den empfohlen. Jedenfalls ist er leistungsfähiger als Divi und zeitgemäßer als Visual Bakery. Und wer damit arbeitet, kann dies auch weiterhin machen.

Elementor vs Gutenberg

Elementor generiert geschätzt 3 mal so viel Quellcode. Bei der Analyse einzelner Elemente muss man sich durch viele Verschachtelungen arbeiten, was die Suche nach Ursachen für etwaige Darstellungsfehler sehr mühsam macht.

Gutenberg ist schlanker und performanter als Elementor, und kostenfreier Teil von WordPress selbst. Wer hier grade vor der Entscheidung steht, dem würde ich Gutenberg ans Herz legen, zumal die nächsten WordPress-Versionen noch stärker darauf (auf)bauen. Auch die vorgesehene Unterstützung von Mehrsprachigkeit ist Bestandteil der Gutenberg-Roadmap.

Was man bei Gutenberg allerdings vielleicht doch einkalkulieren muss (nicht zwingend in Geld), sind zusätzliche Blöcke. Und da man Plugins, deren Blöcke man verwendete nicht einfach wieder rauswerfen kann, sollte man sich für einen Anbieter entscheiden, der sich auf dem Gebiet bereits bewährte.

Ein Pagebuilder ersetzt kein inhaltliches Konzept

Die beliebte Werbe-Aussage „bauen sie Ihre Website, ohne eine Zeile Code schreiben zu müssen“ wird nicht selten so interpretiert, als müsste wenig bis keine Ahnung von der Materie vorliegen, um eine tolle Website bauen zu können. Sebst der beste Pagebuilder kann inhaltliches Konzept und die Fähigkeit die Elemente in schlüssigen Strukturen anzulegen nicht ersetzen.

Mancher Builder kann wohl die Grundstruktur für den Site-Aufbau liefern (mit so genannten Starter-Templates, wenn man grade eins findet, das zum eigenen Angebot passt), und der Anwender kann dann Bilder und Texte durch eigene ersetzen (habe diese Praxis auch bei Agenturen gesehen). Doch wer dann vielleicht doch den einen Abschnitt weg- oder dazuhaben will oder Fehler bei der Anpassung macht, steht damit womöglich schon vor einer unüberwindbaren Herausforderung oder muss mit Darstellungsfehlern leben.

Auch bei einem PageBuilder sollte man vorher genau wissen was man will und tut, und dann mit den verabschiedeten Werten arbeiten: Farben, Innen- und Außenabstände, Schriftgrößen etc. -. Sind erstmal 10 oder mehr womöglich komplexe Seiten gesetzt, ist der Aufwand nachträglich noch was am Design zu ändern entsprechend hoch. Eine mit Pagebuilder sorgfältig gesetzte umfangreiche Landingpage (gar noch nach einer Designvorlage) kann einen mehrere Stunden lang beschäftigen, bis jedes Pixel auf allen Bildschirmgrößen sitzt.

Das Schlimmste finde ich allerdings was passiert, wenn man sich besinnt und einen anderen PageBuilder oder keinen mehr verwenden möchte. – Die Inhalte sind dann nicht mehr zu gebrauchen (im Fall von Elementor bleibt wohl das HTML erhalten, schön ist allerdings was anderes) oder müssen manuell migriert werden.

Kein Geheimnis, ich mag keine PageBuilder

Auf Classicpress umzusteigen war für mich keine Option, schließlich betreue ich WordPress-Kunden. Was mir an Gutenberg hingegen gefiel und mich daher positiv einstimmte war, dass der Wildwuchs endlich ein Ende finden konnte, und sich fortan alle Entwickler nur noch oder zumindest auch an Gutenberg orientieren mussten.

Doch auch wenn es noch Zugriff auf den Texteditor gibt, es ist einfach undenkbar, Inhalte weiterhin wie bisher in diesem Modus zu schreiben. Erstmals seit Frontpage-Zeiten bin ich tatsächlich wieder in der Situation, mit einem visuellen Editor umzugehen. Wer WordPress will, lernt besser früher als später, damit umzugehen.

In meinem Beiträgen kommen nur Absätze, Zwischenüberschriften, Bilder und Codeblöcke vor, und manchmal eine Liste. – So konnte ich mich von Anfang an und in kleinen Dosen an Gutenberg gewöhnen. Mittlerweile habe ich mich mit dem neuen Editor in WordPress angefreundet und arbeite gerne damit.

Gutenberg ist die Zukunft von WordPress.

Daran hat sein Gründungsvater von Anfang an keine Zweifel gelassen. Noch ist die Transformation von WordPress in ein Block-System nicht abgeschlossen. Bald werden auch Header, Footer und ggf. Sidebars aus Blöcken bestehen. Der Anwender wird nahezu völlig die Kontrolle über das Design haben, ohne seine WordPress-Installation verlassen zu müssen. Dieser User (in dem Fall ich) hat das neulich in einem Testprojekt ausprobiert und ist von dieser neuen Form mit WordPress zu arbeiten durchaus angetan.

Nervige total überladene multipurpose Themes mit Plugin-Nachinstallationen wie bei Avada oder Themes mit selbst gestrickten PageBuildern gehören zum alten Eisen. Projekte wie GeneratePress (nicht mal so neu, doch hat es die Kurve super genommen), Kadence, PageBuilderFramework, Neve, die neuen Original-WordPress-Themes und ähnliche sind (wie) geschaffen für die Arbeit mit Gutenberg. Dazu gibt es von den Anbietern dann meist auch gleich eine ganze Garnitur mit nützlichen Gutenberg-Blöcken.

Wer bereits ausprobieren möchte, wie sich Full Site Editing anfühlen wird, hat dazu bereits mehrfach die Gelegenheit mit Q, TT1 Blocks oder Phoenix, für Entwickler ist vielleicht das WordPress Theme Experiments Projekt auf github interessant.