I wasn't totally sure what happened but when I disabled the taxonomy module the menutrails settings screen gives a WSOD. This goes away when taxonomy is reinstalled. This happened under the following conditions:
- taxonomy was initially installed, with one vocab present
- menutrails was installed and working (using categories)
- taxonomy was disabled
- menutrails settings screen is blank
I assume there is some check for either a dependence on the taxonomy module, or this module checks for the presence of a vocab, or assumes that if settings are already present (for menutrails) that it is safe to make other assumptions :)
Hope this helps in some way.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | menutrails.159705.patch | 2.71 KB | sutharsan |
| #8 | menutrails-DRUPAL-6--1.taxonomy.patch | 1.09 KB | sun |
| #6 | menutrails.taxonomy.patch | 2.77 KB | sutharsan |
Comments
Comment #1
gregglesLooking at the code it looks like there are many many calls to taxonomy functions.
My guess is that adding the following to the menutrails.info would fix it:
dependencies = taxonomyOtherwise it would take a little more work to wrap all those calls in module_exists('taxonomy') to prevent the WSOD.
Comment #2
joshk commentedI will address this dependency in the next bugfix release. Good catch.
Comment #3
niklp commentedCool... I'm wondering though - there is a use case for menu_trails *without* taxonomy enabled, i.e. if you're only using trails by node type (e.g. a site built completely on CCK/Views with no other categorisation).
Having a dependence on taxonomy in the module by default could be considered bloating in that case, potentially? Just throwing the idea in the pot...
Comment #4
joshk commentedAgreed. The dependency can and should be worked around. Node-type categories alone are useful, although for most of my own use-cases, taxonomy does come into play, so I don't think of it as bloat.
However, that does raise the interesting point that the system for determining node-to-menu matches could really be an API, with various .inc files adding their own additions (e.g. it would be great to tie this to views). That's probably a little more advanced than I can get in the short-term, but it's definitely something I've thought about.
Comment #5
niklp commentedYeah, it's only bloat if you're using node-types alone, but I wouldn't want to have to enable taxonomy purely to use the module (I think we're in agreement there...?)
It would be *awesome* if we could get this working with views, it would be cool for so many sites... :)
Comment #6
sutharsan commentedThe attached patch makes menutrails work without taxonomy module.
Comment #7
sutharsan commentedChanged title appropriately
Comment #8
sunA partial fix for this was committed for 6.x already.
I've committed the missing parts of the patch in #6 to 6.x now.
Please note that only major bug fixes will land in 5.x. Changing version and marking as fixed for now. Feel free to re-open this issue if you think this patch is required for 5.x.
Comment #9
sutharsan commentedThanks for fixing this in 6.x. however I still believe this should also be solved in 5.x too. If not I need to keep on patching the module on my client's site (which has no taxonomy enabled) to get it working.
I've re-rolled the patch for 5.x-1.x-dev.
Comment #10
sunThanks! Committed to 5.x.
A new development snapshot will be available within the next 12 hours. This improvement will be available in the next official release.
Comment #12
davidneedhamThis bug is still a problem. I have a new drupal install with a new download of this module and I still must have taxonomy added otherwise I get a WSOD. Apparently something got messed up along the way.
Comment #13
davidneedhamHm, not sure which is a duplicate since this came first, but I just found this more recent version of this problem: http://drupal.org/node/564010
Reclosing.