Support for edit caching

[BrianKoontz]

Note: This code has been converted to a Wikka plugin. More details here:  http://www.wikkacase.org/wiki/EditCache

WordPress and other CMSes offer a feature that permits the user to cache their edits for later retrieval. This enhancement provides similar functionality for WikkaWiki. Specifically, each user has the option of saving their edits (on a per-page basis) for future retrieval in the edit window. To keep things simple, the following design criteria is used:

• Only one edit cache object per user per page
• Any existing edit cache is deleted when page is published (i.e., saved as a new page)
• To differentiate between "saving" an edit for later retrieval and "saving" a page for display, a new term, "publish," has been adopted to indicate a page save that will make the page publicly viewable. "Save" (such as "save and continue", "save and quit") refers to an edit draft that will not be made public until it is published.

Further enhancements might include:

• Auto-purging of caches after a specified time period
• An auto-save feature
• A diff display between an edit cache and the current page contents
• Support for multiple drafts in association with a single user and a single page

Related tickets

• #676 page drafts (ACL)

[BrianKoontz]

(In [1191]) Initial implementation of edit caching. Refs #794

[DarTar]

Brian, very interesting proof of concept. The design is obviously much more complicated than in a blog because we must take into account revision control and collaborative editing, but I like the idea very much. A few random notes:

• here (and in your edit cache notes at WC) you should distinguish for clarity between "page" and "revision", otherwise your workflow description is confusing;
• I think there should be the possibility to save any revision of a page as a draft for further use (e.g. cloning or branching);
• diff against a given revision (head by default) would be a very nice addition indeed;
• there's an easy way in WordPress to visualize existing drafts (for a page or for a user, depending on privs), I don't seem to find anything like this in your implementation (unless I'm missing something);
• your system doesn't allow collaborative drafts, or draft pages edited by a group of users before being published. The latter could just be a matter of ACL setting (instead of caching, see #676), but the fact we refer to both kinds of functionality as "drafts" is a bit unfortunate.

- the current GUI with two separate fieldsets is IMO not very intuitive for the end user, who may not know exactly what is going to happen when clicking on any of these buttons. We need to think this carefully through.

[DarTar]

To put the distinction more clearly, this ticket refers to (unversioned) revision drafts whereas #676 refers to (versioned) page drafts. Does this make any sense?

[DarTar]

A few notices:

Notice: Use of undefined constant ACCESSKEY_SAVE_AND_CONTINUE_BUTTON - assumed 'ACCESSKEY_SAVE_AND_CONTINUE_BUTTON' in trunk/handlers/edit/edit.php on line 321

Notice: Use of undefined constant ACCESSKEY_SAVE_AND_QUIT_BUTTON - assumed 'ACCESSKEY_SAVE_AND_QUIT_BUTTON' in trunk/handlers/edit/edit.php on line 322

Notice: Constant PATH_SEPARATOR already defined in trunk/wikka.php on line 282

[BrianKoontz]

Changed title to better reflect differences between this work and #676.

To clarify:

• here (and in your edit cache notes at WC) you should distinguish for clarity between "page" and "revision", otherwise your workflow description is confusing;

A "page" is the most recent revision. Edit caching is simply a backup of the current edit window. It's not intended that multiple cache "revisions" are tracked.

• think there should be the possibility to save any revision of a page as a draft for further use (e.g. cloning or branching);

That would be an issue better suited for #676.

• diff against a given revision (head by default) would be a very nice addition indeed;

Again, an issue for #676.

• here's an easy way in WordPress to visualize existing drafts (for a page or for a user, depending on privs), I don't seem to find anything like this in your implementation (unless I'm missing something);

That's because in WP, a blog entry is a "standalone" object: It's not associated with a page or any other type of object, and a user can have several that can be named differently. In fact, I see this feature of WP to be more in line with #676. What I'm trying to capture in this specific ticket is the ability to (1) autosave the edit window as a backup; (2) come back and work on an edit later. Nothing more, nothing less :)

• your system doesn't allow collaborative drafts, or draft pages edited by a group of users before being published. The latter could just be a matter of ACL setting (instead of caching, see #676), but the fact we refer to both kinds of functionality as "drafts" is a bit unfortunate.

Yes, we seem to have fallen into a semantic trap here. I don't believe the word "cache" carries the same meaning to end users as "draft," yet this really is an implementation of a "cache."

• To put the distinction more clearly, this ticket refers to (unversioned) revision drafts whereas #676 refers to (versioned) page drafts. Does this make any sense?

More like: this ticket refers to a single edit draft...

Really, the intent of this was to simply provide "save and continue" functionality in the event that a browser crash destroys whatever editing you've done. Any additional functionality would be more appropriate to address in #676 (or a separate ticket).

[NilsLindenberg]

(In [1197]) refs #794: fixing a critical bug in caching mechanism + correcting two constant names to prevent notices

[DarTar]

Brian,

after your explanation (which makes the distinction with #676 very clear), there are two reasons why I think the current implementation is problematic:

• it makes the edit screen much more complicated without providing sufficient help (some colleagues of mine don't even understand that they have to click on store in order to save a revision, now imagine if they see a form with 7 buttons!)
• it doesn't address the question of edit conflicts

If this functionality is really about "caching" (and not about drafts), I suggest we make it as invisible as possible in the GUI. Ideally a cache should be automatically saved every N minutes by the engine (if caching is enabled) rather than manually by the user.

Messages offering the user to retrieve a cached version should only be displayed IMO if the revision was accidentally not stored and no one else in the meantime has edited the page. Otherwise we may have cases in which someone reinstates a 1-month-old cache over other users' edits. To avoid this, we should give feedback about the draft being older than the most recent revision by JohnDoe, but this sounds overly complicated from the end-user point of view. What do you think?

[BrianKoontz]

I believe there are some users who would appreciate the ability to save their current edits, especially in the case of a long edit where a browser crash would be an inopportune event. That said, I don't believe the consensus of the core devs is to support this as implemented in 1.1.7, so I'll back the changes out. If possible, I'll try to modularize some aspects of the edit handler so this functionality can be downloaded as a module from WikkaCase. I'll also look into the feasibility of a "simple" edit cache as you've suggested.

[BrianKoontz]

(In [1225]) Backed out all changes. Refs #794.

[BrianKoontz]

Ticket closed due to lack of consensus as to whether this should even be a feature of Wikka.