Aktualisiert: Wie im Blog versprochen habe ich mein Update auf Version 0.815 von Yellow dokumentiert, denn es gab (letzendlich beherrschare) Schwierigkeiten.
Die hier beschriebenen Seiteneffekte und Hürden sind – objektiv betrachtet – weitestgehend „selbstgebacken“. Doch wie diese Zeilen zeigen: Sie lassen sich meistern, sonst wäre dieser Artikel wohl kaum hier, von Yellow zugänglich gemacht, entstanden.
Ich betreibe mittlerweile einige Webseiten mit Yellow. Aus diversen Gründen kann ich sie unmöglich nach jeder Änderung von Yellow aktualisieren und so die technische Entwicklung detailliert verfolgen. Daher haben die genannten Seiten einen mehr oder weniger großen „Abstand“ zur aktuellen Version. Das macht „Durchaktualisieren“ etwas anspruchsvoller.
Einschub 22.02.2021
„Den Drachen reiten“ war offenbar eine Vorahnung. Faktisch wurde es aufgegeben: Yellow hat meinerseits keine Präferenz mehr für Webseiten. Bestehende werden umgeschult auf »OffSiteEdit«.
Für den nachhaltigen, professionellen Einsatz hat sich Yellow aus meiner Sicht zwischenzeitlich leider als zu unstetig gezeigt.
Unklare Stolpersteine
Die integrierte Update-Funktion von Yellow sei für mich unbrauchbar. Das liegt primär daran, dass ich die mit Yellow erstellten Seiten individualisiere. Das sind zwar – aus meiner Sicht – meistens nur kleine Details. Doch bei Updates führt es regelmäßig zu Störungen oder gar zum Totalausfall der Seite.
Woran das genau liegt, hat sich mir bisher verborgen, doch habe ich schon mehrfach feststellen müssen, dass eine Yellow-Installation bei scheiternder Update-Funktion am besten von Grund auf neu aufgesestzt wird. Also in Schritten mit „Lebt es noch?“-Kontrolle:
- Aktuelle Version ziehen und in eine Testumgebung installieren.
- Den
content-Ordner durch den der bestehenden Installation ersetzen. - Den Inhalt des
Theme-Ordners mit dem der alten Installation ersetzen system.inientsprechend anpassen (s. nächster Kasten).- Layoutanpassungen von Standard-Layouts übertragen (s. nächster Kasten).
- Fehlende Plugins in der jeweils aktuellsten Version ergänzen und Funktion prüfen.
- Theme aufräumen, Datei-Leichen entfernen, hier konkret: Layout-Inhalte für Sidebars im Ordner gehören jetzt in das
shared-Verzeichnis, nur dort werden sie gelesen1.
Beim Ersetzen von Dateien auf dem Server (WSL2) oder bei der Verwendung der Update-Funktion gibt es – bei mir – teilweise den bizarren Effekt, dass sich inhaltsgleiche Layout-Dateien unterschiedlich verhalten:
- Wurde sie kopiert, geht es mehr oder weniger schief.
- Ergänze ich die Unterschiede zwischen angepasster und neuer Datei mit dem Editor, klappt es – obwohl die Dateien mit WinMerge verglichen am Ende inhaltsgleich sind.
Es scheint ein Wechselspiel zwischen Browser-Cache, Server-Cache (Wasserstand der Spree?, Mondphase?),… zu geben, der das beeinflusst. Trotz intensiver Suche habe ich keine Antwort gefunden – wer eine Idee hat:
.Das ist mir sowohl beim Blog als auch hier bei Buoa passiert und hat mich STUNDEN gekostet, ohne dass ich nur einen Hauch von Idee hätte, was da wirklich passiert. Caches löschen, Dateirechte neu setzen, Apache neu starten, Dateien einpacken und umpacken, … – ich habe die absurdesten Dinge probiert, um hinterher zu steigen. Das, was mir die Antwort gegeben hätte, blieb offenkundig unversucht. Vermutlich ist es etwas absolut Banales, das erfahrene Administratoren belächeln, aber Gelegenheits-Admins wie mich in die Verzweiflung treiben.
Erwähnenswert ist in jedem Fall, dass es Seiteneffekte sind, die sehr wahrscheinlich ihre Ursache außerhalb von Yellow haben. Macht im konkreten Fall jedoch objektiv keinen Unterschied, was das Nervenkostüm betrifft …
Bekannte Stolpersteine
Der oben erwähnte „Zeitverzug“ trifft gleichermaßen meine eigenen Plugins für Yellow. Die erweisen sich bisher als überraschend robust und bedürfen lediglich gelegentlicher Namensanpassungen für Funktionsaufrufe nach Updates des Kernsystems.
Um den Jahreswechsel herum wurden in der core.php zwei HTML-Elemente ausgesperrt, die ishow, dload einschränkten oder unbrauchbar machten. Ich muss dafür nach einem core-Update das Set $attributesHtml mit onClick ergänzen, sowie das Set $elementsHtml mit script.
Im Gegensatz zu diversen anderen Systemen ist diese Konfiguration bei Yellow fest im Kernmodul verdrahtet, statt in einer ausgelagerten Konfigurationsdatei. Das will der Projekt-Chef von Yellow so haben.
Ist seins, also macht er es halt so. Durch sein freundliches Bereitstellen der "Quellen von Yellow bei GitHub ist es in meiner eigenen Verantwortung, das anzupassen.
Beginn Aktualisierung 14.10.2020
Sowohl für dload als auch ishow gibt es nun Updates. Für alle Extensions kann daher die Original-core.php genutzt werden.
Da es mir redundant erscheint, wenn alle Seiten einer Webpräsenz mehr oder minder umfangreiche Skript- und CSS-Pakete rein präventiv laden, woraus nur an wenigen Stellen eine winzige Funktion gebraucht wird, besitzen meine Extensions, die Scripte erzeugen oder laden, einen Schalter, mit dem sich das auf die Seiten beschränken lässt, auf denen sie benötigt werden. Diese Skripte umgehen den „Minimierer“ (der bei mir meistens deaktiviert ist), weil sie dadurch kaum kleiner werden können aber Fehlfunktionen auftreten können. Sie werden nur auf den Seiten eingefügt, wo sie benötigt werden und die eventuell geöffnet werden.
In der Industrienation Deutschland ist selbst in Ballungsräumen wie der Bundeshauptstadt Berlin im Jahr 2020 die mobile Datenübertragung immer noch fragil2. Da bedeutet jedes eingesparte Bit mehr Stabilitiät und erhöht die Erreichbarkeit einer Seite.
Ende Aktualisierung 14.10.2020
Sinnloses
Ich hielt es mal für pfiffig, statt der Standard-Layout-Dateien durch sebstbenannte zu ersezten und diese für die Standards zu nehmen. Bei Updates erhöht das jedoch den Aufwand der Fehlersuche. Es ist besser, wenn Reibungspunkte direkt sichtbar werden. Die geänderten Dateien liegen in einem Backup, aus dem heraus leicht Anpassungen übernommen und dabei hinterfragt werden können.
Wenn in einer Entwicklungsumgebung bereits die Installation eines frischen Systems scheitert, kann man das zwar umgehen, indem die Installation wo anders vorgenommen und dann rüberkopiert wird. Allerdings ist das ein Signal, dass es in der verwendeten Umgebung irgendwo „klemmt“. So war es bei mir mit XAMPP. Der war jahrelang mein treuer Begleiter unter Windows, hat sich jedoch in den letzten Jahren als zunehmend zickig erwiesen.
Daher bin ich auf Windows Subsystem Linux in Version 2 umgestiegen. Mit neuen Herausforderungen (s.o.), insgesamt jedoch zuverlässiger und „fluffiger“.
Fazit
Bis hierher klingt es sicherlich etwas frustriert und genervt. Stimmt. ABER:
Wie schon im Blog geschrieben, habe ich mir diverse andere Systeme angesehen. Alle haben individuellen Vorzüge. Doch ich habe keins gefunden, dass mit den für mich wichtigen Möglichkeiten von Yellow mithalten kann. Denn die von anderen teilweise angebotene „Plug and Play“-Variante kann Yellow mindestens genauso gut. Darüber hinaus kann Yellow jedoch mit beherrschbarem Einsatz weit mehr. Da wird es bei Marktbegleitern dann heftig bis nahezu unmöglich. Bei einigen davon – bemerkenswerterweise gerade den „hippen“ – sind teilweise schwer nachvollziehbare Einstiegshürden aufgestellt, womit eine steile Lernkurve entsteht. Hier punktet Yellow ebenfalls: Man kann pimpen, doch ohne das bekommt man „out of the box“ ein sauber funktionierendes System. Womit sich diverse andere Systeme sehr schwer tun.
Bei allen persönlichen „Kleinkriegen“ damit bleibt Yellow deshalb für mich „das Mittel der Wahl“ für das, was ich (meistens) als „Webseiten-Erzeuger“ benötige.
Das Bild stammt von Pixabay.