Drei Minuten zu früh.
Okay, der Stefan erzähltuns, warum man über
einen Headless-WordPress-Ansatznachdenken sollte.
Ja, vielen Dank.
Wird jetzt natürlich ein schwerer Talknach dem tollen Mittagessen.
Erstmal vielen Dank auch an dieOrganisatoren.
Ich glaube, wir haben bisher sehrspannende Talks gehört hier und ich hoffe,
ich kann da ein bisschen anschließen, kanneuch ein bisschen Inspiration mitgeben.
Ich habe mir das Themaausgesucht, Headless, warum man
über einen Headless -WordPress-Ansatz nachdenken sollte.
Damit fange ich einfach mal an.
Wer bin eigentlich ich?
Ich bin der Stefan Braunstein,bin von der Agentur von Affenfels.
Man hört es, ich komme aus Stuttgart.
Für uns ist es immer ganz besonderes,in Karlsruhe aufzutreten als Schwaben.
Ich bin bei uns bei von Affenfels für diePHP- und WordPress-Entwicklung zuständig.
Und habe früher Teilnehmerinnen undTeilnehmer in der Gruppe.
Ich habe tatsächlich selber entwickelt.
Mittlerweile ist immer weniger.
Ich habe noch auf einem guten alten Großrechnerbei einer Bausparkasse entwickelt.
Also ich habe so ziemlich alles durch biszur Web-Entwicklung.
Bevor ich einsteige, eine Frage an diegesamte Gruppe.
Wer hat denn von euchbereits den Headless-Ansatz
irgendwo schon malimplementiert, eingebaut, verwendet?
Eins, zwei.
Okay.
Und wem sagt prinzipiell derHeadless-Ansatz etwas?
Ah, das sind schon mehrere.
Genau.
Ich will euch einfach heute einen kleinenEinblick geben.
Wie verwenden wir denn denHeadless-Ansatz?
Was machen wir?
Warum ist es vielleicht gut, den zuverwenden?
Und warum verkauft sich da manchmal dieWordPress-Community so ein bisschen,
in Anführungszeichen, kleiner als sieeigentlich ist?
Weil, wir fangen mal mit einem Vorurteilan.
Das hören wir häufig von Kunden.
Wir betreuen hauptsächlich Leute aus demVerlagswesen.
Da kommt hauptsächlich erstmalder Vorwurf, das WordPress
könnt ihr doch jetzteigentlich nicht verwenden.
Damit macht man dochvielleicht mal so einen Reiseblog
oder Rezepte stellt mandamit dar oder sonst irgendwas.
Ja, dafür war es ursprünglich entwickelt.
Aber wenn ich jetzt einfach mal auf dienächste Slide springe.
Und die Zahl kennt ihr bestimmt,diese legendären 43 %.
43 % aller Webseiten aufder ganzen Welt oder im
ganzen Internet sind aufWordPress-Basis gebaut.
In der ganzen Agentur-Geschichte kommenimmer wieder Kunden und sagen,
ja, aber das WordPress ist ja kostenlos.
Und das kann doch dann auch nicht sorichtig sein.
Es gibt große Content-Management-Systeme,die kosten einiges.
Und die wollen natürlich dann sagen,aber wieso denn das WordPress?
Das ist doch wie gesagt, ich habe vorherdas Vorurteil.
Ich gehe gerade nochmal zurück.
Das ist doch nur für Reiseblogger.
Was bringt denn das?
Deswegen haben wir gesagt, okay,pass auf.
Wir können alles, was diese großenContent-Management-Systeme auch können
eben auch mit WordPressdarstellen.
Und dazu würde ich erstmal weiterspringen.
Was könnt ihr eigentlich erwarten von mirheute?
Ihr könnt von mir heute keinen Code sehen.
Ich habe keine Code-Beispiele dabei.
Ich möchte euch einfach Inspirationmitgeben.
Ich möchte euch zeigen, wie verwenden wirden Headless-Ansatz?
Wie könnt ihr den vielleicht verwenden?
Was könnt ihr denn vielleicht für einenMehrwert rausziehen?
Kurz zum Inhalt.
Vorgestellt habe ich mich schon.
Die Einleitung habe ich schon.
Wir schauen uns kurz an.
Was ist denn Headless?
Wie ist es aufgebaut?
Was für Vorteile bringt es?
Was für Nachteile bringt es?
Weil überall, wo Licht ist, ist natürlichauch Schatten.
Ich habe ein paar klassische Use Casesmitgebracht.
Also für was wäre denn eigentlich so einHeadless-Ansatz interessant?
Und am Schluss habeich noch ein Finale mit fünf
Tipps bei mir aus derPM-Brille mitgebracht.
Weil so ein Headless-Ansatzbedarf noch ein bisschen
mehr, als nur zu sagen,ich mache jetzt Headless.
Wir steigen mal ein.
Was ist denn überhaupt dieses Headless?
Also ich habe hier das Ganze malaufgezeichnet.
Auf der von euch linken Seite sieht manden traditionellen Weg.
Ich habe quasi ein monolithisches Systemaufgebaut.
Das heißt, ich habe mein CMS-System,habe Backend und Frontend relativ hart
verquickt und habe dann eineAusgabeschicht.
Der Headless-Ansatz, der entkoppelt dasGanze ein wenig.
Über die API.
Das heißt, ich habe mein CMS-System,konsumiere dann entsprechend die API und
kann dann über die API diverse Applikations-oder Frontend-Ebenen ansprechen.
In dem Fall könnte es eine Applikationsein.
Es kann eine normale Webseite sein.
Es kann ein Variable sein.
Es kann aber auch irgendein Drittsystemsein.
Durch diese Entkopplung.
Wir haben das eingesetzt bei einem Portalfür Kinder.
Kinderunterhaltung, also für Kindergärtenwerden dort nicht Animationsprogramme,
aber was können Kindergärtnerinnen quasidie Woche über mit den Kindern veranstalten?
Haben wir zum Beispieldas Frontend und die
App konsumieren daquasi einheitlich die API.
Dadurch ergeben sichdurch diese Architektur,
ergeben sich einfachauch ein paar Vorteile.
Und die möchte ich jetzt einfach mal draufeingehen.
Und zwar.
Ich habe hier mal vier Vorteilemitgebracht.
Man könnte noch philosophieren,ob es noch ein paar weitere Vorteile gibt.
Das erste ist die Flexibilität undSkalierbarkeit.
Dadurch, dass ich das Frontend vom Backenderstmal entkoppelt und über die API
konsumiere, kann ich natürlich nach obenhin flexibel skalieren.
Das heißt, ich kann eine App mir davorsetzen.
Ich kann das Ganze über eine Webseitekonsumieren.
Ich kann aber auch die Datenzweitverwerten.
Ein weiterer Punkt bei der ganzenGeschichte ist auch die Sicherheit.
Dadurch, dass ich das Frontend erstmal vomBackend entkoppelt, habe ich natürlich
erstmal die API als angreifbaren Punkterstmal dastehen.
Aber das Frontend an sich ist entkoppeltvom Backend.
Das heißt, ich habe dadurch auch für dieWartung, wenn ich das Frontend warte,
warte ich das Frontend, muss aber nichtzwingend alles am Backend machen.
Dadurch habe ich einfach eine erhöhteSicherheit und eine Wartung.
Dadurch, dass ich frei bin in derTechnologieauswahl im Frontend,
kann ich natürlich auch sagen,hey, ich möchte halt nicht das normale
Rendering verwenden von WordPress,sondern ich möchte zum Beispiel React
verwenden oder eine sonstigeFrontendsprache, was mir
natürlich dadurch einen gewissenTeil an Speed bringen kann.
Was natürlich auch noch zu bedenken ist,da komme ich aber nachher noch dazu.
Ich habe hier die Möglichkeit,dadurch, dass ich das entkoppelt habe,
dass ich selber sagen kann, wie sieht denneigentlich mein SEO aus.
Natürlich ist das eine Herausforderung.
Ich kann das, wir haben esgerade schon mal nach der
Mittagspause kurz mitein paar Leuten diskutiert.
Natürlich kann ich das SEO schlechtermachen.
Ich kann natürlich aber auchdas SEO besser machen, indem
ich halt alles in der eigenenHand habe im Frontend.
Der letzte Punkt.
Ich habe keine Abhängigkeiten.
Ich habe ganz häufig gehört,es wird Elementor verwendet,
es wird ein Divi-Builderverwendet im Frontend.
Dadurch, dass ich mein Frontend hierselber baue und selber in
Anführungszeichen meineWaffen selber wählen kann, was ich
im Frontend haben möchte,bin ich hier komplett flexibel.
Ich bin nicht auf irgendwelche Updatesangewiesen von irgendwelchen Anbietern.
Ich bin selber dafür verantwortlich,kann es an einem Entwickler geben im
Frontend und der kann das Ganze pflegen.
Aber ich habe es schon angedeutet.
Es gibt natürlich auch Nachteile an dieserganzen Architektur.
Da möchte ich auch nicht schönreden undich möchte auch hier nicht einfach sagen,
Headless ist State of the Art und ihrmüsst jetzt alle Headless verwenden.
Es ist einfach ein Ansatz.
Auch hier geht es einfach darum.
Ihr müsst entscheiden, ist es für meinProjekt vielleicht das Richtige?
Nachteil ist, und das müssenwir ganz ehrlich auch mit
dem Kunden kommunizieren,es ist ein zusätzlicher Aufwand.
Dadurch, dass ich das Ganzeindividuell, das Frontend baue,
die API konsumieren mussund so weiter, dauert es natürlich.
Auch länger, bis ich meine erste, ichnenne es jetzt mal Webseite am Start habe.
Das sind Punkte, da kommen natürlich danndie Kunden her und sagen, Mensch
Braunstein, warum soll ich denn dasüberhaupt machen?
Das kostet mich doch mehr und das dauertdoch viel länger.
Das macht doch überhaupt gar keinen Sinn.
Ja, wenn man es mit den Vorteilenaufwiegt, macht es dann doch irgendwo Sinn.
Im Nachgang bin ichdann flexibler, weil ich
einfach getrennteVerantwortlichkeiten habe.
Dann habe ich natürlich auch das Problem.
Ich habe es vorher gesagt mit den Plugins.
Wenn ich Plugins verwende, können dieStress machen.
Die können Stress machen im Frontend, wennich die ganzen Informationen durchroute.
Es kann Probleme geben,was zum Beispiel die Vorschau
angeht von Webseitenund so weiter und so fort.
Ist nicht so einfach.
Und ein ganz, ganz wichtiger Punkt,was man ganz gerne vergisst und auch mit
der ganzen Microservice-Architektur und soweiter immer wieder mal vergisst.
Es erhöht natürlich ungemein dieKomplexität.
Dadurch, dass ich das Frontend erstmalausgelagert habe.
Dass ich da eine eigene Verantwortunghabe.
Dass ich da vielleicht auch einen anderenTechnik-Stack verwende.
Erhöht es die Komplexität meines Projektesnatürlich ungemein.
Das kann natürlich dafür sorgen,dass es immer wieder zu Problemen gibt.
Und ich brauche natürlich auch dieErfahrung.
Ich brauche die Erfahrung, wie steuere ichdenn so eine Rest-API an?
Wie konsumiere ich denn eine API richtig?
Welche Regeln muss ich denn da vielleichtbeachten?
Auch das ist natürlich sowas, wo ich sage,hey, ist nicht ganz so einfach.
Ist relativ komplex.
Sollte man auf jeden Fall in der Wahl derMittel bedenken.
Ich habe noch ein paar Use Casesmitgebracht.
Für was ist denn so ein Headless-Ansatzschön?
Also was hören wir denn hauptsächlich auchvon Kundenanforderungen?
Also, ein Punkt ist, wirwollen zukunftsfähig sein
und problemlos an veränderteAnforderungen anpassen.
Das heißt, wir habenKunden, die sagen, Mensch,
wir würden gerne dasheute so darstellen.
Morgen wollen wir vielleicht eineSingle-Page-Applikation haben.
Wir wollen das relativ offen gestalten,wie wir das haben wollen.
Aus dem Grund kommen viele Leute und sagen,wir wollen das zukunftsfähig gestalten.
Ein zweiter Punkt ist, wir brauchen einzentralisiertes Content-Management-System.
Das heißt, tatsächlich will ich an einerStelle meinen Content pflegen und will den
dann eben an meine Applikation,an Drittanbieter usw.
weitergeben mit einem Single Point ofTruth.
Ganz gängiger Fall, Kunde kommt, sagt,ja, wir wollen erst mal nur eine Webseite.
Wunderbar, bau die uns erst mal.
Und ein halbes Jahrspäter, die Webseite ist
erfolgreich, das digitaleProdukt ist erfolgreich.
Umsätze werden darüber generiert,was passiert.
Der User kommt und sagt dann, hey,was können wir jetzt noch machen?
Wir bräuchten jetzt eine App.
Wenn ich jetzt natürlich denmonolithischen Ansatz gefahren hätte,
hätte ich jetzt das Problem,weil ich jetzt im Nachhinein
erstmal dafür sorgen müsste,ich müsste die App bauen.
Mit diesem Ansatz.
Deswegen sagen wir gleich, okay, hey,schaut langfristig, was ist euer Ansatz?
So könnten wir das verwenden.
Deswegen, wir benutzen das CMS tatsächlichzentral als eine Lösung.
Dann hatten wir auch tatsächlich,Kunden kommen auf uns zu und sagen,
hey, wir wollen unbedingt React imFrontend verwenden, weil wir da vielleicht
einen Entwickler haben odereine Entwicklerin haben, eine
Designerin haben, dieentwickelt hauptsächlich auf React.
Was können wir denn dafür tun?
Wie können wir denn WordPress vielleichtverwenden mit React?
Klassischer Ansatz.
Und ich habe es vorher schon angedeutet.
Unsere Kunden wickeln die Transaktion zumBeispiel hauptsächlich über die App ab.
Es kommen jetzt dann Anforderungen.
Hey, wir wollen das Ganze in der Appdarstellen.
Wir wollen das verwenden in der App.
Wir wollen die Daten in den Newsletter nochmit übertragen und so weiter und so fort.
Aus diesem Grund sinddas diese vier Use Cases,
mit denen hauptsächlichdie Kunden zu uns kommen.
Jetzt eine Frage an euch.
Kam denn von euch schon mal jemand aufeuch zu und hat gesagt im Nachgang,
boah, coole Webseite, wir brauchen jetztnoch vielleicht eine App dazu.
Gab es von jemandem schon mal dieseAnforderung bisher?
Wie hast du das gelöst?
Oder wie bist du es dann angegangen?
Okay.
Ja.
Ja, das ist richtig.
Tatsächlich ist es dann haltimmer auch so ein Punkt, mit
dem man dann im Vorfeld mitdem Kunden kommunizieren muss.
Hey, was willst du denn eigentlicherreichen?
Wo soll es denn eigentlich letztendlichhingehen?
Wenn ich jetzt natürlich nursage, ich mache Headless,
dass ich Headless gemachthabe, ist es nicht gut.
Und ich möchte auch nicht sagen,dass Headless das einzig Wahre ist.
Nochmal.
Es geht mir darum zusagen, man kann darüber
nachdenken, das zu verwendenin bestimmten Projekten.
Am besten perspektivischnachdenken, zu sagen,
hey, wo entwickelt sichvielleicht der Kunde hin?
Wenn jetzt zum Beispiel einGemüseladen um die Ecke zu mir kommt,
dem würde ich jetzt nicht denHeadless-Ansatz aufschwatzen.
Einfach weil es, ich sage mal,mit Kanonen auf Spatzen geschossen wäre.
Das wäre einfach übertrieben.
Wenn jetzt abervielleicht ein Mittelständler
kommt und sagt, ja, wirwollen nur eine Webseite.
Dann kann ich natürlich mitihm nochmal durchsprechen
und sagen, willst du dennwirklich nur eine Webseite?
Oder was schwebt dir denn noch vor in derZukunft, in fünf Jahren, in zehn Jahren
oder in drei Jahren vielleicht auchmittelfristig?
Deswegen, diese vier Use Cases sindtypisch, mit denen die Leute in der
Agentur, im Agenturleben auf uns zukommen,mit dem sie uns hauptsächlich,
ja, mit dem sie hauptsächlich auf unseinprasseln.
Ich bin jetzt schon relativ beim Finale,aber ich habe gesagt, ich habe noch ein
paar Punkte mitgebracht, weildieses ganze Thema Headless
bringt natürlich auch ein paarHürden mit im Projektmanagement.
Ich bin jetzt selber viel imProjektmanagement tätig.
Ich entwickle eigentlich nur noch wenigbis gar nichts mehr, verantworte die
Projekte viel auf Projektmanagement-Ebeneund da gibt es so ein paar Regeln.
Ich selber habe mir diese fünf Regeln immervorgehalten, gerade bei so einem Projekt.
Das erste ist natürlich, ich habe esgesagt, die Sinnhaftigkeit prüfen.
Ich kann nicht zum Kunden gehen und sagen,lieber Kunde, wir machen jetzt Headless,
das kostet dich 30, 40, 50 Prozent mehr,aber das ist jetzt cool, das machen wir.
Das wird nicht funktionieren.
Das heißt, man muss eben in die Zukunftschauen, ist das Ganze ein Projekt,
wo wir vielleicht eine App brauchen?
Ist es vielleicht, wo wir Variablesansteuern wollen?
Ist es vielleicht, wo wir die Datenzweitverwerten wollen?
Wie ist denn das Ganze aufgebaut?
Wie ist das Budget auch von dem Kunden?
Also auch hier gibt es einfach dieSinnhaftigkeit zu prüfen.
Wie gesagt, der kleineBlumenladen um die Ecke wird den
Headless-Ansatz nicht wollenund auch nicht bezahlen wollen.
Mittelständler sagen da vielleicht eher,hm, okay.
Das heißt, Punkt zweileitet sich davon ab,
die Zukunft des Projektesim Auge behalten.
Auch hier geht es einfach darum,was sind meine Eckpunkte?
Wie wird das Projekt vielleicht in zwei,drei Jahren skalieren können?
Das muss ich einfachmit dem Kunden ganz klar
durchsprechen und auchoffen mit ihm kommunizieren.
Klar, das ist das Problem.
Wir müssen klare Verantwortlichkeiten fürFront- und Backends schaffen.
Wir hatten das.
Wir arbeiten in einemgroßen Verlag zusammen
und haben dort denHeadless -Ansatz gefahren.
Dort war es am Anfang so, wir hatten eineDesignerin, die hat dann gesagt,
ja, ich kann ein bisschen PHP,ist ja kein Problem.
Die Funktionen, die ich brauche und dieDaten, die ich vielleicht brauche,
die schreibe ich mir da einfach selberrein.
Und dann hat die Designerin, dieeigentlich von einer anderen Agentur
kommt, hat dann in unserem Codemitgearbeitet.
Erst mal für den Verlag war das auch keinProblem.
Für uns war es dann aberim Nachhinein ein Problem,
weil wir einfachVerantwortlichkeiten haben.
Wir waren für das Backend zuständig,wir waren für die API zuständig und auf
einmal wurden da Daten geliefert,die eigentlich gar keinen Sinn machen,
die einfach für uns auch in der Art,wie sie abgefragt worden sind,
überhaupt nicht sinnvoll sind und nichtunserem Programmierstil entsprechen.
Aus dem Grund ist ein Vorteil eben davondie klare Trennung.
Aber dafür müssen auch klareVerantwortlichkeiten geschaffen werden.
Wo ist dein Tanzbereich?
Wo ist unser Tanzbereich?
Was sind deine?
Was darfst du machen?
Was dürfen wir machen?
Hier muss ganz klar geregelt werden,deine Sache, meine Sache.
Punkt 4, da kommen wir einfach dazu,ist eben die offene Kommunikation.
Das heißt, ich muss mit allenProjektbeteiligten offen drüber reden,
sagen, hey, das ist der Ansatz,wir öffnen unser Backend via API.
Du darfst das konsumieren, das holt dirdie Daten raus.
Wenn du aber was brauchst, ist es unsereAufgabe.
Einfach deswegen, dass wir sagen,wir sind auch dafür verantwortlich.
Und dann ganz wichtig, und das
kriege ich leider immerwieder mit von Neukunden und
so weiter, ist auch einsauberes Projektmanagement.
Es muss sauber dokumentiert werden, wennÄnderungen irgendwo vorgenommen werden.
Sei es in Form von einem Ticket,sei es aber auch in Form von einer
Dokumentation, ineiner Jira-Dokumentation
oder in einem Wiki-Eintragoder wie auch immer.
Dokumentiert es sauber, macht ein sauberesProjektmanagement einfach, dass auch klar
ist, wer eigentlich dennfür was zuständig ist und
was jetzt, warum dieseÄnderung durchgeführt wurde.
Ich habe am Schluss noch eineMessage, weil ich jetzt gerade,
weil jetzt vor drei Wochenwar, glaube ich, die DM Exco.
Ich weiß nicht, ob da jemand von euch war.
Es ist eine große Digitalmesse in Köln unddort sind die ganzen großen Player eben da.
Und man sieht da dieWordPress-Jungs und Mädels nicht,
weil es eben halt natürlicheine Open Source Community ist.
Wir hören aber immerwieder, wenn wir mit
anderen Agenturen reden,ich mache WordPress.
Es ist so ein bisschen so, die Leutegucken uns an so, ach, ihr macht WordPress.
Okay, krass.
Ja, haben wir auch mal früher gemacht.
Machen wir jetzt nicht mehr.
Wir machen jetzt die großen Anbieter,wo man schon, keine Ahnung, 30.000
erstmal bringen muss, dass manerstmal die Lizenz hat und so weiter.
Das ist nämlich viel cooler und so weiter.
Ich finde, die Community und WordPress ansich muss sich nicht verstecken.
In dem Content-Management-System steckt soviel drin.
Wir haben eigentlich, wenn man das soanschaut, eine richtig coole Community.
43% aller Webseiten weltweit laufen aufWordPress.
Und da finde ich es immer schade,dass es dann immer heißt von anderen
Agenturen oder vonanderen Bereichen, na, dieses
WordPress, das wirdso ein bisschen belächelt.
Das ist ja kostenlos.
Ich meine, für uns Schwaben, wir mögen diekostenlosen Sachen, klar.
Aber es ist immer so ein Thema, manwird da immer so ein bisschen angeguckt.
Ja, das ist doch nur so für so Reiseblogs.
Und ich möchte einfach so ein bisschenauch die Community ermutigen, hey,
WordPress muss sich tatsächlich überhauptnicht verstecken.
WordPress kann nämlich alles.
Und noch viel mehr.
Und sogar Headless.
Wir verwenden WordPress bei Verlagskunden,die haben im Jahr Millionen Page Visits
und haben da kein Problem.
Die Redakteure lieben dieses System.
Und mir wäre es einfachein Anliegen, dass wir als
Community sagen, hey,WordPress kann wirklich viel.
Wir können da so viel mitbauen.
Wir haben da so viele Möglichkeiten.
Und damit will ich meinen kurzenInspirationsbeitrag schon abschließen.
Ich hoffe, ihr konntet ein bisschen wasmitnehmen.
Ich hoffe, ich konnte euch diesenHeadless-Ansatz ein bisschen nahe bringen.
Und wenn ihr Fragen habt, kommt sehr gerneauf mich zu.
Verlinkt euch gerne mit mir.
Und ansonsten sage ich schon mal vielenDank erstmal für die Aufmerksamkeit.
Ich habe direkt eine Frage zudem Thema, wo du gesagt hast,
im Endeffekt Headless alsMulti-Frontend-Tool zu benutzen.
Was spricht aus deinerSicht dann dagegen zu
sagen, okay, WordPresskommt eh mit einer REST API.
Ich benutze als Web-Frontend dasklassische Frontend und flansche eine App,
whatever, über REST API auf.
Prinzipiell gar nichts.
Das ist auch ein sehr guter und sehrbeliebter Ansatz, den man fahren kann.
Wenn ich jetzt natürlich sage,hey, pass auf, ich habe jetzt einen
speziellen Prüfvorgang für Beiträge,die speziell überprüft werden müssen,
wo ein spezielles Flaggesetzt werden muss,
dass es zum Beispielveröffentlicht werden kann.
Oder wie auch immer, dass ich eineFilterung reinbauen muss.
Dann würde ich darüber nachdenken.
Wir selber benutzen auch häufig die APIund flanschen das dann quasi dran.
Es kommt darauf an, was wir machen,wenn es die Anforderung React ist.
Aber prinzipiell ist dieser Ansatz supervalide und natürlich auch total möglich,
dass ich im Nachgang auch darüber die Appbauen kann.
Klar, kein Problem.
Ich spiele jetzt mal den Anwalt desTeufels.
Wenn ihr schon das Frontendentkoppelt, warum haltet
ihr ausgerechnet beimBackend an WordPress fest?
Mit einer kaputten Datenbankstruktur,mit Admin-Tools, die nicht ordentlich
funktionieren, mit einem Notification-System, das dringend renoviert gehört.
Was spricht für WordPress?
Für uns spricht beiWordPress hauptsächlich
zum einen erstmalder Tech -Stack an sich.
Den können wir mit sehr gut umgehen.
An sich hören wir sehr viel Positives auchvon den Redakteuren.
Das ist auch so ein Punkt, den man nichtvergessen darf.
Die Leute, die damit arbeiten.
Und wir haben sehr häufig,kriegen wir das Feedback,
dass WordPress ebeneinfach zu benutzen ist.
Die Leute benutzen esgerne mit einer flachen
Hierarchie, mit einerflachen Eingabestruktur.
Sicherlich gibt es Pro und Contra fürWordPress.
Da müssen wir nicht drüber diskutieren.
Wir kriegen das Feedback eben,dass es einfach ist zum Warten.
Und wir haben auch andere Content-Management-Systeme noch im Einsatz.
Die sind noch sehr komplex.
Da sagen dann dieLeute zum Beispiel, ist mir
zum komplex zumBeispiel damit zu arbeiten.
Das ist so ein Vorteil, den wir zumBeispiel immer wieder hören.
Zusatzfrage dazu.
Dann im Backend, wenn du sagst,die Redakteure loben das.
Erarbeitet ihr dannmit FSE-Tools, mit dem
Gutenberg-Editor odermit dem Classic -Editor?
Wir arbeiten viel mit dem Gutenberg-Editorund bauen dort eben die Blöcke mit für
unsere Kunden, wie sie ebendementsprechend brauchen.
Also wir bearbeiten viel mit denGutenbergs.
Wir sind sehr froh mit den Gutenberg-Blöcken aktuell.
Und das ist ein Tech-Stack, der für unsaktuell super funktioniert.
Ganz hinten haben wir noch.
Mit welchem Headless-System habt ihr schon
Erfahrung, dass derso nicht so pain bringt?
Was wir für Probleme entdeckt haben schonbei Headless oder so?
Oder besser gesagt, welche war die besteHeadless, die wir bis jetzt genutzt haben?
An Systemen?
Naja, da ich bei einer WordPress-Veranstaltung bin, ist WordPress
natürlich das beste Headless, was wirverwendet haben.
Es gibt, letztlich kann man da nichtsagen, was das Beste ist oder was nicht.
Es kommt immer darauf an, was ist der UseCase?
Wenn ich natürlich erstmal für ein CMS-System 30.000 liefern muss zum Beispiel,
oder 5.000 oder was auch immer,dass ich erstmal die Basisversion von
einem CMS-System habe, das un-customizedist, wo einfach der Kunde sagt,
okay, da habe ich jetzt Eingabefelder.
Hm, da macht es natürlich schwer.
Die 5.000 Euro zum Beispielkann ich schon mal verwenden
und ein angepasstes,customized Backend machen.
Letztlich haben alle ihre Vorteile.
Wir haben eine Datenbankstruktur,die nicht immer optimal ist.
Wir haben auch bei WordPress, wo nichtalles Gold ist, was glänzt.
Letztlich muss man sich selberentscheiden.
Ich möchte nur ermutigen, dass eben auchWordPress eine gute Alternative für diesen
Headless -Ansatz ist und dass wir sagen,hey, das kann man damit verwenden.
Es ist for free, es ist open source.
Und das Geld, was ich erstmal anLizenzkosten irgendwo vielleicht mal
tragen muss, das kann ich vielleicht fürden coolen Word, für den coolen Funktionen
im Backend-Bereich zum Customizeneinbauen.
Ja, danke.
Und habt ihr da auch ein Shop-Systemintegriert oder ist das.
Wie wird das Headless-System danneingesetzt?
Tatsächlich haben wir jetzt in unsererWordPress-Unit kein Shop-System.
Wir haben DXP-Plattformen,die dann zum Beispiel
ein Shop-System mitintegriert haben und so weiter.
Aber das ist nicht auf WordPress-Basis.
Wir selber machen viel Reichweiten-Seitenund digitale Online-Angebote.
Den Verlag, den wir betreuen, der hateinen eigenen Shop.
Also Shop, das ist ein iFrame.
Was eine Transaktion auslöst und soweiter.
Das ist kein richtiges Shop-System,was wir da eingebaut haben.
Also wir bauen hauptsächlichReichweiten -Seiten
und digitale Produkteauf WordPress -Basis.
Okay.
Kannst du noch mal ganzkurz ein paar Sätze skizzieren
im Einsatz mit derDatenbank, mit der REST-API?
Auf welche Dinge muss man da achten?
Weil es gibt ja auch viele, die haben einPimcore im Einsatz.
Und der Knackpunkt ist, wie fließen dieDaten rein, können sauber verarbeitet
werden und wie können sie wieder sauberrausfließen?
Kannst du da noch mal ein bisschen wassagen?
Ja, also wichtig natürlich mit demArbeiten mit der API ist natürlich,
sie muss, also sie ist ja selber, sie istnicht selber geschrieben hier in dem Fall.
Wenn wir sie konsumieren, zumBeispiel die WordPress-fertige
API, die muss natürlichsauber dokumentiert sein.
Das ist natürlich so ein Punkt.
Wir haben häufig Themen gehabt von,es muss nicht immer ein CMS sein,
aber anderenAPI-Schnittstellen, in denen, ich
sage mal, undokumentierteFeatures drin sind.
Das ist natürlich fatal, wenn dieDokumentation von der API nicht stimmt.
Das finde ich ganz schlimm.
Und ansonsten gelten eigentlich, glaubeich, die normalen Programmierrichtlinien.
Also ich muss natürlich gucken,wie viele Requests muss ich machen?
Wie sichere ich die API?
Auch dementsprechend ab und so weiter.
Generell muss man da einfach schauen,wie es da aufgebaut ist.
Aber ansonsten würde ich sagen,ganz normal verantwortungsvoll
mit der API umgehen, auchbei WordPress in dem Fall.
Danke.
Ich habe eine Frage.
Sie haben sehr viel gesprochen über APIund verschiedene Ansätze.
Ich habe folgendes zum Beispiel,sagen wir so ein Beispiel.
Wir haben WordPress für die Bearbeitungvon Blogs oder Posts und so weiter.
Und zweiterseits wollenwir auch in Zukunft eine App
aufbauen, zum Beispielauch für Android oder für iOS.
Nutzen wir dann REST API oder sollen wirdann eine API speziell dafür entwickeln?
Also wie wäre dann die Prozedur zumBeispiel?
Das kommt jetzt natürlich darauf an,was ihr da konkret für eine App bauen
wollt, was ihr für Zusatzfunktionenbraucht.
Liefert die aktuelleREST-API vielleicht schon
alles, dann könnt ihrnatürlich die verwenden.
Wenn ihr jetzt sagt, aber wir haben jetztandere schreibende Zugriffe und so weiter
und so fort, dann kann es natürlich sein,ihr müsst was Eigenes schreiben.
Dafür müsst ihr natürlich erstmal wissen,was wollt ihr da für eine App bauen?
Was macht die App zum Beispiel?
Ja, zum Beispiel nurwie auf die Homepage zu
gehen und nur einGet-Funktionen zu bekommen.
Also nur lesen von Datenbanken.
Ich glaube, da haben wir es schon gehört.
Kommt immer darauf an, brauche ich daüberhaupt eine App?
Also muss ich da eine komplette App selberschreiben?
Ansonsten kann ich da ganz normal dieREST-API verwenden.
Noch eine Frage?
Vielen Dank für den Vortrag.
Eine Frage wegen der GraphQL.
Wird das auch bei euch eingesetzt odernutzt ihr wirklich tatsächlich nur die
ganz normale Abfrage vom WordPress von derREST-API?
Wir benutzen tatsächlich die ganz normale.
Wir haben uns einPlugin, ein eigenes
geschrieben, was nochdie Daten anders durchgeht.
Aber die GraphSQL verwenden wir nicht.
Dann, wenn keine Fragen mehr da sind, sageich vielen Dank für eure Aufmerksamkeit.
Ich hoffe, ich konnte euch ein bisschenwas mitgeben.
Habt noch einen schönenTag und nochmal vielen
Dank an die Organisatorenfür das tolle Event.
Dankeschön.