Enterprise WordPress

Ich greife mal Nils’ Idee eines “Enterprise WordPress” hier auf und spinne ein wenig herum.

In den Kommentaren wurde diskutiert, ob man nicht Symfony2 oder auch generell ein Framework einsetzen solle oder welche Datenbankart es sein soll. Ich schreib meine Vorschläge dazu mit entsprechender Begründung mal runter 😉

Datenbank: MongoDB

Die Anatomie eines Blogposts kommt einem Dokument sehr nahe, daher sehe ich eine dokumentenorientierte Datenbank ganz weit vorn. MongoDB ist deswegen meine Wahl, weil es im Punkt der Abfrage von Daten einfacher zu verstehen ist, als eine CouchDB. Index Queries sind halt greifbarer für einen MySQL Umsteiger als eine Map & Reduce Funktionalität. Wenn nur ich das so sehe, dann kann es auch gern eine CouchDB sein – wäre mir pers. sogar lieber. Es kam auch ein Kommentar, der nach Beidem verlangte. An dieser Stelle muss ich mich jedoch klar dagegen aussprechen. Die Art der Abfragen und der Ansatz der Perfomanceoptimierung sind grundsätzlich anders – ein Wrapper würde also den jeweiligen Besonderheiten kaum gerecht werden.

Backend: ExtJS (jetzt Sencha) und PHP

Pimcore hat es auf exzellente Art vorgemacht und ich finde dieses gute Beispiel immitationswürdig. Gerade die Möglichkeit, über Widgets eigene Masken zu definieren, ist für z. B. Plugin Entwickler wunderbar einfach. Wer jetzt nicht weiss, wo von ich rede, der sollte sich mal Objekte im Pimcore Backend anschauen. Sencha bringt auch einen Support für Mobile Devices mit, daher kann man auch sehr schön Apps für Touch Devices bauen.

Frontend: Pure PHP 5.3 mit jQuery und selektivem jQueryUI

Nein, ich bin kein Framework-Muffel, sehe aber nicht die Notwendigkeit für ein Blogsystem ein ganzes Framework Ramp-up “auszugeben”, wenn einer der Hauptaspekte des Rewrites Performance ist. Sehr wohl bin ich dafür Komponentenframeworks, wie z. B. Teile vom ZF(2), SF2 oder den ZetaComponents zu nutzen, wo es Sinn macht. jQuery ist für mich immer noch das beste Framework im JavaScript bereich. jQueryUI ist allerdings ganz schön Fett geworden und muss daher sehr selektiv eingesetzt werden.

Caching: Varnish inkl. ESI, Redis

Varnish ist aktuell das schnellste Pferd auf dem Platz und gerade per ESI macht die Sache Spaß. Redis ist für mich der “Memcached successor” und gehört in jedes Setup was vorher mit Memcached gearbeitet hat.

“Sontiges”

Ansonsten gibt es ja bei WordPress noch die Probleme, die immer und immer wieder kehren. Bei Lastverteilung fehlt die Möglichkeit ein gemeinsames CDN zu definieren. Meist hängt man dann mit einer NFS-mount Lösung herum. Diese geht bis zu einem gewissen Punkt auch gut, bei zu viel I/O geht es jedoch eher schlecht.

Trennung von Frontend und Backen ist ein weiteres Thema. Es sollte einen “Shared Library” Ordner geben, der auf Beiden vorhanden sein muss, jedoch sollte man ein oder mehrere Frontend betreiben können, ohne dass man auf jedem Frontend ein Backend “geschenkt bekommt”. Ein Backend gehört aus meiner Sicht auf einen IP-Range beschränkten Server.

Workflows – ein Feature, was ich sehr vermisse. Blogs sind Redaktionssysteme geworden. So erschreckend das sein mag und so sehr Systeme wie FirstSpirit an dieser Stelle besser sein könnten, so intensiv werden WordPress & Co. als eben solche gebraucht. Warum also nicht wenigstens einen vier-Augen-Workflow implementieren?

Vielleicht kann man ja sogar auf das Release von PHP5.4 bauen und sich Traits mal genauer anschauen. Ich denke, dass gerade in der Pluginentwicklung Traits von Vorteil sein könnten.

Zu guter Letzt muss ich noch einen Kommentar von mir am original Artikel korrigieren. Ich würde das WP-EE nicht Plugin-kompatibel schreiben. Der mitgeschleppte Müllberg wäre zu enorm ;). Sicherlich bin ich nicht auf alle Themen, die man an WP optimieren könnte, eingegangen. Da liegt es nun am eifrigen Leser den nächsten Blogpost oder Kommentar zu schreiben und die Idee weiter zu spinnen. Lasst mal was hören!