Diagnostics

Each section describes one symptom. Throughout, the environment is this DokuWiki installation with the wkdoadogit plugin installed and enabled, unless stated otherwise. Mount means the binding between a repository and a wiki namespace, tier the visibility level of that mount.

Environment. The page contains {{wk:adogit>…}} and renders it as ordinary text.

Cause. The plugin is not enabled, or the markup is wrapped across several lines. A markup must sit on a single source line.

Remedy. Check in the Extension Manager that wkdoadogit is enabled, and put the markup on one line. If the page was rendered already, save it once more.

Environment. A state card with that text appears instead of the tree.

Cause. The lookup found neither a connection with the key given nor a mount for the triple of connection, project and repository. Both cases produce the same text. The two commonest variants: the first field of the markup holds the connection's number instead of its key, or the project or repository name differs from the registered one.

Remedy. Open Admin > ADO-Git Repo Mounts and read the ADO repo column in the mount's row. It holds project/repo exactly as registered. The connection key is shown by the same screen in the wizard, in the form project / key. Fastest of all: copy the markup from the mount's row menu, entry Show this repository on a wiki page.

Environment. The markup is verifiably correct, but the page lies outside the project namespace.

Cause. The browser looks up the connection through the DWDO project of the page it sits on. Outside the project root (here {lang}:projects:) the project does not resolve and no connection can be found.

Remedy. Move the markup to a page inside the project, for example en:projects:<project>:repos. One exception applies to a single file: {{source>ado:…}} also works on a page inside the mount namespace.

Environment. The mount is registered, the reader is signed in or anonymous.

Cause. The tier of the mount does not cover that reader. private excludes everyone but editors, readonly excludes anonymous visitors, team excludes everyone outside the project role groups.

Remedy. Choose a different tier in the mount's row menu and then Save. The change takes effect immediately, because permissions are read on every request. Do not edit the permissions by hand: the managed block is overwritten on the next write.

Environment. The mount list in the admin area.

Cause. The mount is in storage, but the matching permissions in conf/acl.auth.php are missing or diverge. This happens when writing the permissions failed (file permissions) or when the managed block was changed behind this screen's back.

Remedy. Choose the tier again in the mount's row menu and then Save. Only the block between # BEGIN wkdoadogit-managed and # END wkdoadogit-managed is rewritten; every other rule stays untouched. If the state remains NOT written, check write permissions on conf/acl.auth.php.

Environment. A mount registered with an older build of the plugin. The list shows tier private, and the Rules column reports a divergence.

Cause. The registration layer once knew only private, readonly and public and silently replaced any other value with private. The permissions were nevertheless written for the chosen team tier, so storage and file drifted apart. Registration now takes any tier the rule writer knows, so new mounts do not carry this fault.

Remedy. Choose tier team in the mount's row menu and then Save. The mount is stored with the chosen tier and the rules are refreshed. The Rules column agrees afterwards.

Environment. A state card with that text appears instead of the tree, or the drawer reports the source as unreachable.

Cause. One of the layers beneath the browser does not answer: the curl extension is missing, the ado_host_allow setting is empty or wrong, the secret is unreachable, or the connection has failed.

Remedy.

1. Open /doku.php?do=wkdoadogit_diag. The table shows which service resolves and which does not.
2. Open do=wkdoado on a project page and choose Test on the connection. The test distinguishes a forbidden server, an unreachable target, a certificate failure and an authentication failure.
3. Check that ado_host_allow holds exactly the server name. This list knows no wildcards, and an empty list refuses everything.
4. Check the curl extension. Without it the connector reports itself inactive.

Environment. A connection of type server against an Azure DevOps installation of your own.

Cause. The collection is named twice, in the base address (https://devops.wvds.it/Me) and in the Collection (server) field. The address builder appends it once more.

Remedy. Empty the Collection (server) field or remove the collection from the base address, then repeat the test.

Environment. The git proxy on an Apache server.

Cause. Apache refuses paths of the form …/git.php/code/project/repo/info/refs by default, because AcceptPathInfo is switched off. The request ends before PHP starts.

Remedy. Use the shipped .htaccess in the plugin directory, which switches the option on for git.php alone. The shipped web.config applies to IIS only and does nothing on Apache.

Environment. The git proxy, authentication over HTTP Basic.

Cause. The token was revoked, has expired, or was issued before the prefix was renamed. Only the hash is stored, so an old token cannot be carried over to a new prefix. The other possibility: the tier of the mount does not permit an anonymous reader to clone, and no credentials were sent at all.

Remedy. Issue a new token at /doku.php?do=wkdoadogit_tokens and store it in the client. Check as well that the token travels as the password; the username is your wiki login.

Environment. clone works, push does not.

Cause. push needs at least level 4, while clone is satisfied by 2. If you sit between 4 and 7, only branches below your own prefix are permitted.

Remedy. Push into refs/heads/users/<login>/ or ask for a tier that grants level 8. The details are in cloning a repository.

Environment. The single-file editor in the browser.

Cause. The file changed after the editor was opened. A commit always applies against the revision the author saw; the server rejects a different base rather than overwriting someone else's change.

Remedy. Close the editor, open the file again and repeat the change on the new base.

Environment. Calling the address /doku.php?id=code:dokuwiki-plugins:wkdoadogit.

Cause. The mount namespace is virtual. It carries permissions but no pages, and the mount creates none.

Remedy. This is not a fault. The repository is shown by a page carrying the {{wk:adogit>…}} markup inside the project; see the tutorial, the page with the browser.

Environment. A non-English interface, any screen of the plugin.

Cause. DokuWiki loads the English texts first and lays the chosen language over them. A key the chosen language file lacks therefore stays English. This is intended behaviour, not an installation fault; it is what keeps the interface from ever showing a blank label.

Remedy. In this build every label of wkdoadogit and wkdoado is translated into German, Slovenian, Croatian and Italian, so an English label points to an older installed build. Compare lib/plugins/wkdoadogit/lang/<language>/lang.php with the English file of the same name: a key the former lacks is the missing translation.

• Show an ADO repository in the wiki for the first time – the whole path from the connection to the file
• Show source code on a wiki page – both markups and their limits
• Clone a mounted repository – the git proxy and the personal token
• Concepts – visibility tier, permissions and limits