Fehlerdiagnose

Ein Eintrag je Symptom. Umgebung jeweils: DokuWiki 2026-07-14b „Mort„, PHP 8.2 oder neuer, Komponenten dieses Hauses, sofern nicht anders angegeben.

Das Verfahren, auf das sich die Lösungen beziehen, steht unter Installieren, Aktivieren und Deaktivieren, Aktualisieren und Entfernen. Die Angaben je Komponente stehen in der Komponentenmatrix.

Umgebung: nach einer Installation von Hand oder nach dem Entpacken eines heruntergeladenen Archivs.

Ursache: Der Verzeichnisname weicht vom Feld base in plugin.info.txt ab. Archive aus einem Git-Server tragen den Zweig- oder Fassungsnamen im Ordner (wkcore-main, wkcore-1.2.0); DokuWiki lädt Komponenten aber über den Verzeichnisnamen. Seltener: Das Archiv wurde eine Ebene zu tief ausgepackt, sodass lib/plugins/wkcore/wkcore/ entstanden ist.

Lösung: Das Verzeichnis so umbenennen, dass es exakt dem Wert von base entspricht. Prüfen: cat lib/plugins/wkcore/plugin.info.txt — die erste Zeile nennt den geforderten Namen. Danach conf/local.php anfassen, damit die Zwischenspeicher verworfen werden.

Umgebung: Erweiterungsverwaltung führt die Komponente mit Namen, Autor und Datum auf; die erwartete Wirkung bleibt aus.

Ursache: Drei Ursachen erzeugen dasselbe Bild, weil die Suite bei fehlenden Diensten bewusst nicht scheitert, sondern Fähigkeiten weglässt:

1. Eine harte Abhängigkeit fehlt oder ist deaktiviert. Die Komponente lädt, findet ihren Dienst nicht und blendet die davon abhängigen Bedienelemente aus, statt beim Absenden zu scheitern.
2. Die Erstkonfiguration fehlt. Bei wkdoado ist die Liste erlaubter Hosts leer und erlaubt deshalb keine einzige Anfrage; bei wkdogit fehlt der Pfad zum Git-Programm. Beides ist der ausgelieferte Zustand und keine Fehlfunktion.
3. Die Auszeichnung ist falsch geschrieben. Fehlt bei {{wk:acmenu>…}} oder {{wk:snippet>…}} das >, greift DokuWikis eigene Medien-Auszeichnung {{ns:datei}} und erzeugt einen Verweis auf eine nicht vorhandene Mediendatei statt der erwarteten Ausgabe.

Lösung: In dieser Reihenfolge. Erst $conf['allowdebug'] = 1 setzen und ?do=wkcore_diag aufrufen: Steht der Dienst der Komponente dort nicht, ist ihr Programmcode nicht gelaufen — dann greift der vorige Eintrag dieser Seite. Steht er dort, die Abhängigkeitstabelle gegen die Erweiterungsverwaltung halten. Bleibt beides ohne Befund, die Tabelle zur Erstkonfiguration durchgehen. allowdebug danach wieder abschalten.

Umgebung: nach einem Austausch der Dateien von Hand, ohne den Erweiterungsmanager.

Ursache: DokuWikis Zwischenspeicher für Seiten, CSS und JavaScript hängen am Änderungsdatum der Konfigurationsdateien, nicht an den Dateien der Komponenten. Der Erweiterungsmanager fasst conf/local.php nach einer Installation selbst an und setzt zusätzlich einen etwaigen PHP-Bytecode-Zwischenspeicher zurück. Wer die Dateien von Hand austauscht, umgeht beides.

Lösung: conf/local.php anfassen (Änderungsdatum aktualisieren). Läuft ein Bytecode-Zwischenspeicher (OPcache), den Webserver-Prozess neu starten. Im Browser hart neu laden (Strg+F5), um dessen eigenen Zwischenspeicher zu umgehen.

Umgebung: Installation oder Aktualisierung über die Oberfläche.

Ursache: Bei einer Neuinstallation braucht der Webserver Schreibrecht auf lib/plugins/ bzw. lib/tpl/, bei einer Aktualisierung auf das Verzeichnis der Komponente selbst. Unter Windows kommt eine zweite Ursache hinzu, die genauso aussieht: das gesetzte Schreibschutz-Attribut auf einem Verzeichnis. PHPs is_writable() meldet dann false, obwohl die Zugriffsrechte stimmen.

Lösung: Rechte des Webserver-Kontos prüfen und setzen. Unter Windows zusätzlich das Schreibschutz-Attribut des Verzeichnisses entfernen. Wo das nicht in Frage kommt, bleibt der Weg über die Kommandozeile oder die Installation von Hand, siehe Von Hand — die Dateien müssen danach dem Konto gehören, unter dem der Webserver läuft.

Umgebung: eine Komponente wurde deaktiviert oder deinstalliert, eine andere zeigt daraufhin eine Meldung oder einen PHP-Fehler.

Ursache: Zu unterscheiden sind zwei Fälle. Eine Meldung über eine nicht verfügbare Fähigkeit ist der vorgesehene Fall: Die verbliebene Komponente hat eine weiche Abhängigkeit verloren und sagt das. Ein PHP-Fehler ist es nicht — dann war die Abhängigkeit hart, und die Abhängigkeitstabelle sagt, welche.

Lösung: Im ersten Fall entscheiden Sie, ob Sie die Meldung hinnehmen oder die Komponente zurückholen. Im zweiten Fall die entfernte Komponente wieder installieren — oder auch die abhängige entfernen, wenn sie ohne die erste keinen Zweck mehr hat. Ein häufiger Fall: wksqliteds entfernt, wkblog behalten. Der Blog führt seine gesamte Speicherung über benannte SQL-Routinen aus und hat dafür keinen Ersatzweg.

Umgebung: nach einer Aktualisierung; die Komponente arbeitet, aber ein neues Merkmal fehlt oder meldet eine fehlende Spalte.

Ursache: Migrationen laufen nicht bei der Installation, sondern beim ersten Zugriff einer Anfrage auf die betroffene Datenbank. Wurde die Oberfläche der Komponente seit der Aktualisierung nicht geöffnet, steht die Migration noch aus. Die zweite Ursache: Ein Lauf ist gescheitert. Die betroffene Fassung wurde dann vollständig zurückgerollt — sie fehlt in schema_migrations und wird beim nächsten Zugriff erneut versucht, mit demselben Ergebnis.

Lösung: Erst die Oberfläche der Komponente aufrufen; das genügt in der Mehrzahl der Fälle. Prüfen Sie danach den angewandten Stand:

sqlite3 data/dwdo/request.sqlite "SELECT version, applied_at FROM schema_migrations ORDER BY version;"

Fehlt eine Fassung dauerhaft, ist der Lauf gescheitert. Die Ursache steht im Fehlerprotokoll des Webservers, nicht auf der Seite — die Komponenten fangen den Fehler ab, damit ein Schemaproblem nicht die ganze Seite mitreißt. Häufigste Ursachen: kein Schreibrecht auf data/dwdo/, kein Platz auf dem Datenträger, oder eine von Hand veränderte Datenbank, gegen die die Migration nicht mehr passt. Im letzten Fall ist die Kopie aus data/dwdo/backup/ der Weg zurück, siehe Wenn es schiefgeht.

Umgebung: Reiter Installierte Erweiterungen, Komponente dieses Hauses.

Ursache: Der Hinweis auf eine verfügbare Aktualisierung entsteht aus einem Abgleich mit dem Verzeichnis auf dokuwiki.org. Die Pakete dieses Hauses sind dort nicht verzeichnet, also gibt es nichts abzugleichen. Das Ausbleiben des Hinweises ist deshalb keine Aussage über Ihren Stand.

Lösung: Das Datum in Administration → Erweiterungsverwaltung gegen das Datum in plugin.info.txt der aktuellen Fassung im Repository halten. Das ist die einzige Fassungsangabe, die es gibt; das Verfahren steht unter Eine Komponente aktualisieren.

• Komponentenmatrix — Abhängigkeiten, Erstkonfiguration, Funktionsprüfung und Datenbestand je Komponente.
• Ergebnis der Installation prüfen — die drei Nachweise, auf die sich mehrere Einträge dieser Seite beziehen.
• Lebenszyklus der Komponenten — der Überblick über alle vier Abschnitte.