Diagnose

Jeder Abschnitt beschreibt ein Symptom. Überall gilt diese DokuWiki-Installation mit installiertem und aktiviertem Plugin wkdoadogit, sofern nichts anderes steht. Mount meint die Bindung zwischen Repository und Wiki-Namespace, Tier die Sichtbarkeitsstufe dieses Mounts.

Umgebung. Auf der Seite steht {{wk:adogit>…}} und wird als gewöhnlicher Text gezeichnet.

Ursache. Das Plugin ist nicht aktiviert, oder die Marke ist über mehrere Zeilen umbrochen. Eine Marke muss in einer einzigen Quellzeile stehen.

Abhilfe. Prüfen Sie im Extension Manager, ob wkdoadogit aktiviert ist, und bringen Sie die Marke in eine Zeile. War die Seite bereits gezeichnet, speichern Sie sie einmal erneut.

Umgebung. Statt des Baums erscheint eine Zustandskarte mit diesem Text.

Ursache. Die Suche fand weder eine Verbindung mit dem genannten Schlüssel noch einen Mount für das Tripel aus Verbindung, Projekt und Repository. Beide Fälle ergeben denselben Text. Die häufigsten Spielarten sind diese zwei: im ersten Feld der Marke steht die Nummer der Verbindung statt ihres Schlüssels, oder der Projekt- beziehungsweise Repository-Name weicht vom registrierten ab.

Abhilfe. Öffnen Sie Administration > ADO-Git Repo-Mounts und lesen Sie in der Zeile des Mounts die Spalte ADO-Repo. Dort steht projekt/repo genau so, wie es registriert ist. Den Verbindungsschlüssel zeigt derselbe Bildschirm im Assistenten, in der Form projekt / schlüssel. Am schnellsten kopieren Sie die Marke aus dem Zeilenmenü des Mounts, Eintrag Dieses Repository auf einer Wiki-Seite anzeigen.

Umgebung. Die Marke ist nachweislich richtig, die Seite liegt aber außerhalb des Projekt-Namespace.

Ursache. Der Browser sucht die Verbindung über das DWDO-Projekt der Seite, auf der er steht. Außerhalb der Projektwurzel (hier {lang}:projects:) lässt sich das Projekt nicht auflösen, und keine Verbindung ist auffindbar.

Abhilfe. Verschieben Sie die Marke auf eine Seite innerhalb des Projekts, etwa de:projects:<projekt>:repos. Für eine einzelne Datei gilt eine Ausnahme: {{source>ado:…}} wirkt auch auf einer Seite innerhalb des Mount-Namespace.

Umgebung. Der Mount ist registriert, der Leser angemeldet oder anonym.

Ursache. Der Tier des Mounts erfasst diesen Leser nicht. private schließt alle außer Editoren aus, readonly die Anonymen, team alle außerhalb der Projekt-Rollengruppen.

Abhilfe. Wählen Sie im Zeilenmenü des Mounts einen anderen Tier und dann Speichern. Die Änderung wirkt sofort, weil die Rechte bei jedem Request gelesen werden. Bearbeiten Sie die Rechte nicht von Hand, denn der verwaltete Block wird beim nächsten Schreiben überschrieben.

Umgebung. Die Mount-Liste in der Administration.

Ursache. Der Mount liegt im Speicher, die passenden Rechte in conf/acl.auth.php fehlen aber oder weichen ab. Das geschieht, wenn das Schreiben der Rechte scheiterte (Dateirechte) oder der verwaltete Block an diesem Bildschirm vorbei verändert wurde.

Abhilfe. Wählen Sie im Zeilenmenü des Mounts den Tier erneut und dann Speichern. Geschrieben wird ausschließlich der Block zwischen # BEGIN wkdoadogit-managed und # END wkdoadogit-managed; alle anderen Regeln bleiben unangetastet. Bleibt der Zustand NOT written, prüfen Sie die Schreibrechte auf conf/acl.auth.php.

Umgebung. Ein Mount, der mit einer älteren Fassung des Plugins registriert wurde. In der Liste steht der Tier private, die Spalte Regeln meldet eine Abweichung.

Ursache. Die Registrierungsschicht kannte einst nur private, readonly und public und ersetzte jeden anderen Wert still durch private. Die Rechte wurden dennoch nach dem gewählten Tier team geschrieben, weshalb Speicher und Datei auseinanderliefen. Die Registrierung übernimmt inzwischen jeden Tier, den der Regelschreiber kennt; neue Mounts haben diesen Fehler nicht.

Abhilfe. Wählen Sie im Zeilenmenü des Mounts den Tier team und dann Speichern. Der Mount wird mit dem gewählten Tier abgelegt und die Regeln werden erneuert. Danach stimmt die Spalte Regeln.

Umgebung. Statt des Baums erscheint eine Zustandskarte mit diesem Text, oder die Schublade meldet, die Quelle sei nicht erreichbar.

Ursache. Eine der Schichten unter dem Browser antwortet nicht: die Erweiterung curl fehlt, die Einstellung ado_host_allow ist leer oder falsch, das Secret ist nicht erreichbar, oder die Verbindung ist ausgefallen.

Abhilfe.

1. Öffnen Sie /doku.php?do=wkdoadogit_diag. Die Tabelle zeigt, welcher Dienst sich auflöst und welcher nicht.
2. Öffnen Sie auf einer Projektseite do=wkdoado und wählen Sie bei der Verbindung Testen. Der Test unterscheidet verbotenen Server, unerreichbares Ziel, Zertifikatsfehler und Anmeldefehler.
3. Prüfen Sie, ob in ado_host_allow genau der Servername steht. Platzhalter kennt diese Liste nicht, eine leere Liste weist alles ab.
4. Prüfen Sie die Erweiterung curl. Ohne sie meldet sich der Konnektor als inaktiv.

Umgebung. Eine Verbindung vom Typ server gegen eine eigene Azure-DevOps-Installation.

Ursache. Die Collection ist zweimal genannt, in der Basisadresse (https://devops.wvds.it/Me) und im Feld Collection (server). Der Adressbauer hängt sie ein zweites Mal an.

Abhilfe. Leeren Sie das Feld Collection (server) oder entfernen Sie die Collection aus der Basisadresse, und wiederholen Sie dann den Test.

Umgebung. Der git-Proxy auf einem Apache-Server.

Ursache. Apache weist Pfade der Form …/git.php/code/projekt/repo/info/refs von Haus aus ab, weil AcceptPathInfo abgeschaltet ist. Die Anfrage endet, bevor PHP startet.

Abhilfe. Nutzen Sie die mitgelieferte .htaccess im Plugin-Verzeichnis, die die Option nur für git.php einschaltet. Die mitgelieferte web.config gilt ausschließlich für IIS und bewirkt auf Apache nichts.

Umgebung. Der git-Proxy, Anmeldung über HTTP Basic.

Ursache. Das Token wurde widerrufen, ist abgelaufen oder wurde vor der Umbenennung des Präfixes ausgestellt. Gespeichert ist nur der Hashwert, ein altes Token lässt sich also nicht auf ein neues Präfix übertragen. Die zweite Möglichkeit: der Tier des Mounts erlaubt einem anonymen Leser kein clone, und die Anmeldung wurde gar nicht erst gesendet.

Abhilfe. Stellen Sie unter /doku.php?do=wkdoadogit_tokens ein neues Token aus und hinterlegen Sie es im Client. Prüfen Sie außerdem, ob das Token als Kennwort übertragen wird; der Benutzername ist Ihr Anmeldename im Wiki.

Umgebung. clone funktioniert, push nicht.

Ursache. Für push ist mindestens Level 4 nötig, für clone genügt bereits 2. Liegen Sie zwischen 4 und 7, sind nur Branches unterhalb Ihres Präfixes erlaubt.

Abhilfe. Pushen Sie nach refs/heads/users/<login>/ oder bitten Sie um einen Tier, der Level 8 gewährt. Einzelheiten beschreibt Repository klonen.

Umgebung. Der Editor für einzelne Dateien im Browser.

Ursache. Die Datei hat sich nach dem Öffnen des Editors geändert. Der Commit greift stets gegen die Fassung, die der Autor gesehen hat; eine abweichende Grundlage weist der Server zurück, statt die fremde Änderung zu überschreiben.

Abhilfe. Schließen Sie den Editor, öffnen Sie die Datei erneut und wiederholen Sie die Änderung auf der neuen Grundlage.

Umgebung. Aufruf der Adresse /doku.php?id=code:dokuwiki-plugins:wkdoadogit.

Ursache. Der Mount-Namespace ist virtuell. Er trägt Rechte, aber keine Seiten, und der Mount legt auch keine an.

Abhilfe. Das ist kein Fehler. Das Repository zeigt eine Seite mit der Marke {{wk:adogit>…}} innerhalb des Projekts; siehe Anleitung, Seite mit dem Browser.

Umgebung. Deutschsprachige Oberfläche, beliebiger Bildschirm des Plugins.

Ursache. DokuWiki lädt zuerst die englischen Texte und legt die gewählte Sprache darüber. Ein Schlüssel, den die deutsche Datei nicht hat, bleibt deshalb englisch. Das ist gewolltes Verhalten und kein Installationsfehler; so zeigt die Oberfläche nie eine leere Beschriftung.

Abhilfe. In dieser Fassung sind alle Beschriftungen von wkdoadogit und wkdoado übersetzt, eine englische Beschriftung weist also auf eine ältere installierte Fassung hin. Vergleichen Sie lib/plugins/wkdoadogit/lang/de/lang.php mit der gleichnamigen englischen Datei: ein Schlüssel, den die deutsche nicht hat, ist die fehlende Übersetzung.

• Ein ADO-Repository erstmals im Wiki anzeigen – der ganze Weg von der Verbindung bis zur Datei
• Quellcode auf einer Wiki-Seite anzeigen – beide Marken und ihre Grenzen
• Ein gemountetes Repository klonen – git-Proxy und persönliches Token
• Konzepte – Sichtbarkeits-Tier, Rechte und Grenzen