WordPress ist ein sinnvolles System – für einen einfachen Blog. Auch dieser Blog hier beruht auf WordPress. Schnell sind Beiträge geschrieben und die Aufgaben erledigt, die bei einem Blog anfallen.
Die Anforderungen professioneller Webseiten gehen über die Anforderungen an einen Blog jedoch weit hinaus. Eine häufige Anforderung bei professionellen Webseiten ist, dass Änderungen vor einer Live-Schaltung einem geregelten Freigabeprozess unterliegen. Bevor also eine Änderung im CMS, Design, in Funktionalität und teilweise auch im Inhalt erfolgt, werden solche Änderungen intern überprüft und dann freigeschaltet. Für inhaltliche Änderungen bietet WordPress die hierfür notwendigen Funktionalitäten in gewissem Umfang. Eine Umsetzung eines solchen Prozesses für Änderungen in der Funktionalität oder im Design wird von WordPress jedoch sehr erschwert – und hierin unterscheidet sich WordPress von anderen Systemen, die von vornherein auf einen permanenten Entwicklungsprozess der Webseite angelegt sind.
Bevor ich auf die Probleme näher eingehe, sei ein Vorteil von WordPress erwähnt: Solange man keine komplexen eigenen Anpassungen gemacht hat, also das WordPress-System – bis auf Standarddesignanpassungen – im Standardzustand betreibt, klappen Updates normalerweise schnell und problemlos. Updates können daher in solchen Systemen häufig ohne vorherige Tests durchgeführt werden. Natürlich muss man sich darüber im Klaren sein, dass etwas schief gehen kann und man auf ein Backup, das ausdrücklich empfohlen wird, zurückgreifen muss. Man muss sich auch darüber im Klaren sein, dass in einem solchen Fall ein Ausfall des Blogs von ca. 1 Stunde, bei Problemen mit der Rücksicherung auch länger, auftreten wird.
Professionelle Webseiten werden dieses Risiko nicht eingehen und Systemupdates, vor allem aber auch eigene Updates vor der Live-Schaltung vorher, wie oben beschrieben, testen. Und hier ist legt WordPress den Administratoren Steine in den Weg: WordPress verwaltet sehr viele Informationen der Webseite in der genutzten Datenbank und legt hier den Domainnamen in den Informationen an mannigfaltigen Stellen mit ab. Testversionen von Webseiten unterscheiden sich von den Live-Versionen jedoch gerade im Domainnamen. Z.B. wird für die Live-Version ein Name wie www.imagmbh.de oder imagmbh.de genutzt, für die Testversion dann test1.imagmbh.de. War ein Test erfolgreich, wird die Testversion „scharf geschaltet“ und ist unter dem echten Domainnamen www.imagmbh.de erreichbar.
Will man einen solchen, sicheren Weg mit WordPress gehen, so muss man beim Umschalten in die Datenbank gehen und in der Datenbank sämtliche Einträge, die den zwangsweise von WordPress eingetragenen Domainnamen enthalten, manuell ändern – oder hierfür ein Script schreiben.
Einen noch absurderen Weg geht das Template „Divi“ für WordPress: Durch es werden nicht nur die Domainnamen eines jeden Links in der Datenbank abgelegt, es wird vielmehr auch die Länge eines jeden Links codiert. Wenn also wie in unserem Beispiel die Testdomäne „test1.imagmbh.de“ heißt und die Live-Domäne „www.imagmbh.de“, muss das Längenfeld generell um zwei gekürzt werden. Hier kann man sich wirklich nur Fragen, was das soll. Falls hiermit eine Sicherheit gegen eine „zufälllige“ Veränderung eines Links gegeben werden soll, so wäre dieser Versuch jedenfalls unprofessionell umgesetzt. Denn um vor solchen Fehlern zu schützen, gibt es anerkannte Prüfsummen- und Hashverfahren. So bleibt nur die sinnlose Mehrarbeit für Administratoren.
Zuletzt kommen dann manche Programmierer auch noch auf die Idee, Links hardcodiert im eigenen Programmcode zu verewigen. Aber hierzu kein weiteres Wort.
Doch ich möchte hier nicht nur klagen, sondern auch beschreiben, wie es professionell gemacht werden kann: Generell gilt, dass man Redundanzen jeglicher Art vermeiden sollte. Wenn also der Domainnamen gespeichert werden muss, eleganter wäre es natürlich, diesen zur Laufzeit zu ermitteln, so sollte dies nur an genau einer Stelle geschehen. Und natürlich wird diese Stelle in der Dokumentation der Webseite, in der der Prozess eines Update beschrieben wird, aufgeführt. Dieser Speicherort könnte sowohl in einer Konfigurationsdatei, als auch in der der Datenbank sein. Meines Erachtens nach ist eine Ablage in einer Text-Konfigurationsdatei zu bevorzugen, da diese von einem Administrator im Allgemeinen leichter angepasst werden kann, als ein Datenbankeintrag, insbesondere dann, wenn bei einer Live-Schaltung auch die Datenbank geändert wird.
Wir bieten übrigens an, Webseiten auf die Wartbarkeit hin zu überprüfen. Wenn Sie also eine Webseite neu erstellen lassen, überprüfen wir diese in Ihrem Auftrag im Hinblick auf die Wartbarkeit und die Professionalität bevor Sie diese abnehmen. So vermeiden Sie zukünftige, ausufernde Wartungskosten. Und natürlich unterstützen wir Sie bei der Beauftragung von Webseitenentwicklungen. Denn wenn Sie die Anforderungen an die Professionalität nicht bei der Beauftragung genau spezifiziert haben, wird es sehr viel schwieriger, diese im Nachhinein zu verlangen. Sprechen Sie uns also möglichst frühzeitig an.