Site loads as "read-only", but with editing GUI just one click away for me?

#1

Friends,

What’s the best way to have a hosted TW5 (say, on tiddlyhost) serve up a public face that’s free of most editing GUI (and other distracting technical stuff), while the same site remaining easy to edit on the fly?

To be clear: I understand many people may have a linear work flow for public files: develop the TW5, finalize the content, then convert to a readOnly theme (or even a static or stripped-down site) and publish; repeat the process for any necessary revisions down the road. This is not how things go for my projects.

Use case (to make the need vivid): I’m constantly updating the TW5 for my big university class; it’s very much a living database for which any workflow more complex than auto-save or one-click save is not practical.

Yet I don’t want students visiting the page to be overwhelmed by GUI elements that are irrelevant to them. I also prefer to keep some data “under the hood” – not necessarily encrypted or hacker-proof, but unlikely to surface for visitors poking around in obvious ways.

Currently, my workarounds include having the ViewToolbar appear only on hover, and tucking most controls (for both page and tiddlers) into the dropdown “more” controls. And then I use minimalist sidebar tabs, using various field-driven filter conditions to prevent technical or archival stuff taking up space in Recent menu, etc.

In TWClassic, it was quite easy to load a tiddlyspot site and hit a checkbox (tucked away where I could find it quickly) that toggled readOnly mode off. Changes to the checkbox setting were locally stored, and it defaulted to readOnly=yes for each session. So editing and saving the project did not require remembering to reverse the toggle (on pain of new visitors seeing the edit interface). If the parallel solution for TW5 is out there, I’ve lost track of it. (In early 2020, Jeremy generously set me up with a custom-hosted login-account solution that solved these problems and more during the peak online-teaching crisis, but that server-based setup made ongoing demands on his time, and it is overkill for my current needs.)

I’m sure I recall that there are ways to save variables locally (in a cookie or in session-specific browser memory) rather than in the tw file itself, but I don’t recall how that’s done. Presumably, this could unlock that same ability to start my editing sessions with one simple step that “unlocks” the editing interface and extra content, leveraging filter conditions in ViewTemplate items to check for the special (local or session-specific) value. Any TW-savvy visitor would be able to do the same, should they deduce or stumble across the trick, which is fine (so long as they can’t actually write changes to the server!).

Any best practices, or ingredients for a solution?

Thanks in advance!

-Springer

#2

I’m interested in this as well.

I did some experiments with the Ton Gerner’s Read Only Plugin and it works OK.

#3

Boris, as far as I can tell, Ton Gerner’s “read only” is something to invoke “before you publish” (that is, a linear kind of workflow); it doesn’t seem designed to be loaded as a default (for visitors), while being overridden in a session-limited way by the ongoing editor. But if anyone can tip me off to the contrary, I’m curious.

#4

Yep it’s not ideal at all, but it’s the closest I came to finding something.

Can you describe how you host — and more importantly update — today?

#5

I keep it simple by hiding TiddlyWiki interface stuff when the sidebar is closed.

For example: Charlie’s Favourite Stuff and Projects

That TiddlyWiki is hosted on a static web site, but I’d do the exact same thing no matter where the TiddlyWiki is.

#6

Charlie,

Intriguing… And does your sidebar state revert to closed for each fresh load? If so, I should hijack whatever that mechanism is (that allows the sidebar to revert to loading-as-closed even if I save when I happen to have it in open state). I do want my students to have access to the actual sidebar (in the form that I have it carefully configured now), but presumably some other toggle could function in a similar way.
-Springer

#7

Boris, I’m using tiddlyhost for this learning site. It’s such a lovely system for it-just-works hosting and editing and saving without worrying about which computer I’m on and which browser and whatnot. (I was using tiddlyspot for years before the recent need to give it a new shape.) Since I am often loading the site – and sometimes adding info – from a classroom’s computer that is not my own, tiddlyhost / tiddlyspot are the gamechangers.

#8

Take a peek at the following tiddlers (remember to open the sidebar for full TiddlyWiki features:

Good lord, I can’t stand this editor in TiddlyTalk (sorry, not meaning to start a non-related thread here, just venting…)

#9

So instead of using sidebar hide/show as trigger for TiddlyWiki features, you could have a button or check box, or a keyboard accelerator.

Or even a “?” parameter in your URL to open up the TiddlyWiki interface.

#10

I have solved this issue successfully on a tiddlywiki I produced for a client. My only paid tiddlywiki engagement so far.

What I did in the end was to create a button/macro that applied all the settings I wanted for “Author mode” and another that reverse these for “Reader mode”.

To do this I created a new tab that also showed recent system tiddlers. I then freshly loaded the wiki and made the settings I wanted, noting all the changes needed, then I did it again for the other “mode” and recorded what I needed for my mode switch buttons.

However if you use autosave while editing it will save the wiki in “edit mode” that visitors will see if they load it while you are editing.

I solved this as follows;

  • The wiki was hosted on SharePoint and the editor needed to check it out, and saves during edit mode where not visible to regular users until, we toggled it back to read only mode, saved, then the wiki was checked back in.
  • If you did not have SharePoint or similar you could store all changes in Local storage, using the local storage plugin, and only save to the host with “publish and save button” that restores read only mode then saves.

Another method which is a little more secure is to capture all tiddler changes for the two modes in two “bookmarklets” . Just click these in the bookmarks to change the wikis mode. This means this logic is not stored in the actual wiki, making it harder for curious users to reverse engineer the switch to edit mode (only if they have edit access).