Das ist ein uralter Draft, den ich im letzten März geschrieben habe. Er beschreibt das, was im Projekt CMS zusammengefasst werden soll. In der Zwischenzeit wurde dieses CMS von mir kritisiert und der Aufbau wird noch einmal durchdacht. Aber ich will den Einblick nicht verwähren, wie ich damals argumentierte und wie der alte Aufbau ausgesehen hat. Wen es interessiert, kann es lesen

Jeder PHP-Entwickler entwickelt bei einer Homepage – die nicht auf “fremder” Software basiert – ein eigenes System, das er meist auch bei anderen Webseiten einbaut und ausbaut. Auch ich habe mein eigenes System, allerdings kann ich nicht mit Sicherheit sagen, dass es dem Begriff CMS gleicht. Eigentlich steht nicht der Inhalt im Vordergrund, sondern es sollte eine Plattform für Programmierer sein. So ist es zumindest bei mir der Fall. Im Folgenden beziehe ich mich also auf die Projekte BRG_HP, MyHP und lowk-spotting.at dessen Merkmale ich im Folgenden analysiere.

• Konfiguration Von entscheidender Bedeutung ist die Konfiguration. Ich schreibe vieles in Variablen wie zB den Titel (<title>) der Seite. Inhalte die sich kurzfristig ändern können, werden genauso zentral definiert, damit ein schneller Zugriff mit minimalem Aufwand möglich.
• (X)HTML und CSS Von der zuerst genannten Regel schließe ich HTML und CSS aus. Grundlegend schreibe ich in keine Variable wie breit die Tabelle xy ist. Da ich (X)HTML und CSS für “nicht ausgereift” halte, muss ich oft die eine Tabelle breiter machen, als die zweite, weil sie einen anderen Inhalt hat, deshalb ist ein zentrale Verwaltung unmöglich (besonders proj:lowk-spotting.at).
• central/ Ein Ordner existiert immer in dem die zentrale Verwaltung stattfindet. Eine MySQL-Verbindung wird aufgebaut, Konfigurationsvariablen zur Verfügung gestellt und die meta-Angaben und das Menü stehen auch nur in einer einzelnen Datei. Aktionen, die sich zumindest 2mal wiederholen und einen aufwändigeren Quelltext enthalten, sind zentral definiert und im Ordner central/ zu finden. Das ermöglicht eine einfache Fehlersuche, falls zB eine MySQL-Verbindung nicht mehr möglich ist. Dann ist der Fehler ist der Fehler in nur einem Ordner (central/) zu finden, in dem sich nur wenig Dateien befinden.
• Ordnung Außerdem muss meine Webseite über eine klare Ordnerstruktur verfügen:
  • root/: Hier befinden sich alle Dateien auf die der User direkt zugreift. Das Verzeichnis enthält alle – im Folgenden genannten – Unterordner. Der Rest der Dateien wird mit require() oder include() eingebunden.
  • bilder/: Dieses Verzeichnis verfügt über alle Bilder, die nicht für das Design der Webseite benötigt werden, sondern nur in einzelnen Dateien und eine hohe Dateigröße aufweisen. Die Bilder sind nicht dokumentiert (der Name ist nicht in Vars definiert – siehe “Doku”).
  • icons/: im Ordner Icons sind alle Graphiken gespeichert, die für das Design verwendet werden. Meist verwende ich hierfür gifs oder pngs. Soll Transparenz im Design enthalten sein, verwende ich natürlich pngs (beachte IE6!). Meist ist es so, dass in bilder/ nur jpegs sind und in /icons nur pngs.
  • central/: Dieser Ordner wurde oben erwähnt. In ihm liegen alle Dateien, die zu 90% in jeder Webseite mitwirken. Eine besondere Datei ist die unten erwähnte hp.php.
  • +workout/ und design/: Diese Ordner kommen nicht auf den Server. In ihm kommen veralterte Dateien und Tests für das Design.

  Diese Ordnerstruktur ist für mich typisch und unverzichtbar. Für mich hat sich diese Struktur sehr bewährt.

• hp.php
  Die hp.php ist so etwas wie eine globale Konfigurationsdatei. In ihr werden allgemeine Variablen, MySQL-Passwort und die Pfade zu den einzelnen Dateien definiert. Ebenso wird das Framework in ihr geladen, der HTTP-Header gesandt und evtl. die meta-menü-Angaben geladen. Sie übernimmt auch alle Aufgaben, die vor dem Senden der Datei ablaufen müssen (Error-Weiterleitung, Variablenausgabe).

Die Namen der Verzeichnisse können in den einzelnen Projekten variieren.

Ich erwähnte bereits den Kampf zwischen Wirtschaftlichkeit und Ideologie. Wie sollte man handelt, wenn W3C-Kompatibilität und Wirtschaftlichkeit in Konflikt stehen?

Prinzipiell: Bei Webseiten versuche ich den folgenden Grundsätzen zu folgen:

1. One page, one job
2. Strikte Trennung zwischen HTML, CSS, JS, PHP, TEMPLATES und CONF
3. Dynamik
4. Überprüfen von Zuständen, die normalerweise nicht auftreten (gutes Error-Management)
5. KISS
6. Kompatibilität mit großer Anzahl von Browsern (IE, FF, Opera, Konqueror, Chrome, Safari, Lynx, etc.)

Im Punkt #5 steht auch wieso ich gegen PHP-OOP bei durchschnittlichen Webseiten bin: OOP kann eine Seite verdammt unübersichtlich machen. Vor allem wenn es schlecht dokumentiert, wenn die Objekte eine starke Abhängigkeit voneinander haben oder es natürlich schlecht programmiert ist. Bei kleinen Webseite bin ich weiterhin gegen OOP (PS: python-OOP finde ich schöner als PHP-OOP)!

Jetzt aber zur eigentlichen Frage: Was ist, wenn sich X und Y ausschließen? Wie geht man damit um? Ich habe für mich die folgende Liste geschrieben. Die #1 hat die höchste Priorität und muss überall gewährleistet sein. Mit “Ideologie” versuche ich bis zur #7 alle Punkte zu erfüllen.

1. Hauptsache, es funktioniert (Browserkompatibilität)
2. Sicherheit
3. SEO (Google)
4. W3C-Kompatibilität
5. Quelltext übersichtlich (clientseitig sowie serverseitig)
6. Quelltext kommentieren (serverseitig)
7. Laufzeit Optimierung

Was ich auch immer machen wollte, aber immer vergaß: Log-Datei für Systemfehler. zB “08.11.01 date.php konnte smileys.php nicht öffnen”