Forum:Unabhängige Wikis - wie es um andere Projekte steht

Forum > Unabhängige Wikis - wie es um andere Projekte steht

Hinweis: Dieser Fred wurde seit 333 Tagen nicht bearbeitet. Dieser Fred ist offiziell versandet - die Diskussion damit Geschichte. Bitte nichts mehr hinzufügen.
Bei Bedarf dann halt einen neuen Fred starten oder diesen notfalls reanimieren.

Hier ist Thema, wie es anderen freien Wiki-Projekten geht. Dieser Forumsbeitrag wird in entsprechende "== =="-Abschnitte je Wiki aufgeteilt.

camera-wiki.org

An anderer Stelle wies ich schon darauf hin, dass camera-wiki.org ein interessanter Vergleichsfall zur Kamelopedia ist, vonwegen Modernisierungsprojekt und https. Die Wiki ist ein Fork, der entstand, als die explizit nichtkommerzielle Camerapedia feindlich übernommen wurde durch die kommerzielle und humorwikifeindliche, ja humorwikivernichtende Wiki-Host--Firma wikia des Jimmy Wales nach Verrat an den Autoren durch den Gründer und Host der Camerapedia. Seitdem behielt camera-wiki.org beständig die Nase vorn bei der Anzahl der Artikel. Unvergleichbar ist die Wiki in Sachen Mediendateien. "Datei hochladen" ist da nicht - alle Bilder werden direkt aus der flickr-Gruppe camera-wiki.org eingebunden. Es besteht praktisch die Sonderlizenz, die nur dadurch gegeben ist, dass das Bild z.B. eine Fotoapparates bewusst der Flickr-Gruppe zugeordnet wurde.

Stand heute ist es soweit: Der Update auf Media-Wiki auf 1.43 wird realistisch. Erst aber muss von Version 1.35, bei der des WYSIWYG-Editor streikt, die Zwischenstufe Version 1.39 erreicht werden. Dabei wurden zuletzt Fortschritte bei der PHP-Konfiguration gemacht. Unser Techniker ist Steevithak, und er stößt in dem Update-Prozess ständig auf unerwartete Felder, wo etwas hakt, umkonfiguriert oder gar im Code geändert werden muss. Hier nochmal, weil es nun mit einem mal optimistisch zugeht in dem Projekt, der Link zur Diskussion: https://www.flickr.com/groups/camerawiki/discuss/72157721920591092/72157721924072830

camera-wiki.org und Kamelopedia, selbst wenn die Kamelo nun vielleicht doch "Wiki classic" bliebe, d.h. auf einer klappernden Ur-Fassung von Mediawiki basierend, auch noch die gemeinsame Frage offen: Wie den Fortbestand sichern als freie Kulturwerke, die auch Zukunft haben. Sloyment hatte iin der Vergangenheit dazu mal eine Vereinsgründung für freie Kulturwerke vorgeschlagen. Für eine andere Lösung bräuchte kamel Kapital: Eine Stiftung. Ooops. Oder, da unser Host Sloyment so technikbegeistert ist (KI), etwa Schaffung einer Kryptowährung "Kameldollar" zur Finanzierung ??? Sie müsste schon ein extrem faires Angebot sein, um mit freien Kulturwerken kompatibel zu sein. Und dennoch die schlechteste Lösung. Kamelurmel (Diskussion) 07:54, 1. Dez. 2025 (NNZ)

Mir tut das in der Seele weh dass wir damals nicht weitergekommen sind mit der Modernisierung. Klar die Kamelo kann noch ewig auf dem alten Stand weiter laufen. Aber mal ehrlich: Ist schon auch bissi Retrofeeling inzwischen. Und wenn der Server selbst einmal Retrofeelings bekommt, so in Richtung Aua Aua, dann wirds knifflig. In letzter Zeit gabs hier ja wieder öfters Gurus. Warum weiß ich nicht. Selbst wenn es Backups gibt von der Datenbank: Setz mal so ein Uralt-Wiki auf einem neuen Server auf. Da kriegst du inzwischen keine Steine mehr in den Weg gelegt sondern gleich den Großglockner, so viele Abhängigkeiten wie da bestehen. Im Grunde bräuchte es ein Image von der Festplatte, damit man erstmal die uralten Versionsstände der Software gesichert hat. Und dann ist nicht sicher, dass so ein Methusalem-Kernel auf moderner Hardware überhaupt hochfährt. Klar mit viel Gebastel kriegt man das alles wieder irgendwie hin. Aber wenn wir ehrlich sind: Würde das Wiki eine längere Downtime überleben, rein von der Nutzerbasis her?

Ich würde inzwischen die Sache anders angehen als damals. Überlassen wir die museale Archivierung denen, die sich darauf spezialisiert haben (archive.org) und machen eine 80%-Migration. So weit waren wir zu einem gewissen Zeitpunkt ja schon. Die meisten Texte waren drüben. Was fehlte waren diverse Gimmicks, Vorlagen, Mediawiki-Plugins usw. Das könnte man alles nach und nach entweder wieder ergänzen oder mangels Bedarf auch ganz entfernen.

--Wüstenspitz (Diskussion) 13:14, 2. Dez. 2025 (NNZ)

/ war zu 99 % voll. In /home waren mehrere alte Backups. Diese hab ich heruntergeladen und dann auf dem Server gelöscht. Jetzt geht es erstmal wieder. -- Sloyment (Diskussion) 23:11, 3. Dez. 2025 (NNZ)

Könnte man ein aktuelles DB-Backup problemlos an ein frisches MediaWiki füttern, oder muss man da erst herumkonvertieren? Beim Umzug sollten ja wenigstens alle Artikelversionen, die Benutzeraccounts und die File-Uploads erhalten bleiben. Den Rest könnte man nach und nach reparieren. -- Sloyment (Diskussion) 23:16, 3. Dez. 2025 (NNZ)

Leider leider... braucht es viel Datenbank-Voodoo. Es gibt verschiedene Wege: Offizielle und funktionierende. Muss man so formulieren. Der offizielle Weg wäre über das API, so war das bei Mediawiki mal vorgesehen. Für einzelne Seiten geht das, aber nicht für die ganze Kamelo. Zu groß, zu inkompatibel zwischen der laufenden und der aktuellen Version, die History würde verloren gehen usw. usf. Der letzte Stand war ein Shellscript das bei mir im Homeverzeichnis auf dem alten Server herum lag. Es hat die Datenbank auf Ebene von Mysql exportiert und komprimiert. Das hatte ich dann zu Fuß auf den neuen Server kopiert und wieder auf Mysql-Ebene eingelesen. Der nächste Step war die Konvertierung der DB, die neuen Strukturen vom aktuellen Mediawiki erzeugen. Das ging auch.

Am Ende hatte ich gefühlt einen sehr großen Teil der Artikel drüben. Nicht alle, es gibt einfach schon zu viele Glitches in der jetzigen Datenbank. Was noch fehlte waren die ganzen Bilder, da wollte sich ein anderes Kamel drum kümmern. Ich hatte mich derweil um die Oberfläche gekümmert (Sandbeige statt Himmelblau...) Und dann gings nicht mehr voran. Knackpunkt waren die zahlreichen Extensions, die entweder nicht mehr gepflegt wurden, komplett verschwunden oder schlicht inkompatibel mit der neuen Version waren. Ich bin dann auf die höchste Düne gestiegen die ich finden konnte und hab in die weite Wüste geschaut und irgendwie war kein Kamel mehr da. Die ganze Geschichte kann kamel ja hier nachlesen. Also hab ich es dann aufgegeben, vorallem weil mir die Zeit fehlte.

--Wüstenspitz (Diskussion) 14:50, 5. Dez. 2025 (NNZ)

Machen wir zur Ehrenrettung der Kamelo halt ein kleines Update auf eine mittlere Version. Das wird kompliziert genug. Wir wollen, dass nix verloren geht, hoffen, manche Extras aktiv zuhalten, fügen HTTPS hinzu. Grüße Kamelurmel

Die Diskussion hatten wir doch auch schon mal. Das meinte ich aber nicht mit 80%-Lösung. Ich seh das so: Ein bisschen Update ist gar kein Update. Worin besteht der Sinn, als Zielversion eine zu wählen, die jetzt schon nicht mehr oder bald nicht mehr unterstützt wird? HTTPS ja, wäre gut im Sinne von SEO, aber das würden wir mit vergleichsweise wenig Aufwand auch mit der jetzigen Mediawiki hinbekommen. Ich würde als Zielversion immer die aktuelle Stable nehmen. Und dann 80% vom Content rüber ziehen. Wenn eine Page von einer uralten Extension abhängig ist, die es nicht mehr gibt, dann muss man eben gucken ob die Page wichtig genug ist dass man sie händisch umschreibt damit sie auf dem modernen Mediawiki so funktioniert wie vorher. Oder ob wir ggf. auch darauf verzichten könnten. Ich hab damals bei den Probe-Migrationen auch mehrere Pages gefunden, die noch älter sind als das derzeitige Mediawiki und jetzt schon nicht mehr funktionieren. Ist aber in all den Jahren niemandem aufgefallen. Dann könnten wir denke ich mit vertretbaren Schmerzen auch drauf verzichten. Generell sollten wir nach der Migration mit so wenig Extensions wie möglich auskommen (vieles geht ja heute auch mit CSS3 was früher noch eine Extension brauchte). Umso geringer ist dann nämlich das Risiko, bei künftigen Upgrades wieder in solche Lock-Ins zu laufen. --Wüstenspitz (Diskussion) 08:02, 7. Dez. 2025 (NNZ)

Folgende Sachen sollten möglichst zu 100 % rüber:

• die User-Accounts,
• die File-Uploads und
• sämtliche Artikel-Revisionen (im Quelltext).

Die Extensions sind auch erstmal sekundär. Wir sollten eine Liste machen, welche Artikel nicht mehr korrekt rendern, um diese dann nach und nach zu reparieren. Besonders auffällige Sachen, z.B. die Hauptseite, könnten wir auch durch eine temporäre Not-Version ersetzen.

Extensions kommen und gehen, aber es gibt immer irgendeinen Ersatz. Z.B. im Musikwiki wurden Lilypond-Noten erst mit <music> eingebunden, dann mit <lilymidi> und jetzt mit <score midi="1">. Keine große Sache, außer dass alte Revisionen nicht korrekt gerendert werden. -- Sloyment (Diskussion) 05:38, 8. Dez. 2025 (NNZ)

♪ The Wiki Songbook for Free Music ♪

Updates hab ich lange vernachlässigt. Installiert ist MW 1.30.0, verfügbar wäre jetzt 1.44.0. Fun-Fact: Der Album-Player ist mittels ChatGPT gevibecodet, hehe. -- Sloyment (Diskussion) 23:24, 3. Dez. 2025 (NNZ)