I have a multilanguage install with per language domains. The XML file is nicely generated with only links for each language, having the correct domain names...
except for the link to the XSL stylesheet in the header. That has the same domain for all stylesheets. (Being: the one corresponding to whatever domain the sitemap (re)generation command was run in.)

I'm not up too date on whether that's legal, but a client pointed out that he saw an error in Firefox so I thought I'd just fix it.

Note: I am just assuming that the 'language' option is always available... since somewhere in xmlsitemap.xmlsitemap.inc I see language_default() being added to an options array. (I haven't actually tested that.)

CommentFileSizeAuthor
#4 1158406-4.patch963 bytesroderik
#3 1158406-3.patch899 bytesroderik
#2 1158406-2.patch949 bytesroderik
xmlsitemap-xsl-lang.patch619 bytesroderik
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented
Status: Needs review » Postponed (maintainer needs more info)

The URL should be relative already and shouldn't cause any problems. Is that not happening in this case?

roderik’s picture

roderik
Primary language Dutch
Location Amsterdam,NL / Budapest,HU
CreditAttribution: roderik commented
Status: Postponed (maintainer needs more info) » Needs review
FileSize
1158406-2.patch949 bytes

Ah, right.

No, I'm sorry to report that on 'domain name' multilanguage sites, url() always returns an absolute URL, thanks to language_url_rewrite(). Unless we cheat in undocumented ways...

New patch attached. Again, only tested on my site. Then again, this one doesn't have any effects for other configurations.

(This was the only location that needed a relative URL, right?)

roderik’s picture

roderik
Primary language Dutch
Location Amsterdam,NL / Budapest,HU
CreditAttribution: roderik commented
FileSize
1158406-3.patch899 bytes

*cough* that was not a success. Below patch fixes a problem I introduced:

The 'domain' property of the language object should be set for the remainder of the code - otherwise all other ('loc') URLs will get the wrong domain.
And I didn't expect this, but the following code modifies $this->sitemap->uri['options']['language'].....

$sm = drupal_clone($this->sitemap);
$o['language'] = $sm->uri['options']['language'];
unset($o['language']->domain);

To get around this, I passed an even simpler (and more hackish) fake language object.

roderik’s picture

roderik
Primary language Dutch
Location Amsterdam,NL / Budapest,HU
CreditAttribution: roderik commented
FileSize
1158406-4.patch963 bytes

*sigh* and directly after uploading this, I saw what I was doing wrong.

The patch in #3 works. This one too. Which one you prefer is partly a matter of taste; I kinda like this one better.

Azrael256’s picture

Azrael256 CreditAttribution: Azrael256 commented

I must say I was having the exact same problem and your patch did the trick, thanks !

Now let's hope it gets integrated into the next update, so that we won't have to patch again next time.