Kostenlos, kompakt und ohne Datenbank: Das Open-Source-CMS Pico


Pico: Vulkan und gar nicht so klein wie das CMS. (Foto: arenagroove / flickr.com, Lizenz: CC-BY)
Pico – Ein CMS ohne Datenbank
Was Pico von anderen Content-Management-Systemen unterscheidet? Der Hauptunterschied liegt im Datenmanagement. Bei Pico werden alle Seiten in Textdateien, in diesem Fall *.md-Dateien (Siehe auch: Was ist eigentlich Markdown?), bereitgestellt. Das System generiert dann aus diesen *.md-Dateien fertige HTML-Seiten. Ein Vorteil davon: Im Gegensatz zu anderen Systemen wie WordPress ist die Performance höher. Außerdem sind die Anforderungen geringer: Pico benötigt nur Webspace und eignet sich hervorragend für kleine Webprojekte wie Blogs oder Websites kleiner und mittlerer Unternehmen.
Installation und Aufbau von Pico
Pico kommt bei 600 Kilobyte bereits mit einem hübschen Demo-Template daher. Man sollte sich aber nicht zuviel davon erwarten, da das Template eigentlich nur die Dokumentation darstellt. Für die Installation muss man die Ordnerstruktur auf den Webspace transferieren und selbsterklärende Einstellungen (die Parameter werden im Code erklärt) in der config.php vornehmen – wie zum Beispiel die Basis-URL der Website.
Die Ordnerstruktur von Pico ist sehr flach. Der „content“-Ordner ist der einzig wichtige Order, denn darin müsst ihr eure Artikel als *.md Datei ablegen. Die Linkstruktur ergibt sich aus der Ordnerstruktur heraus, das heisst: Der Ordnername ist auch gleichzeitig der Name des Unterverzeichnisses der Website.
physischer Speicherort | URL |
---|---|
content/index.md | / |
content/sub.md | /sub |
content/sub/page.md | /sub/page |
content/a/very/long/url.md | /a/very/long/url |
Pico: Das Markup
Um eure Website mit Inhalt füllen zu können, erstellt ihr einfach eine neue *.md-Datei und fügt folgenden Header ein:
/ *
Title: Mein erster Post!
Description: Ich bin der Beschreibungstext
Author: Mario Janschitz
Date: 2013/01/01
Robots: noindex,nofollow
* /
Dieser Header enthält alle Informationen, die ihr derzeit angeben könnt, aber nicht müsst, solltet ihr zum Beispiel den Autor vergessen beziehungsweise ihn nicht benötigen, wird er auf der Website einfach nicht angezeigt – ohne Fehlermeldungen. Die Angabe des Datums ist nur bei einer gewünschten Blogfunktionalität wichtig. Durch das Templating kommt es nicht vor, dass durch einen Eingabefehler die gesamte Website nicht erreichbar ist, was auf einer Seite praktisch ist, aber auf der anderen Seite Fehler unentdeckt lassen kann.
Templates für Pico CMS
Pico setzt beim Templating auf Twig. Die Auswahl, welches Template euer Blog verwenden soll, legt ihr in der config.php fest, in der ihr den entsprechenden Namen eintragen könnt.
{{ config.theme }} = "MeinTemplate"
Das führt uns auch gleich zu den Twig-Variablen. Die index.html-Datei, die euer Theme enthält, könnt ihr mit folgenden Variablen spicken:
{{ base_dir }} - The path to your Pico root directory
{{ base_url }} - The URL to your Pico site
{{ theme_dir }} - The path to the Pico active theme direcotry
{{ theme_url }} - The URL to the Pico active theme direcotry
{{ site_title }} - Shortcut to the site title (defined in config.php)
{{ meta }} - Contains the meta values from the current page
{{ meta.title }}
{{ meta.description }}
{{ meta.author }}
{{ meta.date }}
{{ meta.date_formatted }}
{{ meta.robots }}
{{ content }} - The content of the current page (after it has been processed through Markdown)
{{ pages }} - A collection of all the content in your site
{{ page.title }}
{{ page.url }}
{{ page.author }}
{{ page.date }}
{{ page.date_formatted }}
{{ page.content }}
{{ page.excerpt }}
{{ prev_page }} - A page object of the previous page (relative to current_page)
{{ current_page }} - A page object of the current_page
{{ next_page }} - A page object of the next page (relative to current_page)
{{ is_front_page }} - A boolean flag for the front page
Eine einfach Navigation könnt ihr damit zum Beispiel so umsetzen:
<div class="nav">
{% for page in pages %}
<li><a href="{{ page.url }}">{{ page.title }}</a></li>
{% endfor %}
</div>
Nice and simple!
Pico CMS als Blog
Ihr könnt mit Pico natürlich auch bloggen. Für die Ausgabe eurer Artikel könnt ihr folgendes Code-Fragment in euer Template einbauen:
{% if is_front_page %} <!-- Front page lists all blog posts >
<div id="posts">
{% for page in pages %}
{% if page.date %} <!-- Note we check for Date field (posts) here -->
<div class="post">
<h3><a href="{{ page.url }}">{{ page.title }}</a></h3>
<p class="meta">{{ page.date_formatted }}</p>
<p class="excerpt">{{ page.excerpt }}</p>
</div>
{% endif %}
{% endfor %}
</div>
{% else %} <!-- Single page shows individual blog post >
<div class="post">
{% if meta.title %}<h2>{{ meta.title }}</h2>{% endif %}
<p class="meta">{{ meta.date_formatted }}</p>
{{ content }}
</div>
{% endif %}
Wie gesagt: Hier müsst ihr darauf achten, dass ihr euren Blog-Posts ein Datum mitgebt, sonst funktioniert die Ausgabe nicht korrekt.
Pico? Gefällt mir richtig gut!
Trotz eines positiven Fazits ist mir nicht ganz klar, wer Pico benutzen sollte, ganz besonders, da kein User-Interface exisitiert. Pico ist zwar in der Handhabung, bedingt durch Markup, sehr gefällig und einfach zu bedienen – auch für Laien. Aber das Konzept des dateibasierten CMS dürfte für Anfänger nicht gerade leicht zu verstehen sein. Als Entwickler hat man mit Pico kaum Probleme, vor allem, wenn man es gewöhnt ist andere CM-Systeme zu benutzen.
Trotz der Kritik: Mir macht Pico Spaß! Das System aufzusetzen ist ein Kinderspiel, das Templating mit Twig genau so. Markup ermöglicht ein irrsinnig bequemes Schreiben auf nahezu jedem Gerät, da auf HTML-Tags gänzlich verzichtet werden kann. Einer dieser Punkte allerdings könnte den Einstieg für Anfänger erschweren: Twig. Bevor man also mit Pico Spaß haben kann, muss zuerst Twig beherrscht werden, um ein Basis-Template erstellen zu können, denn das vorgegebene Template ist nicht responsive und stößt schnell an seine Grenzen.
Pico hat sich die Open-Source Fahne umgehängt und das lässt auf einiges hoffen. Es werden schon Plugins angeboten, um die Funktionalität zu erweitern – diese sind noch nicht sehr umfangreich, aber ausreichend. Obwohl mich Pico auf einer Seite begeistert, lässt auf der anderen Seite der ganz große „Bang“ auf sich warten. Vielleicht ist das aber auch nicht nötig. Pico ist klein und fein und erfüllt einen Zweck, schnell und einfach Webprojekte umzusetzen. Vielleicht muss nicht immer etwas revolutioniert werden, um gut zu sein.
Ja, Pico (Download) ist cool, aber Kirby ist es auch. Ob man Pico Kirby vorziehen sollte, kann ich nicht sagen, das soll jedem selbst überlassen sein.
Was meint ihr?
Ich bin selbst ein Fan von http://www.contrexx.com , aber Pico finde ich ganz witzig für kleine Landingpages.
Für solche kleinen Webprojekte ist Pico bestens geeignet! Ich habe contrexx noch nicht eingesetzt, vielleicht kommt mal ein Test dazu.
Und noch ein verkümmerter Nachbau von Template Toolkit (.org). TT2 ist offenbar zu alt und zu uncool, obwohl es die meisten neueren statischen Website-Generatoren featuremäßig in die Tasche steckt (Menü-Erzeugung, Mehrsprachigkeit, etc.). Vorteil von all diesen statischen Generatoren: Leichte Versionierbarkeit mit Git und Co., lokale 1:1 Preview (quasi Staging), schnell, freie Editor-Auswahl, sehr leichte Integration von Extrawürsten, die bei klassischen CMS einen kleinen Aufriss bedeuten würden, automatisierbares Deployment… und so weiter. Ich behaupte, dass ein Großteil der Unternehmenswebseiten auch gut mit einem Generator betrieben werden könnten.
Hey,
schöner Artikel zu Pico. Klingt sehr gut. Mich würde allerdings interessieren, ob sich signifikante Performance Vorteile ergeben beim Einsatz eines nicht Datenbank gesteuerten CMS. Oder generell, ob es eine Überlegung wert ist, auf die Art von CMS umzusteigen bei kleineren Kundenaufträgen. Die „Kostenvorteile“ dürften m.E. vernachlässigt werden, da bei fast allen Providern PHP auch mit einer Datenbank ausgeliefert wird.
@Jonathan
Danke für deinen Einwurf! Dieses Thema umfasst eigentlich einen ganzen Artikel, aber ich kann dir ein paar Denkanstöße geben:
* Performance: Zugriffe auf eine Datenbank entfallen natürlich, allerdings fehlt mir der Vergleich für High-Traffic Websites.
Ich bin bei dem Artikel eben von kleinen Webprojekten ausgegangen. Probleme mit Flat-Filebased-CMS bei großen Projekten kann ich mir folgende vorstellen:
* Sicherheit – man kann quasi erraten wo welcher Inhalt liegt (Stichwort Linkstruktur = Ordnerstruktur) weiters gibt es auch keine Sicherheit Features von Seitens der Datenbank.
* Handhabung – 3000 Files in 200 Ordnern für 3000 Artikel in ein paar Hauptkategorien und Subkategorien, nur so als Denkanstoß :)
* Keine Vorteile von relationalen Datenbanken!
Vorteile für kleine Projekte fallen mir aber auch einige ein:
* Dein lokales System ist quasi ident mit dem deiner Entwickler-Umgebung
* Keine Wartung von Datenbanken, Backup etc.
* Läuft quasi überall – einfach nur Webspace und es läuft
* Statische Dateien können ohne großen Aufwand geladen und angezeigt werden
* Einfache Installation da – wie gesagt – nur Webspace benötigt wird.
Ich würde diese Systeme eben nur für kleine Projekte benutzen. Ich hoffe die Antwort hilft dir weiter!
Danke, danke. Ich finde, einfache System werden viel zu wenig gefördert: Viele Webdesigner sind Junkies, welche für jedes Projekt zum CMS greifen, ohne dabei zu hinterfragen, ob es auch passendere Tools gibt (http://blog.rapsli.ch/posts/2013/2013-10-11-trend-zum-cms-minimalismus.html),
Dabei müssen sie sich in keiner Weise vor den grossen Platzhirschen verstecken: Es gibt eine whitehouse.gov Webseite, aber tausende kleine 10 Seiten Websites.
Und noch zu Performance. Bei High-Traffic Websites ist wahrscheinlich eh ein Varnish oder was ähnliches davor, sprich Daten werden aus dem Memory ausgeliefert, sprich Performance ist wahrscheinlich besser, aber eben… wieviel solcher High-Traffic Websites gibt’s?
@Jonathan,
NoDB ist halt gerade in Mode. Wenn beide Systeme (noDB und DB) gleich gut programmiert (nutzen Caching) sind, dann muessten sie bei gleicher Funktionaelitat ziemlich genau gleich schnell sein.
Keine Ahnung, was die Pico-Macher fuer ein Webspace haben, aber die schnellste Antwort-Zeit, die ich bisher bekommen habe, lag bei 116ms – was alles andere als ‚Blazing fast‘ ist.
Dass die Seite momentan sicher gut besucht ist, aendert daran nichts. Die 300-400ms Spruenge davon habe ich bereits ignoriert.
Da seh‘ ich also momentan absolut keine ’signifikante Performance Vorteile‘. Wird es auch nie geben, da Systeme mit vielen Features einfach auf Caching ausweichen koennen und dann wieder ziemlich schnell sind.
Zum Beispiel das full-featured CMS, das ich gerade entwickle: https://github.com/kryncms/Kryn.cms
Hat auf dem billigsten DomainFactory-Server 60ms Antwortzeit – doppelt so schnell als bei Pico’s momentanen Webspace. Lokal hat Kryn sogar nur 35-40ms. Das obwohl es deutlich ’schwerer‘ an Features ist. Nur als kleines Beispiel.
Dafuer hat Pico aber eben andere Vorteile fuer sehr kleine Webseiten oder eben fuer IT-Affine, die mit Markdown zurechtkommen und sich nicht scheuen fuer komplexeres eben selbst Hand anzulegen.
Es gibt schon seit Jahren gute Mini-CMS ohne MySQL. Ich verstehe nicht ganz, wieso das Rad immer wieder neu erfunden wird.