#045: Grenzen und Möglichkeiten von WordPress (Story von busfinder.com) | m. Christoph Berdenich

Wie wirkt sich das überhaupt aus? Wie merkt man, dass man an die Grenzen von WordPress überhaupt stoßt? Ich glaube, da gibt es auch wieder verschiedene Ebenen, wie man das merken kann.

Das erste ist sicher die Unübersichtlichkeit.

Merkt man glaube ich am besten daran, dass man, wenn man in die Webseite reinsteigt, schon ein schlechtes Gefühl hat, Sachen selber nicht findet.

Es unübersichtlich wird.

Zweites, wo man es merkt, ist Speed from the backend.

Das heißt, wenn man eingeloggt ist ohne Cache, merkt man relativ schnell, wann die Seite beginnt langsam zu werden.

Und woran man es auch erfahrungsgemäß merkt, ist, wenn man einfach das eigene Backlog füllt mit Tasks, mit Fehlern, wo man jetzt nicht genau weiß, wo kommt das her? Die sind schlecht reproduzierbar.

Hallo und herzlich willkommen bei der 45. Episode der Dominik Liss Show.

Auf diesem Podcast gibt es WordPress und Business Talks.

Das heißt, wenn du WordPress in deinem Business verwendest, dann bist du hier genau richtig.

Weil jede Woche entpacken wir die Skills, Storys und Geheimnisse der besten Experten aus der WordPress-Branche.

Und das Ziel des Podcasts ist es, dir dabei zu helfen, ein besserer Professionell in der WordPress -Welt zu werden.

Und heute unterhalten wir uns über die Grenzen von WordPress.

Und da bin ich schon sehr gespannt, weil über diese Themen kann man nicht mit jeder Person sprechen.

Weil dazu gehört dann noch eine Menge Erfahrung, die man haben sollte, um ein bisschen so die Grenzen von WordPress kennen zu lernen.

Deswegen bin ich froh, dass wir heute mit Christoph Berdenich darüber sprechen werden.

Und zwar werden wir das Ganze von der technischen Perspektive ein bisschen so betrachten.

Also was sind so die technischen Grenzen von WordPress? Sowohl bei kleinen Projekten, aber wir werden uns dann hauptsächlich auf die größeren und komplexen Projekte in WordPress fokussieren.

Und Christoph ist CEO von busfinder und Rechnerherz.

Und Rechnerherz, das ist eine Full-Service -Webagentur.

Und busfinder, ja, da wird er euch gleich davon berichten.

Aber im Großen und Ganzen hilft die busfinder, einen Bus zu finden.

Was das genau heißt, da wird euch da Christoph gleich mehr darüber berichten.

Und in der ganzen Branche ist er schon seit über zehn Jahren.

Also da hat er schon einiges an Erfahrung gesammelt.

Und zusätzlich ist Christoph Lehrender an der Uni Wien.

Und seine Lehrveranstaltung ist Mensch-Computer -Interaktion.

Also da bin ich schon sehr gespannt, Christoph.

Herzlich Willkommen.

Könntest du dich bitte auch kurz selbst vorstellen, damit dich die Zuschauer und Zuschauerinnen ein bisschen besser kennenlernen können? Ja, hi Dominik, liebe Zuhörerinnen, liebe Zuhörer.

Mein Name ist Christoph Berdenich.

Ich darf mich vorweg sehr herzlich bei dir für die Einladung zu deinem Podcast bedanken.

Vielleicht ein paar Worte, wo ich sozusagen herkomme.

Ich glaube, ich habe den nicht so untypischen Weg in der WordPress-Welt gewählt.

Ich bin eigentlich gelernter Entwickler.

Und über die Jahre hinweg schaut man da über den Tellerrand der Entwicklung hinaus.

Und da gibt es ja irrsinnig viel in der Digitalbranche zu sehen.

Vom Design über das ganze Business.

Und so hat es sich eben nicht vorgeplant ergeben, dass ich eine eigene Agentur gegründet habe.

Das ist eben Rechnerherz.

Mit Rechnerherz sind wir seit sieben, acht Jahren im Digitalmarkt unterwegs.

Hauptsächlich mit WordPress.

Und weil eine Werbeagentur natürlich alleine zu wenig Arbeit ist, wie die Zuhörerinnen wissen, habe ich ja Startups gegründet nebenbei.

Und das aktuelle Startup, wo wir uns aber jetzt auch schon jahrelang damit beschäftigen, ist eben busfinder.

com.

Und auf busfinder kann man seinen Reisebus buchen.

Das klingt vielleicht in erster Linie nicht ganz so spannend, weil es sehr wenige mit Bussen oder Reisebussen zu tun haben.

Aber es ist eine Branche, die sehr wenig digitalisiert ist.

Wir sind ein europäischer Marktführer.

Diese Worte kann man vielleicht auch nicht über jedes Projekt verlieren.

Und deswegen macht es irrsinnig Spaß, in dieser Branche ein klassisches Digitalisierungs-Innovationsprojekt als Mitgründer und jetzt Geschäftsführer zu begleiten.

An der Universität Wien habe ich die Ehre, einen Teil der Vorlesung Mensch-Computer-Interaktion zu begleiten.

Das ist eine sehr spannende Lehrveranstaltung im Rahmen des Informatikstudiums.

Da geht es hauptsächlich um User-Interaction, User-Experience.

Es ist eine sehr designorientierte Vorlesung.

Und was cool ist, dass die Studierenden im Laufe des Semesters eine App entwickeln müssen in vier Teams.

Und die gehen wir von den ersten Schritten, Low-Fidelity-Prototypen bis hin zum Ergebnis, was dann am Smartphone eine ausführbare App sein soll, über ein ganzes Semester begleiten, wo man, ja, das macht einfach irrsinnig viel Spaß und man kann da aus der Praxis sehr viel mitnehmen und gleichzeitig kriegt man von den Studierenden, die sind doch einiges jünger mittlerweile als ich, sehr viel zurück.

Sehr cool.

Das merkt man gar nicht, den Altersunterschied, das bildest du nicht nur an.

Ja, sehr freundlich, Dominik.

Bezüglich WordPress, weil auf dem Podcast geht es ja hauptsächlich um WordPress und wir werden uns jetzt mit den Grenzen von WordPress beschäftigen.

Beziehungsweise werden wir uns darüber unterhalten.

Und was hat jetzt Rechnerherz und Pathfinder und alles, was du so machst, eigentlich mit WordPress zu tun? Ich darf vielleicht wieder mit einer Geschichte beginnen.

Auf einem WordPress-Podcast das Wort Joomla zu verwenden, ist vielleicht ein bisschen eine blasphemische Angelegenheit, aber anyway, ich habe sehr früh beim Programmieren gemerkt, dass man mit Frameworks oder dass es auf der Welt sehr, sehr viele gute Programmierer gibt und man nicht alles from scratch selber machen muss.

Und eines der ersten größeren Projekte habe ich tatsächlich in Joomla realisiert.

Das war damals vor 14, 15 Jahren.

Und da bin ich drauf gekommen, wie cool das eigentlich ist, wenn man so ein Framework kriegt, das einem sehr viele Dinge abnimmt.

Und Joomla hat mir absolut nicht gedaugt und innerhalb von ein paar Jahren bin ich komplett auf WordPress umgeswitcht und seit es Rechnerherz gibt, machen wir alle Webseiten mit WordPress.

Das machen wir einfach, weil WordPress für uns das flexibelste Content-Management-System ist.

Das brauche ich auf dem Podcast fast nicht erzählen, aber es ist natürlich Marktführer in CMS-Systemen.

Über jede vierte Webseite, von allen Webseiten verwendet WordPress.

Es gibt irrsinnig viele coole Plugins, irrsinnig viele Leute in der Community, die es verwenden, die es weiter betreiben.

Der Gedanke von WordPress gefällt mir und so ist eigentlich das entstanden, dass wir fast zu 100% WordPress verwenden.

Und was hat das Ganze mit Pathfinder zu tun? Pathfinder war in der ersten Version eigentlich eine komplett custom entwickelte Applikation, also eine React-Applikation mit einem riesigen Backend hinten nach.

Und das hat da eigentlich ganz gut funktioniert, sogar in Richtung CEO und Performance war es gar nicht so schlecht.

Es hat aber irrsinnig viele Nachteile gehabt in der Wartung und Pflege.

Wir haben alle Funktionen, also CMS vor allem in der Präsentation gegenüber von dem User selbst programmieren müssen.

Wir haben fast keine CMS-Funktionalität im Hintergrund gehabt und jedes zusätzliche Feature für den Kunden war irrsinnig viel Aufwand.

Da geht es jetzt nicht um den Buchungsprozess, sage ich nachher ein paar Worte dazu.

Der ist auch jetzt immer noch eine JavaScript -App, aber um das Ganze, wie hole ich den User ab, braucht Landingpages für bestimmte Zielgruppen.

Ich möchte irgendwelche Ausflugsziele präsentieren zum Beispiel, da stehe ich sehr, sehr schnell an oder es ist halt irrsinnig viel Aufwand, solche Dinge selbst zu coden.

Und deswegen haben wir uns im Rahmen des Relaunch von Pathfinder.

com dazu entschlossen, vor der ganzen Buchungs-App, nenne ich es mal, also wo man tatsächlich seinen Bus buchen kann, ein großes WordPress-Projekt zu setzen.

Also wenn man auf Pathfinder.

com geht, das Erste, was da lädt und alle Seiten, ist eine ganz normale WordPress-Webseite, die wir da davor gebaut haben.

Ohne Erfahrung kann man da, glaube ich, nicht über die Grenzen von WordPress sprechen, sonst wäre das alles so theoretisch.

Und bevor wir dann aber konkret dann ins Thema eintauchen, ist, finde ich, dann noch eine Sache wichtig, die wir davor noch definieren sollten, und zwar die Arten von WordPress-Projekten.

Weil, sagen wir jetzt mal, okay, ich bin ein Webdesigner, ich erstelle Webseiten für Kunden, baue die mit Elementor und erstelle zum Beispiel hauptsächlich, keine Ahnung, Webseiten für Immobilienprojekte.

Und das ist jetzt zum Beispiel eine Art von Projekt, die ich, ich sage jetzt mal, in die simpelste Form von WordPress-Projekten einstufen würde.

Also zum Beispiel jetzt wirklich Visitenkarten als Webseiten zu bauen mit Hilfe von WordPress oder dann auch komplexere Webseiten, also alles, was in die Kategorie Webseite fällt, also das, wofür WordPress eigentlich gedacht war.

Und dann gibt es auch noch weitere Stufen, wie man WordPress verwenden kann.

Also man kann dann zum Beispiel Teile customisen, man kann das komplette System custom schreiben mit einem custom Theme oder man kann das dann auch zum Beispiel, wie ihr das bei busfinder gemacht habt, ist, dass es halt ein Teil vom gesamten System ist, das, so genau weiß ich das nicht, wie ihr das dann umgesetzt habt oder welcher Teil von WordPress ihr dann für busfinder verwendet habt, aber was man zum Beispiel auch machen kann, wo es so diesen Begriff gibt, Headless CMS, dass man WordPress einfach als Backend verwendet, als Backend-Lösung und im Frontend über die REST-API kommuniziert das dann mit einer JavaScript-Applikation auf Basis von React zum Beispiel, damit dann die Redakteure eine angenehme Art haben, den Content zu bearbeiten und zu erstellen, ohne jetzt wirklich von Scratch ein eigenes CMS zu bauen für die Applikation.

Und wie siehst du das alles? Also wie würdest du WordPress-Projekte kategorisieren und welche Arten von Projekten würden da jeweils in die Kategorien dann reinfallen? Ja, das ist eigentlich schon eine recht gute Unterteilung oder Definition vorweg.

Ich glaube, wir oder in meiner Welt werden wir uns bald an die 100 WordPress-Projekte nähern, die Rechnerherz in den letzten Jahren abgewickelt hat und da war eigentlich von A bis Z, was du ausgezählt hast, alles dabei.

Kurze Werbepause in einer Sache und zwar geht es um die WordPress-Community-Gruppe.

Diese haben wir schon vor ein paar Monaten gestartet und wir werden immer mehr und mehr Leute.

Und in dieser Community-Gruppe, da bekommst du Antworten auf deine WordPress -Fragen, du bekommst konstruktives Feedback zu deinen WordPress-Projekten und es gibt zweimal im Monat eine WordPress-Sprechstunde und dort können wir dein Anliegen noch gerne persönlich besprechen und den Link dazu findest du unten in der Beschreibung.

Das heißt, schau vorbei, die Community-Gruppe ist komplett kostenlos und jetzt geht es weiter mit dem Video.

WordPress ganz ursprünglich war ja oder ist ein Blog-System.

Auch das haben wir gemacht, dass man es als reines Blog-System verwendet.

Dazu zähle ich auch so Visitenkarten, Webseiten, das ist nicht derselbe Anwendungsfall, aber vom Setting und vom Aufbau her als WordPress -Projekt fällt es für mich in eine sehr ähnliche Kategorie.

Für diese zwei Dinge kann ich WordPress fast out of the box verwenden.

Ein bisschen Speed, ein bisschen Design, ein bisschen Sicherheit dazu und dann gibt mir eigentlich WordPress alles, was ich für Visitenkarten, Webseiten oder einen kleinen oder auch großen Blog benötige.

Das hat es ja mit dem Gutenberg meiner Meinung nach, kann man diskutieren, ist kontrovers, verbessert, das heißt, eigentlich braucht man nicht einmal mehr ein Page-Builder oder vielleicht streichst du es auch raus, Dominik, oder du lässt es drinnen.

Kann man natürlich diskutieren, aber ganz grundsätzlich haben wir auch einen riesen Reiseblog, der tatsächlich ausschließlich mit Gutenberg arbeitet und das ist eine der meistbesuchtesten Seiten, die wir überhaupt betreuen.

Also auch das funktioniert.

Das wäre die erste Kategorie für mich, so Visitenkarten, Webseiten, also Präsentationswebseiten ohne Schnickschnack, ein, zwei, drei Subseiten, Kontakt und fertig.

Das zweite wäre die klassischen Webseiten-Projekte für mich, sagen wir mal Unternehmenspräsentationen, wo man seine Dienstleistungen, Produkte, Services ein bisschen über uns hat.

Das sind Projekte, wo man wahrscheinlich schon aber Plugins braucht, um das vollumfänglich realisieren zu können.

Da macht man wahrscheinlich auch schon ein Design-Konzept oder Struktur-Konzept vorher.

Dann schaut man sich an, mit welchen Mittelchen man das lösen kann.

Das ist natürlich eine Präferenzsache, welche Themes, welchen Page-Builder, welche Plugin-Bibliothek man da verwendet.

Das macht sich jede Agentur ein bisschen anders, aber im Kern ist es so, dass man eine Handvoll oder zwei Hände voll Plugins braucht und dann aber jegliche Arten von Unternehmens-Service -Webseiten umsetzen kann.

Das sind so die klassischen Webseiten-Projekte, die zwei.

Und alles, wo es jetzt ein bisschen in Richtung komplexer ist, fällt mir es ein bisschen schwer, die zu kategorisieren.

Ich nehme das zuletzt erwähnte von dir vorweg, nämlich die Headless-Variante.

Das ist eine ganz spannende Entwicklung.

Eigentlich gibt es die eh schon länger und es gibt aber wirklich bekannte Beispiele, wo WordPress als Headless-CMS verwendet wird.

Auch wir haben das schon gemacht in letzter Zeit am WordCamp Vienna.

Diesen Jahres haben wir das auch vorgestellt.

Und zwar haben wir gebaut ein WordPress-Plugin, das die Webseiten in Virtual Reality darstellen soll.

Und im Prinzip funktioniert das genau so.

Also wenn man die Webseite von einem Virtual Reality-Device MetaQuest 2 zum Beispiel im Browser aufruft, erkennt unser Plugin das und wirft den User in eine 3D-Welt rein, wo die Webseite dargestellt wird.

Und in dieser 3D-Welt fetchen wir die WordPress -Contents über die REST-API.

Aber das ganze Rendering 3D, das kann WordPress natürlich out of the box nicht.

Dazu nutzt man ein JavaScript-Framework, das eben mit WordPress über die API kommuniziert und dadurch die Bilder und die Textinhalte lädt.

Der Vorteil ist, man hat die gewohnte WordPress -Umgebung.

Also in dem Fall bei dem konkreten Projekt hat man die ganze Webseite, aber generell hat man die WordPress-Umgebung, man kann sein Content dort managen und kann sie auf verschiedenste Kanäle dann rausspielen.

Also über die Webseite, über die VR-Webseite.

Man könnte eine Version für ein Smart TV bauen, das dann über REST auf die WordPress-Inhalte zugreift.

Man könnte eine App dazu bauen, wo man die Contents von der Webseite abgreift.

Also es sind eigentlich keine Grenzen gesetzt.

Wobei ich das eher ein bisschen als Erweiterung sehe zu einer Webseite, diese Funktionalität.

Genau und jetzt der letzte Punkt wären eben komplexere Softwareprojekte mit WordPress oder komplexere Projekte, müssen nicht unbedingt Software sein.

Da geht es darum, dass man den Kunden versteht, welchen Business Case er online umsetzen möchte.

Das heißt, wir haben eine Webseite und der Kunde bietet eine Dienstleistung oder ein Produkt an, für das man irgendwas mehr bauen muss.

Zum Beispiel, weiß nicht, der will Online-Trainingskurse verkaufen mit einem Abo-Modell für seine Zuhörer.

Und in dem Fall ist es wichtig, dass man das alles vorweg gut definiert, was man braucht.

Sie dann anschaut, was kann die WordPress-Welt, was gibt es schon für Plugins und dass sie einen richtig guten Plan zurechtlegt, um das umzusetzen.

Dazu zähle ich jetzt auch Projekte, wo man Custom-Code braucht, sprich Eigenentwicklungen.

Auch wieder von A bis Z, auch wieder sehr schlecht in Schubladen steckbar.

Man kann ein bisschen was in die Functions -PHP reinhacken, um Funktionität zu erweitern.

Man kann aber genauso gut ganze Plugin-Batteries selber schreiben und so einfach den Webseitenumfang eigentlich unbegrenzt wieder zur Diskussion gestellt erweitern.

Du siehst schon, ich habe jetzt viel geredet, aber schlecht kategorisiert, würde ich sagen.

Je einfacher es ist, desto leichter ist es zu kategorisieren, aber grundsätzlich sehe ich die Grenzen von WordPress relativ weit, relativ gut aus.

Und wenn wir jetzt zum Beispiel die Türen öffnen, was sind für dich persönlich jetzt die Limitierungen von WordPress? Also unabhängig davon, ob das jetzt eine simple Webseite ist, unabhängig davon, ob das ein komplexes Headless -System ist mit einer Frontend-Applikation zum Beispiel, die vorne dran hängt.

Was sind so die Grenzen von WordPress, die man kennen sollte, wenn man sich dafür entscheidet, WordPress als Werkzeug für das Projekt zu verwenden? Ja, jetzt wird es natürlich spannend und offen, um die Grenzen von WordPress da festzulegen, glaube ich, muss man sich anschauen, wo denn die Schwächen von WordPress sein können.

Weil jede Art von Schwäche, wenn man da weiter reingeht, wird es vielleicht irgendwann zu einer Grenze.

Grundsätzlich würde ich sagen, es ist immer projektabhängig und auch umsetzerabhängig, wo die Grenzen denn tatsächlich sind.

Aber ich würde vielleicht auf ein paar exemplarisch oder ein bisschen aufzählen, wo ich denn da die Grenzen sehen könnte.

Ich glaube, das Hauptthema Nummer eins dazu ist, was sehr positiv ist, nämlich, dass es für jeden Anwendungsfall gibt es eigentlich von der WordPress-Community ein Plugin.

Und ich glaube, das ist auch die Hauptgeschichte, wo man dann in Grenzen gerät.

Man kann nämlich so gut wie alles machen und dann installiert man ein Plugin nach dem anderen und dann sitzt man da auf einer Webseite, die durchaus mal 50, 60 Plugins installiert hat, die zwar sehr funktional ist, aber dann rennt man richtig rein in die Troubles.

Erstens muss man es warten.

Es gibt immer wieder Plugin-Inkompatibilitäten, von denen man eigentlich gar nichts weiß, auch zwischen großen Plugin-Herstellern.

Es gibt leider auch schlecht entwickelte Plugins oder Plugins, die nicht mehr weiterentwickelt werden.

Das sind vielleicht da kleine Helferlines, die einmal Sync gemacht haben, aber in zwei, drei Jahren nicht weiterentwickelt werden, dann hängen sie drin.

Man ist vielleicht davon abhängig und dann kann man sie entweder hersetzen und das selbst auf den neuesten Stand bringen, eine Alternative suchen oder whatever.

Mit 50, 60 Plugins hat man dann immer definitiv das Thema Speed drinnen.

Es gibt da sehr viele Plugins, die einfach auf Speed nicht optimiert sind, wesentlich viele Datenpack-Abfragen bei jedem WordPress-Load machen.

Das finde ich auch persönlich ein bisschen ein Problem.

Und dann hat man noch das Thema Sicherheit.

Jedes WordPress-Plugin birgt ein gewisses Sicherheitsrisiko.

Der einzige Unterschied ist bei denen, die richtig häufig verwendet werden, fallen Sicherheitslücken auf der großen Nutzerbasis wahrscheinlich viel früher auf und werden vermutlich auch früher gefixt, als bei kleinen Nischen-Plugins, wo Sicherheitslücken teilweise auch wahrscheinlich längere Zeit offen bleiben können.

Also das Thema Plugins ist für mich Hauptthema, warum man sie irgendwo verrennt und wo auch die Grenzen sind.

Was gibt es da für Tipps? Ich würde vorhin genau überlegen, welche Funktionalität brauche ich? Unbedingt auch mit dem Kunden reden, dass er das versteht, was das für Konsequenzen haben könnte, wenn man dort noch ein kleines Feature und da noch ein kleines Feature, gerade bei Online-Shops ein großes Thema, dazu baut.

Dann würde ich mal versuchen, die Anzahl der Plugins generell zu reduzieren.

Es gibt Plugins, die einfach mehrere Funktionen in einem vereinen und das auch gut machen.

Dann hat man zumindest eine kleinere Anzahl an Plugins.

Trotzdem ist der Rat, so gut es geht, die Anzahl der Plugins generell zu reduzieren.

Dann schaut man aufs Datum, wann es zuletzt runtergeladen worden ist, wie oft es verwendet wird, die Bewertungen durchlesen.

Man kriegt da im Support-Bereich ein Gefühl dafür, wie schnell reagiert der Entwickler, der Hersteller auf Kundensupport oder ignoriert einfach Kundenanfragen.

Und es gibt mal das Gefühl für Plugins, die ich noch nicht kenne, die ich noch nicht verwendet habe, ob das eine gute Idee ist, die in einem Projekt zu verwenden oder nicht.

Also das ist mal ein Punkt Plugins.

Dann ganz generell kann man den Punkt Speed schon als Thema sehen im Wordpress-Bereich.

Ich bin grundsätzlich nicht unzufrieden, wie man Wordpress-Speed optimieren kann.

Ich glaube, ganz in die Tiefe müssen wir nicht hüpfen.

Es gibt ja eh schon Podcast-Episoden oder das ist eigentlich ein episodenfüllendes Thema ganz generell.

Aber wenn sich jemand mit dem Thema Performance beschäftigt hat, kann man mit unterschiedlichen Cache-Layers, mit Plugins, die einfach die nur notwendigen Skripte laden, mit den Portfolian-Performance-Maßnahmen von Unused-CSS über alles, was es halt so gibt.

Da kann man wirklich viel rausholen, wenn man es halt nicht vorher übertrieben hat mit dem Funktionsumfang und mit den Plugins.

Das ist halt natürlich da die Grundvoraussetzung.

Dritter Punkt, habe vielleicht ein bisschen persönliche Meinung, aber obwohl es ein CMS ist und meist verwendet ist der CMS, ist Wordpress bei viel Content gar nicht so gut geeignet, wie man es sich vorstellt.

Also wir haben Projekte, wo es 300 bis 400 Subseiten gibt auf einer Webseite und das ist, wenn man dann vielleicht noch die Mehrsprachigkeit dazu gibt, ist es ziemlich unübersichtlich, den Content zu gliedern, wiederzufinden.

Wenn man jetzt gemeinsam zum Beispiel einen Artikel schreiben möchte, gibt es out of the box auch nicht wirklich coole Features, so wie man es gewohnt ist, so kollaboratives Artikel schreiben.

Die Mediathek ist sofort überfüllt.

Wenn man jetzt mit einem Plugin wieder mal für Abhilfe sorgt, dass man sich so Ordnerstrukturen oder Kategorisierungen zurecht legt.

Also das ganze Thema Content ist, wie gesagt, bei wirklich großen Seiten, und da geht es nicht um Blogs, weil 400, 500 Blogartikel ist egal, aber bei strukturierten Content, Content für verschiedene Nutzergruppen, zum Beispiel große Steuerberatungen zum Beispiel, die haben riesig viel Content, unterschiedliche Strukturen, unterschiedliche Bereiche und das zu gliedern, gemeinsam daran zu arbeiten, das ist ein bisschen mühsam, man braucht wiederum Plugins, um da die Zusammenarbeit quasi gut machen zu können.

Wo wir Grenzen gesehen haben, sind große Shops.

Ich persönlich bin eigentlich Woocomers Fan für kleine Shops, für Subscriptions, für so virtuelle Geschichten ist es ganz gut.

Wenn man einen physischen Shop hat, mit sehr, sehr vielen Produkten, kommt man hinten raus manchmal nicht zurecht, zum Beispiel mit dem Sync, mit dem RB-System, Produktstand abgleichen, Bulk-Bearbeitungen und da das Speed bei wirklich vielen Produkten ist schwierig.

Es gibt für mich kein perfektes Plugin für Volltextsuchen, gemeinsam mit Produktfiltern.

Mit den URLs hat man vielleicht Probleme von den Shops, also große Shop-Projekte würde ich fast eher mit einem spezialisierten Shop-System abwickeln.

Kleine Shops, aber wie gesagt, mache ich sehr gerne in Wordpress.

Dann gibt es das große Thema der ganzen Community -Seiten.

Da gibt es ja riesige Plugins, wo man theoretisch mit einer Plugin-Installation seine Wordpress -Seite zu einer eierlegenden Wollmilchsau macht.

Mit einem Forum, mit Benutzerprofilen, mit Gruppen, mit Chats und so weiter.

Das hört sich cool an.

Man installiert das Plugin, beschäftigt sich einen Tag damit, schaut immer noch cool aus und nach zwei Wochen kommt man drauf.

Hätte ich mir das nicht angetan, also zumindest bei der ersten Einrichtung.

Also bei so ganz großen Spezialanwendungen sollte man sich kurz mal umschauen, was es denn noch gäbe.

Und das letzte Thema, das man sich da unbedingt anschauen muss, auch wenn es jetzt keine Grenze per se ist, weil es überall ist, ist das Thema Sicherheit.

Gerade durch die Vielzahl an Herstellern, die Vielzahl an Plugins, die große Verwendung.

Wäre ich ein Hacker, würde ich mir jetzt erst WordPress anschauen, weil es einfach so viele Webseiten verwenden.

Habt ihr auch schon Podcast-Episode gehabt dazu.

Das Thema Sicherheit darf man nicht außer Acht lassen.

Wie gesagt, das hat man bei jedem System, aber man muss sich auf jeden Fall einen Prozess zurechtzulegen, alle Plugins zu prüfen, zu warten, Backups zu haben, aber wiederum episodenfüllende Geschichte.

Ich sehe das jetzt nicht als Grenze per se, aber das muss man sehen und muss man im Schirm haben, gerade für große Seiten, dass es durchaus ein Thema ist und sein kann, Thema Sicherheit.

Also das, was ich jetzt daraus gehört habe, um das vielleicht so zusammenzufassen, ist, also da gebe ich dann auch ein bisschen so meine Philosophie in das Ganze, ist, dass WordPress eigentlich nur ein Tool ist und es hängt davon ab, wie man das Tool verwendet, ob man dann schnell an die Grenzen stoßt oder nicht.

Weil wenn man zum Beispiel, wie du den Use Case beschrieben hast, dass man vielleicht 30, 40 Plugins installiert, dann ist es halt sehr befüllt mit Plugins, da kann es sein, dass man dann keine gute Erfahrungen hat, wenn man die ganze Webseite updaten muss.

Und dann verstehe ich wiederum, wieso Leute dann so genervt sind von den WordPress-Updates, dass da immer wieder was nicht passt, weil bei 30, 40 Plugins hast du eigentlich eine Garantie, dass irgendwas nicht passen wird.

Und wenn du zum Beispiel nur 5 bis 6 Plugins installiert hast, dann sind sehr selten irgendwelche Troubles bei den Updates, wo du dann eingreifen musst, irgendein Backup einspielen musst und so weiter.

Aber in Bezug auf Grenzen, auf die Symptome, weil du bekommst ja keine Meldung von WordPress so, ey, du bist gerade an eine Grenze gestoßen, bitte mach das und das, um das zu beheben.

Sondern wie wirkt sich das aus, wenn man an Grenzen von WordPress stößt? Also gibt es da irgendwelche Symptome, die sehr typisch sind, wo man merkt so, aha, meine Webseite wird zu komplex, ich sollte irgendwas machen, oder wie wiegt sich das überhaupt aus? Wie merkt man, dass man an die Grenzen von WordPress überhaupt stößt? Ich glaube, da gibt es auch wieder verschiedene Ebenen, wie man das merken kann.

Das erste ist sicher die Unübersichtlichkeit.

Merkt man, glaube ich, am besten daran, dass man, wenn man in die Webseite reinsteigt, schon ein schlechtes Gefühl hat, Sachen selber nicht findet, es unübersichtlich wird.

Zweitens, wo man es merkt, ist das Speed von dem Backend.

Das heißt, wenn man eingeloggt ist, ohne Cache, merkt man relativ schnell, wann die Seite beginnt, langsam zu werden.

Das macht dann einfach viel weniger Spaß, wenn man im Backend herumklickt und man muss jedes Mal, keine Ahnung, Sekunden, also mehrere Sekunden auf den nächsten Pageload warten im Backend.

An dem merkt man es.

Und woran man es auch erfahrungsgemäß merkt, ist, wenn sie einfach das eigene Backlog bühlt mit Tasks, mit Fehlern, wo man jetzt nicht genau weiß, wo kommt das her, die sind schlecht reproduzierbar und ich glaube, das sind die Anzeichen quasi, dass man einfach zu viel drinnen hat, dass es halt diese Fehler, die aufgrund von Plugin oder Theme Inkompatibilitäten entstehen, sind sehr, sehr schwer zu finden.

Manchmal ist man sofort der Hersteller, da sind die miteinander Absprechen angewiesen und zu dem Zeitpunkt, ich glaube, man kann es zeitlang, kann man es handeln, man kann es auch sehr lange handeln, man kann es auch als Dauerzustand behalten, aber das ist, glaube ich, so die ersten Anzeichen, wenn man an die Grenzen von WordPress tatsächlich stößt.

Und welche Möglichkeiten hat man da normalerweise? Ist das dann so, dass man einfach ein Plugin austauschen muss? Ist natürlich jetzt eine Frage, wo ich dich einfach ins tiefe Wasser schmeiße, aber gibt es da irgendwelche Sachen, die man machen kann? Oder sollte man dann langsam andenken, das Projekt vielleicht von neu zu machen, sauberes Setup und vielleicht auf den Business -Use-Case, den man hat, wo man einfach, keine Ahnung, vielleicht hat man zu viele Artikel gehabt, vielleicht hat man ein Plugin verwendet, welches nicht gerade ideal war von der Performance her, vielleicht muss man das dann einfach von scratch aus selbst programmieren, damit man dann weiterhin mehr Einträge in der WordPress-Datenbank abspeichern kann oder einfach mehr Besuchern servicieren kann.

Vielleicht wird die Seite einfach populärer und ich brauche einen neuen Hosting-Anbieter.

Gibt es da irgendeine Art von Checkliste, Anleitung oder Straßenschilder, die man dann sich irgendwie im Hinterkopf behalten kann? Das sollte ich dann vielleicht andenken oder dann ist der Step für das oder was sind überhaupt dann diese Steps, was man überhaupt machen kann? Also ich glaube, eine Straßenschilder fürchte ich oder zumindest sind mir keine bekannt, aber ein paar Tipps würde ich schon gerne da beisteuern.

In erster Linie ist es wichtig und zwar zu jedem Zeitpunkt des Projekts, dass ich verstehe, wo denn der Kunde hin möchte.

Das heißt, man muss sich unbedingt anschauen, welche Prozesse hat der Kunde? Das heißt, was ist sein Geschäftsmodell und wie wickelt er sein Geschäft ab? Im besten Fall weiß ich das schon vor Beginn des Projekts, weil ich mich dann viel besser richten kann.

Aber gerade in der Digitalbranche oder zum Beispiel bei Startups, kann man das, vielleicht ist es vorher noch gar nicht klar, nicht genau definiert oder es muss pivotiert werden oder es wird einfach größer und wächst, ohne dass man es sich gedacht hat.

Das ist alles okay, das passiert laufend.

Wie gesagt, im ersten Fall, wenn man es vorher weiß, kann man sich gut darauf einstellen und das schon größer aufstellen.

Sprich, größer aufstellen heißt, man investiert von vornherein mehr Zeit in eine solide Basis.

Das ist am Anfang natürlich dann ein höherer Aufwand.

Dafür hat man im Long Run dann bessere Karten, wenn man vorher eben die Zeit investiert hat.

Wo man in die Grenzen aber meistens stößt, ist es so, dass man am Anfang nur mal eine kleine Webseite macht, die dann einfach wächst mit den Kunden, mit den Anforderungen, mit dem Geschäftsmodell und dann komme ich eher, glaube ich, in die Situation, die du jetzt geschildert hast, nämlich, dass man beginnt, oder wir vorher darüber gesprochen haben, dass man ihn beginnt, anzustehen und wenn man das merkt, sollte man das selber normal machen, nämlich mit dem Kunden zu sprechen, in welche Richtung geht es und was hast du noch vor und dann, glaube ich, kann man entscheiden, in Richtung, ich mache kleinere Optimierungen, weil es wird jetzt quasi in die Richtung weitergehen und du kleine Optimierungen hast, ich schaue mir die Plugins an, welche sind unperformant, welche funktionieren, welche machen Probleme, versuche die auszubessern, es sind vielleicht zwei Jahre vergangen, es gibt vielleicht was Neues, was Besseres, das wäre das eine, Plugins eben auszutauschen oder vielleicht auf Custom-Lösungen umzusteigen, die Performance nochmal von Grund auf zu optimieren, Serverumzug ist zwar manchmal wirklich notwendig, aber in den meisten Fällen verschiebt man das Problem einfach nur, also es ist sicher keine definitive Lösung, ja und weitergehend oder wenn man nicht mehr zurechtkommt, sollte man dann tatsächlich einen Relaunch, vor allem wenn der Kunde plant weiterzuwachsen, größer zu werden, sollte man sich dann tatsächlich einen Relaunch überlegen, das heißt nicht, dass man das Ganze über etwas wegschmeißen muss, um auf eine Custom-Entwicklung umzusteigen, das ist dann eher die Spezial- und die Riesenfälle, wo man das dann andenkt, aber generell kann man aus den Erfahrungen, erstens aus den eigenen Erfahrungen der Jahre und dann aus den Kundenerfahrungen im zweiten Versuch, dasselbe Projekt für den Kunden einfach besser machen, man versteht den Kunden besser, man versteht das Geschäftsmodell besser, man weiß die User, man hat einen großen Erfahrungsschatz, die Welt hat sich zwei, drei Jahre weiter bewegt, die WordPress-Welt, das sind jetzt nicht große Schritte in den zwei, drei Jahren, also manchmal macht es auch Sinn, einfach einen kompletten Relaunch, basierend auf demselben System, das der Kunde ja grundsätzlich vielleicht eben mag oder gut verwendet, das Projekt einfach nochmal from scratch gemeinsam mit dem Kunden aufzusetzen und einfach auf große Beine zu stellen.

Und kannst du uns da vielleicht von ein paar Erfahrungen, die du schon gemacht hast mit anderen Projekten erzählen, dass du zum Beispiel oder ihr in dem Fall an Grenzen von einem Projekt gestoßen seid und wie habt ihr dann die Lösung gefunden und wie ist es dann vorangegangen? Ja, da kann ich gerne ein paar Beispiele nennen.

Ich fange vielleicht mit passfinder.

com an, weil das eine Geschichte ist, die genau in die andere Richtung gegangen ist.

Passfinder war wie gesagt eine Single Page React App mit einem großen Backend und das React-basierte Frontend eben Single Page, das heißt man lädt quasi nur ein Javascript-File und dann entsteht die ganze App und die holt eben den ganzen Content vom unsichtbaren Backend und da waren die Grenzen und das ist ein richtig großes Projekt, also fünfstellige Anzahl an Entwicklungsstunden, die da in das Gesamtprojekt hineingelaufen sind, inklusive Backend und da sind wir eben drauf gekommen, dass so ein Custom Frontend eben so seine Grenzen hat, nämlich genau das, wo eigentlich die Vorteile von WordPress liegen.

Du musst für jede Funktionalität sehr, sehr viel Zeit investieren, um das zu coden und dann noch um das schön zu machen und wo wir wirklich die größten Troubles gehabt haben, war bei der Responsive Darstellung, das ist, wenn man das Custom baut, ein richtiger Aufwand für uns zumindest gewesen und dann hat man so Dinge, keine Ahnung, man möchte ein Subscription-Modell für seine Werbeflächen einführen in einem Frontend, das heißt man, also in dem Fall waren das gruppengeeignete Reiseziele, da gibt es tausende davon und das muss natürlich ein vollautomatischer Prozess sein, dass es dort ein Sign-up gibt, wo sie die Daten eingeben, die dort gleich ein Jahresabo oder ein monatliches Abo abschließen, da soll eine Online-Zahlung drinnen sein, die sollen dann automatisch ein Profil angeklickt kriegen, ihre Profildaten mit Upload, mit Kategorien, mit Beschreibungstexten, mit den verschiedensten Seiten, GPS-Koordinaten befüllen, die sollen das speichern und der Admin soll das dann freigeben und dann wird es angezeigt und gleichzeitig ein Routenplaner für die Busse, dass die eben dort stehenbleiben können, übernommen.

So, das war zum Beispiel eine Anforderung und wenn man es ihnen hinsetzt und das plant für einen kompletten Custom-Code, kommt man darauf, dass man da gleich wieder auf vielen 100 Stunden ist.

Wenn man sich dazu überlegt, dann wie man das in WordPress abbilden könnte, das wird mit wenn man Rookiverse hat, braucht man dazu eigentlich zwei Plugins zusätzlich und man kann den ganzen Prozess innerhalb von einer Woche umsetzen, wenn man schnell ist und dann ist es halt schon die Frage, investiert man da Monate in einen Case, wo man gar nicht so sicher war ist, wird der dann tatsächlich angenommen von den Usern, ist das ein Business-Case oder macht man mal die Lösung, die ja die endgültige sein kann und auch sein wird, dass man das in WordPress macht und diese Überlegungen haben bei Busfinder dann eben dazu geführt, dass wir die ganze User-gerichtete oder die Präsentations- Seite in WordPress umgesetzt haben und vielleicht aber damit man ein Gefühl kriegt, was wir da drinnen haben und was nicht, also sobald man einen Bus wirklich buchen möchte, also Routenplaner, dann die Busauswahl und dann der Checkout-Prozess, alles was man da sieht, ist weiterhin eine React-App, die haben wir auch von neu aufgeschrieben, weil, wenn schon, denn schon.

Das Ganze ist aber ins WordPress-Ökosystem integriert, mit dem sogenannten Shadow DOM, für die Tech-Interessierten, die kennen das sicher, es gibt die vorgegangene Technologie, wie die mal sagen, I-Frames, da kriegt jeder wahrscheinlich eine Gänsehaut, der gerade zuhört, I-Frames gibt es wahrscheinlich, also seit ich Web mache, gibt es I-Frames, das sind wahrscheinlich 25 Jahre wahrscheinlich werden es sein, wo ich die ersten Versuche gestartet habe und die Webseiten mit Header, Sidebar und Ding, das waren drei I-Frames und überall war da Content drinnen, gut.

I-Frames haben sich bis heute gehalten und jetzt gibt es endlich den Shadow DOM, wo man in den HTML-Code von Webseiten einfach einen Shadow, also eine Schattenseite, sag ich mal, wie wir das übersetzen und da kann man dann irgendeinen Art von Custom-Code reinspielen und der ist von außen nicht zugänglich und dort kann man ein ganz eigenes Design-Universum aufbauen, einen ganz eigenen HTML-DOM aufbauen, der einfach von außen nicht zugänglich ist.

Schaut aber nicht aus wie ein I-Frame, funktioniert nicht wie ein I-Frame, sondern wie eine vollintegrierte Webseite, man hat zum Beispiel, wenn man Cookies setzt, hat man First-Party-Cookies und keine Third -Party-Cookies mit dem Shadow DOM und mit der Technologie haben wir eben den Buchungsprozess ins WordPress reingebracht und das schaut für den User dann nach einem sehr durchgegangenen Prozess aus und es fällt wahrscheinlich nicht einmal auf den ersten Blick auf, dass da eigentlich eine ganz andere App am Werkeln ist als ein WordPress -Buchungsprozess.

Was wir da auf der WordPress-busfinder.

com -Seite noch haben, ist Busreisepräsentation.

Da wieder ein spannendes Geschichtel und zwar haben wir da ein Plugin entwickelt, also ein Custom-Plugin, das importiert die Busreisen von einem Schwesterprojekt über eine Schnittstelle, kopiert die ganzen Reisendaten ins WordPress rein, sprich die Reisebilder, Reiseverlauf, Reisedaten, werden ins busfinder-WordPress reinkopiert, das Plugin bietet eine Suchfunktion, das heißt, der Vortex-Suche, Kategoriesuche, Datumsuche und diese ganze Präsentation ist im WordPress drinnen, das hat natürlich auch SEO-Gründe, weil wenn man dort ein paar hundert Busreisen drinnen hat und in jeder Reise kommt das Wort Bus und Busreise und holt das Reiseziel vor und das quasi als halbwegs eigenen Content da verkaufen kann, ist natürlich für die Suchmaschine auch kein Fehler, sage ich jetzt einmal und wenn man dann auf zu buchen klickt, dann kommt der iFrame, sowieso über iFrame ist geschimpft und wir nutzen es dort selber noch, aber ist trotzdem noch ganz gut gelöst, das heißt, der Checkout-Prozess kommt eben vom Schwesternprojekt und wird dort als WordPress drinnen.

Wird als iFrame im WordPress dann quasi geladen.

Und dann haben wir noch zwei Dinge, wir haben eine Busunternehmer-Übersicht, da importieren wir auch einmal am Tag in der Nacht den ganzen registrierten Buspartner in WordPress rein mit Bilder, mit Beschreibungen und zeigen die dann auf einer Seite an und das, was ich vorher erzählt habe, dieser Subscription-Prozess für Werbeflächen, das haben wir gerade in der Fertigstellung, aber auch das wird eben mit WooCommerce, mit Subscriptions, mit Custom-Profilen, mit einer Suchfunktion, also auch das ist ein Custom-entwickeltes Plugin, das dann die Anzeige der Profile übernimmt und die Suche.

Subscription, wie gesagt, mit WooCommerce und Subscriptions und dann eine Schnittstelle rein ins Buchungstool, damit wir die Ausflugsziele dann auch irgendwann in der Routenplanung anzeigen können.

Zusammengefasst quasi, wir haben WordPress als leading CMS dahergenommen, als erstes Lieferant dessen, was der User von uns als erstes sehen soll, aus optischen Gründen, aus funktionalen Gründen und haben dann unser ganzes Universum, also die Busbuchungen und die Busreisebuchungen mit verschiedensten Technologien, Shadow DOM, iFrame, Custom-Plugin, plus WordPress-Plugins, Subscription-Plugin, in ein großes ganzes reingepresst.

Um vielleicht ans Thema vorzukommen, warum haben wir uns nochmal dazu entschlossen? Das liegt daran, dass dieses System nicht unendlich groß wachsen wird von der Content -Seite her.

Das heißt, das, was richtig Traffic und Ressourcen braucht, ist die Buchungs-App und die liegt woanders, also die ist Cloud-gehostet und hat eine ganz andere Technologie als Background und für eine Präsentation von statischen Seiten die News-Beiträge, zwei Dutzend hoffentlich, die wir über das Jahr veröffentlichen werden und die paar hundert oder tausend Ausflugsziele, da habe ich auch in Zukunft überhaupt kein Zweifel daran, dass WordPress damit zurechtkommen wird, mit einem guten Hoster, mit einem guten Caching, mit einer guten Wartung, und gehe davon aus, dass es zukünftig funktionieren wird.

Und habt ihr diese Systeme voneinander getrennt, weil ich gehe mal davon aus, Peter kannst mich gerne korrigieren, wenn ich da falsch liege, aber bei der Passwahl in der Applikation, also die auf React basiert und im Shadow DOM da alles zusammengebaut wird, die kommuniziert dann mit einem zentralen WordPress -System über die REST-API oder ist das dann irgendwie anders, dieses zentrale System, welches dann die ganzen Daten für die Busse und so weiter hat? Genau, das ist nicht WordPress, das ist das Urpasswendersystem immer noch, das ist quasi ein ERP oder Dispo- und Verwaltungssystem für Busunternehmen, das ist ganz weit entfernt von dem, was man als Content-Management-System braucht, sondern das ist eine Busplanung, sprich da ist eine Kalenderfunktion drinnen, da ist die Geschichten, wie man seine Busse und Fahrer verwaltet, da ist eine Buchungsverwaltung mit Tabularisch, Sortierfilterbar, das sind die ganzen Tarifschema, die man einstellen muss, unglaublich viele Formulare, also das haben wir auch mit React Custom gekodet, mit dem Framework, weil es einfach eine Arbeitsoberfläche ist und auch sein muss und das wäre zum Beispiel eine Geschichte, wo ich mir denke, wenn ich das mit WordPress machen müsste, dann würde man wahrscheinlich nur das Login und die User-Verwaltung überbleiben, was ich von WordPress verwenden kann und alles andere müsste ich sowieso selber coden und für das nehmen wir nicht quasi das WordPress-Universum dann obendrauf, das macht für dieses Projekt zum Beispiel wirklich keinen Sinn, das heißt, das Buchungstool ist wirklich komplett getrennt, wird nur injiziert bei Shadow DOM und kommuniziert mit seinem Heimat-System, Custom-Code mit Java, Kotlin, Cloud-basiert, völlig unabhängig von WordPress in dem Fall.

Wo wir die Schnittstelle haben, ist eben von den Ausflugszielen, die dann quasi vom WordPress über REST rübergehen, in das Buchungstool und vice versa, wo man die Busunternehmen vom Busverwaltungs-Tool abholen und ins WordPress reinholen, das alles REST-basiert.

Okay, also das ist so, finde ich, ein sehr gutes Beispiel für ein komplexes Projekt, ein großes Projekt, wo dann wirklich Teile, wo es sich anbietet, da wirklich WordPress verwendet wird und Teile, wo es einfach keinen Sinn macht, ist halt WordPress nicht das richtige Werkzeug dafür.

Hast du vielleicht noch einen anderen Newscase, der vielleicht ein bisschen simpler ist, wo sich die Leute vielleicht mehr damit identifizieren können, wenn es jetzt zum Beispiel auf Webseiten Basis geht oder wenn es jetzt eine, ich sage jetzt mal, keine custom-entwickelte Applikation ist, hättest du da auch ein Beispiel, wo man das gut sieht, dass die Webseite oder das WordPress an Grenzen gestoßen ist und wie habt du das dann gelöst? Ja, da habe ich auch noch ein, zwei, drei Beispiele, wo ich gerne berichten kann.

Das erste Beispiel wäre ein Onlineshop mit WooConverse, den wir für Einzelhandels Filialen umgesetzt haben und da war das Thema, dass es einerseits sehr gute Kundenansprache geben sollte, das heißt, ein sehr aufwendiges Design, das vom Kunden gewünscht war und wir wirklich unterstützt haben.

In dem Shop gibt es wirklich viele verschiedene Produkt Kategorien, die ja teilweise quer vernetzt sind und es sollten sehr viele Wege geschaffen werden, wie der Kunde eben über diesen großen Blumenstrauß des Onlineshops stolpern sollte.

Das Ganze ist sehr bilderlastig gewünscht werden, mit sehr, sehr vielen Design, technischen Hintergrundbildern, einer sehr großen Produktbasis und einer gesamten Produktmigration vom vorherigen System, was auch WordPress mit WooCommerce war.

Wir haben uns diesen Relaunch angenommen und da haben wir tatsächlich ein relativ großes Performance Problem reingelaufen, mit dem wir eigentlich so nicht gerechnet haben.

Da hat es mehrere Gründe dafür gegeben.

Erstens ist es echt schwer, ein gutes Design, eine Übersichtlichkeit mit Performance und SEO zu optimieren.

Das sind immer zwei Welten, die ein bisschen gegeneinander arbeiten, aber man muss halt eben versuchen, die Mitte zu finden, nur wirklich ein perfektes Design und ein großes Mega-Menü, das sich der Kunde zurechtfindet, ist natürlich eine Höchst-SEO-Strafe mit zu vielen internen Links und dasselbe vom Speed.

Da kann man optimieren, was man möchte.

Man kommt halt auf KA und keine 95% Speed oder nur mit extremen Aufwand, das man eben vorher schon berücksichtigen hätte müssen, sagen wir mal so.

Das heißt, in dem Fall würde das Learning, also wir haben es dann wirklich bis ins Detail optimiert, also bis eh runter, dass man für jede einzelne Seite, die CSS und so weiter ist egal, aber wirklich nur die Scripts dann geladen haben und nur die CSS-Files, die ja tatsächlich notwendig sind, plus ein mehrstufiges Cache, plus exakt definiert, welches Bild wird Lazy geladen, welche Bilder werden gleich geladen.

Also das sind dutzende Stunden an reiner Performance -Optimierung reingelaufen und wir sind dann auf einem B gelandet vom Speed-Score, aber es war dann echt nicht mehr mehr drinnen.

Im Vorhinein hätten wir einfach noch eine Spur mehr uns mit dem Kunden unterhalten müssen, dass wir eben für ein gewisses Level, also für ein gewisses Budget, muss man dazu sagen, was man dann wirklich daraus erreichen möchte und vielleicht ein bisschen genauer definieren, was denn tatsächlich das Outcome sein soll.

Ist es Speed auf 100 oder ist es eben dieses schöne Design und dann einfach viel besser drüber zu reden, in welche Richtung oder was dann wirklich die Prioritäten sind.

Es ist grundsätzlich eh dann gut ausgegangen, also die Seite ist gefühlt extrem schnell und hat gute Userwege, einen guten Checkout-Prozess, also insofern hat sich das dann eh aufgelöst, aber es war zwischendurch wirklich sehr, sehr viel Arbeit, das dann hinzubekommen und man hätte vielleicht am Anfang zwei, drei Entscheidungen anders treffen sollen, um das Ganze, um in das Ding einfach nicht rein reinlaufen und in das Ding nicht reinzulaufen.

Also das war eine Geschichte mit Performance- Grenzen, vielleicht eine Geschichte, die jetzt, ich sage kein Negativbeispiel, aber trotzdem wo man die Grenzen oder wo man sich überlegt, was mache ich mit WordPress, was mache ich nicht mit WordPress.

Es ist ein Verein an uns herangetreten, die Hofübergaben machen, sprich gesellschaftliches Thema, Bauernhof, die Jugend möchte nicht übernehmen, der Betreiber, die Betreiberin, das Ehepaar möchte aber, dass der Hof weitergeht und dann auch für diesen Hof ein Nachfolger.

Und es gibt mittlerweile genug Junge, die ja das als Lebensziel sehen, auf einen abgelegenen Hof und dort eine Landwirtschaft aufzubauen, sei es haupt- und nebenberuflich, aber das nur zum Projektkontext.

Und das Ganze ist eben als Verein organisiert und es sind auf uns zukommen, die Vereinsmitglieder sind mit Excel verwaltet worden und da war die Idee, ob man die Vereinsverwaltung ebenso digitalisiert.

Und wir haben uns da am Beginn des Projekts angeschaut, also wir haben ein bisschen, also einige CRMs schon mal begleitet oder selbst in Verwendung, sei es Odo, sei es Hubspot, sei es sonstiges und die Idee war, nachdem die einen digitalen Business Case haben, sprich die Bereitstellung der Profile und das Anschauen der Profile ist möglich, wenn man Vereinsmitglied ist, das heißt zwar spendenbasiert, aber rein digital, das heißt man wird Online-Mitglied, kann online zahlen, wird dann freigeschaltet, kann sich sein Profil anlegen, das war so der Projektinhalt und das natürlich ist nicht aufwendig, wenn man da externes System hat, das dann manuell mit WordPress zu sünden.

Also im Sinne von, der User hat jetzt sie registriert, da hat er gespendet, bis zu dem Zeitpunkt läuft die Mitgliedschaft, nach drei Monaten soll der Steckdruck wieder aus deaktiviert werden, solche Dinge und da haben wir uns überlegt, dass zwei getrennte Systeme eigentlich mehr Arbeit sind und dann haben wir gesehen, dass Civi CRM ist eine Open-Source CRM, gerade für so Non-Profit-Organisationen und Vereine, eigentlich eine sehr große Funktionalität ist, die es bezüglich gibt und es gibt einen WordPress -Wrapper, das heißt man installiert es mehr oder weniger als WordPress-Plugin, wobei man sagen muss, dass Civi selber geschätzt einiges an, einige mehrfaches an Code mitbringt als WordPress selber und einiges mehr an Funktionalität, das heißt man hat eigentlich das kleine WordPress vor dem großen Civi und dann haben wir begonnen diese zwei Systeme miteinander zu verzahnen, das hat gut funktioniert bei Mitglieder-Synchronisation, bei den Subscriptions hat es gut funktioniert und wo wir dann doch ein bisschen gekämpft haben, ist das ganze Steckdrucksystem, wie kann ich im Civi CRM, also im CRM schauen, welche Steckbriefe der User online hat, dass die Steckbriefe dann welchen Status haben die, muss ich die freigeben, muss ich die überarbeiten und da war eher das Problem, dass man halt dann das Civi CRM ist ein eigener Menüpunkt im WordPress, wird in einem separaten Fenster aufgemacht, die User-Verwaltung, die Steckbriefe sind an einer anderen Ecke im WordPress und da hat man eher so ein Ding schaffen müssen, dass die zwei Systeme halbwegs miteinander, also dass man nicht immer die doppelte Arbeit hat, dort nachzuschauen und da nachzuschauen, dass man es versucht zu einem möglichst homogenen System zu vereinen.

Da haben wir natürlich auch ein bisschen ein Performance-Thema gehabt, nicht im Frontend, sondern im Backend, weil da sehr viel Blut geladen wird durch Civi CRM, durch ein relativ großes WordPress-Projekt und das haben wir dann tatsächlich durch einen relativ flotten Host gelöst, wo einfach genug RAM und CPU zur Verfügung steht.

Wie gesagt, eher für die Backend-Geschichte, weil man da sehr viel arbeiten muss, die ganze Mitglieder-Verwaltung, das muss einfach flott gehen, sonst macht es keinen Spaß und das war tatsächlich eine Geschichte, wo wir gesagt haben, ich kann das Civi CRM nicht Performance optimieren, ich muss es über einen größeren Server einfach lösen und nicht über einen kleinen Shared Host.

Ja, ich finde, da kann man sich das zusammenfassend einfach ganz gut mitnehmen, ist dass die Grenzen von WordPress sich einfach dort verstecken, also bei den Sachen, die ein bisschen zu überraschend dann zum Projekt dazukommen oder die nicht zum hervorsehen waren ein bisschen.

Einfach durch Unklarheiten, egal ob das jetzt von Seiten von Kunden ist, in Form von Kommunikation oder einfach Sachen, in denen man zum Beispiel noch wenig Erfahrung hat und wo man das erste Mal zum Beispiel sowas macht, das sind einfach diese Sachen, wo dann wo man dann an Grenzen stoßen kann, die man davor noch nicht gekannt hat, wo man dann erst lernen muss, wie man diese umgeht oder was dann die besten Lösungen sind.

Ja Dominik, das war jetzt wirklich gut zusammengefasst.

Kundenanforderungen verstehen oder dass der Kunde weiß, was er denn wirklich möchte und ganz gut hat mir gefallen der letzte Satz von dir, nämlich die Dinge, die man selbst zum ersten Mal macht.

Da muss man immer gut aufpassen, dass man das gut plant, vorher wirklich ausprobiert und zwar im besten Fall, bevor man es dem Kunden tatsächlich verspricht, dass es geht.

Ich glaube, sehr viele von uns möchten einfach, es macht einfach Spaß, neue Sachen auszuprobieren, aber für den Kunden zu delivern und vielleicht lässt man sich auch manchmal zu schnell in was reindringen, wo man vielleicht zu wenig Erfahrung hat, gerade wenn es um wirklich große Kunden oder mittelgroße bis große Projekte geht, da würde ich mich persönlich in Zukunft sehr wenig auf Glatteis begeben.

Sprich, wenn da zwei, drei große Features sind, die wir noch nicht umgesetzt haben, für den großen Kunden würde ich es tatsächlich so machen, dass ich mir da Experten an Bord hol, die oder der das schon mal gemacht hat und da mit Rat und Tat zumindest oder klein mit Mitarbeit unterstützt.

Das wäre eine Empfehlung, dass ich mir da wirklich jemanden suche, der genau in dem Bereich Erfahrung mitbringt.

Und vielleicht so allgemein ein paar zusammenfassende Tipps, für die, die es bis jetzt durchgehalten haben in dieser Podcast- Episode.

Das erste ist, den Kunden wirklich zu verstehen.

Es gibt Bücher über Requirements Engineering, das Schritt nachher ansetzt.

wirklich hinsetzen, den Plan des Kunden verstehen, das Geschäftsmodell des Kunden zu verstehen, seine Ziele zu verstehen.

Das kann ruhig ein mehrwöchiger Prozess sein, gerade bei größeren Projekten.

Das Allerwichtigste ist, dass man weiß, in welche Richtung geht es.

Das zweite ist, das ganze Ökosystem des Kunden anzuschauen.

Welche Prozesse gibt es? Gibt es irgendwann Schnittstellen? Welche sonstige Software benutzt der Kunde? Dass ich das auch im Blick habe, dass da keine Überraschungen gibt.

Das dritte ist die Selbstreflexion für ein Projekt.

Kann ich das wirklich in der Größenordnung abdecken? Brauche ich vielleicht auch Experten, die mich da unterstützen? Dann ein Punkt ist, ich sollte schauen, welches Know-how hat denn der Kunde in-house? Know-how zur WordPress-Bedienung, Know-how im Sinne von technischem Grundverständnis, Know-how im Sinne von generell Digitalisierungsgrad, weil man kann das schönste für WordPress mit super coolen Funktionen machen, wenn der Kunde in-house die Möglichkeiten oder das Verständnis nicht hat, das dann auch wirklich abzuwickeln und zu bedienen, wird das Projekt an sich nicht funktionieren.

Das ist zwar schön, wenn man dann stundenweise immer wieder ganz viel dazuarbeiten kann, aber das ist nicht der Sinn und Zweck des Kunden und da muss man halt vielleicht den Kunden dahin zu beraten, dass er ein gewisses Grad an Know-how einfach intern aufbauen muss.

Dann, was auch noch ein guter Tipp ist, aber in der Entwicklerwelt, ich brauche es euch eh nicht erzählen, ist, dass man wirklich Sachen, die man custom macht, dokumentiert und jeden Push in der Functions BAB, den man macht, zumindest, im Functions BAB oben in einer Art Inhaltsverzeichnis zu machen, dass man dann und man wird dann ein Jahr später angerufen und sagt, hey, das und das funktioniert nicht und wenn man dann, keine Ahnung, tausend Seiten Code in der Functions BAB hat und dann nichts dokumentiert hat, braucht man wahrscheinlich einen ganzen Tag, bis man da wieder reinkommt.

Das heißt, alles, was man tut im WordPress, alles, was man customizet, für sich selbst und vielleicht für jemanden anders, der das Projekt dann übernimmt, bitte, bitte dokumentieren, eine Übersicht schreiben, im besten Fall noch eine externe Doku.

Damit kann man nämlich die Grenzen dann viel schneller wieder nach hinten verschieben mit dieser Dokumentation.

Voll, das kann ich nur unterschreiben, kann da voll zustimmen und finde es voll cool, dass man jetzt ein bisschen so dieses an dieser Box der Pandora irgendwie geöffnet haben und da ein bisschen so einen Blick drauf geworfen haben, so was sind so die Grenzen von WordPress, da wird ja auch jeder eigene Erfahrungen haben, deswegen kannst du als Zuschauer und Zuschauerin gerne deine Erfahrungen dann in den Kommentaren dann auch teilen oder falls du irgendwelche Ratschläge brauchst oder Fragen hast, auch gerne in den Kommentaren, falls du dir nicht sicher bist, ob das Projekt so umsetzbar ist oder so umsetzbar ist, was die beste Lösung ist, was das goldene Rezept ist, gerne auch in den Kommentaren und bevor wir zu den Bullet-Fragen kommen, da würde ich dir gerne noch den Spotlight geben, falls du irgendwas promoten möchtest, in den Spotlight stellen möchtest, mach das bitte jetzt.

Ja, falls ihr größere WordPress-Projekte umsetzen möchtet, dann bitte gerne mir einfach ansprechen, ihr findet es mir auf rechnerherz.

at und natürlich darf ja unser Startup an dieser Stelle kurz promoten, das heißt, wenn ihr vielleicht ein bisschen ein größeres Unternehmen seid und hier und da einen Bus anmieten möchtet für die Weihnachtsfeier dann im nächsten Jahr, dann einfach auf busfinder.

com raufklicken und in Echtzeit Angebote für den Bus mit Fahrer kriegen und den auch gleich direkt online buchen.

Ja, kurz als Kontext, also wir nehmen die Episode gerade im Dezember auf, aber die kommt dann im Jänner raus, deswegen für die nächste Weihnachtsfeier wird es sich gut anbieten.

Zu den Bullet-Fragen, sag einfach das Erste, was in den Kopf schießt, wenn es Rechnerherz, Busfinder und alles, was du so machst, auch mit Uni Wien zum Beispiel, nicht gibt, was wäre dein Alternativberuf? Notarzt.

Okay, cool.

Das habe ich noch nicht gehört.

Er hat Medizin studiert, auch abgeschlossen und das wäre quasi der Plan B.

Okay, verstehe.

Was ist das nervigste WordPress-Feature? Habe ich ganz ehrlich gesagt.

Das können wir auch gerne so belasten.

Ich mag alle.

Was war dein letzter Aha-Moment mit WordPress, wo du überrascht warst, dass WordPress das auch kann? Ehrlich gesagt, diese Performance-Optimierungsgeschichte, wie viel man am Ende des Tages tatsächlich noch rausholen kann mit den richtigen Tools.

Finde ich auch.

Es ist auf jeden Fall sehr viel Optimierungspotenzial noch bei vielen WordPress-Seiten.

Gibt es noch irgendeine finale Message, die du an die Zuschauerinnen und Zuschauer weitergeben möchtest? Ganz generell glaube ich, dass WordPress eine sehr coole Plattform sein kann, auch für mittelgroße und große Projekte.

Ich glaube, es macht Sinn, sich da reinzutigern, ein bisschen mit Entwicklung herumzuexperimentieren und bei Bedarf dann wirklich Experten hinzuziehen.

So kann man wirklich sehr, sehr viele Projekte für Kunden echt gut machen.

Cool.

Vielen, vielen Dank.

Hat mich sehr gefreut, dass wir uns heute über die Grenzen von WordPress unterhalten haben.

Und ja, dann sehen wir uns wahrscheinlich beim nächsten WordCamp.

Danke Dominik.

Hat sehr Spaß gemacht und ja, definitiv beim nächsten WordCamp dann wieder in persona.

Bis dann.

.