WordPress ist ein sinnvolles System – f\u00fcr einen einfachen Blog. Auch dieser Blog hier beruht auf WordPress. Schnell sind Beitr\u00e4ge geschrieben und die Aufgaben erledigt, die bei einem Blog anfallen.<\/p>\n
Die Anforderungen professioneller Webseiten gehen \u00fcber die Anforderungen an einen Blog jedoch weit hinaus. Eine h\u00e4ufige Anforderung bei professionellen Webseiten ist, dass \u00c4nderungen vor einer Live-Schaltung einem geregelten Freigabeprozess unterliegen. Bevor also eine \u00c4nderung im CMS, Design, in Funktionalit\u00e4t und teilweise auch im Inhalt erfolgt, werden solche \u00c4nderungen intern \u00fcberpr\u00fcft und dann freigeschaltet. F\u00fcr inhaltliche \u00c4nderungen bietet WordPress die hierf\u00fcr notwendigen Funktionalit\u00e4ten in gewissem Umfang. Eine Umsetzung eines solchen Prozesses f\u00fcr \u00c4nderungen in der Funktionalit\u00e4t 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.<\/p>\n
Bevor ich auf die Probleme n\u00e4her eingehe, sei ein Vorteil von WordPress erw\u00e4hnt: 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\u00f6nnen daher in solchen Systemen h\u00e4ufig ohne vorherige Tests durchgef\u00fchrt werden. Nat\u00fcrlich muss man sich dar\u00fcber im Klaren sein, dass etwas schief gehen kann und man auf ein Backup, das ausdr\u00fccklich empfohlen wird, zur\u00fcckgreifen muss. Man muss sich auch dar\u00fcber im Klaren sein, dass in einem solchen Fall ein Ausfall des Blogs von ca. 1 Stunde, bei Problemen mit der R\u00fccksicherung auch l\u00e4nger, auftreten wird.<\/p>\n
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\u00fcr die Live-Version ein Name wie www.imagmbh.de oder imagmbh.de genutzt, f\u00fcr 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.<\/p>\n
Will man einen solchen, sicheren Weg mit WordPress gehen, so muss man beim Umschalten in die Datenbank gehen und in der Datenbank s\u00e4mtliche Eintr\u00e4ge, die den zwangsweise von WordPress eingetragenen Domainnamen enthalten, manuell \u00e4ndern – oder hierf\u00fcr ein Script schreiben.<\/p>\n
Einen noch absurderen Weg geht das Template „Divi“ f\u00fcr WordPress: Durch es werden nicht nur die Domainnamen eines jeden Links in der Datenbank abgelegt, es wird vielmehr auch die L\u00e4nge eines jeden Links codiert. Wenn also wie in unserem Beispiel die Testdom\u00e4ne „test1.imagmbh.de“ hei\u00dft und die Live-Dom\u00e4ne „www.imagmbh.de“, muss das L\u00e4ngenfeld generell um zwei gek\u00fcrzt werden. Hier kann man sich wirklich nur Fragen, was das soll. Falls hiermit eine Sicherheit gegen eine „zuf\u00e4lllige“ Ver\u00e4nderung eines Links gegeben werden soll, so w\u00e4re dieser Versuch jedenfalls unprofessionell umgesetzt. Denn um vor solchen Fehlern zu sch\u00fctzen, gibt es anerkannte Pr\u00fcfsummen- und Hashverfahren. So bleibt nur die sinnlose Mehrarbeit f\u00fcr Administratoren.<\/p>\n
Zuletzt kommen dann manche Programmierer auch noch auf die Idee, Links hardcodiert im eigenen Programmcode zu verewigen. Aber hierzu kein weiteres Wort.<\/p>\n
Doch ich m\u00f6chte 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\u00e4re es nat\u00fcrlich, diesen zur Laufzeit zu ermitteln, so sollte dies nur an genau einer Stelle geschehen. Und nat\u00fcrlich wird diese Stelle in der Dokumentation der Webseite, in der der Prozess eines Update beschrieben wird, aufgef\u00fchrt. Dieser Speicherort k\u00f6nnte 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\u00e4ndert wird.<\/p>\n
Wir bieten \u00fcbrigens an, Webseiten auf die Wartbarkeit hin zu \u00fcberpr\u00fcfen. Wenn Sie also eine Webseite neu erstellen lassen, \u00fcberpr\u00fcfen wir diese in Ihrem Auftrag im Hinblick auf die Wartbarkeit und die Professionalit\u00e4t bevor Sie diese abnehmen. So vermeiden Sie zuk\u00fcnftige, ausufernde Wartungskosten. Und nat\u00fcrlich unterst\u00fctzen wir Sie bei der Beauftragung von Webseitenentwicklungen. Denn wenn Sie die Anforderungen an die Professionalit\u00e4t nicht bei der Beauftragung genau spezifiziert haben, wird es sehr viel schwieriger, diese im Nachhinein zu verlangen. Sprechen Sie uns also m\u00f6glichst fr\u00fchzeitig an<\/a>.<\/p>\n <\/p>\n
\n