Skip to content

No way to read the wiki locally as a wiki — only as raw markdown #3

Description

@PhilippTheServer

Cloning this repository gets you Markdown files. tools/serve.py renders them for review,
but it is a preview shim, not the thing the content is actually published into.

There is no way to run the real target — Wiki.js — against this repository's content, so
nobody can check how a page will actually look, and nobody can browse the wiki offline.

Expected once solved

docker compose up -d in a fresh clone brings up a self-hosted Wiki.js serving this
repository's pages, browsable immediately with no login.

Specifically:

  1. One command, no manual setup wizard, no account creation.
  2. Every page in the repository is present and readable anonymously.
  3. Guests need no credentials to read.
  4. An automated check fails if the stack stops coming up or stops serving the content.

Activity

  1. added a commit that references this issue on Aug 26, 2026
    67e7b3f
  2. PhilippTheServer commented on Aug 26, 2026

    @PhilippTheServer
    ContributorAuthor

    Solved in #4 (squash-merged as 67e7b3f).

    docker compose up -d in a fresh clone now brings up Wiki.js 2.5 with PostgreSQL, serving
    this repository's pages at http://localhost:3000, readable with no login. WIKI_PORT
    overrides the port when 3000 is taken.

    All four points from the issue:

    1. One command, no wizard. wikijs/bootstrap.py completes Wiki.js's setup over its own
      APIs — POST /finalize for the wizard, GraphQL for the rest. It runs once, exits, and is
      idempotent, so re-running is also the reload command.
    2. Every page present. The Local File System target is pointed at the mounted repository
      and imported. 8 pages; README is dropped afterwards since it documents the repository
      rather than the project.
    3. Guests read anonymously. Verified and granted on every run.
    4. Automated check. tools/check_wikijs.py, run in CI against a real stack.

    Two design points worth recording:

    The checkout is mounted read-only and the disk target is disabled again after importing.
    It is a push target — left enabled, Wiki.js would try to write edits back into whoever's
    working tree. Importing is all that is wanted from it.

    The check does not follow redirects. My first version passed a fully locked-down wiki:
    Wiki.js answers an unauthorised guest with a 302 to /login, urllib followed it, and the
    login page returns 200 carrying the site title — so the assertion matched. A 3xx is now
    the failure it actually is. Verified by revoking guest read: all 8 pages fail, and re-running
    bootstrap restores them.

    Verified on Wiki.js 2.5.314. Both CI jobs pass, including the stack coming up from scratch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions