Funktionen, Module, Plugins, Templates, Lokalisierungen, Konfigurationsdateien; dies und mehr benötigt eine ausgewachsene Webanwendung, um einen größtmöglichen Funktions- und Konfigurationsumfang zu bieten. Sehr schnell entstehen auf diese Weise Anwendungsboliden, deren Umfang durchaus um ein Vielfaches größer sein kann, als die eigentlichen Inhalte, die von ihnen verwaltet werden sollen. So ist die deutsche Version des CMS- und Blogsystems WordPress beispielsweise bereits als Download-Paket ca. 3 MB groß (entpackt 9 MB mit 844 Dateien), während die in der Datenbank abgelegten, reinen Textinhalte eines Blogs lediglich wenige hundert Kilobyte wiegen, je nach Größe des Blogs.
Ein guter Ansatz, diesen Wust an Dateien etwas zusammenzustauchen, wurde von dem eher an fortgeschrittene Benutzer gerichteten Contentmanager sNewsCMS gewagt. Das System besteht im wesendlichen aus einer einzigen, ca. 150 KB großen Kerndatei, welche sämtliche Funktionen und Konfigurationen enthält. Weiterhin wird nur noch eine Designvorlage benötigt, um die Funktionen zur Inhaltsausgabe aufzurufen. Programmcode und Design sind hier also logisch voneinander getrennt. Der Vorteil besteht in der Übersichtlichkeit des Codes, man muss nicht in tiefen Verzeichnisbäumen wühlen, um eine Modifizierung anzubringen. Weniger komfortabel wird es allerdings, wenn es um die Einspielung von Sicherheits- und Stabilitätsupdates geht. Ein System wie sNews ist durch seine eher begrenzten Möglichkeiten dafür ausgelegt, als Grundlage für größere Webprojekte zu dienen, was die ein oder andere Modifizierung an der Kerndatei notwendig macht. Wird die Kerndatei nun aktualisiert, bleibt dem Webmaster nichts anderes übrig, als seine Modifizierungen erneut anzubringen oder sie falls möglich in eine andere Datei auszulagern, um die Arbeit nach jedem Update minimal zu halten. sNews ist also eher als Basis zu sehen und weniger als der Ansatz eines ultra sparsamen CMS.
Mittlerweile gibt es von sNews eine Abspaltung namens Redaxscript, welche das 1-Datei-Prinzip wieder etwas aufweicht und verschiedene Funktionen in einzelne Dateien auslagert und zudem das System um einige neue Funktionen erweitert. Dennoch ist die Größe des Systems im Vergleich zu anderen Systemen sehr gering gehalten.
Es geht aber noch eine Stufe kompakter: wer sich schon immer über die unverhältnismäßige Größe des vielfach bei Webhostern eingesetzten phpMyAdmin geärgert hat, sollte mal einen Blick auf die sehr viel kleinere, ihrem großen Vorbild jedoch in nichts nachstehende Alternative namens Adminer werfen. Das Script besteht aus einer einzigen, je nach Version zwischen 150 und 200 KB großen Datei, welche einfach nur auf den Webspace geladen und ausgeführt werden muss. Dabei kann sie beliebig umbenannt werden, um sie vor all zu neugierigen Augen zu schützen, obgleich eine Login-Abfrage natürlich integriert ist. Programmcode, Sprachdateien, ja selbst die Icons sind als Base64-Code im Script enthalten und passen in vergleichsweise wenige Kilobyte.
Ein Blick auf die Webseite im Bereich Sourcecode zeigt jedoch, dass es sich in Wirklichkeit ebenfalls um eine aus mehreren Dateien bestehende Webanwendung handelt. Der Endanwender erhält lediglich eine “kompilierte” Version, in der alle benötigten Dateien in einem nur schwer lesbaren Zeichensalat zusammengefügt wurden. Einfaches Prinzip, geniale Wirkung. Modifizierungen am Script sind hierbei aber nur schwer möglich, sodass es sich empfiehlt, diese Veränderungen in Plugins auszulagern, das Script als Quellcode zu betreiben oder es mit eigenen Veränderungen selbst zu kompilieren. Seinen Zweck erfüllt es allemal out-of-the-box und unterstützt sogar mehrere Datenbanksysteme, wovon man beim eher plumpen phpMyAdmin nur träumen kann.
Im Hinblick auf ausgewachsene Contentmanager ist es letztendlich natürlich schwer machbar, solche Systeme auf die sprichwörtliche Größe einer Haselnuss zu quetschen. Diese Systeme können und sollen so offen wie möglich bleiben, um dem Endanwender das beste Maß an Anpassungsmöglichkeiten zu bieten. Es ist außerdem wenig sinnvoll, eine Programmiersprache wie php zu entwickeln, wenn deren Möglichkeiten am Ende kaum ausgenutzt werden. Doch gerade am letztgenannten Beispiel zeigt sich, dass es auch Fälle gibt, in denen man nicht mit Kanonen auf Spatzen schießen muss, um an sein Ziel zu gelangen.
