In den letzten Jahren erfreut sich die Pagebuilder genannte Klasse von Plugins großer Beliebtheit. Sie erweitern oder ersetzen den WordPress-Editor und erlauben es, komplexere Layouts (meist) ohne das Schreiben von Code zu erstellen.
Doch wann ist der Nutzen, den wir aus dem Einsatz dieser ressourcenhungrigen Plugins ziehen, es wert, unser Projekt mit großer technischer Schuld zu beladen?
Vorab
Ich werde mich in den folgenden Punkten ausschließlich auf technische Punkte beschränken. Ein „Ich mag diesen Pagebuilder!“ oder „Der Kunde will das!“ sind Argumente, die sich erfahrungsgemäß nicht rational angehen lassen. Das verbleibende, ultimative Argument ist dann natürlich „Das Geld reicht für keine andere Lösung.“ Während das auf Multipurpose-Themes zutreffen mag, ist es kein Freifahrtschein für den Einsatz von Pagebuildern. Werfen wir also einen Blick auf die verschiedenen Szenarien:
🚫 Wenige/keine Seiten, viele Blog-Beiträge
Die meisten Pagebuilder finden für Beiträge in WordPress keine Verwendung. Artikel kommen in der Regel mit deutlich weniger Struktur aus und bestehen eher aus einfachen Inhalten wie Texten und Bildern.
In diesem Fall dürfte sich der Einsatz eines Pagebuilders also vermeiden lassen, kommt er für die meisten Inhalte der Seite doch sowieso nicht infrage.
🚫 Einfach strukturierte Seiten
Auch wenn Pagebuilder sich hervorragend zum Aufbau einfach strukturierter Seiten einsetzen lassen, so kommen wir in den meisten Fällen doch ganz gut ohne sie aus. Denn einen einfachen Seitenaufbau beherrscht der Standard-Editor auch.
Geht der Seitenaufbau in einigen Punkten dennoch etwas über das hinaus, was WordPress von Haus aus mitbringt, können Shortcodes eine gute Alternative darstellen. Sie eigenen sich hervorragend für den Einsatz von Buttons und können in gewissem Rahmen sogar auch zum Aufteilen des Inhalts in Spalten verwendet werden.
✅/🚫 Viele identische, komplexe Seiten
Nehmen wir uns hier ein Beispiel: wir wollen mehrere Gruppen – WordPress-Meetups – vorstellen. Die Seiten haben immer denselben Aufbau: Seitenleiste, Logo, ein kurzer Text und vielleicht ein wenig zusätzliche Information.
Hier könnte ein Pagebuilder sicherlich glänzen, auf den ersten Blick zumindest. Wer sich ein wenig mit den Seiten-Templates von WordPress-Themes auskennt, wird aber auch damit zu einem ähnlichen Ergebnis kommen. Der Vorteil an dieser Template-Lösung ohne Pagebuilder ist, dass sie sich nachträglich einfacher global für alle entsprechenden Seiten anpassen lässt, bei den meisten in Pagebuildern gebauten Templates ist das nicht der Fall, hier müssen Änderung oft auf jeder Seite individuell vorgenommen werden.
Die wichtige Voraussetzung an dieser Stelle ist jedoch ein Grundverständnis von HTML und PHP. Wer darüber nicht verfügt und das Geld für die entsprechende Entwicklungsleistung nicht zahlen kann oder will, wird mit einem Pagebuilder zumindest optisch vergleichbare Ergebnisse erzielen.
✅ Viele unterschiedliche, komplexe Seiten
Viele Seiten mit unterschiedlichem Aufbau sind für WordPress mit Bordmittlen fast nicht zu bewältigen. Wenn es sich um ein eigenes Theme und zumindest um mehrere fest definierte Seitenlayouts handelt, könnte auch das theoretisch von Seiten-Templates abgefangen werden. Gehen wir aber von einem Beispiel aus, in dem jede Seite einen individuellen Aufbau hat, so führt am Einsatz eines Pagebuilders aktuell kein Weg vorbei.
🚫 Die Seite soll in der zweiten Jahreshälfte 2018 online gehen?
Aktuell ist es noch etwas schwer, definitive Aussagen zu treffen, aber die Weiterentwicklung des WordPress-Editors im Rahmen des Gutenberg-Projekts schreitet unaufhaltsam voran und wird den Pagebuilder-Markt ordentlich durchschütteln. Wenn nicht unbedingt nötig, sollte für Seiten, die in der zweiten Jahreshälfte fertig werden erstmal noch kein Auswahl getroffen werden – der WordPress-Core könnte schließlich schon alles benötigte mitbringen.
Nachwort für WordPress-Dienstleister
Egal ob wir uns EntwicklerInnen, ProjektmanagerInnen oder ImplementorInnen nennen, wir haben eine Verantwortung unseren Kunden gegenüber. In vielen Situationen fehlt ihnen die Erfahrung, unsere Entscheidungen fachlich zu hinterfragen. Daher ist es unsere Aufgabe, sie nach bestem Wissen und Gewissen zu beraten. Dabei ist es ebenso falsch, grundsätzlich von Pagebuilder abzuraten, wie es falsch ist, sie für jedes Problem als Lösung zu präsentieren.
Der Kunde hat Anforderungen, die ihr allein (ohne Pagebuilder) nicht bedienen könnt? Sucht euch Partner, bildet Netzwerke, geht auf Meetups. Euch fehlt eine bestimmte Fähigkeit? Lernt. Wir leben im Jahr 2017, alles was ihr über das Internet wissen müsst, findet ihr im Internet selbst.
Nachwort für Auftraggeber/Kunden
Nicht alle Dienstleister sind gleich. Wenn ihr ein Projekt zu vergeben habt, lohnt es sich bei der Suche nach einem Dienstleister gezielt nach der eingesetzten Technik zu fragen. „Nutzten Sie Pagebuilder?“ Wenn ja: „Kann ich diesen Pagebuilder weiter nutzen, wenn ich das Theme wechsele?“ Besonders letzteres ist oft die Gretchenfrage, denn neben allen Argumenten für oder gegen Pagebuilder: sie sollten niemals vom Theme abhängen oder in diesem eingebaut sein, denn das macht einen Wechsel in der Zukunft praktisch unmöglich.
Möchte der Dienstleister einen Pagebuilder einsetzen, lohnt sich die Frage nach den Gründen. Gibt es eine Anforderung, die sich vielleicht nur so umsetzen lässt? Und wenn es wirklich nur eine ist: lässt sich das Website-Konzept vielleicht so umstellen, dass die Site ohne Pagebuilder auskommt?
Lasst euch außerdem vorab die Oberfläche des Pagebuilders vorführen, könnt ihr damit arbeiten und selbst Inhalte pflegen? Genau das ist einer der großen Vorteile an einem Content Management System wie WordPress und wir sollten diese Aufgabe nicht leichtfertig in die Hände der Dienstleister delegieren – wenngleich es auch dafür gute Gründe geben kann.
Ich hab im letzten Jahr bei Agenturen mitgeholfen, die im Rahmen einer Angebotsaktion viele angestaubte Sites auf einen modernen Stand gebracht haben.
Aus der daraus gewonnenen Erfahrung von ca 40 Projekten kann ich o.g. Einsatzempfehlungen nur in vollem Umfang bestätigen.
Nur ein paar Anmerkungen:
„ressourcenhungrig“: Kann ich für die bei uns meist gewählte Theme/Pagebuilder-Kombination (GeneratePress/Elementor) nicht bestätigen. Performance war da nie ein Thema.
„Themeauswahl“: Klar, dass überladene Kaufthemes tabu sind, Themes wie GeneratePress / OceanWP / Astra sind schlank, fast beliebig anpassbar, für PageBuilder vorbereitet und m.E. eine sehr gute Wahl.
„Viele unterschiedliche, komplexe Seiten“: Da gibts durchaus Erweiterungen, die es erlauben, ein Pagebuilder-Template auf alle/ausgewählte Einträge eines Typs anzuwenden und somit auch nachträglich zentral zu ändern.
„Agentur/Dienstleister“: Aus Agentursicht war es m.E. ein Erfolgsfaktor, sich auf wenige, aber solide und flexible Produkte zu beschränken und darin ein tiefes Know-How incl. wiederverwendbarer Lösungsansätze/Code-Snippets/CSS-Code aufzubauen. Auch Pagebuilder-Vorlagen oder eigene Elemente.
„Kunde und Pagebuilder“: Reicht von Leuten, die sich Seiten bauen, dass man nur staunen kann, bis zu Menschen, die das garnicht anfassen wollen. Die konnten wir über eine Lösung mit ACF-Feldern, die in das Pagebuilder-Template gezogen werden abholen.
„Agentur und Codierer“: Eine Agentur muss sich überlegen, welche Skills sie vorhalten / zukaufen will und welche nicht. Da ist es oft durchaus erklärtes Ziel, sich von codierenden Menschen möglichst unabhängig zu machen (Verfügbarkeit, Preise, Verständigungsprobleme). Also keine selbstprogrammierten Themes, und keine handgeklöppelten komplexen Layouts.
Der Entwickler im Vorruhestand hat dann Zeit, viel zu lange Blog-Kommentare zu schreiben.
In einem Punkt möchte ich ganz ausdrücklich widersprechen:
Ein sauber programmiertes Theme kann von anderen Entwicklerinnen und Entwicklern ohne große Schmerzen übernommen werden. Und sauberes CSS/SASS würde ich einem der großen Frameworks in den meisten Fällen vorziehen.
Das regt in mir den Widerspruch ?.
Wir kommen an einen Punkt (oder haben ihn möglicherweise auch schon erreicht), den ich bislang nur aus Typo3 Projekten kannte: Der Streit unter Entwicklern was den „sauber programmiert“ ist.
Es gibt sehr viele Wege die zum Ziel führen. Jeder für sich ist nachvollziehbar sowohl im Sinne von logisch wie auch dokumentiert und regelkonform. Aber oft genug kommt bei der Migration von Projekten das „Argument“: ‚…bevor ich mich in den Code des Kollegen rein gefuchst habe, hab‘ ich das gleich neu gemacht …‘
An der Stelle kein Vor- oder Nachteil gegenüber PageBuildern. Da kommt das ‚… um Gottes Willen, lass uns das neu machen … ‚ nur etwas reflexhafter und sicher oftmals auch berechtigter ?
Moin Stefan,
interessantes Argument. Mag man nicht gern hören, aber faktisch ist da was dran. Wobei da zwei Szenarien drinstecken. Einmal der Fall, das jemand eine Site übernimmt, die handwerklich zwar gut gemacht ist, aber der Übernehmende hat weniger Wissen als sein Vorgänger und kommt mit dem vielen Codekram nicht zurecht. Und einmal der umgekehrte Fall, jemand mit übernimmt eine handwerklich schlecht gemachte Site.
Das würde ja eigentlich bedeuten, dass auch hier die Page Builder einen Vorteil hätten. Zumindest im ersten Fall käme auch der unerfahrene Mensch besser klar, wenn das Layout schön sichtbar und greifbar im PageBuilder steckt und nicht in Page-Templates und Functions versteckt ist. Im zweiten wäre es wurscht, da muss man tatsächlich neu ansetzen.
Ich denke auch an das, was der Kollege oben gesagt hat. Dass Agenturen sich das Coding-Kowhow einkaufen und dann ist der Entwickler irgenwann weg oder zu teuer und sie sitzen blöd da.
Hm.
Egal wie man’s dreht und wendet, es ist höchste Zeit, dass sich der WordPress Core weiter bewegt. Die Situation so wie sie ist, ist nicht gut.
*schickt gutes Karma zu Gutenberg*
Kirsten
Sehr guter differnzierter Artikel zum Thema Pagebuilder. Weiter so 🙂