Das kleine, feine CMS ProcessWire: Reduzierung aufs Wesentliche

Der folgende Gastartikel stammt von Michael van Laar.

Wenn man einen Gastartikel für ein Blog schreibt, das sich schwerpunktmäßig mit WordPress beschäftigt – darf man dann WordPress kritisieren? Ich tue es einfach mal, allerdings mit sachlicher Begründung.

Denn schließlich hat Vladimir mich gebeten, ein paar Zeilen über das kleine, feine und in Deutschland noch nicht sehr bekannte CMS ProcessWire zu schreiben. Und wozu bräuchte ich ProcessWire, wenn ich mit WordPress in allen Lebenslagen rundum zufrieden wäre?

WordPress ist toll, aber …

… trotz aller Weiterentwicklungen über die Jahre merkt man meiner Meinung nach dem System noch immer stark an, dass es kein „neutrales“ CMS ist, sondern ursprünglich eine reine Blog-Software war, die Stück für Stück um Funktionen für Nicht-Blog-Projekte erweitert wurde. Diese Historie begegnet einem bei der Arbeit mit WordPress auf Schritt und Tritt.

Das fängt bei den Templates an, setzt sich in der Gestaltung, der Funktionalität und der Anpassbarkeit des Backends fort und endet noch lange nicht bei der Art und Weise, wie man WordPress um eigene Inhaltstypen, Zusatzfelder und Zusatzfunktionen erweitert.

Versteht mich bitte nicht falsch: Ich mag WordPress. Aber ich mag es eigentlich nur für den Aufbau von Websites, die hauptsächlich Blog- oder News-Charakter haben. Da ist WordPress unschlagbar. Bei allen anderen Website-Arten halte ich persönlich WordPress nicht immer für die beste Wahl.

Gerade für klassische Unternehmens-Websites mit hauptsächlich hierarchisch gegliederten Inhalten, mehreren eigenen Inhaltstypen, vielen Zusatzfeldern verschiedenster Feldtypen und Backend-Anpassungen, die die Website möglichst DAU-sicher und unkaputtbar machen, setze ich WordPress nur ungern ein.

Das ist natürlich eine subjektive Meinung. Doch sie ist nicht aus der Luft gegriffen, sondern basiert auf Erfahrung mit einer Reihe solcher Projekte – die ich nur deshalb zwangsweise mit WordPress umsetzen musste, weil Kunden und Chefs es unbedingt so wollten. Ja, es hat funktioniert. Und mit einigem Aufwand bin ich meiner Vorstellung von der optimalen Umsetzung auch ziemlich nahe gekommen. Allerdings: In einigen anderen CMS wäre das alles wesentlich leichter und schneller gegangen.

Auf der Suche nach Alternativen

Die Erfahrung mit ungefähr eineinhalb Dutzend verschiedenen CMS in den letzten zehn Jahren hat mich zwei Dinge gelehrt. Erstens: Es gibt nicht „das eine perfekte CMS“. Jedes System hat Stärken und Schwächen, wodurch es sich für einen bestimmten Einsatzzweck besser oder schlechter eignet. Auch das CMS ProcessWire, zu dem ich nach dieser ausschweifenden Einführung endlich kommen sollte, ist nicht perfekt. Es ist ein noch recht junges System. Es gibt daher selbstverständlich einige Dinge, die noch nicht ganz rund laufen, und Features, die bisher noch nicht entwickelt wurden. Dennoch ist ProcessWire für bestimmte Anforderungen eine sehr gute Wahl.

Zweitens: Im Prinzip ist jede Website mit jedem System umsetzbar. Die Frage ist immer nur: mit welchem Aufwand für Anpassungen und Zusatzentwicklungen? Deswegen ist es wichtig, zu wissen, wonach man eigentlich sucht, wenn man sich nach CMS-Alternativen umsieht.

Meine Anforderungen an ein CMS – wenn es denn nicht WordPress für Blog-Projekte werden soll – sind schnell dargestellt:

1. Hauptsächlich benötige ich ein CMS für typische Unternehmenswebsites kleiner und mittelständischer Firmen. Das bedeutet:
   • hauptsächlich hierarchisch strukturierte Inhalte
   • viel Related Content, wie z. B. verwandte Produkte, Ansprechpartner, Downloads – das alles selbstverständlich zentral pflegbar
   • ein News-, Presse- oder Blog-Bereich
   • Kontaktformulare
2. Zusatzfelder und eigene Inhaltstypen sollen einfach und flexibel über das Backend erstellt und angepasst werden können.
3. Das Backend des CMS muss für Benutzer intuitiv bedienbar und für Entwickler einfach und schnell anpassbar sein, um es möglichst DAU-sicher und unkaputtbar zu machen.
4. Das CMS soll mir möglichst wenige Vorschriften bezüglich der Templates machen. Weder wie diese heißen, noch wie sie aufgebaut sein müssen. Dass div-Gewitter, wie man sie aus den Standard-Templates der Drupal-Views kennt, indiskutabel sind, versteht sich von selbst.
5. Das CMS muss schnell erlernbar sein. Ein Tag Dokumentation lesen, ein Testprojekt – danach müssen alle wesentlichen Kenntnisse sitzen. Für alles, was länger dauert, habe ich keine Zeit.

Das war’s. Eigentlich ganz einfach, sollte man meinen. Doch nachdem eine Zeit lang alle meine Anforderungen vom CMS MODX Evolution erfüllt wurden, entwickelt sich dessen Nachfolge-Version MODX Revolution immer mehr in eine Richtung, die mir nicht gefällt. Aus dem ehemals schlanken, flexiblen CMS wird meinem Empfinden nach immer mehr ein alles-können-wollendes CMS-Dickschiff, das einfache Arbeitsschritte unnötig verkompliziert.

Umso angenehmer war ich überrascht, als ich vor kurzem ProcessWire kennenlernte. Dieses kleine CMS ist in vielerlei Hinsicht so, wie ich mir den MODX Evolution-Nachfolger gewünscht hätte. Das sehe ich übrigens nicht alleine so. Es kann kein Zufall sein, dass sich im Entwickler-Forum von ProcessWire einige Namen tummeln, die ich aus MODX-Zeiten kenne.

Was mir an ProcessWire so gut gefällt

ProcessWire ist genau das, was sein Name sagt: ein Content-Management-System. Nicht mehr und nicht weniger. Es bietet eine leicht bedienbare und umfassend anpassbare Oberfläche für die Eingabe von Inhalten sowie eine API, mit deren Hilfe man in seinen Templates auf diese Inhalte zugreifen kann. Mehr nicht. Das klingt vielleicht unspektakulär. Doch angesichts der funktionsüberfrachteten Backends manch anderer CMS ist dies ein erfreulich puristischer Ansatz.

Der Hauptentwickler Ryan Cramer wollte so etwas wie jQuery haben, nur eben für CMS-Aufgaben. Und genau das ist ProcessWire letztlich geworden: Ein System, das dem Webdesigner bei den Brot-und-Butter-Arbeiten unter die Arme greift, ihm jedoch in seinem Hauptmetier, dem Gestalten und Coden des Frontends, völlig freie Hand lässt.

ProcessWire richtet sich daher eindeutig an Webdesigner und Frontend-Entwickler, die nach einem leicht zu bedienenden Werkzeug suchen, um einem HTML-Dummy Leben einzuhauchen. Wer nur wenig Ahnung von HTML- und CSS hat, sich zusammen mit dem CMS ein vorgefertigtes Theme herunterladen und dieses lediglich ein wenig anpassen will, wird mit ProcessWire definitiv nicht glücklich werden. Für diese Zielgruppe ist WordPress mit Sicherheit die richtige Wahl.

ProcessWire macht manches anders

In ProcessWire gibt es keine Standard-Inhaltstypen und so gut wie keine Standard-Felder für die Eingabe von Inhalten. Das liegt daran, dass das Konzept der individuell gestaltbaren Zusatzfelder und Inhaltstypen sehr tief im System verankert ist. Das Ganze hat vom Prinzip her ein wenig Ähnlichkeit mit Drupals CCK. Allerdings ist bei Processwire ein hierarchisch organisierter Seitenbaum das Rückgrad des Systems. Jeder Inhalt ist eine Seite innerhalb dieses Seitenbaums. (Selbst das komplette Backend besteht aus solchen Seiten. Sie sind für normale Redakteure jedoch im Seitenbaum ausgeblendet.)

Eine Seite muss dabei nicht zwingend eine typische Inhaltsseite für das Frontend sein. Versteckte Seiten lassen sich auch prima als „Datenbankeingabemasken“ verwenden. Mit ihrer Hilfe kann ein Webdesigner eine Pflegeoberfläche für beliebige Inhalte bereitstellen, ohne eine einzige Zeile programmieren zu müssen. Die zentrale Pflege von Downloads und deren Metadaten, das Anlegen und Verwalten von Farbschemen durch Website-Redakteure oder die zentrale Pflege von Inhalten, die auf der Website an mehreren Stellen auftauchen, sind nur einige der möglichen Anwendungen für solche „Datenbankeingabemasken“.

Welche Eingabefelder im Backend für eine Seite zur Verfügung stehen und wie die Seite im Frontend angezeigt wird, regelt das Template der Seite. Welches Template einer Seite zugewiesen ist, lässt sich von einem Website-Redakteur auch im Nachhinein noch ändern. Ein halbfertiger „Blogartikel“, der dann doch lieber eine „News“ werden soll, muss also nicht gelöscht und neu angelegt werden. (Wo es angebracht ist, kann dieser nachträgliche Template-Wechsel auch von einem Administrator unterbunden werden.)

Ein Template wiederrum besteht aus zwei Teilen: zum einen aus der Information, welche der Inhaltsfelder von dem jeweiligen Template verwendet werden sollen, zum anderen aus einer Template-Datei, in der die Darstellung des Inhalts im Frontend geregelt ist. In jedem Template lassen sich die Felder individuell anordnen, umbenennen, mit template-spezifischen Hilfstexten versehen und auf verschiedene Tabs aufteilen.

Das alles gibt dem Webdesigner die Möglichkeit, den wohl wichtigsten Teil des Backends exakt an die Erfordernisse des jeweiligen Projekts und der zukünftigen Website-Redakteure anzupassen. Dazu trägt auch die nicht unnötig komplizierte, aber dennoch äußert flexible und praxistaugliche Rollen-Rechte-Verwaltung bei, mit der ein Administrator im Handumdrehen für Website-Redakteure alle Elemente ausblenden kann, die sie nicht benutzen müssen oder sollen.

In Kombination mit der automatischen Vergabe der korrekten Templates für bestimmte Website-Bereiche und der Möglichkeit des Frontend-Editings mithilfe des Plug-In-Moduls Admin Bar erhalten Website-Redakteure eine sehr einfach bedienbare Arbeitsoberfläche, bei der es kaum Möglichkeiten gibt, aus Versehen einen falschen Button zu klicken.

Kommen wir zurück zum Aufbau der Inhaltstypen. Bei der Gestaltung der Eingabefelder für die Inhalte bietet ProcessWire viel Nützliches. Es gibt nicht nur viele verschiedene Feldtypen, die neben den üblichen Text- und WYSIWYG-Feldern (wobei sich das TinyMCE-Setup für jedes WYSIWYG-Feld individuell(!) einstellen lässt) auch beispielsweise Color-Picker oder Range-Slider umfassen. Die einzelnen Felder sind meist auch ziemlich durchdacht. So beherrschen die Feldtypen für das Hochladen von Bildern und Dateien nicht nur Drag & Dop, Multiupload sowie das Beschriften und sortieren der Uploads.

Auf Wunsch können hochgeladene Zip-Dateien auch direkt entpackt und die enthaltenen Dateien anstatt des Zip-Containers in das Upload-Feld eingefügt werden. In Kombination mit dem zusätzlichen Plug-In-Modul Thumbnails können für jedes Bilder-Feld beliebig viele Bildgrößen definiert werden. Die entsprechenden Thumbnails und Bildausschnitte werden direkt nach dem Upload generiert, können jedoch jederzeit von Website-Redakteure nachbearbeitet werden, beispielsweise um in der kleinen Version eines Bildes einen anderen Bildausschnitt zu wählen.

Video zum Thumbnail-Modul:

http://youtu.be/fYdUbyvc0E8

Ein weiterer nützlicher Feldtyp sind „Repeater“, die beliebig viele Elemente enthalten können, wobei jedes einzelne Element wiederum aus einer Sammlung verschiedener Felder bestehen kann. Ein Feature-Slider auf der Startseite mit einer nicht festgelegten Anzahl Slides lässt sich mit einem solchen Feld beispielsweise sehr komfortabel pflegen.

Zusätzlich ist das komplette Backend optisch mithilfe von Admin Themes anpassbar. Gerade für Kundenprojekte ist das magenta-türkis-farbene Standard Admin Theme nicht unbedingt angebracht. Hier kann ich das Teflon Admin Theme empfehlen, das deutlich seriöser aussieht.

Wer ProcessWire häufiger einsetzt, sollte sich das Plug-In-Modul Site Profile Exporter genauer ansehen. Ich habe es selbst zwar noch nicht eingesetzt. Doch der Beschreibung zufolge ist es damit möglich, Muster-Websites mit allen benötigten Dateien und Einstellungen zu exportieren, so dass man zukünftige ProcessWire-Projekte darauf aufbauen kann. Wer also immer wieder ähnliche Projekte umsetzt, kann hier sicher viel Zeit sparen. Wer mit ProcessWire ein Blog umsetzen möchte, sollte unbedingt einen Blick auf das Blog Profile werfen.

Ungewöhnlich ist die Template-Sprache von ProcessWire. Sie existiert nämlich nicht. Stattdessen kommt einfach nur PHP zum Einsatz, in Kombination mit einer beliebigen, vom jeweiligen Webdesigner bevorzugten Auszeichnungs- oder Strukturierungssprache, egal ob HTML, XHTML, HTML5, XML, JSON oder was auch immer das jeweilige Projekt erfordert. ProcessWire macht hier weder Vorgaben, noch Annahmen und rendert auch nicht eigenständig Teile des Outputs. Von der PHP-Nutzung war ich anfangs nicht sehr begeistert. Schließlich habe ich den Mischmasch aus HTML und PHP bei WordPress immer kritisiert und fand die in MODX vorgeschriebene strikte Trennung von Darstellungs- und Funktions-Code sehr sinnvoll.

Mittlerweile bin ich jedoch von dem äußerst pragmatischen ProcessWire-Ansatz überzeugt. ProcessWire stellt alle benötigten Inhalte und Funktionen über eine leicht verständliche API zur Verfügung. Den Inhalt des Feldes „headline“ der aktuellen Seite gibt man beispielsweise mithilfe des PHP-Codes <?php echo $page->headline; ?> aus.

Wer es gerne kürzer mag, kann auch die Short-Tag-Schreibweise headline?> verwenden. Auf den ersten Blick sieht das vielleicht etwas aufwändig aus. Würde doch zum Beispiel in MODX Revolution ein einfaches [[*headline]] genügen. Doch so viel komplizierter und länger als „echte“ Template-Sprachen ist die ProcessWire-Variante auch nicht. In einem kleinen Vergleich zwischen Expression Engine und der ProcessWire-Schreibweise schneidet ProcessWire hinsichtlich der Kürze sogar besser ab.

Dafür hat die Verwendung von PHP anstatt einer proprietären Template-Sprache zwei große Vorteile. Zum einen kann jeder Entwickler, der wenigstens über PHP-Grundkenntnisse verfügt, sehr schnell verstehen, was in einem ProcessWire-Template vor sich geht – selbst wenn er sich zuvor nicht mit der ProcessWire-API-Dokumentation beschäftigt hat. Zum anderen ermöglicht PHP eine enorme Flexibilität. Mit wie viel Programmlogik die Templates dabei „verunreinigt“ werden, bleibt jedem Entwickler selbst überlassen. Niemand wird schließlich daran gehindert, aufwändige Operationen sauber in Includes auszulagern. Für „ganz normale“ Templates hingegen genügen PHP-Grundkenntnisse völlig. Mehr als Variablendefinitionen, if-Abfragen und foreach-Schleifen sind nicht nötig, um selbst ambitionierte ProcessWire-Templates zu gestalten. Ich bin wahrlich kein PHP-Profi und komme beim Schreiben von ProcessWire-Templates problemlos zurecht.

Zur Illustration hier ein kleines Code-Beispiel aus der API-Dokumentation: Es soll eine Liste mit Links zu allen Seiten vom Typ „Skyscraper“ ausgegeben werden. Die Liste soll jedoch nur solche Wolkenkratzer enthalten, die vor 1950 erbaut wurden und mindestens zehn Stockwerke hoch sind. Die Sortierung der Listenelemente erfolgt zunächst absteigend nach dem Baujahr und dann absteigend nach der Anzahl Stockwerke.

<ul>
    <?php
    $skyscrapers = $pages->find("template=skyscraper, year<1950, floors>=10, sort=-year, sort=-floors");
    foreach ($skyscrapers as $s) {
        echo '<li><a href="'.$s->url.'">'.$s->title.'</a></li>';
    }
    ?>
</ul>

Erwähnenswert ist übrigens auch, dass über die API nicht nur Templates mit Inhalten befüllt werden können. Die API bietet auch Zugriff auf Funktionen der Seiten- und Benutzerverwaltung. Damit ließe sich ProcessWire auch als Framework für eigene Community-Plattformen verwenden, auf der die Mitglieder verschiedenste Arten von User-Generated-Content erstellen und pflegen können – abseits des simplen Kommentar-Moduls.

Es gibt noch Luft nach oben

Noch ist ProcessWire nicht perfekt. Zwar gibt es bereits eine ganze Reihe Plug-In-Module, die vielfältige Zusatzfunktionen bereitstellen. Doch für mich persönlich stehen zwei Dinge ganz oben auf der Wunschliste:

1. Ein Asset Management, das den Komfort der jetzigen, an einzelne Inhaltsseiten gebundenen Bilder-Upload-Felder mit einer zentralen, seitenübergreifenden Bilder-Verwaltung verbindet. Hier müsste meines Erachtens die Bilder- und Dateiverwaltung von WordPress das Vorbild sein.
2. Die Möglichkeit, einzelne Felder zu Pflichtfeldern zu machen. Dies ist zwar angeblich schon seit längerem angedacht. Doch gibt es bei einigen Feldtypen offenbar noch Probleme. Allerdings ist dieses Feature laut Roadmap für die demnächst erscheinende ProcessWire-Version 2.3 vorgesehen.

Einfacher Einstieg in ProcessWire

Wer jetzt neugierig geworden ist und sich näher mit ProcessWire beschäftigen möchte, tut am besten folgendes:

1. Einführungsvideo ansehen. Das Video zeigt zwar nicht die neuste ProcessWire-Version, gibt aber dennoch einen guten Überblick.
2. Die API-Dokumentation durchlesen. Keine Sorge, die Dokumentation lässt sich sehr flüssig lesen. Die ideale Lektüre für einen Sonntag-Nachmittag.
3. Die restlichen Videos auf der ProcessWire-Website ansehen.
4. ProcessWire herunterladen und selbst ausprobieren. Demo-Website-Inhalte werden automatisch mitinstalliert, so dass man direkt loslegen kann.

Wir arbeiten seit 20 Jahren mit WordPress und bieten diverse Dienst­leistungen rund um das System an. Kontaktiere uns für weitere Informationen oder für ein Angebot.

Verwandte Beiträge:

• Wie WordPress Joomla! abgehängt hat
• WordPress: Detail-Infos für einen Beitrag oder eine Seite
• Lohnt es sich noch auf WordPress zu setzen?
• Marktanteil: Auch in 2021 kennt WordPress nur eine Richtung
• Marktanteil: WordPress ist auch in 2020 nicht zu stoppen