Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Re: [request] Page revisions/history
BTW there is a Textbook Feature request page about versioning if you want to start there in terms of gathering thoughts.
Shoving is the answer – pusher robot
Offline
Re: [request] Page revisions/history
It can (could?) be done as a plugin. Hook into saving articles (and others stuff), when TXP try to save them :
- Interrupt it
- Save the last data row from the appropriate table to a revision table, with a incremental revision number added
- Give back control to TXP
So, the big thing to do is no the engine, it’s the UI. How to design it to be functional, etc.
Offline
Re: [request] Page revisions/history
I think the UI could consist of a few additions to the write page.
- Add a new status radio button called “revision” or better still a “save Revision” button next to the “save” button.
- Add an expandable group above Advanced options that when clicked reveals…
- One revision per line containing…
- radio button
- Date of revision
- Name of revisor
- A “with selected” select listing
- delete
- diff
- edit
- A submit button
- One revision per line containing…
Don’t think you need much more…
Offline
#16 2007-02-16 13:59:10
- Prodoc
- New Member
- Registered: 2007-02-14
- Posts: 6
Re: [request] Page revisions/history
Some comment on the suggestions above:
- A ‘Save as Revision’ checkbox is only needed when editing an existing article. I don’t know what’s common practise in the Textpattern UI but we could disable the checkbox if we’re dealing with a new article and only enabling it, allowing people to check it, when we are editing an existing one.
- When an alteration is meant to be stored as a revision, you would also want a description input field to give a brief summary of the changes.
- Do you really want to have the revisions of an article listed on the write/edit page? I think we should to keep that as clean as possible and use it only for writing and editing. I think it’s better to handle the revision management on the ‘Articles’ tab. Here you have a list of all articles. Under each article you can make in indentation listing all the revisions of an article. These could be shown by default but I think it’s better to add an expand/collapse toggle before each article when there are revisions present. This would leave us with a better overview of all articles and you can display the revisions if needed for a specific article. Imo this is a good example of how it should look like: http://drupal.org/files/issues/diff-070115-orig-UI.png The ‘Show Diff’ button should be positioned directly above and/or below the radio buttons column.
- I think an edit option is redundant because there’s no point in altering a previous revision, that’s where you have revisions for. Instead, we need a revert option to revert to a previous version.
- A ‘With selected’ dropdown isn’t really an option. You are able to check two articles so to with one does the ‘delete’ or ‘revert’ option apply? ;-)
Offline
Re: [request] Page revisions/history
>Prodoc
Thanks for your feedback
- The more I think about it, the more I think that a simple “save revision” button, only appearing when you are editing an existing article on the write page, is the best option. I think it’s the clearest and most straightforward. It’d behave like upm_savenew.
- Description field, absolutely.
- Articles page as a home for revisions; indented, tippable is a nice way to handle it. (the write page would get too cluttered.)
- I think there’s a purpose for editing a previous revision, without creating a new one, or reverting to an old one to edit it.
- The “with selected” depends on it being a radio button, so it should work, but I’d be happy if there was a better way to handle it.
Good thoughts. Good direction. Anyone Else?
Are we ready for a mockup and a bounty?
Last edited by mrdale (2007-02-16 17:21:10)
Offline
#18 2007-02-17 13:39:21
- Prodoc
- New Member
- Registered: 2007-02-14
- Posts: 6
Re: [request] Page revisions/history
1. Two buttons would do the trick indeed. I do, however, feel that both buttons should be more descriptive. If we would have a ‘save’ and a ‘save revision’ button, people might get confused about what the purpose of the ‘save’ button is. To reduce this problem, ‘save existing article’ and ‘save as new revision’ would be better but might a bit too long again. A ‘save as new revision’ checkbox might be more appropriate again to prevent large buttons and also because both buttons would have about the same function. The checkbox should be unchecked be default if we’re dealing with a new article and checked by default if we’re dealing with an article which already has revisions.
4. The whole point of having revisions is to be able to go back in steps. If you edit a page, a new revision gets created. If you where to edit a previous revision, what would be the point if you are not going to use it as a new version to display on the website? With or without allowing to edit an existing revision, in both cases it doesn’t need an extra edit botton/link. You can just open a revision, which would present you with the edit screen just like a normal article, edit the page and save it with the ‘save as new revision’ checkbox unchecked.
I suggest we update the page mentioned by hakjoon with all specs, requirements and possibly a (couple of) mockup(s).
Offline
Re: [request] Page revisions/history
mrdale wrote:
Add a new status radio button called “revision” or better still a “save Revision” button next to the “save” button.
That’s too complicated for the average non-geek user. The revision-versionning system should be completely transparent for him, until he needs it.
Offline
Re: [request] Page revisions/history
>Prodoc said…
The whole point of having revisions is to be able to go back in steps.
Actually I can think of several good reasons why you’d want to keep and edit a previous revision without promoting it. Imagine you’re not just correcting, but editing parallel versions that are both viable banches. However, I’d be happy to settle for revisions without this capability if there’s consensus that this is confusing behavior.
Last edited by mrdale (2007-02-17 20:35:20)
Offline
Re: [request] Page revisions/history
From my point of view: each time the article is saved (whatever is status is), the previous one needs to be a revision. That way, it’s simple to do, simple to handle, simple to explain to a non-geek user, etc. Quite like MediaWiki (and most other wiki) in fact.
Technically, it’s just: hook into the ArticleSave function of TXP, and copy the actual (before saving) SQL row to a new article-revision SQL table.
Then, we could have more complex scripts to purge old revision, meeting the criteria we want, that could be as complex as we need them to be.
Offline
Re: [request] Page revisions/history
md_versions looks promising.
Offline