In der Episode unterhalten wir uns über die Geschichte und den Iststand des WordPress Block Editors (Gutenberg) und die Zukunft von WordPress.
Gast: Thomas Kräftner
https://mastodon.social/@kraftner
thomas@kraftner.com
https://kraftner.com/
In dieser Episode reden wir mit Thomas Kräftner. Thomas ist selbständiger Web Developer mit einem 100%igen Fokus auf WordPress. Er ist auch seit über 10 Jahren in der WordPress Community aktiv.
In dem Gespräch unterhalten wir uns über folgende Themen:
* Entstehungsgeschichte von Gutenberg
* Die kommerzielle Seite von WordPress
* Ist Fullsite Editing “Projekt Reif”?
* Die Zukunft von WordPress
* Neueste Technologien oder stabile Lösungen?
* Was bedeutet Full Site Editing?
* Gutenberg Nachteile bei großen Projekten
* Werden Themes aussterben?
* Sind gekaufte Themes sinnvoll?
* Der Lifecycle von Pagebuildern
* Hat Gutenberg ein Ablaufdatum?
* Wie lange lebt eine Webseite?
* Custom Lösungen oder fertige Plugins?
uvm ...
// WordPress Community Gruppe //
https://dominikliss.com/community
Was ich dich auf jeden Fall gerne fragen würde und in das Thema würde ich extrem gerne mit dir eintauchen, ist Gutenberg.
Das hat zuerst nur als Experiment gestartet, wo man einfach mal ein bisschen rumprobiert hat, was es da für neue Ansätze geben könnte, was kann man aus den diversen Page-Builder -Plugins, die es zu dem damaligen Zeitpunkt schon gegeben hat, mitnehmen, was möchte man vielleicht anders machen, wenn man das in WordPress Core hineinbringt.
So hat das quasi gestartet.
Automattic gehört einem von den zwei Gründern von WordPress.
Also der hat das als Open-Source-Projekt gestartet und hat dann parallel dazu seine eigene Firma hochgezogen, wo er halt WordPress als fertig gehostete Lösung angeboten hat.
Woher kann ich wissen? Weil wenn eine neue WordPress-Version rauskommt, zum Beispiel mit dem Full-Site-Editing, siehst du dann nach dem Update, Full-Site-Editing ist da oder dieses Feature ist da.
Aber woher kann ein normaler User einfach wissen, ist dieses Feature schon reif? Gute Frage.
Wenn ich da eine einfache Antwort drauf hätte, wäre das wahrscheinlich für sehr viele Leute sehr schön.
Ja, wirklich wissen kann man nicht.
Das, was im Normalfall in meinen Augen immer die beste Strategie ist, ist einfach.
.
.
Jetzt haben wir das Full-Site-Editing.
Ich finde es total spannend, dass der Blog -Editor sehr viel mehr Möglichkeiten dem Editor in die Hand gibt.
Dass man jetzt gerade mit Full-Site-Editing sehr viele Dinge vom Layout und der Gestaltung und Farben und Typografie usw.
direkt im Backend von WordPress machen kann, ohne so wie früher programmieren zu müssen, ohne PHP, CSS usw.
zu verstehen.
Mit großer Macht kommt auch große Verantwortung.
Sprich, wenn man dem User all diese Gestaltungsmöglichkeiten in die Hand gibt, gibt man immer noch sehr viel Macht, Dinge kaputt zu machen, nicht schön zu machen usw.
Glaubst du, wird es in Zukunft überhaupt noch Bedarf an Teams geben? Herzlich willkommen bei der neunten Episode des Podcasts.
In dieser Episode besucht uns Thomas Kräftner.
Und der Thomas, der ist in der WordPress-Community, glaube ich, schon seit Anfang an dabei in Wien.
Auf jeden Fall schon jahrzehntelang gefüllt.
Wahrscheinlich stimmt das auch schon.
Thomas ist selbstständiger Web-Developer mit einem hundertprozentigen Fokus auf WordPress.
Deswegen habe ich sehr viele Fragen an dich, weil es gibt sehr viele technische Themen, die wir einfach abdriften könnten.
Aber, Thomas, könntest du dich bitte kurz in deinen eigenen Worten vorstellen? Also, herzlich willkommen und bitte.
Ja, hallo.
Mein Name ist Thomas Kräftner.
Ich bin, wie du schon gerade gesagt hast, selbstständiger Web-Entwickler.
Habe mich mittlerweile eigentlich komplett auf WordPress spezialisiert.
Wobei innerhalb von dem dann noch einmal mit einem Fokus auf Projekte, die mehr Individualentwicklung erfordern.
Also viel Custom-Plugin und Team-Development, wo man nicht von der Stange Sachen verwendet, sondern wirklich ganz individuelle Anforderungen individuell entwickeln braucht.
Das ist irgendwie so mein Fokus.
Ich bin nebenbei auch noch in der WordPress -Community recht aktiv.
Jetzt gerade weniger bei den Events und so.
Aber ich war unter anderem relativ am Anfang beim Meetup in Wien dabei.
Habe auch das WordCamp in Wien mitgestartet.
Und bin da irgendwie auch schon seit Jahren mit wechselnder Intensität in der Community aktiv.
Als Organisator, als Speaker und so weiter.
Du bist auch ein bisschen so ein Mitgründer der WordPress-Community in Wien.
Du bist die Person, die ich persönlich kenne, die am längsten schon dabei ist.
Oder seit dem Anfang an.
Ich gehöre auf jeden Fall zu denen.
Angefangen hat es mit dem Meetup.
Da war ich nicht wirklich im Gründungsteam dabei.
Bin aber ein paar Monate nachdem das gestartet hat, damit eingestiegen.
Und beim WordCamp war ich wirklich beim Ersten dabei.
Ich glaube mittlerweile von den Leuten, die damals angefangen haben, bin ich jetzt einer, der da am aktivsten ist.
Aber wie auch immer.
Das ist ein Team-Effort und es freut mich, dass da immer viele verschiedene neue Leute auch dazukommen.
Was ich dich auf jeden Fall gerne fragen würde und in das Thema würde ich extrem gerne mit dir eintauchen, ist Gutenberg.
Weil Gutenberg hat ja so seine Entwicklungsgeschichte und von meinem Eindruck her war Gutenberg plötzlich einmal da und es hat sich dann mit der Zeit sehr stark weiterentwickelt.
Jetzt gibt es noch das Fullsite-Editing.
Dann gibt es noch eine Roadmap, wohin die Reise gehen soll und so weiter.
Könntest du Gutenberg vielleicht aus deiner Perspektive kurz zusammenfassen, wie Gutenberg entstanden ist, wie du Gutenberg verwendest und in welche Richtung die Reise mit Gutenberg wahrscheinlich geht, jetzt wo wir das Fullsite-Editing, zumindest die erste Version vom Fullsite-Editing haben und so weiter.
Okay.
Ja, also soweit ich mich daran erinnere, hat das Ganze irgendwie so begonnen, dass WordPress im klassischen Editor ja irgendwie ein sehr lineare Inhalts-Editor hatte, der irgendwie mehr an so klassische Texteditoren wie Word oder so erinnert haben.
Und das ist dann irgendwie mit zunehmender Entwicklung des Internets, wo dann halt immer mehr interaktive und ausgefallene Leotsachen interessant geworden sind, hat das dann irgendwie nicht mehr so gut alle Anforderungen erfüllt, weswegen dann irgendwie die Ära der Pagebuilder gestartet hat, wo irgendwie zig verschiedene Firmen versucht haben, die Editing-Experience in WordPress mit so Pagebuildern zu verbessern oder mehr Leot-Möglichkeiten einzubauen.
Und ja, dann kam halt irgendwann der Punkt, wo WordPress als Projekt quasi erkannt hat, okay, das wollen echt verdammt viele Leute, das scheint wohl was Wichtiges zu sein.
Vielleicht wäre es irgendwie sinnvoll, die Editing-Experience in WordPress selbst einmal zu überarbeiten.
Das war so in meiner Wahrnehmung quasi die Entstehungsgeschichte vom Blog-Editor.
Wie das Ganze dann gestartet hat, ich glaube, das hat so eine kleine Vorgeschichte.
Es gab zuerst, bevor in einem WordPress-Projekt eigentlich der Blog-Editor gestartet hat, gab es so ein sehr ähnliches Projekt bei Automatic für WordPress.
com.
Die haben so einen alternativen Editor, ich glaube, hier hat der mal wieder geheißen, Calypso, glaube ich, gehabt.
Damit ich da ganz kurz reinschneide, falls Leute Automatic noch nicht kennen, das ist so die kommerzielle Firma von WordPress.
Also es gibt WordPress.
org, das ist das Open -Source-Projekt, und es gibt WordPress.
com und das ist ein Projekt von Automatic.
Automatic gehört einem von den zwei Gründern von WordPress.
Also der hat das WordPress quasi als Open-Source -Projekt gestartet und hat dann parallel dazu seine eigene Firma hochgezogen, wo er halt WordPress als fertig gehostete Lösung angeboten hat.
Und Automatic ist jetzt gleichzeitig auch irgendwie noch einer der größten Treiber der Community und da passieren oft viele Dinge irgendwie parallel oder zumindest im Zusammenhang.
Und Automatic hat dann viele Plugins aufgekauft wie WooCommerce und .
.
.
Sie haben viele entwickelt, sie haben viele aufgekauft.
Sie sind einfach einer der größten, eigentlich der größte Player im WordPress-Ökosystem.
Kurze Unterbrechung in eigener Sache.
Dafür habe ich mir jetzt extra für euch ein Hemd angezogen.
Und zwar gibt es nun die WordPress-Community -Gruppe.
Also in den Kommentaren bekomme ich schon relativ viele Fragen bezüglich WordPress-Support, konkrete Fragen zu Projekten und so weiter.
Deswegen mache ich jetzt eine WordPress-Community -Gruppe.
Ich habe euch vor ein paar Wochen befragt, welche Tools ich so verwende, und die Mehrheit hat sich für Discord entschieden.
Deswegen wird das eine Discord-Community-Gruppe sein.
Die ist gerade im Aufbau.
Dort wirst du Antworten auf deine WordPress -Fragen bekommen, du wirst konstruktives Feedback zu deinen Projekten bekommen und es wird auch Online-Sprechstunden geben, wo du einfach teilnehmen kannst, deine Fragen stellen kannst oder einfach zuhören kannst, welche Fragen andere Teilnehmer haben.
Das alles ist kostenlos.
Du musst einfach nur den Link unten anklicken.
Die Gruppe ist gerade im Aufbau.
Deswegen wirst du eine E-Mail bekommen mit dem Link zu dem Discord-Channel, sobald diese online ist.
Aber klick unten den Link an, dort kannst du dich in die Warteliste eintragen und sobald die Gruppe online ist, bekommst du diese E -Mail.
Dann geht es jetzt weiter mit dem Video.
Okay, passt.
Calypso hast du gesagt, war da.
.
.
Genau, das gab es, glaube ich, schon mal vorher, so ein Projekt bei Automatic, wo sie eben versucht haben, diese Editing-Experience ein bisschen zu optimieren.
Aus dem ist dann dieses Gutenberg-Projekt entstanden, was dann eben schon wirklich in WordPress.
org, in dem Open-Source-Projekt, angesiedelt war.
Und das hat zuerst irgendwie nur so als Experiment gestartet, wo man einfach mal ein bisschen herumprobiert hat, was es da für neue Ansätze geben könnte, was kann man aus den diversen Page-Builder -Plugins, die es zu den dauernden Zeiten schon gegeben hat, mitnehmen, was möchte man vielleicht anders machen, wenn man das in WordPress Core hineinbringt.
So hat das quasi gestartet.
Gutenberg war anfangs eigentlich eher so eine Art Forschungsexperimentierprojekt.
Also ich kann mich irgendwie erinnern beim WordCamp Europe in Paris, im Jahr, keine Ahnung, lange her, wurde das quasi das erste Mal so vorgestellt.
Und es hat sich dann aber relativ schnell gezeigt, dass das eigentlich ganz interessant ist.
Und dann ist das durch diesen Experiment irgendwann einmal, ohne dass es da wirklich so einen Moment gab, plötzlich ein Entwicklungsprojekt innerhalb von WordPress Core geworden.
Genau, das war so die Entwicklungsgeschichte, soweit ich mich daran erinnere, beziehungsweise wie ich das wahrgenommen habe.
Und das Ganze ist irgendwie in Faden vonstatten gegangen.
Also der erste Schritt war quasi mal, nur den Content Editor zu überarbeiten, also dass man statt dem klassischen Editor, wo man einfach seinen Text hineinschreibt, diesen neuen Block-basierten Editor hat.
Das war irgendwie so die erste Phase.
Und jetzt in den letzten Jahren hat sich das irgendwie immer weiter ausgebreitet und größere Teile von WordPress übernommen.
Also am Anfang war es wirklich nur der Content von einem Post, dann später kamen so Sachen wie das Widget, auch aus Blöcken ausgebaut wurden, dazu das Menü ersetzt wurde, mittlerweile eben Full -Side Editing, wo man das komplette Layout, die Seite, das Theme usw.
auch aus Blöcken ausbaut.
Also das breitet sich irgendwie langsam aus und ersetzt quasi immer mehr Teile von WordPress und bringt sie in diese Block-Denkweise hinein.
Aber dadurch, dass WordPress jetzt so groß geworden ist, oder dass so viele Webseiten mit WordPress betrieben werden, ist ein bisschen das Problem, dass es WordPress schon jahrelang gibt.
Und damals wurde alles mit PHP usw.
das Ganze entwickelt, mit dem alten Editor und das Ganze.
Aber die Technologien, die schreiten ein bisschen voran.
Und damit WordPress dann mithalten kann mit den moderneren CMS, also mit den Content-Management-Systemen, ist WordPress mehr oder weniger gezwungen, sich laufend weiterzuentwickeln.
Aber dadurch, dass es schon so groß ist und so verbreitet ist, können die Entwickler bei WordPress einfach nicht sagen so, hey, wir machen jetzt einen harten Cut, also wir unterstützen das nicht mehr und das ist der neue Editor, weil so haben wir das entschieden, oder das ist der neue Page-Builder in WordPress und das alte gibt es nicht mehr, weil das ganze Ökosystem mit allen Plugins schon so stark auf WordPress aufbaut und die Kompatibilität wird dann einfach nicht mehr da, wenn die einen harten Cut machen so, hey, wir haben jetzt das neue Ding entwickelt, der neue Page-Builder, der ist Gutenberg, das alte gibt es nicht mehr.
Deswegen ist der Prozess von der Entwicklung von Gutenberg so lange und so stückweise schreitet das voran, weil einfach nicht von 0 auf 100 umgeswitcht werden kann.
Und da hat WordPress dann auch eine Roadmap für Gutenberg und so hätte ich das jetzt verstanden, wieso es jetzt nicht von heute auf morgen umgeswitcht wurde und was halt so ein bisschen das Problem von WordPress ist, einfach wegen der Menge oder wegen der Anzahl an Installationen auf der ganzen Welt müssen die sehr vorsichtig sein, was sie implementieren, wie die das machen und in welchem Tempo.
Wie siehst du das von deiner Seite? Ich finde es sehr spannend, dass du das quasi so wahrnimmst, als ob das gerade so langsam vonstatten geht, weil meine Wahrnehmung wäre eigentlich das genaue Gegenteil.
Also ich finde, dass Gutenberg da extrem schnell in dieses WordPress-Ökosystem hineinfährt gerade.
Eben gerade deswegen, weil du, wie du sagst, WordPress eigentlich immer sehr daran interessiert war, Backwards-Kompatibilität zu erhalten, alte Webseiten nicht kaputt zu machen und irgendwie eklige Änderungen immer ganz langsam und vorsichtig hineinzutragen, damit eben nicht alle paar Monate alles komplett über den Haufen geworfen wird.
Das ist jetzt natürlich immer subjektiv, aber ich finde ehrlich gesagt, dass das noch schneller hätte das auf keinen Fall passieren dürfen, weil es ist, finde ich, jetzt schon so, dass eigentlich bei so gut wie jeder Version irgendwelche in meinen Augen doch recht großen Veränderungen stattfinden.
Also ich würde sagen, so oder vielleicht sogar eine Spur langsam auf keinen Fall schneller wäre mein Standpunkt zu dem Ganzen.
Also wie du schon richtig gesagt hast, dass alles subjektiv schnell oder langsam ist.
Ich bin das erste Mal, ich weiß nicht wann, am Anfang wurde Gutenberg als Plugin zur Verfügung gestellt und dann wurde er in den Core der neuen Editor, der Blog-Editor reingemerged.
Das war schon vor, keine Ahnung, drei, vier Jahren oder sowas, wo Gutenberg zum ersten Mal auf die Welt gekommen ist.
Ja, ich glaube 2018 kann das sein.
Es ist auf jeden Fall schon einige Jahre her, dass es begonnen hat mit Gutenberg, das stimmt schon.
Deswegen ist es so in meinem Kopf so, es ist ein bisschen so ein langsamer Prozess, um alles zu entwickeln, damit alles backwards -kompatibel ist, damit die WordPress-Webseiten einfach nicht zusammenbrechen bei einem Update.
Aber so wie du das gesagt hast, stimme ich dir zu, weil jetzt vor allem mit dem Full-Side-Editing und so weiter kommen mit jedem WordPress-Update, mit jeder neuen Version, neue Gutenberg-Features dazu.
Und deswegen ist die Wahrnehmung so da, dass es halt jetzt schnell voranschreitet, das Ganze.
Ich glaube, es kommt dabei sehr darauf an, aus welcher Perspektive man das Ganze betrachtet.
Als jemand, der quasi ein neues WordPress-Projekt beginnt und dem vielleicht noch irgendwelche Features fehlen, die gerade erst in Entwicklung sind, für den kann das natürlich alles nicht schnell genug gehen.
Genauso, wenn man eher Webseiten macht, die sehr kurzlebig sind, also, keine Ahnung, für irgendwelche Events, wo man die Webseite macht, dann ist das Event vorbei und dann kommt die Webseite weg und es kommt eh wieder eine neue Webseite, vielleicht.
Da kann es halt nicht schnell genug gehen, weil wenn man sowieso neu anfängt, dann fängt man halt mit dem an, was gerade der Status quo ist.
Ganz anders ist das halt, finde ich, wenn man Webseiten hat, die schon älter sind, die es vielleicht schon seit zehn Jahren gibt, die in einer Zeit begonnen haben, wo die ganze Atemreise, die WordPress aufgebaut hat, einfach noch anders war, wo vielleicht noch irgendwelche Plugins in Verwendung sind, die essentiell sind, aber die nicht wirklich mit dem Blog-Editor kompatibel sind.
Oder wenn man einfach extrem viel Inhalte schon in einer Webseite drinnen hat, weil, ich meine, okay, bei einer kleinen Firmenwebseite hat man vielleicht eine Handvoll Seiten, aber bei irgendwelchen größeren Unternehmen kommt man ja schneller mal auf tausende Seiten und in diesem ganzen Szenario ist es halt irgendwie sehr viel schwieriger, sich an solche Veränderungen anzupassen, weil da ist das Updaten von WordPress selber das geringste Problem, aber dann vielleicht muss man irgendwelche Plugins durch andere ersetzen, weil die nicht mehr mit dem Blog-Editor funktionieren oder man muss die ganzen Content, die tausenden Seiten eben schon hart migrieren, damit sie mit dem Blog-Editor vernünftig funktionieren und so weiter.
Das sind dann oft Dinge, die sehr zeitaufwändig sind und deswegen halt auch nicht von heute auf morgen erledigt werden können.
Darum braucht man bei solchen Projekten, also da reden wir oft davon, dass die Umstellung auf eine neue WordPress -Version manchmal Monate dauert und nicht einfach nur ein Klick im Backend ist.
Und genau für diese Art von Projekten ist es natürlich eher so, dass das gefühlt relativ schnell vonstatten geht.
Und das dritte, was mir halt auch noch auffällt, ist gerade weil der Blog-Editor noch so stark in Entwicklung ist, sind gerade die Dinge, die jetzt noch nicht so lange existieren, noch einem stärkeren Wandel unterworfen.
Also gerade das Vollzeit-Editing zum Beispiel angesprochen, das ist noch relativ neu.
Da tut sich einfach noch viel mehr.
Da kommt man noch viel öfter auf irgendwelche Sachen drauf, die eigentlich so nicht gut funktionieren, die man vielleicht doch anders machen muss.
Und das heißt, da ändert sich der Unterbau, auf den man seine eigene Website draufsetzt noch öfter.
Da muss man dann halt auch vorsichtiger sein.
Bei dem reinen Inhaltsbearbeiten mit den Blöcken, da haben wir mittlerweile, finde ich, einen relativ stabilen Status erreicht.
Das kann man verwenden, da kann man sich darauf verlassen, dass sich das nicht mehr allzu dramatisch verändern wird.
Das sind halt alles so Überlegungen, die einerseits geschmacksorientiert und andererseits auch extrem davon abhängen, in welchem Kontext man das alles verwendet.
Weil das halt in einem sehr breiten Spektrum an Projekten eingesetzt werden kann.
Von kleinen Einpersonen-Blogs, die als Hobby betrieben werden, bis riesengroßen Corporate -Webseiten, wo unzählige andere Systeme dranhängen mit vielen Editoren und Unmengen an Inhalten usw.
Das sind sehr unterschiedliche Use Cases.
Da bin ich voll bei dir.
Von dem, wie ich Gutenberg verwendet habe, habe ich auch das Gefühl, der Blog-Editor an sich ist schon relativ stabil.
Mit dem kann man schon coole Sachen umsetzen.
Aber beim Full-Site-Editing, da halte ich noch meine Finger weg, bevor ich da irgendein Projekt noch umsetze, weil es dann noch ein bisschen tricky ist, das zu verwenden.
Und in Projekten im großen Stil einzusetzen.
Aber jetzt zum Beispiel, wenn wir uns von der Rolle der Developer, also von der Programmierer-Rolle, ein bisschen distanzieren.
Und sagen wir mal, wir schlüpfen jetzt in die Schuhe von normalen WordPress-Usern, die einfach nur Webseiten waren.
Woher kann ich wissen? Weil wenn eine neue WordPress-Version rauskommt, zum Beispiel mit dem Full-Site-Editing, siehst du dann nach dem Update, hey, Full-Site-Editing ist da.
Oder dieses Feature ist da.
Aber woher kann ein normaler User einfach wissen, hey, ist dieses Feature schon reif? Darf ich das Save verwenden? Wird sich viel ändern? Weil irgendwie kann man es nicht wissen, aber wenn es mit einem Update rauskommt, als das Feature ist schon da, dann gehen die meisten Leute wahrscheinlich davon aus, hey, es ist schon ausgereift, dass man das im großen Stil verwenden kann.
Aber im Endeffekt kann sich da noch vieles ändern.
Also wie kann man ungefähr wissen, ob es safe ist zu verwenden oder nicht? Gute Frage.
Wenn ich da eine einfache Antwort drauf hätte, wäre das wahrscheinlich für sehr viele Leute sehr schön.
Ja, wirklich wissen kann man nicht.
Ich meine, das, was im Normalfall in meinen Augen immer die beste Strategie ist, ist einfach auszuprobieren.
Man kann das Feature ja mal ausprobieren und schauen, funktioniert es so, wie ich das brauche? Gibt es noch irgendwelche Dinge, die nicht gut funktionieren oder die für meine Anforderungen nicht passen? Das ist mal irgendwie etwas offensichtlicher.
Grad FullSight Editing ist ja lange Zeit schon drinnen gewesen in WordPress Core, aber noch mit dem Beta-Label.
Also ich meine, wenn ich auf irgendeinem Feature noch eindeutig darauf sehe, dass das eine Beta-Version ist, dann ist das schon ein relativ starker Indikator, dass man sich im produktiven Einsatz dreimal überlegen sollte, ob man das schon machen möchte.
Ja, das sind irgendwie so die offensichtlichen Dinge, die man, glaube ich, machen kann.
Generell ist es, glaube ich, wie bei jeder anderen technischen Entscheidung immer die Frage, möchte man immer am Bleeding Edge sein und die aktuellsten, neuesten, heißesten Dinge sofort ausprobieren oder möchte man lieber ein bisschen warten, schauen, bis sich die Aufregung gelegt hat und schauen, was dann überbleibt? Und lieber die alten, langweiligen und bewährten Lösungen einsetzen.
Das ist auch wieder eine Geschmackssache.
Also ich bin sehr interessiert an den neuen Dingen, aber beim produktiven Einsatz bin ich da eher vorsichtig und setze lieber mal auf die alten, bewährten, langweiligen Lösungen, wo ich weiß, dass die funktionieren und schon alle Kinderkrankheiten ausgebügelt worden sind.
Das erinnert mich ein bisschen so an, das erinnert mich ein bisschen so an Developer an sich, weil, okay, weil du gesagt hast, du kannst, okay, mal die Bleeding Edge, die neueste Technologie verwenden und so weiter.
Es gibt ja immer wieder neue Technologien, jetzt ist das große Thema AI, es wird wahrscheinlich eine AI-Developerwelle aufkommen oder sowas und WordPress und WordPress-Development an sich ist für die, ich sag jetzt mal unter Anfungszeichen, für die modernen Entwickler oder die Bleeding Edge -Entwickler jetzt überhaupt nicht so sexy an sich.
Also das ist eher so das alte Ding, was stabil ist, was gut läuft, aber man kann mit anderen Sachen, ich sag jetzt mal, viel coolere, dynamische, keine Ahnung, Artificial Intelligence-Geschichten machen, was auch immer diese Buzzwords jetzt sind.
Lange Zeit waren das auch diese JavaScript -Primits und so weiter und WordPress baut ja halt sehr stark auf PHP auf und das, wo du jetzt gesagt hast, hey, man sollte lieber warten und vielleicht das Neueste verwenden, das mich ein bisschen erinnert, das ist eigentlich so, wenn man sich das anschaut, wieso sich jemand entscheidet, WordPress-Developer jetzt konkret zu werden, ist das dann auch ein bisschen so diese Angehensweise, ich nehme etwas, was ich schon jahrzehntelang etabliert habe, was gut läuft, was eine starke Community hat, was stabil läuft und all diese Sachen und nicht jetzt das Neueste vom Neuen, um damit einfach nur Projekte umzusetzen.
Also an das hat mich da ein bisschen das erinnert, aber damit wir das Thema Gutenberg ein bisschen abschließen, jetzt haben wir das Full-Site -Editing.
Danach, es fehlen ja noch aber einige Features, welche in der Roadmap drinnen sind, wie zum Beispiel Mehrsteuerlichkeit und ich weiß jetzt nicht konkret, welche Features noch, es werden wahrscheinlich wieder.
.
.
Mehrsteuerlichkeit soll es sein, also dass man gemeinsam mehrere Leute in den Inhalten arbeiten kann, das soll die nächste Phase sein und dann soll Mehrsteuerlichkeit kommen, das ist so der Plan, der dann auf der Roadmap steht.
Und jetzt müssen wir mal warten, bis Full-Site -Editing ausgereift ist und dann kommen die anderen Features oder die anderen Milestones dann dazu.
Ja, genau.
Also sind wir zugesehen bei der Hälfte der Gutenberg-Entwicklung oder dauert das noch länger? Hälfte? Keine Ahnung.
Ganz ehrlich, ich meine, die Software ist nie fertig.
Insofern, wenn die nächsten zwei Schritte vorbei sind, werden sich wieder neue Schritte ergeben.
Also so gesehen.
Aber ja, wir sind da jetzt schon, also wir sind in dieser Blockwelt sind wir da jetzt schon zumindest ein paar Schritte drinnen.
Ich habe jetzt vorher auch nicht unbedingt gemeint, dass man immer warten soll und muss sich auf die alten, auf die neuen Sachen sich beseitigen.
Ich finde, man muss sich es halt echt überlegen.
Wenn ich einen privaten Blog für ein paar Freunde betreibe, wo es wirklich wurscht ist, wenn ich da irgendwas kaputt mache oder so, bin ich deutlich gewagter in der Auswahl, als wenn ich für irgendeinen internationalen Konzern die Webseite baue, wo jeden Tag, wo irgendwas kaputt ist, potenziell Kunden und Geld verloren geht.
Also da muss man schon irgendwie, finde ich, auch kontextbezogen denken, wann wo was angebracht ist.
Bevor wir jetzt mit dem Blog-Thema ganz weiter gehen, was mir da irgendwie in der Zusammenarbeit, gerade eben bei diesem, man muss sich überlegen, wofür und für was im Kontext von Blog-Editor noch sehr wichtig ist, wo ich auch schon bei WordCaps drüber geredet habe und so, ich finde es total spannend, dass der Blog -Editor jetzt irgendwie eh entsprechend dieser WordPress-Philosophie, demokratiseres Publishing, sehr viel mehr Möglichkeiten dem Editor in die Hand gibt.
Also dass man jetzt gerade mit Full-Thread -Editing sehr viele Dinge vom Layout und der Gestaltung und der Farben und Typografie und so weiter und so fort direkt im Backend von WordPress machen kann, ohne so wie früher programmieren zu müssen, ohne PHP, CSS und so weiter zu verstehen.
Da vielleicht noch, weil das schließt dann gleichzeitig in die Folgefrage ein, welche die ich noch stellen wollte, und zwar das ganze Wort Full-Thread-Editing.
Es wird halt jetzt von vielen Leuten verwendet, aber was bedeutet für dich Full-Thread-Editing oder wie verstehst du das? Was kann man alles damit machen? Was ermöglicht dir das? Und ja, was ist das überhaupt Full-Thread-Editing? Okay, ja, also bisher war es ja in WordPress so, dass man quasi das gesamte Layout der Seite, wo man Widgets platzieren kann, wo man ein Menü platzieren kann, wo dann der Inhalt von meinem Post reinkommt, das wurde alles in den Themes definiert und zwar in PHP Templates.
Das hat aber immer bedeutet, dass der Editor kann zwar den Inhalt der Webseite verändern, aber jetzt nicht das Layout, die Schriften, die Farbe, das Theme der Webseite.
Weil dafür musste man immer zumindest gewisse Programmierkenntnisse haben.
Und die Idee von Full-Thread-Editing ist eben, das ein bisschen aufzubrechen und auch das gesamte Layout und die Gestaltung der Webseite sehr viel mehr von der codelastigen Programmierer -Seite in die Hand der User, der Editoren zu legen, dass man nämlich wirklich auch das grundlegende Layout der Webseite header, footer, wo wird der Inhalt des Posts dann platziert, gibt es da Spalten oder nicht, gibt es eine Sidebar, welche Schriften, welche Farben, dass all diese Dinge eben nicht mehr im Code bearbeitet werden müssen, sondern dass das direkt in WordPress, im Backend durch einen normalen User ohne Programmierkenntnisse gemacht werden kann.
Das ist irgendwie so die Idee dahinter, die einfach sehr viel mehr Möglichkeiten normalen Usern in die Hand gibt, was ich total super finde, vor allem halt für private kleine Hobby-Seiten, für Firmen oder für Einzelunternehmer, die überhaupt kein wirkliches Budget haben, sondern sich das einfach selber machen wollen, aber deswegen jetzt nicht gleich zum Programmierer werden wollen.
Finde ich total super und da hat sich sicher einiges getan und das war glaube ich auch einer der Gründe, warum eben vor dem Blog-Editor diese ganzen Page Builder-Plugins so floriert haben, weil die eben genau das ermöglicht haben.
Was ich persönlich für meine Arten von Projekten da halt ein bisschen problematisch finde, ist, dass das quasi so im Sinne von mit großer Macht kommt auch große Verantwortung.
Sprich, wenn man dem User all diese Gestaltungsmöglichkeiten in die Hand gibt, gibt man ihm halt auch sehr viel Macht, Dinge kaputt zu machen, nicht schön zu machen und so weiter.
Sprich, jetzt ist man halt als jemand, der eigentlich nur den Inhalt bearbeiten möchte, also Text und Bilder in die Webseite stellen, war einfach gesagt, öfter auch in der Situation, dass man gestalterische Entscheidungen treffen muss.
Und wenn man das möchte, ist das schön, aber oft möchte das ein User vielleicht gar nicht oder möchte es, aber sollte es besser nicht, weil er kein sehr talentierter Designer ist.
Und gerade in, sag ich einmal, größeren Webseiten hat man öfter die Situation, dass man da mehr Arbeitsteilung hat.
Also, dass es da irgendwie Konzepte und Designer gibt, die sich einmal eine Seitenarchitektur überlegen, die ein Design ausarbeiten, das dann irgendwie auch der Corporate Identity oder dem Corporate Design von irgendeiner Firma entspricht und dass das quasi mal von einem Team, das sich wirklich mit dem gut auskennt, gemacht wird und dann die Benutzer, die das tagtäglich mit Inhalten befüllen, sich eben genau mit diesen ganzen Fragen der Gestaltung nicht mehr beschäftigen müssen.
Und das ist etwas, was mit dem Blog-Editor teilweise ein bisschen verwaschen wird.
Also, dass da einfach nicht mehr ganz klar diese Trennlinie zu ziehen ist, sofern man das möchte.
Ist jetzt auch schon wieder ein bisschen besser geworden, aber gerade zu Beginn vom Blog-Editor war es irgendwie so, dass da extrem viele Features zur Gestaltung hineingesteckt worden sind, aber noch kaum Möglichkeiten vorhanden waren, die zu kontrollieren, abzuschalten oder irgendwie ein bisschen in ein Korsett zu bringen.
So der Klassiker, den wahrscheinlich viele Leute sich gefragt haben.
Beim Paragraph, also beim Absatzblog von WordPress gab es gleich von Anfang an die Möglichkeit, irgendwie den ersten Buchstaben als Initial großzumachen.
Ist eine nette Idee, kennt man aus Büchern, schadet sich ein netter Ort, aber um ehrlich zu sein, wenn das nicht ganz speziell in dem Design deiner Webseite drinnen ist, ist das jetzt echt nicht etwas, was die meisten Leute nicht brauchen.
Da hat es zum Beispiel Jahre gedauert, bis es eine Möglichkeit, eine saubere Möglichkeit gab, das auszuschalten.
Das sind dann irgendwie so Sachen, wo ich bei Kunden, die eben da eine Trennung zwischen Design und Inhalt haben wollen, oft auf Probleme stoßen.
Da sind wir teilweise jetzt schon vorangekommen, aber gerade beim Thema Fullsite-Editing gibt es da teilweise noch Dinge, die man nachoptimieren könnte.
Nicht, weil ich das Prinzip schlecht finde, sondern weil es da einfach unterschiedliche Use Cases gibt und momentan ist halt der ich habe kompletten Freiraum und kann machen was ich will, Use Case in meinen Augen oft besser abgedeckt als der ich möchte da eine klare Aufgabenteilung und ein bisschen mehr Restriktionen für die Leute, die nur die Inhalte bearbeiten sollen.
Das hat mir sehr viel geholfen, beim Fullsite -Editing da hast du jetzt so eine, ganz grob gesagt, so eine Konfigurationsdatei, wo du dann Farben definieren kannst, welche im Projekt erscheinen.
Also du hast da nicht mehr, wie zum Beispiel bei einem Paragraph, alle Farben zur Auswahl, die du einstellen kannst, sondern hast nur die zum Beispiel vom Design definierten Farben und der User kann sich nur die auswählen und das finde ich ein sehr cooles Feature, welches mit dem Fullsite -Editing erst gekommen ist oder vielleicht gab es das davor schon, aber es war halt nicht so integriert und nicht so schön implementiert, wie jetzt mit dem Fullsite-Editing.
Findest du dann aber das Ökosystem von WordPress oder Third-Party Anbieter und Shops und so weiter machen ja, manche machen ziemlich viel Geld mit Teams, also mit dem Verkaufen von Third-Party Teams und so weiter.
Jetzt, wie sich Gutenberg entwickelt mit dem Fullsite-Editing und so weiter, glaubst du, wird es in Zukunft überhaupt noch Bedarf an Teams geben oder werden dann die meisten Leute einfach nur fertige ich sage jetzt mal Layouts zum importieren für den Fullsite -Editor erstellen und das Teams an sich obsolet werden? Ja, das ist eine interessante Frage, die heftig diskutiert wird in den letzten Jahren.
Ich muss ganz ehrlich sagen, ich habe da nicht so wirklich eine ausgeprägte Meinung dazu, also die Aufregung, die bei dieser ganzen Debatte oft zu Tage tritt, ist letztlich eigentlich eine mehrheitlich wirtschaftlich begründete, dass halt einfach Sim-Shops Angst haben, dass ihr Business-Modell den Bach runtergeht.
Das tut mir natürlich sehr leid für die Firmen, die da ihr Business-Modell haben und ich hoffe für die, dass die irgendeinen Weg finden, wenn dem wirklich so ist, dass Sims aussterben, ein anderes Business-Modell irgendwie zu finden.
Ob das wirklich der Fall ist, tue ich mir schwer zu prophezeien.
Ich glaube, es wird sich teilweise ein bisschen verschieben, weil ja, wenn man vielleicht keine fertigen Sims mehr verwendet, gibt es ja trotzdem noch, irgendwo muss ja das Design passieren und nicht jeder ist selber ein Designer.
In irgendeiner Form wird es fertige Dinge geben müssen, die man einsetzt, ohne komplett von Null weg selber designen zu müssen.
Ob das dann noch Sims sind, wird sich zeigen, aber es ist ja zum Beispiel das Konzept der Block-Patterns in den letzten Jahren immer mehr forciert worden, wo man halt so Zusammenstellungen, komplexere Zusammenstellungen auf ineinander verschachtelten Blöcken und so weiter in die Seite einfügen kann.
Das könnte ich mir zum Beispiel vorstellen, dass das in einer modularen Art und Weise Teile der Aufgabe, die derzeit Sims haben, übernehmen kann und da könnte dann eventuell ich mir vorstellen, dass halt so Sim-Shops anstatt Sims zu verkaufen dann einfach so Pattern-Libraries zur Verfügung stellen, die ja in gewisser Weise sehr ähnlich sind zu dem, was Sims machen, nur halt auf eine modulare, kleinteiligere Art und Weise.
Das könnte ich mir zum Beispiel vorstellen, dass ein möglicher Weg ist, wo sich das in Zukunft entwickelt.
Ich muss aber auch ganz ehrlich sagen, dass ich zu dieser ganzen Sim-Thematik nicht so viel zu sagen habe, weil ich persönlich für die Projekte, die ich mache, auch bis dato keine fertigen Sims verwendet habe, sondern dass eigentlich immer komplett von scratch individual entwickelte Sims waren.
Eben weil, wenn man ein Projekt hat, wo wirklich es ganz, ganz wichtig ist, dass es genau so ausschaut, wie ein Designer sich das überlegt hat, dass es ganz genau on brand ist, wie das halt in den Corporate Design Richtlinien von irgendeiner Firma festgelegt ist, dann war es bis dato, finde ich, auch schon oft nicht wirklich praktikabel mit fertigen Sims zu arbeiten, weil ich sehe das halt irgendwie als zwei unterschiedliche Zielgruppen.
Diese ganzen fertigen Sims waren halt immer sehr auf einen Consumer-Markt ausgerichtet, also für Leute, die sich mit wenig Geld selber zusammen klicken wollen, eine Webseite.
Die halt einfach bei irgendeinem Hosthaus sich einen Server checken, dann ein paar Euro für ein fertiges Sim ausgeben und dann den Rest mehr oder weniger selber machen.
Das heißt, diese ganzen Sims waren eigentlich immer nicht so sehr als Tool, als Teil eines größeren Gesamtpakets, das irgendeine qualifizierte Person zusammenstellt, aus vielen Einzelteilen konzipiert, sondern immer als Produkt gedacht, als möglichst umfangreiches, alles Abdeckende, kauf dieses eine Ding und dann sind alle deine Sorgen gelöst Produkt.
In diese Sims waren da auch Plugins hineingesteckt, ganz viele verschiedene Features, die man dann ein- und ausschalten konnte, je nachdem, was man wirklich haben wollte.
Die waren immer sehr vollgepackt mit allen Möglichkeiten, weil wir kennen das eh alle, wenn wir in ein Geschäft rein spazieren und irgendein Ding brauchen und uns nicht sonderlich gut auskennen, das erste, was wir machen, wir schauen einfach die Feature-Liste an und oft nehmen wir dann einfach das, wo die Feature-Liste am längsten ist oder wo das Verhältnis zwischen Preis und Feature-Liste das vermeintlich Beste ist.
Kann man so machen, geht auch sicher oft gut, aber gerade bei Technologie oder Software, wo man die Sachen dann ja auch warten und pflegen und langfristig damit arbeiten möchte, hoffentlich, ist es halt, finde ich, oft so, dass auch der Ansatz weniger als mehr sinnvoll sein kann, dass man versucht, irgendwas ganz Schlankes, Kleines zu finden, das genau wirklich nur die Anforderung, die man braucht, abdeckt und das dann vielleicht ergänzt mit individuell entwickelnden Dingen oder mit anderen kleinen Plugins, die dann einzelne konkrete Lösungen machen, die man auch ein- und ausschalten kann, anstatt ein so ein All-in-One-Paket zu kaufen, wo dann vielleicht 90 Features drinnen sind, von denen man eigentlich nur drei braucht und den Rest schleppt man eigentlich nur als Ballast mit und die Benutzeroberfläche wird komplex, das Plugin wird größer, die potenzielle Angriffsfläche für Sicherheitslücken wird mehr und so weiter und so fort.
Und deswegen finde ich das bei den Teams eigentlich auch ähnlich, dass das spannend ist, also ich glaube, so diese Ära der All-in-One -Teams, wo irgendwie noch 27 Funktionalitäten, die eigentlich Plugins sein sollten, mit reingebundelt werden in das Team, die ist definitiv vorbei.
Ja, weil du es vorher angesprochen hast, also wenn man jetzt ein Design bekommt von einer Agentur und dann sich ein Team kauft und dann mithilfe eines fertigen Teams dann das umsetzen will, das Design, das ist einerseits, fand ich das, dass es unmöglich ist, das Pixel genau umzusetzen, weil irgendeine Feature irgendein Feature vom Team, das geht dir dann immer in die Quere oder du hast nicht die Möglichkeit, nicht die Freiheit, alles genau so umzusetzen, wie es im Design steht, oder es ist dann so aufwendig, als Developer kannst du da reingreifen und alles verändern, dass du sowieso mehr Zeit dafür aufwenden musst, ein fertiges Produkt anzupassen, als einfach das von scratch selbst zu machen.
Also das ist dann immer so, ja, das eine hat Vorteile und Nachteile und das andere genauso.
Jetzt zu dem Thema noch, die Ära von diesen Teams, vollgepackt mit Features, hey, du kaufst dir das und musst dir über nichts mehr Sorgen machen, die geht langsam, finde ich, auch dem Ende zu, weil wir dann noch andere Lösungen haben, mit Pagebuildern und allen anderen Sachen, aber so dieser Lifecycle von Pagebuildern, weil es gab ja über die Zeit verschiedene Pagebuilder, wie den Bakery Pagebuilder, der jetzt nicht mehr so stark im Einsatz ist, bei alten Webseiten schon, jetzt ist der Cool Kid on the Block, ist jetzt Elementor zum Beispiel, wird wahrscheinlich dann auch irgendwann zum Ende kommen und es ist immer so, es kommt ein neuer Pagebuilder auf den Markt, der löst ein bestehendes Problem, ist leicht, ist schnell, man kann viel damit machen, dann wird es populär, es kommen immer wieder mehr Anfragen von den Kunden, Features und so weiter, wird vollgepackt mit Features, danach wird es vollgeladen mit Features, also das Backend hat so viele Features, dass du mal einen guten Workshop brauchst, um dich damit auszukennen, es wird langsam, es wird buggy und dann kommt irgendein neuer Pagebuilder, der den ablöst und dann beginnt der Zyklus halt wieder von vorne.
Welche Garantie oder welche Sicherheit haben wir? Ich weiß, es ist gemein dir diese Frage zu stellen, weil du jetzt nicht im Gutenberg Core Development Team dabei bist, ich meine, ich weiß, dass du auch sehr aktiv bist in der Community und im Development, auch, glaube ich, für WordPress Core an sich, aber ich schrei ganz gerne mal von der Seitenlinie irgendwas rein, aber wirklich aktiv was beitragen, bin ich nicht sonderlich.
Aber welche Sicherheit haben wir, glaubst du, dass das auch nicht bei Gutenberg passiert, dass das dann immer weiter entwickelt wird, immer mehr Features, immer buggier, bis dann irgendeine Lösung kommt, irgendein Plugin, welches einfach besser ist als Gutenberg, aber Gutenberg ist dann in WordPress Core integriert und dann haben wir wieder dieses Problem, hey, WordPress ist hier, aber es gibt diese anderen coolen Lösungen, die viel besser sind für das, was du machen willst und diese Garantie haben wir nicht, aber wie siehst du das? Ja, also ich glaube, prinzipiell ist es so, dass generell die Wahrscheinlichkeit, dass WordPress Core Dinge langfristig maintained werden und einfach auch nur in einigen Jahren existieren und funktionieren werden, einfach immer viel, viel höher ist, als wenn man auf das Produkt von irgendeiner anderen Firma setzt, weil im Endeffekt jede Firma, die irgendein Plugin oder irgendeine Sache, die an WordPress Undoc dransetzt, ist halt immer nur diese eine Firma, dagegen alles, was in WordPress Core selber entwickelt wird, ist halt die gesamte Community und wenn da eine Entwicklerin oder ein Entwickler irgendwann einmal die Community verlassen, gibt es immer noch einen anderen, der da weitermacht, das heißt, ich glaube generell, es ist immer der sichere Weg, möglichst nah an WordPress Core dran zu bleiben.
Sobald man irgendwelche Lösungen einsetzt, die halt von irgendeinem konkreten Plugin oder irgendeiner Firma abhängen, ist halt immer das Risiko, dass die irgendwann einmal pleite gehen, sich irgendwie in eine andere Richtung entwickeln oder sonst was.
Das ist mal so prinzipiell und eh eigentlich total selbsterklärend und logisch.
Andererseits ist es natürlich gerade deswegen, weil WordPress selber halt diesen ganzen Vergangenheit verpflichtet ist, natürlich auch so, dass die Entwicklung von WordPress Core selber natürlich sehr viel vorsichtiger, langsamer vonstatten geht, als alles, was irgendein Plugin oder eine Firma im WordPress-Ökosystem machen kann.
Wenn ich da ein kleineres, unabhängiges Team bin, kann ich natürlich schnell mal was Neues ausprobieren, schneller aus Fehler lernen und Dinge ganz anders machen, bin noch sehr viel freier darin, manchmal einfach zu sagen, okay, neue Version, alles anders.
Insofern sehe ich das so ein bisschen als einen Feedback-Kreislauf.
Das Ökosystem rund um WordPress kann schneller Sachen entwickeln und ausprobieren und dabei auch mal einen anderen Weg einschlagen und WordPress Core kann man quasi schauen, was hat sich über die Zeit als effektiv herauskristallisiert und hat sich bewährt und dann versuchen, das abzubilden in WordPress Core selber.
Also ich würde mal sagen, idealerweise ist das, was in WordPress Core selber landet, das Best-of von dem, was vorher alle möglichen anderen Plugins und Themes und so weiter ausprobiert haben und wo sich dann irgendwie das Beste herauskristallisiert.
Das wäre also der Idealzustand.
Ich muss sagen, ich habe jetzt mit den PageBuilder -Plugins nicht allzu viel Erfahrung, genau aus diesem Grund, weil ich die schon wieder aufgekommen sind, nur mit Vorsicht beäugt habe, eben genau aus dem Grund, dass wie man ja jetzt auch sieht, viele von denen, auch wenn einige Elemente scheinbar noch ganz gut funktionieren, viele von denen mittlerweile auch schon wieder verschwunden sind.
Wenn ich eine Webseite baue, die nicht nur zwei, drei Jahre funktionieren soll, sondern die vielleicht zehn Jahre funktionieren soll, wäre ich da wahrscheinlich, wenn ich auf das falsche Pferd gesetzt hätte, da bei manchen Projekten schon jetzt in einer ziemlich unangenehmen Situation, dass man irgendwie die ganze Webseite mit einem PageBuilder, der eigentlich tot ist, gebaut hat und das dann eigentlich zwangsläufig bedeutet, dass man entweder einen extrem mühsamen Migrationsprozess durchmachen muss oder eigentlich von vorn anfangen.
Ja, und das ist auch ein bisschen etwas, womit ich mir schwer tue, eigentlich die Frage zu beantworten, weil wenn ein Kunde gerade ein neues Business aufmacht oder hat ein bestehendes Business und will sich eine Webseite bauen und wirklich da Geld in die Hand nehmen und das als Investition sehen, sie eine Webseite zu bauen, dann weiß man nie wirklich, wie langlebig dann die Webseite sein wird oder wann es notwendig sein wird, ein Relaunch zu machen, wenn früher oder später wird es wahrscheinlich notwendig sein, ein Relaunch zu machen, außer du machst einmal eine Informationsseite und bearbeitest die Seite nicht und ja, das ist halt wiederum eine andere Eingehensweise, aber normalerweise, weil sich WordPress weiterentwickelt, weil sich PHP weiterentwickelt, weil neue Technologien auf den Markt kommen, also PHP-Versionen sind nicht mehr aktuell und all diese Sachen können passieren, deswegen ist die Wahrscheinlichkeit da, dass früher oder später die Webseite nicht mehr wirklich weiter ich würde jetzt nicht sagen wartbar wird, aber es macht keinen Sinn, auf der Webseite weiter aufzubauen, sondern es würde mehr Sinn machen, einen Relaunch zu machen, um dann wirklich auf den neuesten technologischen Stand oder auf den neuesten stabilen technologischen Stand die Webseite zu bringen und dann wirklich vielleicht ein neues Design mit dem Relaunch zu machen.
Wie lange glaubst du oder schätzt du, kann man eine Webseite gebrauchen, jetzt das falsche Wort, aber wann wäre ein Relaunch oder wie lange lebt dann so eine Webseite, wenn man die umsetzt, mit sagen wir jetzt mal fertigen Tools und Custom-Entwicklungen, macht das einen Unterschied oder wie siehst du das ganze Thema von der Langlebigkeit von Webseiten? Ich glaube, da gibt es nicht eine das kann man nicht so pauschal beantworten, das hängt immer von den konkreten Umständen ab, die erste Frage, die sich für mich einmal stellt ist, ist das überhaupt relevant, dass diese Webseite lange leben muss? Das Beispiel, das ich vorher schon mal gebracht habe, wenn ich die Webseite für irgendeine einmalige Veranstaltung mache, ist das vollkommen egal, ob die Webseite langlebig ist, weil spätestens nach einem paar Monaten nach der Veranstaltung interessiert die Webseite oft eh keinen mehr und dann kann man vielleicht noch irgendwie einen statischen Export davon machen und das war es dann.
Wenn das relevant ist, muss man sich halt natürlich Gedanken darüber machen, wie man mit dem Thema umgehen möchte.
Man kann natürlich auch den Ansatz fahren und sagen, wir wollen sowieso uns alle zwei Jahre neu erfinden und dann die Webseite komplett wegschmeißen und von vorne machen.
Wenn man das von Anfang an wirklich weiß und einplant und das so die Herangehensweise ist, dann kann man natürlich bei der Entwicklung von einer Webseite ganz anders herangehen als wenn man von vornherein mit dem Zugang an die Sache herangeht, die Webseite muss mindestens zehn Jahre ohne gröbere Umbauten überleben können.
Das ist eine Frage, wo man auch nicht pauschal sagen kann, was ist richtig, was ist falsch und das hängt halt immer sehr von für wen ist diese Webseite ab.
Da muss man einfach gut sich unterhalten, gut zuhören und darauf eingehen und das kann ganz unterschiedlich sein.
Es ist auch nicht unbedingt an so Dinge wie Großhilfefirma oder so geknüpft, weil bei einer großen Firma kann das einerseits bedeuten, die wollen eine Webseite, die möglichst lange lebt.
Es kann aber auch genauso gut bedeuten, die haben das Geld, um die Webseite alle zwei Jahre komplett neu zu machen.
Genauso kann es bei einer kleinen Firma oder einem Einzelunternehmer in einem Handwerk oder so sein, dass der sagt, ich möchte einfach, dass die Webseite, wenn ich sie jetzt schon mache, dann möglichst lange lebt oder er sagt, ich habe jetzt gerade nicht viel Geld und möchte es deswegen möglichst schnell und billig über die Bühne kriegen und wenn das in ein paar Jahren kaputt ist, dann ist das ein Problem, das ich mir in ein paar Jahren überlege, wer weiß, ob es mein Geschäft in ein paar Jahren überhaupt noch gibt.
Ja, also das sind so Fragen, die man stellen muss und das ist jetzt eigentlich auch kein technisches Problem, sondern das ist eigentlich ein wirtschaftliches Projektmanagementproblem wie auch immer, was man einfach mit dem jeweiligen Kunden oder für wen halt auch immer die Webseite ist, klären muss.
Auch wenn das die eigene Webseite ist, muss man sich das auch mit sich selber klären und einfach darüber nachdenken, was da der Plan ist.
Ja, und wenn man jetzt der Serviceanbieter ist oder der Dienstleister, der dann die Webseite umsetzt und für die Kunden realisiert und wenn man merkt, hey, der Kunde sieht das eher als eine einmalige Investition und eine auch existierte Webseite in alle Ewigkeiten, sollte man das auch als Dienstleister hier in dem Fall auch klar dem Kunden kommunizieren, wie das ausschaut, was das bedeutet und oft kann man das, manche Sachen einfach nicht vorhersehen, aber zumindest dem Kunden klar machen, hey, die Webseite wird nicht für alle Ewigkeiten existieren, wenn du die Webseite stark weiterentwickeln willst oder alle möglichen Sachen, also klar, wenn du einen statischen Export machst, wie du gesagt hast, dann kannst du die irgendwo hochladen als HTML und dann kann die wahrscheinlich in alle Ewigkeiten existieren, aber es ist dann auch immer in der Verantwortung von den Dienstleistern, das auch klar und deutlich dem Kunden zu kommunizieren, was da damit verbunden ist oder was die Lebenszeit einer Webseite sein könnte oder was er braucht, was er nicht braucht, was die Umstände sind und so weiter.
Das, was ich noch kurz ansprechen wollte, ist das, worauf du dich eigentlich spezialisiert hast, also sind eher Custom-Lösungen oder maßgeschneiderte Lösungen zu machen und zu programmieren und nicht einfach fertige Plugins zu verwenden oder Themes zu kaufen und das als Lösungen anzubieten, weil ich bin da genauso, also ich habe so einen sehr ähnlichen Weg eingeschlagen, aber was war deine Motivation, das so zu machen und jetzt nicht einfach zu sagen, hey, der Kunde hat dieses Problem, es gibt ein fertiges Plugin dafür, ich nehme das, bastle das ein bisschen um und verkaufe das als eine fertige Lösung? Ja, wie bin ich da gelandet? Was ist passiert? Nein, es ist so, wenn du anfängst, ist es einmal prinzipiell so, wenn du dich selbstständig machst, bist du meistens einmal in der Situation, dass du alles nehmen musst, was du irgendwie kriegen kannst und froh bist, dass du Arbeit hast.
Gleichzeitig bist du am Anfang deiner Karriere, sage ich mal, wahrscheinlich auch noch nicht der absolute Profi, das heißt, am Anfang bleibt dir wahrscheinlich nichts anderes übrig, als eher auf viele kleine, günstige Projekte zu setzen, anstatt sofort auf Großqualität und Kompliziert zu setzen.
Das ist mal so die pragmatische Antwort, also quasi auf die Strategie, auf komplexere, individuelle Anforderungen zu setzen, die hat man erst, wenn man ein bisschen Erfahrung hat.
Das ist eine zwingende Voraussetzung dafür, dass sich die Möglichkeit dann irgendwann einmal ergeben hat.
Dann gibt es noch den ganz langweiligen wirtschaftlichen Grund, wenn dein einziges Alleinstellungsmerkmal ist, dass du billig bist, ist halt die Konkurrenz deutlich brutaler, als wenn du versuchst, über die Jahre mehr technische Kompetenz aufzubauen und auf der Ebene konkurrierst, weil da einfach der Kampf nicht ganz so brutal ist.
Ich habe halt Gott sei Dank mittlerweile das Glück, dass ich genug Erfahrung habe, dass ich kein blutiger Anfänger mehr bin und mich nicht mehr unbedingt auf dem Preisniveau mit den Leuten betteln muss.
Das ist schön, wenn man an den Punkt kommt.
Das ist mal so die nonanette Antwort.
Ganz sonst bin ich halt auch der Ansicht, du kennst sicher diesen Spruch Good fast, cheap, pick two.
Nochmal.
Bei einem Projekt gibt es immer drei wichtige Faktoren, dass es gut gemacht ist, dass es schnell erledigt wird und dass es billig ist.
Du kannst im Normalfall nicht alle drei Faktoren erfüllen.
Wenn es gut und schnell ist, wird es normalerweise ziemlich teuer.
Wenn es schnell und billig ist, wird es selten gut.
Du kannst im Normalfall von diesen drei Dingen eigentlich nur zwei aussuchen.
Irgendwas musst du immer opfern.
Gute Arbeit abzuliefern war mir im Rahmen meiner Möglichkeiten immer schon wichtig.
Darum habe ich mich da einfach irgendwann mehr darauf konzentriert, das zu machen.
Dann hat sich das mit den Kunden ergeben.
Wobei ich auch dazu sagen muss, dass mit dem schnell und billig ist halt auch oft so eine Frage, über welchen Zeitraum betrachtet.
Wenn eine Webseite anfänglich schnell und billig erstellt wird, und sie dann aber für noch kürzester Zeit wieder neu gemacht werden muss, weil sie einfach auseinanderfallen, weil sie nicht gut wartbar ist, wenn man das dann über zehn Jahre rechnet, ist halt die Frage, ob fünf billige Webseiten zu machen, nicht unterm Strich dann doch teurer wird, als ein oder zweimal eine teure, gut gemachte, wartbare Webseite zu machen.
Muss nicht sein, kann aber oft sein, dass das dann unterm Strich sogar billiger wird.
Das ist mal das eine.
Das zweite, was glaube ich, weil du gerade angesprochen hast, dass bei vielen Leuten im Kopf das immer noch so funktioniert, dass eine Webseite so wie ein Flyer ist, den man einmal macht, und dann ist der fertig, das ist halt einfach nicht so.
Eine Webseite ist ein lebendes Ding, das ständig Updates braucht, gepflegt werden muss, mit Änderungen in WordPress Core irgendwie mithalten muss und so weiter.
Sprich, eine Webseite ist nie fertig.
Das muss man manchen Leuten erst klar machen, aber das ist einfach so.
Eine Webseite ist nie fertig.
Wenn man sie nicht pflegt, dann verfällt sie einfach mit der Zeit.
Hält nicht mit der Technik mit und so weiter.
Das heißt, man muss sich einfach um eine Webseite kümmern und das ist eigentlich viel wichtiger, als wie das Ganze am Anfang abläuft, weil schnell die Webseite zu erstellen ist eine Sache, aber sie dann wartbar zu machen und zu halten ist viel schwieriger.
Also, wenn du ganz kurz zusammenfassend, weil, keine Ahnung, ein paar Mal bin ich schon in das Gespräch reingekommen, okay, WordPress hat ja den Ruf, schnell und günstig eine Webseite zu machen, aber dann kommst du dann teilweise, hast du dann solche Anforderungen oder solche Wünschen von Kunden, wo du merkst, boah, also es ist machbar, es ist auf jeden Fall machbar, es ist halt nur zeitintensiv, wenn es gescheit gemacht werden soll.
Also eben dieses Dreigespann, welches du vorher erwähnt hast.
Kurz zusammenfassend wird es wahrscheinlich so sein, dass es immer davon abhängt, was genau der Kunde will, wie er das umgesetzt hat, was die Umstände sind, welches Budget ist da und je nachdem, was es dann ist, kann man sich entscheiden, was die beste Lösung ist.
Und ich will jetzt auch nicht sagen, hey, fertige Lösungen mit Plugins sind schlecht oder hey, es gibt nur Custom-Lösungen, sind die besten.
Ich will auch nicht behaupten, dass du das jetzt gesagt hast oder sowas, sondern ich wollte es mal nur zusammenfassend erwähnt haben.
Und es ist immer abhängig von den Umständen, wenn ich das jetzt korrekt verstanden habe.
Auf jeden Fall.
Ein Nachsatz dazu noch, wenn man irgendwie nicht in der schönen, aber auch äußerst seltenen Situation ist, dass Zeit und Geld egal sind, dann muss man halt pragmatisch sein.
Und da hilft auch oft einfach nicht nur darüber zu reden, was hätten wir gern, sondern auch was für ein Budget haben wir zur Verfügung.
Wenn man diese zwei Dinge gleichzeitig betrachtet, dann muss man halt manchmal einfach pragmatisch sagen, genauso wie ihr euch das überlegt habt, geht sich das in dem Budget einfach nicht aus.
Das ist nicht möglich.
Selbst wenn man das versucht, in dieses Budget zu quetschen, kann man es nur so pfuschig machen, dass damit keiner glücklich wird.
Da hilft es dann, finde ich, oft einfach klar zu sagen, das geht nicht so, aber gehen wir noch mal einen Schritt zurück, überlegen wir, warum will das jemand so haben? Was ist das Ziel, was dahinter steht? Weil eine Webseite ist ja eigentlich so gut wie nie ein Selbstzweck.
Man möchte irgendwas erreichen, etwas verkaufen, mehr Leute erreichen und so weiter.
Und wenn man dann oft einen Schritt zurückgeht und sich das eigentlich zugrunde liegende Ziel und Problem anschaut, findet man dann vielleicht oft eine andere Lösung, die zwar vielleicht nicht so perfekt ist, wie das, was man am Anfang im Auge hatte, aber die dasselbe Ziel in einem anderen Umfang vielleicht, aber doch dasselbe Ziel erfüllt und sich leichter umsetzen lässt.
Manchmal einfach, weil manche Dinge mit WordPress einfach sind und manche Dinge schwierig sind.
Und wenn man da einen pragmatischen Ansatz nimmt und sich das überlegt, wie kann man das Ziel möglichst effizient und einfach umsetzen, ohne stur darauf zu beharren, dass das genau so gemacht werden muss, wie sich das jemand am Anfang vielleicht vorgestellt hat, dann ist das oft auch eine gute Idee, wenn man damit sehr viel effizienter ans Ziel kommen kann.
Finde ich mega cool über alle Themen, über die wir heute geredet haben.
Langsam kommen wir dann schon leider zum Ende der Episode.
Eine Story mag ich nur kurz erwähnen, weil das eine ziemlich interessante Story ist.
Und zwar hast du mal ein Erweiterungsplugin für Yoast geschrieben und dann wurde das von, wenn ich das richtig in Erinnerung habe, von Yoast übernommen und ist jetzt im WordPress Plugin Repository frei verfügbar zum Download.
Kannst du das ein bisschen so kurz erzählen, die Story? Tja, es passt eigentlich relativ gut zu dem, was ich jetzt gerade gesagt habe, dass man sich einfach überlegen muss, wie man effizient an Sachen herangeht.
Ich hatte damals einfach das Problem, dass ich bei einem Kunden eben noch vor Block Editor Zeiten sehr stark auf Advanced Custom Field gesetzt hatte und das aber mit manchen Features von Yoast nicht gut harmoniert hat, weil er einfach die Daten nicht gesehen hat.
Dann habe ich irgendwie geschaut, was kann man da machen, habe im Plugin Repository ein Plugin entdeckt, dass das prinzipiell macht, aber irgendwie in einem sehr rudimentären Feature Set gemacht hat.
Und dann habe ich mir eben gedacht, mein Kunde möchte das, mein Kunde zahlt das auch, habe mir trotzdem überlegt, ist es jetzt effizient, das komplett von Null weg neu zu schreiben für meinen Kunden oder ist es vielleicht schlauer, eine Lösung, die es schon gibt, die quasi schon ein bisschen was davon anbietet, auf das ich aufbauen kann, zu setzen.
Und dann habe ich mir das eben angeschaut und habe gesehen, ja, das kann man so erweitern, wie ich mir das vorstelle, wie ich das brauchen kann und habe das einfach einmal für den Eigenbedarf für mein Kundenprojekt umgeschrieben und wie es dann fertig war, habe ich mir gedacht, okay, eigentlich bin ich sicher nicht der Einzige, der das brauchen kann.
Es wäre doch ganz nett, das irgendwie wieder zurückzugeben an die Community.
Gleichzeitig weiß ich aber auch aus Gesprächen mit anderen Leuten, dass ein Plugin im Plugin Repository zu haben, das Plugin zu programmieren ist in gewisser Weise oft das geringste Problem, sondern es sind dann einfach der Support und die Pflege und so weiter, eh wieder Thema Wartung, oft sehr zeitaufwendig und mir war einfach klar, dass ich das als einzelner Freelancer nicht abdecken kann oder will und anstatt da irgendwas zu versuchen, was nicht funktionieren kann, weil es einfach im Rahmen des in dem Fall Zeitbudgets von mir nicht möglich ist, habe ich mir gedacht, okay, wie kann ich das gleichzeitig doch wieder der Community zur Verfügung stellen, aber ohne, dass dann die ganze Support und mehr hängen bleibt und dann habe ich einfach einmal die Entwickler von Advanced Custom Fields und Jost, weil das eben diese zwei Plugins miteinander verbunden hat, angeschrieben und gesagt, hey Leute, ich würde das hergeben, vorausgesetzt ihr nehmt es dann und kümmert euch drum und das hat Gott sei Dank super funktioniert, Jost war ganz begeistert von der Idee, die haben dann mit mir nochmal drüber geschaut, wir haben dann noch gemeinsam ein paar Dinge feingetun und dann habe ich ihnen das einfach in die Hand gedrückt und mich dann auch relativ bald wieder verabschiedet aus der Pflege von dem Plugin und habe damit jetzt eigentlich auch seit Jahren nichts mehr zu tun.
Ich weiß auch gar nicht, um ehrlich zu sein, weil ich es bei dem Kunden von mir selber mittlerweile gar nicht mehr brauche, wie sich dieses Plugin entwickelt hat, aber das ist auch, finde ich, okay so, weil das ist ja gerade das Schöne an einer Open Source Community, dass man da einfach Dinge teilt und dann das auch mal weitergegeben wird und dann kümmert sich wieder wer andere drum, Hauptsache es wird irgendwie weiter gepflegt und existiert weiter, also das war einfach eine schöne Geschichte.
Also das Plugin ist glaube ich ACF Jost Glue oder so? Wie bitte? Das Plugin, das heißt glaube ich ACF Jost Glue oder so, das heißt die Verbindungsschnittstelle von ACF und Jost, also falls ihr das mal schon verwendet habt, dann hier bitte, der Thomas war dafür verantwortlich.
Aber wenn irgendwas nicht passt, bitte nicht bei mir beschweren, ich habe damit seit Jahren nichts mehr zu tun.
Du bekommst nur die Credits.
Ein bisschen, vielleicht.
Am Ende stelle ich dann noch immer ein paar Bullet-Fragen, also drei um genau zu sein und damit dich die Leute ein bisschen so erkennen lernen können.
Die erste Frage, sag einfach das Erste, was dir einfällt.
Die erste Frage wäre, WordPress und Web-Development und das Ganze was du jetzt machst, gibt es nicht, was würdest du alternativ als Beruf ausüben? Keine Ahnung, um ehrlich zu sein.
Wahrscheinlich auch irgendwas mit einer Schnittstelle zwischen Technik und Kreativität oder was genau, müsste ich länger darüber nachdenken.
Was ist das nervigste WordPress-Feature? Das nervigste WordPress-Feature? Für mich als Entwickler ist oft die Backwards -Kompatibilität und der uralte Code das nervigste Feature, obwohl das gleichzeitig für die User oft der größte Benefit ist.
Und was war dein letzter Aha-Moment bei WordPress, also wo du geschaut hast so, das kann WordPress auch? Puh, das war tatsächlich vor zwei Wochen beim WordCamp Wien.
Es war nur leider was zutiefst technisches.
Es ging um das Datenspeichermodell von guten Backpack-Blöcken und das etwas, was mir daran nicht so gut gefallen hat, dass da die Daten als HTML gespeichert werden und nicht in einer rohen, direkt verfügbaren Variante, dass es da mehr Möglichkeiten gibt, das anders zu lösen, als ich dachte.
Was ich in einem Gespräch mit einem Core-Entwickler herausgefunden habe.
Aber ja, die Details sind wahrscheinlich jetzt zu spezifisch hier.
Aber es ist bei einem WordCamp passiert, wo ich mich einfach mit Leuten unterhalten habe, die dort vor Ort waren.
Also, wenn ihr euch mit WordPress auseinandersetzt geht zu WordCamps, dort passieren die allermeisten Aha-Momente.
Für mich zumindest.
Cool.
Ja, dann vielen, vielen Dank.
Wenn du gerne noch irgendwas von deiner Seite her präsentieren, pitchen möchtest, oder einfach, keine Ahnung, vielleicht deine Dienstleistung, deine Webseite oder andere Projekte, hier wäre jetzt das Spotlight, so hier bitte, go for it.
Also, von mir irgendwas pitchen, habe ich eigentlich überhaupt keinen Bedarf.
Das Einzige, was ich sagen würde, ist, wenn du WordPress verwendest, dann, und damit möglicherweise auch Geld verdienst, dann fände ich es schön, wenn man sich irgendwie in die Community einbringt.
Sei es, indem man einfach nur zu WordCamps geht, Vorträge hält, sich in Meetups organisiert, oder irgendeiner anderen Form Mitarbeiten an dem Projekt, weil das WordPress-Projekt ist immer nur so stark, wie die Summe der Einzelteile der Leute, die mit dran arbeiten.
Cool.
Das würde, glaube ich, die allerletzte Frage abschließen, weil dann stelle ich auch immer die Frage, ob es irgendeine finale Message gibt, die du an die Zuschauer und Zuhörerinnen weitergeben magst.
Wäre das genau das, was du jetzt gesagt hast, oder würdest du noch gerne was dazu sagen? Ja, das erwähne ich dir.
Geht zu WordCamps, unterhaltet euch dort mit den Leuten, egal aus welchem Grund.
Sei es, weil ihr Jobs sucht, weil ihr Aufträge sucht, weil ihr einfach nur irgendwas lernen wollt, oder weil ihr einfach nur nette Leute kennenlernen müsst.
Geht zu WordCamps.
Kann ich bestätigen.
Passt dann.
Vielen, vielen Dank für deine Zeit.
Hat mich mega gefreut.
Fragen bitte alle in den Kommentaren.
Schreiben, falls da irgendwelche Fragen aufkommen, könnte ich dir einfach gruppiert zukommen lassen, falls genau spezifisch an dich Fragen kommen, und dann bekommst du die Antworten direkt von Thomas.
Ja, vielen Dank.
Hat mich gefreut und hoffentlich sehen wir uns bald wieder in real life.
Bitte gerne.
Hat mir auch Spaß gemacht.
Bis bald.
.