Table of Contents

Automated Chapter Creation

To aid in the quick deployment of new chapter sites, a utility script has been installed at /var/www/ It takes care of everything from creating the CMS database; to creating a new domain record in the CRM; to enabling common settings, themes, modules, and extensions; to assigning default user roles; to creating a cron job. Apache is configured such that no new vhosts need to be created. You need only execute the script and point the DNS.

The utility need not be run as root, but it does use sudo internally and may request your sudo password. The utility uses the login-path flag for mysql commands and assumes that the login-path “root” provides root access to MySQL. If you haven’t set this up for your user on the server, run mysql_config_editor set -h localhost -G root -u root -p and supply the MySQL root user’s password when prompted.

The utility allows the administrator to specify the environment (with the e flag) in which to spin up the chapter site. It is recommend that deployments be tested in another environment before being deployed to production.

Run it with the h flag for more information on how it works; for the full picture, read the source.

Optionally, override

  • -c contact ID for the default domain organization
  • -g group ID for the Domain Access Group


  • Be sure that you do not have a mysql .my.cnf in your home dir. Drush is very clever about looking for db credentials to use. Similarly for the custom utils script (which sometimes use mysql login-path).
  • We are no longer using a Wildcard SSL certificate. So, the cert will have to be regenerated to include the new chapter. See below on Apache config for further reference.
  • In environments other than prod, CIVICRM_UF_BASEURL may be set incorrectly. The environment may be appended to the subdomain twice (e.g., -- this can be fundamentally addressed in the generateBaseUrl() function present in sites/default/civicrm.common.settings.php, or set manually in the site’s civicrm.settings.php file for a quick fix. (It’s worth noting that this file does not appear to be under version control, though it’s referenced several times in fis_multisite_tools. I think this is probably intentional -- these files contain information that will vary according to the environment and that, being sensitive, should not be under version control. I’m inclined to think the mistake is putting generateBaseUrl() in this file; a better alternative would be for the settings file to include the function from a file that is indeed under version control.)