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

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

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.

Verstehe ich die 80 % richtig, dass es darum geht, dass manche Artikel nicht richtig rendern, weil es bestimmte Extensions nicht mehr gibt, oder lassen sich manche Artikel gar nicht (im Quelltext) rüberziehen, weil die Tabellen zerstört sind? -- Sloyment (Diskussion) 05:45, 8. Dez. 2025 (NNZ)

Was die Extensions anging, hatten wir ja vor drei Jahren eine Bestandsaufnahme gemacht. Da sieht man schon die 80% die prinzipiell ersetzbar wären. Je weniger 3rd-Party-Extensions man tatsächlich einbaut, umso leichter hat man es künftig bei der Wartung. Bei den Testmigrationen sind mir einige unterbrochene Revisionen aufgefallen. Ist auch in besagtem Post von mir erwähnt. Diese Breaks sind IMHO nicht erst bei der Migration entstanden sondern bereits jetzt in der Datenbank defekt. Soweit ich mich erinnere waren es in allen Fällen fehlende ältere Versionen, der aktuelle Stand war immer vorhanden. Die Tabellen an sich sind nicht "zerstört", das hätten wir längst gemerkt. Es sind wohl eher verlorene Key-Record-Verknüpfungen, vielleicht entstanden wenn ein Kamel einen Submit gesendet hat als unser greiser Server gerade wieder einen rheumatischen Anfall hatte. Das Migrationsscript hat eine Liste betroffener Artikel ausgeworfen. Was die File-Uploads angeht: Die Dateien und Ordner hatte ich auf den neuen Server kopiert. Die zugehörigen Metadaten aus der Datenbank wurden vom Migrationsscript übertragen. Bei Stichproben sah es gut aus aber ich hatte das damals nicht nicht in die Tiefe geprüft. So weit war die Migration noch nicht gediehen. --Wüstenspitz (Diskussion) 21:35, 8. Dez. 2025 (NNZ)

Zurück zum Thema camera-wiki.org - kurz vor dem Durchbruch?

Zitat

„steevithak“

– Das Upgrade auf MediaWiki 1.43 auf dem neuen Server ist abgeschlossen. Ich bin nur auf ein kleines Problem gestoßen: Eine CSS-Klasse, die wir in der Flickr-image-Vorlagen verwende, wurde entfernt. Ich könnte die Vorlagen zwar umschreiben, um die entsprechenden Stile einzufügen, suche aber nach einer einfachen Möglichkeit, eine benutzerdefinierte Klasse sicher in das Vector-Theme einzufügen. Mir läuft heute Abend die Zeit davon, daher bleibt die alte Website noch einen Tag im Lesemodus, bevor der neue Server live geht. über  Gepostet vor 2 Stunden

Das ist bemerkenswert, da ich vor langer Zeit dem Top-Autor zuliebe die Vorlage Flickr_image erstellt hatte als meinen Beitrag zum Erfolg des damals beschrittenen Konzeptes der Wiki mit Flickr-Medien-Einbindung statt Nutzung der Mediawiki-Mediendatenbank. Nun stellt sich im letzten Schritt des Update-Prozesses die Wahl zwischen Vorlagenänderung und programmtechnischer Anpassung der Wiki-Software oder eines ihrer Add-Ons. A&O ist also Findigkeit des Updatetechnikers, und das auch in mehr oder weniger abstraktem Code in und um einer Mediawiki-Installation. -- Kamelurmel (Diskussion) 07:38, 9. Dez. 2025 (NNZ)

Ohne die konkreten Zusammenhänge zu kennen, also des betroffenen Quälkots, kann man das kaum beurteilen. Mein Bauchgefühl sagt, dass dein Weg eigentlich der richtige wäre: Eine Vorlage erstellen bzw. in der vorhandenen Vorlage die CSS-Klasse umschreiben. ABER... Ich bin bei uns auf ein ähnliches Problem gestoßen und wenn mich die Erinnerung nicht trügt, war das sogar der Anstoß für das Upgrade-Projekt. Bei uns gibt es eine Vorlage zur Einbettung von Youtube-Videos. Die allerdings zielt auf ein veraltetes API von Youtube, was letztlich dazu führt dass Videos bei uns hin und wieder nicht angezeigt werden, kein Vollbildmodus funktioniert usw. Ich dachte ich wäre schlau und ändere einfach die Vorlage und schon wäre das Problem aus der Welt. Aber denkste: Bei uns ist aktuell noch die Smarty Template Engine im Spiel und die hat einen eigenen Cache. Dadurch hätte das geänderte Template zwar funktioniert bei neu angelegten Wikipages oder bei Edits wo das Video erstmals neu per Vorlage eingebettet wird. Aber sobald man versucht, ein Video das schon woanders eingebettet war (die selbe Youtube-Video-ID hat), nochmals einzubetten, springt der Smarty-Cache rein und liefert die alte Version des Vorlagenschnipsels aus. Dolle Wurst... Also hab ich kurzerhand den Smarty-Cache gelöscht (zum Glück nach vorheriger Sicherung) und hatte erwartet, dass die Engine das Template neu kompilieren würde. Aber nö, es passierte gar nix. Außer dass auf der Wikipage anstelle des Youtube-Embeds ein großer Kasten mit einer Fehlermeldung erschien. Lange Rede kurzer Unsinn: Der Teufel steckt manchmal im Detail und Details haben wir hier sehr viele. --Wüstenspitz (Diskussion) 12:02, 9. Dez. 2025 (NNZ)

camera-wiki.org Verlautbarung

Der neue Server hat2 vCPUs und doppelt soviel Speicher als der vorige.

Software

• Rocky GNU/Linux 10
• MariaDB 10.11.11
• PHP 8.3.19
• MediaWiki 1.43.5

Kleine Fehler werden als Wartungsarbeiten demnächst noch behoben: Funktionsfähigkeit einiger Widgets und Übernahme von automatisierten Sicherungs- und SSL-Zertifizier-Skripten aus der alten Installation, Mastodonanbindung usw. Kamelurmel (Diskussion) 14:38, 10. Dez. 2025 (NNZ)

Bevor wir dahin kommen, uns Gedanken um einen Austausch des inzwischen rechtslastigen Tweeties gegen ein behaartes Rüsseltier machen zu müssen, müssen wir erstmal die digitale Road to Hell durchwandern. Bei uns ist es glaub ich ein Debian, ansonsten kann man alles recht ähnlich einrichten. TLS über Letsencrypt mit Certbot hätte ich vorgeschlagen. Keine Ahnung warum das manche immer noch "SSL" nennen ^^ Mediawiki 1.43 ist die aktuelle LTS-Version, das ist grad ne blöde Zeit dafür weil genau zwischen zwei LTS-Releases (kommt alle 2 Jahre, nächste im Dezember 2026). Bei den LTS gibts drei Jahre Support, bei den normalen nur ein Jahr. Bei MariaDB wunderts mich dass man die vorvorletzte LTS genommen hat und nicht die 11.4 die bis Mai 2029 Support hat. Bei PHP muss man gucken und sich nach Mediawiki richten, wenn möglich lieber die 8.5 nehmen die bis Ende 2029 Support hat. LTS gibts da ja nicht bzw. jede Version ist eine LTS mit 4 Jahren Support.

PS: Neee, "TLS" und "LTS" sind weder das selbe noch ein Schreipfähler ;-)

--Wüstenspitz (Diskussion) 18:24, 10. 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)