Content-Management done right: processwire CMS/CMF: Von Hebeln und Knöpfchen

Wer die Wahl hat...

Wer Webentwicklung betreibt und eine einfache Möglichkeit zur Pflege und Verwaltung von Daten in Websites, (Web-) Apps oder ähnlichen Gebilden nutzen möchte, steht früher oder später vor der Qual der CMS-/CMF-Wahl. Wir haben uns nach langer Suche für den nicht mehr ganz so neuen Newcomer Processwire entschieden. Warum? Das lest ihr im ersten Artikel der Serie „Content-Management done right: Processwire CMS/CMF“, in deren Verlauf es neben den Beweggründen und einer ausgiebigen Lobhudelei auch einen Überblick über die ersten Schritte bei der Nutzung des Systems sowie Tipps und Tricks aus dem Praxisalltag geben wird. Aber beginnen wir mit etwas einfachem: einem Rant. Meckern kann ja schließlich jeder.

Wer Typo3 benutzt rettet nebenbei auch keine Delfine

Was die Wahl der Content-Management-Waffen angeht, haben wir bereits eine lange Reise mit vielen Kandidaten hinter uns. Noch vor einigen Jahren entwickelten wir auf unserem eigenen, properitären CMS. Später kamen Wordpress, Typo3 und ModX hinzu. Neben den „Big 2,5“ hatte ezPublish einen ebenso kurzen Gastauftritt wie FirstSpirit, mit dessen Hilfe wir einen kurzen Abstecher in die Java-Welt machten. Zudem haben wir beständig nach Neuerungen Ausschau gehalten und dabei das Gros der verfügbaren PHP-Systeme (Anchor, Pyro, Fork, Kirby, PimCore, SilverStripe, Contao, CMSMadeSimple, Perch, […]) getestet. Leider konnte uns keines der genannten Systeme langfristig überzeugen. Vielleicht sind wir einfach zu "picky". Einige waren hübsch, dafür aber kompliziert. Andere kompliziert, dafür aber gar nicht mal so hübsch. Einige eignen sich nur zum Bloggen und dann gibt es noch ... Ach, ihr wisst schon.

Das Problem: man verbringt zuerst die meiste Zeit damit System X abzugewöhnen, die Inhalte vor dem Redakteur Y an den wahnwitzigsten Stellen zu verstecken (oder – manchmal noch schlimmer - sie ihn an den richtigen Stellen falsch pflegen zu lassen).

Hat man Systemkonfiguration und Redaktionsoberfläche gebändigt, macht man sich daran die Auswüchse eines „gelungenen Frontends“ aus diversen vorgefertigten Themes zu entfernen. Hiernach editiert man den Core einiger miserabel programmierter Plugins um die fest verdrahteten Sprachkonstanten zu entfernen (Hallo Wordpress!) und gewöhnt dem Richtext-Editor ab, an den sinnlosesten Stellen Dinge in formschöne <div class=“csc_textpic“ align=“left“></div> Container zu stecken. Dann beginnt man mit der eigentlichen Arbeit. Oder von vorne. Vorher füllt man aber bitte noch Passierschein A38 aus.

Craftsmanship

Was läuft also falsch? Und wie müsste es besser laufen? Eigentlich kann es doch nicht so schwer sein: in ausnahmslos allen Webanwendungen geht es darum Daten abzufragen, diese anzureichern um sie dem Nutzer dann in mundgerechten Häppchen zu präsentieren. Natürlich gibt es beim Entwickeln wie bei den meisten Dingen im Leben verschiedene Herangehens- und Denkweisen. Einige mögen lieber Tütensuppe, andere bevorzugen ein argentinisches Steak und guten Wein.

Unsere Denkweise war schon immer die der „sauberen Handwerkskunst“ (im englischen gibt es den Begriff des „Craftmanship“, der sich irgendwie schöner anhört aber natürlich das Selbe bedeutet). Soll heißen: Wir mögen es Dinge passgenau auf einen  Anwendungsfall zuzuschneiden. Und das bitte ohne, dass uns Vorgaben dazu zwingen es nur „halbgar“ zu machen. Wenn der DIV-Container stört, muss er weg. Basta.

In Code-Workflow übersetzt heißt das: Wir schreiben zuerst semantisches HTML, dass den Inhalt bestmöglich repräsentiert. Schließlich besteht der Zweck der meisten Webapplikationen darin Inhalte für den Nutzer zur Verfügung zu stellen. Oh, und natürlich auch für Maschinen - hallo SEOs!
Danach werden, sozusagen als „Salz in der Suppe“, Styling und Scripte hinzugefügt.
Nur mal kurz das Slider-Plugin aus dem Wordpress-Repository installieren wird bei uns mit zweifacher Todesstrafe und dem Erwürgen mehrerer kleiner Katzen geahndet. Mindestens.

</rant><processwire>

Und hier bietet sich auch der Ansatz für eine perfekte Überleitung in den relevanten Teil des Artikels. Natürlich beim Thema Inhalt. Nicht Katzen.

Also: genau diesen (zu neudeutsch „Unopinionated“) Ansatz verfolgt Processwire. Und ich kann gar nicht oft genug betonen, wie sehr ich es dafür mag liebe.

Natürlich behaupten diverse Verkaufstexte diverser Systeme und diverse Blogartikel diverse Dinge.
„Flexibel“, „Einfach“ oder gar „Revolutionär“ ist nach einer subjektiven, fiktiven, wenig repräsentativen Keywordauswertung der Marketingtexte sämtlicher Content-Managemenet-Systeme der Welt? Richtig: Jedes!

Zu meiner eigenen Verwunderung stimmten die Behauptungen der Marketingtexte von Processwire aber von Anfang an. Die Art, Struktur und Menge der verwalteten Daten sowie ihres Ausgabeformates sind dem System vollkommen egal. REST-Service für eine WebApp? Na klar! RSS-Feed für's Blog? Natürlich! Datenbank für den Produktkatalog? Kein Problem!

Denn auch im Backend von Processwire findet sich das "Unopinionated"-Paradigma wieder. Es werden keine Annahmen über die Ausgabe getroffen, also kann es folgerichtig auch keine Annahmen über die Eingabe geben. Das klingt zunächst nach einem gewöhnungsbedürftigen Ansatz. Hat man aber das Prinzip verinnerlicht, bietet es größtmögliche Freiheit und einen effizienteren Workflow als die Anpassung von unzutreffenden und unzureichenden Voreinstellungen.

Alles ist ein Objekt eine Seite

Wer schon mal Javascript geschrieben hat und mit JSON in Berührung gekommen ist, weiß die Einfachheit dieser Datenstruktur sicher zu schätzen. Objekte, deren Keys und Values sich einfach lesen sowie beliebig erweitern und verändern lassen. Ein ähnliches Prinzip wird in Processwire mit der Analogie der Seiten verfolgt. Alle Inhalte werden in einem hierachischen Strukturbaum angelegt. Dabei ist der Begriff "Seite" meiner Ansicht nach mißverständlich und verwirrend. Zumindest wenn man als Maßstab das herkömmliche "Feld-Wald-und-Wiesen-Content-Management-System" heranzieht. Eine "Seite" in Processwire ist nämlich eigentlich keine "Seite", sie dient lediglich als Strukturelement. Der Seitentitel ist also der "Key" (der Titel der Seite ist als einzige Vorgabe Pflicht) und muss keine physische Entsprechung in z.B. in der Navigation der eigentlichen Applikation haben.

Am einfachsten lässt sich dieses Prinzip wahrscheinlich anhand von gängigen Taxonomien (z.B. Tags) in einem Blog erklären: möchte ich innerhalb eines Blogartikels in Processwire eine Auswahl von Tags zur Verfügung haben, so erstelle ich im Strukturbaum eine Seite "Tags" als Strukturelement unter der ich wiederum die einzelnen Tags (natürlich ebenfalls als "Seiten") anlege. Im Folgenden lassen sich diese Taxonomien über sehr einfach zu handhabene Relationsfelder in andere Seiten importieren. 

processwire pages - tagging

Ein Hinweis zu den Screenshots: Das hier verwendete Admin-Theme "Ergo" ist nicht Bestandteil der Standard-Installation, kann aber im Modulverzeichnis heruntergeladen werden. Die Weiterentwicklung des (zugegeben: nicht sehr hübschen) Standard Admin-Themes ist derzeit aktiver Diskussionspunkt in diversen Beiträgen im Processwire-Forum, an denen sich neuwaerts bzw. meine Wenigkeit aktiv mit einem Beitrag beteiligen, über den es demnächst mehr in diesem Blog zu lesen gibt.

Jede Seite kann nun mit Hilfe eines "Templates" eine beliebige Anzahl von Eigenschaften (Feldern) zugewiesen werden. Möchte ich also die Struktur des genannten Blogartikels erzeugen, lege ich ein Template - nennen wir es "article" - an und weise diesem Inhaltsfelder unterschiedlicher Typen zu. Jede Seite, die ich mit dem Template "article" versehe, verfügt danach über das Set an Eingabefeldern dieses Templates. Für unser Beispiel bieten sich eine Reihe von Feldern an, die einen Blogartikel auszeichnen: eine Headline, der Inhalt des Artikels, Tags, ein Autor sowie ein Abstract für die Darstellung auf der Übersichtsseite. Das Anlegen der Feldtypen ist - wie auf dem Bild zu sehen - einfach und selbsterklärend:

Processwire Fields & Templates


Für eigentlich alle möglichen (und unmöglichen) Felder gibt es bereits vorgefertigte, sehr durchdachte Feldtypen (z.B. Drag & Drop sowie Thumbnailgenerierung bei Bildupload, Repeater für sich wiederholende Inhaltstypen, Relationen mit Autocomplete), die schlussendlich für den Redakteur Eingabemasken generieren. Selbst von der Community entwickelte Custom-Fieldtypes für eher außergewöhnliche Anwendungsfälle  (z.B.: "MapMarker" - generiert Lat/Long Daten aus Adressen; "Colorpicker" - eine Farbauswahl a la Photoshop, [...]) finden sich im Modules-Directory, dem Processwire-Modulverzeichnis.

API & Hooks

Der intuitive und einfache Eindruck des Backends setzt sich bei der Benutzung der Programmierschnittstelle bzw. im Templating des Systems nahtlos fort. Laut Website verspricht Processwire eine jQuery-inspirierte API. Und tatsächlich: hat man einige Erfahrung im Umgang mit jQuery-Selektoren, schreiben sich selbst komplexeste Datenbankabfragen wie von selbst. Dabei dient der Seitenbaum als imaginärer "DOM-Tree", welchen man unter Zuhilfenahme von Selektoren filtern kann. Da Code mehr sagt als tausend Worte, greife ich hier erneut das Beispiel des Blogs auf und möchte gerne alle Datensätze des Autors "Felix Wahner", vertaggt mit PHP, in deren Titel und Inhalt nicht das Wort Processwire vorkommt, abfragen und diese dann absteigend nach Erstellungsdatum sortieren.
Klingt nach einem fiesen SQL-Query mit Joins und allem Pipapo? Ist es nicht.



	// @see http://processwire.com/api/variables/pages/
	$articles = $pages->find('template=article, title|body!=processwire, author="Felix Wahner", tag.title*=php,sort=-date');
	foreach($articles as $a) {
		echo '<a href="' . $a->url . '">' . $a->title . '</a>';
	}

 

Auch die Entwicklung von Modulen bzw. die Erweiterung des Systemkerns ist einfach und eingängig: fast alle Methoden des Cores bieten verschiedene Hooks um die Ein- oder Ausgabe von Daten zu manipulieren sowie sie um Funktionalitäten zu ergänzen. Bei mehr Interesse verweise ich auf den Artikel von Marco hier im Blog sowie auf die Blogbeiträge des finnischen Entwicklers Teppo Koivula aus der Processwire-Community.

Al dente oder durchdacht

Der wie "Spaghetti-Code" (der ein oder andere würden sagen "PHP halt...") anmutende Codeschnipsel im oberen Listing hat, wie man sich vielleicht denken kann, ebenfalls Methode. Da sich Processwire vornehmlich als CMF versteht, obliegt es dem Implementierenden ob er beim Templating gerne "einfach drauf los" PHP in seine HTML-Templates schreiben oder saubere "Seperation of Concerns" betreiben will. Entscheidet man sich für Letzteres, empfiehlt sich ein Blick auf das von uns entwickelte Modul "Template Data Providers", welches eine Abstraktionsschicht in Form von Controllern beim Templating zur Verfügung stellt. Auch die Wahl der Templatesprache ist freigestellt: Neben dem simplen PHP-Templating finden sich z.B. Twig (ebenfalls von uns) und Smarty Module im Modulverzeichnis. 

Und sonst?

Auch an weiteren Funktionalitäten, die als Entscheidungskriterium in Kundenprojekten öfter genannt werden, bleiben keine Wünsche unerfüllt: Es finden sich gute Unterstützung für Mehrsprachigkeit, Multisite Installationen, ein (kostenpflichtiger aber günstiger) Formularbuilder sowie eine granulare Nutzer- und Rechteverwaltung. Zudem gibt es für fast jeden denkbaren Anwendungsfall bereits ein gutes Modul auf dessen Basis sich Funktionalitäten schnell und effizient entwickeln lassen.

Als wahren Diamanten kann man zudem die Community rund um Processwire bezeichnen. Im Forum herrscht reger Austausch, man hilft sich untereinander selbst bei banal anmutenden Problemen. Es herrscht allgemein ein äußerst freundlicher und konstruktiver Umgangston. Auch bzw. vor allem der Hauptentwickler Ryan Cramer gibt Neulingen und Modulentwicklern in fast jedem Thread Hinweise zur Verbesserung ihres Codes, lobt, fördert und betreibt "Community Management" wie aus dem Bilderbuch.

Upcoming...

Da wir von Processwire vollends überzeugt sind, werden im Anschluss an diesen Artikel in Kürze noch weitere zum Thema folgen. Geplant sind unter anderem eine Tutorialreihe vom Setup bis zur fertigen Website sowie ein ausführlicher Artikel zum bereits erwähnten, in Entwicklung befindlichen Admin-Theme (hier ein kleines Preview):

Vorsicht schamlose Werbung: Am besten folgt ihr uns natürlich auf twitter oder Facebook um gleich informiert zu werden, wenn es weiter geht ;)

Fragen, Kritik, Anregungen?

Immer her damit! Hinterlasst einen Kommentar, meldet euch auf den üblichen Social-Media-Kanälen, schickt einen Brief, schaut vorbei oder gebt Rauchzeichen.