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.Overview:
In project_issue_form(), array_merge() is used on an array with numeric keys corresponding to the project node id's. array_merge() is renumbering the keys, causing the project nid's to be lost and the form to malfunction.
Background:
The author of this issue is using drupal cvs along with project cvs. Technically they aren't intended to work together, but this issue report is a fundamental code bug, so it shouldn't depend on the verions. Note however that the author has hacked project.module not not use the taxonomy system. This helps the project module work better with drupal cvs (4.7b4+). This hack was done by changing all occurances of "module_exist('taxonomy')" to "module_exist('taxonomyXXX')". Note that this might affect the results returned by project_projects_select_options(), which is one of the functions in project_issue_form()
Details:
issue.inc reads:
function project_issue_form(&$node, &$param) {
global $user;
$default_state = variable_get('project_issue_default_state', 1);
// Set form parameters so we can accept file uploads.
$form['#attributes'] = array('enctype' => 'multipart/form-data');
// Fetch a list of all projects to make swapping simpler
$projects = array_merge(array(t('<none>')), project_projects_select_options());
...
The line
$projects = array_merge(array(t('<none>')), project_projects_select_options());
does not work because the array returned by project_projects_select_options() has numeric keys corresponding to the project nid's. The array_merge then causes the keys to be renumbered, and they lose their nid's. In the second step of the wizard, the submission form then tries to node_load() the project using $pid=$_POST['edit']['pid'] as the node id, which fails because the array was renumbered.
A simple patch to this issue is to change the line with the array_merge to:
$projects = project_projects_select_options();
This causes the "none" option, which isn't really needed anyway, to disappear from the dropdown list, and the form then works.
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | project_quick_navigate_form.patch | 774 bytes | marcp |
Comments
Comment #1
pfaocleI am having a similiar problem, but the change mentioned above doesn't fix it. A quick debug shows that nothing is returned from project_projects_select_options(), at least on my test site. The problem seems to be down to:
AND h.parent = 0in the SQL query: remove that, and the project select options are returned and the follow up form works a treat.
I guess this could possibly be related? Taking another look now, on a clean install of beta 5 and HEAD project module.
Comment #2
pulsifer CreditAttribution: pulsifer commentedHello Paul,
That problem somehow relates to the project module's use of the taxonomy. It seems to assume that the "Project" keyword would be a root key (parent = 0), but it is not when used with Drupal v4.7. The are some other issues with the project category displays. The easiest fix I found was to disable project's use of the taxonomy module (see above about replacing 'taxomony' with 'taxonomyXXX').
I made at least one other fix to get Drupal HEAD and Project HEAD working together. It has to do with Submit and Preview not being accepted in function project_comment_page().
If you contact me via http://drupal.org/user/44749/contact and include your email address, I will email you all of my changes. In a few days I may be able to post a more complete writeup.
Allen
Comment #3
pulsifer CreditAttribution: pulsifer commented> It seems to assume that the "Project" keyword would be a root key (parent = 0), but it is not when used with Drupal v4.7.
That should say: "It seems to assume that the categories under the "Project" taxonomy would be root keys..."
Disabling Project's use of taxonomy (and removing the Project taxonomy) also made the Project stuff disappear from advanced search, which I thought was a good thing since the issues can be better searched at the issue search page. (I'm not sure what would happen if you searched them from the advanced search page, i.e., if that would work as expected or if it would be misleading for users.)
Comment #4
pfaocleThanks, Allen. You can go ahead and send me your amendments to paul (at) leafish.co.uk.
Please note that the project module is currently holding back (1) the drupal.org upgrade, and consequently (2) the 4.7 release! I'm sure the project maintainers and others would appreciate your ideas/fixes/changes on this project/issue to be posted here.
(Marking critical)
Comment #5
pulsifer CreditAttribution: pulsifer commentedIf the goal is just to get Drupal 4.7 and Projects working together, there are a couple of small hacks that will do the trick. You can see them working together at http://openofficetechnology.com.
The hacks don't address the underlying issues though, which is primarily changes in the Forms API. I do have some thoughts and comments, but need to get the that website launched before I can follow up.
BTW, original issue I reported (array_merge renumbering keys) is different than the interaction problems with the taxonomy module. I believe the array_merge bug will also affect people using Projects in Drupal 4.6 without the Taxonomy module. It might be more clear to change the title of this issue back and start a new issue for the project_projects_select_options() problem.
Comment #6
pfaocleDone: http://drupal.org/node/52262
Comment #7
hunmonk CreditAttribution: hunmonk commenteda better solution is: $projects = array(t('')) + project_projects_select_options();
this joins the arrays while preserving the numeric keys. fixed in HEAD.
i checked 4.6, and it uses a different logic to build the dropdown, so this isn't a problem there.
Comment #8
(not verified) CreditAttribution: commentedComment #9
marcp CreditAttribution: marcp commentedStrange - seems like this bug was fixed eons ago, but it's still there in HEAD. Looking back, I can't see where it was ever fixed.
If this is true (and I wouldn't be surprised if my lack of CVS chops say that it isn't), then this probably means that the project_navigate_quick_form() should just plain go away.
Comment #10
marcp CreditAttribution: marcp commentedFound that the only place that this bug ever exists any more is on the second line of project_quick_navigate_form() in project.module.
Looks like it's done properly in the project_release module and a few times in project_issue.
Still, since this is here, I think the quick navigate form should probably bite the dust in favor of some easily created views and/or jump code.
Comment #11
marcp CreditAttribution: marcp commentedMoved it out of the critical zone.
Comment #12
dww#383518: Project navigation (drop-down select) marked duplicate.
Not sure how to make this code into a view + "jump code". Suggestions welcome, though I'd rather just fix the bug and move on. ;)
Comment #13
marcp CreditAttribution: marcp commentedHere's the patch to fix it and move on.
Comment #14
dwwHurray!!! I finally figured out WHY I was never seeing this bug on my test site, e.g. when replying to #383518. I'm using the drupal.org testing install profile, which sets up the project taxonomy with 2 tiers of terms, just like on d.o. Therefore, my drop-down was actually a nested array, organized by project type. So, the array_merge was collapsing the keys on the outer arrays, but those keys are totally ignored, anyway. This bug only appears on sites that don't have taxonomy enabled or don't have the project vocabulary configured. Now that I can reliably reproduce the bug, I can safely commit the fix, since I've verified a) it actually fixes a bug, and b) it doesn't break the other cases. Phew! Committed to HEAD. Thanks! ;)
Comment #15
dwwOh, and re:
"Strange - seems like this bug was fixed eons ago, but it's still there in HEAD"
Yeah, it just remained broken in project_quick_navigate_form(), and probably no one noticed due to the case I explained above -- if you have a project taxonomy at all, the bug is hidden...