Suppress email to client after site is installed

I agree that we should stop sending those stupid emails by default. Now that we have the login link in the node and a password reset task, there's very little use cases where this is required.

One in which this would make sense is the "dumb user" scenario where the actual site admin doesn't have access to the Aegir interface...

This option is useful when you use (for any reason) the signup form to create a site and client in a one step. It is then required to send that e-mail, so I don't think the global switch on/off is enough.

The global switch could be useful, but it should always auto-default to "yes" when site is created via signup form and not via standard "create site" form.

BTW: in the real world people are using the signup form also internally, to separate privileges in their own team.

Any updates, I really don't want to hack Aegir's core :( but need to confirm there is not better approach for now ? users are creating accounts from a custom form (actually it is pretty much a whole workflow) but I don't want to have aegir send them this e-mail for admin password because I want to create a user with less permissions and send it to them instead!!

Thanks in advance :)

as a work around, I'll set the $client->client_email to null or something just false to stop it from reaching the user this looks super stupid and super hackish, but hopefully this isn't really the best thing I can do :D

Has anything been done about this?

Quite seriously, this is a *ridiculous* limitation to have.

There should be a simple way to disable all emails coming out of Drupal without resorting to hacking the core.

I have wasted days trying to get Drupal to not send email from a default install in an environment where mail is strictly forbidden.

I looks like I'm going to be forced to go back to square one from all the nice Drush scripting I have done because Drupal is incapable of being installed without generating some kind of email.

After much hunting, the only solution, which is unsatisfactory, but at least not a hack of the core.

For Linux:

/path/to/php -d sendmail_path=`which true` path/to/drush site-install .....

which expands to

/path/to/php -d sendmail_path=/bin/true path/to/drush site-install .....

Which means that php will invoke 'true' instead of sendmail and succeed.

Solution for windows is to patch the drush.bat file in %PROGRAMDATA%\Drush or %PROGRAMDATA%\ProPeople\Drush if you have an older version.

@php.exe -d sendmail_path="echo" "%~dp0drush.php" %* --php="php.exe"

Hi DrMiaow,

Personally I don't prefer such a hack at all.... yet this option will be amazing to have on host master..... however, there is another solution that worked better for me (this wasn't available back in May when I first posted here :) )

http://drupal.org/project/hosting_profile_roles

Is a module focused on using Aegir for SAAS sort of things :) .... what I needed from it was to stop the email being sent to user 1 from being sent ... yet wanted to have user 2 created ..with less permissions on the site) to be created and notify the new site owner about it!

Flinally to alter the message being sent to the user you will need to edit your installation profile's install( ) hook to set the new Drupal user confirmation message ;)

Thanks.

I'm just after a solution that will kill emails on install via Drush - so the hack will do for now because I can get it into my build script.

Would rather that Drush had a flag for this - would be much cleaner.

Cheers.

Well, the problem is not with drush here but, as was mentionned in the original post, in the aegir backend itself which unconditionnally sends out those emails.

New features need to be implemented in Aegir 3.x, then we can consider back-porting to Aegir 2.x. Aegir 1.x is essentially deprecated.

If you are using Drush, you can do the following:

PHP_OPTIONS="-d sendmail_path=/bin/true" drush -l <site> site-install <profile>

The aegir site install fails with error 'Unable to send e-mail. Contact the site administrator if the problem persists.' This should be a warning.

That message already is a warning for D7 and for D8 it seems to default to a notice in our code.
See D7 and D8

But Drupal core has it as an error in includes/mail.inc

Can we catch that?