WordPress & Webwork

Das kleine, feine CMS ProcessWire: Reduzierung aufs Wesentliche

Es muss nicht immer WordPress sein. Webdesignern, die möglichst schnell vom HTML-Dummy zu einer funktionierenden Website gelangen wollen, sollten einen Blick auf das in Deutschland derzeit noch wenig bekannte CMS ProcessWire werfen. Gerade weil ProcessWire einen völlig anderen Fokus hat als WordPress, kann es eine gute Ergänzung im Webentwickler-Werkzeugkasten sein.

Der folgende Gastartikel stammt von Michael van Laar.

ProcessWire-Logo 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.

Angepasstes WordPress-Backend

Mithilfe von Plugins wie Adminimize, CMS Tree Page View oder Members lässt sich das WordPress-Backend zwar vereinfachen und absichern. Doch der Anpassungsaufwand ist beträchtlich.

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.

Das Backend von ProcessWire

Das ohnehin schlanke Backend von ProcessWire in der noch einmal reduzierten Variante für Website-Redakteure. Noch simpler geht es kaum noch.

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“.

Versteckte Einstellungsseite

Mithilfe einer versteckten Seite lässt sich sehr einfach eine individuelle Pflegeoberfläche für zentrale Website-Einstellungen und -Inhalte (wie z. B. Adressen oder Fußzeilen-Inhalte) gestalten.

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 Eingabeformular eines Inhaltstyps, der Informationen zu den verschiedenen Geschäften eines Einkaufszentrums beinhaltet.

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:

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.

Dieselbe Ansicht des Backends – links mit dem Standard Admin Theme von ProcessWire, rechts mit dem Teflon Admin Theme.

Dieselbe Ansicht des Backends – links mit dem Standard Admin Theme von ProcessWire, rechts mit dem Teflon Admin Theme. Sieht doch gleich deutlich professioneller aus.

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.

Michael van Laar Michael van Laar ist (ab Oktober 2012) selbstständiger Online-Marketer und Webdesigner. Er beschäftigt sich seit 1997 mit Webdesign. Auf michaelvanlaar.com bloggt er (sobald die Website in Kürze fertig gestellt ist) über Online-Marketing- und Webdesign-Themen.

18 Reaktion(en)

  1. Jan

    Ich habe jetzt nur den ersten Absatz gelesen:

    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.

    Und ich schreibe nur: ACF = Advanced Custom Fields. Mehr CMS für WP geht nicht. Und es ist so genial einfach. Wer es noch nicht kennt: Umbedingt ausprobieren … ACF liefert genau das: Inhaltstypen, Zusatzfelder, Zusatzfunktionen und super easy Anpassbarkeit des Backends.

    Für mich gibt es ehrlich gestanden kein WP ohne ACF mehr.

  2. Gino

    Ausgezeichneter Artikel, vielen Dank! Klingt sehr interessant als Alternative zu WordPress – wie Du auch schreibst: Je nach Anwendung und Anforderung sicher eine dankbare Alternative. Ob die WordPress-Mediathek als Vorbild dienen sollte ist allerdings fraglich. Sicherlich eine gute zentrale Dateiverwaltung, leider nicht sonderlich leicht zu bändigen. Aber für Websites mit nicht allzu viel Content sicherlich brauchbar.

  3. Jan

    So, nun den Artikel zu Ende gelesen. Sehr interessant und andere CMS schaue ich mir immer gerne an. Muss ja nicht immer WP sein.

    Aber ich muss sagen: ACF liefert fast alles für WP, was du in deinem Artikel beschreibst.

    Natürlich muss ich erwähnen, dass bestimmte ACF Funktionen kostenpflichtig sind (wie z.B. Flexible Field, Repeater etc.), aber der Entwickler liefert einen super Support und entwickelt das Plugin ständig weiter.

    In meinem WP Workflow benutze ich ACF, Adminimize und Advanced Access Manager. Dadurch kann ich recht schnell das Backend anpassen und wirklich jedes Element ansteuern. (ok, ein paar Snippets sind in der Functions.php auch noch nötig 🙂

  4. Michael van Laar

    @Jan: Ich habe ACF genutzt, auch mit den kostenpflichtigen Erweiterungen. Es ist auf jeden Fall eines der besten Plug-Ins für Zusatzfelder. Meine Erfahrungen sind trotzdem durchwachsen. Ein Plug-In ist eben doch etwas anderes als eine Core-Funktionalität.

    Mir hat beispielsweise eine schlecht programmierte TinyMCE-Einbindung im ACF schon mal sämtliche TinyMCE-Felder dieser WordPress-Installation unbrauchbar gemacht. Nachdem ich endlich eine Lösung gefunden hatte, musste ich einige Plug-In-Versionen lang bei jedem Update die Plug-In-Dateien ändern, damit der TinyMCE wieder sauber lief.

  5. Jan

    @Michael
    Ja, das ist richtig … TinyMCE und ACF ist ein dunkles Kapitel 🙁 … Da habe ich auch schon ein paar (viele) Stunden verloren. Aber seit einiger Zeit tauchen diesbezüglich bei mir keine Probleme mehr auf und TinyMCE und ACF laufen problemlos. In der aktuellen ACF Version sollte eigentlich alles glatt laufen. Ab und an soll es noch mal Probleme mit Mac und Chrome geben. Aber gut: Das Betrifft auch nur 0,001 % von Menschen 🙂

    Insgesamt ist ACF nun wirklich ausgewachsener und wesentlich stabiler als vor ein paar Monaten. Die aktuelle Version auszuprobieren lohnt sich.

    Aber mit deinem Core Argument hat du völlig recht. Ich habe auch ein sehr, sehr schlechtes Gefühl dabei, dass meine WP Seiten nur noch aus 98 % ACF bestehen … Vielleicht wird der Elliot von Google gekauft und das war’s dann … *grusel*

    Ich habe mir nun auch ProcessWire mal angeschaut und es finde es von einigen Ansätzen sehr toll. Nur leider gefällt mir das Standard UI nicht. Wirkt alles noch sehr technisch. Wenn da sich noch ein Designer austoben würde ….. 🙂

  6. Nico

    Hallo,
    schöner Artikel zu ProcessWire.

    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.

    Vor einigen Monaten habe ich ein solches Plugin geschrieben. Dieses kann man hier runterladen. Es sollte eigentlich komplett funktionstüchtig sein.

    Ich bin grade dabei nochmal alle mine Module durchzusehen und zu optimieren – danach kommen sie in den "Modules"-Bereich 🙂

  7. Michael van Laar

    @Jan: Das Standard-Admin-Theme von ProcessWire ist in der Tat nicht unbedingt das hübscheste. Aber wenn man im ProcessWire-Forum Themes and Profiles ein wenig stöbert, stößt man schnell auf etwas Brauchbares. Vielleicht versuche ich mich irgendwann auch mal an einem Backend-Theme.

    Bei solchen Dingen (ebenso übrigens bei den Backend-Übersetzungsdateien) merkt man eben ganz einfach, dass das System noch nicht so erwachsen und verbreitet ist wie die etablierten Content-Management-Systeme.

  8. Michael van Laar

    @Nico: Dein Modul hatte ich auch kurz mal getestet. Aber vielleicht stelle ich mich ja zu blöd an. Damit kann man alle hochgeladenen Dateien sehen, bearbeiten und löschen kann. Oder stimmt das nicht?

    Was ich gerne hätte, wäre beispielsweise die Möglichkeit, im TinyMCE nicht nur auf die Bildfelder der aktuellen Seite oder einer auswählbaren anderen Seite zugreifen zu können, sondern in einer hübschen Bildergalerie mit allen Bildern der Website suchen und auswählen zu können. Oder in ein Bildfeld nicht nur neue Bilder hochladen zu können, sondern auch Verweise zu vorhandenen Bildern unterzubringen zu können.

    Ich weiß schon, dass das mit dem Hilfskonstrukt eines separaten Inhaltstyps für Bilder und deren Metadaten gelöst werden kann. Kenne ich aus diversen Drupal-basierten Websites. Aber das ist ziemlich umständlich. Zuerst muss man für jedes neue Bild eine neue Seite in einem versteckten Bilder-Verwalt-Bereich des Seitenbaums anlegen. Und dann erst kann man die Bilder über ein Seitenreferenzfeld in Artikel einbauen. Braucht man die Bilder nicht an einer fest vorgegebenen Stelle des Artikels, sondern individuell mitten im Text (wie beispielsweise bei Blog-Artikeln), so hat man über die ProcessWire-Bildauswahl im TinyMCE nur recht mühsam Zugriff auf die Bilder, weil jedes Bild an einer eigenen Seite hängt.

    Das alles ist noch nicht wirklich komfortabel. Da geht noch mehr. Leider reichen meine eher spärlichen PHP-Programmierkünste nicht aus, um selbst etwas passendes zu bauen.

  9. Jan

    @Michael
    Danke für deinen Link-Tipp. Du hast recht: Im Forum sind schon bereits sehr schöne Design-Ansätze dabei. Cool! Ich werde ProcessWire weiter verfolgen.

    Was mir total super gefällt: Das jeder TinyMCE Block selber angepasst werden kann. Das wünsche ich mir bei WP auch sehr!

  10. Sabine

    @Nico: Dein Plugin ManageFiles (Übersicht über die Bilder auf allen Seiten mit Möglichkeit zu Löschen) habe ich ausprobiert. Aber ähnlich wie Michael es sieht, ist das für mich noch nicht die Lösung. Marc Hinse hatte im Processwire-Forum ebenfalls schon mal einen Weg angedacht.
    Image inputfield like in TinyMCE

    Die Pflichtfelder sollen wohl beim nächsten Update im Herbst (?) dabei sein.

  11. Soma

    Danke, dass Du dir die Zeit genommen hast den Beitrag zu schreiben – Dank an den Website Betreiber!

    Was mir nach dem durchlesen aufgefallen ist das der wahrscheinlich wichtigste Feldtyp nicht erwähnt wird oder ich hab’s übersehen. Der "Page" Feldtyp. Damit können Relationen zwischen Seiten "one2one", "one2many" oder "many2many" realisieren. In den Einstellungen des Feldtyps kann man diverse regeln festlegen um zu bestimmen welche Seiten dann zur Auswahl stehen (Template, Parent, custom php code, selector string). Er bietet diverse zu Eingabe in der Maske viele verschiedene Inputfeldtypen wie z.B. Checkboxen, einfache oder multiple Selects wo man auch einfach den Page Tree browsen kann, oder der ASM Multi Select womit man mehrere Pages zu einer Liste hinzufügen kann und dann sortieren. Damit lassen sich diverse nützliche Dinge anstellen wie zum Beispiel verwandte Artikel oder Kategorien etc etc. Auch zu erwähnen wäre das es sogar eine Autocomplete Module, gibt für den Page Feldtyp, der auch gleich Einträge (Seiten) erstellen kann wenn ein Eintrag noch nicht vorhanden ist, mit einem Klick.

    Ansonsten toller Beitrag, vielen Dank nochmals.

  12. Matthias Mees

    Ich finde ja nicht, dass ProcessWire „nicht mehr und nicht weniger“ als ein CMS ist. Aus meiner Sicht ist es deutlich näher an einem Content Management Framework, auch und gerade, weil es praktisch kaum „fertige“ Templates kennt – es liefert zwar eine Art Beispiel-Template mit, dessen Code-Kommentare sehr wertvoll für Neulinge sind, aber mehr eben auch nicht. Das ist im Übrigen das, was ich an PW liebe: Endlich mal ein System, das mir im Frontend absolute Freiheit in puncto HTML, CSS und JS lässt.

    Der klare Vorteil ist dabei aus meiner Sicht die API, die selbst PHP-Vollhonks wie mir einfaches, nachvollziehbares, aber dennoch sehr mächtiges Templating ermöglicht, und zwar so, dass die damit ausgegebenen Inhalte dennoch selbst für Laien einfach verwaltbar bleiben, was auch daran liegt, dass man die „Eingabemasken“ für Seitentypen sehr fein granuliert anpassen und mit Anmerkungen versehen kann. Ja, Standardwerte bzw. Vorgaben wären praktisch, aber wirklich zwingend notwendig sind sie eigentlich nicht.

    Last not least zur Medienverwaltung: Auch da finde ich nicht, dass sie zentral sein muss. Die Zuordnung von Bildern und Dateien zu bestimmten Seiten kann durchaus Vorteile haben. Auf Seiten, die viele Assets verwenden, wird so eine zentrale Datenbank wahnsinnig schnell unübersichtlich, spätestens dann, wenn Redakteure ins Spiel kommen, die „nicht vom Fach“ sind und wild Assets hochladen, die „man mal brauchen könnte“. Natürlich vermeidet eine dezentrale Medienverwaltung das nicht automagisch, aber Wildwuchs wird zumindest unwahrscheinlicher.

    Es hängt natürlich immer vom konkreten Projekt ab, aber ich habe relativ selten Bedarf, Grafiken oder Dateien mehrfach zu verwenden – und selbst das kann man theoretisch (aber nicht sehr komfortabel) auch out-of-the-box über die API hinklöppeln.

    Das wirklich Coole an PW zum Schluss: Es stellt sich eigentlich nie die Frage, ob etwas mit PW geht, sondern immer, wie etwas mit PW geht. Nicht zuletzt durch die stets freundliche und hilfsbereite Community sind da eigentlich immer schnell Lösungen, z.T. auch in Form von neuen Modulen, gefunden.

  13. Jens

    Ich kann ProcessWire auch nur loben. Ich seh das wie Matthias eher als Content Management Framework. Meinen Bedürfnissen kommt das eher entgegen als dieser immer wieder neue Versuch, bspw. WordPress oder andere CMS mit diesem oder jenem Plugin in irgendeine Richtung zu "verwursten". Ich war auch mal "WordPress-süchtig", hätte jedem erzählt, das damit alles zu erschlagen werden kann. Aber irgendwann hat das Templating auch genervt. Seitdem ich vor ein paar Monaten auf ProcessWire aufmerksam wurde bin ich der Meinung, damit wurde endlich ein Traum war. Für mich ist es jetzt meist erste Wahl, daneben benutze ich noch Contao.
    Übrigens geht Processwire schon auf von Ryan entwickelte Vorgänger zurück…Dictator CMS (2003) und ProcessWire 1.0 (2007), ist also nicht viel jünger als WordPress oder andere Systeme.

  14. Pingback: luxblog » Das kleine, feine CMS ProcessWire: Reduzierung aufs Wesentliche | WordPress & Webwork

  15. Christoph

    Endlich mal ein System, das mir im Frontend absolute Freiheit in puncto HTML, CSS und JS lässt.

    Aus genau diesem Grund habe ich bisher Textpattern eingesetzt, das zwar vom Konzept her genial, aber leider Kunden nur schwer zu vermitteln ist …

    Processwire hatte ich mir mal gebookmarked und jetzt, nach Erscheinen der neuen Version näher angeschaut. Ich muss sagen, ich bin regelrecht begeistert! Aus meiner Sicht ist der offene "Framework"-Ansatz einfach überzeugend. Ich habe in den letzten Monaten einige Projekte realisiert, bei denen ich mir gewünscht hätte, ich hätte PW früher kennengelernt.

    Klar, CMS ist immer auch Glaubensfrage 😉 Aber mir gehen Systeme wie z.B. Contao mit ihren vorgefertigten Funktionalitäten und Templates ziemlich auf die Nerven. Und WP ist mir ehrlich gesagt auch zu bloaty. Obwohl es natürlich ein sehr elegantes, kundenfreundliches Backend hat.

  16. Pingback: luxblog » Grundlagen zu Processwire

  17. Pingback: Vielen Dank an die Gastautoren | WordPress & Webwork

  18. Pingback: Mich in den Dienst des Wandels stellen - Iromeisters Abenteuerreise

Die Kommentare in diesem Beitrag sind geschlossen.