Perch: Nur ein kleines CMS – oder doch mehr?

Um es mit Watzlawick zu sagen:

Wer nur einen Hammer als Werkzeug kennt dem ist jedes Problem ein Nagel.

So verfahren viele Webentwickler auf eingefahrenen Bahnen. Der Typo3-Experte tendiert dazu, genau so wie der Drupal-, WordPress- oder ExpressionEngine-Freund. Und klar: Die meisten kleinen und mittleren Projekte lassen sich ohne Problem mit allen der üblichen Standardtools lösen. Statt aber ständig mit Kanonen auf Spatzen zu schießen, könnte man aber auch einen Blick über den Tellerand wagen, beispielsweise in Richtung Perch.

perch

Auf den ersten Blick wirkt Perch wie ein etwas hübscheres Tool zum Ersetzen von Texten in statischen HTML Seiten. Dort, wo einst der ausformulierte Text stand, setzt man eine Zeile Code ein:

<?php perch_content('About main_heading');>

Nachdem erstmaligen Aufruf dieses Dokumentes erscheint in der Perch Administrationsoberfläche sofort entsprechender Platzhalter unter Beibehaltung der im Code vergebenen Bezeichnung und kann mit Inhalten befüllt werden. In diesem Beispiel also der Headline auf der About-Seite.

share-regions1-small

Neben Texten lassen sich natürlich auch ganze Codeblöcke, Bilder und dergleichen Austauschen. Diese Elemente können natürlich auch mehrfach inkludiert werden, so dass man die Navigation oder die Kontaktadresse im Footer zentral editierbar machen kann. Schon mit diesen recht einfachen Maßnahmen kann man potentiellen Auftraggebern bereits vollkommene Autonomie über die Verwaltung von Inhalten auf Ihrer Seite geben ohne ein komplexeres CMS zu installieren und die unterschiedlichen Seitentypen in passende Templates umzustellen.

Richtig interessant wird Perch aber durch Möglichkeiten, die darüber hinausgehen. So lassen sich kleine Custome Templates anlegen, die das Erstellen immer wiederkehrender Seitentypen einfach machen:

<div class="product">
<h2> <perch:content id="name" label="Product name" required="true" type="text" /> </h2>
<img src="<perch:content id="photo" label="Photo" type="image" />"
class="photo" alt="<perch:content id="name" label="Product name" />" />
<perch:content id="desc" label="Description" required="true"
textile="true" type="textarea" />
<p> <a href=" Read more...</a> </p>
</div>

Das Anlegen neuer Produkte sieht dann für den Redakteur so aus:
28

Weiterhin lassen sich mit Hilfe von Conditional Tags über einfach Schalter, bestimmte Elemente einfach an oder abschaltbar machen.

30

Als Fazit lässt sich festhalten, dass Perch, das sich mit einem Preis von rund 40 EUR pro Domain bequem in jeder Kalkulation unterbringen lässt, in machen Fällen durchaus eine überlegenswerte Alternative zu den anderen, großen, größeren und viel größeren Lösungen darstellen kann. Natürlich fehlen manche Funktionen – aber genau das ist das Prinzip.

Kommentare (31)

  1. Danke für den kleinen Einblick. Was mich aber extrem skeptisch macht ist der Syntax. Ist dieser wirklich so oder hast du den nur so geschrieben, damit er nicht umgewandelt wird hier auf deiner Seite? Ich meine und <?a href=" Read more… finde ich extrem strange.

    Über die Mehrsprachigkeit hätte ich gerne noch bescheid gewusst. Die ist ja neusterdings laut der Seite auch verbaut.

    • Das war mein Fehler in der Syntax. Sieht natürlich ganz normal aus, so wie jetzt hier korrigiert.

      Was die Mehrsprachigkeit angeht, so ist diese wohl implementiert – es scheinen aber noch Language-Packs zu fehlen:

  2. Mittlerweile gibt es auch Sprachpacks, direkt auf der Herstellerseite. Siehe http://grabaperch.com/suppo...

    Hab Perch seit ein paar Tagen für einen Kunden im Einsatz und es funktioniert wirklich gut.

    Es ist manchmal etwas arg eingeschränkt und vor allem ein besseres Conditional-System sowie eine Möglichkeit den Content direkt auf der eigentlichen Seite editieren zu können (wäre ne Implementation wert) wären fein, aber alles in allem perfekt für fast jede kleinere Seite, die auch ohne Blog auskommt.

    Muss aber Nachtmeister zustimmen, der Syntax ist wirklich etwas komisch ich hätte vor allem für die Template-Snippets lieber was gesehen, was nicht ganz so nahe am HTML-Code liegt.

  3. Hmmm, bis ist das mit den 40 Euro las, fand ich es ja noch ganz knuffig. Aber nein, eigentlich ist es so oder so Nonsens. Ein System wie MODx z. B. leistet unendlich viel mehr, ohne damit wirklich mehr Arbeit zu verursachen. Man kann ebenfalls mit HTML starten, Platzhalter hinzufügen und nach Belieben wiederkehrende Teile in Templates bzw. Codeschnippsel auslagern. Dafür steht man dann nicht nach kürzester Zeit blöd da, wenn von den News automatisch immer nur die letzten drei angezeigt werden sollen oder man eine Breadcrumb-Navigation bauen will.

    Ich glaube übrigens, dass die Einteilung “mittlere/kleine Site” bzw. “mittleres/kleines CMS” selten weit führt. Interessantere Kriterien sind doch sowas wie: “Fange ich bei null an oder habe ich ein HTML-Vorlage?” und “Benötige ich eigene Inhaltstypen oder komme ich mit Blöcken bzw. Seiten und vorgefertigten Modulen hin?”.

    • Nun kenne ich MODx nicht wirklich, von daher kann und will ich gar nicht ausschließen, dass auch das eine interessante Alternative oder vielleicht für manche Projekte sogar der Königsweg ist.

      Allerdings kommt es eben immer auf Art, Umfang und die zu erwartenden Wünsche und Ansprüche des Kunden im Umgang mit der neuen Site an. Und ein Admin-Interface wie bspw. dieses hier möchte ich keinem Kunden zumuten, ohne dass es dafür eine Reihe extrem guter Gründe gibt.

  4. @rbq Damit läufst du genau auf dem Weg, den Oliver direkt am Anfang des Posts als Holzweg darstellt.

    In vielen Fällen will ich gar kein “unendlich viel mehr”, sondern ein “eher noch viel weniger”.

    Kunst ist das richtige wegzulassen.

    Und Perch kümmert sich eben nur um die Inhalte einer statischen Seite und erhebt gar nicht den Anspruch, mehr zu tun.

  5. Muss aber sagen, dass der Preis für die Features schon nicht berechtigt ist. Ich bin mir sicher, dass die geringe Funktionsweise sogar in wenigen Tagen selber programmiert werden kann.

    Ansonsten gefällt mir das System recht gut. Nur eben der Preis lässt für die Leistung zu wünschen übrig. Oder bezahlen wir in Zukunft drauf, damit wir auch ja weniger bekommen? ;)

    • Wobei 40 EUR sicherlich in jedem noch so kleinen Angebot Platz finden dürften.

      Aber ja, das ist natürlich eine Frage des Prinzips, denn man bezahlt natürlich für eine Software, deren Funktionen es in vielen anderen Tools kostenlos gibt. Und viel mehr. Und das ist dann der entscheiden Punkt….

    • Stimme Oliver hier zu: 40 EUR haben überall Platz im Angebot. Und wer kann denn für 40 EUR etwas für ein paar Tage selbst programmieren? Ich wünschte mir bei vielen Systemen eine Möglichkeit zu vereinfachen, ohne, dass man auch automatisch Rechte verliert (vgl. z.B. WordPress: Einfachere Darstellung = weniger Rechte, nicht unbedingt das, was man für den Kunden möchte).

      Schaue mir Perch auf jeden Fall noch einmal an. Hatte als einfaches System ein paar mal frogCMS (ein RadiantCMS für PHP) im Test, was auch ganz gut funktionierte, auch von der Nutzerseite her.

      Danke für den Artikel.

  6. Preis ist definitiv ein Knackpunkt.

    Selber Programmieren so ne Sache, wenn wenig von PHP versteht, bzw. nicht die Zeit hat. Setze gerne auf Eigenlösungen, aber grade für besagten Kunden waren Zeit und Bezahlung dafür einfach zu knapp.

    Und natürlich zahlen wir für weniger drauf, siehe Apple und Co.

    • Und natürlich zahlen wir für weniger drauf, siehe Apple und Co.

      Die Kunst liegt im Erkennen, der Mut im Weglassen….

      • Bei Apple ist das eher Ansichtssache. Grundsätzlich kann man sagen, dass ich Flexibilität einbüsse, wenn ich Mac benutze. Aber das ich da durch “weniger” bekomme, würde ich nicht sagen. Ich bekomme eher anderes. Aber ich habe die Funktionen immer noch, welche ein Windows PC bietet, einfach über andere Schnittstellen und Oberflächen. Das ist aber eher eine andere Diskussion. Sicher ist, Perch würde ich ohne weiteres für jemanden Einsetzen, der eine kleine Seite statische Seite benötigt und eher Laihe ist im Umgang mit Web und Software.

  7. Man muss auch klar sagen, dass Design bestechen kann. Heute werden viele Applikationen, die eigentlich völlig Sinnfrei sind oder einen kleinen Nutzen haben, mit einem guten Design leicht an die Leute und so potenzielle Käufer gebracht, welche oft schnell mit dem Auge entscheiden. Ich lasse mich davon auch beeinflussen würde aus dem Grund Perch vor ModX vorziehen. Da ich ModX aber Ansatzweise kenne (in etwa auf die selbe Art wie Perch) würde ich im selben Umfeld wohl ModX wählen. (Habe zu der Bestechung durch schönes Design übrigens neulich einen Beitrag in meinem Blog geschrieben. Ich hoffe Perch fällt nicht in diese Sparte)

  8. Nichts gegen’s weglassen, ich verstehe den Sinn durchaus. Mit nur einem User braucht man keine Benutzerverwaltung, ohne Kommentarfunktion keinen Spamfilter. Das wirkt sich auf das Gesamtgewicht der Software aus, evtl. auf den Preis und ziemlich sicher auf den Einrichtungsaufwand.

    Aber dies hier sind doch alles nur noch angedeutete Funktionen. Für einen Bruchteil eines Templatesystems mit einem Ansatz von Inhaltstypen und evtl. noch einem Hauch von Navigation in einem System fehlt mir einfach das Verständnis. Da ist doch sowas von vorprogrammiert, dass man sofort an Grenzen stößt …

  9. Apropos Design, was ist eigentlich aus Wildflower geworden? Das sah doch auch hübsch übersichtlich aus, obwohl CakePHP drunter steckt.

  10. Interesannte Vorstellung!

    Über Sinn oder Unsinn ein 40 EUR Produkt selbst zu programmieren braucht man nicht zu diskutieren. Gerade für die kleinen Projekte, die entsprechend Kostensensibel daher kommen, ist jedes weitere Wort überflüssig.

  11. Ich bin völlig mit dem Open Source CMS “TypoLight” zufreiden. Bei größeren Projekten kommt dann TYPO3 zum Einsatz. Warum 40 EUR für Perch ausgeben?

  12. Da kann ich eine Anekdote zu beitragen. Ich hatte ja im Frühjahr versucht eine eigenes, minimalistisches PHP-CMS zu basteln. Ich hab das dann aus unterschiedlichen Gründen eingestellt. Ich hab aber die spannende Einsicht davon getragen, dass man mit ziemlich wenig Code in PHP wirklich unglaublich kommt. Und zwar nicht, weil PHP nun viel mehr kann, sondern einfach, weil man heute zum einen Sachen anders anpackt, als noch 2002 und zum anderen besser weiß, was welche Features man braucht und was man im Code regeln kann.

    Hier die Dokumentation meiner Liebelei mit “Heimweh”
    http://anmutunddemut.de/cat...

    Hier der Code:
    http://github.com/benthebea...

    • Gut, Du hast aber auch nur Funktionen extern ausgelagert. WIie gesagt sind die Funktionen, die das CMS Perch mitbringt bestimmt schnell mal programmiert.

      Anders sieht es aus, wenn man PHP OOP mit Klassen programmiert. Da nehmen alleine die Programmierung der Klassen sicher ziemlich viel Zeit in Anspruch.

      Ich weiss jetzt nicht, wie Perch programmiert wurde, aber ich bin mir auch mit meinem eher “Anfänger” Wissen über PHP sicher, dass der Aufwand ziemlich gering ist.

      • Öhm … ich versteh da Deine Argumentationslinie nicht so ganz.

        Auf jeden Fall ist “richtige” Anwendungsentwicklung aufwändiger. Egal ob OO oder anders (Drupal ist da ein schönes Beispiel für nicht-OO Engineering). Das ist ja v.a. so, weil “richtige” Anwendungen ganz andere Zielsetzungen und Anforderungen haben.

        Was ich mit Heimweh vorhatte und was Oliver scheinbar in Perch gesucht hat, geht aber ja eher in die Richtung aus der PHP einst kam. Nämlich das das einfach ersetzen und zusammstöpseln von Inhalten in HTML-Dokumenten / Templates. Die ganzen frühen PHP Sachen sind alle vom Wesen her, zuallererst HTML-Dokumenten und erst danach etwas Programmierung. Das hielt die Codebasis extrem gering und die Flexibilität für denjenigen, der FTP/HTML und ein wenig PHP beherrscht sehr hoch.

        Mit den Open Source Systemen haben wir zwar viel mehr Leute erreicht und das ist eine überwältigend großartige Leistung. Aber ich für meinen Teil sehne mich ein wenig zurück zu der Flexibilität von früher.

      • Danke! Und nach dem Aritkel und der Diskussion hier, juckt es mir ja doch in den Fingern, mich da nochmal dranzusetzen. Scheinbar, bin ich ja nicht der einzige, der in sich in die Richtung bewegt.

  13. <img src=”<perch:content id=”photo” label=”Photo” type=”image” />”
    class=”photo” alt=”<perch:content id=”name” label=”Product name” />” />

    <perch:content id=”desc” label=”Description” required=”true”
    textile=”true” type=”textarea” />

    Bei sowas dreht sich mir allerdings der Magen um. Das Template versucht ja nur so auszusehen, wie XML ist aber weder wohlgeformtes und daher nur Datenmüll, für den Perch vermutlich einen eigenen Parser geschrieben haben. Wenn man sowas, braucht man auch keine XML-esque Notation mehr, weil das ja doch von keiner XML-Bibliothek weiterverarbeitet werden kann. Da kann man besser entweder sowas wie Smarty mit eigener Notation machen, oder – wenn man denn unbedingt spitze Klammern haben will – sollte man besser gleich reines PHP verwenden.

  14. Lasst mich mal versuchen, aus all den Kommentaren hier ein Fazit zu ziehen:

    Perch ist sicher nicht perfekt, es ist nicht kostenlos, es erzeugt kein wohlgeformtes XML etc. Es gibt viele, viele andere Tools und Möglichkeiten, mit denen man arbeiten kann (inkl. natürlich der Option ein solches Tool selbst zu entwickeln), dennoch – und das war schon immer mein Punkt: Kann Perch in manchen Projekte die richtige, weil schlanke und unkomplizierte Wahl sein. Einverstanden?

    • “Einverstanden?” Ja!

      Und mehr noch: Perch ist ein spannener Wegweiser in eine neue, alte Richtung. Weniger Code. Weniger Features. Mehr Flexibilität, die aber auch mehr Kompetenz fordert. Back to the Roots of PHP, aber ohne die Fortschritte zu vergessen, die wir gemacht haben.

  15. Für mich gibt es ei solchen “kleinen” Lösungen einen wichtigen Aspekt, der noch wenig beleuchtet wurde: Wie sicher kann ich sei, dass dieses Stück Code weiterentwickelt, gepflegt, auf dem neuesten Stand gehalten wir? Ich habe mir angewöhnt, vor allem auf das Changelog zu achten: Wie lange ist das letzte Release her, “atmet” das Projekt überhaupt noch? Das ist übrigens bei Community-Projekten oft leichter zu beurteilen. Eine kleine Entwickler-Community gibt mir in der Regel ein besseres Gefühl als ein Einzelentwickler, bei dem ich nicht weiß, ob er das Projekt nicht morgen generell hinschmeißt. Aber natürlich kann es auch genau andersherum laufen…

  16. Auf der einen Seite gebe ich dir ja recht dass man nicht immer mit Kanonen auf Spatzen schießen muss.
    Allerdings weiß man nicht bei jedem Projekt wie umfangreich es irgendwann wird. Umso besser wenn man da gleich ein anständiges umfangreiches System einsetzt – und wenn es sowieso OpenSource ist ist auch der finanzielle Aufwand nicht ausschlaggebend ob nun OS Lösung 1 oder OS Lösung 2.

  17. Pingback: » Kleiner Test des kleinen CMS Perch — cne _LOG Archiv

  18. Vielleicht ist euch auch dieser Hammer zu wuchtig für eure Nägel, aber ich habe es gerade kennengelernt und finde es aus Anwendersicht schön simpel und spannend, WYSIWYG-mäßig; Riot.

    Klar gibt es da für viele gleich eine riesige Hürde, wenn sie Java hören, aber die Hürde am Anfang zu nehmen lohnt sich laut Berichten der Kollegen. Das CMS ist eher ein Rahmen, in den sich etliches reinhängen lässt, aber eben auch ganz reduziert zu nutzen.
    Und im Vergleich zu Perch ist es OpenSource, die Lizenzgebühren entfallen…

    Nur um die Werkzeugpalette zu ergänzen, damit nicht alle Probleme Nägel bleiben.. ;)

Kommentare sind geschlossen.