Child Theme Check aktualisiert – aber wozu eigentlich?

Die Zeiten ändern sich.

Dieser Beitrag scheint älter als 4 Jahre zu sein – eine lange Zeit im Internet. Der Inhalt ist vielleicht veraltet ...

Im Jahr 2015 habe ich auf dem WordCamp Köln einen Vortrag über das Child Theme Dilemma gehalten. Also dem Problem, dass durch das Kopieren von Templates womöglich Sicherheitslücken oder veraltetes Markup konserviert werden und der Nutzer dies nicht mehr parat hat. Der Vortrag und meine Plugin-Lösung (das Child-Theme-Check-Plugin) wurden sehr wohlwollend aufgenommen, aber trotzdem ist die Idee nicht erfolgreich geworden. Warum das nicht passiert ist, möchte ich mir in diesem Artikel mal anschauen.

Fangen wir nochmal beim Feedback an. Es gab diverse Artikel über meine Idee. Im deutschsprachigen Raum zum Beispiel von David Remer im Krautpress-Blog. Die Theme-Schmiede Elmastudio hat ebenfalls einen Artikel dazu gebracht. Und auch das bekannte WPTavern berichtete darüber. Die Kommentare unter den Artikel sind allesamt positiv und auch die Rezensionen zu dem Plugin sind ausschließlich 5-Sterne-Bewertungen.

Ein paar Zitate gefällig?

Thorsten, that sounds like a really useful plugin. Thanks for putting it together and letting everyone know about it! – Nick Schäferhoff (Autor Smashing Magazine)

This is an incredible plugin. Tested it and installed it on a few sites, where I had been facing the same damn problem. -Ahmad Awais

Und trotzdem ist die Idee nicht abgehoben. Warum nicht? Ich habe damals meine Idee im Theme Review Team (TRT) vorgeschlagen. Tammie Lister hat mir sehr rüde klar gemacht, dass das TRT eben Themes reviewt und für andere Dinge weder Zeit noch Lust hat. Externe Plugins, die nicht aus dem TRT-Team selbst kommen, werden nicht empfohlen. Wenn ich die Idee nach vorne bringen wollte, sollte ich einen News-Blog finden und die Idee bekannter machten und einen Pull Request für das Theme-Check-Plugin schreiben. Mir kam das schon damals so vor, dass sie nicht damit rechnete, dass ich das kann und machen würde. Aber ich tat es.

WPTavern berichtete, der Theme-Check-PR war da – nun hätte es doch klappen müssen! Aber auch jetzt kam nichts. Der PR wurde explizit ignoriert (ein gleichzeitig eingereichter Fix für das Theme-Check-Plugin wurde aber gerne angenommen).

Also versuchte ich die nächste Idee. Wenn die Versionsnummern in einem Standardtheme wären, dann würde die Idee doch sicher wie ein Virus in andere Themes übernommen werden, also erstellte ich ein Pull Request für TwentySeventeen.

Und wieder tat sich nichts. 2018 gab es kein Standardtheme und ein Ticket für TwentyNineteen hatte ich zwar erstellt, aber nur geschaut, ob irgendwer mitmacht. Nicht auf Github und auch nicht später auf Trac. Es gab keine Reaktionen außer der Rückfrage vom Lead nach einem PR. Niemand anderes hatte Interesse daran. Folglich wurde es nicht umgesetzt und auch für TwentyTwenty hat sich das nicht geändert.

Und wieder stellte ich mir die Frage, warum klappt das nicht!?

Und ich fragte auf Twitter. Die Twitter-Diskussion mit Sam Wood alias Otto42, die daraus entstand, ist eine Lehrstunde in Narzissmus, Macht und Egomanie. Jemand, der am Hebel sitzt und die Regeln mehr oder weniger frei bestimmen kann, was er wann, wie umsetzt, ohne Kontrollgremium, „erklärt“ mir, dass die Idee für ihn „keinen Sinn ergibt“. Fordert „mehr Diskussion“ oder „mehr Werbung“ für die Idee und jedes mal, wenn ich darlege, wie ich genau das geforderte umgesetzt habe, wechselt er seine Argumentation.

Click here to display content from Twitter.
Erfahre mehr in der Datenschutzerklärung von Twitter.

Eine kurze lange Zusammenfassung:
Seine erstes Argument warum er den Pull Request für das Theme-Check-Plugin nicht gemergt hat, ist, dass die Idee keinen Sinn ergibt. Nun, warum macht WooCommerce dasselbe mit im Theme überschriebenen WooCommerce-Templates auf der Statusseite?

Sein zweiter Kritikpunkt ist, dass er nicht versteht, warum es *erforderlich* sein soll. Das ist schlicht falsch, denn mein PR wäre erst einmal eine Empfehlung und soll die Theme-Entwickler dazu ermutigen die Versionsnummer zu benutzen. Wenn die Durchdringung gut ist, kann vielleicht irgendwann weit später auf „erforderlich“ umgestellt werden.

Der nächste Punkt war dann, dass ich angeblich nichts erklärt hätte. Ja, wenn man nur am Pull Request schaut, dann stimmt das. Das dazugehörige Issue enthält jedoch Links zu englischsprachigen Slides, zum Plugin (inkl. weiterer Artikel) und einen Verweis auf die Technik bei WooCommerce.

Jetzt kommt mein Lieblingsargument: So eine Änderung erfordert Diskussionen und Fürsprecher. Das Theme Review Team (TRT) hat jedoch keinen Einfluss auf das „Theme Check“-Plugin und hat sehr deutlich gemacht, dass sie mir in diesem Punkt nicht weiterhelfen können oder wollen. Auf der anderen Seite denkt Sam Wood dass er ein deutliches Signal vom TRT benötigt, um da aktiv zu werden. Es zeigen also beide Seiten auf den jeweils anderen und ich bin gekniffen.

Als ob nicht schon zig Nachrichten und Informationen ausgetauscht worden sind, stellt er nun fest, dass er es immer noch nicht versteht. Was interessant ist, weil andere das wohl können (nach Lesen der Artikel/der Slides, Ausprobieren des Plugins, etc.) und ja auch WooCommerce darin wohl einen Sinn sieht.

Nun kommt der erste Punkt, dem ich fast zustimmen kann: Mehr Erfordernisse erhöhen die Hürde für Entwickler. Nun ist es aber ja erst einmal nur eine Empfehlung und somit keine echte Hürde. Ein Strohmann-Argument. Auch seine Angst, dass die Entwickler/Entwicklerinnen hier Fehler machen werden oder die Version nicht ändern, trotz Änderungen am Template ist IMHO unbegründet, denn bei WooComerce-Themes klappt es ja auch. Er möchte Erfordernisse eher abbauen. Ja gut, aber auch hier gilt: Es ist nur eine Empfehlung im ersten Schritt. Und wird es vielleicht auch immer bleiben.

Es gab keine Diskussion darüber, niemand hat danach gefragt. Ja, das stimmt, aber warum hat er nicht am Github-Issue nachgefragt, wenn er etwas nicht verstanden hat? Warum hat er die Kritikpunkte dort nicht eingebracht? Er ist doch der Maintainer des Plugin! Na klar macht niemand bei einer Diskussion mit, wenn der einzige mit Schreibrechten offenbar keinen Sinn in der Idee sieht. Diskussionsversuche fanden ja statt. Es konnte unter diversen Artikel, am Plugin, am Issue/PR oder in Slack diskutiert werden. Da kamen nur positive Nachrichten oder eben Schweigen/Absagen.

Der einzige wirklich valide Punkt, den er in meinen Augen vorgebracht hat, war, dass das Theme Check Plugin nicht für „best practices“ gedacht ist, sondern für Dinge, die Probleme machen können. Auf der anderen Seite sind bestimmt die Hälfte der als „Recommended“ im Theme-Check-Plugin befindlichen Punkte eben genau „best practices“. Nun ja …

Jetzt wird es ganz absurd. Als nächstes wirft er mir vor, es nicht genug vorangebracht zu haben. Ich habe ja nur, ein Plugin programmiert, einen Talk gehalten, den Talk in Englisch wiederholt, ein Issue/PR für sein Plugin gebaut, mit dem TRT diskutiert, ob sie mich unterstützen, wurde in diversen Blogs in Deutsch und Englisch gefeaturet und habe die Versionsnummern in das Standardtheme Twenty Seventeen gebracht. Offensichtlich nicht genug. Ich bin aber nur ein Freelancer und kann keine Marketing-Kampagne für eine Idee umsetzen. Wenn mich niemand (international) unterstützt, sei es in der Sache oder finanziell, kann ich so etwas nicht leisten und WordPress verliert mich als Contributor, weil ich gegen die Übermacht an Firmen-Interessen nicht ankomme.

Zum Schluss wird noch absurder: „Did you email me?“ – Dabei gilt üblicherweise in unserer Community, dass wir die Privatsphäre einhalten und die Personen in offiziellen Positionen auch nur über offizielle Kanäle anfragen.


TL;DR: Das Fazit ist nach ihm: Ich hätte die Idee mehr bewerben sollen und wenn mehr Leute dafür gesprochen hätten, dann hätte er es integriert. Dagegen spricht, dass er auch nach der Diskussion keinen Sinn in der Idee sieht, denn sie würde dem Theme-Entwickler noch mehr Pflichten geben und wäre fehleranfällig. Außerdem ist das Theme-Check-Plugin nur für Probleme und nicht für „best practices“. Er macht sehr deutlich, dass er der alleinige Maintainer des Plugin ist und nicht mal dem TRT Rechenschaft schuldet.

Ich habe daher immer noch keine Ahnung, warum die Idee nicht durchgestartet ist. Aber ich habe nach all diesen Streitereien ein paar Thesen:

  • Reine Integratoren/Theme-Nutzer benötigen keine Child-Themes und/oder verstehen die Idee gar nicht.
  • WordPress.com-Entwickler (Automattic) haben zwar auch Child-Themes, aber nicht für den Nutzer wahrnehmbar oder editierter, daher auch kein Bedarf für den Child Theme Check.
  • Theme-Entwickler mit Lite/Pro-Versionen haben kein Interesse daran, dass Freelancer Child-Themes nutzen. Der Endkunde soll natürlich lieber die Pro-Version kaufen.
  • Theme-Entwickler ohne Pro-Version machen das Ganze eher aus idealistischen Gründen und müssen das Geld mit anderen Dingen verdienen, sie haben keine Zeit für solche PRs und die Idee zu unterstützen hilft Ihnen auch kaum bei ihrer eigenen Sache.
  • Theme-Entwickler von Premium-Themes ohne Lite-Version haben am ehesten Interesse an Child-Themes und bieten diese sogar manchmal direkt an. Häufig sind die Themes allerdings ohne die Beschränkung von WordPress.org eher komplexer und schlecht für Child-Themes geeignet. Die Unterstützung in der Sache Child Themes ist daher hier eher durchwachsen.
  • Hardcore-Entwickler nutzen keine Child-Themes, sondern schreiben ihre Themes komplett selbst. Vielleicht auf der Basis von _s oder WP Rig. Aber nicht auf Basis eines anderen Themes via Child Theme.

Folglich bleibt nur eine sehr spitze Zielgruppe übrig. Intermediate-Entwickler wie mich, die Child Themes nutzen. Und mit dieser kleinen Gruppe ist einfach kein Blumentopf zu gewinnen.

Auf meine Ankündigung, dass ich das Plugin schließen werde, wenn es niemand übernimmt …

Click here to display content from Twitter.
Erfahre mehr in der Datenschutzerklärung von Twitter.

… kam genau eine Anfrage.

Und jetzt kommt ihr. Nutzt jemand das Plugin? Wenn ja, wie? Inklusive eines Themes mit Versionsnummern in jedem Template oder nur die Anzeige der Unterschiede?

Soll ich das Plugin schließen, vom Versionscheck befreien und nur die Unterschiede direkt anzeigen oder noch einen Versuch starten, trotz der oben genannten Widerstände, andere davon zu überzeugen?

Ich freue mich über eure Meinungen und Anregungen in den Kommentaren!

17 Antworten auf Child Theme Check aktualisiert – aber wozu eigentlich?

  1. Klassische Themes werden mit den längst hinter verschlossenen Türen beschlossenen Phasen von Gutenberg ohnehin obsolet. Jeder akuelle privat oder premium Theme-Entwickler schaufelt sich mit jeder weiteren Unterstützungsarbeit von Gutenberg sein eigenes Grab. Klingt heftig, ist aber so.

    Community driven CMS, lol, neisklar.

    Empfehlung: Schliesse das Plugin, geniesse stattdessen Zeit mit Freunden und Familie.

  2. Moin!

    An der Situation mit den Gatekepern und fehlenden Interesse im Core lässt sich wohl wenig direkt machen.

    Ich sehe aktuell nur einen Weg über Theme-Hersteller, die mitspielen. Außer Elmastudio haben sich bisher anscheint keine weiteren an der Aktion beteiligt.
    Wenn eine steigende Anzahl an Herstellern die Versionsnummern pflegen hast du gute Multiplikatoren, die mehr Bewusstsein für das Problem schaffen. Diese Hersteller können den Child-Theme-Checker z.B. auch in die Upgrade-Guide ihrer Themes einbauen.

    Mit diesen Guides werden dann die Implementatoren erreicht, die wiederum fordern die Versionierung von weiteren Herstellern ein.

    Einen Versuch wäre es wert. Vllt lassen sich ja alle deutschen Hersteller als Vorbild gewinnen.

    Es grüßt
    derRALF

    • Ich werde diesen Weg nicht alleine starten. Wenn aus der Community Unterstützung kommt und mehr Theme-Entwicklerinnen/Entwickler mitmachen – sehr gerne! Aber aktuell sehe ich da gar kein Interesse. Wäre interessant zu hören, was die so denken und ob sie es überhaupt mitbekommen haben (oder sich aktiv dagegen entschieden haben).

      • Ich denke für die professionellen Themeschmieden wäre die entscheidende Frage: Verringert das Pflegen eines @version-Tag meinen Supportaufwand? Nach dem Motto:
        Nach jedem neuen Release erhalten wir X Anfragen, weil Child-Themes nicht mehr funktionieren. Mit der Pflege eines @version-Tags und dem Verweis auf das Plugin in unseren How-To Docs reduzieren sich 20 Minuten * X auf Boilerplateantwort * X.
        Wenn diese Rechnung aufgemacht werden kann und X groß genug wäre, würde sich ein solcher Weg wahrscheinlich lohnen.

  3. Hi Thorsten,
    ich selbst habe schon seit Ewigkeiten kein Child Theme mehr verwand. Daher nutze ich das Plugin nicht wirklich.

    Ich habe mir jetzt nochmal Deinen Vortrag auf dem Kölner WordCamp angeschaut. Für kleine CSS Geschichten braucht man mittlerweile ja auch gar kein Child Theme mehr. Da kann man ja einfach in den Customizer gehen und die Anpassungen vornehmen. Bleiben also eher tatsächliche Templateänderungen übrig. Da könnte ich mir also vorstellen, dass, seitdem das Child Theme Dilemma das erste Mal vorgestellt wurde, immer weniger Child Themes gebraucht werden, da vieles über den Customizer regelbar ist, wofür man vorher ein Child Theme genommen hätte. Damit dann auch weniger Pain und weniger Bedarf für einen @version-Tag. Und das ist vermutlich ein Trend der anhalten wird. Mein Eindruck ist, dass in den nächsten Jahren Templatedateien mehr und mehr an Gewicht verlieren werden (Gutenberg yolo). Damit dann vermutlich auch Child-Themes. Deshalb glaube ich, dass @version sich nicht mehr als Standard etablieren wird.

    Mich würde aus der Praxis mal interessieren: Ich sehe das theoretische Problem, welches ein @version-Tag löst. Aber wie häufig tritt das in der Praxis auf? Und wie häufig tritt es so auf, dass ein @version-Tag das auch wirklich lösen würde? Wie häufig sind Probleme nach dem Update eher verbunden mit sich verändernden Styles des Eltern-Themes und wie häufig sind es tatsächlich Änderungen in der Templatedatei? Ich selbst habe da leider keine ausreichenden Erfahrungen. In den WP Tavern Kommentaren finde ich zwei Kommentare die explizit sagen: Ja, ich hatte Probleme bei Theme-Updates. Auch auf der Review/Support-Seite des Plugins finde ich da keine konkreteren Erfahrungsberichte. Daher würde mich das tatsächlich mal interessieren: Welche Probleme haben Leute die Child-Themes verwenden nach ihren Updates tatsächlich und könnte @version ihnen helfen?

    Darüber hinaus löst der @version natürlich noch nicht das Problem sondern unterstützt mich nur in meiner lokalen Testumgebung (*hüstl*) nach einem Update schneller Fehler zu spotten. Trotzdem bleibt es mir ja nicht erspart ein wenig über meine Installation zu wandern, um zu sehen, ob das wirklich alles war (Stichwort Styles – wie jetzt 150 Pixel Padding plötzlich?!).

    Aber das sind nur meine Fragen, weil ich – wie gesagt – selber eigentlich keine wirklichen Erfahrungen in diese Richtung gesammelt habe. Für mich wirkt es derzeit so als ob der @version-Tag ein theoretisches Problem löst, das in der Praxis aber nicht zu häufig auftritt. Und das deshalb diese Idee auch nicht richtig abgehoben hat. Oh Gott, ich kann mir grad gut vorstellen, wie alle folgenden Kommentare so „Was?! Bist du bekopppt? Keine Ahnung hast Du“ XD, aber das wäre ja auch gut!

    Wenn sich nun aber zeigt, dass @version tatsächlich ein wichtiges Problem angegangen ist und die Idee trotzdem nicht fliegt; dann ist mein zweiter Gedanke: Kann man das gleiche Problem anders lösen? @version braucht eine gemeinsame Praxis der Themeautoren und Autorinnen. Wenn die den Tag nicht setzen ist das Ding tot. Das Problem aber immer noch da. Am Ende des Vortrags erwähnst Du kurz, dass während Eurer Diskussionen um das Plugin auch Ideen zirkulierten wie etwa „Vergleiche der Templatedateien des Parentthemes über gespeicherte Hashwerte der Dateien“. Das schiene mir ein gangbarer Weg, welcher auf den @version-Tag verzichten könnte und dem Plugin augenblicklich mehr Nutzen verschaffen würde. Neben dem Diffen ist das Plugin derzeit einfach nur ein Showcase wie cool ein @version-Tag wäre. Wenn man stattdessen (oder parallel) mit einem anderen Mechanismus arbeiten würde um Warnhinweise zu generieren täte dies dem Plugin wahrscheinlich gut.

    Liebe Grüße,
    David.

    • Hallo David,

      man konnte ja schon vorher mit Plugins nur das CSS überschreiben. Der Customizer macht das jetzt zwar auch, aber in dem winzigen Bereich macht das nicht viel Spaß (obwohl das CodeMirror ganz nett ist). Aber du hast absolut Recht, dass die Bedeutung eher abgenommen hat. Ein häufiger Grund für Child-Themes ist für mich das Bearbeiten des Footers (WP-Link + ggf. Werbelink raus) und das Hinzufügen eines zweiten Menüs für Impressum/Datenschutz in den Footer. Dadurch das nun viele Themes den Footer frei editierbar machen und solche sekundären Menüs (oder Footer Widgets) anbieten ist das Problem nicht mehr so dringlich.

      Das @version ist ja auch nur ein Gimmick, um schneller zu sehen, welche Dateien sich verändert haben. Es gibt gute Theme-Anbieter, die im Changelog/Release-Artikel angeben, welche Dateien sich in diesem Update verändert haben. Wenn das jeder machen würde, dann bräuchten wir das Plugin wahrscheinlich gar nicht. Aber mit der Versionsnummer sieht jeder schnell, wo was geändert wurde und daher geschaut werden muss. Aber ehrlich gesagt ist der Diff im zweiten Reiter das eigentliche Feature.

      Ein konkreter Fall war z.B., als die header.php im Child-Theme war und dann das Eltern-Theme den Title-Support umgestellt hat, auf die Core-Variante. Dadurch, dass in der functions.php der Support aktiviert wurde, aber die header.php des Child-Themes noch die alte Variante beinhaltete, crashte der Titel gehörig. Die Versionsnummer brauchte es dazu allerdings nicht. Der Diff brachte schnell das Problem zutage.

      Was das Generieren der Warnhinweise angeht, so konnte mir niemand ein System vorstellen mit dem das gleiche möglich ist, ohne womöglich Unmengen an false positives zu generieren (Datei neu gespeichert, aber nicht verändert z.B.).

      Nach deinen Ausführungen würde ich sagen. Wirf den Versionscheck raus und biete nur den Diff an. Mehr wird nicht klappen.

  4. Hallo, Torsten!

    Wir beide wissen, ich arbeite schon lange nicht mehr entwickelnd im Agenturgeschäft, und meine letzten kommerziellen Erfahrungen mit Child Themes stammen aus der Zeit, als ich noch für einen deutschen Plugin- und Theme-Anbieter mit Schwerpunkt Woocommerce Support leistete. Damals sind wir in genau die Probleme gerannt, aus denen heraus dein Plugin wohl entstanden ist, und wenn es damals bereits existiert und Verbreitung gefunden hätte, wäre ich sicher ein vehementer Unterstützer der Idee gewesen.

    Allerdings führten Child Themes schon damals (2013–2015) ein absolutes Nischendasein. Wir versuchten zwar, unsere Kundschaft dazu zu bewegen, das Konzept als Best Practice aufzugreifen – ohne nennenswerten Erfolg.

    Deinen sechs Thesen stimme ich vollständig zu. Ich habe keine Daten zur heutigen Situation, kann mir aber angesichts der allgemeinen Richtung, die WordPress mit dem Block Editor und (in naher Zukunft) Full Site Editing eingeschlagen hat, nicht vorstellen, dass Child Themes noch mal irgendetwas anderes als eine Statistenrolle im Gesamtbild spielen werden.

    Daher würde ich dich, als Freund und langjähriger Weggefährte in Sachen WordPress, absolute dazu ermutigen wollen, das Projekt an den Nagel zu hängen bzw. nur solange und in dem Rahmen weiterzuführen, wie es dich selbst in deiner täglichen Arbeit noch unterstützt.

    Was deine leidigen Erfahrungen mit diversen Core Teams und Personen aus dem „Inner Circle“ von WordPress angeht, hast du meine volle Sympathie. Und: ich bin leider überhaupt nicht überrascht.

    Aus meiner Sicht hat WordPress spätestens seit 2018 (je nach dem, wen du fragst, auch früher) aufgehört, eine Open Source Community in dem Sinne zu sein, in dem wir es vielleicht noch kennengelernt haben – eine leicht anarchische Gemeinschaft, die diskutiert, streitet, kollaborativ Lösungen schafft und Beiträge als solche grundsätzlich erstmal willkommen heisst. Jenseits der lokalen Meetups und WordCamps, an deren langsam versiegenden Tropf seine Rekrutierungsstrategie hängt, ist WordPress vor allem eins: isoliert. Kontrolliert von einer kleinen Gang von Jungs, die entweder viel zu früh viel zu viel Investorengeld in die Hand bekommen haben, oder denen mittlerweile alles, was nicht von ihrem Arbeitgeber (dem mit dem Investoregeld) kommt, komplett scheissegal ist, sieht WordPress – trotz aller Marktdominanz – einer schwindenden Zukunft als Open Source Projekt entgegen.

    Die Gleichgültigkeit gegenüber freiwilligem Engagement, in die du mit deiner Initiative gerasselt bist, halte ich in diesem Zusammenhang schlicht für symptomatisch. Und das Beste, was du meiner Ansicht nach tun kannst, wäre, dich auf den Wert zu besinnen, den du für dich selbst aus deinem Projekt geschöpft haben magst. Ich kenne dich als einen wunderbaren Menschen und ein exzellenten Entwickler! 😄 Die Idee mit dem Child Theme Check war klasse! Wenn sie nicht abgehoben hat, liegt das, was mich betrifft, mehr als offensichtlich an Faktoren außerhalb deiner Reichweite.

  5. Hallo, Torsten

    wie es der Zufall will, habe ich gerade letzte Woche einem uralten Post bei mir im Blog ein Update verpasst.
    https://die-netzialisten.de/wordpress/anleitung-childtheme-anlegen-update/
    Inklusive Link zu deinem Plugin.
    Da hatte ich deinen Post hier noch nicht gelesen.

    Mein Childtheme-Post rankte still und ausdauernd im stabilen Mittelfeld, war aber inhaltlich stark veraltet. Ich hatte mich einfach nicht mehr drum gekümmert. Auch in meinem Empfinden waren Child-Themes nicht mehr wirklich aktuell. Das bisschen CSS kann man im Customizer machen, wer braucht da noch Childthemes?

    Inzwischen hat sich meine Einschätzung ein bisschen gewandelt (daher auch das Update). Ich könnte mir vorstellen, dass Child-Themes in Zeiten von Gutenberg wieder an Bedeutung gewinnen werden.
    Noch ist nicht ganz klar, wohin die Reise geht mit den „Gutenberg-Themes“, aber Childthemes werden sehr wahrscheinlich eine Rolle spielen.
    Gut möglich, sie werden weiterhin ein Nischendasein führen, weil das Konzept für den Durchschnitts-Anwender nicht so richtig verfängt.

    Aber für kleine und mittlere Kunden-Projekte finde ich den Weg über ein Childtheme mit einem soliden Gutenberg-Theme als Basis eine sehr interessante Option. Es gibt noch nicht viele von den gut gemachten Gutenberg-Themes, aber das wird sich hoffentlich auch weiter entwickeln.

    Die Childthemes, an denen wir gerade arbeiten, enthalten im Wesentlichen Styles und Funktionen wie z.B. zusätzliche Block-Styles. Duplizierten Templates kommen selten vor. Die Childthemes Aber manchmal muss man halt doch eine header.php oder einen Template Part kopieren und umbauen.
    Und dann ist es gut, wenn es da ein Plugin gibt, dass ein Auge drauf hat.

    Lang lebe das Childtheme!
    ;o)

    Schöne Grüße

    Kirsten

    • Ja, ich bin auch gespannt wie die (Child-)Themes sich in Zeiten von Gutenberg entwickeln werden. Viel Potential aber nicht zwangsläufig eine Notwendigkeit für Child-Themes. Mal schauen …
      Das mit dem „Auge drauf“-haben ist so eine Sache. Mit Versionierung ja, ohne halt nur manuell über den Diff-View. Und die Versionierung bieten nur sehr wenige Themes an. Und wer darauf achtet ist wahrscheinlich gar nicht die Zielgruppe. Ist schwierig. Bin nach wie vor hin- und hergerissen.

      • Wir werden sehen ;o)

        Thema Auge drauf: Ja, das stimmt schon.
        Versionierung und Diff-View sind keine einsteiger-freundlichen Konzepte.
        Ich werd das in meinem Artikel mal ergänzen.
        Die Methode war in der ursprünglichen Version mal anders, oder?
        Ich erinnere mich dunkel.

        • Nein, das war schon immer so. Ohne Versionsangabe im Theme kann es keine Warnung geben. Weil ich nicht weiß, wann ich die triggern müsste. Die Versionierung würde ja von der Entwicklerin/dem Entwickler kommen. Man kopiert das Template, es der Vergleich zwischen Eltern-Theme (nach Update) und dem Child-Theme bringt dann die Warnung hervor.

          Alle Ideen das anders zu lösen (Prüfsumme/filemtime/etc.) scheitern, weil nicht jedes Speichern Änderungen enthalten muss.

          Der Diff-View ist schon recht Einsteiger-freundlich, wenn die Alternative die Installation eines Diff-Tools ist, mit dem die zwei Dateien einzeln gefüttert werden müssen …

  6. Nutze das (noch) nicht, finde die Idee aber gut und sinnvoll.

  7. Ich fand die Idee damals (2015) schon gut und verstehe ehrlich gesagt nicht, warum das nicht besser angenommen wird. Eine simple Methode mit großem Effekt. Elmastudio ist eine der wenigen Theme-Schmieden, die das nach wie vor durchziehen, oder?

    • Ja, leider. Aber auch nicht rückwirkend für die alten Themes und bei Aino ist es auch nicht mehr dabei. Die Themes, die es haben sind bei der Plugin-Beschreibung aufgeführt. Ich denke diese ganzen Versionierungsidee ist tot und ich werde sie wohl dann entfernen:

      „Wenn Du entdeckst, dass Du ein totes Pferd reitest, steig ab.“

  8. Hallo Torsten,
    ob und wie du mich in deine Zielgruppe einordnest, weiß ich nicht: Ich bin weder Theme-Entwickler noch Programmierer, nur WP-Anwender.
    Allerdings nutze ich seit mehreren Jahren (Anfang nicht mehr bekannt) Child-Themes (verschiedener Parents) und habe mir daher auch dein Plugin angesehen. Obwohl ich das Problem „konservierter Bugs“ auch sah und sehe, gibt mehrere Gründe, warum ich es nicht nutze: 1. Vermeidung JEDES Plugin, das ich nicht UNBEDINGT brauche; 2. die erwähnte notwendige Versionierung des Parent-Theme; 3. wegen eines einfachen diff-Vergleichs benötige ich es nicht. (Durch meine Backup-Strategie habe ich IMMER, d.h. vor und nach jedem Update von Themes und Plugins beide Versionen zur Verfügung. Mittels „diif“ der Ordner bzw. „diffuse“ der betroffenen Files sind kritische Unterschiede sehr schnell gefunden.)
    Zum Nutzen von Child-Themes: Solange nur von css-Anpassungen die Rede ist, reicht der Customizer ja aus und Template-Anapssungen können irgendwann mal durch die Entwicklung von Gutenberg überflüssig werden – was aber, wenn es um Ergänzungen der function.php geht? Soweit ich sehe, bietet Gutenberg auch künftig dafür keine Lösung. Deshalb werden Child-Themes m.E. nicht aussterben. Es gibt aber darüber hinaus auch bei css-Anpassungen einen Grund für Child-Themes: Wenn eigene css-Klassen angelegt und im Blog verwendet werden, ist es einfacher, diese über einen Theme-Wechsel zu „retten“ – wenn die css-Datei gut strukturiert ist und eigene Klassen sauber von den Korrekturen des Theme getrennt sind.
    Was mich im Moment in diesem Zusammenhang allerdings hauptsächlich umtreibt, ist die Frage nach den mit einem Child-Theme zusammenhängenden Ladezeiten. Vielleicht hat irgendjemand Erfahrungen? Was ist günstiger: css im Customizer oder im Child?

    • Klar, wer Plugins reduzieren will und sich einen Diff auch selbst anlegen kann, der braucht das Plugin in dieser Form nicht. Und für reine CSS-Änderungen braucht man auch keine Child-Themes (wobei die Enge der Customizer-Spalte ganz schön nerven kann). Bei komplett getrennter Funktion inkl. eigener CSS-Klassen wäre auch die Frage, ob das nicht eher in ein Plugin gehört. Denn bei einem Theme-Wechsel wird ja auch das Child-Theme obsolet.

      Zu deiner Frage nach der Performance: Dazu gibt es IMO keine klare Antwort. Das CSS im Customizer wird meines Erachtens im Head geladen. Bei sehr vielen Änderungen blähst du also deine Seiten auf und dieser Code wird immer geladen (höchstens durch Caching-Plugins minifiziert). Die CSS-Datei im Child landet nach dem ersten Laden im Browser-Cache, erzeugt aber anfangs einen Request (+Overhead) mehr. Ist eine Abwägung. Je mehr Änderungen, desto eher würde ich ein Child-Theme nutzen.

Schreibe einen Kommentar

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