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.
I get the following errors:
# notice: Object of class stdClass could not be converted to int in modules\forum\forum.module on line 248.
# notice: Object of class stdClass could not be converted to int in modules\forum\forum.module on line 253.
# notice: Object of class stdClass could not be converted to int in includes\database.inc on line 210.
This is caused by taking the $node->taxonomy elements as term_ids when they really are term objects.
Comment | File | Size | Author |
---|---|---|---|
#13 | forum-node_save-tid-7.x-dev.patch | 1.79 KB | criznach |
#11 | forum-node_save-tid-7.x-dev.patch | 1.51 KB | criznach |
#8 | forum-node_save-tid.patch | 1.58 KB | criznach |
#1 | 207024-forum-taxonomy-v2.patch | 701 bytes | joshmiller |
forum.module_nodeapi_presave.patch | 662 bytes | salvis | |
Comments
Comment #1
joshmillerThe title wasn't informative of what is being accomplished here.
The use case: Errors when batch publishing a forum topic
The problem: Forum doesn't handle taxonomy term objects properly.
I've looked at the three lines of code and they accomplish a simple type change from object to int very nicely. Re-rolled patch against D7.
Comment #2
catchIs this code not tested in core? Does it sometimes get an int and sometimes an object? Marking to CNW since either one of those questions needs an answer before we commit this I think.
Comment #3
eojthebraveJust FYI, I've been unable to reproduce this problem.
Steps taken to try and reproduce the problem.
1. Enable forum module
2. Create a new forum for testing, admin/build/forum
3. Create a couple of new forum topics, mark them as un-published.
4. Navigate to admin/content/node, select the un-published forum topics and then publish them.
This was done on a clean install of Drupal HEAD.
Looking at the code I'm not sure that this is relevant for Drupal 7.
I was also unable to re-produce the error in Drupal 6.10
Can anyone confirm that this is still a problem? Can anyone provide detailed instructions as to how someone could reproduce the problem.
Comment #4
catchComment #5
salvisThe terms in $node->taxonomy are usually objects. However, when implementing hook_node_access_records() I've found out the hard way, that $node->taxonomy can contain elements of one of three types (in D6):
The first case is the normal one. The current code only works in the third case (the variable name
$term_id
is a give-away), which means it's not working:The "errors" that I mentioned in the OP are actually E_NOTICEs...
... from the in_array() call, and $node->tid is not set, because the condition is false. I don't know whether the failure to set $node->tid has any nasty consequences later on, but it's clearly a bug.
You need to have the cvs version of Drupal to see notices. Or you can set a breakpoint on line 254 and look at what you get for $term_id. Or you can insert
if (is_object($term_id)) drupal_set_message('BUG', 'error');
above the in_array() call.
Note that this issue was posted in January 2008. I don't know whether it applies to D7 and I'm not going to find out. I do know that it applies to D6.
Comment #6
cburschkaTo find out how $node->taxonomy is handled in Drupal 7, the best reference is taxonomy's own saving function.
As we can see, taxonomy itself codes for the possibility of each element of the
$node->taxonomy
array being either an object, an array of tids, or a tid. When loading node objects, taxonomy generates $node->taxonomy as an array of objects. (Note that$node->taxonomy['tags']
is a special array of[ int vid => string term-names ]
for freetagging, which is processed and removed separately.)Comment #7
cburschkaIt stands to reason that forum_node_presave will need to code for all of these cases. Unless we can show that some of these cases will never occur in the data that forum_node_presave is passed.
Comment #8
criznach CreditAttribution: criznach commentedHere's a patch for 6.13 that should handle the 3 cases above. I've only found a test case for the first scenario (array of objects keyed by tid), so I'll need some help reviewing it for the other cases. In our case, it solved issues with the scheduler module. I'll try to get a patch for 7.x-dev as well.
Comment #10
aharown07 CreditAttribution: aharown07 commentedTested the 6.x version. Corrects the problem I was seeing... custom content types w/forum taxonomy now save properly when Scheduler publishes them (and appear in the forums).
Comment #11
criznach CreditAttribution: criznach commentedOk, here's a patch for 7.x-dev. To test this using only core modules, do this....
Enable Trigger and Forum core modules.
Assign the "Save post" action to the "After saving a new comment" trigger.
Create a forum container.
Create a forum inside that container.
Create a post in the forum.
Reply to the forum post with a comment.
Now try to view your post. It will be gone from the forum because it's record in the forum table has been deleted.
Again, I can only come up with a test case for the first scenario in the code. I can't think of situations where $node->taxonomy is a single term object, or single tid, but apparently they exist.
Comment #13
criznach CreditAttribution: criznach commentedMy bad... This should pass all tests.
Comment #14
salvis@criznach: I found that during [Rebuild permissions] the elements of $node->taxonomy are of the tid=>term type. During node creation they're vid=>tid for single-select taxonomies and vid=>array(tid=>tid) for multi-select taxonomies (D6).
Comment #15
criznach CreditAttribution: criznach commentedI think one key difference is that one format comes from the form api, and another comes from db_fetch_object.