Please see [the Drutopia Platform README for an overview of hosting and deploying Drutopia sites](https://gitlab.com/drutopia-platform/drutopia_host#introduction )
These last two repositories are private to Agaric and others maintaining the Drutopia platform, so if you're following along at home you'll have to create your own analogs, per [the documentation](https://gitlab.com/drutopia-platform/drutopia_host#introduction).
Ordinarily this will live under https://gitlab.com/agaric/sites (for Agaric clients) or https://gitlab.com/drutopia-platform/sites (for direct Drutopia platform members).
Copy the `composer.json`, `composer.lock`, and `.gitignore` files used by the appropriate build source, such as the [default build source for the Drutopia Platform](https://gitlab.com/drutopia-platform/build_source).
Once you have created and are in this directory, whether `agaric/sites` or `drutopia-platform/sites` or wherever you want your project to live within the GitLab namespace, you can copy-paste these commands for a quick start:
Webserver, PHP, and MySQL versions and types are selected here to match those used on Elizabeth and should be adjusted to match your live environment, including double-checking that they are still valid for `elizabeth.mayfirst.org`. Please update this documentation if it changes! The last two options (enabling Xdebug by default and not using DNS for your local site) are optional at the developer's preference. Additional ddev options can be found at [ddev.readthedocs.io/en/latest/users/cli-usage](https://ddev.readthedocs.io/en/latest/users/cli-usage/).
In order to get a configuration that has the proper site key, it is easiest to first deploy the site to the eventual live location, and sync that database locally.
If you are creating a specialized build of Drutopia, you will have to add that to the host vars, and build that prior to deploying the site. `ahoy vars-edit` and `ahoy deploy-build <build_target>` are used for this. Note that new builds should be added ONLY as absolutely required. Configuration, and themes should be leveraged as much as possible prior to resorting to a new build. If additional/different modules are required, a new build is required - do *NOT* add them to build_source except when they are known to be required for *ALL* Drutopia basic sites.
Create a new site (member entry) per instructions in Drutopia hosting. The simplest method is to use `ahoy new-site <member-slug>` and follow it's output to get started. Then use `ahoy deploy-site <member-instance>` to deploy one.
The [drush site aliases file](https://github.com/drush-ops/drush/blob/9.5.x/examples/example.site.yml) can be used to provide easy access to the live/test instances of a site. From the root of your project directory (e.g. `agaric/sites/example/`), you may create one with:
This will create a self.site.yml using the expected pattern of "site_name_INSTANCE" (e.g. example_com_live for the example-com live instance). Supply the URL form of the site name for the MY_SITE variable (i.e. with dashes, rather than underscores).
Drutopia releases will expect the configuration in `$project_root/config/sync`. Be sure to set the appropriate variable in `settings.php` for it to be stored/retrieved from there. Note not to use `settings.ddev.php`, as this will be generated during `ddev start`:
First, ensure that all domain names are pointed to the new location. Deploy the site with the appropriate `server_hostname`, and `server_aliases` already set. Note that if `canonical_redirect: true` you should use the default `<member>-live.drutopia.org` for `server_hostname` until the certificate is provisioned.
Currently, acquiring the certificates must be peformed directly on the server (as root) by running:
Adjust the vault configuration to include the path to the newly generated cert and key values in the SSL settings for the member (`site_ssl_cert_path` and `site_ssl_key_path`). If there are no further changes, an `ahoy deploy-site-minimal <member>` deployment is enough to activate the certificates (if host names have been added, a normal deploy is necessary for them to reach Drupal's setting for allowed hostnames).
#### Reconfigure For Future Deployments
Once the initial site has been installed, be sure to update the vault parameters, as appropriate:
```
config_import: true
drupal_install: False (or else remove this line)
```
#### Potential Traps
If configuration is not importing: log in as root and delete the file `/home/<member>/site/CUSTOM-VERSION` and run the config-forced install option again - this tells the activate script to repopulate the config folder from the custom source.
