{# The page a wiki whose file cannot be read shows — issue #71. Deliberately standalone rather than extending base.html: the chrome asks the active wiki for its theme, its page list and its settings, and that is exactly the wiki that just failed to open. This page needs nothing from any database, so it renders when nothing else about this wiki does. #} {{ wiki_name }} can’t be read — Waikiki
🌺 Waikiki

“{{ wiki_name }}” can’t be read

Waikiki opened {{ path }} and {{ reason }}.

{% if others %}

Open a different wiki

{% for w in others %}

{% endfor %} Manage wikis…

{% else %}

Manage wikis…

{% endif %}

Restore this wiki from a backup

{% if backups.latest %}

Waikiki keeps local snapshots of every wiki. The newest is {{ backups.latest.when }} ({{ (backups.latest.bytes / 1048576) | round(1) }} MB, {{ backups.latest['wikis'] | length }} wiki(s)).

{% elif backups.enabled %}

Automatic backups are on, but no snapshot has been taken yet — they run while the app is open, so a wiki that broke early may have none.

{% else %}

Automatic backups are switched off, so there may be no snapshot to go back to. Any .wiki or .db file you exported yourself works here just as well.

{% endif %}
  1. Find a snapshot in {{ backups.dir }} — one folder per date, one {{ wiki }}.db file inside it per wiki.
  2. Use Manage wikis → Open wiki file… on that {{ wiki }}.db.
  3. It opens as a separate wiki, so you can read it and compare before deciding what to do with the damaged one. Neither the backup nor the damaged file is changed.

Backups sit on the same disk as your wikis, so they are insurance against corruption and mistakes, not against losing the machine. Keeping a .wiki export somewhere else is worth the minute it takes.

What SQLite said 
{{ detail }}