Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I found this bug when using the core forum module with node form rearrange.
Core's hook_nodeapi() implementations, that deal with taxonomy, always check for terms in $node->taxonomy, which is the array of terms that is normally saved to the node object by the taxonomy module. Node form rearrange uses its own properties, like $node->taxonomy_field_4.
In the case of the forum module, it finds no terms associated with the node (in $node->taxonomy), so it never saves anything in the forum table in the db. All forum posts, will therefore never show up. The forums will show the correct number of posts, but when you are actually inside the forum, it is empty.
There could be other consequences in other core (or even contrib) modules by not using the $node->taxonomy convention.
Comments
Comment #1
chiddicks commentedYes, there definitely are ramifications to not using the $node->taxonomy convention, since other modules rely on it being there. However, this module's reason for being is to break apart the taxonomy fieldset into individual fields and moving them around in the node form, which necessitates this break from convention. If you find another way, I would be delighted to know about it.
Comment #2
dman commentedRe-opening, as you said you'd like to hear suggestions.
I've tried this:
- Don't mess with the form structure during form_alter
- Instead use hook_form_alter to insert a #pre_render callback instruction.
- Let all other modules keep doing what they want, according to normal $node->taxonomy structure expectations.
- The #pre_render function then shuffles the form around just before it gets rendered.
Works so far for me. All I wanted to do was a small modification to some taxonomy selects, but I found I couldn't insert my action between the point where they were added to the form and when node_form_rearrange shifted them away.
As before, It still leaves the data in the node_form_rearrange custom fields during nodeapi('presave') when the submit data is first being processed. That's not hurting me yet, but modules that try to process the taxonomy data at presave may not see it where expected. An edge case I think.
Patch attached
Comment #3
dman commentedThis approach is working well for me.
I also wish to export the weights - using CCK features to save the node_extra_weights field. However, using numeric vids isn't safe during deployment, so I'd rather have those elements handled by (d7-style) 'machine_names'.
This patch (a small update to the above one) uses human-readable ids when creating and re-arranging the form, and produces a configuration array that can be exported safely with features.
Basically, it stops using 'taxonomy_field_17' and uses an id like 'taxonomy_field_subjects' instead.
This belongs in its own feature request/patch, but I can only feed back improvements on code that I'm actively working on. And the previous patch #2 was something that made it possible for me to move forward.
Comment #4
dman commentedCleaner patch, #3 had some cruft from the packaging script