multilanguage i18 error: wrong include

Can you tell me what module weight you have for custom_breadcrumbs_taxonomy and i18ntaxonomy in your system table? I think the two modules should be compatible if custom_breadcrumbs_taxonomy has a greater weight.

You can adjust the relative weights of the custom breadcrumbs submodules at admin/settings/custom_breadcrumbs. Be sure that custom_breadcrumbs_taxonomy is lower down on the list than custom breadcrumbs (be sure to check the 'Adjust module weights' box before saving the configuration or the weight will not be adjusted). Unfortunately, the weight of i18ntaxonomy isn't currently part of the calculation when determining module weights, but depending on other submodules you have enabled, this might fix the problem for you anyway.

If it doesn't work after you try that, heck the weight of custom_breadcrumbs_taxonomy again, and if necessary, manually set it to be 6 or greater.

Let me know if this works. If so, I can commit a fix to 6.x-2.x-dev today.

@harrrrrrr has this been resolved? Did the suggestion in #3 work for you?

Ok. Closing for now since this issue seems to have gone stale. If you followup, be sure to check the latest code. Thanks.

Just had the same problem with the latest dev release.
The install hook needs to modify the custom_breadcrumbs_taxonomy module weight accordingly...

@bojanz, this is what I suspected and suggested in #3. I've just been waiting for someone who is able to test. So are you saying that you tried the suggestion in #3 and found that it fixed the problem? If not please present your solution as a patch so others can test it. Thanks.

Marked #505002: multilanguage i18 error as a duplicate (even though it came first), since it looks like there may be more progress on this issue.

I had to go into the system table and change the weight of custom_breadcrumbs_taxonomy to 100, since it not only needs to be higher than i18ntaxonomy, it also needs to be higher than page_manager (which is 99) in order for it to work in a panel.

Be sure that custom_breadcrumbs_taxonomy is lower down on the list than custom breadcrumbs (be sure to check the 'Adjust module weights' box before saving the configuration or the weight will not be adjusted)

By applying this tip, everything works now, all my taxonomy terms are correctly translated in breacrumbs. and no more errors.

PS: Custom Breadcrumbs for Taxonomy get weight of 100.

The latest version of custom breadcrumbs taxonomy (6.x-2.x-dev) automatically sets the weight to be greater than both page_manager and i18ntaxonomy. See the comment in #3 again (or the relevant quoted text in #11). As heyyo indicates, that should automatically set the weight to be greater than page manager.

Returning this to a support request because I can't find a bug here....

I was continuing to get the error too using the latest 6.x-2.x-dev (January). Uninstalled and re-installed. I finally tried changing the module weights on the bottom of the settings page "admin/settings/custom-breadcrumbs". It was unintuitive because it didn't include the i18n module in the list. It only lists the custom breadcrumbs modules I've enabled: the base and taxonomy modules. It's not entirely clear what it even does since you'd think that the base module would have to appear first no matter what. I put it at the top and it seems to be working now.

In a side note, when I activated the module, I believe it disabled my Panel override of taxonomy term pages. When I enable it again it's working fine. Odd.

Hello, I experienced this error too after installing rc1 release, - I'm using localised taxonomies - with panels to control their display.

So I disabled and re-enabled a few times, and I've noticed the same as nubeli, where my Panel's overrides are getting disabled whenever I change custom breadcrumbs module. I've then played around with the module weights as discussed above, and a couple of times when trying to use a lower weight I got this error on Panels, so there does seem to be some confusion going on with the overrides for this particular type of page:

-> Page manager module is unable to enable taxonomy/term/%term because some other module already has overridden with custom_breadcrumbs_taxonomy_term_page.

Now - panels overrides are working, and no errors cropping up, but it seems to have disabled all my normal node-type breadcrumbs, which are just showing "Home" - only taxonomy and (randomly) views pages are working with breadcrumbs at all.

I don't know a lot about module weights and what they should or shouldn't be, so I'm hoping someone else can draw some conclusions of some kind from this. My custom breadcrumbs modules currently look like this:

Custom Breadcrumbs - 0
Custom Breadcrumbs for Paths - 1
Custom Breadcrumbs for Panels - 2
Custom Breadcrumbs for Views - 3
Custom Breadcrumbs API - 4
Custom Breadcrumbs for Taxonomy - 100

Might try the dev version now, but I'm already on the rc1 release of 8th Jan which seems to already have this fix listed in the notes.

Ahh.... the disappearing breadcrumbs on other nodes was caused by me having this selected:

"Use the taxonomy hierarchy to set the breadcrumb trail for nodes and taxonomy pages"

My vocab isn't identical to the menu structure so it wasn't showing properly - All working now :)

The latest version of custom breadcrumbs taxonomy (6.x-2.x-dev) automatically sets the weight to be greater than both page_manager and i18ntaxonomy.

Not for new installs it doesn't... :)

Can you make the SQL update statements also fire from hook_install(), not only hook_update_X?

sub

Its currently firing from hook_enable()....It should already work for new installs. I was thinking that that would be more appropriate than hook_install().

Is there something I am missing? Still don't see the bug...

OK, sorry, I made the wrong assumption when I didn't see a hook in the .install file.

Now I actually tested. Your error is here:

Great. Thanks for catching this! Committed to 6.x-2.x-dev.

I just updated to 6.x-2.x-dev (using the update.php) and still get this error:

Fatal error: require_once() [function.require]: Failed opening required 'sites/all/modules/custom_breadcrumbs/custom_breadcrumbs_taxonomy/i18ntaxonomy.pages.inc' (include_path='.:') in /var/www/vhosts/bestsportdeals.be/httpdocs/includes/menu.inc on line 346

however when I manually lower the 'CB for taxonomy' weight below 'CB for views' then it does work. (note: it was already below the 'CB' module, now I manually dropped it to the lowest place)

yes, this is the correct solution. custom_breadcrumbs_taxonomy should have a heavier weight (lower on the list) than views. I'll have another look to see if it automatically adjusts to the proper weight upon enabling the module. From your description, it may not have. Can you describe, step-by-step, how you updated. For example, did you disable the custom breadcrumbs modules and re-enable after installing the new code?

[Edit: To clarify, I mean custom_breadcrumbs_taxonomy should have a heavier module weight than the views module (not custom_breadcrumbs_views). But modifying the relative weight of the custom breadcrumbs modules will automatically ensure that this occurs, regardless of the relative weights of the cb modules. So you should be able to return to your original configuration without the error returning - you just needed to adjust the module weights to trigger the process...]

no, I just copied the new module over the old and ran the update.php script (otherwise you lose all settings?)

You can disable the module and re-enable it without losing your settings (everything is cached). But when you do that, custom breadcrumbs can/should reset the weights of custom breadcrumb modules if needed. I am not sure if running the update.php script will accomplish the same...I'll have to look into it further. Thanks for the info.

[Edit: to clarify, disabling a module is different from uninstalling it. If you uninstall (any of) the custom breadcrumbs module(s), you will lose the custom breadcrumbs and the settings for that module. But you can disable it temporarily without losing anything.]

Note I'm not testing, I was just looking since I knew this issue already...

It seems you misnamed your hook_update_N functions.

The weight update is called custom_breadcrumbs_taxonomy_update_6000() . 6000 will only run when upgrading from 5.x to 6.x, never when upgrading from 6.x, because your Drupal will already have '6000' registered as weight.

If every update from 6x-1.x to 6.x-2.x-dev should update the weights, you must name the function custom_breadcrumbs_taxonomy_update_6200() at least.

Luckily you can rename your current custom_breadcrumbs_taxonomy_update_6200() to custom_breadcrumbs_taxonomy_update_6201() without causing nastiness. Users will only get warnings that a column cannot be added.

That update function was a first attempt at dealing with this issue. It was used before we realized that i18ntaxonomy was also overriding taxonomy/term/tid pages so it wouldn't help this problem, even if it worked. I no longer think hook_update is the right place to adjust the weights of these modules because the need to re-weight the modules isn't dependent on a particular version of drupal or custom breadcrumbs. It depends on what other modules have been installed, and what weight they have been assigned.

So the update function has been superseded by two mechanisms to react to modules like views, i18ntaxonomy, etc. First, hook_enable is implemented to reset the module weights everytime custom_breadcrumbs_taxonomy is enabled. Second, you can also trigger this same process by adjusting the weights manually on the custom breadcrumbs configuration page.

But even with these provisions this error will occur if you upgrade without first temporarily disabling the module and then re-enabling it. I guess this isn't a common practice in upgrading modules (mentioned briefly as an option in step 5 at http://drupal.org/node/672472). I would expect the same error would be triggered if modules like views or i18ntaxonomy are installed after custom breadcrumbs.

So I think I am still left looking for the best solution to the problem. Its an easy fix, once you realize the problem, and it can be easily handled from the custom breadcrumbs configuration screen, but I suspect it is more than a documentation problem. It would be great if these errors could be avoided altogether (but without indiscriminate database queries).