WordPress Theme-Featuritis: Warum Funktionen in Plugins gehören!
WordPress Themes gibt es wie Sand am Meer. Ob kostenlos oder kostenpflichtig. Das Traum-Theme ist nur wenige Klicks entfernt. Aber…halt! Ein noch so tolles und auf den ersten Blick günstiges Theme kann sehr schnell zum Alptraum mutieren. Ein Plädoyer für klarere Trennung zwischen Plugins und Themes und mehr Transparenz beim Theme-Verkauf!
Das Theme-Portal „Themeforest“ gilt nicht umsonst als Mekka für Theme-Fetischisten. Das Portal bietet tausende fertige Vorlagen, so genannte Premium Themes. Für durchschnittlich 75 Euro bekommt man ein fertiges Layout im Responsive-Design. Feine Sache, oder?
Nachteil vieler Premium-Themes: Abhängigkeit!
Die meisten dieser Themes haben einen entscheidenden Nachteil: Sie machen abhängig! Was viele nicht bedenken: Viele Themes machen einen Theme-Wechsel unmöglich. Die Themes protzen vor Funktionalitäten, die gar nicht in Themes sondern in Plugins gehören. Nicht selten findet man Themes mit zig verschiedenen Slidern. Wer im Gottes Namen braucht all diese Slider? Viele Themes versuchen sich auch in Suchmaschinenoptimierung oder sogar in Shop-Funktionalitäten.
Funktion gehört in Plugins. Layout in Themes. Punkt.
Fakt ist: All diese Features gehören definitiv in Plugins. Warum? Weil man sein Theme wie Klamotten nur wechseln kann, wenn man diese Funktionalitäten über theme-unabhängige Plugins steuert. Oder würdet ihr Klamotten anziehen, an denen eure Haut haften bleibt? Noch spitzer formuliert: Würdet ihr ein Haus kaufen, welches zwar günstig ist aber im Falle eines Tapetenwechsels neu gebaut werden müsste? Nicht lachen…die Frage ist ernst gemeint!
WordPress sieht ganz bewusst sowohl Themes als auch Plugins vor. Das Schöne an dieser klaren Trennung ist, dass man seine Slider – insofern man ein Plugin nutzt – behalten kann, auch wenn man sein Theme wechselt. Verschmilzen Theme und Plugins zu einem Einheitsbrei ist nichts mehr zu wollen.
Abhängigkeits-Klassiker Shortcodes
Viele Themes protzen mit einer gewaltigen Menge an Shortcodes (im Beispiel unten z.B. „Tons of Shortcodes“). Diese kleinen Code-Schnippsel in eckigen Klammern sind durchaus praktisch. Setzt man zum Beispiel einen (fiktiven) Shortcode [latestposts] in den Editor, würde dieser Code-Passus automatisch – dank des Theme – durch die letzten Beiträge ersetzt. Praktisch.
Das Problem? Angenommen man wechselt das Theme und nutzt ein Theme, welches diesen Shortcode in dieser einen Schreibweise nicht unterstützt. Was dann? Genau, die eckigen Klammern mitsamt Text werden so ausgegeben wie sie sind. Nix da „letzte Beiträge“.
Könnte man es noch verschmerzen, dass die letzten Beiträge gar nicht ausgegeben werden, setzen viele Premium-Themes auf Shortcodes um überhaupt erst die Websites darstellen zu können. Seine eigene Website so aufzubauen wie in den kosmetisch gepimpten Demo-Versionen ist fast unmöglich und gleicht einem Shortcode-Puzzle aus tausend Einzelteilen. Trennung von Struktur und Inhalt? Fehlanzeige!
Und worauf soll ich achten? Wie finde ich ein passendes Theme?
Weniger ist mehr. Dieser Grundsatz gilt vorallen Dingen bei Themes. In erster Linie sollte man sich nicht von Features blenden lassen. Alle Features wird es auch – in den meisten Fällen bedeutend besser aufbereitet – in Plugin-Form geben. Ein Theme sollte sich auf das Layout konzentrieren und einfach richtig gut aussehen. Nicht mehr, nicht weniger. Alles andere: Plugin suchen! Bei jedem Theme sollte man sich die Frage stellen ob das was man in WordPress eingibt auch noch Sinn ergibt, wenn das Theme deaktiviert wird.
Gute Beispiele für leichtgewichtige und flexible Themes findet man beispielsweise bei den deutschen Webdesignern von Elmastudio. Die Themes sind sauber programmiert, halten sich weitgehend an Standards, können bequem gewechselt werden und das Tolle ist: Sie sind erschwinglich. Kennt ihr noch andere Quellen für hochqualitative Themes, die sich auf das Layout konzentrieren und dem „Feature-Wahn“ trotzen?
Hi Gino, deine Argumentation hat was für sich und mag für viele Blogger zutreffen. Gerade beim Drag-and-Drop Editor war ich skeptisch.
Natürlich machen integrierte Funktionalitäten einen Themewechsel schwieriger; aber die Überarbeitung der statischen Seiten gehört für mich dazu. Schadet nicht, da mal mit dem Eisenbesen durchzukehren…
Im Fall von Enfold stimmt’s außerdem nicht, dass man die Demoseiten nicht hinkriegt. Klar braucht so ein komplexes Template Einarbeitungszeit, aber Enfold ist so gut dokumentiert und logisch aufgebaut, dass man für das bisschen Lernkurve Funktionalitäten kriegt, die ich anderswo so nirgends gefunden hab.
Funktionen wie eine Ajax-Suche im Theme zu integrieren, macht hochgradig Sinn… über die Shortcodes kann man natürlich streiten.
Meiner Meinung nach sind die paar Stunden Mehrarbeit beim Themewechsel absolut zu verschmerzen, wenn man dafür soviel Flexibilität kriegt – und wie oft wechselt man schon das Theme?
Nicht zu vergessen: all das Zeugs auf Themeforest einzeln zu kaufen, kostet gleich mal ein paar 100 Dollar.
Hallo Ritchie. Ja, ich glaube unsere zwei Standpunkte symbolisieren haargenau beide weltweit dargebrachten Argumentationen. Punkto Enfold magst du da in der Tat sogar Recht haben. Wahrscheinlich hab ich mir da ausgerechnet das weisse Schaf aus der schwarzen Herde herausgepickt. Mein Fehler :) Dennoch ist es so, dass die Tendenz klar zu Irreführung und übertriebener „Featuritis“ geht. Gerade Einsteiger wissen die Spreu nicht vom Weizen zu trennen. Wer wie du oder ich da Vorerfahrung hat, hat es einfacher. Ich will jetzt nicht so weit gehen und sagen man bräuchte ein Gütesiegel, aber sowas in der Art wär nicht verkehrt. So könnte auch ein Premium-Theme der Enfold-Sparte ein Gütesiegel erhalten, wenn es sich an gewisse Normen und Qualitätsstandards hält.
So kann jeder frei entscheiden ob er den komfortablen Weg der Abhängigkeit wählt (dann aber wohlbewusst) oder den freien flexiblen Weg.
Ebenfalls problematisch bei Themeforest ist nämlich, dass man sich nur aufgrund der aufgemotzten Demoversion ein Bild von dem Theme machen kann. In den Unterbau kann man allerhöchstens via Screenshots blicken. Man kauft die Katze meist also im Sack. Einmal bezahlt, stellt man fest, dass das ach so tolle Theme mit seinen 100 Slidern und 1000 Shortcodes an sich mehr einer Theaterbühne gleicht, die mühsam von wenigen Standpfeilern aufrecht gehalten bleibt ;)
Aber wie gesagt, meiner Meinung nach müsste WordPress irgendwann mal neben dem eigenen Theme-Verzeichnis ein Gesamtportal hochziehen wo alle Themes (auch Premium/kostenpflichtig) gelistet sind, die klaren Standards entsprechen. So könnte man sich zumindest sicher sein, dass im Code sauber gearbeitet wurde. Dann mach man sich gewissermassen vielleicht immer noch abhängig, aber statt Schund konsumiert man dann zumindest sauberen Stoff ;)))
Tatsächlich ist Enfold eine schlechte Wahl für dein Beispiel, denn der Layout Editor den ich in in dem Theme verwende, und der einen Großteil der Features verantwortet, ist ein selbst geschriebenes Plugin welches ich mittelfristig auch gern als standalone Variante anbieten möchte.
Zugegeben könnte es wohl nen tick easier sein das Plugin zu extrahieren wenn man Theme wechseln will aber das wird auch noch :)
Wie man daran erkennt bin ich also grundsätzlich mit dir einer Meinung, Funktionalität sollte in Plugins wandern. Ist auch generell der Trend auf Themeforest und wird auch dort zur Vorraussetzung für Themes werden.
Als jemand der mittlerweile einen recht guten Überblick darüber gewonnen hat was die User auf Themeforest für ein skillset haben kann ich dir aber sagen dass die Meisten so wenig Ahnung von Webdesign haben dass es für sie nicht möglich ist ohne fremde Hilfe plugin styles zu überschreiben um ein Plugin optisch komplett an ein neues Theme anzupassen. Es scheitert an einfachen CSS Kenntnissen.
Was allerdings jeder kann ist content im editor mit neuen Shortcodes formatieren. Die frage ob features via plugins geadded werden wird mir pro Jahr vielleicht ein oder zweimal gestellt. Ich bin also zu dem Schluss gekommen dass es, obwohl es eine nette best practice ist, für die meisten User doch komplett irrelevant ist ob ein feature im theme framework oder als plugin eingebunden wird. Für mich ist diese Diskussion also theoretischer Natur und hat mit der Wirklichkeit (leider) recht wenig zu tun :)
Hallo Kriesi, danke für deinen Beitrag. Also ich stimme mit dir weitgehend überein. Einzig und allein der letzte Satz…kann ich so nicht unterschreiben. Das Thema hat sehr viel sogar mit der Praxis zu tun. Es ist eben nicht irrelevant für die User, dafür sind eben Standards da. Im klassischen Webdesign kann ich auch Websites bauen, die toll aussehen, wo der Entwickler Begriffe wie „Semantik“ oder „Markup“ nie gehört hat. Der Anspruch eines professionellen Entwicklers/Designers sollte es immer sein Standards zu respektieren.
Dass User das nicht explizit fragen dass dieses oder jenes Feature besser in ein Plugin gehört, hat weniger mit mangelnder Nachfrage als mit fehlendem Kernwissen zu tun. Das macht es dann aber noch nicht auf Anhieb irrelevant in der Praxis. Wenn ich ein Haus baue erwarte ich vom Architekten auch, dass er Standards respektiert, damit mir mein Haus auch in zig Jahren noch Spass macht. Das ist sein Job. Und unser Job ist es Produkte die wir anbieten (und mit denen man dann auch Geld verdient) so aufzubauen, dass sie einfach auch in vielen Jahren noch viel Spass bereiten. Und dass kann man nur wenn man die Dinge klar trennt (ohne dass man das gefragt wird, denn das können die User doch nicht wissen). Wenn die User es wissen, ganz ehrlich, brauchen sie wahrscheinlich deinen Theme-Builder gar nicht…;)
Ich verstehe aber an sich was du da meinst. Ich fänd es toll wenn dein Theme am Ende eine tolle Basis stellt und man sich einen „Theme Builder“ gerne als Extra-Plugin hinzu installieren kann. Denn ich wöllte dein Theme weil es gut aussieht und nicht wegen dieses Theme-Builders. Wer das anders sieht, prima…kann sich das Extra-Plugin installieren. Nur da habe ich die Wahl. Aktuell wird einfach alles in einen Topf geworfen…so nachdem Motto „wat nicht passt, wird passend gemacht“.
Jedenfalls eine sehr interessante Diskussion, zumal die Argumente sachlich ausgetauscht werden. An sich sogar positiv, dass ich Enfold als Beispiel genommen habe, so hat man auch differenzierte Ansichten von Entwicklern/“Anhängern“.
Ich kann mich deiner Meinung voll und ganz anschließen. Beispielsweise bei neueren Themes mit einem integrierten Sitebuilder, der eine individuelle Gestaltung der statischen Seiten ermöglicht, ist ein Themewechsel im Nachhinein gar nicht mehr möglich, ohne sich das gesamte Layout der Seiten zu zerschießen. Da gilt es sich zu entscheiden, zwischen der komfortablen Lösung, aber der Einschränkung das Theme nicht wechseln zu können oder der aufwendigeren Variante alles selbst in die Hand zu nehmen aber flexibel zu bleiben.
Haargenau, Marco. Die Entscheidung muss man dann fällen. Wichtig wäre nur (und da muss sich ein Portal wie Themeforest an die eigene Nase fassen), dass man 100% aufgeklärt wird wie der Unterbau aussieht oder sich die Layouts zusammenstellen lassen. Da kocht jeder sein eigenes Süppchen. Ich kann ja nur objektiv entscheiden welcher Weg für mich der bessere ist, wenn ich alle Fakten auf dem Tisch liegen habe. Klar ist aber, dass man nur eine Frontend-Demo hat und ein paar sauber ausgewählte Screenshots. Das ist zu wenig. Ein Schritt wäre wenn man auch anhand einer WordPress-Demo das Theme im Backend testen könnte. So sieht man schnell ob das Ding hält was es verspricht.
Ich kann hier vielleicht einen Blickwinkel beisteuern, der im Artikel noch nicht vorkommt: der eines Anbieters. Als ein solcher brauchst du nämlich ein gewisses Rückgrat (moralisch, aber auch finanziell), wenn du es mit den Themes „richtig“ machen und auf die „bells and whistles“ verzichten willst.
Theme-Autoren und Plattformen tragen seit Jahren dazu bei, dass Endanwender beim Theme-Kauf ein selbstaufblasendes Schlauchboot erwarten, anstatt einen Bausatz à la [Name eines beliebten schwedischen Möbelhauses] — was eigentlich der passendere Vergleich wäre. Erwartet wird auf relativ breiter Front eine „install.exe“: Theme runter laden, Knopf drücken, alles wie im Demo, inkl. Inhalte.
Mit solchen Erwartungen bist du als Anbieter *sofort* konfrontiert. Anschließend kannst du dir aussuchen: versuchst du, deine Kunden zu „mündigen“ Anwendern zu „erziehen“ (bitte nicht falsch verstehen, das sind wirklich ganz dicke Anführungszeichen!); oder gibst ihnen, was sie ohnehin erwarten, machst deinen Schnitt und lässt die weiter oben im Beitrag richtig geschilderten Probleme ihre Sorge sein?
Glücklicher Weise sehen wir international gerade eine Trendwende bei den Theme-Anbietern. Die Tage der selbstaufblasenden Schlauchboote scheinen gezählt… ;)
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.
Danke, David. Dem hab ich absolut nichts hinzuzufügen!
Ich finde das Thema extrem spannend, vor allem weil es ein weites Spannungsfeld zwischen den einzelnen Positionen gibt. Ich habe mit WordPress und Themes nur am Rande zu tun. Ich sehe das Problem aber auf allen Ebenen der Software Entwicklung. Durch den Einsatz von Kompenenten mache ich mich abhängig.
Mir fallen dabei zwei Themen ein, die ich im Fronend-Bereich vermisse: Standards für Clean Code Development http://de.wikipedia.org/wiki/Clean_Code und Standars für Komponenten http://blog.ralfw.de/search/label/Event-based%20Components. D.h. möglichst sauberen, getesteten Code zu produzieren und dabei Komponenten zu verwenden, die nur lose gekoppelt und damit leicht getauscht werden können.
Man muß dem Kunden klar machen, daß es um 500,- auch etwas dementsprechendes bekommt. Wenn eine Website sowieso nach ein paar Monaten wieder eingestampft wird, ist das ja egal.
Ich hab gute Erfahrungen mit Elegantthemes.com gemacht! Das Jahres-Abo kostet um die 100 Euro.
Das mit den Shortcodes habe ich auch schon gehört, ich vermeide so über trüber Themes jedenfalls. Hab auch eine Firmenwebsite gebastelt mit der ich optisch sehr zufrieden, auch wenn die Suchmaschinen die Seite leider nicht so mögen http://www.elisabethschoenherr.at
freundliche Grüße
Elisabeth
Hallo zusammen,
ich finde deine Argumentation schlüssig, aber hätte als Anfänger was die Entwicklung von WordPress-Themes angeht eine Frage.
Wenn ich ein Theme nur für mich allein entwickel, dann kann ich doch auch z.B. Shortcodes & Co. direkt mit in meinem Theme einbauen oder nicht?
Denn das Theme ist ja nur für mich und ich will es in Zukunft nach meinen Bedürfnissen anpassen, somit kann ich doch auch auf so viele Plugins wie möglich verzichten, wenn ich entsprechende Funktionen von Haus aus einbaue.
Das trägt gleichzeitig doch auch zu einer gewissen Sicherheit bei, denn Plugins sind ja oft genug auch Einfallstore für Hacker.
Gruß
Markus
Klar, wer für sich selbst entwickelt und absolut kein Interesse an diesem „flexiblen Wechseln von Äusserlichkeiten hat“, kann machen was er will. Im Prinzip geht es in diesem Beitrag ja mehr um dieses rigorose Vermischen im Falle von gekauften Themes. Doch auch wer für sich selber entwickelt, sollte sich möglichst an „WordPress Code-Standards“ halten (rein der Zukunftsträchtigkeit wegen). Heisst: Layout = Theme, Funktion = Plugin. Und was das „auf Plugins verzichten“ anbelangt. Damit gewinnt man im Prinzip ja nix. Ob ich die Funktionen nun ins Theme dresche und mir „drei Plugins spare“ oder direkt auf Plugins setze, macht in allen Belangen keinen Unterschied. Außer eben, dass ich es mittels Plugin sauber trenne und mein Theme nicht von eben diesen Funktionen abhängig ist. Zwingend ist das natürlich nicht. Wer selber sein Theme baut, kann ja machen was er will :)
Hi Gino!
Auf der Suche nach einem Theme hab ich diesen Beitrag von dir entdeckt. Bin Anfängerin, was WP angeht und deshalb aufgrund der vielen Themes extrem überfordert! Habe jetzt mit Hemingway gestartet, zum Testen, weil kostenlos. Aber den Aspekt, wo Theme und Pugin vermischt wird, kann ich doch gar nicht beurteilen!? Habe das Theme Sabana entdeckt und es gefällt mir – kannst du mir weiterhelfen, ob das auch ein Mischmasch ist und woran ich das erkenne?
Liebe Grüße
Franziska
[…] Themeforest und anderen WordPress Theme Marktplätzen herrscht die sogenannte WordPress Featuritis. Diese Krankheit bezeichnet das Vollstopfen des WordPress Themes mit Funktionen. Das Resultat sind […]