Zum Inhalt springen

Gespräch:MediaWIki Update 1.43 auf 1.44.2

aus AufEinWort, der freien Forschung

Über diese Seite Gespräch

Update Vorbereitung MediaWiki 1.44
ChatGPT Sophos GPT-5
9. Oktober 2025 n. Chr. erst.  
14:07 Uhr Ausgabe 02
Ausgabe 02
unüberarbeitet ungeprüft
↓ Fehlerbehebung Lingo Extension nach MediaWiki 1.44 Update
2025100902 MediaWIki Update 1.43 auf 1.44.2

Vorbereitung MediaWiki Update

Guten Morgen Sophos,

im Folgenden geht es um das Update von meinem MediaWiki 1.43 auf 1.44

Mein M1 Server ist auf dem aktuellen Stand un mit MediaWiki 1.44 kompatibel.

Backup von Server ist erstellt runJobs sind abgearbeitet.

Da ich derzeit einziger User meines eigenen MediaWiki bin, fallen einige sonst erforderliche Maßgaben weg.

Ich habe bereits ein Update aller MediaWiki Extensions und auch deren Kompatibilität geprüft.

Ein extensions-Ordner für MediaWiki 1.44 ist vorbereitet. Download MediaWiki 1.44 habe ich auch bereits.

Ein MariaDB Backup habe ich bereits per Querious SQL Software erstellt. Ich würde gerne noch eines per phpMyAdmin oder bash erstellen.

Was gibt es noch zu beachten?

Hinweise zum Update

Guten Morgen Nikolaos ☀️

(9. Okt. 2025, 14:07 Berlin)

Deine Vorbereitung ist vorbildlich gründlich – du hast schon fast alles Wichtige abgedeckt.

Ich gebe dir im Folgenden eine präzise, vollständige und auf dein Setup zugeschnittene Checkliste mit Fokus auf:

1️⃣ Backup-Vollständigkeit,

2️⃣ technische Übergänge,

3️⃣ bekannte 1.44-Änderungen.

🧩 1. Vollständige Sicherung vor dem Update

Du hast bereits:

✅ komplettes Server-Backup

✅ Extensions-Update und Kompatibilitätsprüfung

✅ MariaDB-Backup via Querious

✅ runJobs abgearbeitet

Zusätzlich empfehlenswert:

🔹 A. Datenbank-Backup (zweite Quelle)

Ein zweites SQL-Dump-Backup ist gut zur Redundanz (Query-Dumps sind manchmal unvollständig bei großen Tabellen).

Per bash (empfohlen, schnell und sauber): mysqldump -u wikiuser -p --default-character-set=binary --single-transaction --quick --lock-tables=false wikidb > ~/Backup/wiki_$(date +%F_%H-%M)_pre144.sql

(ersetze wikiuser und wikidb durch deine Werte)

Option --single-transaction sichert konsistent ohne Lock.

Per phpMyAdmin:

Export → „Angepasst“ → alle Tabellen → SQL → Kompression „gzip“.

Das ist etwas bequemer, aber langsamer.

💡 Tipp: Prüfe kurz, ob dein Dump alle SMW-Tabellen (smw_object_ids, smw_di_*) enthält.

⚙️ 2. Update-Ablauf (angepasst an dein lokales M1-Setup)

Da du MediaWiki manuell und nicht via Git einsetzt, nimm bitte den klassischen Schritt-für-Schritt-Weg:

  1. Wartungsmodus aktivieren Falls du LocalSettings.php angepasst hast: $wgReadOnly = 'Wartung: Update auf MediaWiki 1.44 läuft.';
  2. Alte MediaWiki-Dateien sichern mv /usr/local/var/www/mediawiki /usr/local/var/www/mediawiki_143_backup
  3. Neue Version entpacken
    tar -xvzf mediawiki-1.44.tar.gz -C /usr/local/var/www/
mv /usr/local/var/www/mediawiki-1.44 /usr/local/var/www/mediawiki
  4. Kopiere deine lokale Konfiguration:
    • LocalSettings.php
    • images/
    • evtl. custom/, favicon.ico, robots.txt
    • evtl. composer.local.json (falls du Composer nutzt)
  5. Ersetze den extensions-Ordner durch deinen vorbereiteten 1.44-kompatiblen Ordner.
  6. Cache leeren (vor dem Update-Skript):
  7. Update ausführen: php maintenance/update.php Achte auf eventuelle Schema-Meldungen (z. B. neue Felder in page_restrictions oder actor-Bezug).
  8. Wartungsmodus wieder deaktivieren # $wgReadOnly = false;
  9. Testlauf:
    • Seite aufrufen
    • Versionsseite prüfen (Special:Version)
    • SMW prüfen (Special:SemanticStatistics)

🧮 3. MediaWiki 1.44 – Änderungen mit Relevanz

Ich liste nur die für dein Setup potenziell relevanten Punkte:

Bereich Änderung Bedeutung für dich
PHP Erfordert mindestens PHP 8.1 Dein M1-Server erfüllt das
MariaDB/MySQL Mindestens MariaDB 10.4 Du hast das wahrscheinlich schon
Skin Vector-2022 Anpassungen bei Sidebar und Preferences Prüfe, ob dein Custom-CSS noch greift
Extension-Schnittstellen Einige Hooks deprecated Prüfe bei eigenen Gadgets und Lua-Modulen, ob du mw.loader-Hooks nutzt
ResourceLoader mw.loader.using verhält sich strenger JS, das Lazy-Load nutzt, sollte angepasst werden
Semantic MediaWiki 5.2 (optional) Erscheint zeitnah und optimiert 1.44-Support Du kannst bei Gelegenheit upgraden, sobald getestet

🧰 4. Nacharbeiten & Feintuning

  • runJobs neu starten: php maintenance/runJobs.php --maxjobs=100
  • Rebuilds bei SMW: php extensions/SemanticMediaWiki/maintenance/rebuildData.php -f
  • ElasticSearch: Falls CirrusSearch läuft: (führt zum Verlust des Index, wenn Extension:Wikibase aktiv ist!) 
    php extensions/CirrusSearch/maintenance/updateSearchIndexConfig.php
php extensions/CirrusSearch/maintenance/reindexDocs.php --skipLinks --indexOnSkip
  • PHP OPCache leeren (nach Webserver-Restart): sudo apachectl restart (falscher Befehl, da brew httpd!)
  • Finaler Check: Special:Version → prüfe MW 1.44.x, SMW-Version, alle Extensions „enabled“.

Wenn du magst, kann ich dir:

  • eine bash-Checkliste (copy-paste-fähig) für deinen M1-Server schreiben, oder
  • eine Kurzliste der Dateien, die beim Update nicht überschrieben werden dürfen,

damit du’s beim eigentlichen Wechsel stressfrei hast.

Möchtest du eine dieser beiden Varianten?

composer.local.json Setup

Fehlermeldungen nach update

Danke für all deine Hinweise und Anmerkungen. Überprüfe bitte für mich, welche composer Version ich für MediaWiki 1.44 brauche.

Ich muß für Semantic MediaWiki "composer update --no-dev" laufen lassen bekomme jedoch reichlich Fehlermeldungen:

Fehlermeldungen nach update 
> MediaWiki\Composer\VersionChecker::onEvent
Loading composer repositories with package information
Updating dependencies                                 
Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Root composer.json requires composer/installers ^2.0, ^2.2.0|^1.0.1, ^1.0.1, found composer/installers[dev-dependabot/github_actions/actions/checkout-5, dev-main, v1.0.0, ..., 1.x-dev, v2.0.0-alpha1, ..., 2.x-dev (alias of dev-main)] but it does not match the constraint.
  Problem 2
    - Root composer.json requires mediawiki/page-forms ^5.9.1 -> satisfiable by mediawiki/page-forms[5.9.1].
    - mediawiki/page-forms 5.9.1 requires composer/installers ^2|^1.0.1 -> found composer/installers[v1.0.1, ..., v1.12.0, v2.0.0, ..., v2.3.0] but it conflicts with your root composer.json require (^2.0, ^2.2.0|^1.0.1, ^1.0.1).
  Problem 3
    - Root composer.json requires mediawiki/semantic-media-wiki ~5.0 -> satisfiable by mediawiki/semantic-media-wiki[5.0.0, 5.0.1, 5.0.2, 5.1.0].
    - mediawiki/semantic-media-wiki[5.0.0, ..., 5.1.0] require composer/installers ^2.2.0|^1.0.1 -> found composer/installers[v1.0.1, ..., v1.12.0, v2.2.0, v2.3.0] but it conflicts with your root composer.json require (^2.0, ^2.2.0|^1.0.1, ^1.0.1).
  Problem 4
    - Root composer.json requires mediawiki/semantic-glossary ~5.0 -> satisfiable by mediawiki/semantic-glossary[5.0.1].
    - mediawiki/semantic-glossary 5.0.1 requires composer/installers >=1.0.1 -> found composer/installers[v1.0.1, ..., v1.12.0, v2.0.0, ..., v2.3.0] but it conflicts with your root composer.json require (^2.0, ^2.2.0|^1.0.1, ^1.0.1).
  Problem 5
    - Root composer.json requires mediawiki/mermaid ~6.0.1 -> satisfiable by mediawiki/mermaid[6.0.1].
    - mediawiki/mermaid 6.0.1 requires composer/installers ^2.2.0|^1.0.1 -> found composer/installers[v1.0.1, ..., v1.12.0, v2.2.0, v2.3.0] but it conflicts with your root composer.json require (^2.0, ^2.2.0|^1.0.1, ^1.0.1).
  Problem 6
    - Root composer.json requires mwstake/mediawiki-component-formengine ~3 -> satisfiable by mwstake/mediawiki-component-formengine[3.0.0, ..., 3.0.9].
    - mwstake/mediawiki-component-formengine[3.0.0, ..., 3.0.9] require composer/installers ~1.0|~2 -> found composer/installers[v1.0.0, ..., v1.12.0, v2.0.0, ..., v2.3.0] but it conflicts with your root composer.json require (^2.0, ^2.2.0|^1.0.1, ^1.0.1).

Use the option --with-all-dependencies (-W) to allow upgrades, downgrades and removals for packages currently locked to specific versions.

Ende der Fehlermeldungen.

MediaWiki 1.43 läuft mit dem Setup composer.local.json:
    "require": {
        "composer/installers": "^2.0",      
        "mediawiki/page-forms": "^5.9.1",
        "mediawiki/semantic-media-wiki": "~5.0",
        "mediawiki/semantic-glossary": "~5.0",
        "mediawiki/mermaid": "~6.0.1"
    },

ChatGPT:

Längeres Nachdenken für eine bessere Antwort
Überprüfen der Composer-Abhängigkeitsanforderungen für MediaWiki 1.44

Die Mailingliste sagt, dass MW 1.44 Composer 1.x entfernt und Composer 2.x benötigt. Das bedeutet, Composer 2.x ist erforderlich. Die Fehlermeldung betrifft jedoch den Konflikt der composer/installers-Versionsbeschränkung. Wir sollten die Version auf "^2.2.0 || ^1.0.1" setzen, um Abhängigkeitskonflikte zu vermeiden. Mehrere Erweiterungen erfordern diese Mindestversionen.

Searching Composer-Versionen und Abhängigkeitskonflikte

MW 1.44 benötigt Composer 2.x, und der beste Ansatz für Installationsbeschränkungen ist "^2|^1.0.1", aber einige Pakete erfordern mindestens ^2.2.0. Der Fehler entsteht wegen mehrfacher Constraints. Lösung: Entferne die explizite Zeile aus composer.local.json oder setze sie auf "^2.3" und verwende den -W-Flag für Updates.

Fertig

Kurz & präzise:

Welche Composer-Version braucht MediaWiki 1.44?

MediaWiki 1.44 erfordert Composer 2.x (Composer 1 wird nicht mehr unterstützt). Quelle: offizielle Ankündigung zur 1.44-Release-Serie. lists.wikimedia.org

TL;DR: Composer 2.x (z. B. 2.7/2.8) ist korrekt für MW 1.44. PHP-Basis: ≥ 8.1.0. MediaWiki+1

Warum deine composer update --no-dev scheitert

Alle gezeigten Konflikte drehen sich um composer/installers. Einige deiner Pakete verlangen mindestens ^2.2.0oder ^1.0.1 (Fallback für Altumgebungen). Wenn du im composer.local.json "composer/installers": "^2.0"pinnst, kollidiert das mit Abhängigkeiten, die ^2.2.0 fordern (u. a. SMW 5.x, Mermaid, teils Page Forms). Best-Practice ist, gar nicht selbst zu pinnen – oder den Range "^2.2.0 || ^1.0.1" zu erlauben. MediaWiki

Zusätzlich ist für SMW 5.x die Installation/Updates via Composer dokumentiert; das ändert aber nichts am Kernproblem (Installers-Constraint). Semantic MediaWiki+1

Saubere Lösung (empfohlen)

  1. Entferne die explizite Zeile zu composer/installers in deiner composer.local.json. Lass die Transitivabhängigkeiten entscheiden – damit landet Composer automatisch auf einer kompatiblen 2.2+-Version.
  2. Oder (wenn du es explizit halten willst): ersetze durch "composer/installers": "^2.2.0 || ^1.0.1" Das erfüllt die strikteren Anforderungen deiner Pakete. MediaWiki
  3. Führe dann (gerne im MW-Root) aus:
    composer clear-cache
composer update --no-dev -W
    Der Schalter -W erlaubt ggf. notwendige Up-/Downgrades in der Abhängigkeitskette (genau das, was Composer dir vorgeschlagen hat).

Zu deinen konkreten Paket-Ranges

Dein aktueller Ausschnitt:

"require": {
  "composer/installers": "^2.0",
  "mediawiki/page-forms": "^5.9.1",
  "mediawiki/semantic-media-wiki": "~5.0",
  "mediawiki/semantic-glossary": "~5.0",
  "mediawiki/mermaid": "~6.0.1"
}

Anpassungsvorschlag (minimal-invasiv):

"require": {
  "mediawiki/page-forms": "^5.9.1",
  "mediawiki/semantic-media-wiki": "~5.0",
  "mediawiki/semantic-glossary": "~5.0",
  "mediawiki/mermaid": "~6.0.1"
}

(Zeile composer/installers entfernt.) Alternative (explizit, aber kompatibel):

"require": {
  "composer/installers": "^2.2.0 || ^1.0.1",
  "mediawiki/page-forms": "^5.9.1",
  "mediawiki/semantic-media-wiki": "~5.0",
  "mediawiki/semantic-glossary": "~5.0",
  "mediawiki/mermaid": "~6.0.1"
}

Hinweis zu Versionen:

  • SMW: Für MW 1.44 ist SMW 5.x passend; 5.1.0 ist aktuell empfohlen (kannst du später anheben, falls gewünscht). Semantic MediaWiki
  • Page Forms: Die Doku zeigt mittlerweile Beispiele mit ^6.x; 5.9.1 funktioniert i. d. R. weiterhin, ein Upgrade auf 6.x ist optional. MediaWiki

Prüfschritte nach der Korrektur

  1. composer validate
  2. composer update --no-dev -W
  3. php maintenance/update.php
  4. Special:Version & SMW-Seiten testen.

Wenn du magst, passe ich dir deine exakte composer.local.json an (inkl. ggf. Umstieg auf ^5.1.0 für SMW) und notiere die exakten Befehle für deinen M1-Server-Pfad.

Du:

Mit "composer/installers": "^2.2.0 || ^1.0.1" funktioniert   composer update --no-dev.

Man muß die gesamten Semantic MediaWiki Extensions vor "omposer update --no-dev" aus dem Extension-Ordner löschen – ansonsten bleibt das update hängen oder die Extensions werden doppelt registriert.

"php maintenance/run.php update" lief ohne Fehler durch.

Nun läuft "php extensions/SemanticMediaWiki/maintenance/setupStore.php" und mein WikiMedia zeigt eine Semantic MediaWiki Service-Seite wegen Update auf MediaWikki 1.44.2 was ich abwarten muß: "Adding supplement jobs ..."

ChatGPT:

Längeres Nachdenken für eine bessere Antwort
Ich werde sicherstellen, dass ich die Situation richtig verstehe. Die Erwähnung von "Adding supplement jobs" deutet darauf hin, dass es bei der Konfiguration eine Blockade gibt. Ich werde nach den relevanten Informationen suchen und den Benutzer über die nächsten Schritte informieren. Wahrscheinlich hilft auch, die Logs und die Queue zu überprüfen.

Searching for Semantic MediaWiki setupStore guidance

Es scheint, dass "Adding supplement jobs..." normal ist, und die Benutzer sollten den Job-Queue prüfen. Wenn es langsam ist, können sie Optionen wie --skip-import oder --skip-optimize verwenden. Die speziellen Seiten wie Special:SemanticMediaWiki können nach dem Abschluss bereinigt werden. Ich werde praktische Befehle wie “php maintenance/runJobs.php” bereitstellen.

Fertig

Super, das klingt alles exakt richtig – vor allem dein Workaround mit

"composer/installers": "^2.2.0 || ^1.0.1" und dem leeren Extensions-Ordner vor composer update. 👍

Zu deinem aktuellen Punkt („setupStore.php … Adding supplement jobs …“ + Service-Seite):

Was passiert da?

  • setupStore.php richtet den SMW-Store ein und stößt zusätzliche Jobs an (sog. supplement jobs). Das ist normal und seit SMW 3.x so vorgesehen. Semantic MediaWiki
  • Je nach Datenmenge kann das dauern; die Service-Seite bleibt sichtbar, bis die Aufgaben abgearbeitet sind bzw. der Setup-Status aktualisiert ist. Semantic MediaWiki

So bringst du die Jobs sauber durch

1) Job-Queue aktiv leeren (du bist Single-User, also ruhig „blocking“):
  1. php maintenance/runJobs.php --maxjobs=500 --wait
# ggf. mehrfach, bis 0 Jobs übrig sind

Vorher/Nebenbei kannst du den Stand prüfen: php maintenance/showJobs.php

2) Falls es dir zu lange dauert (große Wikis) – setupStore.php mit Skip-Flags:
  • Import überspringen: php extensions/SemanticMediaWiki/maintenance/setupStore.php --skip-import
  • Optimierung überspringen: php extensions/SemanticMediaWiki/maintenance/setupStore.php --skip-optimize

Das ist inhaltlich unkritisch; Import/Optimierung kann man später gezielt nachholen. Semantic MediaWiki+1

  1. Nachlauf (wenn die Service-Seite noch mahnt):
  • Datenreparatur/Neu­aufbau über Spezialseite SemanticMediaWiki → „Data repair and update“, oder CLI-seitig mit deinen gewohnten Rebuild-Skripten. Semantic MediaWiki+1

Kompatibilität & Versionshinweis

  • Du bist jetzt auf MediaWiki 1.44.2 – passt. MediaWiki
  • SMW 5.x läuft damit grundsätzlich, aber SMW 6.0.1 ist seit Aug 2025 offiziell für MW 1.43–1.44 empfohlen (reine Bugfixes). Ein späteres, ruhiges Anheben auf 6.0.1 wäre sinnvoll. Semantic MediaWiki

Checks, die ich jetzt noch machen würde

  • Special:Version und Special:SemanticStatistics öffnen.
  • Wenn du Cirrus/Elastic einsetzt: nach Store-Setup die Search-Jobs laufen lassen (Index-Rebuild wie gewohnt).
  • Job-Queue final auf 0 prüfen:

Wenn du mir sagst, wie groß deine SMW-Tabellen ungefähr sind, gebe ich dir eine konkrete Reihenfolge (inkl. sinnvollen --maxjobs-Werten) für den Durchlauf, damit die Service-Seite maximal schnell verschwindet.

Du:

Ich habe jetzt erst festgestellt das "php extensions/SemanticMediaWiki/maintenance/setupStore.php" erst losläuft und dann am Ende hängen bleibt.

Fehlermeldung SMM 
Adding jobs ...
   ... Property statistics rebuild job ...[233bb0eeef39e93e2736abca] [no req]   TypeError: SMW\MediaWiki\Jobs\PropertyStatisticsRebuildJob::__construct(): Argument #1 ($title) must be of type Title, MediaWiki\Title\Title given, called in /Library/WebServer/Documents/mediawiki/extensions/SemanticMediaWiki/src/SQLStore/Installer.php on line 401
Backtrace:
from /Library/WebServer/Documents/mediawiki/extensions/SemanticMediaWiki/src/MediaWiki/Jobs/PropertyStatisticsRebuildJob.php(23)
#0 /Library/WebServer/Documents/mediawiki/extensions/SemanticMediaWiki/src/SQLStore/Installer.php(401): SMW\MediaWiki\Jobs\PropertyStatisticsRebuildJob->__construct(MediaWiki\Title\Title, array)
#1 /Library/WebServer/Documents/mediawiki/extensions/SemanticMediaWiki/src/SQLStore/Installer.php(252): SMW\SQLStore\Installer->addSupplementJobs()
#2 /Library/WebServer/Documents/mediawiki/extensions/SemanticMediaWiki/src/SQLStore/SQLStore.php(439): SMW\SQLStore\Installer->install(SMW\Options)
#3 /Library/WebServer/Documents/mediawiki/extensions/SemanticMediaWiki/src/SPARQLStore/SPARQLStore.php(424): SMW\SQLStore\SQLStore->setup(SMW\Options)
#4 /Library/WebServer/Documents/mediawiki/extensions/SemanticMediaWiki/maintenance/setupStore.php(167): SMW\SPARQLStore\SPARQLStore->setup(SMW\Options)
#5 /Library/WebServer/Documents/mediawiki/maintenance/includes/MaintenanceRunner.php(694): SMW\Maintenance\setupStore->execute()
#6 /Library/WebServer/Documents/mediawiki/maintenance/doMaintenance.php(100): MediaWiki\Maintenance\MaintenanceRunner->run()
#7 /Library/WebServer/Documents/mediawiki/extensions/SemanticMediaWiki/maintenance/setupStore.php(276): require_once(string)
#8 {main}

Was könnte die Ursache sein?

ChatGPT:

Längeres Nachdenken für eine bessere Antwort
Es scheint ein Fehler aufgrund einer Typzuordnungsänderung in MW 1.36+ zu sein – von der globalen Title-Klasse zur MediaWiki\Title\Title-Klasse. Die SMW-Version könnte nicht mit MW 1.44 kompatibel sein. Wahrscheinlich muss SMW auf die neueste Version aktualisiert werden, um den Fehler zu beheben.

Fehlerbehebung bei inkompatiblen Title-Klassen in SMW

Die Release-Notizen 1.44 zeigen, dass alte Klassennamen und Aliase entfernt wurden. Ich muss überprüfen, ob der Alias für die „Title“-Klasse auch entfernt wurde. Der Ausschnitt der Release-Notizen zeigt zwar einige Aliase, aber ich werde genauer nach dem „Title“-Alias suchen, um sicher zu sein.

Durchsuchen von Versionshinweisen nach Titel-Alias

Die Release-Notizen zeigen, dass der \Title-Alias entfernt wurde, was den Fehler erklärt. SMW verwendet noch den globalen \Title-Typ, während MW den \MediaWiki\Title\Title-Typ übergibt. Lösung: Upgrade von SMW auf Version 6.0.1 und Anpassung aller SMW-Erweiterungen. Eventuell auch den Composer-Installations-Tag anpassen.

Searching for SMW Title type hint issues

Fertig

Kurzdiagnose:

Das ist ein Namespaces-Bruch zwischen MediaWiki 1.44 und deiner SMW-Version. In MW 1.44 wurden die alten Klassen-Aliasse endgültig entfernt – u. a. \Title → \MediaWiki\Title\Title. Deine SMW-Jobs (PropertyStatisticsRebuildJob) erwarten noch den alten Typ Title, bekommen aber das neue Objekt MediaWiki\Title\Title → daher der TypeError. MediaWiki

Lösung (sauber & dauerhaft)

→ SMW auf 6.0.x anheben (mind. 6.0.0, besser 6.0.1). Diese Versionen sind explizit kompatibel mit MW 1.43–1.44 und berücksichtigen die geänderten Core-Typen. Semantic MediaWiki+1

Schritte

1) composer.local.json anpassen (ohne eigenen Pin für composer/installers, den hast du ja schon korrekt gelöst):
  1. {
  "require": {
    "mediawiki/semantic-media-wiki": "^6.0.1",
    "mediawiki/semantic-glossary": "^6.0",
    "mediawiki/page-forms": "^6.0",
    "mediawiki/mermaid": "~6.0.1"
  }
}

(Versionen von Glossary/PageForms ggf. an deine übrigen Extensions anpassen; wichtig ist SMW ≥ 6.0.)

2) Dann im MW-Root:

Schneller Workaround (nur falls du erst später upgraden willst):

composer clear-cache
composer update --no-dev -W
php maintenance/update.php
php extensions/SemanticMediaWiki/maintenance/setupStore.php
php maintenance/runJobs.php --wait --maxjobs=500

Als kurzfristige Krücke könntest du den alten Alias selbst setzen, bevor SMW geladen wird:

// In LocalSettings.php, sehr früh:
if (!class_exists('Title') && class_exists(MediaWiki\Title\Title::class)) {
    class_alias(MediaWiki\Title\Title::class, 'Title');
}

Das entschärft den Typkonflikt für betroffene SMW-Klassen, ist aber nur eine Übergangslösung. Offiziell wurde der Alias in 1.44 entfernt – langfristig solltest du auf SMW 6.x gehen. MediaWiki

Wenn du willst,

prüfe ich dir die exakten kompatiblen Versionen deiner SMW-Addons (Glossary, Page Forms, ggf. Maps, Mermaid) für MW 1.44 und liefere dir ein passgenaues composer.local.json.

Du:

Gut , dann brauche ich vorba noch die aktulelle Version für mediawiki/semantic-compound-queries": "~3",

ChatGPT:

Längeres Nachdenken für eine bessere Antwort
Längeres Nachdenken für eine bessere Antwort

Suchen nach kompatiblen Versionen für Semantic Compound Queries

Öffnen der Packagist-Seite für Versionsanforderungen

Die

Fertig

Kurz & präzise:

  • Aktuell stabil: mediawiki/semantic-compound-queries 3.0.0 (Release: 14. Sep. 2025). packagist.org
  • Kompatibilität: PHP ≥ 7.4, MediaWiki ≥ 1.39, SMW ≥ 4.0 → damit kompatibel zu MW 1.44 + SMW 6.x. packagist.org

Composer-Eintrag (empfohlen)

Wenn du „~3“ beibehalten willst, ist das korrekt; alternativ etwas expliziter:

"require": {
  "mediawiki/semantic-compound-queries": "^3.0"
}

Dein bereits gesetzter Workaround für composer/installers passt dazu (^2.2.0 || ^1.0.1). packagist.org

Befehle

composer update --no-dev -W
php maintenance/update.php
# (falls nötig) SMW-Setup/Jobs danach:
php extensions/SemanticMediaWiki/maintenance/setupStore.php
php maintenance/runJobs.php --wait --maxjobs=500

Wenn du möchtest, passe ich dir dein komplettes composer.local.json (SMW 6.0.1 + SCQ 3.0.0 + PageForms/Glossary/Mermaid) konsistent an.

Fehler nach Update durch /mediawiki/cache

Du:

Ich bin einen Schritt Weiter lande in den nächsten Fehler. Was bedeutet Folgendes?:

Warning: Failed to open stream: Permission denied in 
Warning: dba_open(/Library/WebServer/Documents/mediawiki/cache/l10n_cache-en.cdb.tmp.618070387): Failed to open stream: Permission denied in /Library/WebServer/Documents/mediawiki/vendor/wikimedia/cdb/src/Writer/DBA.php on line 41
[bec3d4b9e710ad0a46d778a5] /Spezial:Spezialseiten Cdb\Exception: Unable to open CDB file for write "/Library/WebServer/Documents/mediawiki/cache/l10n_cache-en.cdb"

Backtrace:

from /Library/WebServer/Documents/mediawiki/vendor/wikimedia/cdb/src/Writer/DBA.php(43)
#0 /Library/WebServer/Documents/mediawiki/vendor/wikimedia/cdb/src/Writer.php(49): Cdb\Writer\DBA->__construct(string)
#1 /Library/WebServer/Documents/mediawiki/includes/language/LCStoreCDB.php(97): Cdb\Writer::open(string)
#2 /Library/WebServer/Documents/mediawiki/includes/language/LocalisationCache.php(1286): LCStoreCDB->startWrite(string)
#3 /Library/WebServer/Documents/mediawiki/includes/language/LocalisationCache.php(615): LocalisationCache->recache(string)
#4 /Library/WebServer/Documents/mediawiki/includes/language/LocalisationCache.php(524): LocalisationCache->initLanguage(string)
#5 /Library/WebServer/Documents/mediawiki/includes/language/LocalisationCache.php(404): LocalisationCache->loadSubitem(string, string, string)
#6 /Library/WebServer/Documents/mediawiki/includes/language/MessageCache.php(684): LocalisationCache->getSubitem(string, string, string)
#7 /Library/WebServer/Documents/mediawiki/includes/language/MessageCache.php(1306): MessageCache->isMainCacheable(string, string)
#8 /Library/WebServer/Documents/mediawiki/includes/language/MessageCache.php(1223): MessageCache->getMsgFromNamespace(string, string)
#9 /Library/WebServer/Documents/mediawiki/includes/language/MessageCache.php(1146): MessageCache->getMessageForLang(string, string, bool, array, MediaWiki\Language\MessageInfo)
#10 /Library/WebServer/Documents/mediawiki/includes/language/MessageCache.php(1041): MessageCache->getMessageFromFallbackChain(string, string, bool, MediaWiki\Language\MessageInfo)
#11 /Library/WebServer/Documents/mediawiki/includes/language/Message/Message.php(1545): MessageCache->get(string, bool, string, MediaWiki\Language\MessageInfo)
#12 /Library/WebServer/Documents/mediawiki/includes/language/Message/Message.php(1223): MediaWiki\Message\Message->fetchMessage()
#13 /Library/WebServer/Documents/mediawiki/includes/specialpage/SpecialPage.php(802): MediaWiki\Message\Message->isDisabled()
#14 /Library/WebServer/Documents/mediawiki/includes/specials/SpecialSpecialPages.php(43): MediaWiki\SpecialPage\SpecialPage->outputHeader()
#15 /Library/WebServer/Documents/mediawiki/includes/specialpage/SpecialPage.php(734): MediaWiki\Specials\SpecialSpecialPages->execute(null)
#16 /Library/WebServer/Documents/mediawiki/includes/specialpage/SpecialPageFactory.php(1731): MediaWiki\SpecialPage\SpecialPage->run(null)
#17 /Library/WebServer/Documents/mediawiki/includes/actions/ActionEntryPoint.php(499): MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, MediaWiki\Context\RequestContext)
#18 /Library/WebServer/Documents/mediawiki/includes/actions/ActionEntryPoint.php(143): MediaWiki\Actions\ActionEntryPoint->performRequest()
#19 /Library/WebServer/Documents/mediawiki/includes/MediaWikiEntryPoint.php(202): MediaWiki\Actions\ActionEntryPoint->execute()
#20 /Library/WebServer/Documents/mediawiki/index.php(58): MediaWiki\MediaWikiEntryPoint->run()
#21 {main}

ChatGPT:

Längeres Nachdenken für eine bessere Antwort
Fertig

Kurzfassung: Schreibrechte im cache/-Ordner fehlen (oder falscher Besitzer) → MediaWiki kann die LocalisationCache-Datei (l10n_cache-*.cdb) nicht neu schreiben. Häufige Ursache: Wartungsskripte (CLI) wurden als anderer User ausgeführt als der Webserver – die erzeugten Dateien gehören dann „dir“, nicht dem Webserver-User.

Was genau passiert?

  • MW 1.44 nutzt standardmäßig LCStoreCDB und schreibt CDB-Dateien nach "$IP/cache" (hier: /Library/WebServer/Documents/mediawiki/cache).
  • Beim Schreiben entsteht erst eine Temp-Datei *.cdb.tmp.*. Dazu braucht der Webserver-User Schreibrechte im Verzeichnis. Fehlen sie → Permission denied.

Fix (macOS, Apache läuft i. d. R. als _www)

  1. Besitz & Rechte korrigieren (einmalig, rekursiv):
  2. sudo chown -R _www:_www /Library/WebServer/Documents/mediawiki/cache
sudo find /Library/WebServer/Documents/mediawiki/cache -type d -exec chmod 775 {} \;
sudo find /Library/WebServer/Documents/mediawiki/cache -type f -exec chmod 664 {} \;
    Alte L10n-Caches löschen (falls „root“ o. ä. Besitzer):
    sudo rm -f /Library/WebServer/Documents/mediawiki/cache/l10n_cache-*.cdb*
  3. L10n-Cache sauber neu aufbauen – am besten als Webserver-User:
    cd /Library/WebServer/Documents/mediawiki
sudo -u _www php maintenance/rebuildLocalisationCache.php --force
  4. Sinnvolle Konfig-Absicherung (in LocalSettings.php, Pfad anpassen):
    $wgCacheDirectory = "$IP/cache"; // sicherstellen, dass gesetzt & beschreibbar
// optional explizit:
$wgLocalisationCacheConf['storeDirectory'] = "$IP/cache";

Merke: Wenn du künftig Wartungsskripte (SMW setupStore, reindex, runJobs, …) nicht als _www ausführst, setze danach die Besitzrechte im cache/ wieder korrekt – sonst passiert der Fehler erneut.

Alternative (nur als kurzfristige Krücke)

  • Temporär auf „Datei-Store“ oder „Array“ umstellen (langsamer/mehr RAM): $wgLocalisationCacheConf['store'] = 'file'; // oder: 'array' (nicht empfohlen dauerhaft)

Besser bleibt aber der saubere Rechte-Fix oben.

Wenn du willst, prüfe ich dir kurz, welcher User deine Apache-Prozesse tatsächlich nutzt, und passe die Befehle an (z. B. ps aux | grep httpd).

Fehler nach Update durch alte Vector-2022 Skin

Du:

Ich bin mit der Fehlersuche weiter.

Es war nichts von all dem – ich mußte die VectorSkin neu installieren und hatte sie zuvor von MediaWiki 143 übernommen – das war mein Fehler.

Nun ist Semantic MediaWiki wieder online.

Ich habe noch folgende debug Meldung: 

Deprecated: Use of MediaWiki\Skin\Skin::appendSpecialPagesLinkIfAbsent was deprecated in MediaWiki 1.44. [Called from MediaWiki\Skin\Skin::buildSidebar in /Library/WebServer/Documents/mediawiki/includes/skins/Skin.php at line 1639] in /Library/WebServer/Documents/mediawiki/includes/debug/MWDebug.php on line 386

Recherchiere bite, was ich da tun kann.

ChatGPT:

Längeres Nachdenken für eine bessere Antwort
Durchsuchen des Webs nach MediaWiki 1.44 Deprecations

Anleitung zur Behebung der Sidebar-Warnung

Bearbeiten der MediaWiki:Sidebar für spezielle Seitenlinks

Um das Problem zu lösen, sollte ich entweder den Link explizit hinzufügen oder die Veraltung durch Bearbeiten der MediaWiki:Sidebar entfernen. Für die deutsche Version könnte eine Lokalisierung notwendig sein, sodass der Text "specialpages" korrekt erscheint. Ich denke, dass eine direkte Methode wie Special:SpecialPages|specialpages am besten ist. Außerdem sollte der Cache gelöscht und neu erstellt werden, um sicherzustellen, dass alles korrekt funktioniert.

Fertig

Kurz gesagt: Das ist kein Fehler, sondern eine gezielte 1.44-Übergangs-Warnung.

Sie erscheint, wenn dein MediaWiki:Sidebar bereits angepasst ist und der Link zu Spezialseiten dort nicht explizitsteht. Dann fügt Core ihn „automatisch“ hinzu – und genau dieses automatische Einfügen löst die Deprecation aus. Lösung: Link selbst in MediaWiki:Sidebar eintragen; danach verschwindet die Warnung. MediaWiki+1

Fix in 2 Minuten

  1. MediaWiki:Sidebar öffnen/erstellen und im Bereich * navigation den Eintrag explizit setzen, z. B.:
    * navigation
** mainpage|mainpage-description
** recentchanges-url|recentchanges
** Special:SpecialPages|specialpages
    (Robust und sprachunabhängig: Special:SpecialPages|specialpages. Alternativ geht auch das Muster mit ...-url, falls es für deine Sprache hinterlegt ist.) MediaWiki
  2. Caches leeren (nach dem Speichern):
    # optional, aber hilfreich
php maintenance/rebuildLocalisationCache.php --force
php maintenance/runJobs.php --wait --maxjobs=200
# und einmal die Startseite mit ?action=purge aufrufen

Hintergrund

  • In MW 1.44 wurde der Link „Spezialseiten“ aus dem „Toolbox“-Block in die Standard-Sidebar verlagert. Um wikis mit angepasster Sidebar nicht plötzlich ohne Link dastehen zu lassen, hängt Core ihn bis MW 1.45automatisch an – mit Deprecation-Hinweis, damit Admins die Sidebar dauerhaft korrigieren. MediaWiki+1

Falls du die Sidebar bewusst ohne „Spezialseiten“ führen willst: setze den Eintrag trotzdem explizit und „entferne“ ihn, indem du als Ziel ein - setzt – dann wird er ausgeblendet, und die Deprecation verschwindet trotzdem (Mechanik der Sidebar-Parserlogik). Details siehe Sidebar-Doku. MediaWiki

Wenn du möchtest, schaue ich mir deine aktuelle MediaWiki:Sidebar an und gebe dir eine schlanke, mehrsprachige Fassung passend zu Vector-2022 (inkl. TOOLBOX-Elementen ab 1.43).

weiter mit Gespräch:Fehlerbehebung Lingo Extension nach MediaWiki 1.44 Update

Abgerufen von „https://aufeinwort.info/w/index.php?title=Gespräch:MediaWIki_Update_1.43_auf_1.44.2&oldid=149409“