Project_issue module uses 'category' field in its own table, but stores it in the common node array, which conflicts with category module which also stores its 'category' field in node array. They have completely different meaning of these fields. Project_issue module writes string, category module writes array to node['category'] entry. Both modules get confused when collided. It happens for example when trying to enter new bug request. Bug category drop-down list entry never gets written to the database.
I fixed this issue in my sandbox completely by renaming array element node['category'] which project_issue module uses everywhere in its code to node['issue_category'], leaving category module code unchanged. I think this is good for a quick patch, but in general, a better naming scheme for shared data is needed. I believe that each module should store its own data in the node array using only sub-array with same name as the module. This will remove any chance of ambiguity and conflict between modules.
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | project_issue.zip_.patch | 42.33 KB | heimstein |
Comments
Comment #1
dwwthanks for the detailed and clear bug report! this is clearly another source of the pain being discussed in http://drupal.org/node/90188 (though this seems to be a totally separate problem from what's being discussed there). i agree that we need namespaces in the $node object to avoid conflicts like this. i found a similar collision bug with the book.module and a $node value called "pid". :( see http://drupal.org/node/98278 about that...
anyway, until a more general solution is worked out, hopefully with core support, i'd be willing to commit a patch that changed
$node->categoryto$node->pi_categoryeverywhere in the project_issue codebase. that said, i don't personally use category module on any sites that run project*, so i have no personal need for this to work. therefore, someone else will have to do the work if they want to see it done. sounds like you've got this mostly working in your locally modified copy already, so carefully rolling a real patch for just this change shouldn't be too much work.thanks,
-derek
Comment #2
liquidcms commentedlol.. good timing Derek.. i just figured out that this has been the issue i am having.. both use $node->category.
I will likely try to create the patch that you suggest. Should have something today.
Comment #3
bdragon commentedThanks for the heads up.
As luck would have it, I am currently in the middle of doing a pretty comprehensive rewrite of category's node representation at the moment.
I am moving to a category_ and container_ prefix for everything, and changing the category field would be pretty easy at this point, as I'm going to have to run through category's code base updating stuff anyway.
I just changed it to category_categories. It will take a while to get this stable and backported, unfortunately, as I am currently working on an experimental branch. I may backport this rename specifically if it turns out this is a widespread issue.
Thanks,
Brandon Bergren, (Interim) Category Maintainer
Comment #4
liquidcms commentedi did get part way through the renaming of category to pi_Category but it wasn't as easy as i hoped... and i had to get work done on some other things first.. i hope to get back to it this weekend... however... what i really need is a issue tracker for current project... so 2 ways to go for this.
my plan was to add this to my company site (which uses cat module).. but if hack to project_issue module takes more than about 1/2 hour or so.. i will simply set up a sub-domain off my site with another drupal install and use the taxonomy module there.
but will take another look this weekend at getting pi module to work with cat
Comment #5
heimstein commentedis there any progress on that? i use cat and pi, which lead to the conflict described above. i looked to pi's CSV but it's still $node->category and not $node->pi_category in the code. i am also using d 5.1 not 4.7. as it seems, newest pi-files in CSV are still for 4.7, aren't they?
Comment #6
dww@heimstein:
a) no, i haven't had any time to work on this, so pi is still using "category".
b) HEAD of project* is for 5.x (see http://drupal.org/node/75232/release for example, and you'll see that http://drupal.org/node/96566 (the 5.x-0.x-dev release) is pointing to HEAD.
c) see also http://drupal.org/node/142208 for another example of a similar bug. :(
Comment #7
heimstein commentedso now one is on that, i was on my own - and without time to wait.
created a patched pi-module (version DRUPAL-5--0-2-BETA)
patching tooks only few minutes, seems to work, but side-effects, stability and completeness are unknown.
sorry, i was not able to create apropriate patch files, so i put everythin in a zip an fake-renamed it to bypass the extension-check here. hopefully one of you will merge this (or any) fix somehow into the branch
Comment #8
dwwwhen you have some time, please post a real patch (http://drupal.org/patch). it'd probably take me longer to use this zip file than to just re-do the changes myself. :( however, since this isn't a fire priority for me or drupal.org, i'm not inclined to spend too much time on it. if there was a patch i could use, i would, but this is just an invitation for me to spend a bunch of my time on a bug that i don't care that much about.
Comment #9
dwwi'd like to just fix all of this, all at once, at http://drupal.org/node/98278