Sie werden immer den Fall haben, dass Sie einen bestimmten Wunsch haben, welcher mit einem CMS / Framework in der Basiskonfiguration NICHT realisiert werden kann. Wie erläutern  Ihnen, was Sie dann tun könnten oder lassen sollten.

Es gibt mehrere Varianten, für die man sich entscheiden kann, wenn man eine bestimmte Funktionalität nicht findet. Die Grundsatzfragen ist und bleibt aber immer die selbe: Sind Sie wirklich sicher, dass Sie dieses Feature benötigen? Sind Sie sicher, dass Sie hierfür eine Investition tätigen wollen?

Variante 1: Verzicht

Unsere Daumenstatistik besagt, dass 90% aller Wünsche oder Zusatzwünsche an dem Punkt einen kurzen Tod sterben, an dem wir nur eine Aufwandsschätzung einreichen und/oder Ihnen einen Kurzeinblick in das Thema IT-Sicherheit verpassen. Viele Wünschen entstanden aus der Inspiration bei Webseiten Dritter; das ist auch gut und richtig so, nur muss man eben verstehen, dass es über 100 gängige Redaktionssysteme am Markt gibt, von denen 80% sich vermutlich auf immerhin 10 typische CMS aufteilen lassen. Doch auch dann, wenn für ein CMS eine Erweiterung einmal möglich war, so gilt diese Option oftmals nur bestimmte Versionen oder Konstellationen, dh. die Erweiterung eines Systems um ein zusätzliches Feature führt oftmals dazu, dass etwas anderes plötzlich nicht mehr funktioniert. Die Argumentationslinie "die anderen haben das aber doch auch" ist zwar naheliegend, führt aber nicht immer zum Ziel, denn ein ganz maßgebender Aspekt ist mitunter die IT-Sicherheit. Ein Verzicht auf Features oder die Umsetzung von Wünschen ist stets eine Option.

Variante 2: Zusätzliche individuelle Programmierung oder Konfiguration einer Erweiterung von STUELKEN.

Ob zusätzliche Menü-Variante zur Navigation, schönerer Kontaktformulare oder kleinere Animationseffekte, bei welchen irgendetwas auf- und zuklappt: Viele kleine Dinge, die ein Redaktionssystem in der Standardinstallation nicht sofort bieten kann, lassen sich durchaus mit zusätzlicher Programmierung in PHP oder JavaScript ergänzen. Obwohl allerdings durchaus das eine oder andere machbar wäre, scheitern viele Wünsche gerade im unteren Drittel des Preissegments am Wunsch, tatsächlich eine Finanzierung zu tätigen. Wer sich darüber ärgert, dass mancheine Agentur nicht einmal mehr den Preis für eine mögliche Erweiterung ermittelt oder Erweiterungen von Beginn an konsequent ablehnt, sollte wissen, dass die eigentliche Programmierung insbesondere bei Kleinigkeiten das geringste Problem ist: Was man auch angeht, es dauert fast immer mindestens 2 Stunden.

In Zahlen: Was man auch immer individuell "mal eben in 15 bis 30 Minuten" programmieren könnte, erfordert fast immer mindestens 15 bis 30 Minuten Diskussion und Abstimmung, 15 bis 30 Minuten Konzeption, 15 bis 30 Minuten Programmierung und 15 bis 30 Minuten Tests nebst 15 bis 30 Minuten Übergabe und Kurzeinweisung. Selbst wenn alles ohne Probleme durchläuft sprechen wir von 5 Einheiten à 15 bis 30 Minuten, dh. mind. 5 bis 10 Zeiteinheiten à 15 Min. und/oder 1,25 bis 2,50 Stunden. Die Praxis zeigt, dass es deshalb selbst für Kleinigkeiten im Grunde nur Aufwandswerte ab 2 Stunden gibt, manche Sonderwünsche aber auch durchaus mal einen Entwickler 2 Tage oder auch eine Woche zeitlich binden können. 

Variante 3: Installation einer gängigen, aktuellen Erweiterung von Drittentwicklern der Open-Source-Community

Es gibt durchaus Erweiterungen für Redaktionssysteme welche konsequent mit dem Redaktionssystem aktualisiert werden, wenn auch durch einen Drittentwickler unabhängig vom Kernentwicklerteam des Redaktionssystems. In diesen Fällen kann eine Installation dieses Features durchaus eine Option sein. Man sollte sich nur bewusst werden, dass die Dokumentation dieser Erweiterungen bei manchen Redaktionssystemen und Dritt-Lösungen sehr spartanisch, schlecht bis hoffnunglos veraltet ist. Das führt dazu, dass mancheine Erweiterung, die man vor 2 Jahren noch mit 2 Klicks installieren konnte, erst in Verbindung mit zig Recherchen im Internet und ein paar Workarounds lauffähig wird, und nicht zuletzt müssen mitunter noch andere Erweiterungen installiert werden, von denen diese Erweiterung abhängig ist, ob man denn will oder nicht. Erweiterungen sind von Drittentwicklern, welche oftmals niemand wirklich kennt, und niemand kann abschätzen, wie lange diese Erweiterung noch unterstützt werden und/oder kompatibel sein wird.

Variante 4: Wechsel des Reaktionssystems

Dieser Fall ist so einschneidend, dass wir dem eine eigene Diskussion gewidmet haben.

Variante 5: Eigenprogrammierung einer Software

Keine Sache von 5 Minuten, aber manche Dinge kann man tatsächlich in 1, 2 oder 3 Tagen durchaus soweit programmieren, dass man für viele Dinge gar kein CMS mehr benötigt. Eine Eigenentwicklung ist also stets eine Option.

Diskussion

Es ist kein Geheimnis: Webseiten und damit Internetauftritte können durchaus sehr einfach sein, viele werden aber technisch schon seit über 10 Jahren über serverseitige und clientseitige Skript- und Programmiersprachen technisch umgesetzt. Webseiten sind damit schon lange nicht mehr statische angehübschte HTML-Dateien Online-Dokumente sondern längst Programme oder webbasierte Softwarelösungen.

Mancheine HTML-Seite in den 90er Jahren konnte man bequem in 100 Zeilen HTML programmieren, und im Grunde genommen würde ohne Redaktionssysteme das bei manchen Webseiten auch heute noch möglich sein. Die technisch Entwicklung ging aber weiter, und mit der Entwicklung entstanden auch immer neue Möglichkeiten, neue Wünsche, neue Lösungen. So verschiedenen Wünsche und damit die Lösungen sind, so unterschiedlich ist auch die Länge oder auch die Komplexität des Quellcodes oder der Systemarchitektur der Webseite.

Heute hat allein die Designtemplate für das Templatesysteme in der Summe schnell mehr als 20.000 Zeilen Quellcode für Mastertemplates, Subtemplates, Content Templates und damit Stylesheets und Skripts.

Übrigens: Im Falle eines Änderungswunsches kommt zunehmend darauf an, wer diese Designtemplate eigentlich entwickelt hat, denn um zuweilen 20.000 Zeilen Quellcode zu sichten oder zu verstehen, den möglicherweise Ihr Designer nicht entwickelt sondern bei sehr günstigen Lösungen (oder Wordpress?) nur irgendwo "gesaugt" hat, benötigt man (a) Zeit und (b) plötzlich ein Verständnis für Quellcode der entsprechenden Skript- und Programmiersprachen, den man beim einfachen Installieren nicht benötigte.