Sometimes, it looks like $object->book["p$second_child"] is a string instead of an integer. This means that sometimes it fails in picking up when it equals 0. I encounter it when I do token_replace on a node body during preparations for a drupal_execute() call.
The attached patch reduces a === to ==, which lets the comparison evaluate properly. Was there some other reason why it was === before?
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | screenshot_044.png | 83.82 KB | dave reid |
| #4 | 457916-book-path-empty-D6.patch | 853 bytes | dave reid |
| bookpathalias_pid_is_string.patch | 794 bytes | deviantintegral |
Comments
Comment #1
deviantintegral commentedAnyone else ever run into this? I'm still needing to apply this patch for things to work properly with the Skeleton module.
Comment #2
gregglesI think there are times when it can evaluate to "false" which then evaulates to being "==" to 0. But of course I don't remember those and we don't have tests. Does this affect 6.x-1.x as well?
Comment #3
deviantintegral commentedI'm actually applying this patch to a 6.x-1.2 installation... I think I misclicked and meant the 1.x branch for this issue. It's definitely returning "0" and not FALSE, but perhaps this really is a bug somewhere else and it should always be an integer.
Comment #4
dave reidI can confirm this. I created a book page and used Devel module's 'Load' tab on the node to inspect what's in $node->book. All the p[num] values are strings.
Re-rolled the patch to remove the offset.
Comment #5
deviantintegral commentedYay - I'm doing some crazy things with the Skeleton module, so I was worried that I was doing something breaking the book hierarchy.
I wonder if it's a bug in core and that those values should always be integers. But the patch certainly provides a band-aid fix.
Comment #6
dave reidCommitted #4 to all three CVS branches.
http://drupal.org/cvs?commit=330254
http://drupal.org/cvs?commit=330256
http://drupal.org/cvs?commit=330258