#069: WordPress kann mehr sein als ein Reiseblog | m. Stefan Braunstein

Wir werden uns in dieser Episode mit dem kompletten Potenzial von WordPress beschäftigen und wir werden diesen Mythos, dass man WordPress nur für Blogs und simple Websites verwenden kann, ein für alle Mal widerlegen.

Aber was wirst du jetzt aus dieser Episode mitnehmen? Du wirst auf jeden Fall viel besser verstehen, was eigentlich ein CMS ist und welches Potenzial in WordPress steckt, wenn man das wirklich zu 100% ausnutzt.

Es wird deine Arbeit als Freelancer oder Freelancerin oder natürlich dann auch Angestellter oder Angestellte in einer Agentur vielleicht nicht so stark verändern, hängt natürlich davon ab, was du machst und wie du mit WordPress arbeitest, aber mit dem Wissen aus dieser Episode wirst du WordPress als System einfach viel besser verstehen und dadurch wirst du dann deine Kunden viel besser beraten können.

Herzlich Willkommen bei der 69. Episode der Dominik Liss Show.

Auf diesem Podcast gibt's WordPress und Business Talks.

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

Weil in jeder Episode entpacken wir die Skills, Stories und Geheimnisse der besten Experten aus der WordPress-Branche und das Ziel des Podcasts ist dir dabei zu helfen, ein besserer Professional in der WordPress-Welt zu werden.

Heute unterhalten wir uns mit Stefan Braunstein und da bin ich schon sehr gespannt, was er uns zu dem Thema erzählen wird, weil wir werden uns in verschiedenen Themen bewegen, eben dann auch sehr technisch, wie zum Beispiel Headless, was ist das, was ist das nicht, wie kann man dann WordPress bestmöglich ausnutzen und nach welchen Prinzipien, Designprinzipien, Fundamenten und so weiter kann man da vorgehen.

Und ja, Stefan, bitte, sag uns kurz, wer du bist, was du machst und inwiefern du jetzt da das Know-how oder die Erfahrung, die erarbeitet hast, um über dieses Thema da jetzt mit uns zu sprechen.

Ja, Dominik, vielen Dank für die Einladung erstmal.

Ich hoffe, das Schwäbische drückt nicht zu arg durch und ihr versteht mich trotzdem alle.

Ja, ich bin der Stefan Braunstein, arbeite aktuell für die Agentur von Affenfels in Stuttgart, bin in der Entwicklung seit 2001, dort habe ich meine Ausbildung angefangen, damals bei der Bausparkasse hier in Stuttgart.

Habe damals angefangen auf Großrechnern zu entwickeln, also wirklich noch PL1 gelernt früher, bin dann rüber geswitcht zur SAP ABAP-Entwicklung, hatte aber immer so eine kleine Vorliebe für die Webentwicklung, habe damals dann angefangen mit PHP, nicht mit einer großen IDE oder sonst irgendwas, sondern tatsächlich noch auf dem Notepad, was Windows XP eben so mitgebracht hat.

Ja, habe dann relativ nach meiner Ausbildung meinen Zivildienst gemacht, gibt es jetzt ja auch nicht mehr, und bin dann zu einer Firma gewechselt, die sich hauptsächlich für Logistik spezialisiert hatte und habe dort Intranet-Applikationen mit PHP, damals Typo3 als Benutzer-Framework entwickelt, war dort eine ganze Weile, habe dann die Agentur wieder gewechselt, war dann in einer Agentur, die hauptsächlich Laravel-Applikationen geschrieben hat für Solar-Wesen und seit 2020 bin ich jetzt bei von Affenfels darf dort ein Team betreuen von ExpertInnen für WordPress und Laravel-Applikationen und wir entwickeln so alles mögliche an Applikationen, hauptsächlich auf WordPress, was eben gefordert ist.

Und so ist mein kurzer Abriss.

Ich habe letztes Jahr meinen zweiten 39. Geburtstag gefeiert.

Ich bin ein paar Tage dabei bei der Entwicklung, habe die Phasen alle so mitgemacht, was es so gab.

Einführung Social Media und so weiter und so fort.

Und ja, darf jetzt weniger programmieren, aber mit meinen KollegInnen dann im Team eben mehr die Applikationen planen, entwerfen und dann eben das Beste für unsere Kunden rauszuholen.

Sehr cool, sehr cool.

Also ich bin auf jeden Fall schon sehr gespannt auf die Episode, weil es ist relativ selten, dass wir technische Episoden haben.

Aber das ist dann umso besser, dass wir jetzt in das Thema uns vertiefen können, weil ich finde, das ist ein sehr weit verbreiteter Mythos, dass WordPress nur als Blog-System verwendet werden kann, aber man kann so viel mehr damit machen.

Und da an der Stelle vielleicht dann auch eine kurze Werbeeinschaltung, weil das Thema, worüber wir jetzt sprechen werden, darüber wirst du auch sprechen, wenn du uns in Wien beim WordCamp besuchen wirst.

Deswegen ist das ein kleiner Sneak Peek in das WordCamp Vienna 2025, dann eben Ende April.

Also, falls du die Episode anhörst und vorbeischauen möchtest, bitte, kauf dir ein Ticket, schau vorbei und dann sehen wir uns persönlich vor Ort.

So, Werbepause ende.

Ich werde auf jeden Fall den Link unten anhängen in der Beschreibung, damit du das leicht findest.

Und das, was mich extrem freut, wieso wir uns jetzt in dem Fall unterhalten oder wieso wir das Thema mit dir besprechen können, ist, dass du dann schon eher dieses Software-Design-Mindset hast, also als Software-Developer und nicht als Programmierer.

Und auf diese Unterscheidung werden wir später auf jeden Fall noch eingehen, was der Unterschied ist zwischen einem Programmierer und einem Software-Developer.

Ja, die Definitionen unterscheiden sich sicher, hängt immer davon ab, mit wem du sprichst, aber wir werden das so gut es geht einfach aufklären.

Und ja, Vielleicht klären wir aber mal die Frage, weil das Thema allgemein ist, man kann WordPress auch für viel mehr verwenden als nur für Blogs.

Vielleicht einmal als Einstieg die Frage, wie du eigentlich WordPress dann verwendest, weil ich kann mir nicht vorstellen, dass du einfach WordPress installierst, Elementor drauf klatscht und du dir eine Website zusammen klickst.

Du verwendest sicher WordPress technischer, aber kannst du uns da mitnehmen, wie du das machst? Genau, also ich kann da einfach mal einen kleinen Einblick in unsere Arbeit geben, wie wir eigentlich WordPress verwenden.

Ich war dann auch am Anfang, als ich noch wenig Berührungspunkte mit WordPress eben hatte, man hört es natürlich, WordPress, setz denn WordPress auf, klatsch da deine Beiträge rein und fertig ist die Webseite.

Als ich dann damals zu von Affenfels gewechselt bin, war es dann auch erst mal so, ja wir arbeiten mit WordPress, dann habe ich gesagt, okay, dieses typische die die blicke dann natürlich also wie ich sie jetzt bekomme so war dann mein blick im so ok ja also das heißt wir klicken jetzt webseiten zusammen und das mache ich jetzt hier nee nee nee nee nee nee wir machen das anders und zwar wir verwenden wir einen großen teil vom WordPress headless das heißt wir verwenden gar nicht das rendering von WordPress heißt wir arbeiten auch bei den meisten projekten nicht mit elementor oder divi bilder oder sowas zusammen, sondern wir haben uns ein eigenes Framework gebaut, was so ein MVC reinbringt, ein einfaches MVC, Model-View-Controller, ein Design-Pattern eben, das wir verwenden viel.

Auf die Design-Patterns werden wir sowieso später noch eingehen.

Okay, super.

Falls du jetzt gerade zuhörst, als Zuschauer, Zuschauerin, Zuhörer, Zuhörerin, falls dann irgendwie MVC-Pattern und so weiter, jetzt wir darüber sprechen, wir werden das später sowieso noch aufschlüsseln, was dann die jeweiligen Patterns sind, die man verwenden kann.

Aber als erstes würden wir einfach das Thema ein bisschen vorbereiten, deswegen habe ich dich gefragt, so hey, wie verwendest du das? Und das ist genau, und ja, ich wollte das nur kurz einschieben, aber bitte, mach mal du weiter und dann tauchen wir in das Thema ein.

Also wir verwenden, wir haben uns so ein Framework gebaut, in dem wir sogenannte Slots definieren können programmatisch.

Das sind Slots bei uns, das sind Elemente, mit denen ich quasi programmatisch eine Seite zusammenstecken kann, welche dann eben einen eigenen Controller mit bringen, der mich eigene Business Logiken abbilden kann für einen diversen Slot.

Wir Wir bauen jetzt weniger die klassischen Visitenkarten-Webseiten für unsere Kunden, sondern für die Verlage, für die wir arbeiten, bauen wir hauptsächlich entweder digitale Produkte, große Reichweitenseiten oder E-Magazine, welche wir abbilden.

Wir konsumieren dort eine API für Benutzerberechtigungen.

Also darf dieser User überhaupt denn diesen Beitrag sehen und dafür haben wir uns eben komplett eigentlich, wir benutzen vom WordPress das Backend, ja das ist sehr beliebt, auch der Gutenberg Editor sehr beliebt, auch bei den Redakteuren eben, deswegen verwenden wir das Backend, das Frontend und so weiter haben wir komplett quasi ausgekoppelt in eigene Renderprozesse, sage ich jetzt mal vereinfacht.

Auch die Art, wie wir Templates bauen, die dann befüllt werden, haben wir auch komplett extrahiert.

Man kann eigentlich sagen, wir benutzen die Daten, den Datenlayer noch von WordPress und das Backend und dann war es das aber schon.

Und natürlich halt eben, was halt das Schöne an dem WordPress ist, warum wir dann das über WordPress machen nicht unser eigenes Backend bauen.

Die sämtlichen Plugins, die eben dabei sind, die uns dann eben bei bestimmten Themen helfen.

Und genau, so verwenden wir ganz vereinfacht gesprochen WordPress, das heißt Datenlayer noch und die Admin und dann der Rest kommt quasi von unserem Framework im Frontend.

Und du hast jetzt schon diese Art, wie man WordPress verwenden kann und diese Art kommt im Internet jetzt immer öfter vor und da meine ich das Headless, die Headless-Methode, Strategie, Design-Pattern, wie man immer das auch betiteln möchte.

Es kommt immer öfter vor, zum Beispiel, hey, wir verwenden Headless WordPress, Headless WordPress ist die Zukunft, Headless WordPress bringt dir wahnsinnig viele Vorteile und so weiter.

Da wäre es gut, wenn wir kurz auf das eingehen können, was ist das jetzt eigentlich, weil du hast das schon zum Teil erklärt, aber damit wir das vielleicht so von Grund aus vielleicht mal kurz aufschlüsseln, was überhaupt eine Headless-Architektur bedeutet und ist das etwas, wo man sich zum Beispiel ein WordPress-Plugin installieren kann und dann ist meine Website Headless oder wie kann ich das dann am besten verstehen oder wie schaut das dann in der Praxis aus, wenn man dann ein Headless-System bauen möchte mit WordPress? Und jetzt gibt's eine kurze Pause, weil ich würde dich gerne in das WP Office einladen Und im WP-Office, da triffst du neue und vielleicht auch alte WordPress-Kollegen und Kolleginnen, da lernst du neue Skills und Erfahrungen, die dir dabei helfen werden, deine Kunden langfristig erfolgreich zu betreuen und das Ganze basiert auf zwei Segmenten, auf zwei Fundamenten.

Also einerseits ist es eine komplett kostenlose WordPress-Community-Gruppe, wo du da an Fragen stehen kannst, du kannst Fragen von anderen beantworten und dich einfach austauschen und Dazu gehört dann auch zum Beispiel die regelmäßige Sprechstunde, die ebenfalls kostenlos ist.

Die findet einmal im Monat statt und da reden wir einfach über ein WordPress-Thema, tauschen uns aus, also quasi wie so ein kleines WordPress-Online-Meetup.

Und das zweite Fundament von WP-Office sind gezielte Online-Workshops.

Aktuell haben wir einen Workshop zum Thema Ladezeit von WordPress-Websites und wie man diese verbessern kann.

Das heißt, falls dich das Thema interessiert, dann schau einfach vorbei.

würde mich sehr freuen, wenn du dabei bist und wenn ich dich dort auch begrüßen darf.

Diese Workshops sind dann nicht kostenlos, weil da natürlich auch mehr Vorbereitungszeit rein fließt und die halte ich auch nicht alleine ab, aber die sind mega umfangreich und du wirst sicher extrem viel Wissen und Erfahrung aus den Workshops mitnehmen können.

Ja und weil du jetzt gerade bei der Podcast Episode zuhörst oder zuschaust, dann starte ich im WP Office dann noch zu jeder Episode eine Diskussion.

Das heißt, falls du darüber reden willst, falls du deine eigenen Erfahrungen zu dem Thema der Podcast-Episode teilen möchtest, dann mach das bitte im WP-Office, weil in den meisten Podcast-Apps gibt es keine Möglichkeit, um zu kommentieren.

Ja, weil das wäre einfach ganz cool, wenn dann zu der Podcast-Episode ein kleines Gespräch entstehen könnte.

Dann sehen wir uns vielleicht im WP-Office.

Der Link ist in der Beschreibung.

Wie gesagt, komplett kostenlos.

Melde dich einfach an und du bist dabei.

Und jetzt geht's weiter mit der Podcast-Episode.

Oder wie kann ich das dann am besten verstehen oder wie schaut das dann in der Praxis aus, wenn man dann ein Headless-System bauen möchte mit WordPress? Also, mir wäre jetzt kein Plugin bekannt, was das alles löst auf einmal.

Headless abstrahiert quasi das Frontend vom Backend in dem Fall, das CMS, arbeitet als CMS und über eine API rufe ich im Frontend die Daten ab, die ich dann in meinem WordPress-Admin eingebe, also meine Blogartikel, meine Seiten und so weiter und so fort, rufe ich über die API von WordPress ab und stelle die im Frontend dar.

Was hat das jetzt für Vorteile, außer dass es gerade sich super kompliziert vielleicht anhört und super komplex sich auch anhört? Ich bin im Frontend komplett variabel, was ich machen will.

Also ich kann, wenn ich mit React das Frontend bauen will, kann ich das einfach mit React bauen.

Wenn ich die Daten in eine App geben will, kann ich die Daten in eine App geben.

Wenn ich die Daten in eine Newsletter mit einfließen lassen will, kann ich die Daten auch in eine Newsletter mit einfließen.

Einfach, weil ich eine Abstrahierung habe zwischen dem CMS an sich.

Dort werden die Daten generiert, die Beiträge geschrieben und dann der ganzen Ausgabeschicht, die dann eben den Head darstellt und habe eine lose Kopplung.

Was hat es noch für Vorteile? Ja, es kommen dann viele natürlich sagen, es ist aufwendiger zu bauen und so weiter, muss man darüber diskutieren, keine Frage ist es natürlich.

Diese Flexibilität erlaubt mir aber auch mal und das ist ein ganz wichtiger Punkt, finde ich, aktuell in der aktuellen Situation auch, ich kann mein Backend, gut WordPress ist jetzt self-hosted bei uns, das ist jetzt weniger das Problem, aber angenommen, es gibt ja auch andere Headless, CMS-Systeme, Contentful und Co, angenommen dort ändert sich mal irgendwas an der Preispolitik, an der Art der Verarbeitung oder die Firma gibt es nicht mehr oder oder oder, dann muss ich mein Frontend nicht zwingend wegwerfen, sondern kann das einfach quasi aufsetzen auf ein anderes Headless CMS und habe dort eben eine entkoppelte Architektur.

Das ist der Vorteil, warum wir vieles, den großen Teil bei uns in Headless umsetzen.

Einfach, dass wir dort losgelöst sind und im Frontend einfach auch selber entscheiden können, wie wollen wir das bauen.

Soll es eine Single-Page-Applikation werden mit React, dann benutzen wir einfach React im Frontend und wenn das ein ganz normaler Twig-Template werden soll mit statischem HTML, dann bauen wir das eben auch da drüben.

Also wenn ich das jetzt mal so zusammenfassen kann, dann fällt einfach diese Schicht von WordPress weg, dass man Themes verwenden kann.

Also es wird einfach im Frontend nichts mehr ausgespielt über WordPress, sondern WordPress wird einfach nur wirklich nur dafür verwendet, um Daten einzugeben, Content zu bearbeiten.

Aber die Ausspielung der Daten im Frontend oder der Ansicht halt der Website muss dann custom entwickelt werden anhand von einer Webapplikation zum Beispiel mit React.

Und auf die Nachteile und Risiken von dem kommen wir gleich darauf hin.

Also das kommt dann gleich.

Da würde ich dann gerne noch den Begriff CMS aufschlüsseln.

Und da ist es ja so, ok, das hört man ja immer wieder, WordPress ist ein CMS, ein Content Management System, aber damit man das halt wirklich versteht, was sollte man dafür wissen oder was glaubst du ist das Essentielle bei einem CMS, dass man versteht, was das ist, weil man hat den Begriff zum Beispiel öfter gehört, aber was ist das Essenzielle, dass man versteht, damit man dann eben WordPress nicht nur als Blog nutzen kann, nicht nur als einfach simple Website, sondern was macht eigentlich ein vollwertiges CMS aus, weil WordPress war ja am Anfang kein vollwertiges CMS, es hat sich zudem entwickelt.

Und damit wir das Thema vielleicht auch ansprechen, was das überhaupt bedeutet, wenn ein System ein vollwertiges CMS ist.

Also für mich macht zum einen erstmal eine gute Datenerfassung, eine gute hohe Benutzerzufriedenheit im Backend ist erstmal ganz wichtig für ein sogenanntes CMS.

Ich brauche die Leute, die damit arbeiten, RedakteurInnen, JournalistInnen, wie auch immer, Betreiber von Webseiten müssen sich erstmal wohlfühlen mit der Erfassung der Daten.

So, das ist erstmal wichtig und da kann jetzt natürlich diskutieren, auch bei WordPress.

Ist das alles schön? Ist das alles gut? Gebe ich raus.

Punkt an alle anderen.

Kann ich verstehen.

Das ist erst mal ganz wichtig, dass die Daten sauber strukturiert erfasst werden können in einem CMS.

Was für uns ganz elementar sind, sind die Custom Post Types.

Ich muss unterschiedliche Entitäten anlegen können.

Also wir haben halt nicht nur einen normalen Artikel, sondern wir haben zum Beispiel bei einem Artikel einen Experten dabei.

Dieser Experte hat bestimmte Attribute, keine Ahnung, sei es die E-Mail-Adresse, sein akademischer Grad, seine Vita, was auch immer und ein Bild, keine Ahnung.

Damit muss ich flexibel sein, um das anlegen zu können.

Also heißt, ich muss mir erstmal meine Applikation natürlich anschauen im Grund, was habe ich denn da, was will ich denn bauen und dann muss ich das datentechnisch eben auch zurechtlegen.

Also, was brauche ich denn für Entitäten, für Models? Da kommen wir, glaube ich, nachher nochmal drauf.

Was brauche ich denn dafür alles und wie muss ich die aufbereiten, dass sich das funktioniert? Und dafür ist WordPress eben super geeignet, durch diese Custom Post Types, dass ich eben einfach eine Entität anlegen kann, die einfach beschreiben kann über Advanced Custom Fields, die editierbar machen kann, ohne Probleme.

Und das ist für uns essentiell bei der Wahl des CMS.

Wenn wir ein CMS nur zur Verfügung stellen, ich kann nur eine Seite quasi befüllen oder einen Artikel, dann limitiert das uns natürlich in der Arbeit, weil dann kann ich nicht sagen zu Kunden, ja, aber wir können da noch Experten hinzufügen oder Rezepte mitmachen oder Rechtstexte mit einfließen lassen.

Da bin dann eben limitiert mit der ganzen Geschichte und deswegen sind für uns die Custom Post Types, diese Entitäten in dem Fall, super, super wichtig.

Ja und wenn wir dann einfach unter die Haube schauen, dann gibt es natürlich Vor- und Nachteile bei jedem System und da ist WordPress da auch nicht ausgeschlossen.

Also ich finde, dass WordPress als CMS einfach wahnsinnig vielfältig ist in den Möglichkeiten, die es bietet, vor allem eben, wie du es angesprochen hast mit dem Custom Post Types und mit den Custom Meta-Feldern und das kann man sich jetzt alles auch mit Hilfe von Plugins wie z.

B.

ACF erstellen und so weiter und damit kann man schon wahnsinnig viel machen.

Und den wirklichen Benefit oder das wirkliche Potential sehen wir dann gleich, wenn wir uns dann z.

B.

die Design Patterns anschauen wie z.

B.

MVC und so weiter.

Da wollte ich einfach nur mal das Thema klären, was bedeutet das eigentlich, wenn ein System ein vollwertiges Content-Management-System ist und damit wir das abgehackt haben, weil dieses Vorwissen brauchen wir einfach, um dann später darauf aufzubauen, dass ich würde jetzt wieder gerne zurückspringen, also jetzt werden wir vielleicht ein bisschen viel herumspringen, aber springen wir zu der Headless-Architektur zurück, weil das hat ja viele Nachteile und Risiken und ich finde, dass es dann im Internet, auf LinkedIn und so weiter, oft als einfach die Zukunft von Web-Projekten gelabelt wird und so weiter, aber ich habe auch die Erfahrung gemacht, dass es halt nicht immer das ideale System ist oder die ideale Architektur, um Projekte zu bauen, weil das, was für mich halt ein mega großer Benefit ist, wenn man das WordPress-System Headless verwendet, ist, dass du halt ein zentrales Backend hast und da kannst du zum Beispiel die Website anknüpfen als React Website zum Beispiel.

Du kannst eine Mobile App anknüpfen, damit das die Daten von dort auch sorgt.

Du kannst alle möglichen Applikationen, Websites, alle möglichen Formen davon kannst du einfach mit dem kommunizieren lassen.

Da finde ich macht das mega viel Sinn.

Wenn das dann aber zum Beispiel nur eine Website ist oder nur ein Projekt ist, wo da nur eine Website darauf zugreift, ist finde ich das auch mit viel Overhead verbunden, das so umzusetzen und andererseits habe ich da noch die Erfahrung gemacht, dass zum Beispiel Headless oft hochgepriesen wird auf, hey, du hast viel bessere Performance.

Also zugegebenermaßen, wenn du jetzt ein schlechtes Theme verwendest und das komplex aufsetzt mit vielen Plugins, hast du eine schlechte Performance, das ist klar, aber wenn wir uns rein das anschauen, wie WordPress dann, wie du dann an die Daten kommst, dann ist, finde ich, immer die Kommunikation zwischen einem Headless-System dauert, finde ich, immer länger als einfach eine direkte Datenverbindung, die du dann in WordPress hast, wenn du zum Beispiel ein Custom Theme entwickelst.

Und was hast du dann von deiner Seite aus gemerkt? Wann ist eine Headless-Architektur sinnvoll? Wann ist es weniger sinnvoll? Mit welchen Nachteilen und mit welchen Risiken ist das Ganze verbunden? Damit man sich einfach dem bewusst ist und nicht einfach blind darauf glaubt, hey, Headless ist die Zukunft, wenn mir irgendwer ein Headless-System anbietet, dann muss das das Beste sein, sondern was sollte man da wissen, damit man eine bewusste Entscheidung treffen kann? Genau, also ich bin da auch kein Freund von diesen Schwarz- und Weißmalereien, es gibt ja dann immer, also generell, WordPress ist das Beste und es gibt nur WordPress, nee, es gibt auch andere Systeme und die machen das auch gut, ja.

Und weil wir jetzt Headless bei manchen Projekten verwenden, ist es auch nicht immer überall sicher einzusetzen.

Wie gehe ich denn da vor? Vielleicht einfach mal aus meiner täglichen Arbeit.

Ich gucke mir mit dem Kunden erst mal die Anforderungen.

Was wollt ihr denn haben? Und dann kommen die, ja wir hätten gerne vielleicht ein, nehmen wir ein konkretes Beispiel, ein digitales Produkt aus der Welt der veganen Rezepte.

Okay, alles klar.

Was plant ihr denn da in Zukunft noch mitzumachen? Soll es nur eine Webseite werden, eine Reichweitenseite werden, sollte es eine Applikation noch haben und so weiter und so fort.

Und dann geht man mit dem Kunden erstmal ins Gespräch und fragt auch mal, wo seht ihr denn das Projekt vielleicht in zwei, drei, fünf Jahren auch? Und was für Details, Anforderungen habt ihr denn überhaupt? Wenn dann natürlich rauskommt so von wegen, ja, eigentlich wird es nur eine normale, also in Anführungszeichen nur eine normale Webseite, soll auch nicht respektierlich sein, dann würde ich ihm nie so eine Headless-Architektur empfehlen.

Einfach wie du es gesagt hast, also dann ist WordPress dafür da, für was man WordPress entwickelt hat ursprünglich, bevor es dann die API gab, zu sagen, ich baue mir einfach meine Webseite dann eben komplett mit WordPress-Mitteln und da ist es dann auch gut.

Habe ich jetzt aber natürlich irgendwelche Themen, wie zum Beispiel, ich möchte irgendwelche React-Komponenten spezielle haben, oder es ist angedacht, die Daten nicht eben nur auf einer Webseite darzustellen, sondern vielleicht eben noch in einer App.

Dann kann ich natürlich sagen, okay, pass auf, dann lassen Sie es doch aber gleich richtig machen, dass wir dann das gleich abstrahieren und das dann gleich komplett auf Headless aufziehen.

Ich denke, das muss jeder einfach fallspezifisch bewerben.

Man kann nicht sagen, also ich würde, wäre ja in Anführungszeichen der Wahnsinn, wenn ich in der Gegend rumlaufe, würde ich sagen, ihr müsst alle jetzt, und Headless ist der heilige Kral und macht es und überhaupt und das ist das Beste, was ihr machen könnt.

Nee, das ist ja fatal.

Also ich glaube, man muss sich da die Anforderungen einfach mit dem Kunden gemeinsam anschauen und aber auch dem Kunden dann aufmerksam machen und sagen, hey, pass auf, wenn wir das Headless machen, dann ist es mehr Aufwand, als wenn wir jetzt die Seite komplett nur bei WordPress zusammenschrauben, aber du hast die und die Vorteile.

Oder wenn wir das nicht Headless machen, dann können wir das und das zum Beispiel nicht so einfach umsetzen.

Ich glaube, das muss einfach abgewogen werden, gemeinsam mit dem Kunden.

Ja, der Aufwand ist mehr, da müssen wir nicht darüber diskutieren, aber der Headless-Ansatz bietet natürlich einfach so viele Möglichkeiten, dass ich einfach noch andere Dinge mit reinziehen kann, APIs konsumieren kann von irgendwo.

Bei Benutzerberechtigungen, wenn ich jetzt nicht die WordPress-Benutzerberechtigungen verwende, sondern keine Ahnung eine SSO angebunden habe oder sonst irgendwo, dann bietet es natürlich so einen krassen Mehrwert.

Aber natürlich, wie du es gesagt hast, es ist nicht der heilige Gral von allem.

Man muss es immer abwägen und sagen, ist das tatsächlich der richtige Weg und da muss man einfach schauen, wie könnte sich das Produkt oder das Projekt in Zukunft auch entwickeln.

Ein kleiner Tipp von mir, fragt einfach immer den Kunden, wo sie das Projekt in zwei, drei Jahren vielleicht, was ist denn angedacht und dann entscheidet ihr einfach nochmal sauber darüber.

Was natürlich auch ist, die Komplexität in so einem Headless-Projekt wird natürlich erhöht.

Also ein guter PHP-Entwickler kann ein guter React-Frontend-Entwickler sein, muss es aber nicht.

Das heißt, ich habe dann schon mal natürlich dort nochmal einen zweiten Entwickler oder Entwicklerin zum Beispiel in dem Projekt vielleicht dabei, der dann das Frontend macht.

So erhöht natürlich die Komplexität der Zusammenarbeit dann wieder.

Wenn ich die Daten im Backend zur Verfügung stellen muss, brauche ich einen anderen Techstack als der oder diejenige, die es im Frontend zusammenschraubt.

Das heißt, dort arbeite ich dann schon vielleicht in kleinen Teams und wenn es nur Zweierteams sind, die Leute müssen sich schon mal abstimmen.

Das heißt, ich muss dann schon mal Schnittstellen definieren, welche Daten übergebe ich, kommen die auch sauber rein, wer validiert denn diese Daten, die da reinkommen, ist das die Aufgabe von Frontend, ist das die Aufgabe von Backend.

Ich habe einen höheren Verwaltungsaufwand auch, darf man auch nicht unterschätzen, wenn einfach immer mehrere Leute daran arbeiten, auch in unterschiedlichen Disziplinen, unterschiedlichen Programmiersprachen.

Das heißt, dort muss ich natürlich dann auch erstmal ein klares Regelset haben.

Wenn ich dann noch vielleicht Externe habe, dann wird es natürlich noch mal spannender, wenn ich mit einem Externen zusammenarbeite, weil das die Lieblingsfrontendagentur von Firma XY ist oder von meinem Kunden ist.

Dann muss ich mit denen vielleicht zusammenarbeiten.

Wie kann sich dann so ein Projekt entwickeln? Läuft es dann immer super? Arbeiten die vielleicht ganz anders haben, die eine andere Art zu arbeiten.

Auch das sind Themen, die man einfach auch in der Organisation mit überdenken muss.

Die Komplexität wird dann natürlich oder kann sich natürlich erhöhen.

Nicht alle sind vielleicht wie du Dominik, die alles dann entwickeln können.

Also die Frontend machen und Backend machen und hier und da und tralala, sondern ich brauche dann vielleicht nochmal eine zweite Expertin, einen zweiten Experten, der dann eben das Frontend zusammenbaut.

Dann muss ich mit Leuten zusammenarbeiten und dann wird das natürlich immer wieder, kann es, muss nicht, aber kann natürlich dann immer einfach wieder schwierig werden.

Ja, und ich finde das, was du jetzt gesagt hast, ist mega, mega wichtig, einfach am Anfang dem Kunden zu fragen, hey, was ist eigentlich das Ziel, wohin soll die Reise gehen, was sind die Anforderungen vom Projekt und so weiter, weil dann kann man halt wirklich nur eine informierte Entscheidung treffen.

Generell würde ich das immer empfehlen, wenn ihr ZuhörerInnen gerade da seid, redet einfach offen auch mit euren Kunden, Kundinnen drüber, wo das Projekt denn hingehen soll.

Ich finde, vielleicht kann der Kunde oder die Kundin das nicht technisch gut ausführen.

Vielleicht hat er auch noch nicht die Vision, wo es hingehen soll.

Aber ich habe gelernt in den 20 Jahren jetzt, wo ich in der Webentwicklung unterwegs bin, umso mehr ich von dem Kunden weiß, einfach wie der Kunde tickt.

Welche Mitspieler gibt es denn da vielleicht noch? Ja, hat das Marketing da vielleicht noch mitzusprechen oder ist der Geschäftsführer einer, der auf dessen das Wert legt? Lernt da auch wirklich eure Kunden kennen und auch die Projekte, was sie machen wollen.

Natürlich ist es einfach, einfach eine Seite hinzuklatschen.

Das kriegen wir alle hin.

Aber um eine hohe Kundenzufriedenheit zu haben, ist es, glaube ich, einfach super wichtig, den Kunden zu verstehen und auch potenzielle Mitspieler.

Wir haben zum Beispiel gerade aus der echten Welt ein Projekt.

Dort integrieren wir WordPress in ein Stellenportal.

Das funktioniert super.

Die Leute dort sind super fähig.

Das ist eine andere Firma, für die die arbeiten.

Aber wir arbeiten mit denen super zusammen und wirklich ExpertInnen in allen Bereichen macht total Spaß, aber wir merken halt einfach, da gibt es andere Anforderungen an den TechStack zum Beispiel, aus Datensicherheitsgründen, aus technischem Verständnis, aus den Leuten vielleicht, die auch dort arbeiten, die vielleicht auch nur bestimmte Themen können.

Das heißt, wenn wir jetzt nur mit unseren ursprünglichen Ansprechpartnern gesprochen hätten bei dem ganzen Thema, hätten wir eine andere Sicht der Dinge gekriegt, bevor wir mit den TechnikerInnen dann gesprochen hätten, die dann eben sagen, pass auf, aber wir können das nicht so einfach so und so machen oder wir können nicht einfach den und den TechStack verwenden, wie ihr jetzt gerade denkt, weil wir dort und dort Bedenken haben, mit dem und dem das zu machen.

Das heißt, nehmt euch die Zeit, sprecht mit euren potenziellen Kunden oder euren Bestandskunden, lernt sie richtig kennen, was das Thema angeht, fragt entsprechende Fragen auch nach und holt dann eben das Optimale für das gemeinsame Projekt raus.

Ich glaube, das ist so ein ganz wichtiges Auch gerade bei so Entscheidungen zu treffen, architektonische Entscheidungen, wie baue ich denn jetzt dieses Projekt auf? Einfach zu sagen, ich entwickle das letztlich gemeinsam mit dem Kunden, indem ich die Informationen von ihm kriege und versuche dann das Beste rauszuholen.

Das ist, glaube ich, ganz, ganz wichtig und das kann ich nur jedem Zuhörer, jedem Wort Zuhörerin empfehlen.

Sprecht mit euren Kunden.

Ich glaube, die sind auch dankbar.

Ich glaube, die nehmen sich diese Stunde oder zwei extra Zeit gerne, wenn sie dann eben auch merken, sie werden auch da gut beraten, und ihr in Anführungszeichen klatscht nicht einfach nur eine Webseite hin, sondern hinterfragt vielleicht auch bestehende Prozesse, die vielleicht auch in der Betriebsblindheit schon immer so waren.

Wir haben doch das immer so gerendert und es ging doch schon immer den und den Weg und es gab doch schon immer diese Kontroll-E-Mail-Ansage.

Wir kennen sie alle.

Also jeder, der in so SaaS-Projekten oder in so B2B-Projekten arbeitet, das war doch schon immer so.

Wieso sollen wir das denn hinterfragen, auch einfach mal Fragen stellen und sagen, ist denn der Prozess noch gut und dann die richtige architektonische Entscheidung treffen und dann kann das Headless sein, es muss nicht Headless sein, in vielen Situationen bietet sich es dann aber an.

Ja, und das ist dann immer schon so individuell von Projekt zu Projekt, dass man dann auch nicht sagen kann, hey, wenn diese Anforderungen da sind, dann macht das Sinn.

Es sind dann diese Details, auf die es ankommt, weil ein Beispiel, was ich jetzt gehabt habe, ist oder vor kurzem gehabt oder aktuell dann auch kommen wird, je nachdem, wie man es definiert, aber das muss ja nicht von Anfang an headless sein zum Beispiel.

Wenn man jetzt eine Website baut, zum Beispiel ein Portal mit Profilen für irgendwelche Experten und so weiter, dann passt das, dann kann man das mit Hilfe von Custom Post Types bauen und so weiter.

Die Nachteile in der Datenbankstruktur sind dann wiederum ein anderes Thema, aber das lassen wir mal vorne weg.

Gehen wir mal davon aus, die Daten sind sauber aufgesetzt im Backend ohne Performance-Problemen, auch von der Anzahl der eingetragenen Experten zum Beispiel.

Und das ist alles mit einem Page Builder zum Beispiel mit Bricks zusammengebaut oder mit einem Custom Theme und das passt und später entwickelt sich das weiter.

Die Person, die das betreibt, also in dem Fall dann der Kunde, sagt, hey, wir haben immer mehr Umsatz, wir wollen das weiterentwickeln.

Wir wollen den Experten jetzt ein Custom-Dashboard zur Verfügung stellen.

Aber die wollen das jetzt nicht mithilfe eines Plugins machen, weil dann die Website vielleicht überladen ist, sondern die wollen halt die Website in sich lassen, eine Frontend-Applikation dazu bauen, wo sich die Leute einloggen können, aber gleichzeitig wollen die die Expertenprofile nur im Becken von WordPress bearbeiten und anlegen.

Und da bietet es sich, finde ich, super an, dass es sich zu einem Headless-System zum Teil weiterentwickelt, weil dann kannst du Mithilfe eben da, was du vorher angesprochen hast, über die API, da sind wir den Begriff immer noch nicht aufgeschlüsselt, aber das ist einfach nur ein Weg, wo man halt mit dem Headless-System von WordPress dann kommunizieren kann, über die WordPress-API, kann man dann zum Beispiel die Webapplikation, das Dashboard für die Experten bauen und das kommuniziert dann über die API mit dem WordPress-System, aber die Website läuft noch immer nach dem klassischen WordPress Schema.

Also es gibt kein, das muss 100% Headless sein oder nichts Headless, sondern da gibt es auch viele Zwischenlösungen und viele Graustufen dazwischen dann auch.

Total und da ist es, wie du es gesagt hast, auch der Weg ist natürlich auch ein gangbarer zu sagen, ich baue das 100% erstmal auf WordPress Mitteln und knüpfe danach die API an.

Die API habe ich, die muss ich nicht nochmal entwickeln, die gibt es schon bei WordPress.

Das heißt, da muss ich nicht noch mal irgendwas reinziehen oder irgendwie noch mal 20 Euro im Monat mehr zahlen, dass die API freigeschaltet wird.

Die API gibt es, die kann ich verwenden und das heißt auch, wie du es gesagt hast, auch ein Weg ist natürlich zu sagen, wenn ich eine Weiterentwicklung habe, wie kann es dann vielleicht dieses Teilprojekt dann Headless zum Beispiel zu machen.

Deswegen richtiger Ansatz einfach auch zu hinterfragen, was haben wir bisher gemacht, ist das der Weg, kann ich das damit umsetzen oder möchte ich das vielleicht jetzt den Teil raus extrahieren und den eben headless darstellen.

Richtiger Ansatz, genau.

Also auch ein total gangbarer Weg zu sagen, ich mache es nachträglich vielleicht oder teile eben nur headless.

Ja und da würde ich extrem gerne jetzt mal in das Thema eintauchen, was wir vorher so angeteasert haben, diese Software Design Patterns, weil wenn man aus der Softwareentwicklung kommt, dann hat man diese irgendwann kennengelernt und da haben wir vorher das MVC eben erwähnt.

Headless ist auch eine Art von Architektur, von Design Pattern, was wir jetzt ausführlicher besprochen haben und da gibt es zum Beispiel auch die N-Tier Architektur und diese ganzen Sachen und für Softwareentwickler ist es finde ich ja gang und gäbe, dass man diese kennt, aber wenn du jetzt Beispiel Programmierer bist und dir WordPress, also PHP, JavaScript eher so nebenbei angelernt hast, dann ist es relativ selten, dass du diese Patterns kennengelernt hast.

Aber wenn du diese Patterns kennst, dann helfen dir diese wahnsinnig viel, WordPress einfach als ein vollfertiges CMS zu sehen und zu sehen, was man da wirklich für ein Potenzial nutzen kann in dem System.

Und nach welchen Designprinzipien, Designpatterns richtest du dich normalerweise? Ist das dann nur das MVC oder auch andere? Oder vielleicht können wir auch gerne darauf eingehen, was genau MVC ist und wie das funktioniert, wie man das verstehen sollte, damit man das jetzt zum Beispiel, wenn jetzt jemand nur Webdesign macht oder ich sage jetzt mal technisch bisschen feinere Sachen dann auch im WordPress-Backend, aber jetzt nicht unbedingt ein Software-Developer ist.

Wie sollte man das am besten verstehen, damit es mir dann in der täglichen Arbeit mit WordPress hilft und was ist dann das Potenzial in WordPress, wenn man das auf das WordPress-System übersetzt? Also um auf das MVC fangen wir einfach mal damit vorne an.

Generell, finde ich ist es immer wichtig sich mit dem Rahmen und den Parametern zu beschäftigen.

Nur weil ich jetzt in Anführungszeichen nur Contents baue und sage, ja ich baue halt meine CSS Klassen rein und meinen SAAS Prozess und so weiter, ist trotzdem wichtig, das drumherum zu verstehen.

Einfach auch um zu verstehen, wie könnte ich denn eine Applikation, eine Webseite aufbauen, welche Verantwortlichkeiten gibt es denn vielleicht und auch gerade wenn man mit anderen dann zusammenarbeitet, werden immer wieder mal so Patterns eben fallen.

Wir können die natürlich einzeln beschreiben.

Eine gute Seite kann ich nur empfehlen, an denen ich das viel gelernt habe, war damals laracast.

Das ist von dem Gründer von Laravel eine Videoplattform.

Da kann man sich alle Videos mal anschauen.

Da werden schön erklärt, Design Patterns erklärt, was ist es überhaupt und so weiter und so fort.

Also jeder der sich da mal weiterbilden will.

Ich habe da keinen Gutscheincode für euch oder sonst irgendwas.

Der Affiliate-Link ist dann in der Beschreibung.

Genau.

Na Spaß.

Die Podcast-Episode enthält keine Produktplatzierungen.

Genau.

Ne, also da habe ich zum Beispiel gelernt, aber es gibt natürlich auch viele Entwicklerinnen oder Software-Developer bei YouTube, die das auch erklären zum Beispiel.

Einfach da gerne mal reingucken.

Was haben wir mit dem MVC gemacht? Früher war ja dieses EVA-Prinzip immer so gang und gäbe an der PHP-Datei.

Also ich hatte oben irgendwelche Parameter, die reingekommen sind, also das E, die Eingabe, dann habe ich die Verarbeitung gehabt, heißt ich habe irgendwelche Berechnungen gemacht oder irgendwie noch eine Datenbankabfrage oder das irgendwo noch weggeschrieben und hatte dann unten das A, die Ausgabe, also dieses EVA-Prinzip, war so die, ich sag mal, so Nullerjahre rum hat man viel in diesem EVA-Prinzip dann gearbeitet.

Als dann die Objektorientierung kam, hat man dann gesagt, naja, okay, man muss es auch so ein bisschen vielleicht trennen.

Schön ist auch dieses SOLID-Prinzip.

Ich werfe das jetzt einfach mal rein, weil ich glaube, wenn wir das alles erklären, dann könntet ihr, also googelt das mal, das SOLID-Prinzip, dann könnten wir, glaube ich, hier noch, wobei wir ja dann beim WordCamp sind wir doch an der Uni, vielleicht können wir da einfach auch eine Vorlesung dazu halten, wobei da gibt es dann bessere ExpertInnen natürlich, die das noch besser erklären können.

Genau, also da gab es das EVA-Prinzip, heißt Daten kamen rein, wurden verarbeitet und es gab eine Ausgabe und das war alles in einer Datei.

Wer hat, wer ohne die guestbook php Datei auskam in den Nullerjahren hebe die Hand oder die was weiß ich was also es waren so typische typische Sachen die man eben früher hatte dann hat man das ganze Objekt orientiert auch mehr und mehr aufgegliedert hat dann Klassen eben gehabt hat dann eben auch einzelne einzelne Verantwortlichkeiten dann geschaffen und dann gab es dann eben unterschiedliche Patterns also um mal eins meiner Lieblings-Pattern zu nehmen, das Repository-Pattern zum Beispiel, also ein Repository anlegen, was sind die Verfügbarkeiten, Daten beschaffen, Daten schreiben und so gibt es eben die unterschiedlichsten Pattern.

Das MVC, was wir jetzt vorhin mal angesprochen haben, das Model View Controller, trennt eben die Verantwortlichkeiten vom Model, also von der Entität, der Datenbank kann man sagen, also die Daten, die in der Datenbank stehen, werden in einem Model zur Verfügung gestellt quasi, hat noch ein bisschen Business-Logik.

Dann gibt es das V, ist der View, also die Ausgabeschicht quasi und dann gibt es den Controller.

Der Controller macht jetzt bei uns in dem Fall das Routing, gibt die Informationen weiter, holt noch ein paar Informationen von hier und von da, bereitet das alles vor und übergibt es quasi dann an die Vue nach vorne.

So bauen wir das auf, deswegen haben wir damals diese Elemente Slots bei uns eingeführt, dass wir die Daten nehmen können von WordPress.

Wir haben uns dann auch noch Laravel und Eloquent in bestimmten, aber das würde jetzt zu weit führen und auch wahrscheinlich nur technisch verwirren, hinzugefügt.

Das heißt, wir nehmen uns eine Entität, nehmen wir zum Beispiel einen Experten, ja, also wir haben einen Experten-Slot, wir nehmen uns einen bestimmten Experten von einem Beitrag, der damit verknüpft ist, holen den quasi aus der Datenbank, aus dieser verzogenen Datenbankstruktur, die historisch gewachsen ist, ziehen die uns da quasi raus, bereiten die auf mit bestimmten Daten, also ziehen vielleicht ein Bild von irgendwo, berechnen vielleicht sein Alter und so weiter und so fort und geben diese Daten dann im Controller, in dem sie abgefragt werden, durch an die Vue und stellen dann eben diesen Experten da.

Dadurch haben wir einfach eine Trennung und eine klare Verantwortlichkeit.

Also die Vue macht bei uns keine Business-Logik, sondern, also wir berechnen da nichts mehr, sondern die ist tatsächlich nur bei uns da, um die Darstellung zu übernehmen.

Controller bereitet das Ganze auf, zieht sich die ganzen Daten, macht auch Teile der Logik rein und das Model an sich, die Entität ist eben das gespeicherte, kann man jetzt vereinfacht sagen, in der Datenbank, was wir ausziehen, also der Custom Post Type zum Beispiel und das wird dann quasi dadurch.

Also das ist so vereinfacht gesagt unsere MVC Architektur, die wir da haben.

Auch dort ist es wie mit, du musst Headless verwenden, da gibt es immer leichte Abwandlungen.

Es gibt immer so Graubereiche, wann ist der Teil jetzt eher für den Controller gedacht und wann kommt er eher in ein Model.

Auch dort steckt drei Entwickler in einen Raum und du hast vier Meinungen darüber, was jetzt genau in einem Controller nur sein darf und was in einem Model.

Aber prinzipiell ist es natürlich gut und wichtig, wenn man sich mit diesen Pattern einfach mal beschäftigt, die sich einfach mal anguckt, kann euch einfach nur helfen, dieses Wissen.

Und in Bezug jetzt auf WordPress, weil das ist ja ein eingemeines Software-Design-Pattern, aber an sich ist ja egal, ob jetzt WordPress als ein Headless-CMS verwendet wird oder nicht, das MVC-Pattern, das gilt ja immer, auch wenn jetzt zum Beispiel das WordPress-System nicht als Headless-System verwendet wird, sondern ganz klassisch mit einem Theme hast du ja Model, View, Controller, also Model, Datenbankverbindungen, Custom Post Types und so weiter, View, Theme, Custom Theme, was auch immer, Page Builder und Controller halt alles dazwischen.

Wenn ich das jetzt so auf WordPress übersetzen kann, oder? Genau, richtig.

Also so kannst du das eigentlich in WordPress, also die groben Disziplinen zu einordnen, genau.

Ja, Weil ich verwende dann immer zum Beispiel, ich meine, das ist das Gleiche nur im Blau, zum Beispiel die n-Tier-Architektur, also n als quasi so eine unbekannte Zahl an Tiers, die man dann einbauen kann und insofern, dass was dann auch auf dem basiert, ist zum Beispiel, dass man am Anfang dann den Data-Layer hat, dann den Business-Layer und dann den Presentation-Layer und das ist genau das Gleiche nur in Orange oder in Grün.

Also du hast den Data-Layer, Datenbank-Layer, dann im Business-Layer die ganze Logik, wie wird dann die Website zusammengebaut, wie werden die Daten aufarbeitet und so weiter und dann den Presentation-Layer, was in dem Fall klassisch WordPress halt dieses Theme ist oder Custom-Theme oder sowas.

Und in dem Fall, wenn wir das wieder mit Headless vergleichen, ist einfach bei Headless nehmen wir den Presentation-Layer oder eben die Views in dem Fall beim MVC und teilen das, spalten das auf und verpacken das in was eigenes, was nicht in WordPress integriert ist, sondern was eigenstehendes ist und das kommuniziert dann mit WordPress und WordPress hat dann einfach den Data-Layer, Business-Layer oder die Models und die Controller alle drinnen und in die Richtung kann man das dann auf WordPress übersetzen oder hättest du da irgendwas zum ergänzen oder siehst du das von einer anderen Perspektive? Ich sehe es genauso wie du und ich glaube das ist ganz wichtig, dass man dieses Verständnis hat eben und dann kann man sich auch noch mal einordnen, wie kann ich denn so ein Headless vielleicht einordnen, so eine Headless Architektur einfach dann, dass ich sage, okay die View kann ich dann eben raus extrahieren zum Beispiel oder ich kann eben um das N-Tier Beispiel jetzt einfach noch mal nehmen, kann natürlich dann einfach über die API quasi die API konsumieren und kann da einfach noch eine Schicht reinziehen, was auch immer eine Authentication-Layer zum Beispiel, der nur prüft, darf überhaupt dieser angemeldete User in der Session diesen Beitrag zum Beispiel überhaupt sehen.

Und deswegen hast du das eigentlich, also ich sag mal so, ich glaub's dir.

Ich nehm's dir ab, das hast du sehr gut beschrieben.

Ne, aber so kann man es genau machen.

Also ich find das sehr gut beschrieben.

Sehr cool.

Ja und alles, was wir jetzt besprechen, das klingt halt alles so, als wäre das alles Custom-Entwicklung, Custom-Code, alles von Grund aus selbst programmiert und so weiter.

Also mega aufwendig, du brauchst dafür Fachleute, die sich da auskennen, die Erfahrung haben und das Ganze.

Aber wenn dann schon so ein Projekt entsteht mit höherem Budget, es sind Fachleute dabei, es ist eine höhere technische Komplexität da, wieso baut man das nicht einfach dann alles selbst von scratch? Also wozu braucht man dann eigentlich WordPress, wozu nutzt man dann eigentlich WordPress, Wenn man kann sich ja genauso gut, ich weiß nicht, eine eigene Datenbank erstellen, dann irgendeine Business-Logik in Form einer Custom-Web-API zur Verfügung stellen und dann eine Frontend-Applikation bauen.

Also inwiefern braucht man dann eigentlich auch WordPress, ist dann WordPress eigentlich so reingeklatscht, damit es da ist, hat es dann doch einen Sinn WordPress zu verwenden oder wie schaut das aus, weil wenn man sowieso schon so viel custom macht, wozu braucht man dann eigentlich noch WordPress? Gute Frage.

Hören wir auch immer wieder, warum denn eigentlich WordPress? Ihr könnt doch dann quasi das alles schon selber bauen.

Lassen wir mal das Technische weg und gehen einfach mal auf das, was es wichtig ist und das sind deine ZuhörerInnen zum Beispiel, die sich in der WordPress Community mitbeteiligen.

WordPress, wir haben es gehabt, war am Anfang ein klassischer Reiseblog vielleicht und wir machen einfach mal irgendwie ein paar Fotobilder drauf und ich setze da mal kurz was auf.

Durch die ganze Community, durch den Open-Source-Gedanken und ich weiß WP Drama ist jetzt vielleicht auch nicht das beste, das leuchtendste Beispiel für funktionierendes Community-Management, aber dennoch sind dort Leute am Werk aktuell und in der Vergangenheit, die dieses WordPress, dieses Open-Source-Projekt nach vorne treiben.

Die das weiterentwickeln, die dann neue Features einbauen.

Letzte große Feature, diese Gutenberg-Blöcke zum Beispiel.

Das sind einfach riesen Geschichten.

Natürlich könnte man ein CMS, also wirtschaftlich gesehen wäre es natürlich wahrscheinlich ein Wahnsinn, aber könnte man auch selber bauen, irgendwo.

ja aber durch das was da alles durch die community einfließt durch leute die jetzt gerade zuhören die sagen hey ich baue da ein plugin vielleicht für ein ganz spezifisches problem das vielleicht keine ahnung 20 webseiten auf der welt haben gibt es einfach immer wieder input von außen der das rechtfertigt WordPress zu nehmen.

Das sind die Plugins zum Beispiel.

Yoast SEO, ich glaube fast jeder hat es schon mal verwendet oder kennt es irgendwo.

Alleine, dass ich mich darum nicht kümmern muss, wie denn eigentlich meine Meta-Tags aufgebaut sein müssen, hilft einfach so einem Projekt schon weiter.

Dass ich so Sachen eben wie Gutenberg-Editoren habe, die einfach das in einer wunderbaren Eingabemöglichkeit uns zur Verfügung stellen, dass wir Daten oder dass wir Webseiten zusammenbauen können.

Oder aber auch Elementor zum Beispiel.

Auch klar sitzen wir immer da dann, als wenn gesagt, Elementor, das ist ja nur zusammenklicken.

Ja, mag sein.

Aber auch das hat seine Daseinsberechtigung, weil es eben auch viele Leute im Marketing gibt, die sagen, ja, ich muss jetzt hier eine Marketingseite bauen und ich habe halt einfach nicht IT für sechs Semester studiert und ich muss mit meinen Mitteln das irgendwie machen können, dass ich jetzt da zum Erfolg komme.

Deswegen gibt es da immer Rechtfertigungen in meinen Augen, das in WordPress zu nehmen und ich finde halt tatsächlich und ich möchte jetzt gar nicht zu geopolitisch werden, aber es gibt einfach immer mehr Gründe zu sagen, ich benutze ein Tool, also jetzt kommen wir gerade weg von diesem selber entwickeln, aber trotzdem es gibt immer Gründe zu sagen, ich benutze ein Open Source Tool mit einer guten Community dahinter, poste das irgendwo selbst oder bei einem Hoster meines Vertrauens in meinem Land, das meine Datenschutzrechte hat und so weiter und so fort, weil diese SaaS-Dienste ist einfach und wir haben das auch erlebt in der Vergangenheit, wir hatten dort auch ein Hoster, super Angebot, war alles super fancy, haben wir alles gemacht, klasse und hier mit klicken und so weiter, ja, der hat dann irgendwann einfach die Preise so drastisch erhöht, dass wir gesagt haben, oh, hoppla, was machen wir denn jetzt, cool, die ganzen Features, die wir darauf aufgebaut haben und so weiter und so fort.

Automatisches Deployment und so weiter und so fort.

Was machen wir jetzt eigentlich damit? Haben wir jetzt ja ein Problem.

Oder auch eine kleine Geschichte aus meinem eigenen Leben.

Ich fahre seit einiger Zeit einen Tesla.

Würde ich mir nicht mehr kaufen, weil da einfach jemand jetzt das für sich einfach komplett da irgendwie und ich möchte jetzt nicht politisch werden und so weiter, Aber komplett irgendwie, wie beschreibe ich es denn am humansten, der einfach komplett durchspitzt, würde ich jetzt sagen, der einfach durchdreht in irgendeiner Art und Weise, würde ich mir einfach nicht mehr kaufen.

Jetzt weiß ich natürlich auch, dass es bei einem SaaS-Projekt nochmal was anderes ist, aber lass es einfach bei einem SaaS-Projekt die Preise erhöhen, Datenschutzanforderungen sich ändern, wie auch immer.

dann habe ich erst mal ein Problem und deswegen verwenden wir WordPress gehostet bei uns.

Also wir hosten das dann beim Kunden auf den ihren Systemen und wir wissen dann wir haben den Code und sind im Besitz von diesem Code.

Ja jetzt noch mal um die Frage zurück natürlich könnte man selber schreiben wirtschaftlich wahrscheinlich der Wahnsinn würde wahrscheinlich kein Kunde zahlen und man belächelt immer so dieses WordPress.

43 Prozent, die kennen ja glaube ich alle deine ZuhörerInnen, 43 Prozent aller Webseiten laufen eben, selbst die NASA hat ihre Webseite auf WordPress aufgebaut und alles was Taylor Swift in die Hand nimmt wird Gold, deren Seite läuft auch übrigens auf WordPress.

Und wenn wir das einfach nochmal sagen, weil es immer so belächelt wird, dieses WordPress, auf das wollte ich zurückkommen jetzt um den Bogen, weil ich mich jetzt kurz einmal gedreht habe, um auf diesen Bogen nochmal zurückzukommen.

Es wird immer belächelt, aber es hat eine wahnsinnige Daseinsberechtigung in meinen Augen durch die Community, durch die Leute, die das weiterentwickeln, durch die Leute, die das vorantreiben, durch die Leute, die bei WordCamps sich austauschen, die Plugins entwickeln dafür, die am Core weiterarbeiten und so weiter und so fort.

Deswegen wäre es wirtschaftlich, könnte ich das keinem Kunden mit einem guten Gewissen verkaufen, zu sagen, wir bauen ein eigenes CMS.

Da sind die Wartungsaufwände vorhanden, da sind Features, die man aufwendig neu schreiben müsste oder sich irgendwo über ein Composer-Paket reinziehen müsste, vorhanden.

Ich würde Abhängigkeiten zu ganz vielen anderen Entwicklern aufbauen und so weiter.

Also in dem Sinne, man kennt ja alles, auch dieses eine Thema, wo das halbe Internet lahm gelegt wurde.

Ich glaube, war es irgendeine Curl, eine Library, die irgendwo injected wurde bei ganz vielen Projekten und an dieser einen Library hat sich was geändert und dadurch haben ganz, ganz, ganz viele andere Libraries und Projekte und Composer-Pakete nicht mehr funktioniert.

Lange Rede, kurzer Sinn, wirtschaftlich würde ich es nicht machen, macht absolut keinen Sinn.

Und ich habe keine Community hinter mir, die das wartet, ich habe keine Community hinter mir, die das weiterentwickelt und die mir auch vielleicht helfen kann, weil wenn ich was eigenes baue, bin ich erstmal auf mich alleine gestellt.

Ich musste selber damit klarkommen und da habe ich viel geredet, aber kurze Antwort, nee, machen wir nicht.

Wirtschaftlich würde es nicht bringen, nein.

Nein, ich finde, dass du es genau richtig erklärt hast, weil das ist auch das, wieso ich sehr gerne WordPress verwende und wieso ich halt riesengroßer Fan davon bin.

Also einerseits immer haben wir halt einen Bias, weil wir halt dank WordPress ein Gehalt bekommen und Geld verdienen und dann bist du immer halt pro WordPress, weil du einfach dein Leben damit finanzieren kannst, also hast du dann schon automatisch seinen Bias.

Aber rein möglichst objektiv gesehen, finde ich alle diese Punkte, die du jetzt aufgezählt hast, ja, da kann ich mich einfach zu 100% unterschreiben.

auch von der technischen Seite, wenn wir jetzt viel über Headless gesprochen haben und so weiter.

Da hast du halt auch die Vorteile, dass halt viel von diesem zum Beispiel Data Layer und Business Layer mitkommen.

Du hast schon eine Datenbankverwaltung, du hast schon eine Benutzerverwaltung, du kannst Custom Posts selbst erstellen und so weiter.

Und das ist, finde ich, schon so viel die geleistet wurde.

Ich habe da jetzt nicht viel mit Laravel gearbeitet, aber da kannst du dir dann auch verschiedene Libraries, Packages installieren, gell, für die Benutzerverwaltung und so weiter.

Ist auch schon da, aber es ist halt ein höherer Aufwand, finde ich, das aufzusetzen, als jetzt einfach WordPress zu installieren.

Fertig, WordPress hat eine REST-API, die du sofort ansprechen kannst und du kannst loslegen mit der Frontend-Entwicklung der Applikation zum Beispiel.

Und man hat natürlich schimpfen dann immer viele über auch dieses Backend und so weiter wie das Backend und das ist ja nicht so modern und so cool und fancy und überhaupt.

Aber aus meiner Erfahrung arbeiten halt ganz viele gerne damit, weil es simpel und reduziert ist in einer gewissen Art und Weise, weil es einfach gelernt ist über Jahre und Jahrzehnte, weil wahrscheinlich jeder mal irgendwo im Marketing oder jeder Redakteur oder sowas vermutlich schon mal irgendwo Kontakt mit WordPress hatte und sei es im privaten Umfeld, das darf man auch nicht vergessen, dass viele Leute dann vielleicht in die Vereinswebseite, du machst doch da irgendwas mit Medien, du kannst doch bei uns die Vereinswebseite auch machen, das ist nämlich auf WordPress aufgesetzt und dann irgendwie schon Kontakt damit hatten oder sonst irgendwas, das können die einfach dann mitnehmen und sagen, hey, pass auf, dann nehme ich das mit, das Wissen, was ich dort habe, kann es in meinem Alltag wieder einsetzen.

Durch die Gutenberg-Blöcke kann ich den Content mir zusammenstecken, wie ich will und den Gutenberg-Block, den es nicht gibt, den kann man sich entwickeln lassen und ich habe dann quasi genormte Daten eben, die da sauber drinstecken und nicht jeder Twitter-Link, halt wir machen für Twitter jetzt keine Werbung mehr, jeder Mastodon und BlueSky-Link sieht dann anders aus und wird ein anderes Snippet verwendet, so kann ich jetzt eben einfach sagen, ich baue mir über die Gutenberg-Blöcke das alles schon vor.

Deswegen muss ich sagen, ich bin, kann es jedem nur empfehlen, weil einfach auch viele, das darf man nicht unterschätzen, einfach auch in der Freizeit zum Beispiel schon irgendwo Kontakt haben mit WordPress vielleicht.

Wie gesagt, jemand hat vielleicht mal selber früher einen Blog aufgesetzt, für das was WordPress ja gedacht war, macht die Vereinswebseite oder, oder, oder, hat da vielleicht schon Erfahrungen mit.

Deswegen auch da die Akzeptanz von den KundInnen, von den Leuten, die damit arbeiten, ist ganz, ganz wichtig, Weil, wenn man was selber baut, dann steht man immer erst mal in Konkurrenz zu bestehenden Sachen.

Und bestehende Sachen, dann heißt es nämlich immer, ja, aber bei Typo3 kann ich doch das machen und bei Contentful kann ich doch das machen und da kann ich doch die Eingabe so machen, warum habe ich denn nicht solche Blöcke, das ist doch cool, das gibt es doch.

Das heißt, immer wenn ich was eigenes baue, für den Kunden stehe ich erst mal in indirekter Konkurrenz mit bestehenden Projekten oder Produkten.

Und dann ist es natürlich immer erst mal, ja, aber ich hätte jetzt gern so einen Knopf, wie die da eben auch haben, um diese Funktion dann zu machen und so weiter und so fort.

Und dann baue ich quasi aus Erfahrungen 90 Prozent WordPress, 10 Prozent Typo3 irgendein Zwischending, das irgendwelche Funktionen hat, dann kann ich doch gleich sagen, ich nehme WordPress, das ist, da wisst ihr, was ihr kriegt, das ist sofort aufgesetzt.

Wir verwenden da hauptsächlich das Bedrock dafür, das heißt, wir customisen das dann mit den Composer-Paketen eben und installieren da drüber unsere Plugins und so weiter und so fort.

Das heißt, auch der Kunde kann da nicht irgendwelche Plugins wild installieren und sagen, ach, jetzt mache ich da das drauf und das drauf und das drauf, sondern das können wir, das haben wir programmatisch eben reglementiert.

Genau, und das ist auch was, was man nicht unterschätzen darf.

Die Leute, die damit arbeiten, müssen sich damit wohlfühlen und automatisch, wiederhole mich, stehst du in Konkurrenzen, das ist nicht gut meistens für die Akzeptanz intern für das Projekt.

Ja, voll.

Und ja, da falls du als Zuschauer oder Zuschauerin, Zuhörer oder Zuhörerin da jetzt eigene Erfahrungen gemacht hast oder deine Meinung gerne teilen würdest, dann gerne in den Kommentaren oder dann eben später auch im WP-Office, da wird dann eine Diskussionsrunde gestartet zu dem Thema natürlich.

Und welches Thema ich noch gerne ansprechen würde, was halt an sich dann als Konsequenz mit sich geht, wenn man jetzt komplexere WordPress-Systeme erstellen möchte oder WordPress-Konstrukte, je nachdem wie man das benennen möchte, ist das dann oft diese Tendenz da ist zum Over-Engineering.

Das heißt, du hast dann eine Anfrage so, ja, ich brauche eine Website für das und das, das soll da sein, vielleicht dann irgendwelche Expertenprofile und so weiter und dann, ja, der engagierte, motivierte Entwickler so passt perfekt, ich mache das alles in Custom-Datenbank-Strukturen, ich mache das alles Headless mit Frontend-Applikation und so weiter und das Ganze und dann dauert das zehnmal so lange und das Ergebnis ist nach wie vor das gleiche, als würde man eine Website bauen damit, aber was ist dann dieses Over-Engineering, weil jeder hat schon glaube ich damit mal Erfahrungen gemacht, also mehr Vorarbeit geleistet, als das dann im Endeffekt notwendig war, aber welche Erfahrungen hast du damit gemacht? Da kann ich auch eine nette Geschichte erzählen von einem Kollegen, Sven, grüße an dich.

Überragende Entwickler, super Architekt, wirklich, aber der hat sich mal so, der hat mal in so einer Zeit gelebt, dass er alles mit irgendwelchen Interfaces dekoriert hat, quasi was er gemacht hat.

Es gab dann eine Zeit, da musste man gefühlt eine Viertelstunde von Interface zu Interface springen, um an die richtige Code-Stelle erst mal zu kommen, was natürlich wahrscheinlich in irgendeiner Lehre das Optimale gewesen wäre, das so zu bauen, aber es war einfach ein riesen, ein riesen Interface-Schlachten.

Hat er auch dann einen Schritt zurückgemacht, hat er gesagt, ja, war vielleicht ein bisschen zu viel over-engineert eben.

Und da ist es halt auch wichtig.

Letztlich, die meisten von uns arbeiten ja irgendwo mit der Zeit, also auf Zeit irgendwo, was dann auch dem Kunden zur Rechnung gestellt wird.

Ich bin kein Freund davon, alles zu bedenken und im Vorfeld durchzuplanen und Möglichkeiten offen zu halten.

Wenn der Kunde ganz klar sagt, es wird keine App geben für mich, das brauchen wir nicht, was auch immer, gibt es für dieses Projekt nicht, dann nehme ich das auch erst mal als gegeben.

Natürlich kann ich jetzt sagen, aber wenn ich das Ganze, vielleicht überlegt er sich es in zwei Jahren ja nochmal anders.

Da kann ich sagen, da lasse ich doch hier jetzt nochmal die und dann kann ich das schon vorbereiten, dass wir dann eventuell eine App hier verwenden können.

Da muss man einfach abwägen, was will der Kunde, wo soll es wirklich hingehen, was sind definitive Aussagen und wenn der Kunde zu mir sagt, nein Herr Braunstein, ich möchte keine App haben, dann kann ich das festhalten, kann sagen, also wir bereiten das auch so vor, dass es keine App gibt.

Wenn er dann zwei Jahre später kommt und sagt, ich hätte gern jetzt aber noch eine App, Dann würde ich sagen, können Sie sich noch daran erinnern, als wir da beim Kaffee bei Ihnen saßen, hier habe ich gerade nochmal den Aufschrieb rausgeholt, haben wir gar nicht vorbereitet, weil es sonst einfach in der initialen Geschichte zu teuer geworden wäre.

Auch dort muss man einfach immer wieder abwägen, was will der Kunde, ich muss ihn verstehen, ich muss die Anforderungen hundertprozentig verstehen und dann muss ich mich hinsetzen und sagen, was ist eine effektive Art und Weise zu arbeiten.

Natürlich kann ich überall einen Cache dazwischen hauen oder ein was weiß ich was performante Datenbanken hochziehen und High End, Hochverfügbarkeits Cluster haben und so weiter und so fort.

Die Frage ist, brauche ich das für eine Vereinswebsite? Wenn zu mir jemand kommt, ich habe eine Vereinswebsite, möchte eine Vereinswebsite zum Beispiel haben, was auch immer, dem muss ich das auch nicht Headless anbieten, weil ich dann auch weiß, der wird das nicht an einen Shop anbinden im ersten Step oder wie auch immer.

Da gilt es einfach zu gucken, was der Kunde wirklich braucht.

Was ist sinnvoll? Man soll jetzt auch nicht sagen, ich baue das Minimum für ihn ein.

Wir Schwaben sind ja so, so günstig wie möglich dran kommen, das Sparsame, so sind wir ja.

Trotzdem muss ich sagen, okay, was ist sinnvoll? Das ist auch immer ganz wichtig, ein partnerschaftliches Verhältnis mit dem Kunden haben.

Der Kunde muss einem vertrauen.

Das ist, wie wenn ich nachher zum Autohaus gehe und sage, hier ist mein Auto und der sagt, oh Herr Braunstein, Ihr Fluxkompensator ist kaputt und ich habe keine Ahnung von Autos.

Wirklich, ist für mich ein Gebrauchsgegenstand und dann sage ich zu dem ersten Mal, oh mein Fluxkompensator, Mensch, habe ich noch nie gehört, aber gut, ich vertraue Ihnen.

Das hat auch was mit Seriösität zu tun.

Deswegen meine ich, natürlich kann ich alles Mögliche reinhauen und überdenken und vorplanen und offen halten.

Letztlich geht es darum, den Kunden zu verstehen, den Weg hin zu verstehen, wo sehen sie die seit in zwei, drei Jahren, was sehen sie da für Features und dann muss ich das sauber planen und bauen.

Und deswegen ist das ganz schön mit WordPress eigentlich schon zu arbeiten, weil da habe ich das meiste schon.

Da habe ich nicht die Möglichkeit, 14 Interfaces dahinter zu klatschen erstmal.

Also kann ich machen, ist dann kompliziert und umständlich und da wird jeder Entwickler sagen, was mache ich eigentlich gerade hier selber, aber da habe ich eigentlich schon ein Set schon vorgegeben und kann es nicht mehr groß beeinflussen.

Das ist das Gute, glaube ich, an der Geschichte WordPress zu verwenden, zu sagen, ich habe einfach mein Set schon, ich habe eine bestimmte Spielwiese schon, ich bin nicht komplett auf der grünen Wiese, da gehen eben bestimmte Sachen leicht oder bestimmte Sachen halt nicht und deswegen ist das schon mal gut, ein vorgefertigtes System zu verwenden, ob's dann WordPress ist oder was anderes, sei mal dahingestellt, aber da wir ein WordPress-Podcast sind, nehmt WordPress.

Aber prinzipiell ist es dann natürlich, hab ich es dann natürlich schwieriger, schon mal irgendwas zu over-ingenieren an bestimmten Bereichen.

Also so nach dem Prinzip sollte man immer vorgehen, keep it simple und falls dann irgendwie der Bedarf ist, dass man das irgendwie groß aufbauen soll, dann ist auch glaube ich genug Budget da, dass man das halt vielleicht auch von scratch wieder neu machen kann oder so.

Genau, auch da, wie gesagt, Kunde sprechen mit dem Kunden, einfach das rausloten und sagen, hey, pass auf, natürlich können wir das vorbereiten, du musst aber damit rechnen, das sind jetzt schon mal die und die Aufwände mehr, die wir da haben dafür, ist es dir das wert? Also siehst du das denn auch dann? Und da einfach offen und transparent drüber reden über die ganzen Geschichten und dann kann er selber entscheiden, wenn er sagt, Herr Braunstein, ich möchte aber den Fluxkompensator jetzt in mein Auto eingebaut haben, dann bauen wir den diesen Fluxkompensator natürlich ein, obwohl wir es erstmal vielleicht davon abraten werden und das ist, glaube ich, auch ganz wichtig, da offen und ehrlich einfach kommunizieren.

Dann durch Kommunikation, meistens entsteht eigentlich so eine Softwarearchitektur in diesen Gesprächen schon mit dem Kunden, einfach um zu verstehen, was er will.

Meistens kommt dann auch das raus, was er dann auch braucht.

Das heißt, nicht mal technisch groß reden, malt euch vielleicht die Prozesse auf, die der Kunde hat, auf dem Board mit dem Kunden gemeinsam und dann entsteht automatisch eure Microsoft-Architektur oder eure Headless-Architektur oder was auch immer.

Und da einfach gucken und dann einfach das Beste für euer gemeinsames Projekt dann einfach rauszuholen.

Und das Thema, was für mich persönlich jetzt ein bisschen wichtig ist, wo ich immer wieder damit konfrontiert werde online, ist dann auch, dass du halt immer wieder Leute siehst, die sich halt betiteln auf LinkedIn oder sowas.

Ich sage jetzt nicht, dass das schlecht ist, sondern das ist einfach nur so, wie ich das persönlich sehe.

Keine Ahnung, WordPress-Experte, Web-Designer und so weiter, aber dann schreiben zum Beispiel oft viele Leute WordPress-Developer rein, aber wenn du so ein bisschen näher hinschaust oder wenn du mit den Leuten sprichst oder mal die Person näher kennenlernst, dann bemerkst du, die Person, die kann gar nicht entwickeln oder kann gar nicht programmieren, sondern kann jetzt technisch sehr viel mit WordPress-Plugins konfigurieren, aber ja, einfach sich Webdesigner zu nennen ist dann doch zu wenig, aber jetzt ein vollwertiger WordPress-Developer oder Developerin ist er oder sie dann auch nicht, weil wenn man halt nicht so tief programmieren kann, ist es dann auch so eine Sache und das was dann noch dazu kommt ein Level weiter, gibt es dann auch die Programmierer und die Software-Developer und da ist finde ich auch ein Unterschied, mit jemandem zusammenzuarbeiten oder wenn jemand ein Projekt technisch umsetzt, ist das dann wirklich eben so ein, sage ich jetzt mal unter Anführungszeichen, WordPress-Developer, ist das ein Programmierer, ist das ein Software-Developer, kannst du das von deiner Seite vielleicht aufschlüsseln, die Begriffe, was das jeweils bedeutet und welche Vor- und Nachteile man jeweils hat, wenn man mit so einer Person zusammenarbeitet oder welche, ja, ich lasse einfach mal reden und sag mir bitte deine Perspektive auf diese Themen.

Also genau, Disclaimer, meine Perspektive, und auch da wird man wahrscheinlich drei Leute vier Meinungen haben, ein reiner Programmierer, also ich behaupte in meiner Anfangszeit, als ich Großrechner-Sachen entwickelt habe, und da war das organisatorisch auch so ausgelegt, da war ich reiner Entwickler.

Und zwar habe ich da an Großrechnern auch an einzelnen Projekten und Programmen gearbeitet, aber dort wurde eigentlich alles vorgegeben.

Was ich machen muss, wie ich es machen muss, welche Zeit ich dafür habe, welches Budget zur Verfügung steht und so weiter und so fort.

Das heißt, auch gar nicht böse gemeint, aber ich habe einfach nur den Code runtergetippt.

Ich war eigentlich nur da und war eigentlich, heute würden wir es wahrscheinlich über eine KI machen, habe eigentlich nur das umgesetzt.

Natürlich muss ich dann wissen, welche Klasse oder welche Funktion muss ich dafür ansprechen und so weiter und so fort.

Aber eigentlich habe ich erst mal nur das umgesetzt, was ein Softwarearchitekt dann damals oder eine bestimmte Stelle eben ausgegeben hat und dann hochgerechnet hat, wie lange darf der dafür brauchen und habe das umgesetzt.

Schönes Beispiel, wir mussten damals zum Beispiel, der alte Mann erzählt von früherer Softwareentwicklung, Wir mussten damals bei den Großrechnern, gab es immer ein Statement, das musste in jedem Code drin sein, durfte aber nie verwendet werden.

Aber der Interpreter musste eben sehen, ja, diese Zeile Code ist drin, durfte aber nie angesprochen werden.

Deswegen gab es dann damals von einem Softwarearchitekten das entwickelte Statement, das werde ich nie vergessen, if weihnachten gleich ostern denn für diese zeile aus und da war dann dieses statement drin der interpreter war erst mal glücklich oder der compiler war erst mal glücklich hat gesagt war cool ist drin passt haken dran fertig da war ich ein programmierer und habe das einfach umgesetzt was quasi von mir gefordert waren software developer oder developerin beschäftigt sich eben halt auch noch mit mehr.

Ich finde, es müssen immer wieder mal Entscheidungen getroffen werden, auch ganz einfachen Entscheidungen.

Ist denn, um jetzt mal ein praktisches Beispiel nochmal rauszuholen, ist die Aufgabe dieser Klasse oder dieses Patterns eben überhaupt das, was sie macht oder vermischen sich da vielleicht Aufgaben.

Muss ich denn vielleicht eine gewisse Aufgabe in einen Service extrahieren, in ein Repository auslagern, ins Model mit übergeben und so weiter und so fort.

Das sind Entscheidungen, die in meinen Augen ein Software-Developer, eine Software-Developerin treffen muss und treffen kann.

Das heißt, Solid-Prinzip erfüllt, sie muss sich mit Patterns auskennen, sie muss nicht nur die Programmiersprache kennen, wie sie entwickelt, sondern tatsächlich halt, wie entwerfe ich denn auch Code, lesbaren Code, wiederverwendbaren Code, wie halte ich diese Solid-Prinzipien denn ein? Und da ist es ganz wichtig, einfach einen Programmierer, ich weiß nicht, ob es noch so viele Programmierer in dem Sinne gibt, also in der Webentwicklung weiß ich nicht, zumindestens habe ich schon lange nicht mehr viele gesehen, muss man schon in der aktuellen und der modernen Webentwicklung muss man schon auch diese Prinzipien verstehen und muss auch eben auch wissen Entscheidungen treffen und auch Code bauen, der von mehreren verstanden wird und nicht nur den eigenen Code.

Programmiere glaube ich, es sind so die Jungs aus den Nullerjahren, die irgendwas machen hier im Kellerchen und von mir aus irgendwas zusammenbauen, was vielleicht auch gar keiner versteht, weil sie gar keine Schnittstellen mit irgendwelchen anderen Teams haben und so weiter.

Und ich würde sagen, meine Definition ist ein Software-Developer muss eben halt die Software entwickeln, weiterentwickeln.

Ein Programmierer setzt eigentlich nur Code um, den andere quasi im Kopf vorgedacht haben und er dann nur sagt, okay, alles klar, das mache ich mit der Funktion, da ziehe ich mir die Funktion rein, das baue ich so runter, die eigentlich nur runterschreiben.

So würde ich das definieren.

da denken wir, finde ich, sehr ähnlich.

Also ich habe dann nur eines zum ergänzen, das hast du schon auch erwähnt, aber ich wollte es nochmal betonen, dass Software-Developer eben aktiv die Entscheidung treffen müssen, aber auch alle Konsequenzen, so gut es geht durchdenken sollten.

Das heißt, wenn du zum Beispiel jetzt die Anforderungen hast, hey, du hast ein Portal mit Stellenanzeigen und du kannst dafür jetzt zum Beispiel ein Plugin auswählen, wo du dann das anzeigen lassen kannst, eine Suche hast mit Filtern und so weiter und die kleinen Sachen, da passt du einfach das Plugin mit den PHP Hooks und Filtern an, oder Actions und Filtern besser gesagt, dann musst du halt auch das bedenken, okay, was ist, wenn dann jetzt zu viele Stellenangebote drinnen sind und das alles verlangsamt wird und die Suche, die von dem Plugin kommt, einfach nicht effizient gebaut wurde, weil das liegt dann außerhalb von deiner Kontrolle, wie effizient dann der Code geschrieben wurde oder wie effizient dann die Daten aus der Datenbank geholt werden.

Und dann macht das zum Beispiel Sinn, in manchen Fällen zu sagen, ja okay, es gibt Plugins dafür fertige Plugins, aber der Kunde wird langfristig damit nicht happy sein, weil es halt viele Limitierungen gibt.

Und dass es einfach teilweise dann auch weniger aufwendig ist, dann das von scratch selbst zu programmieren, weil man eben schon diese potenziellen Bottlenecks, Risiken und so weiter, diese Fallen kennt.

Aber da muss man dann auch, finde ich, einiges an Erfahrung haben und viele Fehler gemacht haben, damit man diese Sachen erkennen kann.

Und das ist, finde ich, das, was da noch einen Software-Developer wirklich da noch von einem Programmierer unterscheidet.

Ein Programmierer sagt so in die Richtung hat dieses Mindset, ja passt, mach ich schon, wird schon irgendwie.

Und ein Software-Developer denkt das durch, schaut, hey, welche Potentialen, Gefahren gibt's da und welche Fallen kann ich vermeiden und trifft anhand von dem einfach dann die Entscheidung, damit das bestmöglich dann verläuft, das Projekt umgesetzt wird und der Kunde auch wirklich langfristig happy damit ist.

Genau und glaube ich auch, was da dazu führt, das mache ich gerne mit meinen Jungs und Mädels in meinem Team eben, dass wir auch sagen, wir nehmen auch viel Software EntwicklerInnen bei uns, haben auch viel Kontakt mit Kunden.

Einfach, um auch noch mal auf der technischen Sicht zu sagen, natürlich kommt eine Anfrage vom Kunden, der sagt, ich hätte gerne das so und so gebaut und als PM, jetzt kann ich entwickeln und verstehe natürlich auch und kann dann natürlich auch Vorschläge machen, was wir machen können, aber nicht jeder hat vielleicht eine abgeschlossene Entwicklerausbildung oder hat als Entwickler gearbeitet oder entwickelt noch vielleicht selber und deswegen ist immer auch wichtig, finde ich, dass ein Software-Developer auch die Folgen vielleicht für den Kunden erwähnen könnte und sagen könnte, ja klar können wir das so machen, ist dann halt aber scheiße, weil anders wäre es besser, lass es uns anders machen, weil dann haben wir hier nicht das Problem und so weiter, ist auch nicht jedem seine Sache, müssen wir nicht darüber diskutieren.

Software Developer sind nicht unbedingt immer die extrovertiertesten Menschen und wollen auch nicht immer den Kundenkontakt haben, das ist auch okay, das muss man auch respektieren und akzeptieren, aber wenn man dann natürlich jemanden hat, der sagt, ja, ich kann mit dem Kunden einfach auch reden oder wenn es nur über die Ticketkommunikation ist, einfach ein Kommentar zu schreiben, dann auch zu sagen, hey, Kunde, natürlich können wir das auch so machen, aber lass es uns doch vielleicht so und so.

Da haben wir doch vielleicht nochmal eine andere Chance.

Auch total wichtig und gehört sicherlich auch zum heutigen Berufsbild dazu, dass du halt nicht nur einfach dieser Programmierer bist, der einfach sich hinter seiner IDE versteckt und Sachen einfach umsetzt.

Haben wir bei uns gar nicht mehr oder weiß ich, ob es das überhaupt mal in der Agentur gab, aber kann man sich auch, glaube ich, heute in Zeiten von KI und Co auch nicht mehr erlauben, einfach zu sagen, ich baue nur noch den Code und jeder, der das aktuell macht, würde ich ermutigen, schaut auch mal über den Tellerrand und guckt einfach, dass ihr vielleicht den nächsten Step für euch selber weiterentwickelt, baut selber kleine private Projekte mit auf, lernt einfach, lernt aus Fehlern, wie es Dominik gerade gesagt hat, super wichtig, lernt einfach auch aus euren Fehlern.

Jeder macht von uns Fehler und jeder hat irgendwo jetzt gerade bestimmten Projekt im Hinterkopf, wo er sagt, da habe ich einen großen Fehler damals gemacht oder das habe ich ordentlich an die Wand gefahren geführt.

Das gehört dazu, das gehört zum Lernprozess dazu, aber wichtig ist dieses Weiterbilden, glaube ich, auch in unserer Branche und das ist, ich glaube, Entwickler ist jetzt nicht wie ein, auch das soll gar nicht disrespektierlich sein, wie ein Landschaftsgärtner, ja, es kommt einfach dazu, dass wir sagen, hey, ich arbeite mich einfach weiter an bestimmten Themen durch und lerne daraus und schau, was kommt als nächstes, wie ändert sich die nächste PHP-Version, wie ändert sich die nächste WordPress-Version, was bringt es für Vorteile für uns, was können wir denn da vielleicht nutzen, wie kann ich denn da meinen Programmierstil vielleicht anpassen, Mentorenprogramme, redet mit anderen EntwicklerInnen irgendwo und zeigt mal euren Code vielleicht und fragt, was kann ich besser machen.

Auch da ist es ganz wichtig, einfach sich weiterzubilden.

Entwickler ist nicht dieser Speditionskaufmann, der halt jeden Morgen in die Spedition fährt und irgendwo eine Dispo macht von A nach B, sondern unsere Technologie ist so im Wandel und wie wir es jetzt haben und vom Programmierer zum Software-Developer, das könnt ihr wahrscheinlich auch einfach nochmal eine Folge machen, ist einfach auch ein komplett spannender Prozess, weil einfach dieses Mindset für den Software-Developer ist einfach ein anderes als das von dem Programmierer deswegen kann ich nur die ZuhörerInnen ermutigen, bildet euch da einfach immer wieder weiter, hört Podcasts, lest irgendwelche Berichte oder Abhandlungen durch und zeigt euren Code einfach.

Ja, und ich glaube in diesem Sinne können wir dann langsam die Episode beenden, weil da haben wir schon, habe ich gerade auf die Uhr geschaut, schon über eine Stunde gequatscht und wir haben dann noch ein paar andere Themen vorbereitet gehabt, wie zum Beispiel, eh, wie wichtig ist jetzt React in WordPress, weil das ist ja ein sehr, sehr wichtiger Bestandteil jetzt von WordPress, also was sich dann unter der Haube von dem Blockeditor versteckt und so weiter.

Und da werden wir sicher noch einige Themen finden, aber das wäre auch eine gute Überleitung, dass wir das auch einfach direkt vor Ort auf dem WordCamp in Wien machen können.

falls du dann irgendwo dann als Zuhörer oder Zuhörerin da bist, bitte, ja, falls du dann Fragen an den Stefan hast, die du gerne persönlich klären würdest, kannst ihn dann gerne auch für WordCamp fragen.

Am Ende stelle ich dann auch immer so drei Bulletfragen, damit dich die Leute etwas besser kennenlernen können und davor lasse ich dir gerne den Spotlight, falls du irgendwas bewerben möchtest, irgendwas in den Spotlight stellen möchtest, dann macht das bitte jetzt.

Was ich bewerben oder möchte vielleicht die Zeit zu nutzen, einfach euch noch mal zu ermutigen, diese Community zu ermutigen, einfach da weiterzumachen.

Ich glaube, es ist gerade super wichtig zu sehen, wie wichtig Open Source Projekte sind.

Man muss nur über den Teich gucken, was da gerade mit Daten passiert, mit Datensicherheiten passiert und so weiter und so fort und umso wichtiger ist es, dass man sich in Projekten wie WordPress oder in anderen Themen engagiert.

Das würde ich einfach sagen, lasst euch da nicht entmutigen.

Wir sind mehr als ein Reiseblog und eine lustige Rezeptesammlung.

WordPress kann so viel mehr.

Da möchte ich euch einfach ermutigen.

Bleibt da dran.

Lernt, tauscht euch aus.

WordPress hat so eine tolle Community, finde ich.

Wenn man auf so einem WordCamp rumläuft, trifft man die interessantesten Menschen, bleibt da einfach dran und ja, das kann ich einfach nur weitergeben.

Lasst euch da nicht entmutigen, weil es in Anführungszeichen nur WordPress ist.

Ja, perfekt.

Zu den Bulletfragen.

Ja.

Wenn es alles, was du machst, wenn es das nicht gäbe, also von Affenfels, du arbeitest nicht mehr dort, es gibt kein WordPress, du bist kein Entwickler, Teamleiter und Lead Developer.

Was wäre dein alternativer Beruf? Ich habe mir da lange Gedanken gemacht und witzig ist tatsächlich, man hat immer irgendwas mit Pflanzen im Kopf.

Das haben wir schon einmal gehabt.

Ja, in anderen Episoden haben viele gesagt, und selber habe ich das auch so gedacht, was wäre denn eigentlich so tatsächlich so ein Beruf, wo ich sagen würde, Mensch, das wäre es jetzt dann was.

Also ich bin Sportfan in sämtlichen Sachen und ich würde wahrscheinlich dann in so Physiotherapie-Bereich vielleicht reinschnuppern wollen, so Sportverletzungen behandeln, bei großen Verletzungen wieder zurückkommen, Fitnessberatung und sowas.

Da würde ich mich dann so im sportlichen Bereich, da irgendwo würde ich mich sehen, wenn wir nichts digitales mehr auf dieser Welt quasi hätten, was man entwickeln könnte.

Und was ist das nervigste WordPress-Feature? Das nervigste WordPress-Feature? Ja, da wir das WordPress nicht ganz so verwenden, wie wir es eigentlich verwenden sollten.

Das ist eine sehr gute Frage.

Was ist eigentlich das nervigste WordPress-Feature? Ich glaube, es ist gar nicht, kommt entsetzlich, es ist gar nicht das WordPress-Feature selber, sondern es ist manchmal die Denkweise, wie manche über WordPress reden und denken.

Das ist so das, was mich so tatsächlich so am meisten nervt.

Und das ist so, natürlich hat WordPress, wir müssen nicht darüber reden, über die Datenbankstruktur und so weiter und so fort.

Also technisch müssen wir nicht darüber reden, dass es da auf jeden Fall Baustellen gibt und man kann immer alles besser machen über ein historisch gewachsenes Projekt und so weiter und so fort.

Aber das ist so was, was mich, glaube ich, so abseits vom Code, da wir halt das WordPress tatsächlich nicht so verwenden, wie wir es verwenden, glaube ich, mit am meisten nervt.

Ja, da kann ich mich eigentlich voll unterschreiben.

Das habe ich so als in der Form noch nie so wirklich, also schon darüber nachgedacht, nie so aktiv wahrgenommen, aber das stimmt natürlich.

WordPress wird dann oft einfach schlecht geredet, einfach weil es schlecht geredet gehört oder warum auch immer.

Auf einem anderen Spektrum, was ist dein Lieblings-WordPress-Feature? Ja, auch da.

Es gibt viele coole Sachen.

Also, ich bin ein totaler Fan von den Gutenberg-Blöcken.

Finde ich total cool, wie das umgesetzt ist, was es für Möglichkeiten bietet, da einfach seine Seite oder seinen Artikel so zusammenzustecken.

Finde ich ein ganz cooles Feature.

Ich finde die API, die dann einfach von Haus aus mitkommt, super.

Ich glaube, auf die zwei Sachen, die API, die uns natürlich irgendwo so die Lifeline ist zum WordPress ist wichtig, aber auch die Gutenberg-Blöcke finde ich total tolles Feature, auch eigene Gutenberg-Blöcke zu entwickeln, finde ich cool, weil es einfach einen Mehrwert bringt für die KollegInnen, die dann damit arbeiten, da sauber die Daten zu erfahren.

Sehr cool.

Gibt es noch irgendeine finale Message, die du gerne an die Zuhörerinnen, Zuhörer, Zuschauer, Zuschauerinnen weitergeben möchtest? Kommt nach Wien.

Besucht WordCamps tatsächlich.

Also es ist super wichtig in der Community, auch wenn man vielleicht nicht der High-End-Entwickler ist.

Und vielleicht hat auch die Folge in Anführungszeichen erstmal viele abgeschreckt und gesagt, um Gottes Willen, über was reden die jetzt da eigentlich? So verwende ich das ja gar nicht.

Oder bin ich schlecht oder nicht mehr so gut oder was auch immer, gar nicht.

Sucht, kommt gerade zu WordCamps.

Ich war letztes Jahr in Karlsruhe, war eine ganz fantastische Veranstaltung.

Wien, Leipzig, wo überall auch.

Geht dahin, besucht es, besucht WordPress Stammtische, besucht andere Formate, die vielleicht auch online stattfinden.

Einfach tauscht euch aus, habt da keine Berührungsängste, holt euch einfach Wissen und lasst euch nicht entmutigen, das weiterzumachen, auch wie gesagt, wenn jetzt vielleicht viele Fachbegriffe gefallen sind, mit denen ihr vielleicht erst mal jetzt noch nichts anfangen konntet, aber trotzdem nutzt eben WordCamps und wenn wir jetzt natürlich mit Dominik reden, dann natürlich das WordCamp in Wien.

Besucht es auf jeden Fall, Wien, eh eine schöne Stadt.

Ich freue mich auf jeden Fall, wenn ich dort bin.

Kommt auf mich zu, Sprecht mich an, sprecht den Dominik an.

Ich glaube, tauscht euch mit den Profis aus, also mit den Profis, die jetzt anders vielleicht entwickeln wie ihr oder den anderen Weg fahren.

Kommt auf die zu, holt euch da Wissen oder wenn ihr einsteigen wollt, vielleicht auch da einfach mal vorbeigucken.

Es sind immer tolle Veranstaltungen.

Sehr cool.

Ich glaube, das ist ein wirklich schöner Abschluss.

Die ganzen Links, Sachen, die wir erwähnt haben, auch in Bezug jetzt aufs WordCamp oder zum Beispiel auch das WordCamp Europe kommt ja dann auch im Juni und so weiter.

Es gibt es gibt viele Events, das werde ich dann einfach unten verlinken in der Beschreibung.

Alle Kontaktdaten natürlich zum Stefan, LinkedIn, alles wo du halt, wo du im Internet zu finden bist, werde ich dann unten verlinken und ja, dann freue ich mich schon auf das Gespräch im WP-Office, was dann für Erfahrungen und so weiter von den Leuten kommen, falls ihr dann Fragen habt.

Das könnt ihr dann auch dort stellen.

Da könnt ihr dann auch, weil in den meisten Podcasting-Apps kann man nicht kommentieren, deswegen geht dann dort einfach das Gespräch weiter.

Und ja, vielen, vielen Dank, Stefan, für deine Zeit.

Hat mich sehr gefreut.

Sehr gerne, jederzeit wieder.

Und wir sehen uns dann jetzt in Kürze dann im April, Ende April in Wien.

Freue ich mich.

Sehr cool.

Dann vielen Dank und schönen Tag noch.

Ich weiß Ich weiß nicht, wann das die Leute hören, aber ja.

Werden wir dann irgendwann zusammen schneiden.

Macht's gut!.