Danke für den Artikel, den ich auch so unterschreiben kann!
Als Plugin-Entwickler, auch und gerade für das Genesis (Theme) Framework, kann ich nur sagen: Ja, Funktionen gehören in ein Plugin! Insbesondere dann, wenn diese Theme-Wechsel-relevant sind! Aber auch so, würde ich selbst Theme-spezifische Funktionen in Plugins packen, einfach, weil es die Daten-Portabilität und den Komfort (für Anwender & Entwickler), sowie die langfristige Pflegbarkeit erhöht bzw. verbessert.
Plugins können einfach aktiviert bzw. deaktiviert werden. Schon ein wichtiger Punkt, auch wenn es trivial erscheinen mag! Außerdem bietet die Plugin-API einige Checks bevor ein Plugin überhaupt installiert/ aktiviert werden kann – das findet bei Theme-Code alles nicht statt. Außerdem haben korrekt programmierte Plugins auch De-Installationsroutinen um auf Wunsch Daten/ Einstellungen auch wieder zu löschen. Themes bieten das nicht, es sei denn, mit viel Aufwand implementiert, mir ist aber kein Theme bekannt, was soetwas tut…
Widgets sind auch ein gutes Beispiel: Lasse ich da viele Widgetbereiche via Plugin implementieren, habe ich bei Theme-Wechsel nicht ständg die verschobenen, gelöschten oder inaktiven Widgets. Etwas, was viele Benutzer in den Wahnsinn treibt…!
Für all diese hier im Artikel, den Kommetaren und meinen Beispielen aufgeführten Sachen, sind viele (bei weitem nicht alle!) ThemeForest-Autoren nur schwer bis gar nicht zu sensibilisieren!!! Das liegt unter anderem am veränderten Käufer-Verhalten und der Käufstruktur bei ThemeForest: In den Anfangsjahren waren dies mehrheitlich Freelancer, Entwickler, Agenturen, wo man gewisses Grundwissen voraussetzen konnte. Dies hat sich aber mehrheitlich zu Endanwendern bzw. den Webseite-Besitzern verschoben. Diese Käuferschichten haben keine Vorkenntnisse und sind auch nicht bereit, sich diese anzueignen. Es wird eine Knopfdruck-Mentalität erwartet bzw. wirklich eingefordert! Siehe Kommentare von Caspar und Kriesi… :)
Envato als Firma hinter ThemeForest ist an der Entwicklung nicht „unschuldig“, denn der finanzielle Aspekt ist sehr wichtig. Es wird das verkauft, was gewollt/ gefordert wird, also womit der Rubel halt rollt. Punkt. (Und wieso eigentlich auch nicht???) Envato hat 2013 nur eingelenkt mit neuen Richtlinien, weil der Support-Aufwand bei Dritt-Anbietern außerhalb von Envato derartig gestiegen ist (z.B. bei anderen Plugin-Schmieden), sowie auch „Beschwerden“ und einer Art immer größer werdenden Image-Schaden, dass man dachte, man könnte gegensteuern, mit neuen Best Practices, Richtlinien etc. Diese Vorschläge wurden jedoch bereits deartig aufgeweicht, dass viele gute Ansätze wieder verpufft sind. Hier haben sich die profitabelsten Anbieter einfach durchgesetzt, wovon viele einfach nicht bereit waren/ sind, verschärfte Richtlinien zu Standards (ähnlich wie bei WordPress.org), a la ThemeCheck Plugin/ Theme Review Team umzusetzen. Die Offenheit von Autoren wie Kriesi, siehe oben, sind eher die Ausnahme — natürlich dennoch höchst willkommen und unterstützenswert!
Ich habe über einige Monate die Forendiskussionen bei ThemeForest zu den neuen Richtlinien verfolgt und teilweise auch mitgemacht und war erschüttert über die Ablehnung von vielen Autoren zu diesen „Standards“. Ein sehr oft gehörtes Argument dagegen war: man würde ja eine komplette Webseiten-Lösung dem zahlenden Kunden anbieten. Sprich: für 45-60 US-Dollar, ein paar Klicks gibts die fertige Webseite. Ein Schlaraffenland für WordPress-betriebene Webseiten per ThemeForest Theme-Kauf…!?! :-)
Eine ganze Menge dieser Endkunden schlägt dann z.B. bei mir im Plugin-Support auf: den wenigsten überhaupt kann ich helfen! Bzw. ich will denen auch gar nicht helfen, weil es bedeuten würde, unter viel Zeiteinsatz sich durch Coding-Wüsten zu arbeiten, wo einem die Haare zu Berge stehen. Letztlich bleiben solche Anwender dann im Regen stehen, weil zwar die Theme-Anbieter eigenen Support anbieten, aber nicht für Plugin-Inkompatibilitäten von Dritt-Plugins. In aller Regel ist jedoch das miserabl gecodete Theme Schuld, weniger oft das Plugin!
Am Ende kaufen sich die gefrusteten Anwender oft das nächste (gleichartig schlecht gecodete) Theme bei ThemeForest, und erleben den nächsten Technik-Reinfall… Ganz am Ende versucht man es bei Freelancern, Agenturen, Entwicklern und bekommt dann für mitunter sehr viel Geld endlich die langersehnte „komplette Webseite-Lösung“, ganz ohne Theme-CPTs, ohne 10 Slider, ohne 20 eingehänte Javascripte und Stylesheets auf jeder Frontend-/ Adminseite usw. Für viele Endanwender steht jedoch davor ein jahrelanger Leidensweg (im Support), bis man, von „ganz unten“ her, endlich bereit ist, was ganz anderes zu probieren…
Die Wahrheit ist am Ende irgendwo in der Mitte: Es gibt nämlich auch jede Menge sehr gut gecodeter WordPress Themes bei ThemeForest, z.B. von Autoren wie „ThemeBlvd“ und anderen, die auch bereits vor den neuen Richtlinien alle Funktionen in Plugins ausgelagert haben – meist sogar völlig kostenlose, 100%-ig GPL-Lizenzierte Plugins!
Und JA: Design-mäßig gibt ThemeForest in großen Teilen des WordPress-Theme-Marktes den Ton an; aus code-technischer Sicht, ist leider die Mehrheit dieser herrlichen Designs eine mittlere Katastrophe. — Allerdings: Auch *viele andere* Theme-Shops *außerhalb von ThemeForest* bieten nicht immer automatisch guten Code an. Oft sieht man auch da nach einem „außen hui“, ein „innen pfui“…!
Was auch gern vergessen wird: wenn ich hunderte oder gar tausende zu pflegende Theme-Dateien in einem ThemeForest Theme habe, wie soll bitteschön ein einzelner Theme-Herausgeber das immer alles aktuell und sicher halten? Mit den 2-3 letzten WP-Versionen, allen Sicherheitspatches für eigenes verbaute „Plugins“ etc.? Das ist doch gar nicht zu schaffen, selbst wenn man alleiniger Entwickler ist, aber vielleicht 3 Support-Helfer hat. Viele TF-Autoren sind noch immer Einzelkämpfer, haben aber ein riesiges Portfolio an Themes und jedes schleppt seine 600 oder-was-weiß-ich-wieviele-Dateien mit.
Zum Vergleich: Das Genesis Framework von StudioPress/Copyblogger hat inklusive Bildchen und CSS und JavaScript alles in allem etwa 80 Dateien. Dahinter stecken 3 hauptamtliche Entwickler, 3 Designer sowie ca. 20 Community-Entwickler! Die meisten der offiziellen Child Themes haben i.d.R. 2-3 PHP-Dateien, plus 1 Stylesheet und evtl. noch eine superkleine JS-Datei und vielleicht noch ein Bildchen. Nach meiner Erfahrung ist sowas gut pflegbar und anpassbar, auch über Jahre hinweg. Die Genesis-Herausgeber haben seit 2011 zahlreiche Features ausgegliedert in – freie – Plugins oder ganz „ausgebaut“ (ohne Ersatz). Bereits vorher war Genesis keine Featuritis-Bombe. Jetzt erst recht nicht. Und das ist gut so. Es hält bei Herausgebern und Anwendern das ganze auf dem wirklich gebrauchten Minimum, ist aber jederzeit durch gut gepflege Plugins individuell erweiterbar — aber eben nur so viel, wie Projektweise auch benötigt wird.
Ein typisches ThemeForest Theme, hält abertausende Code-Zeilen vor, die niemals nie zum Einsatz kommen, aber als potentielle Sicherheitslücken (mangels Pflege) 24/7 auf den Servern schlummern.
Außerdem: Ein ThemeForest Theme mit rund 3.000 Textpassagen will auch erstmal übersetzt sein. WordPress selbst hat etwa 4.000 Passagen (für ein ganzes CMS!). Das sagt auch sehr viel über Qualität und Quantität aus.
Also nochmal: Funktionen gehören in Plugins! Es ist besser *eine* Aufgabe via *einem* Plugin zu lösen, als mit einem Teil Software alles erledigen zu wollen.
Themes sind fürs Design/ Layout. Plugins für die Funktionen, die den CMS-Motor bereichern und das Design auf Wunsch mit mehr „leben erfüllen“.
Themes sollen wieder Themes sein und werden. Zurück zum Urschleim von WordPress: es gibt eine Theme-API und eine Plugin-API. Wer sich an dieser Grundphilosophie orientiert, fährt auch auf lange Sicht gut.