Summary:
In workflow-6.x-1.0-rc3, hook_menu_alter modifies a menu item which is does not exist until it has been created by the Trigger module.
Details:
The Trigger module calls hook_hook_info to know whether to create new tabs on the Triggers administration page. The Workflow hook_hook_info will not return any triggers until there is at least one workflow which has been assigned to a content type and has at least one transition defined. So, on a clean install of Workflow you get a warning because hook_menu_alter is modifying a menu item which has not been properly defined yet.
The patch I'm submitting simply checks within hook_menu_alter to see if 'admin/build/trigger/workflow' exists before modifying it.
The only unresolved issue with this is that you have to manually tell Drupal to rebuild the menu after you've created the first transition. Would it be practical to programatically rebuild the menu as soon as the first transition is created?
| Comment | File | Size | Author |
|---|---|---|---|
| workflow-awmckinley-menu_alter.patch | 656 bytes | awmckinley |
Comments
Comment #1
jvandyk commentedAwesome! Yes! This has bugged me for a while. Not the menu_alter() thing, which was simple, and thanks for that. But the latter problem. The problem was if you edited the workflow before a type was mapped, the query inside the workflow_hook_info() would fail and prevent the tabs from being built. Now in addition to giving you the helpful message that you either haven't assigned any transitions or mapped to any type, it actually rebuilds menus when you do map to a type. (It was already rebuilding when transitions were assigned. But you need both.)
Fix is in HEAD and will appear in RC4.
Comment #2
femrich commentedI'm experiencing exactly this problem. Do you recommend (for non-coders) installing the HEAD version now, or will RC4 come out soon and is it better to wait?
Comment #3
jvandyk commentedHere is how you can get an idea of that as a noncoder.
On the project page you can click on CVS messages to see what's been done recently. The 6.x-1.x-dev development snapshot on that page is a downloadable tarball of HEAD, so will include all the changes you see there. Compare that with the release notes for RC3 to see what's been added since RC3.
So right now, RC3 is out but it has the menu_alter() bug in it, but that has been fixed in the 6.x-1.x-dev snapshot, which will become the RC4 release. If you do choose to use a dev snapshot, be sure to keep track of the date you downloaded it, so you know where it is in terms of new features/bugfixes being added. You need to do this because a 6.x-1.x-dev snapshot from today may not be the same as a 6.x-1.x-dev snapshot from tomorrow.
Is RC4 coming out soon? I don't know; that depends on how much time I can carve out to work on workflow. :)
Comment #4
awmckinley commentedGood stuff! My idea for rebuilding the menu was going to be a lot more complicated - I like yours better.
We're going to be using Workflow on an issue tracking system we're working on. Thanks for the great work!
Comment #5
scottrigbyThe 6.x-1.x-dev version works great - thanks :)
Comment #6
Anonymous (not verified) commentedAutomatically closed -- issue fixed for two weeks with no activity.
Comment #7
arhak commentedsubscribe
Comment #8
kyle.vh commentedwhen I upgrade to the dev version (nov 13th)--as a solution to the missing arg 1 for trigger access error, i get this error during the update.php:
An error occurred. http://dev2.focus.server273.com/update.php?id=1&op=do
Fatal error: Call to undefined function _system_update_utf8() in /home/focus/www/dev2/sites/all/modules/workflow/workflow.install on line 170
And then:
"The update process was aborted prematurely while running update #2 in workflow.module."
Any thoughts?
Comment #9
jvandyk commentedPlease create a new issue; do not reopen a closed issue. In the new issue, describe what version of workflow you were upgrading from.