Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.See:
http://drupal.org/cvs?commit=358690
More precisely:
http://drupalcode.org/viewvc/drupal/contributions/modules/purl/includes/...
This patch introduced a regression which makes the subdomain domain rewrite method going mad. It can't guess the right default domain anymore, which makes it duplicates the subdomain prefix when already in the purl context.
Plus, the variable 'purl_base_domain' in the admin/settings/purl page has a wrong description which does not talks about the subdomain processor at all.
Comments
Comment #1
pounardAlso, your base domain variable seems to going totally dumb if you don't write the "http://" in the variable admin section textfield, and this is written nowhere. This piece of code is unstable and un-documented.
Comment #2
jmiccolis commentedI've just committed a change that adds validation to the base domain setting http://drupal.org/cvs?commit=387314 however I don't follow the real issue here. Can you tell me what exactly you are seeing and how I can reproduce it?
Comment #3
pounardThe base domain settings is also important for subdomain modifier, its not written anywhere.
Before the commit I exposed upper, Purl was able to find the base domain by itself, on three different environments I was running the site I'm working on. It was working well with subdomain modifier, and now, it isn't.
The procedure is for me:
If I don't set the base domain setting, when hitting the site using a subdomain modifier, Purl does not detect it.
Plus, when I write the base domain variable, if I write this:
mydomain.tld, it does not work and Purl seems to have a weird behavior (still not finding my subdomains), I must set the full url scheme like this:http://mydomain.tldelse my sub domain modifiers won't be detected in url.