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.

2 Likes

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>
2 Likes

@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