SF Ordnerplan als Content-Management-System für eine Website

Die Historie dieser Website

Diese Website, www.ct-systeme.com, entstand in den 1990er Jahren im längst vergessenen Microsoft FrontPage. Danach folgte die Umsetzung als anonym erreichbare Seite eines Microsoft SharePoint Servers. Das hatte den Charm, dass z.B. die Liste der Neuerungen in einem Programm ab einem bestimmten Programmstand einfach nur eine SharePoint-Liste war. Die konnte auf der Produkt-Homepage in einer Ansicht gezeigt werden, die nur die jüngste Neuerung zeigte, dieselbe Liste konnte aber auch auf der Neuerungen-Seite vollständig gezeigt werden - ohne dass man an zwei Stellen pflegen musste.

Allerdings ist SharePoint schon lange nicht mehr für anonym erreichbare Websites gedacht, und es funktionierte dafür auch immer schlechter (um nicht zu sagen, es war nervig). Was also tun? Wir wollten immer noch gerne die Vorteile von SharePoint haben, aber die noch verbessert, und natürlich ohne die Nachteile. Das leistet auch ein klassisches Website-Tool eher nicht.

Da wir z.B. die ganzen Produkte eh schon in unserem SF Ordnerplan hatten, exportierten wir so viel Content wie möglich maschinell aus SharePoint und importierten es in Ordnerplan-Vorgänge und Stammdatenobjekte, die jetzt leicht zu pflegen sind.

Wie ist diese Website "gemacht"?

Vorgänge mit Kurztext, Inhalt, Bildern und Downloads

Wir haben drei Prozesse in unserer SF Ordnerplan-Installation unterhalb von 2.9 Website definiert:

• 2.9.01 Homepage: Die Root-Homepage von www.ct-systeme.com. In diesem Prozess soll es nur einen Vorgang geben, der Untervorgänge hat.
• 2.9.02 Produkt-Homepage: Die Homepage eines SF-Produkts.
• 2.9.03 Website-Artikel: Ein Website-Artikel mit oder ohne Bezug zu einem SF-Produkt.

Der Fließtext ist ein Feld vom Typ Formatiertes Memo in SF Ordnerplan, in dem wir also Überschriften, Aufzählungen etc. leicht editieren können. SF Ordnerplan speichert formatierten Text intern automatisch sowohl im Richt-Text-Format (RTF) als auch in HTML - letzteres nutzen wir für die Website aus.

Die Seite, die Sie hier gerade lesen, ist z.B. dieser Vorgang:

Die Hierarchie der Webseiten ist dadurch gegeben, dass ein Webseiten-Vorgang ein Untervorgang der übergeordneten Seite ist - bis zur Homepage.

Bilder

Das obige Bild entstammt dem folgenden Stammdaten-Objekt, in das einfach ein Screenshot eingefügt wurde, und das dem Vorgang im dafür vorgesehenen Feld Bilder hinzugefügt ist:

Der Vorgang weiß also, welche Bilder es geben soll, und im Text sind einfach die Objektbezeichnungen der Bild-Objekte in geschweiften Klammern eingefügt. Das geht sehr flott von der Hand und klingt wahrscheinlich nur viel komplizierter, als es ist. Tatsächlich geht das Aufnehmen eines Bildes in eine Website damit deutlich schneller und angenehmer, als es noch in SharePoint der Fall war.

Die Icons für die SF-Produkte hatten wir eh schon beim Produkt hinterlegt. Wenn eine Webseite, die nicht zu einem Produkt gehört (z.B. das Impressum), auch ein "Icon" haben soll, ist das ebenfalls einfach als Bild-Objekt dem jeweiligen Vorgang zugeordnet.

Downloads

Dateien, die wir auf einer Seite zum Download anbieten, sind

• Dokumente im Vorgangsordner der jeweiligen Webseite (z.B. die SF Ordnerplan-Trainingsunterlagen) sowie
• dem Vorgang zugeordnete Stammdatenobjekte, wie z.B. dieses:

Wie kann man sich die Struktur vorstellen?

Ganz einfach - lassen wir doch in SF Ordnerplan ein Zusammenhang-Diagramm anzeigen, z.B. vom Vorgang dieses Beitrags aus, den Sie gerade lesen:

Was sehen wir da?

• Gelb hinterlegt ist der Vorgang, von dem wir ausgegangen sind - dieser Webseiten-Beitrag also.
• Das ist ein Untervorgang von Faszinierendes, was zur Homepage von SF Ordnerplan gehört, die zu den Infrastruktur-Lösungen zählt, die von der Homepage aus erreicht werden können - vergleichen Sie das "Breadcrump", die "Brotkrümel" ganz oben auf dieser Seite.
• Zu den Vorgängen gehören verschiedene Bilder und/oder Downloads. Dasselbe Bild und derselbe Download können also auch leicht an mehreren Seiten auftreten.

Genauso einfach kann man natürlich auch die gesamte Website-Struktur mit ihren aktuell ca. 90 Seiten darstellen, hineinzoomen und direkt Dinge bearbeiten:

Wie entsteht daraus eine Website auf dem Webserver?

Wir haben auf einem Webserver tatsächlich zwei Websites angelegt: Eine für den "Staging"-Bereich, in dem wir Änderungen schreiben lassen und erst prüfen können. Wenn alles gut ist, wird das auf die tatsächlich anonym und öffentlich erreichbare Website übertragen.

Zur Erstellung all der html-Seiten und der richtigen Speicherung der zugehörigen Bilder und Downloads nutzen wir die PowerShell-Schnittstelle von SF Ordnerplan. Damit ist es ein Leichtes, all die Vorgänge, Neuerungs-Listen von SF-Produkten, Bilder und Downloads zu lesen und ganz simples, statisches html daraus zu machen.

Wir rufen also ein PowerShell-Script namens Publish-SFGmbhHomepage.ps1 auf, dass die Website im Test-Bereich ("Staging") erstellt, incl. einiger einfach hineinkopierter Dateien wie z.B. die styles.css mit den Formatierungsangaben.. Mit -Force als Parameter erstellt das Script auch gleich die öffentliche Website. Das sieht dann so aus:

Das Erstellen der vollständigen Webseite auf diesem Wege dauert eine Minute und ein paar Sekunden.

Welche Vorteile haben wir dadurch?

Eine ganze Reihe:

• Wir brauchen den dicken SharePoint-Server nicht mehr dafür, ihn nicht mehr zu warten (SharePoint-Sicherheitsupdates müssen monatlich manuell installiert werden) und uns nicht mehr plagen (mittlerweile war es jeden Monat wieder Arbeit, nach den Sicherheitsupdates die öffentliche Website wieder anonym erreichbar zu machen).
• Wir können die Pflege des Website-Inhalts sehr komfortabel in SF Ordnerplan erledigen - dem System, in dem wir ja eh den ganzen Tag arbeiten und "alles" erledigen.
• Wir genießen all die ausgereiften Features von SF Ordnerplan, etwa die Änderungsprotokollierung, die grafischen Darstellungen oder auch die Ad-hoc-Abfragen ("Zu welchen SF-Produkten gibt es noch keine Homepage auf der Website?").
• Die resultierende Website ist "primitives" statisches html.
• Der Webserver braucht nichts anderes zu können, als statische Dateien anonym auszuliefern. Die Angriffsfläche für Hacker ist - anders als bei SharePoint oder einem anderen direkt auf Datenbanken zugreifenden Content-Management-System (CMS) - fast Null.
• Es ist einfach, im PowerShell-Script z.B. auf der Homepage die "Jüngsten 5 Beiträge" aufzulisten, die "Sitemap" zu generieren (siehe den Link am Ende dieser Seite) und dergleichen mehr.
• Wenn wir Screenshots einfach per Druck oder Alt+Druck (kopiert nur das aktuelle Fenster) in ein Website-Bild-Objekt einfügen, landet das dort im BMP-Dateiformat. Das PowerShell-Script ändert noch als BMP vorliegende Bilder automatisch ins viel platzsparendere und damit im Browser schneller ladbare PNG-Format, und es schreibt das zurück ins Stammdatenobjekt, braucht das Bild also nur einmal zu wandeln.
• Die getrennten Webseiten für Test und Öffentlichkeit sind ganz einfach zu handhaben.

Warum verwenden wir nicht einfach ein existierendes CMS?

Es gibt viele Lösungen für Websites, eben die sogenannten Content-Management-Systeme, die wir durchaus in Erwägung zogen. Warum also eine eigene Lösung dafür bauen und das Rad neu erfinden?

• Die Angaben über die SF-Produkte wie Name, Kurzbeschreibung und Icon haben wir eh schon in SF Ordnerplan. Da lag es nahe, die Webseite selbst auch darin zu definieren.
• Wir brauchen kein aufwändiges (und evtl. teures) CMS zu installieren, zu warten oder bei einem externen Hoster zu mieten.
• Auf dem Webserver ist die Angriffsfläche für Angreifer fast Null, weil der so konfiguriert ist, dass er nur noch statische Dateien anonym ausliefern kann. Da läuft nichts Aktives, kein Datenbankzugriff, nichts.
• Deshalb laden die Webseiten im Browser auch fantastisch schnell, auch auf Smartphones im Funknetz.
• Inhalte zu pflegen, z.B. diesen Beitrag zu schreiben, ist ganz einfach und robust, und geschieht in einer gewohnten und leicht zu beherrschenden Umgebung.
• Wir brauchen überhaupt keine Cookies. Irgendwelche Tracking-Dienste verabscheuen wir sowieso, aber auch für die Funktionalität der Website sind keinerlei Cookies notwendig. Wir brauchen Ihnen also auch nicht mit den verhassten "Cookie-Bannern" auf die Nerven zu gehen - oder wollte die etwa jemand?
• Wenn die Website grundsätzlich anders erscheinen soll, ändern wir das PowerShell-Script nach Belieben und lassen die Site einfach neu erzeugen. So hatten wir z.B. anfangs die Downloads zu SF-Produkten als dritte Spalte der Produkt-Homepage dargestellt, das aber später so geändert, dass die - überall einheitlich - unterhalb der "Weiteren Informationen" stehen und nur die "Jüngste Neuerung" in einer separaten Spalte landet.
• Herausforderungen reizen uns. Dieses interne Projekt hat jede Menge Spaß gemacht. Noch mehr Spaß macht es jetzt, neue Inhalte hinzuzufügen.

Voilà.