Sidebar
ein-/ausblenden

Core Plugins - Fluch oder Segen

Die WP Hacker Mailing Liste ist immer für eine Diskussion gut und bisher habe ich dort gern mitdiskutiert, trotz meines sehr schlechten Englisch und der Scheu vor Diskussionen, die nicht in der Muttersprache verlaufen. Einige Punkte konnten dort schon aus meiner Sicht und der Sicht der deutschen Anwender erreicht werden - was ich bemerkens- und lobenswert finde.
Aktuell gibt es eine neue Diskussion, die die Entwicklung zu Core Plugins zum Thema hat. Andrew, versierter und interessierter Entwickler, hat das Thema in einem Gastbeitrag der WP Tavern aufgenommen und bringt einige wichtige Punkte zum tragen.

Auch ich möchte meine Sicht der Dinge ein wenig darlegen und rufe zur Diskussion auf. WordPress ist aus meiner Sicht eine Applikation die Spaß macht und das Potential in sich trägt, weiterhin nutzbar und zukunftsträchtig zu sein. Diese kurze und einfache Form meiner Meinung meine ich aus der Sicht eines Anwenders und ebenso eines Entwicklers. Ich will nur kurz und bündig Möglichkeiten zeigen, die ich mir in dem Punkt wünsche und wie ich mir ein WordPress der Zukunft vorstellen könnte, ohne den jetzigen Pfad zu verlassen und die Nutzung parallel zu gewährleisten - quasi ohne einen Start bei Null.

Core Plugins

Core Plugins erlauben es, dass der eigentliche Core von WordPress schlank bleibt und man sich die notwendigen Erweiterungen mit Hilfe der Core Plugins holt. Damit schaltet man nur Funktion zu, die man auch wirklich benötigt bzw. die von anderen Erweiterungen, zum Beispiel Plugins aus der Community, gebraucht werden.

Fahrplan

Bisher ist die Philosophie von WordPress: wachse, erweitere mehr und mehr; wie ich das auch in den Gedanken zu 2009 schon veröffentlicht habe. Dies liegt aus meiner Sicht sicher daran, dass der Großteil der Benutzer immer mehr Funktionen möchte, was auch schon an der Wunschliste von WordPress zu sehen ist.

Pro & Kontra

Das Entwicklerteam um WordPress tut sich schwer mit Entscheidungen, was kommt in den Core und was nicht. Zum Teil werden ewige Diskussionen geführt, bis man es umsetzt. WordPress ist bekannt für ein schnelles Wachstum und Funktionsvielfalt. Aus diesem Aspekt heraus ist es sicher schwer, zu sagen, wir nehmen bestimmte Bereiche heraus und stellen sie als Plugin zur Verfügung. Dies bedeutet aber eine angekoppelte Entwicklung, was mehr Zeit kostet und die scheint WordPress nie zu haben. Ich stimme zu - damit wird die Entwicklung träger, der Aufwand des Testens höher und die Vielfalt hat keinen gemeinsamen Standard. Aber ist es nicht ein Mehrwert, wenn man ein schlankes stabiles System hat, welches man mit den den entsprechenden Plugins um die benötigten Funktionen erweitert?

Aus meinem Umfeld der eigenen Entwicklungen, veröffentlicht oder nicht, rund um und mit WordPress weiß ich, wie viel Aufwand es bedeuten kann, Plugins aktuell zu halten und entsprechend zu testen. Ich kann verstehen, wenn man sich gegen Core Plugins ausspricht. Aus dem Blick der unterschiedlichen Anwendungen und Lösungen, die ich mit WordPress umgesetzt habe, kann ich aber die Entwicklung in die Richtung Core Plugin nur unterstreichen.

Core Plugin oder klassisches Plugin?

In diesem Zusammenhang stellt sich aber dann auch unwiderruflich die Frage, warum Core Plugins, warum nicht die klassischen Modelle der Plugins im wordpress.org Plugin Repository? In diesem Verzeichnis zeigt sich besonders stark, wie aktiv die Community um WordPress ist und die Vielfalt der Plugins ist unüberschaubar, eine Prüfung des Code ist für die einzelnen Plugins nicht zu gewährleisten (was ich im Grunde auch unterstützte, so lange sie GPL sind; aber das ist eine andere Diskussion). Die Möglichkeit der Core Plugins sehe ich da anders, denn sie könnten diese Sicherheit geben und den gleichen Standard wie der Core selbst haben.

Versionsaufwand

Durch die vielen Versionen von WordPress, die auch nicht wenig im Umlauf sind, ist es schwer Plugins an alle Versionen anzupassen. Seit Version 2.7 ist die Bereitstellung von Schnittstellen und Möglichkeiten für Entwickler viel konsistenter und übergreifender geworden. Ich selbst tue mich schwer auf Systeme mit niedrigeren Versionen zu portieren und ich kenne diese Meinung auch von anderen Entwicklern, die viel mehr von Code verstehen als ich - es macht einfach keinen Spaß ist mein Grund. Aber es ist nicht der einzige, es sind auch die Möglichkeiten und die saubere Implementierung, die seit 2.7 übergreifender und durchgängiger umgesetzt wurde.
Ähnlich ist die Diskussion zu PHP5, die ich auch hier nicht anschneiden will - schauen wir, was WordPress 2.8 bringt oder Matt am 14.Februar in Jena dazu sagt. Die WP Hacker Mailing Liste hat auch dazu eine umfangreiche Diskussion.

Nochmal Core Plugin

Mit Hilfe der Core Plugins, um wieder zum Thema zurück zu finden, sehe ich Chancen für stabilen Code mit mehr Aufwand aber ebenso großen Feedback. Plugins können sich darauf beziehen, können diese abfragen und die Performance könnte davon profitieren. Die Vielfalt der Möglichkeiten, die WordPress jetzt schon bietet, wäre noch größer und leichter zu begründen. Jedes Core Plugin ist einzelnen erhältlich oder komfortabel über einen Builder für eine Komplettversion zu bekommen.

Ein Beispiel

Um das ganze ein wenig plakativer zu gestalten, soll ein Beispiel dienen, welches in der Vergangenheit zu viel Ärger und Diskussionen geführt hat, nicht nur bei Entwicklern - die Revision in WordPress seit Version 2.5.
Diese Funktion ist für die Nutzung als CMS und mit unterschiedlichen Autoren in WordPress unumgänglich. Sie stellt aus dieser Sicht einen Mehrwert her - gibt aber gleichzeitig sehr viele Datenmengen in die Datenbank. Dies ist vor allem dann unnötig, wenn man das Blog allein betreibt und auf diese Bereicherung im CMS-Sektor verzichten kann. Aus meiner Sicht stellt gerade die Revision in WP ein typisches Produkt für ein Core Plugin dar. Wer es benötigt, der aktiviert es und fertig. Ich kenne so viele WordPress-Nutzer, die diese Funktion noch nicht mal kennen, sich nur über das Feld im Backend wundern und die großen Datenmengen beim Backup bestaunen. Im Standard gibt es keine Möglichkeit diese Funktion einzuschränken oder zu deaktivieren - dazu ist ein Eingriff in die Konfigurationsdatei notwendig oder das Nutzen eines Plugins. Dank der großen und freien Community wird so was kommuniziert - erreichen kann man damit trotzdem nie alle und Dienstleister bereinigen dann die Daten, wenn der Kunde es wünscht.

Fazit

Daher stimme ich für Core Plugins, parallel entwickelt mit und für den Core, gern in Abhängigkeit der Version des Core. Ebenso bin ich für die eigenständige Form der Core Plugins und die Freiheit für Entwickler in den bekannten Plugins aus dem wp.org Plugin Repository.

Geschafft

Wunderbar, du hast es bis hier gelesen? Schon dafür danke ich und sage Entschuldigung: Nun sind es doch einige Zeichen mehr geworden, gesagt habe ich trotzdem nicht alles und vielleicht bin ich auch komplett auf dem Holzweg, aber es ist eine Meinung und Open Source ist aus meiner Sicht eben mehr als Nehmen und Geben von Source Code, es ist auch die Freiheit mitzumachen, mitzudenken und zu diskutieren - ja geradezu Anregen zum Diskutieren.

Artikel #883, 5. Februar 2009 · Entwicklung, WordPress · 21 Kommentare
Tags: Entwicklung, Plugin, Webdeveloper, WordPress, WP
Kommentar-Feed zum Artikel · Kommentare und Pings sind nicht erlaubt. · Kurzlink

21 Kommentare zu „Core Plugins - Fluch oder Segen“

1
Kommentar von Dennis Morhardt
5. Februar 2009 um 14:36
Ich muss dir zustimmen. Diese Core-Plugins würden WordPress um vieles schlanker machen. Wie im Lego-Baukasten kann man sich dann jeder sein WordPress zusammenstellen. Jedoch müssen die Core-Plugins stark an den Core selber koppelt sein, dass heißt, selbe Versionierung (Core 2.7, Core-Plugins auch 2.7) und es muss feste Teams geben, ähnlich wie beim Core. Tickets und Patches darf jeder einreichen, aber wirklich an den Code darf nur das Team des jeweiligen Core-Plugins. Ich denke das würde ganz gut funktionieren.
2
Kommentar von Thomas Scholz
5. Februar 2009 um 14:39
Ich glaube nicht einmal, daß die Auslagerung einiger Funktionen in Core-Plugins die Entwicklung verlangsamt. Das könnte ja durch mehr Helfer aufgefangen werden. Ich würde beispielsweise durchaus gerne am WP-Code mitarbeiten, aber der immer noch sehr chaotische Code schreckt mich doch sehr ab.
Hätte ich nur ein Plugin vor Augen und eine abgesicherte API, dann fiele es mir leichter, da auch mal anzufassen und den einen oder anderen kleinen Bug zu reparieren. Und ich glaube nicht, daß meine Sicht so exotisch ist.
3
Kommentar von Mo
5. Februar 2009 um 14:45
Ich halte Core Plugins auch für einen sinnvollen Schritt in die richtige Richtung. Für viele meiner Projekte brauche ich nur einen Bruchteil der Funktionen die WP bietet, da wäre doch ein maßgeschneidertes System schon sinnvoll.

jQuery-UI ist da ein gutes Beispiel...ein gibt einen Kern und die optionalen Erweiterungen kann man sich entweder einzlen runterladen oder zusammen mit dem Kern bequem in ein passendes Paket packen lassen.
4
Kommentar von Frank Bültge
5. Februar 2009 um 14:46
@Dennis, @Thomas: Genau so meine ich das; Entwickler würden sicher eher mitarbeiten, wenn es gekapselt wäre und damit überschaubarer.
Die Abhängigkeit und Bedingung zum Core ist pflicht, so dass man eine Referenz hat.
5
Kommentar von Marvin
5. Februar 2009 um 14:47
also ich würde Coreplugins ebenfalls begrüßen, denn gerade das oben genannte Beispiel mit den Revisions zeigt sehr deutlich was für Vorteile daraus resultieren würden. Jeder kann sich eine individuelle WP-Version "bauen", die maximal flexibel ist. Man, das wär echt genial..
6
Kommentar von datenkind
5. Februar 2009 um 14:47
Core-Plugins sind wichtig, denn sie bedienen elementare Funktionen eines Blogs, die man nur bedingt durch externe Regularien handhaben sollte. Das Problem hieran ist aber, dass gerne vergessen wird, Optionen – sei’s nur an/aus – anzubieten. Meinen großen Argwohn über die automatisierte Caption-Einbindung bei Bildern seit 2.5 hab ich dir ja damals erzählt. Man konnte es deaktivieren, mit 2.6 änderte sich aber wieder etwas und da war’s nicht mehr so einfach.
So auch die Versionierung. An sich genial und auch zeitgemäß – aber eben nicht immer von Vorteil, wie du es bereits erläutert hast.

Gute Beispiele: Gravatare! Ich finde es super, dass man sich dafür entschieden hat, dieses Feature in den Core aufzunehmen und ihn mit halbwegs vernünftigen Option ausgestattet hat – wobei einige relevante immer noch fehlen (nicht jeder will im Template hacken um die Größe einzustellen).

Ich kann nur aus der Sicht eines Nutzers sprechen, ich finde es wichtig, als Nutzer immer noch die Möglichkeit zu haben, dass mir ein Core-Plugin nicht aufgezwungen wird. So ein „ist dabei, muss aber nicht laufen“-Ding – vorausgesetzt, sie beeinflussen nicht die Funktion oder Sicherheit des Systems.
7
Kommentar von Gilly
5. Februar 2009 um 14:59
Finde die Idee der Coreplugins auch toll. Nutze WordPress gelegentlich auch als Basis für Websites, da wäre durchaus einiges was man dann nicht braucht: Kommentarfunktion, RSS, XRMPC, etc.
8
Kommentar von Eberhard - Aebby - Huber
5. Februar 2009 um 15:57
Gute Gedanken - aus rein technischer Sicht fände ich Core-Plugins eine gute Sache. Das Beispiel mit den "Revisions" illustriert das sehr schön. Der nachträgliche Aufwand für Spezifikation und Implementierung einer Plugin-Schnittstelle ist jedoch nicht ganz ohne. Das würde auf jeden Fall einen aufwändigen Umbau des Core und eine längere Releasepause erfordern. Danach geht die Weiterentwicklung aber sicher flüssiger weiter, sicher auch deswegen weil mehr Leute einsteigen könnten.
9
Kommentar von Fabian Künzel
5. Februar 2009 um 17:14
Also das Prinzip "Core-Plugins" würd ich ebenfalls sehr begrüssen.

Der Moduläre Aufbau mittels Core-Plugins (oder auch Pakete) würde WordPress für Anwender und Entwickler Flexibler und Nutzerfreundlicher machen.

Das Core-Packet von WordPress würde auf ein minimales Schrumpfen und jeder anwender könnte selbst endscheiden, was er will und braucht.

Die genannten beispiele, z.B. mit dem "Revisionen" oder gar auch die Kommentar-Schnittstelle könnte sich jeder selbst aussuchen.

Somit wäre WordPress jedenfalls Flexibler und würde einen großen Schritt in die Zukunft und Nutzer Freundlichkeit legen. Einen mehraufwand seh ich dadurche igentlich nicht (ausser der ersten Entwicklung dahin).

Ich hab nochmehr dazu zusagen, daher werde ich im laufe der nächsten stunden mal einen eigenen Beitrag dazu in meinen Blog veröffentlichen und einen Ping hier her schicken, damit die Diskussion weiter läuft =)
10
Kommentar von Ralf
5. Februar 2009 um 17:21
Verstehe ich das richtig? Jahrelang wurde jedes Plugin das mehr als 3 Downloads hatte in den Core übernommen und WP so schlichtweg aufgebläht. Jetzt dreht man den Spieß um und will den eigentlichen Core wieder auf das beschränken was er mal war, veröffentlichen und speichern von Beiträgen.
Etliche Jahre habe ich mich gewundert warum Tags so wichtig sind das sie unbedingt in den Core mit rein müssen und eine Backup-Funktion weiterhin von Plugin-Autoren realisiert wurde. Ich will ja nicht meckern, nur ist eben dieses Vorgehen das was mich bisher an WP sehr gestört hatte. Mit jeder neuen Version bekomme ich zig Funktionen die ich nicht benötige, warte aber vergeblich auf eben jene Funktionen auf die man tunlichst nicht verzichten sollte. Ehrlich gesagt wäre es zu schön um wahr zu werden.

Bei den Core-Plugins habe ich allerdings ein paar Bedenken. Akismet kann man quasi jetzt schon als Core-Plugin ansehen. Es wird von den "gleichen" Entwicklern heraus gebracht und ist standardmäßig bei WP mit dabei. Das Akismet aber nicht der Weisheit letzter Schluss ist, haben viele, viele Diskussionen gezeigt. Und ganz unbedenklich ist Akismet ja nun auch wieder nicht.
Aus diesen Erfahrungen heraus würde ich bei Core-Plugins doch ein wenig vorsichtiger sein. Unter Umständen kommt dabei nichts gutes raus und am Ende setzt man dann anstatt auf einem Core-Plugin wieder auf ein Plugin von einem freien Autor.

Fazit: Man nehme sich WP 1.5 (oder älter) zur Brust, aktualisiere den Code, mache ein paar Anpassungen und werde damit glücklich. Denn das wäre dann ja quasi das wo man mit Core-Plugins hin will: Wenig Funktion im Kern, Rest kommt durch Plugins.
11
Kommentar von Fabian Künzel
6. Februar 2009 um 09:56
@Ralf,

ich geb dir nicht ganz unrecht. Der Core wurde über die letzten Versionen wahnsinnig Aufgeblät. Ich hab damals mit WordPress 2.0.1 Angefangen.. das ist jetzt ca. 3 Jahre her... Mittlerweile stehen wir bei 2.7.0... 2.7.1 kommt bald....

Der Core hat erheblich zugenommen... wichtige Funktionen... so wie auch unwichtige Funktionen... hab mich mit der in wp implentierten Tag funktion auch nie wirklich anfreunden können, habs aber mittlerweile Akzeptiert.

Trotzdem halt ich den schritt einer Modulariesierung von WordPress für den richtigen weg. Ich hab gestern aufgrund des Beitrages hier bei Frank, auch einen Artikel dazu in meinen Blog Veröffentlicht. Hier geb ich meinen Standpunkt dazu und gebe sogar ein Beispiel wie das ganze Realisiert werden könnte, denn eine andere Software für Webseiten Betreiber hat den schritt bereits vor einiger Zeit gewagt und fährt damit erfolgreich.
12
Kommentar von Uwe
6. Februar 2009 um 12:04
Ehrlich gesagt sehe ich momentan keinen echten Mehrwert, auch nicht im genannten Revisions-Beispiel.

Im Wesentlichen werden Core-Plugins doch wohl vom WP-Kernteam entwickelt und gemanagt werden. Hier ergibt sich erst mal ein zusätzlicher administrativer Aufwand, den man nicht unterschäzen sollte. Releasetechnisch wird ja wohl dann immer ein Satz Core-Plugins an eine bestimmte WP-Version gebunden sein. Dann kann man es auch gleich komplett releasen. Alles andere dürfte dauerhaft auch nicht wartbar sein. Wenn externe Plugins noch auf verschiedene Core-Plugin-Versionen referenzieren können, dann kommen wir langsam dahin was man in der Windows-Welt gern als DLL-Hölle bezeichnet.

Und warum kann man nicht einfach bestimmte Funktionen via Flag abschaltbar machen? Im Endeffekt sollte es dem WP-Core doch ziemlich egal sein ob er eine Funktion nicht ausführt oder das zugehörige Plugin nicht lädt. Prüfen muss er in beiden Fällen ob etwas ausgeführt werden muss. Echten Mehrwehrt sehe ich hier momentan einfach nicht.

Vielleicht hat ja wer sinnvolle Beispiele, die wirklich einen Mehrwert bringen. Vor allem für die Anwender.

LG Uwe
13
Kommentar von Gerd
6. Februar 2009 um 12:43
Modularisierung ist der einzige Weg, der seit den letzten Versionen zu beobachtenden Verfettung des WP-Cores entgegenzuwirken. Wenn man das geschickt anstellt, könnte man es auch so hinbekommen, dass man sich sein Wunschpaket vor dem Download zusammenklicken kann und dann wie bisher einen Ein-Paket-Download bekommt. Wer mit der separaten Installation von Plugins nichts am Hut hat, wäre damit gut bedient.
14
Kommentar von Ralf
6. Februar 2009 um 16:50
@Fabian: WP 1.2 hatte so um die 320KB (gezippt), WP 2.7 liegt bereits bei ca. 2MB (de-Version, gezippt!!). Es wäre wirklich interessant zu sehen wie groß WP wäre, hätte es die gleichen Funktionen wie WP1.2 allerdings mit überarbeiteten (quasi 2.7-kompatiblen) Code. Es dürfte weit unter 1MB sein, schätze ich mal.
Die Verfettung von WP liegt allerdings nicht alleine an Funktionen die kaum jemand braucht, sondern auch daran das immer mehr Schnittstellen und Frameworks dazu gepackt werden. In WP1.2 bzw. WP1.5 gab es weder JS-Frameworks noch einen WYSIWYG-Editor. Von daher wäre es schon fraglich was denn als Core-Plugin umgesetzt wird und was im eigentlichen Core verbleibt. Soll der WYSIWYG-Editor als Plugin angeboten werden oder doch lieber im Core verbleiben? Gibt ja etliche Blogger, Frank eingeschlossen , die den Code-Editor verwenden. Und was ist mit den ganzen JS-Frameworks? Plugin oder Core?
Und genau an diesen Punkt würde die Umsetzung scheitern. WP ist OpenSource und viele Köche können sich nie auf ein Menü einigen. Bei dem in deinem Beitrag gebrachten Beispiel von BurningBoard handelt es sich um eine Firma. Dort sind die Entscheidungsprozesse ganz andere, da kann wesentlich diktatorischer entschieden werden.

Zudem muss ich Uwe recht geben. Wie soll man eine WP-Version aktuell halten wenn sie in zig Module aufgesplittet ist? Die Update-Frequenz wäre irgendwann tatsächlich bei wöchentlich oder noch kürzer. Und wenn man ein Core-Plugin aktualisiert hat, dann darf man auch gleich drei andere Plugins aktualisieren die von diesem Core-Plugin abhängig sind.

Das WP-Team hat sich irgendwann in dem Projekt verrannt und findet nun keinen Ausweg mehr aus der selbst geschaffenen Misere. Würde man WP komplett neu programmieren, könnte man gleich eine neue Blogsoftware schreiben die alle fehler vermeidet die WP bislang gemacht hat. Denn viele Fehler kann man gar nicht mehr rückgängig machen, auch nicht mit einer Umstellung auf Core-Plugins. Im Fall von WP würde das u.U. die Situation sogar noch verschlimmern.
15
Kommentar von Tom
7. Februar 2009 um 13:28
Worum geht es eigentlich bei der Diskussion?
Aus meiner Sicht sind immer Geschwindigkeit des Systems und Wartbarkeit/Bedienbarkeit die Prämissen.
Eine Auslagerung in Coreplugins ist doch nicht notwendig. Die Diskussion kann man sich sparen, wenn man Uwe folgt:

Und warum kann man nicht einfach bestimmte Funktionen via Flag abschaltbar machen? Im Endeffekt sollte es dem WP-Core doch ziemlich egal sein ob er eine Funktion nicht ausführt oder das zugehörige Plugin nicht lädt. Prüfen muss er in beiden Fällen ob etwas ausgeführt werden muss.

Genau das ist für mich die Lösung. Ich will einfach nur an/abschalten können.
Darüberhinaus ist eine Plugin-Api das beste, was man so einem System antun kann.
Der Kern bleibt bei den Entwicklern und die packen rein, was sie meinen und was fehlt, das strickt sich die Community als Plugin nach...
Alles andere führt nur zu Diskussionen und mehr Aufwand...

Tom
16
Kommentar von fermodes
7. Februar 2009 um 16:39
@Frank: Also ich schließe mich Deiner Meinung an, jedoch stehe ich den Core-Plugins weniger skeptisch gegenüber als Du. Wenn sich der Trend seit Version 2.0 fortsetzt, schwillt WP innerhalb kürzester Zeit unglaubich an - und in diesem Fall wäre die Stabilität auch nur schwer zu gewährleisten. Abhilfe schaffen dann nur regelmäßige (öfter als bisher !) Updates zum ausbügeln von Schwachstellen - und das will sich glaube ich auch kein Blogger antun. Ich glaube mich daran zu erinnern, das das Theme "schlankes WordPress" oder "WP Light" erst kürzlich diskutiert wurde (Texto ?) - da waren die Meinungen zwar auch geteilt, aber wer ein komplettes System wünscht kann bei der Installation doch einfach alle Features aktivieren und fertig - so sind beide Parteien zufrieden gestlellt. Nur die Entwickler müssen bereit sein - für den anfänglichen Mehraufwand.
17
Kommentar von Dieter
7. Februar 2009 um 17:47
WordPress wird mehr und mehr zum Horror. Auf einem Athlon 2100 ist WP bei intensiver Nutzung des admin panel kaum noch ausführbar. Irgendwann beginnt das System zu swappen.

Wenn ich mir bueltge .de ansehe, dann sehe ich Javascript Orgien. JAVASCRIPT! Das kann es nicht sein.

Schaut Euch mal den an http://diveintomark.org. Ich kann es nicht beschwören, aber der arbeitet mit einer aufgebohrten 1.x oder sehr niedrigen 2.x WP Version. Jedenfalls hat der sich irgendwann ausgeklinkt.
18
Kommentar von Sören
8. Februar 2009 um 10:36
Aus Sicht der Wartbarkeit und des Testens wären Core-Plugins mit Sicherheit ein Segen. Der "Aufgeblähtheit" des WP Codes wird eben nicht dadurch entgegen gewirkt, dass ich alle Funktionalitäten in den Core implementiere und dann irgendwo ein Flag zum abschalten anbiete. Nicht umsonst beschweren sich ja viele, dass sie sich im WP Code nicht zurecht finden. Das würde sich ändern wenn klar definierte optionale Funktionalitäten in separate Core-Plugins ausgelagert würden.

Aus Sicht eines Pluginauthors bekomme ich allerdings ein leichtes Schaudern. Viele Plugins entstehen dadurch, dass ein halbwegs begabter Blogger eine Funktionalität vermisst und diese dann als Plugin in sein eigenes Blog einbaut. Das mag in seinem Blog ganz gut funktionieren - aber hat er das auch für alle anderen Konstellationen getestet, in denen die verschiedensten Core-Plugins an- bzw. abgeschaltet sind? Durch die Modularisierung könnte der Eindruck entstehen, dass es sich bei Core-Plugins um exotische Funktionalitäten handelt, die man beim Testen des eigenen Plugins ignorieren kann.
19
Kommentar von Haschek
9. Februar 2009 um 19:10
It's GPL, you can fork it!
20
Kommentar von Von Fueberg
31. Dezember 2009 um 00:11
Da muss ich dir zustimmen. Dieses Plugin, würde WordPress um einiges leichter machen. Ich nutze WordPress auch gelegentlich und manche Dinge sind dort total fehl am Platz.
21
Kommentar von Sebastian Plesch
9. Januar 2010 um 21:39
Ich glaube nicht wirklich das dass Plugin gut wäre, WordPress wird meiner Meinung nach immer unsicherer und ähnelt vom Sicherheitsstandard her schon wie Joomla...
Mehr Erweiterungen bringen auch mehr Schwächen mit sich....