I have a setup for a couple of small Swedish newspapers, two regional and one national - and domain is a great fit for our new website. :)
My problem is that I have static information pages ("About the company" kind of stuff) in my menu, and with SEO switched on - those URLs are rewritten for all users. Without SEO - there's no problem.
I have tried all imaginable combinations of affiliation settings, and the only way to get the link to stay within the current domain - is to disallow affiliation all other domains.
The sites are entirely in Swedish, but if you'd like to take a look - they are located at http://beta.fria.nu (the main site), http://beta.stockholmsfria.nu (one of the regional papers). The menu in question is the top vertical bar, and the menu item is the one floating to the right ("Om Fria Tidningar") - and two of its subitems.
I had a look at custom_url_rewrite_outbound, but I can't immediately see where this goes wrong. I've also tried intercepting the links at theme level - but the URLs have not yet been rewritten there as far as I can tell, which does seem a bit strange. I have the values recieved by theme_menu_item_link and theme_links dumped at the bottom of the page currently - and none of them contains a FQDN.
Anyway, the misbehaviour disappears if I switch SEO off (which I am reluctant to do). However, the best solution for me would be if I could switch the SEO off for these particular pages (since then the subitems of those menus will become indexed, and some of those are unique for each newspaper - like subscription stuff).
Comments
Comment #1
agentrickardWell, this is really a "by design" feature. I changed the issue status and title because your request runs counter to the current logic.
By design, the SEO optimization is "greedy" -- it will transform all node links to follow absolute paths to the assigned domain for a node. If you disable strict SEO, you still have the ability to force this behavior on specific paths, using the "Special page requests" form on the module settings page.
I would not call this "misbehavior" -- it is the core design of the module.
What you seem to be after is a way to disable SEO rewrites on specific pages.
You are correct that the behavior is controlled through
custom_url_rewrite_outbound(). What you may want to do is copy that function directly into your settings.php file and then edit it. Remove the include call as well. That way updating the module will not interfere with your modifications.To modify the function as you need, I think that all you need to do is to comment out the final clause in the function.
This piece is the logic that rewrites urls for pages assigned to "all affiliates." If you disable it, and assign those menu links to "all affiliates," then you should get the behavior you want. However, this would mean that any node that is assigned to "all affiliates" will be linked to from the current domain. If this is not the behavior you want, then we have to do something else.
In that case, you would need some logic to tell the function to skip the rewrite sequence. Like so:
The logic of that IF statement will vary, depending on how your menu items are structured.
Comment #2
agentrickardI took a quick look. Here is the kind of logic I think you need.
The 'omfria' part of the path may not be needed, if that is a subdirectory of the install and not a Drupal internal path.
Comment #3
Ibn al-Hazardous commentedThanks for the quick answer(s)! :)
I'm afraid I mixed a bug report and a feature request in one post, mea culpa. The bug is that SEO rewrites URLs even if the user agent is Firefox or Internet Explorer (at least for static nodes in menus, and at least for me - that is what currently happens at the URLs I provided). Should I repost the bug, without mixing it up with a feature request?
Anyway, thanks for the pointers to where I can hack the feature (disabling SEO on some pages) in. I'll get started on it right away! :)
Comment #4
Ibn al-Hazardous commentedThere, got it to work. :)
But I realize that I made an assumption about how SEO works, that probably isn't valid. I was thinking that SEO only is activated when the user agent is a search engine spider (alternatively, when the user agent isn't a well known browser). Since it appears that isn't so, I suppose that'd be a second feature request. Would anyone else be interested in something like that?
Comment #5
Ibn al-Hazardous commentedI just made a quickie - to see if it's feasible to enable SEO for search spiders only. This is what I came up with:
As far as I can see, the problem with my approach is keeping the list of search engine user agents up to date. I guess that would be manageable with a central xml-file checked with cron. OTOH it's not that long between versions on a supported Drupal module.
Comment #6
agentrickardRight. The URL rewrite feature happens at the PHP level when the page is being generated, and it doesn't care how the page is being generated.
Now you do have two tangled reports. Let's keep the spider report over at http://drupal.org/node/255711
As for the issue here, did the above code solve your menu problem?
Comment #7
sunThis is probably a duplicate of #256007: Single Sign-on and SEO
Comment #8
Ibn al-Hazardous commentedYes, the suggested solution works fine. The only change needed was that I had to use the unaliased URLs (node/1234), otherwise it works perfectly. :)
As for this being a duplicate of #256007, I doubt it. We don't use SSO, and probably never will - since our newspapers are distinct products that share some articles. What we really wanna do, is turning on SEO for search spiders only, but I'll keep the rest of the discussion that generates over at http://drupal.org/node/255711 as requested. :)
Comment #9
sunSorry, #7 was based on the code in #1 and #2. Your code in #5 is definitely a completely different topic and probably a new feature.
Marking as duplicate of #256007: Single Sign-on and SEO for now.
Comment #10
agentrickardWell, the original issue -- Disable SEO on some pages -- still applies. I don't know that it will ever get coded, but we should keep this around for reference.
Basically, you might have need for a setting that lists pages for which url rewrites should be ignored.
Comment #11
agentrickard