Problem:

Sitemap generation would only work for the current language - other languages would be incomplete or contain links to the wrong nodes.

Steps to reproduce;

1. Install Drupal 7, i18n and xmlsitemap.
2. Set up multiple languages, create some translated nodes with custom paths.
3. Set up a menu - set the menu translation mode to "Translate and Localize"
4. Create menu items for different languages, to the various different nodes.
5. On the front end, the menu will only show items that match the current language - so you can swap out menu items for specific languages.
6. Create a sitemap for each language.
7. Run Cron. The site map for the current language will populate correctly, other languages will display incorrect links, and without their aliases.

I tracked the problem down the xmlsitemap_menu_create_link function.

This was looking for the menu item's language in the wrong place, so all menu items were given "language undefined" UND.

Also the way that the menu works in "Translate and Localize" mode is that when the menu is displayed, any menu items that don't match the current language (or are language neutral) are hidden. This causes all other links to be set as inaccessible in the xmlsitemap table.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

silloyd’s picture

FileSize
983 bytes

Patch attached that fixes the issue for me.

Ludo.R’s picture

Status: Active » Needs review

This patch works perfectly for me.

My menus are set to " Fixed Language".

Status: Needs review » Needs work

The last submitted patch, xmlsitemap-1966512.patch, failed testing.

Anonymous’s picture

Issue summary: View changes

edit

tolasam’s picture

Status: Needs work » Needs review

1: xmlsitemap-1966512.patch queued for re-testing.

Status: Needs review » Needs work

The last submitted patch, 1: xmlsitemap-1966512.patch, failed testing.

Dr.Osd’s picture

Issue summary: View changes

Same problem. Appliyng patch missing node/xx and taxonomy/xx path links from sitemap.xml in not base language.

vladan.me’s picture

Status: Needs work » Needs review
FileSize
984 bytes

This patch actually should fix both issues mentioned in XML generation process
+ $menu_item['xmlsitemap']['access'] = $menu_item['access'] && !$menu_item['external'];
This allows menus that are wrongly interpreted as hidden (i18n issue) to be visible.

+  $menu_item['xmlsitemap']['language'] = isset($menu_item['language']) ? $menu_item['language'] : LANGUAGE_NONE;

This sets appropriate language of the menu item so it gets set well while generating links and figuring out if menu should be visible or not.
Rolling the same patch.

vladan.me’s picture

Probably needs some additional tests since nothing fails.

Simon Georges’s picture

I can confirm it's much better with the patch than without (unfortunately, still not perfect, but much much better).

Simon Georges’s picture

Nevermind, I had an issue with the data of my menu.
I can confirm my sitemaps now exactly match the status of the menus and the languages. Thanks a lot for the patch, this is really needed for websites with i18n.

giupenni’s picture

Works like a charm.

Thank you.

Simon Georges’s picture

Status: Needs review » Reviewed & tested by the community

Ok, I think that qualifies as several reviews ;-)

Dave Reid’s picture

If I wasn't using i18n, what affect does removing the check on $item['hidden'] have? Do we know the side effects of that change?

jyraya’s picture

I agree with Dave Reid, removing simply $item['hidden'] is not the best solution because what do we do if the menu link is actually hidden?

After debugging the full process determining the value of 'hidden', I observed that "xmlsitempap_menu" use "menu_link_load" function to load the menu link.

Before returning the menu item, it translates it.

In my environment but I think it is also the case in yours, "I18N menu" alters this translation process by, amongst other actions, forcing the attribute 'hidden' to TRUE if the menu link language does equal to "LANGUAGE_NONE" ("und") or to the interface language.

So to solve the problem, I see so far 2 possibilities:

  1. We could try to force the language of the interface in order that the I18N alteration does not set "hidden" to TRUE. I cannot figure out yet how to do it and all side-effects that can have to proceed like that.
  2. In the function "xmlsitemap_menu_create_link", we could check if the menu link is actually hidden or not by querying the table "menu_links".

In my opinion, the 2nd possibility is the easiest one to implement. The patch "xmlsitemap_menu-1966512-14.patch" could be an implementation.

jyraya’s picture

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 15: xmlsitemap_menu-1966512-14.patch, failed testing.

jyraya’s picture

New version, I will not meet EOL problems this time.

jyraya’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 17: xmlsitemap_menu-1966512-16.patch, failed testing.

jyraya’s picture

Status: Needs work » Needs review
FileSize
1.29 KB

Last try.

justb3a’s picture

#20 works for me. Thanks!

steveoriol’s picture

#20 works for me. Thanks!

alvar0hurtad0’s picture

Status: Needs review » Reviewed & tested by the community

yes, it works.

RavindraSingh’s picture

Status: Reviewed & tested by the community » Needs work

Reopening it, as this is not working with 7.x-2.2 release.
It is still adding duplicate and adding node/nid URLs.

Dave Reid’s picture

This should be going inside the xmlsitemap_i18n submodule to alter the default link values generated by xmlsitemap_menu. xmlsitemap_menu should know *nothing* about i18n and should only support what core supports.

RavindraSingh’s picture

Nope, it looks like when nodes are getting duplicate from the xmlsitemap_node submodule.

Node

crtlf’s picture

Patch #20 works for me, with 7.x-2.3 release.
Thanks !

mmncs’s picture

#20 with 7.x-2.3, works for me as well.
Many thanks!

pifagor’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 20: xmlsitemap_menu-1966512-17.patch, failed testing. View results

rescandon’s picture

#20 with 2.5 has been working very well in one of our clients in the last two years.
Thank you.