Das Theme-Desaster von WordPress

„Themes werden sterben“ verkündet Robert Windisch vom „WP Sofa“-Podcast aus ja immer wieder. Aber obwohl es natürlich nicht ganz so schlimm um die Themes steht, so ist die Situation alles andere als rosig. Warum spreche ich dann trotzdem von einem Desaster? Weil hier mehrere Herausforderungen zusammenkommen. Der Block-Editor (Gutenberg), jQuery-Umstellung und das kommende Full-Site-Editing. Das „Fast Moving Target“ Block-Editor erfordert neue Tools und Fähigkeiten, die nicht unbedingt bisher gebraucht wurden. Zeitgleich ändert sich das Umfeld mit „breaking changes“ in jeder neuen Hauptversion. Alle kleineren Theme-Entwickler lernen und warten ab und genau jetzt erfordert die jQuery-Umstellung aber Updates, weil es sonst knallt …

Auf dem Rücken der Nutzer wird hier Vertrauen in ganz großen Stile verspielt. Und wenn du an Verschwörungstheorien glaubst, dann ist der Weg nicht weit, darin einen Sinn zu sehen die kleinen Hobby-Entwickler abzustoßen und das Umfeld zu professionalisieren und nur noch die „Big Player“ überleben zu lassen.

Aber nochmal von Anfang an …

Der Block-Editor erfordert mehr als nur HTML, CSS und PHP. Das bisherige Set an Tools und Fähigkeiten ist überholt. Theme-Entwickler:innen müssen sich nun mit Webpack, React & Co auseinandersetzen. Oder dieses Wissen einkaufen. Auf einem Markt, der wenige Expert:innen dazu bereit hält. Es erfordert also Zeit und/oder Geld Schritt zu halten mit den Entwicklungen des Block-Editors, der ein Entwicklungstempo vorgibt, das enorm ist. Alle zwei Wochen ein Release und immer wieder massive Probleme, ungefixte Bugs und Paradigmen-Wechsel, die das Erstellen einer Doku unmöglich machen. Nichts bleibt lange gleich und der Support- und Dokumentationsaufwand sind enorm.

Doch genau in diese Zeit nun kommt WordPress und stellt die jQuery-Version um. Wieso das nicht als vorbereitende Maßnahme viel früher angegangen wurde, keine Ahnung. Doch was ich in meiner täglichen Arbeit merke: Nicht jeder Theme-Entwickler kümmert sich darum. Die berühmte Rückwärtskompatibilität ist nur durch ein Extra-Plugin gewährleistet und der Laie ist aufgeschmissen. Themes gehen kaputt, Funktionalitäten gehen verloren – Vertrauen der User schwindet in das System WordPress. Der Marktanteil von WordPress ist ja angeblich bei 40%. Doch dabei werden die traffic-stärksten 10 Millionen Websites angeschaut. Nicht die kleine Frisör-Installation. Doch genau da, an der Basis, verprellen wir die User.

Ich vermute, dass kaum ein(e) Theme-Entwickler:in noch viel Zeit, Arbeit und damit Geld in ein Theme stecken möchte, dass mit dem kommenden Full Site Editing womöglich sowieso dem Untergang geweiht ist. Selbst hochgelobte, gut bewertete Themes von etablierten Theme-Herstellern (keine Einzel-Entwickler:innen) veröffentlichen keine neuen Updates. Bugs werden nicht gefixt oder Fehler bleiben online … was bleibt ist der der Ausweg Relaunch.

Aber wohin gehen die User in dieser Phase? Zu den großen Anbietern, die schnell genug adaptieren konnten. Wer heutzutage ein Theme sucht ist gut beraten etwas zu nehmen, was auch in Zukunft noch Bestand hat. Früher waren kreative Themes die Regel, doch nun haben wir Hello, Go, GeneratePress, Astra, OceanWP und Co. – ausnahmslos große Anbieter.

Kurios anmutend, ist dann auch noch, dass Matt Mullenweg die Schuld dem Theme Review Team und deren Regeln gibt:

The .org theme directory is particularly bad when you compare it to any half-decent commercial theme marketing page, or the designs available on other site building services or Themeforest directories. The .org theme directory rules and update mechanism have driven out creative contributions, it’s largely crowded out by upsell motived contributions.

(zitiert nach https://wptavern.com/upsells-barriers-and-the-end-beginning-of-the-quality-free-themes-era)

Es ist ja nun nicht so, dass den Entwickler:innen von seitens WordPress.org da viel geboten wird. Individuelle Inhalte für die Vorschau sind erst seit kurzem überhaupt möglich. Und die meisten Regeln können durch Companion Plugins ad absurdum geführt werden.

Anstatt die Regeln zu ändern oder mehr Mitarbeiter:innen für das Theme Review Team bereit zu stellen wird ja auch der Monopolismus gefördert und die Automattic-Themes in das Jetpack-Angebot eingegliedert. Gut für den eigenen Upsell – schlecht für das Ökosystem. Aber immer mit dem Finger auf die anderen zeigen.

Das Theme-Beispiel zeigt nochmal genau die Gründe auf, warum ich meine regelmäßigen Contributions fast komplett herunter gefahren habe. Es wird immer viel gefordert, aber wenig geboten (außer dem System und der Plattform selbst). Die GPL und Open-Source werden immer dann bemüht, wenn es um das Teilen geht. Selbst aber wird nur dann gegeben, wenn es nicht schmerzt. Aussagen, wie die Behauptung, der Block-Editor sei kein Angriff auf die Page Builder, kassieren sich mit den Jahren selbst.

Am Ende werden nur die Anbieter überleben, die genügend Ressourcen haben, um das Ganze zu stemmen. Neue Techniken lernen, auf den Zug aufspringen und eine Nische finden, die noch nicht abgedeckt wird und zwei Kriterien erfüllt: So groß, dass es genügend Menschen interessiert, denen eine Pro-Version verkauft werden kann (oder ein Service), aber klein genug, dass es nicht vom Core (oder Jetpack) übernommen wird.

Viel Glück dabei.

Und ich sehe dann dabei zu, wie die Hobby-Blogger und Bastler, die WordPress groß gemacht haben, sich etwas anderes suchen. Während wir immer weniger, aber dafür immer größere Anbieter haben. Vor allem Hoster, die das ganze dann auch immer mehr mit ihrer eigenen Technik verzahnen. Wann kommt neben den Entwicklungstool auch eine App nur für WP Engine /Kinsta / GoDaddy Kunden? Monopolismus war auch nie gut dafür die kreativsten Lösungen hervorzubringen …

Ich schreibe das mit Wut und Frustration im Bauch. Machen wir den Reality-Check in den Kommentaren? Wer findet, ich übertreibe? Wer findet, ich habe Recht und das System stinkt? Und wer findet, dass ich eindeutig zu viel Anglizismen in diesem Artikel benutzt habe?

Nachtrag: Danke an Simon vom WP Letter für die Erwähnung. Den dort ebenfalls zum Thema erwähnte Artikel von Fränk Klein möchte ich euch allen ebenfalls ans Herz legen. Er geht etwas sachlicher an die Sache heran, aber trifft einen meiner Punkte:

Should Full-Site Editing be in WordPress 5.8?

38 Antworten auf Das Theme-Desaster von WordPress

  1. Hallo Torsten,

    Du sprichst mir aus der Seele! Ich halte den ganzen Block-Editor zwar per se – als default – für Unsinn. Genau wie das full site editing. Denn ausgerechnet die strenge Trennung von Gestaltung und Inhalt war für mich immer der entscheidende Vorteil eines Content (!) Management Systems, wie es WordPress war. Und bei der ganzen Gutenberg-Entscheidung wurde meines Erachtens zu stark der Fokus auf Nicht-Bloggende gelegt, so dass die Zielgruppe, die einst WordPress groß machte, mittlerweile nur noch als Minderheit angesehen kann. Oder durch Automattic so angesehen wird.
    Mir geht auf jeden Fall die zunehmende Monopolisierung Richtung Automattic, die Du ja auch thematisierst, gehörig auf den Zeiger. Vor allem, weil es der Laden mit dem Datenschutz bzw. dem, was wir Europäer unter Datenschutz verstehen und auch leben (müssen; Stichwort DSGVO) nicht so wirklich hat. Ich halte Jetpack und andere Dienste, die von Automattic angeboten werden, immer noch für vollkommen unvereinbar mit dem europäischen Datenschutzvorgaben.
    Ich bin jedenfalls langsam dabei meine Pläne in Richtung Absprung von WordPress und Wechsel zu Classicpress zu konkretisieren. Denn ich selber habe keine Lust mehr auf das eigensinnige Gebahren von Matt Mullenweg und seiner Mitstretiter, genauso wenig, wie ich Lust darauf habe, befreundeten Bloggern, die ich bei der Rechnik unterstütze, zu erklären, warum ein Relaunch bald unvermeidlich ist. Und das, obwohl sie mit Design und Funktionalität des bisherigen Themes und Blog-Setups seit Jahren zufrieden sind.

    • Gestaltung und Inhalt zu trennen und gleichzeitig einen Page Builder Block-Editor anzubieten ist ja das schizophrene Ziel, was niemals erfüllt werden kann. So richtig stylen kannst du ja nicht, aber so richtig getrennt ist Design und Inhalt auch nicht mehr.

      Automattic behauptet ja immer, dass sie die Datenschutz-Vorgaben einhalten, aber es wird ja eher im Nachhinein gemacht und nicht mitgedacht. Und es gibt genügend Feature, bei denen wir dringend aufpassen sollten.

      Ob ClassicPress der richtige Weg ist oder andere Systeme muss dann jeder für sich entscheiden. Auf jeden Fall stehen wir gerade an einer Weggabelung …

  2. Hey Torsten,

    ich kann deinen Unmut verstehen. Ich bin fast seit Anfang an WP-User gewesen und habe demnach fast die gesamte Entwicklung mitgemacht. Irgendwann kam für mich persönlich der Punkt, an dem WordPress kein Blogsystem mehr war. Individualisierungen waren, selbst für mich als Entwickler, zu fummelig. Es gab/gibt andere CMS, die mir die gleichen oder mehr Features bieten und die ich schneller auf meine Bedürfnisse anpassen kann. Seit ein paar Jahren nutze ich deshalb ein anderes System. Für Kunde habe ich noch weiter WordPress-Seiten gebaut und dort auch eigene Gutenberg-Blöcke gebaut. Das fiel mir nicht so schwer, weil ich mit React arbeite, den Cut fand ich aber schon mutig.

    In den letzten zwei Jahren ist aber etwas passiert. Gerade jüngst wieder. Immer mehr Firmen und Agenturen kommen auf uns zu und sagen ganz deutlich: Wir wollen auf gar keinen Fall WordPress haben. Früher war das genau umgekehrt, da hieß neue Webseite == WordPress.

    Ich glaube, das Kind ist nämlich schon viel früher in den Brunnen gefallen und WordPress hat deshalb viel Vertrauen verloren. Themes wurden nicht weiterentwickelt, Plugins waren schlecht programmiert oder wurden nicht mehr gepflegt, das Dashboard wurde zur Werbefläche. Ich weiß, dass das nicht in erster Linie an WordPress liegt, aber gerade Menschen die technisch nicht so versiert sind (wie vermutlich sehr viele WP-User) verstehen diesen Unterschied nicht. Deren Seiten sind langsam, verteilen munter Spam oder begrüßen sie nach dem Login mit massenhaft Werbebannern, unter denen sich irgendwo das eigentliche Dashboard versteckt.

    Ich wage mal die These, dass WP u.a. heute deshalb fast 40% Marktanteil hat, weil gerade die, die sich technisch nicht auskennen oder interessieren, WP benutzen. Der klassische Freelance-Designer, der ein Baukasten-Theme installiert und für seine Kunden mehr oder weniger schnell etwas zusammenzimmert, weiß im Zweifel gar nicht, wie der Kram im Hintergrund funktioniert.

    Es zeichnet sich ab, dass Entwickler langsam andere Wege gehen. Der JamStack wird immer populärer. Flat-File-CMS. Systeme, die besser individualisierbar sind. Ich denke im „professionelleren“ Bereich wird man sich langfristig anderen Systemen als WordPress zuwenden.

    Was dann von WordPress bleibt? Der Weg, der eingeschlagen wurde, deutet imho schon darauf hin und es passt auch zu deiner These der Big-Player, die profitieren: WordPress wird immer mehr zu Squarespace, Wix und Co. Ein System, was man sich im besten Fall selber installiert, und sich dann irgendwie was zusammenklickt. Hier ein Plugin installieren, da ein Theme und den Rest schiebt man sich irgendwie mit Gutenberg zusammen. Da steckt sicherlich viel Geld hinter. Für Entwickler dürfte WP damit aber immer uninteressanter werden. Und vielleicht ist das auch gar nicht sooo schlecht. So können neue, spannende Technologien entstehen. Natürlich schmerzt das, wenn man sich jahrelang in der Communit eingebracht hat, aber vielleicht ist es dann einfach Zeit für etwas Neues. Mir hat dieser Schritt damals sehr gut getan und ich hatte wieder mehr Spaß daran mit dem neuen System, neue Dinge zu entwickeln.

    • Ja, vielleicht ist es mal Zeit sich ein zweites Standbein aufzubauen. Als Alternative zu WordPress. Auch um mal die eigene Komfortzone zu verlassen und wieder was spannendes zu Lernen. Ich habe nur leider nicht mehr so viel Zeit dazu …

  3. Moin, Torsten,

    Ja, mit den klassischen Themes sieht es derzeit schlecht aus, das Theme-Verzeichnis gibt momentan nichts her.
    Aber da baut sich auch gerade was um.
    Ich habe kein Interesse an den ganzen Multipurpose-Themes, das finde ich keinen guten Weg.
    Aber ich komme gut klar mit Gutenberg und bin sehr gespannt auf die weitere Entwicklung. Wie‘s am Ende ausgeht muss man sehen.

    Was wären denn interessante Alternativen für Kundenprojekte? Hast du, haben die Leser hier Ideen und Vorschläge, für schlanke Systeme, mit denen Kunden gut arbeiten können? Die mehr als einen Entwickler haben und die schon etwas länger als 6 Monate am Leben sind?

    • Auf Twitter wurde Kirby und Zulu genannt. Die Klassiker Joomla, Drupal & Co gibt es ja auch noch. Oder Flat File Systeme wie Grav oder Static Site Generator wie Eleventy. Ob das aber alles wirklich kundentauglich ist, habe ich noch nicht angeschaut.

      Ich glaube auch, dass die Entwicklung spannend ist, aber der Weg ist echt hart und aktuell warten alle und schauen sich die Entwicklung an. Insbesondere eben wegen dem FSE. Niemand will auf das falsche Pferd setzen und das bedeutet, dass gerade vieles „on hold“ ist. Wenn aber dann „breaking changes“ kommen, wie die jQuery-Umstellung – dann geht ständig was kaputt. Ich repariere gerade auf zig Websites alte Plugins/Themes notdürftig, weil es die Hersteller nicht (mehr) machen. Und das nervt …

      • Kirby ist toll. Ich hab es schon bei 2–3 Projekten eingesetzt und finde es großartig. Vor allem die individuelle Anpassung des Backends (Kirby nennt das Blueprints) ist eine gute Idee. So kann ich dem Kunden die Felder geben, die er füllen soll und muss und nicht mehr. Aber eigentlich war Kirby ja nicht das Thema…

        Als Gutenberg aufkam, hab ich mir noch gedacht, dass das sicher bald wieder eingestampft wird, weil alle Welt weiter mit dem Classic Editor arbeiten will. Dann hatte ich mich damit abgefunden, und gehofft, dass diese unsäglichen Pagebuilder mal verschwinden, weil mit Gutenberg eine smarte Variante aufkommt. Und nicht ein Pagebuilder im Pagebuilder. Also hab ich angefangen, meine Templates von der Arbeit im Gutenberg aus zu planen. Keine Blockplugins, sondern „Vanille Gutenberg“. 🙂 Aber Gutenberg macht es mir echt schwer. Das unvermeidliche Javascript meinetwegen, aber was mich wirklich nervt ist, dass sich Gutenberg so massiv ins Frontend einmischt. Und das ich massiv Aufwand betreiben muss, um diese Einmischungen loszuwerden. Das will ich nicht. WP soll da ein paar DIVs hinmalen und fertig. Um den Rest kümmere ich mich.

        Als ich 2019(?) auf dem WordCamp in Berlin das erste Mal so richtig mitbekommen habe, was WP da plant mit FSE und Co, da hab ich sofort WIX und Co am Horizont gesehen. Und mit Grausen an den Supportaufwand gedacht, wenn der Kunde mal wieder durch Rumspielen seine Seite zerkloppt hat. Für mich teilt sich hier die Zielgruppe: Auf der einen Seite die Bastler, die statt mit WIX oder dem 1&1 HomePage Designer halt mit WP ihre Seite zusammenklöppeln. Und auf der anderen Seite die Agenturen und Freelancer, die für Kunden Seiten bauen. Die erste Fraktion is augenscheinlich die, die von Automattic vorrangig ins Auge gefasst wird. Die zweite Fraktion jedoch hat null Interesse daran, dass der Kunde an jedem Fitzelchen spielen kann. Nicht mal vordergründig aus monetärem Interesse (das auch), sondern einfach deswegen, weil der Kunde viel Geld für ein anständiges Design und Backend ausgibt. Mit FSE wäre dem gestalterischen Wildwuchs doch Tür und Tor geöffnet. Und dann ist WP nicht mehr viel wert. Sondern nur noch ein Bastelsystem für kleine Freelancer, die halt einfach nur eine Seite brauchen. Es wäre schade um WP, denn eigentlich kann das System und vor allem das Ökosystem drumherum inzwischen viel mehr und hat sich von eben diesem Bastelsystem zu einem ernsthaften CMS gemausert.

        Zur Konsequenz: Ich werde mich in zwei Richtungen umschauen: Zum einen werde ich versuchen Kirby wieder einzusetzen. Und ich werde mir ein Framework wie Symfony näher anschauen. Einzig, dass ich dann ein eigenes Backend schreiben muss nervt mich. Etwas, dass ich vermeiden wollte und will, denn dann Supporte ich nicht nur eine Seite, sondern auch noch das CMS an sich…

        Aber wir müssen in Bewegung bleiben. 🙂

        Stephan.

        • Ich habe in den vergangenen Jahren auch sehr viel mit WordPress gearbeitet und dafür in Projekten programmiert. Kürzlich bin ich auf Statamic als CMS für meine Website umgestiegen – und ehrlich gesagt war es ein Genuss, damit zu arbeiten (Hinweis an de Stelle: z. B. der Spiegel arbeitet damit als Backend).

          Warum ich Statamic schätze:
          – aufbauend auf Laravel und damit einem modernen PHP-Framework
          – auf Wunsch (!) Flat File oder DB-basiert
          – komplette Git-Unterstützung inkl. Inhalte
          – ausgezeichnet erweiterbarer Editor. Da baue ich meine „Blocks“ schneller zusammen, als ich in Gutenberg den Knopf finde, um das übergeordnete Spaltenelement zu finden
          – problemlose Erweiterung durch Collections (Pendant zu Custom Post Types) mit sehr vielen Feldtypen → so sehr ich ACF schätze, finde ich es grandios, dass das System von Haus aus die Erweiterbarkeit mitliefert
          – strukturierte, weiterverarbeitbare Daten + Live-Preview während Inhaltsbearbeitung
          – die Dokumentation ist grandios (und unterhaltsam obendrein :))
          – in der „Pro“-Version gibt es auch noch Multisite und Multilingual

          Ich kann jedem empfehlen, mal hier deren Vergleich zu WordPress zu lesen: https://statamic.com/vs/wordpress

          Was Statamic nicht bietet:
          – Themes → man muss selbst entwickeln können und wollen 🙂

    • Ich kann getkirby.com sehr empfehlen. Gibt es seit einigen Jahren, ist ein schnelles System und für die Kund:innen sehr schön individualisierbar und damit gut zu handhaben. Hat auch ne sehr aktive Community und tollen Support.

  4. Und ich sehe dann dabei zu, wie die Hobby-Blogger und Bastler, die WordPress groß gemacht haben, sich etwas anderes suchen.

    WordPress bot über lange Zeit eine Art Zeitkapsel trügerischer Verlässlichkeit, quasi eine von innen nach außen verkehrte Schneekugel: „Außen“ tobte der Sturm des sich stetig wandelnden Webs, während es „innen“ jahrelang beinahe unnatürlich ruhig zuging, zumindest in Bezug auf einige technologische Eckpfeiler wie PHP, Rückwärtskompalität und jQuery.

    Dass diese Zeitkapsel irgendwann dem Druck des äußeren Wandels nicht mehr standhalten und einschneidende Veränderungen nötig werden würden, war immer nur deine Frage der Zeit – die Web-Entwickler:innen-Community hat uns da regelmäßig dran erinnert.

    Ich glaube Noel Tocks Statement zu meiner Frage während seines „We’ve hit peak WordPress“-Talks (bei 36:06) in 2018 fasst den Effekt dieser Entwicklung ganz gut zusammen: die Zeiten ändern sich (oder WordPress wird jetzt aktiver mitgeändert). Spezialisierung scheint unumgänglich, und ich denke, eine gewisse Abwanderung ebenso. Trotzdem bin ich neugierig, wie WordPress Ende 2021 aussehen und welche Möglichkeiten es für die „kleinen“ Shops und Entwickler:innen bieten wird.

    • Neugierig bin auch. Ich befürchte nur, dass Ende 2021 noch nicht so viel Erkenntnisgewinn bringen wird. 2022 oder 2023 vielleicht.

      Ich bin sogar nicht böse darum, wenn sich der Markt etwas bereinigen würde. Das Problem ist nur dieser Spagat zwischen „wir sind betrieben von Volunteers“ / „unsere Stärke ist die Community“ und der Realität. Die Verzeichnisse (Plugins/Themes) sind keine Marktplätze. Explizit so definiert. Kein Premium-Support erlaubt, keine Signaturen und kein Opt-Out aus dem Supportforen-System. Stattdessen haben wir Support-Reps-Rollen, Sticky-Posts, die sagen, wo echter Support zu bekommen ist und Upsell-Notices, die die Grenzen des Erlaubten regelmäßig erkunden und manchmal auch überschreiten. Wir haben firmengetriebene Entwicklung von den Profiteuren und neben ein paar kleinen Reports und PRs keine echte Entscheidungsgewalt als einzelnes Community-Mitglied.

      Das ganze sieht für mich aus wie ein „Wasch mich, aber mach mich nicht nass!“ – wir vergraulen die Hobby-Entwickler, aber wir lassen die Plugins und Themes noch im Verzeichnis, damit wir mit den immensen Zahlen werben können. Gleichzeitig ist die Hälfte veraltet, unbenutzbar mit aktuellen Versionen und das System bietet KEINE FILTER dazu. WTF.

      Wenn es eine ehrliche Ansage gäbe: Wir werfen jetzt alles raus, was nicht die Spezifikation xy einhält und dann die ganzen 10 Jahre alten Sache mit unter 10 aktiven Installationen verschwinden würden, dann wären wir ja schon einen Schritt weiter, aber aktuell wird Open-Source und GPL als Deckmantel benutzt und anstatt auch offiziell die Kontrolle zu proklamieren immer noch das Märchen erzählt, dass sich jeder einbringen kann. Wie begrenzt diese Möglichkeiten sind (oder um welche unliebsamen Aufgaben es da geht) wird nicht erwähnt …

    • Ich sehe das ähnlich wie Caspar. Auf der einen Seite vordere ich seit Jahren, dass der PHP Teil von WordPress modernisiert wir und man sich endlich mit PSR, Composer, Autoloadern, Dependency-Management usw. auseinander setzt und auf der anderen Seite, bin ich frustriert wenn eine ähnliche Entwicklung bei den Themes statt findet.

      Ich mag den Gutenberg-Editor und nutze ihn seit der ersten Stunde. Ich glaube er hat viel potential und ich finde ihn wesentlich intuitiver wie den alten WYSIWYG. Ich stimme Torsten zu, dass es aktuell wenig Spaß macht, als Laie mit den neuen Features und Anforderungen zu experimentieren. Ich kenne mich mit React nicht wirklich aus und es ist schwer Dokumentation und Hilfe zu finden. Aber so funktioniert ein agiler Prozess nun mal. Man veröffentlicht schnell und geht auf das Feedback von Nutzern ein. Auch wenn ich mich selber gerade überfordert sehe, mit der Geschwindigkeit mit zu halten, glaube ich dass der Schritt notwendig ist oder war. Ich glaube aktuell ist wirklich nicht die Zeit um als kleine Agentur auf Full-Page-Editing zu gehene, aber auch das Feature wird irgendwann fertig, stabil und wohl dokumentiert sein. …und dann freue ich mich React lernen zu dürfen 😉

  5. Kirby tauchte an meinem Horizont schon ein pasr mal auf. Ich werd mal wieder reingucken.
    Danke!

  6. „Themes werden sterben“? Stimmt. Aber ist das schlimm?

    Das Theme Twenty Seventeen ist jetzt vier Jahre alt, wirkt aber technisch gesehen wie aus einer anderen Epoche. Rückblende: Als gestalterisches Highlight hatten die Theme-Entwickler in Customizer eine Funktion eingebaut, mit der vier Seiten zu einer Startseite verknüpft werden konnten. Damit widersprach das mit jeder WordPress-Version ausgelieferte Standard-Theme zwar der wahren, reinen Lehre, dass nur Beiträge zu dynamischen Seiten zusammengefasst werden, aber … dieses Layout, Beitrags-Bilder als Parallax-Hintergrund und dann auch noch wahlweise ein- oder zweispaltiger Satz (für die ganze Website) – der schiere Wahnsinn!
    Leider waren die gestalterischen Möglichkeiten damit auch schon erschöpft. Wer mehrspaltigen Satz wollte, musste (Einsteigern und Endanwendern kaum zu vermittelnde) Shortcodes einsetzen. Ein kreativeres Layout für Galerien war nur mit zusätzlichem Plugin möglich. Und so ging es mit den gestalterischen Unzulänglichkeiten weiter, die viele Anwender:innen lieber zu Multi-Purpose-Themes und Page-Buildern greifen ließen. Irgendwie war das aber auch nicht das, was wir uns gewünscht haben. Schlechte Performance, Lock-In-Effekt – nein, das war keine Lösung.

    Inzwischen haben wir im WordPress-Core einen neuen Editor, der Inhalte in Blöcke aufteilt und damit jedem Anwender granulare Einstellungen für einzelne Elemente einer Webseite ermöglicht. Wie in Twenty Seventeen Inhalte zu kombinieren ist (mit erheblich mehr Flexibilität) mit wenigen Mausklicks auch technischen Laien möglich und aus den wenig performanten Multipurpose-Themes von „damals“ sind Themes geworden, die eine offene Leinwand („Canvas“) anbieten und deutlich mehr Gestaltungsspielraum geben. Dabei wird nur soviel CSS und JavaScript geladen, wie zwingend nötig ist und mit zusätzlich kommerziell angebotenen Plugins kann ich modular die Funktionalität so erweitern, wie ich es als Nutzer benötige.
    Kurz: wir haben heute gestalterische Möglichkeiten, von denen wir vor vier Jahren geträumt hätten. Aus Anwendersicht empfinde ich das als großen Fortschritt.

    Ja, stimmt, das bisherige Skillset reicht nicht mehr ausreicht, um ein eigenes Theme zu erstellen. Aber mal ehrlich: Will ich das? Will mein Kunde das? Und will mein Kunde das bezahlen?
    Themes sollen semantisch korrektes HTML haben, barrierefrei und suchmaschinenoptimiert sein, auf zwei Dutzend Endgeräten schick aussehen und eine zukünftige Entwicklung vorwegnehmen, die wir selbst nur erahnen. Kurz: Themes zu entwickeln ist tatsächlich eine recht komplexe Sache geworden, die ich lieber spezialisierten Programmierern überlasse. (Das muss übrigens nicht zwingend ein „Big Player“ oder ein großes Team sein. Das Theme „Go“ wurde auch von einer einzigen Person programmiert.)

    Bisher konnte ich Metaboxen für Custom Fields selber programmieren („weil ich’s kann!“) oder aber das (wenn ich mein Honorar mit den einmaligen Lizenzgebühren vergleiche) per Saldo günstigere ACF nutzen. Mit dem Block-Editor ist es doch nicht anders: Wieso soll ich mit Webpack und REACT hantieren, wenn ich mit meinen Grundkenntnissen in HTML, PHP und CSS und einem Plugin wie Genesis Custom Blocks selber Blöcke erstellen kann? Ich bin überzeugt, wir werden hier noch mehr Plugins bekommen, die uns dabei unterstützen.
    Ich habe irgendwann gelernt, wie man Themes erstellt, weil ich es musste. Aber eigentlich sehe ich meine Expertise eher darin, meinen Kunden und Kundinnen zu zeigen, was gestalterisch möglich ist und wie sich eine Idee in eine ansprechende Webseite umwandeln lassen. Mit den aktuellen Themes habe ich dafür ein vielseitiges Instrument.

    „Themes werden sterben“? Mag sein. Na und?

    • Ja, stimmt alles. Aber das ist nicht mein Punkt. Ich will nicht (und kann es auch nicht) mit React und dergleichen hantieren. Aber die unklare Situation beim FSE und den ständigen Änderungen beim Block-Editor plus die Arbeitsweise des Theme-Teams (mit all den schizophrenen Vorgaben) haben dazu geführt, dass wir aktuell keine guten (oder besser ausreichend unterschiedliche, supportete) Lösungen im Theme-Verzeichnis haben. Da geht aber wegen jQuery-Umstellung (oder comment type Umstellung) zeitgleich gerade ständig etwas kaputt.

      Noch ein Beispiel für die verbuggte Situation, die wir aktuell haben: Kundin ist auf WP 5.3 und ich hatte das Gutenberg-Plugin installiert, weil eine Funktion fehlte, die nur per Plugin nachzurüsten war zu der Zeit der Erstellung. Gutenberg-Plugin aktualisiert und zack „Fatal Error“.

      Anderes Beispiel (Reproduktion auf clean install steht noch aus): Im Absatz-Block stelle ich die Schriftgröße um, aber der Wert wird nicht gespeichert. Springt immer normal zurück. Keine Fehler in der Browser-Konsole. Ich kann mich auf das Grundsystem, den Core aktuell nicht verlassen. Nicht mal bei absoluten Basisfunktionen.

      Noch ein Beispiel: Baue ein Bild ein und klicke auf die Prozentwerte – boom.

      Und dann kommt dieses unfertige Stück Software auch noch und wird Menüs und Widgets ersetzen? Und damit einhergehend werden sich CSS-Klassen ändern und tausende Themes kaputt gehen? Ja, super.

      Ich habe kein Problem damit auf eine Basis aufzubauen. Habe selten, fast nie, Kunden komplett von Grund auf neu geschriebene Themes verkauft. Bin ein großer Freund von Child-Themes und stehe auch Multipurpose-Themes nicht mehr ganz so ablehnend gegenüber.

      Aber was mich erheblich stört ist die Unklarheit in der aktuellen Übergangssituation, die alles blockiert. Ich wünschte, ich könnte 5 Jahre vorspulen …

      • Und dann kommt dieses unfertige Stück Software auch noch und wird Menüs und Widgets ersetzen? Und damit einhergehend werden sich CSS-Klassen ändern und tausende Themes kaputt gehen? Ja, super.

        Deinen Ärger kann ich gut nachvollziehen. Was wäre die Alternative? Drei, vier oder mehr Jahre Entwicklung in einem OpenSource-Projekt, aber ohne Release? Wir sind in Deutschland sicher noch stärker einem Qualitätsbegriff verbunden und wollen unseren Kunden eine solide Arbeit abliefern, während das nach meiner Einschätzung in den USA „flexibler“ gesehen wird, um Prozessen voranzutreiben.

        Veraltete Software mitzuschleppen gilt als rückständig, der Wechsel einer nicht länger unterstützten jQuery-Bibliothek als veantwortungslos – wie man’s macht …

        Dass die Entwicklung unklar ist und schlecht kommuniziert wird, sehe ich auch so.

  7. Automattic, WordPress, Matt Mullenweg oder wer auch immer genau haben es geschafft, WordPress als das „nette“ CMS darzustellen, indem sie den Communitygedanken extrem gefördert haben, was wiederum von begeisterten Communitymitgliedern auf Meetups etc. meiner Meinung nach zu unkritisch weitergebetet wurde.
    Dass Automattic eine millionenschwere, klar kommerziell ausgerichtete Firma ist, ist und war aber doch eigentlich schon immer offensichtlich. Deswegen habe ich auch nie verstanden, warum sich Leute dermaßen selbstlos in der Community engagieren, was Automattic selbst ja eben nicht tut. Sie verdienen damit sehr viel Geld, eben auch mit der „ehrenamtlichen“ Arbeit von tausenden Communitymitgliedern. Es hat fast etwas sektenartiges.

    Für mich sieht es auch so aus, dass Automattic weg will von dem (unter professionellen Entwicklern) schlechten Ruf, technisch veraltet zu sein. Deswegen hat man sich auf ein modernes Framework wie React eingeschossen, was meiner Meinung nach eine schlechte Entscheidung war, da es dem bisherigen Spirit von WordPress klar widerspricht. Vergleicht man die Einfachheit des Erstellens von Custom Blocks von Elementor zu der Kompexität, die Gutenberg mitbringt, dann entspricht Elementor viel besser dem „typischen“ WP Klientel. Ein Elementor light wäre der bessere Gutenberg.

    Wie dem auch sei, wenn WordPress immer komplexer wird, entsteht eben auch Platz für andere CMS, die einfach bleiben. Ich hab noch nicht das perfekte für mich gefunden, aber wer weiß was noch kommt.

  8. Wenn es als Agentur mit „Coding-Skills“ darum geht, sehr individuelle oder komplexere Anforderungen umzusetzen, ist WordPress inzwischen meist aussen vor.

    Nicht nur wegen der mangelnden Fähigkeit, komplexere, cross-referenzierte, mehrsprachige Informationsmodelle umzusetzen, von ‚Author Experience‘ gar nicht zu reden, auch wegen des Themas ‚Themes.

    Aus eigener Erfahrung kamen dann Kirby (einfacher) oder Craft CMS (komplexer) ins Spiel.

    Am Anfang klingt es erstaunlich, wenn es z.B. bei Craft CMS heisst: Themes? Gibt es nicht. Bring your own HTML.

    Und dann macht man die Erfahrung: Es ist einfacher und schneller, fancy Designs ‚from scratch‘ umzusetzen als ein WordPress-Theme zu suchen, zu kaufen, alles wegzuschnitzen was man nicht braucht, alles umzubiegen was man anders braucht, mühsam dazuzubauen, was man zusätzlich braucht, und bei der nächsten Block-Editor-Version umzubauen, was nicht mehr funktioniert.

    Wenn man sich dann ein ‚Starter Blueprint‘ aufgebaut hat mit Strukturierungsregeln und wiederverwendbarem Kram (z.B auf Basis Twig/Tailwind CSS/Alpine JS), geht es noch produktiver.

    Beispiel: Als Übung haben wir das neue Twenty-TwentyOne-Theme mit seinen Blockpatterns nachempfunden. Dauert einen halben Tag.

    Und: Das lässt sich dann für alle drei Systeme verwenden, (Twig bei Craft native, für WordPress und Kirby als Plugin), so dass die Arbeit für Frontend-Menschen weitgehend identisch ist (ja, mit Unterschieden, z.B. für ‚responsive Images‘).

    Fazit: Was weiss denn ich, insbesondere wenn man sich als ‚Non-Coder‘ positionieren muss. Persönlich gehe ich WordPress inzwischen wenn möglich aus dem Weg.

  9. Du übertreibst nicht. Die Entwicklung war klar absehbar. Man wurde als Kritiker ignoriert, lächerlich gemacht, mit einem Selbstmörder der sich vor einen Zug stellt verglichen (von otto in wptavern Kommentaren). Und die wenigen, die ihre Themes adaptieren ider es zumindest versuchen, verbrennen Stunden und Tage und Wochen durch desaströse Codequalität überall in Gutenberg und hunderte nicht gefixte Bugs. Danke für Deine Zusammenfassung, sie wird ignoriert, allenfalls lächerlich gemacht werden, msrk my words.

  10. Pingback: Der langsame Tod von kostenlosen WordPress Themes - Luehrsen.blog

  11. Ich werde von dem Artikel auch abgeholt.

    Hab mir heute vorgenommen für mich eine Aufstellung der Alternativen zu machen.
    Kirby, Eleventy, Grav, Publii und mal sehen, was sonst so kommt.

    Wir wollen mehr auf Static Site Generators setzen – aber da hab ich sorge, dass das für Kund:innen zu wenig zugänglich ist. Ich bevorzuge es mich als Entwickler nur dort in Projekte „einzubauen“ wo es wirklich nötig ist. WordPress war dafür bisher gut. Wenn ich sauber arbeite, kann nötigenfalls jemand anders daran weiter bauen.

    Für mich ist das lustige, dass die Verwendung von React bei Gutenberg mich mega abgestoßen hat. Ich hab nur minimale Erfahrungen mit Gutenberg höre aber immer wieder, dass Vue deutlich zugänglicher ist (damit hab ich schon Erfahrungen) und JSX macht für mich (noch) keinen Sinn.

    … gleichzeitig suche ich gerade eine Alternative, die sowas wie Gutenberg hat. Weil ich die Idee eines Block-Editors eigentlich toll finde. Ich hab vor vielen Jahren mit Sir Trevor rum gespielt – für mich das erste Projekt, von dem ich weiß, dass Block-Editor-mäßiges anbietet.

    Für mich als Entwickler würde ich mir eine Aufwertung des PHP-Parts wünschen und dort solidere, klarere APIs statt ne neue Technologie einzuführen.
    Ich prüf mich da selbst, ob das Lern-Faulheit ist – weiß aber gleichzeitig, dass ich super bereit bin mich in modernes PHP einzuarbeiten (das mit WordPress halt auch nur halbwegs geht).

    Freut mich zu lesen, dass hier viele Leute Kirby positiv hervorgehoben haben. Wer weiß, vielleicht geht es ja in die Richtung weiter für mich.

    … und ja, ich sehe es auch mit Skepsis, dass grob im letzten Jahr alle der großen Hoster fleißige Shoppingtripps machen und teilweise fusionieren. Das ist eine krasse Machtkonzentration und ich vertraue nicht darauf, dass z. B. die Zugänglichkeit von Genesis irgendwann an ein Hosting bei WP Engine geknüpft wird.

    Hat jemand einen Link zu einer guten Übersicht zu WP-Alternativen, die für Entwickler:innen erstrebenswert sind und trotzdem Kund:innen-freundlich?

  12. Wie Caspar schon sagt ist das Abschaffen von Technical Debt eigentlich zu begrüßen. Was zu kritisieren ist ist die Geschwindigkeit und Brutalität, mit der es passiert.

    Ich hab mal mit meiner Brille auf die Folge der Entwicklung geschaut:
    https://www.luehrsen.blog/2021/02/15/der-langsame-tod-von-kostenlosen-wordpress-themes/

    Ich glaube, dass Themes als Konzept des portablen Presentation-Layers für Daten und Funktionen in WordPress bestehen bleiben werden. Was aber verschwinden wird sind die wirklich kostenlosen Themes bei WordPress.org, die ersetzt werden durch „kostenlose“ Theme bei GoDaddy, JetPack und Co.

    Die monopolisierung des Marktes schreitet voran.

    • > die ersetzt werden durch „kostenlose“ Theme bei GoDaddy, JetPack und Co.

      Und die man einem Kunden nur empfehlen kann, wenn Rahmenbedingungen wie DSGVO, ePrivacy-Verordnung usw. aussen vor bleiben.

  13. Hallo Torsten! Meiner Meinung ist das ganze ja auch so eine Strategie, das eigene gehostete Angebot zu stärken, indem man die einst als Open Source verteilte Software strategisch schwächt. Und daran hat Gutenberg einen ganz großen Anteil, denn Calypso, das Framework, auf dem WordPress.com läuft, ist ja ebenfalls React & Co. Das klassische WP-Admin wird nur noch als Notanker an einer Stelle bereitgestellt und auch nur für die Funktionen, die Calypso noch nicht nachgebaut hat.

    Gutenberg selbst ist ja auch ein ständiges „Moving Target“. In meiner speziellen Situation als blinder Blogger habe ich mich ja sogar eine zeitlang in dem Projekt engagiert. Aber das ganze gestaltete sich so schwierig, dass ich die Energie nicht mehr drauf verwende.

    Ich habe WordPress, auch aus den von Dir geschilderten Gründen, inzwischen komplett den Rücken gekehrt und auf einen statischen Site-Generator umgestellt. Klar habe ich jetzt weniger Features, aber das habe ich mir auch so ausgesucht. Ich habe WordPress wirklich sehr lange die Treue gehalten, weit über 10 Jahre, mich immer wieder für Verbesserungen bei dessen Barrierefreiheit eingesetzt, aber irgendwann ist es genug. Gutenberg und die anderen Entscheidungen sind ein Gate-Keeping, das dem Open-Source-Gedanken hier ganz klar zuwider läuft und nur noch die Interessen der Enterprise-Division von Automatik vertritt. Sehr schade!

    Viele Grüße
    Marco

  14. Das eine ist die Technik im Backend und Frontend im Theme. Hier ist eine Modernisierung der Verfahren sicherlich zu begrüßen und wichtig. Eben beispielsweise, dass man einen etablierten Packetbuilder etc. nutzt und modernes JavaScript – wo es denn notwendig ist.
    Das Thema Block-Editor ist aber nicht nur relevant was die Entwicklungstechnik angeht, sondern der Editor verändert auch den Usecase und das Nutzerverhalten der Autoren.

    Wenn eine jQuery-Version, die schon lange veraltet ist, endlich auch mal auf eine neue Version gestellt wird, ist das etwas, was ich als Business von uns Entwicklern sehe. Damit war zu rechnen, damit müssen wir umgehen können.
    Wenn aber plötzlich unsere Kunden, User und Autoren sich vor einen ganz neuen Bedienverhalten sehen, dann ist das was völlig anderes. Jetzt müssen wir plötzlich erstmal den Usern ein neues Eingabesstem erklären, während wir gleichzeitig versuchen müssen, uns durch die mangelhafte sich öfters wechselnde Doku von Jung-React-Codern (überspitzt böse gesagt) zu kämpfen um dem Block-Editor wieder so zu entwaffnen, damit die Corporate Design des Themes erhalten bleibt und Autoren nicht einfach wieder blickenden, hüpfenden Text in COmic Sans (geladen von Google) herbeimalen können.

    Zumal hiermit das Thema der Nutzung von WordPress als CMS durch WordPress selbst ad absurdum gestellt wird. „Wir“ als Entwickler und Manager haben jahrelang gegen den Vorwurf kämpfen müssen, dass WordPress ja nur ein Blogsystem sei. Es war und ist ein vollwertiges WCMS. Aber jetzt kommen die Leuten daher und machen daraus etwas, was sich wieder nur als persönliches Blog nutzen lässt.
    Das tut einen doch irgendwann an der Stirnplatte weh vor lauter Facepalms.

    Wir haben bei unseren Kontext (Uni Erlangen-Nürnberg, die zweitgröße Uni in Bayern) nun über 650 Websites auf WordPress bei der wir trotz der 5er Version den Block-Editor abgeschaltet haben. Gleichwohl haben wir schon viel Zeit darauf investiert, unsere Plugins auch für den Block-Editor vorzubereiten.
    Ich frage mich, ob wir diese Zeit nicht doch abschreiben sollten und doch auf ClassicPress wechseln sollten.

  15. Ich hoffe einfach, dass Automattic auch weiterhin die Möglichkeit bietet, alle zusätzlichen Funktionen, die ich nicht benötige, mit einem Befehl in der functions.php abzuschalten. Ich brauche weder Gutenberg noch Jetpack noch mit Schnickschnack überladene Themes. Mir reicht ein stinknormales HTML-Eingabefeld im Backend. Vielleicht wird es ja doch langsam Zeit, zu einem anderen System zu wechseln, aber WordPress ist eben der Standard, besonders wenn es um ausgefallene Funktionen und individuelle Problemlösungen geht.

    • Dafür solltest Du im WordPress 4.9.x Zweig bleiben bzw. geblieben sein und ein paar für zukünftige PHP-Updates nötige Anpassungen dann selbst in den Core einpfegen, alternativ ClassicPress ansehen und ggf. dort mitmachen.

      Automattic hat WordPress in der klassischen Form bereits satt an die Wand gefahren, derzeit steht nur noch ein Sichtschutz in Form der Plugins Classic Editor bzw. Enable jQuery Migrate Helper davor, der dann in Zukunft eines schönen Tages verschwinden wird.

      Bei den neuen Widgets ist das bereits jetzt so, Classic Editor zaubert die nicht wieder her: https://github.com/WordPress/gutenberg/issues/25552

  16. Pingback: eicker.TV - DSGVO, WordPress Themes, Clubhouse, Parler, Microsoft xCloud > eicker.digital

  17. WordPress ist leider schon deshalb falsch abgebogen, weil Barrierefreiheit nicht mehr mitgedacht wird. Es wird nur von der grafischen Präsentationsebene aus gedacht. Wer barrierefrei arbeiten will, muss zuerst an Bedeutung denken und dann an deren visuelle Präsentation. Das verlangt eine Abstraktion und das interessiert aber halt die Massen nicht. WP hat sich für einen Weg entschieden, ich werde mich nach Alternativen umschauen müssen.

  18. Pingback: Wordpress-Entwicklung: Gutenberg, Blocks, FSE – Lese- und Lernliste › Webwriting-Magazin - vom Publizieren und Kommunizieren im Internet

  19. Der Artikel ist jetzt zwar schon ein paar Tage alt, aber ich bin unter der Woche nicht dazu gekommen, meine Gedanken in Ruhe aufzuschreiben.

    Ich habe in den knapp 9 Jahren, die ich schon mit WordPress arbeite, viel gelernt und viele Custom Plugins und Themes für Kunden mit besonderen Anforderungen entwickelt. In den letzten Jahren hatte ich viel um die Ohren und daher nicht die ausführliche Möglichkeit groß was für Gutenberg zu machen. Auf der anderen Seite habe ich in anderen Projekten viel über JavaScript, React usw. gelernt.

    Jetzt habe ich seit Anfang des Jahres begonnen Kundenprojekte auf Gutenberg umzustellen und mich daher wieder intensiv mit Gutenberg beschäftigt.

    Bei allen Entwickler-Aufgaben war für mich eine der wichtigsten Stützen immer die Dokumentation. Die ist zwar für den PHP-Teil von WordPress auch nicht 100%ig intuitiv, aber man kommt doch recht zügig rein, kann sie durchsuchen und bekommt die nötigen Infos.

    Selbst mit Erfahrung in React und JavaScript, ist die Dokumentation von Gutenberg für mich schlicht unbrauchbar. Wie du schreibst »das Erstellen einer Doku [ist] unmöglich« bei diesem Entwicklungstempo. Unmöglich vielleicht nicht, aber wenn man ihr keine Priorität gibt, fällt sie hinten runter und damit verliert man unterwegs viele der Entwickler – glaube ich. Aktuell muss ich mir viele Infos mühsam aus mehreren Blogbeiträgen zusammen suchen, die nur mit Glück noch aktuell sind.

    Zugegeben, auch bei anderen JS-Projekten fehlt Dokumentation, aber da habe ich in der Regel Type-Definitionen für TypeScript. Die verraten mir dann zumindest was ich wo übergeben kann und wie ich die Sachen am Ende zusammenstecken kann. Es gibt zwar (inzwischen) auch Types für Gutenberg, die sind aber offensichtlich veraltet und werden nur sehr stiefmütterlich gepflegt (selbst der Type für registerBlockType() stimmte nicht). Das war/ist für mich mit der frustrierendste Punkt. Klar, es ist OpenSource und man könnte jetzt sagen „dann beteilige dich doch“, aber wenn ich nicht mal Zeit habe meine eigenen Projekte fertig zu bringen oder schlicht keinen Plan habe, geht das nicht.

    Von daher kann ich deinen Frust sehr gut nachvollziehen. Mir hat die Entwicklung für WordPress immer Spaß gemacht und auch neue Themen wie React stellen für mich grundsätzlich kein Problem dar. Ich hatte Anfangs richtig Bock auf Gutenberg und habe die Möglichkeiten gesehen. Wenn man es mal hat kann man ja auch richtig coolen Kram damit machen. Aber durch die vielen Probleme mit der Doku habe ich aktuell kaum noch Lust auf die Entwicklung und nach jeder Dev-Session richtig schlechte Laune.

    So wird die Umstellung für die kleinen Seiten noch aufwändiger als angenommen. Ein weiterer Grund, warum ich mir auch ClassicPress nochmal genauer angeschaut habe.

    Das Themen wie jQuery mit der Zeit angegangen werden, finde ich auch nicht schlecht – wie ja auch viele schon gesagt haben. Aber auch ich sehe das Tempo als Problem. Schließlich muss man jedes Kundenprojekt anpacken und bei Nebenberuflichen Entwicklern kann das eine Weile dauern.

  20. Auch ich finde die Entwicklung von WordPress bedenklich. Vernünftiger Support für profesionelle Websites wird aufwändiger, gleichzeitig werden unerfahrene Kunden von dem zukünftigen WP-Seitenbaukasten à la WIX, Squarespace & Co. angezogen, und zu einem hohen Anteil enttäuscht werden.

    Ich war vielleicht einer der frühesten WordPress-Nutzer in Deutschland, fahre aber seit 2005 zweigleisig: Für individuell zu gestaltende Websites oder Kunden mit fertigen Designs von Grafikern nutze ich seitdem MODX (modx.com) – OpenSource natürlich. Aktuell ist es MODX Revolution 2.8. Ich hoffe die Updates zu MODX 3.0 laufen reibungslos. Von auf 2 waren Updates per Klick nicht möglich … Trotzdem will ich auf MODX nicht mehr verzichten. Nichts für HTML-Neulinge oder Laien, aber wer HTML, CSS und vielleicht sogar PHP kann (letzteres z.B. für individuelle Programmierungen) hat mit MODX ein wertvolles Werkzeug, ein schlankes, SEO-ideales und hoch designflexibles Werkzeug. Inkl. Blogfunktionen.

  21. Die Frustration von Entwicklern und Websitebertreuern bzgl. der aktuellen Entwicklung von WordPress nimmt überall merklich zu, ein Beispiel von vielen hier:

    https://wordpress.org/support/topic/known-issues-with-wp-5-7/#post-14162112

  22. Pingback: Wie Wordpress nebst den Anwendern sogar die Entwickler vergrault - Chamäleon-Media Techblog

  23. Sehr gut gesagt.

    Mich nerven die ständigen Verschlimmbesserungen gewaltig. Und obwohl ich seit 20 Jahren mit WP arbeite stelle ich um, wo ich nur kann.

    Je nach Bedürfnis auf einfache schlanke Systeme wie Getsimple CMS, BludIT-CMS oder andere, die auch noch schneller als WP laden. Ist eh ein Witz, daß man Erweiterungen braucht, damit WP schnellere Ladezeiten kriegt.

    Eine weitere Verschlimmbesserung bei WP war wieder Gutenberg. Wer braucht sowas?
    Meine Kunden? Will keiner. Die wollen schnell Texte, Bilder publizieren, mehr nicht.
    Sicher wollen sie kein „halbes Studium“ abschließen, um zu lernen wie man WP-Gutenberg bedient. Nichtmal ich will das.

    Wann hat das eigentlich mit diesen ständigen Verkomplizierungen, Verlangsamungen und Verschlimmbesserungen angefangen?

    Wie z. B. damals die Bilder-Hochlade-Funktion vor einigen Jahren. Als plötzlich beim Bildhochladen sich zwangsweise (bis heute) die gesamte Mediathek öffnet!
    In 99% oder sogar 99,99% aller Fälle lädt der Anweder bei einem neuen Beitrag ein neues Bild hoch, nur in den wenigsten Fällen wiederverwendet er ein bereits vorhandenes altes Bild.

    Macht es Sinn, daß sich bei sowas eigentlich Simplem wie dem Hochladen von Bildern erst die ganze Mediathek öffnet und die ganzen alten Bilder geladen werden?

    Natürlich nicht.

    Aber es blieb bei der Verschlimmbesserung und Verkomplizierung.

    Eine Frage ist, wieviele Verschlimmbesserungen und Verkomplizierungen WordPress noch verträgt bzw. die Anwender noch vertragen.

  24. Pingback: Werden kostenlose WordPress - Themes bald vom Markt verschwinden? — Horst Schulte

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.