Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#1 2006-03-10 16:12:37

R.M.S.
Member
Registered: 2005-09-12
Posts: 15

Versioning / Autosave / Locking

Versioning / Autosave / Locking are three related concepts on which I’ve tried to make some of the options and problems clear. You are ofcourse encouraged to participate and discuss this. My own experience comes from a student newspaper where I work and where I have integrated a modified TxP into the workflow. This has been a real success story, and these functions could make things even better. I originally thought these were “specialist” requirements (found in expensive publishing software used by newspapers), but apparently other TxP users find things such as versioning etc. handy as well.

There are multiple problems these functions are meant to solve:

PROBLEM: Multiple concurrent edits (a) waste time (b) relegate every edit except the last one saved to the garbage bin.

ASSESSMENT: (b) is solved by a good versioning system, in which any version is saved and remains available. (a) is not solved by versioning, since in the end you want one published version, multiple different edited versions are pointless. It may however be solved by locking the file. When one person is editing an article, nobody else can.

PROBLEM: the editor accidentally deleted a crucial part of the original article, and him or someone else wants to restore it.

ASSESSMENT: Restoration (i.e. “click here to revert to previous version”) is a primitive kind of versioning. Full-blown versioning is preferred, so the other (good) editorial work can be kept, while giving the editor a chance to check previous versions to correct his mistake.

PROBLEM: (true story) Somebody pulls the plug from a computer. A writer loses his article-in-progress entirely.

ASSESSMENT: Autosaving solves this, on the condition that it not only functions for existant articles, but also for articles that haven’t been saved ever before.

** 1. Versioning **
See also: http://forum.textpattern.com/viewtopic.php?id=12354
See also: http://forum.textpattern.com/viewtopic.php?id=14044
See also: http://textpattern.net/wiki/index.php?title=Article_version_control

I think there are already some really good ideas about versioning in the previous threads.

** 2. Autosave **
When combining autosaving with versioning, the following question arises: should every autosave start a new version? This is likely somewhat over the top.

My ideas:
- If the article has never been saved before, when autosave is set into function it pops up a dialog box asking “do you want to save this article now and put autosave on?”. As such autosave can be connected to an article_id.
- Autosave works by overwriting the version one is writing or editing. Only when one presses the save/publish button, versioning is put into action.

PROBLEM: Should a new version be created upon opening an article, or upon saving one? This could provide difficulties in combination with autosave. If one chooses to create a new version upon saving, all autosaves that have happened before are in the previous version, so the previous version is “gone”. This makes versioning far less useful.

So making a new version upon (starting) editing seems smarter. However, this is somewhat problematic as well, since it creates a new version every time someone clicks on an article to see its contents in the List view. This could be lessened by making a new version upon the first autosave. Another option is by making the edit window uneditable by default, and introducing an “edit” button that makes it writable again. This edit button then creates a new version as well.

** 3. Locking **
See also: http://forum.textpattern.com/viewtopic.php?id=9653

I think locking is less problematic than it is made out to be.

Basic working: two database fields per article (or rather each version), one with a date (when the lock was put into action), one with an amount of minutes.

People do not put indefinite locks on articles, but (a) a lock lasts a fixed amount of time (b) if this fixed amount is not what is wanted, people can choose a custom lock (.c) upon saving, the lock is disengaged, regardless of lock-time remaining.

The normal situation is that locks dissapear upon save, problems are adressed by (a) giving admins, editor-in-chief etc. unlocking capabilities and (b) by auto-unlock when the time the lock is active has expired.

PROBLEM: upon saving, one is returned to the edit view instead of to the list view (at least in 4.01 this is so). Perhaps one wants to edit some more, but the lock is now automatically disengaged!

This can be solved by various approaches:
- (as said) custom-time locks editors and writers can start themselves. The editor just starts a new lock for his re-read.
- The “Edit” button I mentioned in relation to versioning. Locks are engaged when this button is clicked.
- Easiest approach: return one to the list view instead of to the edit view upon saving an article.

PROBLEM: when the lock time has expired but the editor is still editing, he loses the security of locking.

Solutions:
- When lock time is about to expire, a dialog asks if one wants to “add minutes”.
- Versioning takes limited (!) care of this as well, by creating different versions if different people edit, so the editor his very long edit-session will not just disappear.

PROBLEM: should a lock affect a version of an article, of the article as a whole?
SOLUTION: when one tries to edit a locked article, a dialog asks if one wants to start a new version.

PROBLEM: should a locked article still be viewable by all?
SOLUTION: yes, it is just not editable, and it must be (visually) clear that this is the case.

Last edited by R.M.S. (2006-03-10 19:12:50)

Offline

#2 2006-03-13 03:10:38

Jeremie
Member
From: Provence, France
Registered: 2004-08-11
Posts: 1,578
Website

Re: Versioning / Autosave / Locking

It will take some time to see this through, and comment on it.

Offline

#3 2007-02-16 20:21:22

tgermer
New Member
From: Portland, Oregon
Registered: 2005-01-25
Posts: 7
Website

Re: Versioning / Autosave / Locking

Is Autosaving a feature we can expect in version 4? I’ve had the pain of losing a few posts recently, and on the flip-side, have had the joy of using Google’s autosave in Gmail. I wouldn’t mind an Autosave feature that just auto-saved on-top of the previous save every couple minutes, or every x characters written.

In the meantime, I’m trying my best to remember the habit of saving it as “Draft” whenever I make substantial edits.

Offline

#4 2007-02-17 06:07:01

Jeremie
Member
From: Provence, France
Registered: 2004-08-11
Posts: 1,578
Website

Re: Versioning / Autosave / Locking

Not in core as far as I know.

But I think it could be done with a plugin.

Offline

#5 2007-02-17 07:18:54

colak
Admin
From: Cyprus
Registered: 2004-11-20
Posts: 9,090
Website GitHub Mastodon Twitter

Re: Versioning / Autosave / Locking

If it is implemented I would have autosave as an optional. I would hate a text going live whilst working on it.


Yiannis
——————————
NeMe | hblack.art | EMAP | A Sea change | Toolkit of Care
I do my best editing after I click on the submit button.

Offline

#6 2007-02-17 07:45:05

Jeremie
Member
From: Provence, France
Registered: 2004-08-11
Posts: 1,578
Website

Re: Versioning / Autosave / Locking

That’s not what autosave is. Autosave just save your article often, without your intervention, while you writing it.

Offline

Board footer

Powered by FluxBB