Quo vadis, WebsiteBaker?

Ich mache schon ziemlich lange Webdesign, und immer noch häufig statische Seiten. Das hat einige Vorteile: Ich bin völlig frei, was das Design betrifft. Ein CMS schert letztlich alles über den selben Kamm und alle Seiten sehen irgendwie gleich aus. Statische Seiten habe ich völlig im Griff – soweit HTML das überhaupt zulässt. Fragen wie: Wie realisiere ich, dass diese eine Seite ein anderes Hintergrundbild hat als die anderen? – pah! – ein Klacks. Mit einem CMS ist das gar nicht so einfach.

Das Schöne an WebsiteBaker ist: auf diese Vorzüge von statischen Seiten muss ich nicht unbedingt verzichten, kann aber trotzdem die Vorzüge nutzen, die ein CMS mir und meinen Kunden bringt: Trennung von Inhalt, Design und Funktion, mehrere Benutzer und Gruppen, von jedem Computer aus bearbeitbar. Und vieles andere.

Mit WebsiteBaker lassen sich sehr elegant und ohne Verrenkungen die geilsten Sachen fabrizieren, vor allem auf Grund der logischen Struktur und dem Umstand, dass ich direkt im Template mit PHP arbeiten kann. Dadurch muss ich nicht in WB-Dateien herumbasteln (und bei jedem Update zittern); die speziellen Eigenheiten einer Website sind dort, wo sie hingehören: Im Template. Dort ist Design und Funktion der Website definiert. Nicht im Inhalt der Site – und nicht im CMS. Alles beieinander und nicht zerlegt in Hunderte kleine Fragmente.

Das macht Freude.

Und das macht weniger Freunde:

Die Trennung von Inhalt, Design und Funktion ist bei WebsiteBaker nicht immer durchgängig. Das betrifft vor allem die Modul-Optionen, die in den Standardeinstellungen oft kaum brauchbar sind und deswegen meist willkürlich geändert werden. Dadurch verliert sich jeder Standard.

Ein verwandtes Ärgernis sind die generell fehlenden Vorgaben zur einheitlichen Verwendung von HTML-Tags und CSS. Das eine Template kennt nur eine einzige H1 – und zwar im Header des Templates, das andere verwendet wiederum strenge w3c-Standards. Dadurch ist es kaum möglich, Templates zu beurteilen – man müsste erst einmal die eigene Site ummodeln. In Verbindung mit weiteren fehlenden Standards – etwa welche CSS-Klassen zB im Gästebuch verwendet werden sollen, kann der Wechsel eines Templates zum aufwändigen "Redesign" werden.

Zur Klarstellung: Ein starres Teil wie zb das Blog "Wordpress" hat mit solchen Problemen natürlich nicht zu kämpfen. Hier sind die Standards klar und fix. Aber Wordpress ist ein Blog und wird nie und nimmer ein CMS. Bestenfalls zu einem Blog, das mit 200 Erweiterungen wie ein CMS auf Wordpress-Basis aussieht.
Die geliebte Freiheit beim Umgang mit WebsiteBaker hat eben ihren Preis.

Flucht nach vorne – oder nach hinten?

Es wird gemunkelt, dass WebsiteBaker 3 mit WebsiteBaker 2.X nicht viel zu tun hat. Vor allem die Template-Engine Smarty stösst vielen sauer auf: "Warum soll ich eine Pseudo-Sprache lernen, wenn ich das mit PHP genauso gut direkt machen kann?"

Kann sein, dass genau das obige erwähnte Problem der Vater des Gedankens ist: Neustart.
Kann aber auch sein, dass einige das grausliche Wort "Fork" in den Mund nehmen und auf Basis von WebsiteBaker 2.X ein neues CMS entwickeln: Aber ohne die alten Probleme mitzunehmen.
Kann aber auch sein, dass das einige schon gemacht haben und gar nicht groß darüber geredet haben.

Comments

Add Comment

Horizontale Einseiten-Site

Mach sowas mal mit Joomla - oder gar Wordpress... Geht gar nicht! Genau das mag ich an WebsiteBaker: Mit ein bisschen PHP im Template ist fast alles machbar. Und das, ohne in den Core einzugreifen. Im Backend ist "Rooms" eine ganz normale Site.

Variable Templates

Oder Sites, die - je nach Fall - mal so oder mal so aussehen?

Keine Website ist wie die andere, jede braucht eine individuelle Lösung. Und das geht mit WebsiteBaker auch.