Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Here's what's happening:
I'm installing aegir with vagrant so my default hostmaster email address ends up being aegir@hostname. If hostname is not a FQDN and you do not change it, installing sites will fail with:
DRUPAL_INSTALL_FAILED
Exception Object ( [message:protected] => The e-mail address webmaster@devshop is not valid. The e-mail address webmaster@hostname is not valid.
I can just edit my user's account and update the email... but it would be nice if we did the same validation that drupal install does?
Comment | File | Size | Author |
---|---|---|---|
#6 | provision-validate_email-2038279-6.patch | 3.95 KB | ergonlogic |
Comments
Comment #1
ergonlogicWe already do validate the admin email ininstall.hostmaster.inc. It'll bypass the check if the '-y' flag is set though. How are you running the install?
Comment #2
Jon PughHmm... yeah. I am using the devshop install script.
Not sure how to solve this. I'd say for core aegir, maybe display a message on node/add/site if your mail isn't valid?
For devshop I would also need to check for this on node/add/project as well... thoughts?
Comment #3
ergonlogicThe site form is already overly complicated, so it'd be best not to add additional validation for such a corner case. Another approach might be to validate the email address in install_main() and so forth. We could then set a valid default and throw a warning.
Comment #4
ergonlogicFixed in 77cbe7d.
Comment #5
anarcat CreditAttribution: anarcat commentedI'm not sure I like the new default. 'localhost' is a valid domain, while 'example.com' is actually not: rfc2606 reserved that domain for "documentation and testing" purposes. While the idea behind the RFC is cover the situations where the "example.com" domain may "escape" test beds and documentation, it is fairly clear that it is not expected behavior.
We should instead use a real domain, preferably the domain associated with the server the site is on.
Comment #6
ergonlogicHow's this for a start? First, we can't use expressions to define constants. For now, I just used
global $url
, since, at least we know it's a valid fqdn.For "the domain associated with the server the site is on", I guess we can look up the task context, and then parse the 'master_url'. I think that'd be preferable to looking at
$_SERVER['SERVER_NAME']
or the like. Since the site would be built on the master then synced out to remotes, this would end up using the master's domain (I think).Comment #7
anarcat CreditAttribution: anarcat commentedlooks much better, thanks!
Comment #8
ergonlogicI considered doing this:
While it works well, in that is uses "the domain associated with the server the site is on", it won't actually fix this issue. In fact, it gets us right back to square one.
Also, it turns out that '
global $url
', is not in fact validated as an FQDN, so that doesn't help too much either. Since the point is to ensure the site install succeeds while throwing a warning that will prompt action, I went with the following:I replaced example.com with '.invalid', since this appears to be a proper use of said TLD. Also, since it's independent of the version of Drupal being installed, I moved this function into install.inc.
Fixed in 16ce3af.
Comment #9
anarcat CreditAttribution: anarcat commentedgreat! i didn't know about .invalid!