Sie sind hier

Warum derzeit keine neuen Fragen im Forum möglich sind (oder: Supportende für Drupal 7 und die Folgen für komascript.de)

Bild von Admin

Nun ist das passiert, was irgendwann passieren musste: Drupal 9 ist erschienen. Damit nähert sich für das auf komascript.de eingesetzte Drupal 7 mit Riesenschritten das Supportende. Diejenigen, die hier schon vor 5 Jahren dabei waren, werden sich erinnern, dass wir beim Supportende für Drupal 6 schon einmal auf Drupal 8 umsteigen wolltne und damals damit gescheitert sind, weshalb es dann erst einmal Drupal 7 wurde.

Wie sich in einer Woche sehr intensiver Recherche und Tests zeigte, ist ein Upgrade von Drupal 7 auf die aktuelle Version von Drupel 8 durchaus möglich. Dabei ergeben sich aber diverse Probleme, deren Lösung einiges an Handarbeit erfordert. Bisher ungelöst sind dabei derzeit folgende Probleme:

  • Obwohl die Default-Darstellung von Büchern bei Drupal 8 der von Drupal 7 ähnelt wird diese nach dem Upgrade komplett auf den Kopf gestellt. Die Liste der Child-Nodes mit dem Navigationsmenü erscheint dann plötzlich über dem Text des jeweiligen Abschnitts. Das ist inakzeptabel. Leider konnte bisher weder in den Tiefen des Drupal 8-Handbuchs noch in den Konfigurationsmenüs eine Möglichkeit gefunden werden, die Defaultreihenfolge wiederhezustellen also: erst Text, dann Child-Nodes und Navigationsmenü.
  • Die Aktivierung des neuen Layout-Moduls hat genügt, um den berüchtigten »The website encountered an unexpected error«-Zustand auszulösen. Die Aktivierung des Moduls (eigentlich sind es zwei Module) geschah in der Hoffnung, damit das vorgenannte Problem zu lösen. Ein Deaktivieren der beiden Module per drush wurde daher nicht versucht. Das Problem lässt leider befürchten dass der Gesamtzustand der Installation nach dem Upgrade alles andere als stabil ist. Das ist natürlich inakzeptabel.
  • Die bisherigen Text Filter werden nicht mit konvertiert. Deshalb werden Inhalte nicht angezeigt. Dieses Problem ist lösbar, indem man zusätzliche Text Filter mit den bisherigen Namen anlegt. Ein (konfigurierbares) automatisches Mapping auf die neuen Text Filter wäre hier deutlich angenehmer, zumal die bisherigen Systemnamen 1, 3, 4, 5, 7 nicht sonderlich sinnvoll sind. Alle alten Beiträge hätten damit dann Text Filter zugewiesen, die den Benutzern künftig besser nicht mehr zur Verfügung stehen sollten.

Eine längere Internet-Recherche hat kein Ergebnis zur Lösung des ersten Problems erbracht. Da die Standarddarstellung eine andere ist als die Darstellung nach dem Upgrade ist aber davon auszugehen, dass es eine Lösung gibt. Hier könnte ein Experte oder eine längere Diskussion in einem Drupal-Forum vielleicht eine Lösung bringen.

Wie eine längere Recherche im Internet ergab, sind die letzten beiden Probleme nicht ganz selten. Teilweise sind die sogar noch größer. Es hat den Anschein, dass Systeme, die noch aus Vor-Drupal 7-Zeiten stammen kaum nach Drupal 8 oder gar 9 konvertiert werden. Selbst Dienstleister empfehlen, stattdessen eine neue Installation aufzusetzen und nur relevante Inhalte von Hand zu übertragen. Offenbar geht die Mehrzahl davon aus, dass insbesondere Forenbeiträge, die mehr als drei Jahre alt sind, ohnehin wertlos geworden sind. Bei komascript.de steckt aber in den Foren sehr, sehr viel Know-How. Aber auch die Bücher (das ist der Bereich »Dokumentation« unter »Navigation«) und Downloads (das ist der Bereich »Dateien« unter »Navigation«) ist nicht zu verachten. Die letzten beiden könnten jedoch mit einiger Man-Power auch manuell in ein neues System übertragen werden. Für das Forum scheidet dieser Weg leider aus.

Die Frage, die sich dabei stellt ist auch, wie künftig verfahren werden soll. Gerade die Möglichkeit, dass jeder hier recht einfach Beiträge verfassen kann, stellt uns fortwährend vor erhebliche Herausforderungen. Eine gar nicht so seltene Empfehlung war daher, Benutzern möglichst wenig Rechte einzuräumen oder gar kein Forum sondern maximal so eine Art moderiertes Gästebuch zu betreiben. Wer eine aktive Community will, soll dagegen erhebliche Kosten für Moderation und Administration einplanen.

Derzeit stehen zwei Szenarien zur Diskussion:

  1. Konvertierung soweit möglich und hoffen, dass es nicht wieder zu einem »The website encountered an unexpected error«-Problem kommt. Wie das Problem mit der falschen Darstellung der Bücher dabei gelöst werden soll, ist offen.
  2. Kompletter Neuanfang. Die bisherigen Bücher könnte nach und nach manuell neu eingepflegt werden. Einige alten Forenbeiträge könnten entweder als Teil der FAQ oder des neuen »Wie man« quasi auf Zuruf in die neuen Seiten eingefügt werden.

Bei Lösung zwei stellt sich die Frage, wie zukünftig mit einem Forum verfahren werden soll. Hier gibt es drei Möglichkeiten:

  1. Alles wie bisher.
  2. Forenbeiräge von vorn herein auf begrenzte Lebensdauer und lediglich für Diskussionen anlegen, wertvolle Informationen aber künftig zeitnah von wenigen privilegierten Benutzern in FAQ oder »Wie man« einpflegen.
  3. Kein Forum mehr anbieten, sondern auf einschlägige Foren (beispielsweise KOMA-Script-Forum auf goLaTeX) verweisen und ansonsten wie 2.

Da derzeit also die Zukunft von komascript.de sehr ungewiss ist, werden wir die Anmeldung neuer Benutzer vermutlich in Kürze abschalten und allen einfachen Benutzern das Schreibrecht für neue Beiträge entziehen [Update: Das ist inzwischen geschehen]. Damit wird dann verhindert, dass sich weitere Inhalte anhäufen, deren Konvertierung schon heute kaum zu leisten ist. Alle anderen dürfen weiter diskutieren sollen sich aber bewusst sein, dass ihre Inhalte u. U. von geringer Lebensdauer sind,

Um eine Diskussion dieser Frage (vor allem der langjährigen Nutzer) wird ausdrücklich gebeten. Alle derzeitigen internen Projekte (dazu zählen auch die neuen »Wie man«-Seiten) liegen bis auf weiteres auf Eis.

forum: 
Bild von Markus Kohm

Ein Vorschlag, der mich erreicht hat, war übrigens statt zu Drupal 8 oder Drupal 9 zu Backdrop CMS zu wechseln. Tatsächlich ist das eine durchaus attraktiv erscheinende Alternative. Davon abgesehen, dass ich mir das persönlich erst einmal näher anschauen müsste, ergeben sich auf den ersten Blick ein paar Nachteile:

  • Es gibt kein geShifilter-Modul. Es gibt zwar ein highlight.js-Modul, aber damit müssten existierende Code-Tags wie <latex> erst konvertiert werden. Darüber hinaus kenne ich mich mit highlight.js nicht aus und habe keine Ahnung, ob ich Doku-Links für LaTeX-Befehle automatisch generieren könnte.
  • Es gibt kein Remote-Administations-Tool. Bisher kann ich im Normalfall den Auftritt per drush in den Wartungsmodus versetzen, Updates durchführen und den Wartungsmodus wieder aufheben. Das war eine der großen Errungenschaften bei Drupal 6. Dagegen ist es extrem aufwändig, jedes Mal manuell eine Kopie anzulegen, eine Datenbank-Backup zu erzeugen, Module manuell herunterzuladen, auszupacken und dann in einem Browser das Update zu starten. Man braucht da immer sowohl ein Terminal als auch einen Browser und muss ständig dabei bleiben.

Was sonst noch an Problemen auftreten könnte, weiß ich nicht, da ich mir das nicht näher angeschaut habe.

Bild von Markus Kohm

Ein weiterer Vorschlag war, gleich ganz weg von Drupal zu Typo3, Wordpress oder sonst irgendwas zu wechseln. Damit wäre man dann letztlich bei dem Szenario »Kompletter Neuanfang« mit Verlust des kompletten bisherigen Inhalts. So recht erschließt sich mir der Vorteil gegenüber einem Wechsel zu einer neuen Drupal-Version oder Backdrop-CMS nicht.

Dasselbe gilt übrigens auch für die Idee, auf die Möglichkeiten von github (im Fall von KOMA-Script derzeit eher von SF) zurück zu greifen. Attraktiv ist davon allenfalls der Issue-Tracker.

Typo3 habe ich vor ca. zehn Jahren mal selbst als Betreuer einer Website benutzen müssen. Es war fürchterlich. Das Backend ist wie ein hochambitionierter Beitrag zu einer Olympiade unübersichtlicher, unergonomischer CMS gewesen. Ich weiß nicht, wie es heute ist. Ich kann mir nicht vorstellen, daß Typo3 heute weniger komplex ist als damals. Die Beiträge weiter unten auf dieser Seite klingen aber ohnehin eindeutig so, als käme Typo3 nicht weiter in Betracht.

Könnte ich nach Anleitung helfen, die Seite umzustellen, wenn es darum geht, irgendwelche Inhalte von A nach B zu befördern oder irgendwelche Schalter pro Artikel umzustellen? Da kann man sich ja so langsam in einer nicht öffentlichen Kopie der Seite durcharbeiten, wenn noch Zeit ist, bis V7 endgültig aus dem support läuft. Ich sitze öfter mal im Zug... Wenn dann die neue Seite vorzeigbar ist, tritt sie an die Stelle der alten. Oder so irgendwie.

Vielleicht findet sich noch der eine oder andere Helfer unter den Langzeit-Nutzern der Seite, denen Du an so einer Kopie die notwendigen Rechte geben würdest.

Wenn Du Hilfe hättest, würdest Du dann vielleicht sogar gleich auf V9 versuchen, umzustellen?

Bild von Markus Kohm

Der Umstieg auf Drupal 9 ist absolut erforderlich. Drupal 8 verliert nämlich gleichzeitig mit Drupal 7 den Support. Derzeit ist da das Problem, dass es diverse Module wie geSHifilter für Drupal 9 noch gar nicht gibt. Auf der anderen Seite ist versprochen, dass das Upgrade von einem aktuellen Drupal 8 auf Drupal 9 nicht viel aufwändiger als ein normales Update werden soll. Das gilt aber, wie immer, leider nur für den Kern. Wenn ein essentielles Modul nicht rechtzeitig fertig wird, steht man diesbezüglich vor allem bei einer Konvertierung der alten Seiten dumm da.

Hier läge tatsächlich einer der großen Vorteile in einem möglicherweise sogar öffentlichen Parallelbetrieb:

  • archiv.komascript.de (ob Subdomains möglich sind, muss ich erst den Domain-Inhaber und den Systemadmin fragen, Unterordner sind notfalls möglich, soweit ich eine weitere Datenbank bekomme) ohne jeglichen Schreibzugriff mit den alten Seiten,
  • komascript.de komplett neu aufgesetzt.

Das neue System würde dann gleich mit Drupal 9 erstellt und eben erst einmal nur das bieten, was dort derzeit zur Verfügung steht. Das würde aber (aufgrund einiger fehlender Spam-Schutz-Mechanismen, die sich sehr bewährt haben) auch erst einmal mit stark eingeschränktem Schreibzugriff eingerichtet. Auch in dem Fall müsste ich für Fragen vermutlich erst einmal auf externe Foren verweisen und für Fehlermeldungen den Issue-Tracker auf SF in Betrieb nehmen oder ein github-Projekt einrichten. Die Frage des allgemeinen Forums ist ohnehin offen. Da kamen zwar viele nützliche Impulse, aber ich weiß wirklich nicht, ob ich mir das noch einmal antun will. Nicht nur die sehr unerfreulichen Vorkommnisse der letzten Wochen, sondern auch die massiven Spam-Bot-Angriffe und die sich immer wieder ändernden Rechtsrahmen und deren Grauzonen werfen da deutliche Schatten.

Übrigens ist auch die Frage des Repositories für Vorabversionen offen. Ob das mit einer neuen Installation noch so funktionieren würde, ist derzeit noch vollkommen ungewiss. Das ist eines der Dinge, die ich erst ganz zum Schluss testen werde.

Bild von Markus Kohm

Helfen wird früher oder später Anwendern(, die über die notwendigen Rechte verfügen,) auf jeden Fall möglich sein. Ob diese Hilfe dann in der Form erfolgt, dass alte Beiträge manuell aus dem alten System in das neue eingepflegt werden, oder darin besteht, die Text-Filter-Einstellungen anzupassen und ggf. die Inhalts zu editieren, um die Darstellung zu korrigieren, hängt von der Entscheidung ab, wie genau es weiter gehen soll. Wobei ich schon sehr stark zu einem Neuanfang tendiere.

Etwas ähnliches wollte ich auch vorschlagen. Ich bin zwar nicht oft hier, würde aber trotzdem meine Hilfe anbieten, wenn es sich irgendwo sinnvoll ergibt. Sei es die Übertragung von Inhalten, oder das testen/vergleichen von Drupal 7 und Drupal 9, oder etwas anderes. Jedenfalls bin ich froh, daß es KOMA-Script und komascript.de gibt und wünsche mir, daß das so bleibt.

Bild von Admin

Heute wurde über die Drupal-Security-Mailingliste, dass aufgrund von Corona das Support-Ende für Drupal 7 auf November 2022 verschoben wurde. Klingt erst einmal gut, weil es ein Jahr länger Zeit gibt. Ändert aber nichts daran, dass ein Upgrade notwendig werden wird und dafür eine Strategie erarbeitet werden muss. Es ist nicht anzunehmen, dass die bei den Upgrade-Versuchen ermittelten Probleme durch die Verschiebung verschwinden. Es bringt daher auch nichts zu sagen, wir verschieben die Entscheidung über die Zukunft jetzt erst einmal um ein Jahr. Vielmehr bietet sich dadurch die Möglichkeit, die gewonnene Zeit sinnvoll zu nutzen, beispielsweise um, wie von cookie170 angeregt, gemeinsam wichtige Inhalte in ein neues System einzupflegen oder auch nur Erfahrungen damit zu sammeln.

Von Admin-Seite wird es die nächste Aufgabe (wie immer für Markus) sein, testweise auch einmal ein Upgrade direkt auf Drupal 9, also ohne den Zwischenschritt über Drupal 8 zu testen. Es ist allerdings jetzt schon klar, dass dabei viele Dinge in Ermangelung der entsprechenden Module derzeit nicht (brauchbar) konvertiert werden können. Deshalb steht eine Neuinstallation ohne unmittelbare Übernahme von Inhalten weiterhin im Raum.

Obwohl wir die Registrierung neuer Benutzer bereits deaktiviert haben und einfache Benutzer auch keine neuen Beiträge mehr anlegen können (kommentieren und damit hier mitdiskutieren können sie aber noch), wird derzeit davon ausgegangen, dass der tatsächliche Umstieg oder auch der (eingeschränkt) öffentliche Parallelbetrieb nicht unmittelbar bevor steht. Solange alles ungewiss ist, wollen wir einfach keine komplett neuen Inhalte haben. Davon ausgenommen sind Inhalte von wenigen Benutzern, bei denen wir davon ausgehen,. dass sie ggf. bereit sind, diese selbst auch in ein neues System einzupflegen.

Das Ende für Drupal 8 bleibt übrigens bei November 2021. Ein Grund mehr, warum der Zwischenschritt über Drupal 8 eventuell keine gute Idee ist.

Administratorentscheidungen sind grundsätzlich nicht im Forum zu diskutieren. Für Fragen an die Administratoren ist die bekannte Administrator-E-Mail-Adresse oder das Forum Site zu verwenden.

Bild von Markus Kohm

Obwohl wir die Registrierung neuer Benutzer bereits deaktiviert haben und einfache Benutzer auch keine neuen Beiträge mehr anlegen können (kommentieren und damit hier mitdiskutieren können sie aber noch), […]
wollen wir einfach keine komplett neuen Inhalte haben. Davon ausgenommen sind Inhalte von wenigen Benutzern, bei denen wir davon ausgehen, dass sie ggf. bereit sind, diese selbst auch in ein neues System einzupflegen.

Wobei auch das in allen Aspekten derzeit provisorisch ist. Obwohl es unwahrscheinlich ist, kann es sein, dass die Rechte wieder ausgeweitet werden. Es kann aber auch sein, dass weitere Benutzergruppen, keine neuen Inhalte mehr werden anlegen können. Wichtig ist, dass neue KOMA-Script-Releases durch die Upgrade-Problematik weder verhindert noch geplant verschoben werden. Auch die dann notwendige neue Release-Seite wird es geben.

Bild von Markus Kohm

Ich habe übrigens schon vor einiger Zeit begonnen, einige wenige Wiki-artige Inhalte in Wiki auf SourceForge zu migrieren. Alle Inhalte dort, sind sowohl in Englisch als auch in Deutsch verfügbar. Allerdings kann ich es unmöglich schaffen, alle Wiki-artigen Inhalte selbst zu portieren und zu übersetzen. Bei den vielen Forenbeiträgen, deren wesentlichen Inhalte zwar erhaltenswert sind, die aber komplett überarbeitet werden müssen, um in eine Wiki-Struktur zu passen, ist das für einen allein ohnehin nicht zu bewältigen.

Dazu kommen diverse Seiten, wie die Kritik an einem YouTube-Tutorium, aber vermutlich auch mit typografischen Hinweisen, beispielsweise zu Nebenwirkungen des Abschaltens des Absatzeinzuges, die eigentlich im Wiki zu KOMA-Script nicht wirklich viel verloren haben. Das Wiki dort ist derzeit auch eher als sehr Projekt bezogene Ergänzung zu komascript.de gedacht.

Trotzdem wäre es schön, wenn ich nicht als einziger Inhalte dorthin portieren würde.

Comments for "Warum derzeit keine neuen Fragen im Forum möglich sind (oder: Supportende für Drupal 7 und die Folgen für komascript.de)" abonnieren