Gespräch:Fehler bei SiteLink Erstellung

Über diese Seite Gespräch

ChatGPT Sophos GPT-5.2 Thinking
27. November 2025 n. Chr. erst.
16.36 Uhr Ausgabe 02
Ausgabe 02
unüberarbeitet ungeprüft

Hallo Sophos,

wenn ich in meinem Wikibase zu meinem localen Repo winen SiteLink von Q14 "Johann Wolfgang von Goethe" zur Wikiseite "Johann Wolfgang von Goethe" über aewi erstellen will, dann erhalte ich folgende Meldung:

Die Seite „Johann Wolfgang von Goethe“ konnte nicht auf „aewi“ gefunden werden.

Die externe Website „aewi“ hat keine Informationen zur Seite „Johann Wolfgang von Goethe“ bereitgestellt.

An sich hatte dies bereits funktioniert. Inzwischen habe ich den SQL-Prefix "wiki_" entfernt und den Namen der SQL-Datenbank von "mediawiki" auf "aewi" geändert. "aewi" ist auch site_global_key und site_group in der SQL-Tabele sites. MediaWiki funktioniert an sich fehlerfrei und Indexe hatte ich neu angelegt.

Was könnte an Fehler oder Ursache vorliegen?

ChatGPT:

(27. Nov. 2025, 16:36)

Hallo Nikolaos,

das Fehlerbild („Die externe Website ‚aewi‘ hat keine Informationen …“) entsteht fast immer, wenn Wikibase beim Validieren des Sitelinks die Zielseite über die in der sites-Tabelle hinterlegten Pfade nicht korrekt abfragen kann. Nach deiner DB-Umbenennung sind vor allem diese Punkte kritisch:

Wahrscheinlichste Ursachen (kurz)

sites-Eintrag inkonsistent (falscher site_group, site_pagepath, site_api_path, Protokoll/Host). Für Sitelinks muss beides gesetzt sein und $1 enthalten. MediaWiki
Gruppen-Mismatch: site_group des sites-Eintrags passt nicht zu deinen siteLinkGroups im Repo/Client. MediaWiki
Site-ID/DB-IDs nach Umbennenung nicht angepasst (siteGlobalID, localClientDatabases, ggf. repoDatabase/changesDatabase). MediaWiki
Zielseite ist Redirect – Sitelinks auf Redirects sind standardmäßig nicht erlaubt. phabricator.wikimedia.org

Schnelltest (in dieser Reihenfolge)

Existenz/Redirect prüfen (API): Aufrufen (im Browser reicht): https://wiki.aewi.de/w/api.php?action=query&prop=info&titles=Johann%20Wolfgang%20von%20Goethe&format=json → Muss mit missing=false und ohne Redirect zurückkommen.
sites-Zeile kontrollieren (SQL):
```
SELECT site_global_key, site_group, site_type, site_protocol, site_domain,
       site_path AS pagepath, site_api_path
FROM sites
WHERE site_global_key='aewi'\G
```
Erwartet:
- site_type = mediawiki
- site_group = eine deiner Gruppen (z. B. default oder aewi)
- site_protocol = https
- site_domain = wiki.aewi.de (oder dein Host)
- pagepath = /wiki/$1
- site_api_path = /w/api.php Falls abweichend → korrigieren (siehe nächster Schritt). MediaWiki
Eintrag sauber neu setzen (überschreiben):
```
php maintenance/addSite.php aewi default \
  --interwiki-id aewi \
  --language de \
  --pagepath='https://wiki.aewi.de/wiki/$1' \
  --filepath='https://wiki.aewi.de/w/$1'
```
(Falls du statt default eine eigene Gruppe nutzt, diese hier einsetzen.) Wichtig: Danach Webserver/PHP-Prozesse neu laden, weil die sites-Tabelle gecacht wird. doc.wikimedia.org+2MediaWiki+2

Repo/Client-Konfiguration abgleichen (LocalSettings.php):

// Gruppen müssen zur sites.site_group passen
$wgWBRepoSettings['siteLinkGroups']   = [ 'aewi' ];   // oder ['default']
$wgWBClientSettings['siteLinkGroups'] = [ 'aewi' ];

// Client-Site-ID (dein Wiki selbst)
$wgWBClientSettings['siteGlobalID'] = 'aewi';

// (Nur wenn Repo + Client auf demselben Wiki): lokale DBs für Dispatching
$wgLocalDatabases = [ 'aewi' ];
$wgWBRepoSettings['localClientDatabases'] = [ 'aewi' => 'aewi' ];

(Siehe „Enabling sitelinks“ und Beziehung Repo/Client.) MediaWiki+1

Index/Cache für Sitelinks auffrischen (falls nötig):
```
php extensions/Wikibase/repo/maintenance/rebuildItemsPerSite.php
```
(Hilft, wenn das Mapping wb_items_per_site veraltet ist.) MediaWiki+1
Verifikation in der Oberfläche: Spezial:SetSiteLink im Repo benutzen und dort Site ID = aewi + Sitelink = Johann Wolfgang von Goethetesten; diese Seite gibt bei Fehlschlag oft die hilfreichste Meldung aus. MediaWiki

Noch zwei seltene Stolpersteine

Interwiki-Prefix: Falls du das Prefix aewi auch für echte Interwiki-Links nutzt, prüfe Spezial:Interwiki (ab MW 1.44 im Core verwaltet). Für Sitelinks ist es nicht zwingend, aber konsistent zu halten ist sinnvoll. MediaWiki+1
Redirect-Ziel verlinken: Wenn deine Seite ein Redirect ist, bitte den Zielartikel als Sitelink setzen. phabricator.wikimedia.org

Wenn du willst, gehe ich die aktuelle sites-Zeile mit dir durch (poste die Ausgabe der SELECT-Abfrage oben). Dann sehen wir in einem Blick, ob es „nur“ ein Pfad-/Gruppen-Mismatch ist oder ob die siteGlobalID/DB-Zuweisungen nachgezogen werden müssen.

Du:

zu Wahrscheinlichste Ursachen zu 1. site_pagepath und site_api_path sind nicht in der Tabelle sites Spalten:

site_id
site_global_key
site_type
site_group
site_source
site_language
site_protocol
site_domain
site_data
site_forward
site_config

zu 2. und 3. LocalSettings sind:

$wgWBClientSettings['siteGlobalID'] = $wgDBname;
$wgWBRepoSettings['siteGlobalID']   = $wgDBname;
$wgArticlePath = "/$1";
$wgDBname = "aewi";
$wgLocalDatabases = [ $wgDBname ];
$wgWBClientSettings['repoUrl']         = $wgCanonicalServer;  // "https://wiki.aewi.de"
$wgWBClientSettings['repoArticlePath'] = $wgArticlePath;      // "/$1"
$wgWBClientSettings['repoScriptPath']  = $wgScriptPath;       // "/mediawiki"
$wgWBClientSettings['siteGlobalID'] = $wgDBname;
$wgWBRepoSettings['siteGlobalID']   = $wgDBname;

4. Zielseite ist Wikiseite nicht Redirect, erreichbar unter https://wiki.aewi.de/Johann_Wolfgang_von_Goethe Schnelltest

zu Schnelltest 1. Existenz/Redirect prüfen: "query&prop" ist keine gültige api-Abfrage.

zu Schnelltest 2. "WHERE site_global_key='aewi'\G" #1064 - Fehler in der SQL-Syntax.

Bitte die korrekte Syntax im Handbuch nachschlagen bei '\G LIMIT 0, 25' in Zeile 4 zu Eintrag sauber neu setzen (überschreiben): gibt die Meldung "Site with global id aewi already exists."

1. Anmerkung: Ich nutze ShortURL seirt Anbeginn und muß daher in URL keinen Scriptpath angeben. Die Seite ist vorhanden!!!

2. Anmerkung: Weiteres aufgrund der Abfragefehler nicht ausgeführt. Wie lauten die richtigen Abfragen?

3. Anmerkung: Was ich noch inzwischen gemacht habe ist mittels cerbot das SSL Zertifikat erneut. Was auch nicht geht ist die Artikel Vorschau wenn man die Maus über einen Link hält.

4. Anmerkung: Die Abfrage "php maintenance/run.php exportSites php://stdout" enthält die richtigen ID's zu globalid, group und localid,

der Path ist

	<site type="mediawiki">
		<globalid>aewi</globalid>
		<group>aewi</group>
		<path type="page_path">https://wiki.aewi.de/$1</path>
		<path type="file_path">https://wiki.aewi.de/$1</path>
		<localid type="interwiki">aewi</localid>
	</site>

5. Anmerkung: curl -I 'https://wiki.aewi.de/api.php' HTTP/1.1 200 OK

6. Anmerkung: curl -I 'https://de.wikipedia.org/w/api.php' HTTP/1.1 200 OK

7. Anmerkung: Ich habe php maintenance/run.php refreshLinks gestartet

2025-11-27 17:14:24 cirrusSearchLinksUpdate kīnéō addedLinks=[] removedLinks=[] prioritize= update_kind=page_refresh root_event_time=1764263663 cluster= namespace=0 title=kīnéō requestId=fac058b1cf31e0d236764b75 (id=3158495,timestamp=20251127171423) STARTING

Muß bei "addedLinks=[]" und "removedLinks=[]" nicht ein Link drin stehen?

ChatGPT:

Danke für die präzisen Details – damit lässt sich das gut eingrenzen.

Was bei dir korrekt aussieht

Deine sites-Tabelle hat (ab MW ≥ 1.35) keine Spalten site_pagepath/site_api_path; die Pfade liegen als strukturierte Daten in site_data/site_config. Dein exportSites-Dump zeigt saubere Einträge für page_path/file_path. MediaWiki
repoUrl, repoArticlePath, repoScriptPath, siteGlobalID und DB-Name wirken konsistent.

Wo’s hakt (wahrscheinlich)

Sitelink-Gruppen nicht (mehr) deckungsgleich konfiguriert. Nach DB-/Konfig-Änderungen vergisst man leicht, auf Repo UND Client dieselben siteLinkGroups zu setzen – sonst akzeptiert das Repo zwar die Gruppe „aewi“, kann aber die Site nicht verwenden. Prüfe/ergänze untenstehende Zeilen auf beiden Seiten:
```
// dieselbe(n) Gruppe(n) auf Repo und Client
$wgWBRepoSettings['siteLinkGroups']   = [ 'aewi' ];
$wgWBClientSettings['siteLinkGroups'] = [ 'aewi' ];
```
(Siehe „Enabling sitelinks“/Advanced configuration.) Nach Änderungen Webserver/PHP-Prozesse neu laden, da die Sites-Tabelle lokal gecacht wird. MediaWiki
Sites-Cache nicht neu geladen. Selbst bei korrekten site_data/site_config greifen Änderungen erst nach Neustart langlaufender PHP-Prozesse (httpd/php-fpm) – genau das fordert die Doku auch nach addSite/importSites. MediaWiki+1
Existenzprüfung via API schlägt (still) fehl. Der von dir gesehene Hinweis („…hat keine Informationen…“) kommt, wenn die Ziel-Seite per API nicht als existent zurückkommt. Teste die Seite einmal exakt so (funktionierende Abfrage, Leerzeichen mit _):
```
https://wiki.aewi.de/api.php?action=query&prop=info&titles=Johann_Wolfgang_von_Goethe&format=json&formatversion=2
```
Erwartet: pages[0].missing nicht vorhanden. (Die API-Parameter sind genau so erforderlich.) MediaWiki

Konkrete Checks/Abfragen (korrigiert)

A) API-Check (existiert die Seite aus Sicht des Repos?)

URL wie oben aufrufen; wenn missing: true erscheint, sieht die Gegenstelle die Seite nicht → dann stimmt irgendwo Pfad/Rewrite/Title-Normalisierung nicht (oder es blockiert ein Zertifikats/CORS-Detail).

B) SQL-Check in phpMyAdmin (ohne `\G`)

\G ist eine MySQL-CLI-Darstellung, nicht SQL – in phpMyAdmin gibt’s dafür normale SELECTs. Nutze:

SELECT
  site_global_key, site_group, site_type, site_protocol, site_domain,
  CONVERT(site_data  USING utf8mb4) AS site_data_json,
  CONVERT(site_config USING utf8mb4) AS site_config_json
FROM sites
WHERE site_global_key = 'aewi';

Du solltest in site_data_json einen Block mit page_path (bei dir https://wiki.aewi.de/$1) und file_path sehen. (Felder & Caching siehe Handbuch zur sites-Tabelle.) MediaWiki

C) Sites-Eintrag notfalls per Script überschreiben

Wenn du den Eintrag aktualisieren willst (ohne manuell in site_data zu fummeln), nimm addSite/importSites. Beispiel für addSite (falls du vorher entfernst oder mit anderer GlobalID neu anlegst):

php maintenance/run.php addSite aewi aewi \
  --language de \
  --pagepath "https://wiki.aewi.de/$1" \
  --filepath "https://wiki.aewi.de/$1"
# danach Webserver/PHP neu laden

(Die Doku zeigt --pagepath/--filepath und fordert das Neuladen.) MediaWiki+1

D) Repo/Client – Minimal-Block nebeneinander (gegenseitig konsistent)

// Basis
$wgServer = 'https://wiki.aewi.de';
$wgCanonicalServer = $wgServer;
$wgScriptPath = '/mediawiki';     // wenn dein api.php unter /mediawiki liegt
$wgArticlePath = '/$1';           // dein ShortURL-Mapping

// Wikibase
$wgWBClientSettings['repoUrl']         = $wgCanonicalServer;
$wgWBClientSettings['repoArticlePath'] = $wgArticlePath;      // '/$1'
$wgWBClientSettings['repoScriptPath']  = $wgScriptPath;       // '/mediawiki'

$wgWBClientSettings['siteGlobalID'] = 'aewi';
$wgWBRepoSettings['siteGlobalID']   = 'aewi';

// WICHTIG für Sitelinks:
$wgWBRepoSettings['siteLinkGroups']   = [ 'aewi' ];
$wgWBClientSettings['siteLinkGroups'] = [ 'aewi' ];

(„Advanced configuration“ beschreibt die relevanten Settings und die Sitelink-Gruppen.) MediaWiki+1

Zu deinen Anmerkungen

„query&prop ist keine gültige Abfrage“ – korrekt; die gültige Form findest du oben (mit action=query&prop=info…).
SQL-Fehler \G – siehe B); das ist kein SQL, sondern nur ein CLI-Formatter.
addSite meldet „exists“ – erwartet; du kannst entweder mit importSites.php aus einer XML neu importieren oder den bestehenden Eintrag löschen/neu anlegen. Danach unbedingt Webserver/PHP neustarten, sonst sieht MediaWiki die Änderung nicht. MediaWiki
„Artikel-Vorschau bei Hover“ – das hängt an der Page-Previews-Funktion (RessourceLoader + API/REST). Nach Zertifikat-Wechsel kann ein Mixed-Content/CSP/Cache-Effekt stören. Prüf in der Browser-Konsole, ob Requests auf /api.php oder /api/rest_v1/page/summary/… fehlschlagen. (Faktisch separater Fall, aber oft gleichzeitig sichtbar, wenn der Server/Cache neu konfiguriert wurde.)
refreshLinks … addedLinks=[] removedLinks=[] – unauffällig. refreshLinks protokolliert nur Unterschiede. Wenn beim Neuparsen keine Linkänderung entsteht, bleiben die Arrays leer.

Kurz-Checkliste (in deiner Reihenfolge umsetzbar)

API-Existenztest der Zielseite (URL oben).
siteLinkGroups auf Repo & Client setzen → Webserver/PHP neu laden. MediaWiki
sites-Eintrag prüfen (SELECT oben) – stimmt page_path exakt? MediaWiki
Falls nötig Eintrag aktualisieren (addSite/importSites) → neu laden. MediaWiki+1
Erneut Sitelink setzen (Repo-Spezialseite). Wenn’s wieder scheitert: Debug-Log aktivieren($wgDebugLogGroups['Wikibase']/['Http']) und die letzte Fehlzeile hier posten – dann sehen wir die echte Ursache (z. B. SSL-Verify, Timeout, 404).

Wenn du magst, schick mir noch die Ausgabe von:

der API-URL oben,
und dem SELECT über sites (nur die JSON-Blöcke gekürzt). Dann gebe ich dir die exakten nächsten zwei Zeilen/Schritte.

ChatGPT:

Wahrscheinlichste Ursachen (kurz)

Schnelltest (in dieser Reihenfolge)

Noch zwei seltene Stolpersteine

Du:

ChatGPT:

Was bei dir korrekt aussieht

Wo’s hakt (wahrscheinlich)

Konkrete Checks/Abfragen (korrigiert)

A) API-Check (existiert die Seite aus Sicht des Repos?)

B) SQL-Check in phpMyAdmin (ohne \G)

C) Sites-Eintrag notfalls per Script überschreiben

D) Repo/Client – Minimal-Block nebeneinander (gegenseitig konsistent)

Zu deinen Anmerkungen

Kurz-Checkliste (in deiner Reihenfolge umsetzbar)

B) SQL-Check in phpMyAdmin (ohne `\G`)