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
repRev
-
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).
delRev
-
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
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:
- Q:
- Why don't you show people their posts to confirm them before you post them? Then people wouldn't make mistakes and typos.
- A.
- 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.
- hmmm
- 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.
Credits
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.
and
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
- 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..))
- 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
) 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
- Yes, if you have tested it to your satisfaction
- 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=" Save Changes " />
%TMPL:P{"sep"}% <a href="%SCRIPTURLPATH%/view%SCRIPTSUFFIX%/%WEB%/%TOPIC%?unlock=on">Cancel</a> edit %TMPL:END%
to this:
%TMPL:DEF{"topicaction"}%
<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>
<label accesskey="q" for="quietsave">
<input type="submit" name="action" value="QuietSave" />
</label>
<label accesskey="k" for="checkpoint">
<input type="submit" name="action" value="Checkpoint" />
</label>
<label accesskey="p" for="preview">
<input type="submit" name="action" value="Preview" />
</label>
<label accesskey="c" for="cancel">
<input type="submit" name="action" value="Cancel" />
</label>
</fieldset>%TMPL:END%
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):
%TMPL:DEF{"topicaction"}%
<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" />
%TMPL:END%
3) and update the help ('TWiki06x01.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