TW - view vs edit modes

I have been firing off questions and getting great answers… and learning from this group. I think I need to share a small snippet in return. I have written a couple of help files in TW, including one for my latest project Memory Keeper. The help file is a dedicated TW file that I put online. Memory Keeper references the online help. When end-users view this file I wanted to hide specific TW editing controls. But, when I edit the content I do not want to manually unhide these controls each time.

I’m sure there are numerous ways to address this. I elected to use URL parameters. I put together a macro to return the value of a specific URL parameter. Macro getUrlParameter has two parameters, 1. the name of the parameter you want the value of; and 2. if that parameter name is missing from the URL what default value should getUrlParameter return.

Eg. <<getUrlParameter mode "view">>

This example says return “view” if parameter “mode” is missing from the URL, otherwise return the value of mode from the URL.

Eg. mysite.com/mytiddlywiki.html?mode=edit

In this way, I can control an edit mode session vs a view mode session of my TW help file.

In some TW help files, I use other parameters. Eg. user=operator vs user=administrator
…where I wanted to hide administrator help from operators.

The getUrlParameter macro

Type: application/javascript
module-type: macro

/*\
title: getUrlParameter.js
type: application/javascript
module-type: macro

Macro to return a Url parameter

\*/
(function(){

"use strict";

exports.name = "getUrlParameter";

exports.params = [
{ name: "theParameter" }, { name: "defaultValue"}
];

exports.run = function(theParameter, defaultValue) {

var queryString = window.location.search;
var urlParams = new URLSearchParams(queryString);
var selectedParameterValue = urlParams.get(theParameter);
if (selectedParameterValue == null) {
   return defaultValue;
} else {
   return selectedParameterValue;
}
};

})();

Example usage in a StyleSheet tiddler… only if mode=edit will the user see edit controls the TW.

<$reveal type="nomatch" default=<<getUrlParameter mode "view">> text="edit" >
  button[title="Edit this tiddler"], 
  button[title="Create a new tiddler"],
  button[title="Save changes"],
  button[title="show/hide control panel"],
  button[title="Show information for this tiddler"],
  button[title="Create a new tiddler tagged with this one"],
  button[title="Create a new journal tiddler tagged with this one"],
  button[title="Clone this tiddler"],
  button[title="Export tiddler"],
  button[title="Delete this tiddler"],
  .tc-subtitle {display: none !important;}
</$reveal>

Tip: If you implement this… add ?mode=edit to your URL before adding the CSS to it. In this way, as you edit your TW you will not lose your edit controls.

Note that the TWCore already extracts the window.location.search URL value and stores it in the “$:/info/url/search” shadow tiddler at startup. Thus, without adding any extra macro code, you can write:

<$list filter="[{$:/info/url/search}removeprefix[?]split[&]match[mode=edit]]">
   ... your CSS goes here ...
</$list>

and, for cases where a fallback value (e.g., “view” or “edit”) is to be used:

<$list filter="[{$:/info/url/search}removeprefix[?]split[&]removeprefix[mode=]match[edit]else[view]]" variable="mode">
   the mode is <<mode>>
</$list>

@EricShulman Thank you for this.

I wrote the macro after a search on the topic for this–which came up with nothing.

Gee, I suspect there are a bunch more tiddlers I could refactor knowing this kind of information.

The ideas here would be nice packaged as a wiki “mode solution” rather than just documenting the parts.

I returned here and went to do this however found problems and erratic results, but after an hour I rediscovered a bug in my prefered save method - via Timimi plugin.

If I can’t raise Rizwan ibnishak I hope someone with some Bowser addons dev experience may be able to help.

Note:

  • Have tested saving a tiddlyhost wiki with “?test” on the URI and it works

On top of tiddlyhost I am developing the solution further, and will package it and add it here.

Observed bugs in above solution;

  • The edit button is not being hidden in read only mode

Adding features

  • Providing matching startup actions for both modes to allow more advanced settings
  • Rather than only allow edit on “mode=edit” I am allowing this to be configured so one could use a complex string instead.
    • Although since this string is passed on the URI it is not that secure (but better than nothing)
    • Allow a bookmark be generated that allows edit mode
  • Provide a bookmarklet that can override the read-only trigger
  • FInd a way to disable shortcuts that bypass hidden buttons eg ctrl-s for save wiki