create new tag
, view all tags
savemulti is an addon script from KoalaSkin which merges the functionality of the stock save and preview cgi scripts. Savemulti has been in use on many systems for a long time, years, with no significant problems reported. This topic is about what needs to be done to replace the stock SaveCgiScript with savemulti.

savemulti is just like save, with another optional parameter in the URL: action which can take the values (set by the forms in the edit template):

  • Checkpoint save & continue editing
  • QuietSave save but don't trigger email notification
  • Cancel cancel edit, release lock
  • Preview go to preview view.
  • anything else saves and returns to view mode.
Thus, basically this script is just an if/then/else on the value of action, doing in this case slight variations of what is done in save

Issues to be addressed

We can take it into the CairoRelease after testing: does it work with forms? does it work with repRev? delRev? etc? savemulti would be renamed to save and replace save and preview.

Preview mode is not going to be removed. this is simply proposal that preview should be an option and not forced upon those who don't want to use it all of the time. This has not changed.

Test Results

repRev and delRev

Here are my (MattWilkie's) results of testing repRev and delRev in conjunction with savemulti. Please see the description in TWiki.cfg for what repRev and delRev are.

I did not test from a username which is not part of the TWikiAdminGroup


  • save and quietsave are successful.
  • checkpoint works the first time - it saves the edit - but when the page reloads you are taken out of repRev mode so any subsequent actions are logged.
  • preview works, however like checkpoint subsequent action, e.g. save from the preview screen increments the revision number (and author).


  • save and quietsave are successful, the last revision is deleted.
  • checkpoint works, but like repRev you are kicked out of delRev mode (which is probably a good idea anyway. How often are you going to want to delete multiple revisions like this?)
  • preview gave me the "Access Denied. Only members of the TWikiAdminGroup are allowed to perform this action." message. I am a member of the admin group however.

Server Apache/1.3.27 (Unix) Debian GNU/Linux mod_auth_pam/1.1.1 mod_perl/1.27
Client Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507
Perl 5.8.0
twiki Alpha 13 May 2003
skin SeeSkin (actually SeeSkinToo, from cvs)
savemulti # CN 28 Feb 2002 (I think, I did not see an explicit version number)

None of the problems discovered with the *Rev commands would affect people using the classic twiki skin because the extra functions are not exposed. Thus they are not a reason to not include savemulti in the core (but they should still be fixed).

-- MattWilkie

Does this still need more testing before it can be accepted as core? Peter said "does it work with forms, does it work with repRev, delRev, etc?" and Matt has answered repRev and delRev. Nobody has mentioned specificaly that forms are ok, what else is there that needs testing?

Are there any remaining objections to its incorporation into the core?

Anecdotal Reports

I've been using savemulti for awhile now and I'm an addict. No more lost edits by inadvertantly closing the browser window. Which is unfortunately quite often for me as I usually have Sticky Keys turned on. (SK means that when you slap ctrl ,for example, and it stays depressed until after the next keypress.) However I've noticed that using it plays havoc with the WebStatistics. On my work twiki I'm currently credited with 43 topic actions on a page I only created three days ago! : -) -- MattWilkie 19 Sep 2002

I used savemulti for a while w/o problems, really love it. I strongly second the wish to make savemulti the default. You want that extra preview cycle only in rare cases. And the checkpoint is really worth it! -- PeterKlausner - 26,28 Aug 2002

Never encountered a problem with savemulti; using it for 11 months and ~10 different forms. Haven't tried the hidden admin options, I always resort to the shell for that stuff wink BTW: given the choice, my users ran just 276 previews compared to 12000 direct saves! -- PeterKlausner - 14 Jul 2003

I've used it at http://www.redbourn.org.uk/ for well over 18 months. My users don't have access to the shell and they have never asked me to fix a problem. -- MartinCleaver 15 jul 2003

I have been using savemulti for nine months and haven't had a single problem with it. I use it with forms. -- MattWilkie 15 Jul 2003

Of course savemulti is used here extensively at ILOG without problems by my users. On the repRev and delRev, I must confess that I never use them, as I never seem to remember their existence when I need them. And when I remember, I hesitate to use them because I do not know if they still work. Actually, I tried once to use delRev but it did not work because the last revision also changes attachements... (something that do not work as intended by the user with the original save script of course). [...] If delRev is important, make it a supported feature first, with a defined behavior (especially wrt attachements), but do not delay the savemulti feature... -- ColasNahaboo - 07 Aug 2003

JoelOnSoftware writes in Building Communities with Software:

Why don't you show people their posts to confirm them before you post them? Then people wouldn't make mistakes and typos.
Empirically, that is not true. Not only is it not true, it's the opposite of true.

Part one: when you have a confirmation step, most people just click past it. Very few people reread their post carefully. If they wanted to reread their post carefully, they could have done it while they were editing it, but they are bored by their post already, it's yesterday's newspaper, they are ready to move on.

Part two: the lack of the confirmation step actually makes people more cautious. It's like those studies they did that showed that it's safer, on twisty mountain roads, to remove the crash barrier, because it makes people scared and so they drive more carefully, and any way, that little flimsy aluminum crash barrier ain't gonna stop a 2 ton SUV moving at 50 mph from flying off the cliff. You're better off, statistically, just scaring the bejesus out of drivers so they creep along at 2 miles per hour around the hairpins.

Possible Changes

There is one change I would like to see, but don't think implementing it should keep it out of the core, namely: recieving an unexpected input value parameter should return an error condition. The lack of this caused me to chase my tail for several days trying to figure out why my form was not working as expected. This "lack" does not cause problems for day to day use, only for troubleshooting skin development.

Other issues

The whole delRev interface is wrong and prone to error. Far better would be a page/dialog which lists the revisions and asks you to pick which one(s) to delete. This is not particular to savemulti, the current save is just as wrong.

There is also the very important question of whether repRev and delRev should ever be used. That however is a debate for another day and another topic.

On the repRev and delRev, I (CN) must confess that I never use them, as I never seem to remember their existence when I need them. And when I remember, I hesitate to use them because I do not know if they still work. Actually, I tried once to use delRev but it did not work because the last revision also changes attachements... (something that do not work as intended by the user with the original save script of course).

Notes on Using Savemulti

Information on using savemulti now, without waiting for it to be brought into the core.

Easiest way: use a skin which implements it, best choice is KoalaSkin. SeeSkin and PhotonSkin also use savemulti (there may be others, search the plugins web).

Roll your own: savemulti is intended to replace save and preview so it saves one script. As for the diff, well, it will just replace save by savemulti, but note that the templates will have to be modified accordingly.

ColasNahaboo incorporated the new save and preview scripts into it. Please review the template patches. There is an help text at the end that you may want to edit.

bugfix: Under mod_perl, savemulti can leave the lock if one previews before saving. Apply the additional patch save-multi.2.diffs to save multi after save-multi.diff

bugfix (found by Esteban Manchado): you need to edit the 2 lines (near lines 135 & 210) containing the string:

         $theParent = "" if( $theParent eq "%TOPICPARENT%" ); # means keep same
to add a backslash character:
         $theParent = "" if( $theParent eq "%\TOPICPARENT%" ); # means keep same
Otherwise it could mess saving topics without parents

Some of the issues you might encounter:

Savemulti seems to forget the loginname when saving, so changes belong to TWikiGuest. TOPICINFO says guest, the lock file says MyName on first edit, but guest after first save, if you re-edit, the topic is "locked by another user", save instead of savemulti in the edit.tmpl works correctly!?

You probably have forgotten to declare savemulti as requiring valid user in .htaccess just as for save

Why does Checkpoint save implies dontNotify? We have been using savemulti for some months now, and we love it, but some days ago we noticed that some changes were not appearing in the .changes file. We need them there because of a program we wrote (the "lurker", a mixture of page diff and WebChanges), and when someone uses Checkpoint, the changes don't appear in there. I suppose the patch is simply remove the $dontNotify = "checked";, but I don't know why is it there in the first place. Comments?

-- EstebanManchado - 30 Jul 2003

For me it is because Checkpoint is a "save and continue editing" mode. Which means don't tell everybody yet because I'm not finished. When I'm done I'll slap Save to let everybody know.

-- MattWilkie - 30 Jul 2003

Yes, this was the intended reason. The use case of checkpointing is really work in progress, to save intermediate state in case of browser crash, and to provide some sort of undo mecanism (reverting to last checkpoint) I do not think one want to notify on the checkpoints.

-- ColasNahaboo - 31 Jul 2003

The rationale sounds all fine. But at least with the AthensRelease, it doesn't work like this:

  • the very first save (or checkpoint) determines, whether notification will be sent or not
  • ticking/unticking the box on later saves does not change the notification flag

I guess this feature/bug is not easy to fix. Un-doing the notification with a later save means deleting entries from the .changes file, not just slapping a line to the eof.

at least turning notification on should be easy, which would cover the checkpoint, checkpoint save scenario

-- PeterKlausner - 31 Jul 2003

Mmm... I think it is a TWiki bug, not a savemulti one, see bug description and patch at SaveWithinHourShouldNotifyChange

-- ColasNahaboo - 31 Jul 2003

Related thoughts

An investigation of the goals and requirements of preview is discussed in SaveWithoutPreview.

-- ThomasWeigert

Controll the appearance of preview and save in an AdministratorControlledWorkflow

-- MartinCleaver - 12 May 2004

Alternate approach to skipping Preview

Combined Preview/Edit Window

Alternatively, what if we had a 'View Preview in New Window' button. It would pop a purely cosmetic page showing what your page would look like if you were to save it. Repeated clicks on this button would then refresh this same window rather than pop additional ones (this is pretty easy with JavaScript). This would eliminate the need to continually do 'Preview' and 'Back'.

-- MattWalsh - 01 Mar 2001

I'm not sure about having the Edit box in Preview - I've seen this on some Wikis and WebLogs, and it works fine on short pages, but would be a real pain on long pages (which are common on TWiki). So I'd prefer a SavemultiCgiScript approach to Preview that lets you just go Edit-Save if you don't want a preview (like on SlashDot).

-- RichardDonkin - 11 Feb 2002

Replace Preview with Save

thanks MartinCleaver, and thanks CrawfordCurrie and #twiki-irc All this time I've been waiting for a fix to savemulti, when all I really wanted was to be be able to replace the Preview button with a Save button. In any skin. The answer is: edit edit.tmpl, any variant, and replace 'preview' with 'save'. There are two occurences, the first is the script path (bin/preview) and the second is the label of the button (Preview Changes). And that's it. really. sheesh.


Many thanks to all People who contributed to this feature and related stuff over time:

ColasNahaboo, PeterKlausner, MartinCleaver, PeterThoeny, MattWilkie, JohnTalintyre, MartinCleaver, WillNorris, SamHasler, ArthurClemens, SvenDowideit, WalterMundt, LynnwoodBrown, BenoitFauvel, AndrewTetlaw, AndreUlrich, RichardDonkin, MattWalsh, HansDonner, DougPhilips, PeterMasiar, RandyKramer, ThomasWeigert,

REFACTORING FODDER BELOW refactoring in progress. don't be shy about putting in your bit :)

as savemulti is just another parameter, i don't see why we don't merge its functionality into the core save - if no-one objects, I'll look at this in the next week or so.

-- SvenDowideit - 02 Mar 2004

I agree, Sven. I'm going to go ahead and move this into PatchReadyForCVS.

-- WalterMundt - 05 Mar 2004

snippets to go to other pages, where they are closer to the central topic theme

See DownUploadForEditing for a simple patch to upload the topic text from a local (text-) file. Just define a form with <input type=file name=textfile> to trigger this feature. -- PeterKlausner

BTW, this exemplifies why we need either some "recommended list of patches to apply" or some regular update of the core to avoid having too diverging codes in the stable and alpha ones. For KoalaSkin, you can see that I maintain such a list at http://twiki.org/cgi-bin/view/Plugins/KoalaSkin#New_installation_HOWTO (see point No 5). Such a global list on TWiki.org would be great I think (with a link to click and painlessly upgrade a running installation) -- ColasNahaboo

  • I fear that the delay in getting it rolled in is symptomatic of the fact that there are few TestHarnesses written for TWiki and no TWikiTestMaster to coordinate testing beyond adhoc anecdotal evidence. A TWikiTestMaster would explicitly write a test plan for each piece of functionality. Not having such plans means we end up being over cautious about accepting patches into the core. This cautiousness then drags TWiki's speed as an OpenSource project and ultimately impacts people's enthusiasm to contribute patches.
  • Non-rollout of this patch has impacted further - there are copies of it bundled with multiple skins, often renamed as something else (AmbarSkin) but otherwise unchanged. This has happened because 1) the functionality is widely wanted and 2) we don't have a TWikiPluginsMaster to coordinate. In turn this pollutes the TWikiBaseDir/bin directory and causes more PluginBinNameClashes, not to mention making even more difficult the process of completing ConsolidateFunctionalityFromSkins.

-- MartinCleaver

Savemulti for twiki beta 07-May-2004

I upgraded twiki to 2004-Feb-08 Alpha and now savemulti is broken: on save topicname and webname are reversed and you get thrown to the webnotfound oops page. If you go to Preview and save from there, it works.


With Cairo (May beta release) and AmbarSkin, SavemultiCgiScript (as ambarsave) breaks before the end. Message is "this topic does not exist yet" and bin/view//TestTopic occurs.

This has a bug in it caused by Walter's removal of old support code in TWiki.pm v 282. MartinCleaver supplied in-topic patches which have been integrated into the attached savemulti by MattWilkie (thanks to LynnwoodBrown's clarification). Known to work with CairoRelease (tested against beta 2004 May 07). Changes: fixed disappearing $webName, some calls were moved to the new RenderDotPm (encode/decodeSpecialCharacters); read SavemultiCgiScript rev 1.67 for details.

Savemulti for DakarRelease CairoRelease

As savemulti embeds it's own copy of the preview script, changes to the mainline preview need to be backported to savemulti. Better to move savemulti into SaveDotPm, see SavemultiIntoSaveDotPm.

DONE! don't use the attached savemulti unless you can't wait for the next release with the integrated save and savemulti. It should be in CVS (well, SVN) soon.

-- MattWilkie - 11,14 Jul 2004

WELL DONE! Good work on the tenacity! I'd given up hope, but this really is encouraging. Should this now be marked FeatureDone?

-- MartinCleaver - 15 Jul 2004

REMINDER the standard installation doc still has a ThisIsWrong badge in it covering the lock changing. That section of the doc needs to be removed/rewritten!

-- CrawfordCurrie - 19 Jul 2004

ok guys, I have applied the patches to my local test version, now I want to know explicitly

  1. can I just call TWiki::UI::Save::savemulti( $web, $topic, $userName, $query ); in SaveCgiScript rather than creating a new CgiScript (with all old save functionality still working (seems to work for me..))
  2. where is the docco for how a template developer is to use this stuff? (i've worked out from teh code what i need to do but.)

once these and other details are banged out (probly on irc smile ) we should be able to commit and have one fully functional SaveCgiScript (otherwise changing all the old templates will be too much work)

-- SvenDowideit - 21 Jul 2004

  1. Yes, if you have tested it to your satisfaction
  2. Not written yet, AFAIK

-- CrawfordCurrie - 22 Jul 2004

Patched applied to SVN with savemulti called from SaveCgiScript (all old functionality from save still works the same)

  • default edit template done
  • pattern skin edit template changed to use the field set version Matt has given us - Arthur, do you have time to make it look good for this weekend?

-- SvenDowideit - 23 Jul 2004

For Skin Developers, to use savemulti

1) In edit.my-skin.tmpl replace preview with save :

<form name="main" action="%SCRIPTURLPATH%/save%SCRIPTSUFFIX%/%INTURLENCODE{"%WEB%/%TOPIC%"}%" method="post">

2) and change topicaction from this:

%TMPL:DEF{"topicaction"}% <input type="submit" value=" &nbsp; Save Changes &nbsp; " />
  %TMPL:P{"sep"}% <a href="%SCRIPTURLPATH%/view%SCRIPTSUFFIX%/%WEB%/%TOPIC%?unlock=on">Cancel</a> edit %TMPL:END%

to this:

<fieldset><legend><span class="deem"> [[%TWIKIWEB%.AccessKeys][AccessKeys]]: S = Save, Q = Quiet Save, K = Checkpoint, P = Preview, C = Cancel</span></legend>
   <label accesskey="s" for="save">
      <input type="submit" name="action" value="Save" />
   <label accesskey="q" for="quietsave">
      <input type="submit" name="action" value="QuietSave" />
   <label accesskey="k" for="checkpoint">
      <input type="submit" name="action" value="Checkpoint" />
   <label accesskey="p" for="preview">
      <input type="submit" name="action" value="Preview" />
   <label accesskey="c" for="cancel">
      <input type="submit" name="action" value="Cancel" />

Note: the above example uses AccessKeys which might not be appropriate for all sites. If you don't want to use them, use something like this instead (this is used on the default twiki skin):

   <input type="submit" name="action" value="Save" />
   <input type="submit" name="action" value="QuietSave" />
   <input type="submit" name="action" value="Checkpoint" />
   <input type="submit" name="action" value="Preview" />
   <input type="submit" name="action" value="Cancel" />

3) and update the help ('TWiki06x00.WikiSyntaxSummary'):

   * *Save:* Save topic and return to normal view
   * *QuietSave:* Save but will not trigger email notification to people monitoring the page (checks the "Minor changes" checkbox)
   * *Checkpoint:* Save, and re-edit immediately
   * *Preview:* Do not save yet, but show what the topic would look if saved
   * Cancel:* Discard changes and return to view mode, release lock
   * *Do not use BACK in your browser to cancel* instead, or the topic will stay locked, preventing other people to edit it for one hour

-- MattWilkie - 23 Jul 2004

Removed CSS id tags and SeeSkin specific reference. Added sans-AccessKeys example. Added text from Sven which I inadvertantly deleted yesterday.

-- MattWilkie - 24 Jul 2004

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatdiff edit.tmpl.diff r1 manage 2.5 K 2002-08-29 - 09:17 ColasNahaboo diffs against TWiki20020803beta
Unknown file formatdiff preview.tmpl.diff r1 manage 2.0 K 2002-08-29 - 09:18 ColasNahaboo diffs against TWiki20020803beta
Unknown file formatdiffs save-multi.2.diffs r1 manage 0.7 K 2002-09-12 - 13:26 ColasNahaboo additional patch to apply after save-multi.diff
Unknown file formatdiffs save-multi.diffs r1 manage 6.9 K 2002-08-29 - 09:01 ColasNahaboo diffs against save of TWiki20020803beta
Unknown file formatEXT savemulti r2 r1 manage 10.0 K 2004-07-05 - 11:46 MattWilkie updated to work with twiki beta 2004 May 07
Unknown file formatdiff savemulti-preview-enhancements.diff r1 manage 0.5 K 2003-09-30 - 08:38 WillNorris in preview mode, links open in a new window
Edit | Attach | Watch | Print version | History: r83 < r82 < r81 < r80 < r79 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r83 - 2004-08-22 - SamHasler
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2015 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.