Client name of first client (created on installation) is empty

It seems the client title is empty on installation, so this is probably something we need to fix in the install profile.

So I 'fixed' this by changing the field in hostmaster.profile from $node->email to $node->title and hardcoding the client 'title' to 'admin'. Not sure if anarcat will be happy with this default or not.

But a new problem has emerged: the main hostmaster site node still sets a blank client nid as its client instead of using this 'admin' one, and I don't know why.

We were not setting a drush_set_default for client_name in install.hostmaster.inc, so I set one.

Because of fixing this, I also undid my 'hardcoding' of 'admin' as the title of the first client node, switching back to fetching it from drush_get_option like we used to for client_email.

Nonetheless, it still creates a new client node when installing the hostmaster site, so I'm baffled.

This might be why: in the 'import' task of the hostmaster site post installation:

WD php: hosting_get_client_by_email() is deprecated and may yield undefined results, replace with hosting_get_client(), called from hosting_import_client in /var/aegir/hostmaster-HEAD/profiles/hostmaster/modules/hosting/site/hosting_site.module:324 in /var/aegir/hostmaster-HEAD/profiles/hostmaster/modules/hosting/client/hosting_client.module on line 133.

WD php: Unknown column 'c.email' in 'where clause' query: SELECT c.nid FROM hosting_client c INNER JOIN node n ON n.nid = c.nid WHERE c.email = '' in /var/aegir/hostmaster-HEAD/profiles/hostmaster/modules/hosting/client/hosting_client.module on line 135.

: hosting_get_client_by_email() is deprecated and may yield undefined resul... (Expand)
Unknown column 'c.email' in 'where clause' query: SELECT c.nid FROM hosting_client c INNER JOIN node n ON n.nid = c.nid WHERE c.email = '' in /var/aegir/hostmaster-HEAD/profiles/hostmaster/modules/hosting/client/hosting_client.module on line 135.
An error occurred at function : drush_hosting_post_hosting_task

So the issue is not just limited to the main aegir install, but rather, that any site imported into Aegir with a 'null' client name, generates a client node with a null title.

It should probably default to the first client if the client name itself is null and there is no email.

Still don't know why the hostmaster site gets imported as though its client name is null, when we are definitely setting it in the context on installation..

We were also erroneously injecting the site URL as the 'email' address of uid 1 on sites, including the hostmaster site itself.

It turns out this was because install_5 and install_6.inc both were sending arguments '$url, $client_email' to install_create_admin_user, which in fact only took 1 argument ($client_email).

Thus $url was sneaking in and being used as the email address. No idea how this ever actually worked.. must've gone hidden for a long time

Furthermore, the client_email from the installer is not propagating into the right context it seems, as install_6.inc is getting NULL and reverting to using webmaster@localhost. This should probably be in a separate ticket, I'll clean up later, just noting problems as I find them..

Fixed the email issue in #7 and #8

So this is incredible

The reason why it's failing with a null client is, somewhere, the client_email is still being saved in the context.

This causes the deprecated function to be run, which fails, since the Aegir code knows nothing about the email value in the database.

Keeping the deprecated logic here has actually hurt us! :)

I caught this snippet of a dlm($data) from the hosting_site_post_hosting_import_task, just before we run hosting_import_site (which in turn runs hosting_import_client)

drupalcmig5net [db_user] => drupalcmig5net [site_ip_addresses] => Array ( [@server_master] => 173.203.110.174 ) [installed] => 1 [profile] => default [language] => en [aliases] => Array ( ) [context_type] => site [platform] => @platform_drupal6 [server] => @server_master [db_server] => @server_localhost [uri] => [root] => [site_path] => /var/aegir/platforms/drupal6/sites/drupalc.mig5.net [site_enabled] => 1 [client_name] => admin [redirection] => [loaded-config] => 1 [name] => @drupalc.mig5.net [client_email] => miguel.jacq@gmail.com [backend] => 1 [provision_save_config] => ) )

Still trying to find where it's fetching that client_email from. It's not in the drush alias nor in the site's drushrc.php!

So I think I've fixed this here.

There was one too many variable substitutions in hosting_get_client() (not a big issue)

There were two $name arguments to hosting_import_client, one of which was optional: I couldn't understand this, and this appeared to be the problem - maybe the second $name was nullifying the first? It just didn't seem right, and seemed to be the cause of all this: but please revert it if I'm too stupid to understand.

The last bit was rearranging the order of importing the client: not sure if it really mattered, but since I discovered that client_email is still in the context somewhere, I don't think this should take precedence if it's deprecated: we should try and handle the new client_name first, and revert to client_email if we have to.

I looked over the code again just because I was doubting myself...

In all cases where hosting_import_client is called, we only call it with one argument anyway (be it email or name). So I think this is fine the way I've done it.. it works, at least.

I also re-arranged the order in that check as well, again, so that we don't always throw ugly deprecated errors on new installs: once again, we should always try to use the new method and fall back to the old method if it doesn't work.