Where are we at on Read-Only TWs?

#1

Hello all,

I went searching here for a read-only solution. I found Ton’s plugin, but it predates the more recent stuff that discerns if your wiki is online. But those options that I saw were only to hide the viewtoolbar buttons.

My use case is: When the standalone file is online I need to hide the viewtemplate buttons only when online, and also the sidebar and also the toggle button that opens and closes the sidebar. But when offline, I want the sidebar open and the everything visible just like normally.

What at this point would be the “best practices” way to do that?

#2

How secure do you want it?

I often use a technique borrowed from one of Mohammad’s plugin that offer an obscure keystroke to toggle between read-only mode and edit mode. Read-only mode hides many of the buttons, but I don’t go as far as you in hiding the whole sidebar. (Even in read-only mode, my wikis need it for navigation.) I’m sure we could configure this to also hide the sidebar and its button.

I have different needs than yours. My edit mode is Node, and my read-only mode is a single-file wiki served over http(s). At startup, I look to see if the Node modules are included. If not, I turn on read-only mode. For you, we could probably do something with $:/info/url/protocol to decide when to turn on read-only mode.

But this mode is about hiding controls and not disabling them. If someone added this to the URL: they’d load the control panel, and could use it as they like: #%24%3A%2FControlPanel. And there are other ways around my restrictions. I’m ok with that. A TW sophisticate could download a copy and make changes, but they couldn’t upload their changes, so I feel safe enough; I mostly don’t want to confuse users with things they can’t do. You may have different requirements.

You can see mine in action at https://charter2024.andoverct.info/. To toggle modes, you can use CTRL/SHIFT-/ (control-shift-slash). Because @pmario pointed out that this is difficult to type on German keyboards, I also added CTRL-SHIFT-1 to do the same thing.

I don’t know how far it has wandered from Mohammad’s Utility plugin, but that’s where it started. The current code looks something like this:

ReadOnly.json (3.7 KB)

If this sounds like a good fit, let me know, and I think we could adapt it relatively easily.

1 Like
#3

Hi Scott

I don’t need anything secure or disabled. I just want the sidebar hidden, and the button, because users who come from cell phones in a vertical position ONLY see the (to them) confusing sidebar if they open a TW online standalone. I want them to see just the river. And if they accidentally click on the toggle sidebar button, it will be confusing to them.

2 Likes
#4

Try this:

Create a tiddler (e.g., “NoSidebar”), tagged with both $:/tags/Stylesheet and $:/tags/StartupAction/Browser, containing the following text:

<$list filter="[{$:/info/url/protocol}prefix[http]]">
.tc-hide-sidebar-btn { display:none !important; }
<$action-setfield $tiddler="$:/state/sidebar" text=no/>
</$list>

Notes:

  • The $list filter detects when you are online (i.e., http:// or https://)
  • If online, use CSS to hide the sidebar toggle button
  • If online, set the TWCore state tiddler to hide the sidebar
  • The $:/tags/Stylesheet applies the CSS
  • The $:/tags/StartupAction/Browser processes the $action-setfield when the TiddlyWiki is loaded.

Let me know how it goes…

enjoy,
-e

#5

Hi Eric

I did as you say, but the toggle button still displays. See giffmex - Marcos

#6

ah! when the $:/state/sidebar text is set to “no”, the toggle button classname changes from .tc-hide-sidebar-btn to .tc-show-sidebar-btn, so you need to use:

<$list filter="[{$:/info/url/protocol}prefix[http]]">
.tc-show-sidebar-btn { display:none !important; }
<$action-setfield $tiddler="$:/state/sidebar" text=no/>
</$list>

-e

1 Like
#7

Thanks! That worked great, Eric. I also pilfered a code of yours from another thread to hide the viewtoolbar buttons.

#8

TidGi-Desktop has a read only mode, toggle it on workspace setting without code, https://tidgi.fun/ is deploied in this way.

#9

In case anyone needs to know, there is a complication with Eric Shulman’s solution, but only if you use TiddlyStow to edit the file: TiddlyStow is a webpage, so opening the file with TiddlyStow renders it as read-only. No editing possible. So I had to use another way to open and edit the file.

[edit: I had the same problem on TidGi, though I don’t know why. Both TidGi and the standalone were on my computer.]

#10

Since your goal is to handle “users who come from cell phones”, you could check to see if your TiddlyWiki is running in a mobile browser instead of checking for “http” in the URL.

To do this, you first need to install the “Browser Sniff” plugin from the TiddlyWiki Official Plugin Library. This will add $:/info/browser/... shadow tiddlers that are created at startup. Among these is $:/info/browser/is/mobile, which will have a text field containing “yes” when using a mobile browser.

Then, in your “NoSidebar” startup tiddler, you can replace

<$list filter="[{$:/info/url/protocol}prefix[http]]">

with

<$list filter="[{$:/info/browser/is/mobile}match[yes]]">

Notes:

  • You MIGHT need to use tag $:/tags/StartupAction/PostRender instead of $:/tags/StartupAction/Browser to ensure that the .../is/mobile shadow tiddler has been initialized before the “NoSidebar” startup is invoked.

Let me know how it goes…

-e

1 Like
#11

I think I will leave it as is. I have other ways of opening the file to edit. And while most users will enter via cell phones, some will do so through laptop browsers. Thanks though, Eric!

#12

I might plug TW-Uglify here. It has the ability not only to compress tiddlywiki files, but remove unwanted features, such as editing.

It’s the pruning feature. There a demo of it in one of the demo tabs.

1 Like
#13

There are two radically different senses of read-only:

(1) BAKE IT — you’ve finished editing (Wait, do people ever finish editing a thing? :stuck_out_tongue_winking_eye:) , and now you want to extrude a streamlined version that is henceforth a fun read-only html resource.

(2) FRONT-END IT — you have a hosted wiki, it’s a work in progress, and you want it to live on a server (web or intranet) where non-authors can access it, without being distracted by various affordances relevant to editing. (And maybe you also want it to be protected against certain kinds of casual snooping, even if savvy users can hack into json content.)

The Flibbles solution sounds great for type (1).

For type (2) I recommend $:/TiddlyTweaks/ReadOnly

It has lots of great resources such as special css that applies only to web visitors who aren’t accessing over file-mode or logged in over tiddlyhost. Plus settings for which sidebars show up, which toolbar buttons, etc.

3 Likes
#14

Yeah… After posting, I read a little more and realized @DaveGifford was asking more about a Type (2) solution, which Uglify can’t help with.

Type (1) solutions are also where commercial uses for Tiddlywiki come in. Some people use it to create production builds for their websites. Sometimes even shopping sites. No need for editing there.

1 Like
#15

Interesting thread. Useful.

Still I am left thinking … Where are the base docs for this obvious need?

#16

Well, what are you waiting for Titch?

1 Like
#17

Broheim, you.   

#18

Here is the simple Gifford version:

https://giffmex.org/gifts/documenting.tw.html#Hide%20sidebar%20and%20viewtoolbar%20buttons%20when%20file%20is%20accessed%20online

#19

V. good. What I like in your docs is how they bring bits 'n pieces together with a clear focus on solving specific common needs.

#20

I wriite them for my idiotic and forgetful self. I assume most people won’t want or need most of my very specific use cases but I offer them up anyway just in case someone finds parts of them useful.

2 Likes