Schon seit einer ganzen Weile arbeite ich an „PF-BITS 2.0“, einem Relaunch meines Lokalblog-Projekts. Was sich ganz einfach anhört, ist so komplex, dass sogar ich Respekt davor habe. Zwar bin ich kein Anhänger von „Spaghetticode“, bastle also nicht ständig irgendwelche Dinge hier und da hinein, aber dennoch gibt es einige Dinge zu berücksichtigen. Und das sind so wichtige Dinge, dass der Relaunch Schritt für Schritt geplant werden muss. Ein kleiner Bericht aus dem Maschinenraum:
Weg von Multisite
PF-BITS läuft auf einer WordPress-Multisite-Umgebung. Das war 2016 noch eine praktische Lösung, weil ich so mit der Mittagstisch-Plattform – die auf einer eigenen Instanz läuft – beginnen konnte. Alles schön getrennt, aber alle Instanzen teilen sich das einheitliche Theme und selektiv auch die Plugins.
Was zu Beginn noch ganz praktisch war, wurde immer komplexer. Zum einen gibt es Änderungen am Theme, die ich mit einem Child-Theme auffangen musste. Und da dann immer mehr Templates einrichten musste, um Individualitäten abzubilden. Schon das war müßig.
Dazu kam dann allerdings, dass WordPress in Sachen Multisite im Laufe der Jahre immer restriktiver in Sachen Sicherheit wurde. Konnte ich zu Beginn noch Ressourcen ganz lässig zwischen den Instanzen teilen, so ist dies aus Sicherheitsgründen nur noch für den Superadmin möglich. Und den will ich nun nicht wirklich ständig im Einsatz haben, um Programmcode ablaufen zu lassen.
Erste Instanz: Die Job-Plattform
Diese Instanz ist die dritte und letzte Instanz gewesen. Da diese mit einem fertigen Plugin läuft, war diese Instanz relativ einfach in die Hauptinstanz zu migrieren: Alle Inhalte exportieren, das Plugin in der Hauptinstanz aktivieren und alle Inhalte wieder importieren. Angepasst werden mussten lediglich die Ordnerstrukturen, was überschaubar ist. Und auch die Verbindung zur Jobplattform von Google – sehr zickig, wenn die Inhalte zu anderen Adressen umziehen – lässt sich einfach ummodeln.
Dieser Job war an einem Tag zu erledigen und konnte auch live am Produktivsystem durchgeführt werden. Und schon sind aus drei Instanzen nur noch zwei geworden. Wenn alles nur so einfach wäre!
Zweite Instanz: Die Mittagstisch-Plattform
Bei dieser Instanz, es war ursprünglich die zweite Instanz, ist es dann schon haariger, weil sehr viel eigener Programmcode hier läuft. Der ist zwar modular aufgebaut, aber verteilt auf mehrere Ebenen. So findet sich ein Teil des Codes in der functions.php des Themes (ein denkbar schlechter Ort, aber was wusste ich am Anfang schon) und ein anderer Teil in einem eigenen Plugin (der perfekte Ort dafür).
Ziel ist es hier also, all den Programmcode der Mittagstisch-Anwendung in mein hauseigenes Plugin zu packen. Letztlich vor allem Copy-and-Paste von der functions.php, allerdings arbeitet einiges an Code mit weiteren Plugins wie „Advanced Custom Fields“ und einem Plugin, um Programmcode in Form von Shortcodes abzubilden. Und nicht zu vergessen ist, dass die Mittagstisch-Plattform gleich mit zwei Custom Post Types arbeitet, die selbstverständlich korrekt und zuverlässig abgebildet sein müssen. Und bei beiden Post Types ist der RSS-Feed zum Datenaustausch sehr wichtig. Und selbstverständlich sollte sich dann bei der Migration die URL-Basis möglichst nicht ändern. „Uff“ sagt man da. Immerhin liegen hier weit über 6.000 bisher veröffentliche Wochenkarten, die allesamt schön bei Google indiziert sind und die ich da auch nur ungern weghaben wollte.
Dazu kommt, dass ich einige WordPress-Finessen, sagen wir, ein wenig anders nutze. So habe ich für die Wochenkarten für jeden Restaurant einen eigenen WordPress-Benutzer am Start. Das ist in einer eigenen Instanz kein Problem, denn dort dürfen außer diese Nutzer und ich niemand drauf. Wird aber alles in einer Instanz betrieben, gibt es Redakteure, die da drauf könnten, ich aber keinesfalls will.
Also muss die zukünftige Mittagstisch-Anwendung zusätzlich eine eigene Benutzergruppe mitbringen und dann muss der gesamte Programmcode auch eben so angepasst werden, dass es nur mit dieser Benutzergruppe läuft.
Bei dieser Großbaustelle bin ich aktuell noch. Weil es so komplex ist, läuft das in einer Entwicklungsumgebung, die identisch zur Produktivumgebung ist. Zeitziel: Mitte des Jahres.
Das neue Design
Nun denkt man bei einem Relauch: Hey, cool, ein neues Design kommt! Das aber ist in diesem Relaunch-Projekt überhaupt noch gar nicht am Start und auch noch gar nicht ausgesucht, da zunächst die obigen Hausaufgaben erledigt werden müssen.
Dann aber ist das Auswählen und Anpassen eines Themes nochmal ein Job, der ein paar Tage dauern dürfte. Immerhin hat der Entwickler meines bisherigen Themes namens „MH Magazine“ angekündigt, im Laufe des Jahres eine neue Version zu veröffentlichen. Es ist also so, dass ich an einem Relaunch arbeite, obwohl das neue Theme noch gar nicht existiert.
Was ist eigentlich ein Relaunch?
Und genau darauf will ich auch hinaus in diesem kleinen Bericht: Ein Relaunch hat nicht unbedingt nur mit Klickibunti auf der sichtbaren Website zu tun, sondern trägt die echten Herausforderungen vor allem hinter den Kulissen.
Was bei PF-BITS so schlau einfach aussieht auf der Vorderseite, ist hinten im Maschinenraum richtig viel Zeug, der sogar mich hin und wieder überrascht, wenn ich Programmteile finde, die mal eben sieben Jahre alt sind und erstaunlicherweise immer noch gut funktionieren. Geschrieben in PHP 5.6. Heute sind wir bei 8.2.
Schreibe einen Kommentar