Help! Conditional handling for "prevent edit" plugin?

#1

Dear javascript folks, and perhaps @linonetwo in particular:

My “customers” (students) really should NOT see a “Do you really want to close/leave???” warning. They’re not editing, and there’s nothing for them to save, so it’s distracting.

I happily installed the prevent-edit plugin to solve this problem. The core of the thing is super-simple (though the plugin has readme and other plugin stuff):

exports.startup = function() {
  $tw.unloadTasks = $tw.unloadTasks.filter(task => !task.toString().includes('confirmationMessage'));
}

Recently I’ve gotten burned a few times in a row; I’ve lost serious author-mode work because of completely accidental tab-closures (errant key-strokes, mouse-clicks that land “behind” where I think I’m clicking, etc.).

So, javascript-savvy folks: How do I hack prevent-edit so that it CHECKS whether the wiki is in read-only mode, and prevents the alert ONLY IF wiki is in read-only mode?

In other words, I want to KEEP the alert (preventing accidental closure with unsaved work), just when:

  • $:/config/utility/IsReaderMode has value no
  • Or: $:/status/IsLoggedIn has value yes would be equivalent for me, in practice.

Many thanks in advance!

#2

I will try to look in whatever spare time I can squeeze out during municipal and school budget season. But first, two questions:

  • Do you view the wiki in the same manner the students do? Or are there differences, such as between them seeing it over the web versus you viewing and editing from the file system?

  • Is readerMode static for a session or do you have a way to toggle it on and off in a running wiki?

1 Like
#3

It’s all TiddlyHost. (I dwell in TiddlyHost. Long live TiddlyHost!)

So I’m logged in when I edit (which is one of the cues that disactivates readOnly when the page loads), but everyone involved (students and I) are accessing over http:// at all times. .

When I’m in “reality-check” mode, accessing student view on a secondary browser without logging in first, I do have ways to toggle off the readOnly status for css purposes (to troubleshoot by accessing edit-mode GUI and system tiddlers that are otherwise suppressed), but I never attempt to log in “retroactively” in order to save from a session that launched as readOnly.

I believe $:/status/IsLoggedIn is set when the wiki loads, and I don’t generally change that. At any rate, I’d be plenty happy with a solution that keeps the “You might lose changes!” alert just for edit sessions that are properly initiated under the logged-in umbrella.

(When do I accidentally load the url without having logged in, I can tell immediately because there are so many visual cues, including a page-background color that differs based on whether I’m logged in. So even though I can in theory load the page in my main browser account without logging in, I never accidentally commence edits thinking that I’m logged in.)

#4

I don’t think a javascript solution is needed. Whether a save is necessary is set by a filter, then if there are any changes to the resulting titles the (CSS?) dirty state is set. This then triggers the save warning on exit.

Possible solution

Use the values of the above IsReaderMode and/or IsLoggedIn in the filter that sets the dirty indicator to dirty so the results are different based on the values.

I will see if I can find the tiddler implied in the above and edit here if I find it soon.

Edited: See SavingMechanism which says;

The saver mechanism uses the filter defined in $:/config/SaverFilter to specify which modified tiddlers trigger the dirty state for the wiki. (The dirty state is reflected in the red colouring of the “save changes” button in the sidebar).

The read colouring is a CSS state see $:/core/ui/Buttons/save-wiki

A simple change of the above filter is not working, I continue to research

#5

I think this will do it:

exports.startup = function() {
  if ($tw.wiki.getTiddler('$:/status/IsLoggedIn').fields.text !== 'yes') {
    $tw.unloadTasks = $tw.unloadTasks.filter(task => !task.toString().includes('confirmationMessage'));
  }
}

It’s barely tested, but I believe it would work.

I don’t know if @TW_Tones is right that this can be done easily without JS, but since it was already a JS solution, it seemed reasonable to just update the JS.

@linonetwo: I hope it’s not a problem that I simply altered your plugin in place. If you don’t like that, I will repost with one in a different namesapce. I upped the version to 0.0.2, so if you do additional development without these changes, it might be best to skip that version.

$__plugins_linonetwo_prevent-edit.json (2.7 KB)

#6

I am confident It can, I have done something similar previously however I don’t have the wiki that uses $:/status/IsLoggedIn to test on. Any guidance would be helpful, unless I just hack it.

  • It makes sense if one is already using prevent edit plugin to modify it as you propose.

On a related matter I would like to trigger actions on or before a “leave this wiki” message to optionally force a save (not for this current topic) or to trigger what I would call a “logout process”. A generic solution to only ask to confirm leaving if certain conditions are met eg; if $:/config/logout-needed=yes action then if $:/config/logout-complete=yes confirm (or don’t) leaving.

  • I am not yet sure if this is possible but I have seen suggestions it may be and it would be logical if a tab could manage its own exit.
#7

I have a wiki on TiddlyHost that is public. If you have one too, or can simply create one, then I think my technique would work for you too. Log into TiddlyHost on one browser, visit your wiki, make your changes, save your wiki, and use the “Refresh” button to test that the warning does show, i.e. that it hasn’t been suppressed. Open up a different browser, not logged into TiddlyHost, and visit your wiki, make some change, and refresh. If you’ve done it correctly, then the warning will have been suppressed on the not-logged-in browser.

#8

The filter contained in $:/config/SyncFilter which contains the default used (rather than $:/config/SaverFilter) seems to alter the the dirty state. ie if no tiddlers match it is not displayed.

Its default is;

[is[tiddler]] -[[$:/core]] -[[$:/library/sjcl.js]] -[prefix[$:/boot/]] -[prefix[$:/HistoryList]] -[status[pending]plugin-type[import]] -[[$:/isEncrypted]] -[prefix[$:/status/]] -[prefix[$:/state/]] -[prefix[$:/temp/]]

This seems to be applied to all tiddlers, one at a time.

#9

a non js solution maybe to conditionally blank the contents of $:/config/SaverFilter.

I created a tiddly with this content;

<$reveal type="nomatch"  state="$:/status/IsLoggedIn" text="""yes""">
<$action-setfield $tiddler="$:/config/SaverFilter" $value=""/>
</$reveal>
<$reveal type="match"  state="$:/status/IsLoggedIn" text="""yes""">
<$action-deletetiddler $tiddler="$:/config/SaverFilter"/>
</$reveal>

and tagged it with $:/tags/StartupAction/Browser

Note that the $:/status/IsLoggedIn will only change when you ‘hard reload’ the tiddlywiki from tiddlyhost - I use Ctrl + Shift + R to do this.

#10

Thanks. I think something like this will do, although I already have quite a complex saver filter in place, so I can’t just delete it in order to restore to shadow! Still, I can blank it out when the session loads without login, and since the saver filter itself can’t possibly save from that state, my usual saver filter will be in place when I load from logged-in condition.

It can also be manually changed by manually toggling out of readOnly mode, and then finding and setting to yes that $:/status/IsLoggedIn tiddler. Occasionally I do this if my TiddlyHost logged-in session times out, and I refresh a page without realizing this fact… Somehow the browser session itself sometimes hangs onto that no state, so a simple refresh doesn’t work to clear it. (Reloading a browser session on a mac is usually cmd-r; I’m assuming ctrl-shift-r is the win variant?)

#11

@Springer: I was wondering if you’d been able to test this and if it did what you needed. I know you have a different working solution, but I was curious.

#12

Scott, I hadn’t gotten to testing the javascript. I’m grateful for your devoting attention to it!

My wiki had a control-panel-related RSOD that I had to start troubleshooting soon after posting about the prevent-edit author-mode challenge. When you posted your suggested. code, I was feeling very gingerly about whether I had gotten to the bottom of that RSOD problem (I may post about it soon in case the troubleshooting is helpful to others), so I was delaying on adding anything that I didn’t myself understand fully.

#13

Makes sense. Hope you RSOD is really solved!

1 Like