Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.The Revision tab node/x/revisions is shown if I click on node/x/track. Switching back and forth to published version removes/adds the tab :-)
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | workbench_moderation-hide-revision-tab-1780182-12.patch | 1.43 KB | mvc |
| |||
| #10 | 1780182-10.patch | 1.41 KB | EclipseGc |
| #1 | workbench_moderation-revisions-tab-not-always-hidden-1780182-2.patch | 2 KB | richard.thomas |
Comments
Comment #1
richard.thomas CreditAttribution: richard.thomas commentedI've run into the same issue with a tab I added, using drupal_get_form() as the page callback. It seems the code in workbench_moderation_menu_local_tasks_alter() is assuming the page argument order. I've simply changed the code to use menu_get_object() instead, it seems to handle all cases the previous code did, and I've tested it with my tab, the devel tab, and the statistics tab. I've attached a patch.
Comment #2
richard.thomas CreditAttribution: richard.thomas commentedComment #3
stevectorI think I'm following what's happening in this patch. Can you give me a clearer set of instructions on how to reproduce this bug?
Comment #4
richard.thomas CreditAttribution: richard.thomas commentedEnable moderation on a node type, then enable the core statistics module, go to a moderated node and you should now have a "Track" tab. Choose the track tab and the "Revisions" tab will reappear in the tab list, going back to the published version removes it from the local tasks again.
In my case I was seeing the issue on a custom tab I had added, but it will occur on any local action where the node is not the first page argument.
Comment #5
hass CreditAttribution: hass commentedComment #6
stevectorGot it, thanks. In the case of the stats case, I think the problem is in core and have filled an issue there: #1863260: Use the normal menu system approach for loading arguments on user/%user/track/navigation and node/%node/track
It's unlikely that'll get moved back to to 7.x any time soon. So I've gone ahead and committed this patch. Thanks guys! http://drupalcode.org/project/workbench_moderation.git/commitdiff/51b91d...
Richard, congrats on your first commit listed on your profile! http://drupal.org/user/1924680
Comment #8
cschults CreditAttribution: cschults commentedIf this patch got accepted, what version of Workbench Moderation will it be applied to? I'm experiencing the same thing for custom Panel pages where the path is /node/x/some-action, but I've installed the latest stable release. Thanks.
Comment #9
cschults CreditAttribution: cschults commentedGot around this issue by removing the permission "View content revisions" under "Node".
Comment #10
EclipseGc CreditAttribution: EclipseGc commentedBad form to reopen old issues, I know, but this one warrants it I think. The fix for this seems a little suboptimal, and as cschults points out, we still run into this issue with custom page_manager deployed pages to node/%node/*. In order to more directly squash this, I wrote an additional access callback that checks if the node type in question is moderated and if it is, it routes through the normal workbench_moderation access checks, and if it's not moderated, then it gives core it's normal shot at this. Appears to work as desired for me. Pretty simple. I suspect the hook_menu_local_task_alter() stuff is unnecessary, but I've not attempted to remove it yet.
Eclipse
Comment #12
mvcThe patch from EclipseGc seems safe but didn't work for me when viewing unpublished drafts of webforms while logged in as a user with permission to moderate that draft. Here's another possible solution; I didn't roll it together with that one but it should be possible to apply both. I have tested this with 7.x-1.4 and it should apply safely to the latest 7.x-1.x. I suspect it still applies to 7.x-3.x but I'm not ready to update to that version.