I don’t know if my techniques would suit you. It depends on whether you only want to keep the extra information from casually wandering eyes or to ensure it’s not visible to a TW-sophisticated hacker.
Mine only handles the former. But it’s worked well for me across many projects. You can download the following and drag it to a wiki:
ReadOnlySettings.json (4.1 KB)
You will need to save and reload, since there’s a startup action included. This offers a read-only mode and turns it on by default if I’m not running in Node. I can toggle that with the keystroke CTRL-SHIFT-/ (or because that may not work on certain keyboards, with CTRL-SHIFT-1.) So when I build and deploy my wiki to GH Pages or similar, it’s read-only mode, but I can easily toggle into edit mode.
Yes, this is security-by-obscurity. I would not do this if I was worried about someone peeking behind the curtain. But that’s not my concern; it may be yours. Instead, I simply don’t want to confuse users with things that seem to offer them the ability to change but which they can’t update on my read-only servers.
That code really needs to be updated. We discussed this in #12964. It shouldn’t be difficult, but I’ve never gotten back to it. The code works fine for me, though.
I find it a little simpler to write a custom widget to do the same thing:
title: $:/_/my/widget/edit-only
tags: $:/tags/Global
\widget $edit.only()
<% if [{$:/status/IsReaderMode}!match[yes]] %>
<$slot $name="ts-raw" />
<% endif %>
\end
Then it can be used like this:
This is <$edit.only>NOT </$edit.only>in read-only mode.
<$edit.only>
Handles block mode (if you start with a newline),
[[Links|https://google.com]], and //so on// ''work'' as expected.
</$edit.only>

