Dynamic readOnly interface (for everyone but me, over Tiddlyspot) on TW5?

[springer]

Dear all,

My teaching site is hosted on Tiddlyspot, where students can access it for notes and resources, and I can make ongoing additions and edits.

On my TW Classic site (also Tiddlyspot), there was a "backstage" area, and a "readOnly" checkbox (which I tucked in an odd corner) that would always default to "true" until I unchecked it (or loaded with a readOnly:no url variant).... 

I have tried doing my homework: I looked at http://tw5readonly.tiddlyspot.com/ since it's clearly in the ballpark... but I despaired that it would work for me: I don't want the Tiddlyspot server to sometimes show everything to everyone (while I'm between edits with AutoSave on, which I do love!), and serve up the readOnly interface only when I restore the theme manually and save.

I have looked at the official tiddler about Web Server Authorization here, but I found no documentation there about how to get the ViewTemplate and other UI elements to respond to the difference between writers and (anonymous, non-authenticated) readers (and I'm not even sure whether/how all this applies to Tiddlyspot in particular.)

I found a 2014 thread where Jeremy mentioned once-upon-a-time having

a blue "edit" button at the top right. Until it was clicked none of the UI paraphernalia associated with editing was displayed... got lost in some refactoring at some point...

Almost-hooray. That would have been fine (equivalent to what I had in TWC), since this isn't a matter of sensitive data, but rather of efficient and clean GUI for readers.

Dave Gifford also recently asked an equivalent question -- but not for Tiddlyspot. I'm afraid any solution that involves "then, do these steps before you upload" doesn't cut it for a Tiddlyspot-hosted wiki; this situation calls for a dynamic solution. (And I really am editing this thing continuously and wanting students to see new material promptly, so I'm not poised to add a frequent step like exporting to a read-only at a different URL.)

So, what's the current wisdom? Ideally, it should be achievable to make sure that readers who have not authenticated with Tiddlyspot (or, maybe just: readers who haven't entered a password, or who have not found the special unlocked "back door" checkbox/url variant/empty button, whose state doesn't get saved at the server...) don't encounter the interface elements that are only appropriate for me as writer/admin. A bunch of stuff is then revealed *only* when in admin (not readOnly) mode:

• Page Toolbar shows me control panel, tag manager, time stamps on/off, etc. 
• View Toolbar shows me edit, info, clone, encrypt, etc.

Surely someone must have solved this challenge? I regret that at this point I'm needing to ask how. Thanks for any help you can offer!

-Springer

[Mat]

I don't have time now but hopefully in the weekend, to explain an alternative route that I use for a pretty much identical situation. Briefly, I use a save button that saves to two tiddlyspots at the same time - the "current" admin one and a public one - but for the public one the tiddlers are filtered.

<:-)

[springer]

I look forward to seeing what you've rigged up, Mat. Thanks.

-Springer

[Mat]

OK, so this is not an official release because is turned out to require too much work to make an elegant package of my personal setup - so what you're getting is more of a demo with some instructions. For one thing, it contains several of my actual tiddlers that I use for teaching science to middle schoolers. Those tids are in Swedish tho :-)

http://starhub.tiddlyspot.com/

<:-)

[Mohammad]

Wow,

 This is amazing Mat!

Can we use the same mechanism on another domain like university domain? Or this is specific to tiddlyspot.com?

--Mohammad

[Mat]

Mohammad wrote:

Can we use the same mechanism on another domain like university domain? Or this is specific to tiddlyspot.com?

Thanks Mohammad. I'd say you can use the idea for anything that you can save to. It all centers around the Publish plugin concept where the $:/plugins/TWaddle/Publish/Button is a variant on the wiki standard $:/core/ui/Buttons/save-wiki so it has multiple instances of these:

<$action-sendmessage $message="tm-save-wiki" $param="MySaveFilter" />

Coincidentally, @oleghbond just posted his "wiki farm" concept which is related but much more advanced and powerful.

<:-)

[Mohammad]

Mat,

 This make TW much more flexible, where one like to have multi wiki (multi-pages) website!

For example a website ( a wiki) per course.

Many thanks

Mohammad

[Joshua Fontany]

Great implementation. Would this also allows something like a "Demo" wiki to be rendered out from a full-feature "members only" one?

Mental note: investigate this after the next Json Mangler release. :)

Best,
Joshua Fontany

[Mat]

Joshua Fontany wrote:

Great implementation. Would this also allows something like a "Demo" wiki to be rendered out from a full-feature "members only" one?

Sure, why not? It is just a matter of filtering out the tiddlers you don't want to include. Or, actually, they can even be included but selectively styled out based on domain as I note at the very bottom of the About tiddler and which is also how the About tiddler displays differently on the two sites in my demo.

<:-)

[TonyM]

Folks

Just a pointer that with or without the aformentiond tool you can steel the save empty button from tiddlywiki.com and modify it to save other editions based on selected tiddlers.

Jeremy s innerwiki plugin does this and provides a tool to iframe a new wiki including one that you choose what you wish to include from the parent wiki. Including a data parameter, In the inner wiki you can save it like any other wiki to get your new edition.

Innerwiki was designed for a particular use case but it is capable of being used for a lot more

Regards
Tony