Over the past few days, completely unrelated to the taxonomy module, I have been trying to eliminate a nasty and elusive bug in a contributed module. In doing so -- for the first time in an age -- I resorted to tracing all PHP errors, warnings and notices into a log file. After accumulating trace messages for several hours on a production website, much to my surprise I learned that there were periodic entries related to the file taxonomy.pages.inc. The repeated messages read as follows:
E_STRICT: Creating default object from empty value in `modules/taxonomy/taxonomy.pages.inc':34
$current->tid = $tids[0];
In reviewing the code for taxonomy.pages.inc, it appears that somehow the query of line 20 is returning zero resulting terms and hence $tids[0] and $names[0] remain unset. I am unsure how in that event the code then enters the if block 'if ($names)' around line 27. [Perhaps the test should be 'if (!empty($names))'?]
I did not log any of the parameters in the calls to taxonomy_term_page(). Hence, I cannot recreate the condition(s) under which this log message is thrown. However, in looking at other log files, I am wondering if somehow a tid value of zero is being passed in.
For the moment, I have resolved this issue on my local copy of taxonomy.pages.inc by enclosing the entire breadcrumb creation code around line 34 in an 'if (isset($tids[0]))' block. Perhaps better programmers might have a better solution? This edge case probably needs to be addressed in core as well.
Let me know if you have any questions. Cheers!
Comment | File | Size | Author |
---|---|---|---|
#10 | taxonomy.pages_.inc_.patch | 708 bytes | petyovsky |
#8 | taxonomy.pages_.inc_.patch | 526 bytes | petyovsky |
#3 | taxanomy.pages_.inc_.patch | 583 bytes | RStrydom |
Comments
Comment #1
Lars Toomre CreditAttribution: Lars Toomre commentedWhoops... I meant to say enclosed in 'if (!empty($tids[0]))' block. The isset() condition was falling through the condition and the NOTICE E_STRICT was still thrown.
Comment #2
TimmyT CreditAttribution: TimmyT commentedfollow this post: http://drupal.org/node/1724096
Comment #3
RStrydom CreditAttribution: RStrydom commentedI had the same problem when I upgraded to php 5.4
The Fix on https://drupal.org/node/1724096 worked for me.
I have rolled it into a patch
Comment #4
zionduc CreditAttribution: zionduc commentedThank you for the patch file!
I'v tried it with drupal 6.28, and this patch fixes the problem for me.
Comment #5
rbosscher CreditAttribution: rbosscher commentedI've tried it with drupal 6.30, and also this patch fixes the problem.
Comment #6
riteshsarraf CreditAttribution: riteshsarraf commented3 years and no release. Also no comment whether it will have a release. As much as I hate to hand modify source files, I guess I don't have a choice here.
Comment #8
petyovsky CreditAttribution: petyovsky commentedHi.
After upgrading to newest PHP (v5.5) a found a lot of same error messages:
Creating default object from empty value in `modules/taxonomy/taxonomy.pages.inc':34
everytime when someone filter content of nodes by taxonomy module.
I tried locate where is a problem and prepared some patch by the D7's taxonomy module.
Affected file is:
modules/taxonomy/taxonomy.pages.inc.
Please maintainer apply this patch to the future releases of D6. Its a nasty bug. :-)
Thanks,
Peter
Comment #9
VM CreditAttribution: VM commentedThis would need to be rolled against -dev.
The patch as it currently stands fails testing.
also of note: from https://www.drupal.org/requirements
Considering the sun is setting on D6, I'm not sure how much work would go into testing D6 on newer versions of PHP.
Comment #10
petyovsky CreditAttribution: petyovsky commentedHi.
Ok no problem. I prepared new patch (but have absolutely same content) against 6.x-dev.
Please see attachments.
I know that sun setting down on the D6, but there is absolutely no reason why don't accept patch that fix
someone PHP bad programmers practice.
Please read and consider applying of this patch again.
Thanks,
Peter.
Comment #11
jwilson3#10 RTBC. Thank you @petyovsky.
Comment #14
JamesK CreditAttribution: JamesK commentedLooks good, thanks @petyovsky
Comment #15
joachim CreditAttribution: joachim commentedWorks for me too.
Tagging as Quick fix as this may help get attention from a core committer.
Comment #16
steinmb CreditAttribution: steinmb as a volunteer commentedTested on 5.5.23.
RTBC from me too. This should also be safe on 5.1.x and 5.2.x -versions of PHP.
Comment #17
MichelleTagging so it shows up in the list of PHP upgrade issues.
Comment #18
AnybodyHas this patch ever been applied? It should be ...
Comment #19
Michelle@Anybody: If you mean committed, no. It's still at RTBC which means the community thinks it is ready but it still needs a core committer to look at it and commit. Given that 6.x is EOL soon, I doubt it will ever happen.
Comment #21
izmeez CreditAttribution: izmeez commentedThe patch in #10 still applies to D6.46 without problems but does not appear to be needed with php 7.2 but may be needed for backward compatibility to earlier versions of php 5.4+ and since it was RTBC I am changing it back to that but wonder if it should be Closed as fixed.
Comment #22
izmeez CreditAttribution: izmeez commentedThe patch in #10 applies without difficulty to Drupal 6.46 LTS and the patch was previously marked as RTBC.
Comment #23
dsnopekThe patch here looks good! However, we fixed this in a slightly different way in the D6LTS fork:
https://github.com/d6lts/drupal/commit/a3dcc334ccf68b5de682cc9bfa9cb5aa2...
Comment #24
izmeez CreditAttribution: izmeez commentedThat's great, looks better. Thank you.