I have a multilingual site (English and Spanish) where English is the primary language, and Spanish nodes are prefixed with '/es'. Path custom breadcrumbs work for Language Neutral nodes, English nodes, but not for Spanish ones.

1) Create an English node at /content/somenode
2) Create a path breadcrumb to content/somenode and set it's language to No language or English - this works fine
3) Create a Spanish node at /es/content/somenode
4) Create a path breadcrumb to content/somenode, and set its language to Spanish - the breadcrumb isn't applied

(I'm actually trying to use this with aliases to language specific views)

I suspect the problem is to do with the language prefix in the path.


MGN’s picture

Status:Active» Postponed (maintainer needs more info)

Two questions for you:

1. In step 4, should the path breadcrumb be to es/content/somenode so that steps 3 and 4 parallels steps 1 and 2, switching language to Spanish?

2. Do you have any problems with node-type custom breadcrumbs to Spanish nodes ?

mrfelton’s picture

1) no I don't believe it should be. In step 3, I gave the node the alias /content/somenode - i18n takes the responsiblity for adding the prefix to it. For the cb, the language is sat on the cb object itself, so cb should be responsible for adding the prefix if necessary.

2) I haven't tried - will test in the morning.

mrfelton’s picture

Status:Postponed (maintainer needs more info)» Active

ok, on further inspection it seems that the breadcrumbs are applied to paths with prefix if you:

a) set that langage of the cb
b) include the prefix when you specify the path

I believe this behaviour is wrong, as the prefix is not actually part of the path but is something that is added to the path by the locale module, and is implied by the language. cb should work either one way or the other. That is to say that either you specify a path including the prefix (which I believe to be the wrong thing to do) OR you set the language using the select provided and the prefix is impled from that. The second approach makes a lot more sense since the prefix is subject to change. If the prefix is included in the path, all cb items would need updating upon changing the path prefix.

mrfelton’s picture

Title:path Custom breadcrumbs not applied to translated nodes (with a path prefix)» path Custom breadcrumbs not applied to langage prefixed aliases to Views pages
Status:Active» Needs review
new1.02 KB

A little more investigation... Where this is really a problem, is for Views pages, which, unlike nodes, can have no language (although they can be set to a language prefixed path but that's not quite the same thing. Anyway, what has been happening for me is that I have a language sensitive View (one that only displays nodes in the users current language or with no language preference), and I have language specific path aliases pointing to this view (eg. some/path => theview, and es/some/path => theview, ie/another/path => theview) and language specific content is displayed based on the way the view is accessed. Now, for the alias with no prefix, I could get a path specific breadcrumb working fine. However, for the other two aliases I couldn't.

I traced this to what I believe to be a problem in the views_pre_render implementation where $curpath = drupal_get_normal_path($_REQUEST['q']); was being used to determine if a cb should be applied or not. So we were querying the View to work out its path, including arguments etc. and then testing that path with _custom_breadcrumbs_paths_page_match($curpath, $viewpath);. Now, $curpath may or may not include a path prefix, but $viewpath never will - hence, when a path prefix was used to access the view, a cb was never being applied. The attached patch (included below for reference) seems to fix the problem and I'm now able to set up specific path cbs for aliases to Views with or without a language prefix.

--- custom_breadcrumbs_paths/custom_breadcrumbs_paths.module  21 May 2009 05:54:39 -0000
+++ custom_breadcrumbs_paths/custom_breadcrumbs_paths.module  26 May 2009 09:06:44 -0000
@@ -76,7 +76,7 @@ function custom_breadcrumbs_paths_nodeap
//       object type.
function custom_breadcrumbs_paths_views_pre_render(&$view) {
   // Don't really do anything with the view. This is just a pretense to insert a breadcrumb.
-  $curpath = drupal_get_normal_path($_REQUEST['q']);
+  $curpath = drupal_get_normal_path($_GET['q']);
   // Check to see if the view path matches the current path.
   $viewpage = FALSE;
   foreach ($view->display as $display) {

However, even with this, I still believe that the behaviour of CB is wrong and that the path prefix should not be required to specified in the path itself, but should instead be implied from the language selection of the cb object - but that is a substantially more complicated issue, and with this patch at least, I am able to use cb to create my breadcrumbs at least.

MGN’s picture

Status:Needs review» Postponed (maintainer needs more info)

What about something like this (in hook_nodeapi and hook_views_pre_render)

while ($breadcrumb = array_pop($breadcrumbs)) {
$page_match = FALSE;
      if (
$matchpath) {
        if (isset(
$breadcrumb->language)) {
$path = $breadcrumb->language .'/'. $breadcrumb->specific_path;       
$page_match = _custom_breadcrumbs_paths_page_match($_REQUEST['q'], $path);
        if (!
$page_match) {
$page_match = _custom_breadcrumbs_paths_page_match($_REQUEST['q'], $breadcrumb->specific_path);
      if ((!
$matchpath) || ($matchpath && $page_match)) {

I have tried this (only with locale, not i18n), and it seems to work as expected. I set up several breadcrumbs for a a view (two with different languages, one with all), and the breadcrumb is selected according to the properly prefixed path.

Sorry I can't provide a proper patch right now since I am also in the middle of a number of other changes. Let me know if this works for you.

MGN’s picture

The code in #5 only works with the wildcard matching section of the code. We also need something like this when wildcard matching is not being used.

if ($viewpage) {
// Check for breadcrumb at this path.
global $language;
$matchpath = variable_get('custom_breadcrumbs_paths_allow_wildcards', FALSE);
    if (
$matchpath) {
// Get all path breadcrumbs (in this language).
$param = array(); 
    else {
// Check for path prefix and strip it out if its found.
$prefix = $language->language .'/';
$path = str_replace($prefix, '', $_REQUEST['q']);
$param = array('specific_path' => $path);
$breadcrumbs = custom_breadcrumbs_load_breadcrumbs('custom_breadcrumbs_paths', $param);
    while (
$breadcrumb = array_pop($breadcrumbs)) {

See any problems with this? I am going to try to work something like this into my next commit for further testing.

MGN’s picture

Status:Postponed (maintainer needs more info)» Fixed

I just committed a series of changes which should fix this problem. Its in cvs now, and should be in the next nightly snapshot. Please test it out and reopen if the problem persists.

mrfelton’s picture

Seems to be working well - thanks.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

liquidcms’s picture

Status:Closed (fixed)» Active

i think this is somewhat related so will simply re-open this issue - if it isn't please let me know and i'll move to new ticket.

the path matching code function has this:

function _custom_breadcrumbs_paths_page_match($breadcrumb) {
  $page_match = FALSE;
  if (isset($_REQUEST['q'])) {
    if (isset($breadcrumb->language) && $breadcrumb->language != '') {
      // Check for a match on the prefixed path.
      $path = $breadcrumb->language . '/' . $breadcrumb->specific_path;
      $page_match = _custom_breadcrumbs_match_path($_REQUEST['q'], $path);

which is wrong.

$breadcrumb->language is using the language identifier, for example "en" but it should be using the $language->prefix (which is typically also "en", but in our case is set to "eng") since this is what is actually appended to the path.

not sure right place to patch this.. give me a couple minutes and i'll submit patch.

liquidcms’s picture

new2.12 KB

not sure the best way to fix this, but...

MGN’s picture

Status:Active» Needs review

Marking as needs review since there is a patch now...