I am getting to the stage of making my TW publicly accessible. So, I am thinking about what to show and hide through the main UI. Can I get some ideas from people who have done this before, what facilities did you hide/configure and how?
bobj
1 Like
It all depends on who your audience is and will they care or use what is left.
Unless you want to hide all the edit features then look for read only themes and settings.
Standard hiding is no guarantee of security if that is what you are looking for.
I have a number of wikis that are for general consumption but with only a few editors. The editors view the wiki over Node and have full access. The public sites are on GitHub Pages or GitLab Pages, derived from the edits we made in the Node version and committed to git. Almost all of these are behind corporate walls, but a framework I started for creating them is at https://crosseye.github.io/TW5-Tiddox/.
In either view, you can toggle read-only mode on or off with a keystroke (I usually use CTRL-SHIFT-/.)
In read-only mode the following buttons are hidden:
clonedeleteeditnew-herenew-journal-hereimportmanagernew-imagenew-journalnew-tiddlercontrol-panelsave-wikiinfo
as well as the tools and more sidebar tabs. Also drag-and-drop is disabled. This is mostly done through a few tiddlers cherry picked from Mohammad’s utility plugin, plus one custom action setReadOnlyOnReload.
3 Likes
Of possible use:
The hide macro can probably be modified to work in reverse, i.e to show specific elements in certain tiddlers of your choice.
1 Like
Thank you everyone for your ideas and thoughts.
bobj
Just another idea.
You could tag tiddlers “locked” and use the stylesheets attached to hide the buttons.
locking-tiddlers.json (1.4 KB)
to expand on this i’d recommend assuming anything on the site is public information. i would recommend treating anything hidden via template changes etc. as “getting rid of unnecessary ui elements / irrelevant information” and not “users should not know this information / this is private”.
1 Like
Absolutely. In my case, there’s nothing hidden that would be worrisome if they saw it, and they cannot save changes back to the server. It is mostly a matter of showing them the content without bothering them with (to-them) useless options for modifying that content.
2 Likes
Uglify may be able to help here if you’re still looking for a solution. It allows generation of wikis without certain features. It can also configure servers to send wikis to clients without features as well.
Uglifying is optional.
3 Likes
Scott’s suggestion is good. And I believe Scribs points out an important point: assume anything will be found by someone who’s got the inclination to find it. Imagine your accounts, passwords or customer data. Best leave it on a secure server rather than putting it out there.
How about hosting a few different TWs. One to direct you to each of the others. Some of the others might include passwords if you feel it’s necessary.
But a single site with TWO kinds of data (public and private) always involves some risk And it would involve some plugin and a considerable amount of scripting at the very least. And would it be something you could repeat or replicate later on down the road?
For me, no.
Right.
Asking now …
— What “hider” plugins do we have?
… or
— Any tutorials to acheive this easily, manually?
Just asking for practicals
TT
Right. Sort of …
But can we open this up a bit?
Q #1: If we use encryption for individual Tiddlers for that private/sensitive data should we worry at all?
Somehow I didn’t see this post, back in September.
There are two very different ways of preparing a wiki for public non-editing audience.
One is to “bake it” into a read-only form, actually removing lots of the TiddlyWiki core code. It seems tools like uglify would be good for that. (Ideally, especially if you were doing lots of these or if the site is getting lots of traffic, stripping the code down to remove most editing and customization features would be the efficient approach in terms of bandwidth, storage, etc.)
The other is to have a “two-faced” wiki, one with a readOnly mode for public viewers, and an edit mode for the author. A script on load can determine whether one is signed in to tiddlyhost, or accessing over a local filesystem, and make the editing UI available only in that case (otherwise default to a more limited interface).
I always do this latter for my web-facing tiddlyhost projects (unless they’re about TiddlyWiki in which case keeping edit-interface is helpful). My projects are never “done” but always under perpetual (perhaps intermittent) development. Call them “half-baked” 
Two tools I’ve used for the “two-faced” or “half-baked” approach are:
- TiddlyTweaks ReadOnly
- kookma’s utility plugin (see “Customize UI elements” to toggle what features appear for view-only mode).
1 Like
[My added emphasis] to underline @Springer’s useful pointer that TW already has plugins to ease “hiding” — better called, perhaps, “non-disclosures” — of data end-users don’t need to see.
TT
In tzk, I have found it helpful to implement feature flags to dynamically hide custom elements in public versions.
Where you want to selectively include something (we’ll call it dingbat1), you use <% if [m2.ff[dingbat1]] %>. Each flag has a tiddler defining its name and values in the private and public versions separately (so if you want you can turn it off in both or enable it in both, as your needs change). There is a feature flags
To pick the mode, you just need to change a single tiddler to identify whether this is the public or private edition, and the m2.ff function looks there.
Aside from ease of use (almost everything can be done in-wiki instead of having to be configured separately in a build script or something), another major advantage is that if you want to see some UI element in a different version than it’s normally limited to, you can just go turn it on temporarily. Obviously there are cases where you might want to completely remove things and this is a disadvantage though!
This sounds like it’s halfway between the “bake it” solution and the “two-faced” solution. That is — if I understand correctly — you’re still manually toggling back and forth. So this wouldn’t be good for continuous dynamic edits with auto-save via tiddlyhost (say), where you risk having the toggled-to-edit mode served up to the public.
But it would work well for a “publish, but retain the ability to toggle back into edit mode and re-publish with revisions later” kind of model, yes?
Your solution also reminds us that plugin editors can only make a best-guess menu of what we probably want to hide from public view. But for that reason TiddlyTweaks’ version of read-only mode has a free-form read-only css area. I use this for clearly-named css classes like “author-note” (that I can apply to spans and divs and whole tiddlers) — specified as .author-note {display:none;} so that I can bracket anything that needs not to be displayed to the general viewing public, as in @@.author-note REVISE FOR NEXT SEMESTER @@ or even icons that appear before tiddler titles that meet some filter condition, designed to remind me that they’re high priority for editing attention… (I’ve also got red-outline styling for this class in my regular css, so that I’m reassured, in my own edit/author interface, that this note-to-self is not in fact going to show up for web-viewers. 
)
We should also remind folks that all of these reader-mode display tricks are only for stuff that isn’t high-stakes confidential! — just whatever would be distracting or irrelevant to the purpose of the wiki for end-readers. The whole html file is still available for inspection, if someone is determined to see what’s going on under the hood. I also tend not to disable complex keyboard shortcuts for things like Advanced Search, so that I can get under the hood quickly if I’m troubleshooting how the site appears within an LMS iframe, or verifying its appearance on an alternate browser where I’m not logged in, etc.
You’re correct that I’m “manually” toggling (well, automatically, but while building a different copy of the wiki).
But if you want the TiddlyHost situation, you could use a state tiddler that was configured to stay out of the saver to toggle the feature flag.
Unless someone copies the whole wiki, sees what needs to be added to make it work, and then adds the wiki to the wiki containing the toggle tiddlers.
Not sure though if it works that way, as this is based on adding code to a programming language.
I started using NodeJS to develop my wiki locally, and have implemented a scheme in which things that are tagged [[Private]] are not compiled when I run tiddlywiki wiki --build index to create the single file version of the wiki which I host for public consumption.
First make sure you have the tiddlyweb plugin installed in tiddlywiki.info
"plugins": [
"tiddlywiki/tiddlyweb",
"tiddlywiki/filesystem",
"tiddlywiki/highlight",
"tiddlywiki/markdown",
"tiddlywiki/qrcode"
],
Then edit the tiddler $:/plugins/tiddlywiki/tiddlyweb/save/offline and specify which tags to remove from the build process, in my case [[Private]]
\import [subfilter{$:/core/config/GlobalImportFilter}]
\define saveTiddlerFilter()
[is[tiddler]] -[[$:/boot/boot.css]] -[prefix[$:/HistoryList]] -[status[pending]plugin-type[import]] -[type[application/javascript]library[yes]] -[[$:/boot/boot.js]] -[[$:/boot/bootprefix.js]] -[[$:/plugins/tiddlywiki/filesystem]] -[[$:/plugins/tiddlywiki/tiddlyweb]] -[prefix[$:/temp/]] -[tag[Private]] +[sort[title]] $(publishFilter)$
\end
{{$:/core/templates/tiddlywiki5.html}}