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.
Comment | File | Size | Author |
---|---|---|---|
#11 | fix_language_prefix.patch | 2.12 KB | liquidcms |
#4 | 461194_cb_views_language_prefix.patch | 1.02 KB | mrfelton |
Comments
Comment #1
MGN CreditAttribution: MGN commentedTwo 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 ?
Comment #2
mrfelton CreditAttribution: mrfelton commented1) 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.
Comment #3
mrfelton CreditAttribution: mrfelton commentedok, on further inspection it seems that the breadcrumbs are applied to paths with prefix if you:
a) set that langage of the cb
AND
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.
Comment #4
mrfelton CreditAttribution: mrfelton commentedA 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.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.
Comment #5
MGN CreditAttribution: MGN commentedWhat about something like this (in hook_nodeapi and hook_views_pre_render)
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.
Comment #6
MGN CreditAttribution: MGN commentedThe 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.
See any problems with this? I am going to try to work something like this into my next commit for further testing.
Comment #7
MGN CreditAttribution: MGN commentedI 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.
Comment #8
mrfelton CreditAttribution: mrfelton commentedSeems to be working well - thanks.
Comment #10
liquidcms CreditAttribution: liquidcms commentedi 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:
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.
Comment #11
liquidcms CreditAttribution: liquidcms commentednot sure the best way to fix this, but...
Comment #12
MGN CreditAttribution: MGN commentedMarking as needs review since there is a patch now...
Comment #13
lamp5