I ran into a problem with SEO rewrites not working on the front page when the blogapi and url_alter modules are enabled. My setup may represent an edge case, but the fix seemed pretty easy, so I wanted to point it out.
I came across this bug when I created a view block that showed posts from across different subdomains. I enabled SEO rewriting in the domain access settings so that the links would go to the correct source domain. I enabled the block for all pages, and everything appeared to work perfectly. However, when I checked the block from the front page, I found that none of the urls for content on other domains were being rewritten properly. I ended up tracing this back to an issue with the module load order and the fact that domain_access does not include() its url_outbound_alter hook until domain_init is called. Here's what I was able to figure out:
With the blogapi module enabled, at the start of a page view, blogapi_init runs and calls url() only if viewing the front page. url() in turn calls custom_url_rewrite_outbound, which on my site is being defined by the url_alter module. url_alter then calls module_implements('url_outbound_alter') to find out what modules are implementing its hook. However, at this point, based on the default module load order, domain_init has not yet been called (it will be called after blogapi_init because of alphabetical ordering). Therefore, settings_custom_url.inc has not been included and domain_url_outbound_alter has not been defined. In this case, module_implements('url_outbound_alter') does not return domain_url_outbound_alter() as a hook, but it caches the value in a static array, so even after settings_custom_url.inc is included by domain_init, future calls to module_implements('url_outbound_alter') will still not include domain_url_outbound_alter. Then, when my view is built, the domain_url_outbound_alter does not get used, and my urls are wrong. Note that on any page besides the front page, blogapi_init does not call url, so the first call to custom_url_rewrite_outbound and module_implements('url_outbound_alter') occur after domain_init has run.
My simple fix was to change the weight of the domain module in the system table to -10, so that domain_init would be called before blogapi_init. Because I have prefixed the url_alias table, I also had to change the weight of the domain_prefix module so that domain_prefix.path.inc would be included to define domain_prefix_domainpath. To be safe, I set the weight of all of the domain_* modules to -10. This has solved my problem, and now seo rewrites happen on all pages.
| Comment | File | Size | Author |
|---|---|---|---|
| #9 | 820062-url-alter.patch | 2.23 KB | agentrickard |
| #2 | domain_url_alter.patch | 1.69 KB | threeps |
Comments
Comment #1
agentrickardUgh. I dislike messing with module weight. We could try moving the invocation to hook_boot(), or even just to the top of the module include file.
Comment #2
threeps commentedThanks for suggesting a better way to address this problem. The attached patch moves the include of settings_custom_url.inc into domain_boot(). drupal_get_path wasn't available when domain_boot is called, so I just included the file by relative path. I also moved the check to include domain_prefix.path.inc into domain_prefix_domain_bootstrap_full(). I wasn't sure if this was the right spot for it, and now domain_prefix_init() is empty. Together, these two changes fixed my problem and I could leave the module weights at 0.
Comment #3
agentrickardThese both look like smart changes to me, and since we already use hook_boot(), it's ok to add the code there. Trying to send some folks over from #578824: URL rewrites to source domain not working (anymore) to test.
Comment #4
agentrickardComment #5
obstikle commentedAfter coming over from #578824: URL rewrites to source domain not working (anymore)...
Well, the patch fixes source domain URL rewriting on the website I was having trouble with, when using domain, url_alter and feedburner modules. But it breaks URL rewriting in the feedburner module. (I don't actually use this feature, but I thought I should check it anyway.)
I still haven't been able to replicate any of this behaviour on a clean install.
Comment #6
threeps commentedI don't use the feedburner module so I have not tested this, but I just took a quick look at the feedburner code. It looks like both feedburner and domain access work by changing the base_url of the URL to be altered. However, feedburner sets its module weight to -1, so the feedburner url alter hook runs before the the domain access url alter hook. This means that after feedburner changes the base_url (in the $options array), domain access is called and changes base_url again.
Maybe domain access should check whether the base_url has already been changed from the primary domain, and if so should then leave it alone? I'm not sure what the right approach to that conflict is.
Comment #7
agentrickardurl_alter module is supposed to mediate those conflicts.
And in the feedburner case, DA should win out, since it sets the canonical base url for content. Feedburner should respect that, IMO.
You could change the DA weight to -2.
Comment #8
Exploratus commentedI was having this problem. domain Source on the home page was not printing out the approporaite links, it was using the current domain rather than the source domain. Other pages were fine.
I applied patch #2 and it worked immediately, now every link (including the homepage) points to the domain source domain.
Comment #9
agentrickardNice work on this issue. Committed to 6--2 branch with a little bit of cleanup.
Comment #10
agentrickardCommitted to all branches.
Comment #12
agentrickardI'm rethinking this approach, and really want to get Dave Reid's input on it before releasing the change.
Comment #13
agentrickardRE-closing.