Problem/Motivation
Just as node/%node is a parent item for view, edit, delete so should node/%node/revisions/% be the parent for view, revert, delete.
Currently, you need to revert from the revision list page, where you only have the date to know whether it's the revision that you actually want to switch to.
Proposed resolution
Show revision actions on view revision page.
Remaining tasks
1. Get UX opinion.
2. Ifusing actions, rename issue title.
Contributor tasks needed
| Task |
Novice task? |
Contributor instructions |
Complete? |
| Reroll the patch if it no longer applies. |
|
Instructions |
|
| Update the issue summary |
|
Instructions |
|
| Update the issue summary noting if allowed during the beta |
|
Instructions |
|
User interface changes
Adds a revert, and delete button to the current revision.
API changes
Beta phase evaluation
Comments
Comment #1
boombatower commentedComment #2
boombatower commentedNot sure if delete should be included since it isn't for node/%node/delete.
Comment #3
brianV commentedRe-rolled against current head. I left delete included, although I agree that it's removal should be considered for consistency.
Comment #4
brianV commentedre-rolled with bugfix.
Comment #5
brianV commentedHere's another option for consideration - rather than making the revisions actions local tasks, I put them as local actions.
Comment #7
brianV commented#4: 1108888-node-revisions-rev3.patch queued for re-testing.
Comment #8
brianV commented#5: 1108888-node-revisions-rev4.patch queued for re-testing.
Comment #10
brianV commented#4: 1108888-node-revisions-rev3.patch queued for re-testing.
Comment #11
brianV commented#5: 1108888-node-revisions-rev4.patch queued for re-testing.
Comment #12
yesct commented#5: 1108888-node-revisions-rev4.patch queued for re-testing.
Comment #13
welly commentedPatch applies correctly.
Comment #14
welly commented#5: 1108888-node-revisions-rev4.patch queued for re-testing.
Comment #15
webchickHm, can someone take a screenshot of what this does? I can't quite parse it from the description, nor from reading the code.
Comment #16
petercook commentedChanged two cases of MENU_LOCAL_ACTION in patch to MENU_LOCAL_TASK
Shorter tab labels would be good with hover over for extra description.
Comment #18
rooby commentedHere are before and after shots:
Before:

After the patch in #4:

After the patch in #5:

After the patch in #16:

After seeing these images, a quick comparison of the patches in #4 & #16 indicates that #16 is a re-roll of #4.
Comment #19
mradcliffeReverting to needs work as the patch fails tests, and it may need a re-roll.
Thank you for the screenshots, rooby.
Comment #20
rooby commentedSo what is the desired appraoch, actions (#5) or tabs (#16)?
Seems to me that actions makes more sense, because the labels describe actions.
Comment #21
mrded commentedComment #22
mrded commentedTake a look new patch, it should works fine.
Comment #23
rbayliss commentedThe patch applies now, but I'm getting the following Exception after creating a node:
Commenting out the revert and delete hook_menu entries makes this go away, so it is breaking on building the local tasks. I'll leave at needs review for the moment we can get the testbot error log.
Comment #25
mrded commentedThis version should be better.
Comment #26
rbayliss commentedPatch applies, and the tabs look good. One problem is that when you go to node/{NID}/view or node/{NID}/revisions/{VID}/view, you get a page not found. I think there will need to be a way to deal with menu default local tasks in routes, but that problem is not introduced by this patch.
Comment #27
mrded commentedI've added description and made title more obvious.
Comment #29
rooby commentedWe still need to agree on the outcome of #20.
I feel actions are more logical.
Comment #30
mrded commentedI don't see a reason to show 'MENU_LOCAL_ACTION' without any 'MENU_LOCAL_TASK', and it looks strange.
What's why, I vote for 'MENU_LOCAL_TASK'.
Comment #31
rocketeerbkw commentedIt was mentioned in #2270717: There is no way to get back from viewing an old node revision that tasks and actions could be used in these ways:
Comment #32
yesct commentedIt's been a long time. unassigning so it is clear anyone can work on this.
it's a normal task, we should see if it can be done during the beta. adding the instructions for beta evaluation to the summary.
Comment #33
rooby commentedAgain, we still need a consensus on #20
My vote is for actions instead of tabs because deleting and reverting are actions.
Comment #34
lokapujyaAdd the actions. I think you can get back to the current revision by clicking the title.
Comment #35
lokapujyaComment #36
lokapujyaComment #37
lokapujyaComment #38
johnpitcairn commentedGetting back to the current revision by clicking the title may work, but that is likely to be rather non-obvious to the average user, isn't it? I'd advocate an obvious link for that...
Comment #39
Bojhan commentedNope, this violates our guidelines http://drupal.org/ui-standards
Comment #40
rooby commented@Bojhan:
Any chance of getting some more specifics on the parts of the guideline that this doesn't align with?
Do you mean that neither option (tabs or actions) are valid within the guideline?
Since the way this currently works is (IMO) not very user friendly I have to wonder a little why we have UI standards that don't allow making something more user friendly.