Vor Kurzem habe ich zum ersten Mal einen Page-Builder für ein Kundenprojekt eingesetzt. Die Anforderungen waren relativ speziell: Innerhalb einer Multisite sollten Redakteure selbst Sites erstellen können, die jeweils aus einer Art Landingpage bestanden. Die Layouts dafür sollten variabel und weitgehend frei gestaltbar sein. 

Das ist ein ungewöhnlich langer Artikel geworden. Wer nicht alles lesen möchte, hier sind ein paar Anchorlinks zum schnelleren Durchlesen:

– Was ich mir angeschaut habe
– Das Testlayout
– Frontend-Editing, Responsiveness und WordPress-Integration
– Die Page-Builder in der Einzelbetrachtung
– WordPress und Page-Builder

Ich hatte mir zu Beginn des Projekts vier Page-Builder ausgesucht und verschiedene Szenarien durchgespielt. Ich wollte sehen, was die Redakteure machen können und ob vielleicht wichtige Funktionen fehlen.
Dabei war mir wichtig, dass auch wenig erfahrene Nutzer gut zurechtkommen und ein „Knöpfchen“ für jede Funktion vorfinden, die für die Umsetzung meines konkreten Projekts wichtig war.
Ein Beispiel: Hintergrundbilder, auf denen ein Text platziert wird, müssen immer ein bisschen abgetönt werden, damit der Text auch lesbar ist. Wer sich mit HTML und CSS zu helfen weiß oder mal eben schnell Photoshop anschmeißen kann, kriegt das natürlich hin. Aber Redakteure ohne Vorkenntnisse nicht.

Die Kandidaten

Für diesen Artikel habe ich noch zwei weitere Plugins mit aufgenommen:

  1. Tailor, das einzige mir bekannte OpenSource-Projekt unter den Page-Buildern.
  2. Visual Composer, the elephant in the room

Von allen Plugins habe ich jeweils die kostenlose Version installiert.

Zum Vergleich treten an:

Das hier ist kein systematischer Test, eher eine Stichprobe. Mein Ziel war, ein Gefühl dafür bekommen, wie es sich mit dem jeweiligen Page-Builder arbeitet.

Wer einen gründlichen und umfassenden Vergleich lesen möchte, dem empfehle ich den Artikel von Pippin Williamson (en)

Was ich mir angeschaut habe

  1. Lernkurve
    Wie schell habe ich mein Layout zusammen? Wie lange muss ich suchen und Herumprobieren bis ich da angekommen bin, wo ich hin will? Nachdem das Plugin installiert war, habe ich mit jedem Test-Layout ca. 20 bis 30 Minuten zugebracht.
  2. Nested Columns
    Mit ineinander verschachtelten Spalten bekommt man ein stabileres, sichereres Layout hin als mit locker aneinandergereihten Elementen. Für Vorlagen, die anschliessend vom Kunden bearbeitet werden sollen, ist das ein nicht unwichtiger Punkt.
  3. Buttons
    Buttons sollten sich individuell gestalten lassen und nicht auf ein vorgegebenes Design festgelegt sein.
  4. Zugriff auf WP Widgets
    Mit einigen Page-Buildern hat man keinen Zugriff auf Widgets. Gerade wenn man Plugins verwendet, spielt sich dort jedoch viel ab.
  5. WP Posts
    Mit einigen Page-Buildern hat man keinen Zugriff auf Posts.
  6. Hintergrundbilder abtönen
    Kann man auch anders lösen, ist aber im Alltag ein wichtiges Detail (s.o.)
  7. Eigenes Layout als Vorlage speichern
    Ein wichtiger Aspekt für systematisches Arbeiten: Wenn man bei jeder Seite von vorn anfangen muss bzw. die Webdesignerin ihren Kunden keine Vorlagen zur Verfügung stellen kann, fehlt etwas ganz Entscheidendes.
  8. Was passiert, wenn man das Plugin deaktiviert?
    a. Werden noch alle Inhalte im Frontend dargestellt?
    Leider kann das keines der Plugins leisten. Elemente verschwinden (z.B. Hintergrund-Bilder) und zwei Kandidaten verteilen zusätzlich den berühmt-berüchtigten Shortcode-Salat.
    b. Wie sieht der Inhalt im Editor aus?
    Einige Page-Builder produzieren ein relativ wildes Code-Chaos, andere hinterlassen den Editor hingegen sehr sauber.
SiteOriginBeaver BuilderPootle BuilderElementorTailorVisual Composer
Lernkurvesteilflachflachmittelflachsteil
Nested Columnsjaneinneinneinjanein
Button stylenneinnein (gar keine Buttons, nur Pro-Version) neinja, aber Styling erzeugt Fehler jaja
Zugriff auf WP Widgets ja janein, (Shortcodes gehen) ja janur Default Widgets
WP Posts darstellenja, aber nur Listeneinneinnein
(Pro-Version)
 janein
Hintergrund-Bilder per background-color einfärben neinjajajaneinnein
Eigenes Layout als Vorlagen speichernjein (sehr kompliziert) aber es gibt Site Packsnein (Pro-Version)nein (Pro-version)jaja?
Plugin deaktiviert:  Darstellung FrontendBackground-Bilder, Spalten und andere Inhalte (Buttons, Video) verschwinden; ShortcodesBackground-Bilder und Spalten verschwindenBackground-Bilder und Spalten verschwindenBackground-Bilder, Spalten und andere Inhalte (Buttons, Video) verschwindenBackground-Bilder und andere Inhalte verschwinden; ShortcodesBackground-Bilder und andere Inhalte verschwinden; Elemente verschoben, Shortcodes
Plugin deaktiviert:  HTML im EditorCode-Chaos; aber keine ShortcodesSehr sauberViele spans und Inline CSS;Sehr sauberHeftiges Code-Chaos; viele ShortcodesDas heftigste Code-Chaos von allen; viele Shortcodes

Das Testlayout

Ich habe mit den Page-Buildern ein einfaches Seitenlayout gebaut. Dabei habe ich auch versucht, ein WordPress Widget aus einem Plugin (Easy Forms for Mailchimp) zu integrieren und ein paar Posts darzustellen.

In den Screenshot ist links das Layout mit aktivem Page-Builder zu sehen, rechts sieht man wie das Ganze aussieht, wenn das Plugin deaktiviert ist.

Die Layouts fallen alle recht ähnlich aus, unterscheiden sich jedoch in einigen Details. Die Plugins arbeiten beispielsweise mit unterschiedlichen vordefinierten Abständen zwischen den Elementen. Das große Bild oben lässt sich nur bei BeaverBuilder so platzieren, dass es über den Layoutspiegel links und rechts hinausragt. Bei Elementor ist es mir trotz ehrlichem Bemühen nicht gelungen, den Button direkt im Text-Modul zu platzieren. Geht bestimmt irgendwie, aber nicht schnell und intuitiv.

LockedIn-Effekt

Nach dem Deaktivieren des Plugins bleibt immer Code im Editor zurück. BeaverBuilder und Elementor hinterlassen den Editor sehr sauber, SiteOrigin, Tailor und Visual Composer produzieren ein z. T. eindrucksvolles Code-Chaos. Ein derart vollgeschriebener Editor trägt zu dem berüchtigten LockedIn-Effekt bei. Wenn man mal eine Weile mit dem Page-Builder gearbeitet hat und sich nach einer Weile entscheidet, ihn doch nicht mehr zu nutzen, hat man ein Problem. Alle Seiten müssen einzeln und per Hand auf Code-Ebene überarbeitet werden.

Das trifft man im Editor an, wenn das jeweilige Plugin deaktiviert ist.

Frontend-Editing, Responsiveness und WordPress-Integration

Unterschiedliche Konzepte für das Frontend-Editing

Frontend-Editing haben alle Page-Builder, aber die Konzepte dafür variieren. Bei Elementor zum Beispiel fühlt sich jede Seite wie eine Art leerer Canvas an, auf dem man nach Herzenslust „herummalen“ kann. Am anderen Ende des Spektrums steht SiteOrigin mit seiner sehr spröden Oberfläche, die ohne WYSIWYG-Darstellung auskommt. Tailor, BeaverBuilder, Visual Composer und Pootle-Builder liegen irgendwo dazwischen.

Dabei haben nur BeaverBuilder, Elementor, Visual Composer und Pootle-Builder ein Frontend-Editing, das sich konsistent anfühlt. SiteOrigin und Tailor emulieren zwar eine Ansicht von vorn und man kann auch die Elemente anklicken und bearbeiten, aber spätestens beim Klick auf „Speichern“ findet man sich plötzlich im Backend wieder. Das ist irritierend und fühlt sich umständlich an.

Und so sehen die Ansichten für das Frontend-Editing aus.

Responsive Design

Mit der Responsiveness kommen die Page-Builder ganz gut zurecht, wobei sich alle auf ein einfaches Standardverhalten festlegen. Das heisst, sie wechseln früh in eine einspaltige Darstellung. Man kann ein paar Details einstellen, z.B. unterschiedliche Werte für Margins und Paddings für Desktop und Mobil. Meist gibt es auch eine Art „Cheat“-Funktion, über die man ein Element auf dem kleinen Screen einfach ausblenden kann.

Was responsives Verhalten angeht, kann keiner der Page-Builder Wunder bewirken. Man kommt nicht drumrum, das Layout immer wieder zu testen und nachzugucken, was denn so passiert, wenn der Bildschirm kleiner wird.
Für unerfahrene Nutzer kann das ein rechter Kampf sein. Sie können nicht einschätzen, in welcher Reihenfolge die Elemente auf kleinen Screens angeordnet werden. Was eben noch schön nah beieinander stand, wird auf dem kleinen Screen plötzlich auseinander gerissen. Das ist logisch, wenn man weiß, was im Hintergrund (Reihenfolge im HTML) passiert, aber eben nur dann.

WordPress-Integration

Eine große Herausforderung liegt in meinen Augen in der Verknüpfung eines Page-Builders mit der WordPress-Mechanik. Nicht bei allen Page-Buildern kann man beispielsweise auf WordPress-Widgets oder Posts zugreifen. Auch die Verknüpfung Theme-Customizer und Page-Builder ist häufig ein Knackpunkt: Wie geht der Page-Builder damit um, wenn z.B. Farben global über den Customizer definiert werden sollen? Das klappt leider nicht immer.

Die Page-Builder in der Einzelbetrachtung

1. Elementor

In Elementor kann man jedes individuelle Element über unzählige Optionen feintunen, aber das Arbeiten mit globalen Angaben ist schwierig. Farben im Customizer sind nur als Farbschema definierbar,  bestimmten Elementen – z.B. allen Content-Links oder allen Buttons – eine Farbe global zuzuweisen ist nicht vorgesehen. Informationen aus der Theme-Ebene (z.B. wenn die Textfarbe im Customizer festgelegt ist) werden nicht konsistent übernommen.

Bei Elementor ist es mir sehr schwer gefallen, den Überblick zu behalten. So faszinierend und vielfältig die Möglichkeiten sind, die Elementor bietet, von diesem Page-Builder habe ich mich als erstes verabschiedet. Es ist mir nicht gelungen, Elementor in eine Systematik einzubinden und beispielsweise Farben und Schriften über das Theme global zu definieren.

2. Pootle Builder

Pootle Builder war der nächste Kandidat, den ich zur Seite gelegt habe. Hier fehlte mir der Zugriff auf WordPress Widgets. Neben einigen anderen Details wie gestauchten Videos und hakeligen Buttons. Pootle Builder wirkt auf mich sehr sympathisch, aber das Plugin hat meinen Gefühl nach viele Lücken.

3. BeaverBuilder

Für das konkrete Projekt habe ich mich für BeaverBuilder entschieden. BeaverBuilder war das einzige Plugin, das alle wichtigen Features für mein Projekt mitbrachte. Allerdings musste ich in die teure Pro-Version (199$/Jahr) investieren.

BeaverBuilder ist der mächtigste Page-Builder von den Fünfen. Mir ist das eigentlich schon zu viel des Guten. Es gibt nichts, wofür es nicht ein Extra-Modul gäbe – Info-Circle, Fancy Text – you name it. Viele Module bietet BeaverBuilder selbst an, aber es gibt zahlreiche Zusatz-Anbieter, die im BeaverBuilder-Öko-System mitschwimmen.

In der kostenlosen Version kann das Plugin erstaunlich wenig. So gibt es beispielsweise kein Buttons-Modul, das kommt erst mit der Bezahl-Version (99$). Ich finde, es ist kein guter Stil, die User zu drängen, die Pro-Version zu kaufen, indem man Funktionen weglässt, die sehr häufig gebraucht werden.
Ich habe für die Buttons in meinem Demo Layout ein kostenloses AddOn namens „Ninja Beaver Lite AddOns“ installiert (von dem es selbstverständlich auch eine „Premium Version“ gibt). Hat mir für den Moment aus der Patsche geholfen. Ich finde das aber nicht ideal, denn ich möchte nicht auf AddOns aus der zweiten Reihe angewiesen sein.

4. SiteOrigin

Nachdem ich am Anfang ziemlich gefremdelt habe mit der etwas eigentümlichen Oberfläche, habe ich mich nach einer Weile ganz gut reingefunden. Auch wenn es spröde und kastelig aussieht, die Sache hat Methode. Man schiebt nicht willkürlich Elemente spazieren, sondern man baut das Layout aus Blöcken, die einem klar erkennbaren Raster folgen. Dadurch behält man besser den Überblick was man tut und klickt sich nicht so schnell ins Layout-Chaos.

Ausserdem gefällt mir die Preispolitik von SiteOrigin sehr gut. Der Page-Builder ist kostenlos, und alle wichtigen Funktionen sind mir dabei. Auch der Einsatz in einer Multisite ist kein Thema. Die Pro-Version besteht aus einer Reihe von netten Addons zu einem sehr fairen Preis (29$). Und es gibt viele, sehr schöne Themes, einige davon kostenlos.

5. Tailor

Tailor hatte ich ursprünglich nicht auf meiner Liste, für mein Projekt wäre Tailor nicht richtige Besetzung gewesen. Dann kam vor ein paar Tagen das neue Theme Pukeku von Elmastudio raus. Mit diesem Theme orientiert sich Elmastudio neu – unter anderem mit dem Page-Builder Tailor [UPDATE: Da Tailor nicht mehr weiterentwickelt wird, hat sich Elmastudio inzwischen umorientiert und setzt auf Elementor]

Beim Ausprobieren war ich positiv überrascht. Die Oberfläche ist sehr schön gemacht, bei OpenSource-Projekten ist das ja oftmals so ein Killer-Feature. Die Optik erinnert stark an den Customizer und bedient sich entsprechend vertraut.

Die Funktionalität kommt an Giganten wie BeaverBuilder oder Elementor nicht heran, aber genau das gefällt mir. Tailor fügt sich meinem Empfinden nach sehr schön in den WordPress-Workflow ein. Tailor wirkt dadurch nicht so „aufgesetzt“ und ist weit weniger dominant als die großen Mitbewerber.

Was mir nicht gefallen hat ist, dass Tailor Code-Chaos im Editor hinterlässt.

6. Visual Composer

Auch Visual Composer hatte ich ursprünglich nicht auf meiner Liste, weil ich meinen Kunden die penetrante Oberfläche nicht zumuten wollte. Und ja, Visual Composer und ich, wir werden auch jetzt keine Freunde. Mir ist das Plugin zu laut, zu voll und zu aufdringlich.

Das Plugin muss man von der Herstellerseite herunterladen, es liegt nicht im offiziellen Plugin-Verzeichnis. Nach dem Hochladen und Aktivieren werde ich erst Mal durch ein großes Overlay ausgebremst. Visual Composer verlangt eine Mailadresse und ich muss AGBs akzeptieren. Danach installiert es dann irgendwelche Module. Das Brems-Overlay erscheint übrigens jedes Mal wieder, wenn ich das Plugin aktiviere, nachdem es deaktiviert war. Ohne Mailadresse bewegt sich Visual Composer nicht. Man kann allerdings eine Phantasie-Adresse eintragen, das Plugin überprüft die Echtheit nicht.
Nachdem Installieren der Module erscheint ein neues bildschirmfüllendes Popup mit Vorschlägen, was ich jetzt machen könnte. Das empfinden sicherlich viele Menschen als hilfreich, mich hat es gestört.

Im Frontend-Editor habe ich mich nur schwer zurechtgefunden. Die UI ist in knalligen Farben gehalten, es gibt viele Bildchen und Icons, ständig öffnen sich Popups und Overlays, sobald man mit der Maus bestimmte Elemente berührt. Ich finde das anstrengend. Aber das mag anderen Leuten anders gehen.

Manche Sachen gingen sehr schnell – so gibt es beispielsweise ein Extra-Modul für das große Bild mit Text und Button oben. Und das Plugin verteilt auch gleich Beispiel-Inhalte, z.B. Texte und Bilder, so dass man gleich eine visuelle Rückmeldung bekommt.
Anderes war eher zäh. Ich konnte z.B. kein Video einbauen, auch nicht über einen embed-Shortcode. Ich hatte keinen Zugriff auf das MailChimp-Widget und es gibt auch kein Modul für Posts.
Aber es gibt zahllose AddOns für Visual Composer, auch kostenlose. Wer Zeit und Lust hat zu suchen, findet sicherlich eine Lösung.

Visual Composer hinterlässt übrigens das mit Abstand wildeste Code-Chaos im Editor.

Und, Kirsten, bist du jetzt auf den Geschmack gekommen?

Schwer zu sagen. Am Interessantesten fand ich Tailor, BeaverBuilder und SiteOrigin. Wobei ich mir Tailor erst Mal noch näher anschauen möchte [UPDATE: Tailor wird derzeit nicht mehr weiterentwickelt. Wir warten auf Gutenberg. Danke Christopher für den Hinweis]. Bei BeaverBuilder stört mich die Lizenzpolitik.
Am Sympathischsten ist mir momentan SiteOrigin. Allerdings landet auch hier viel Code-Müll im Editor und das Frontend-Editing-Feeling ist sozusagen nicht vorhanden.

Ich bin unentschlossen.

WordPress und Page-Builder

Bei Sites, die viel Content bewegen müssen und dabei heftig die WordPress-Maschinerie mit Posts, Custom Post Types, Archives etc. bemühen, sehe ich Page-Builder nicht als Idealbesetzung.

Page-Builder arbeiten (noch) außerhalb der WordPress-Systematik und das finde ich problematisch. Die Idee ist ja, dass sich die Kunden ganz auf die Arbeit mit ihren Inhalten konzentrieren sollen. Die Inhalte kommen in den Editor, das Design ist Aufgabe des Themes. Ist das Theme gut durchdacht, sehen die Inhalte in allen Darreichungsformen, die WordPress anbietet – Einzelansicht, Widgets, Startseite, Archive usw. – immer gut aus.
Wenn ein Redakteur plötzlich in das Layout eingreifen kann, gerät dieses Prinzip ins Wanken. Mal ganz abgesehen von der Designqualität – wie vermittle ich einem Kunden, dass er an der einen Stelle (= Seite mit Page-Builder) die Elemente per Frontend-Editing nach Belieben herumschubsen kann und an der anderen Stelle (z.B. category archive) rein gar nichts anfassen kann, weil das Layout im Template feststeckt? Schwierig.

Andererseits …

Große Projekte mit viel Content sind das eine, aber die vielen kleinen Seiten sind ja auch noch da. Ich vermute, sie machen den Löwenanteil aller WordPress-Installationen da draußen aus.

Der Standard-Editor bietet für solche Projekte definitiv zu wenig Möglichkeiten. Die Entwicklung muss in Richtung Editor-Erweiterung und Frontend-Editing gehen. Wer weiß, vielleicht bringt Gutenberg eine gute Lösung. Aber noch kann ich nicht erkennen, wo die Reise hingeht.