agaric/documentation
10
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Clarify and correct new Drutopia site documentation

Browse source 
- update config directory
 - pull out 'notes'
 - tone down build_source messaging
This commit is contained in:
benjamin melançon 2022-05-31 15:21:08 -04:00
parent 489ebb24fa
commit 20e5744903
1 changed files with 11 additions and 3 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
tools/creating-new-drutopia-site.md
View file

@ -64,7 +64,11 @@ Webserver, PHP, and MySQL versions and types are selected here to match those us
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. 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. 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}
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 modules are required, consider adding them to `build_source`, knowing they will be available for *all* Drutopia SaaS 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 its output to get started. Then use `ahoy deploy-site <member-instance>` to deploy one. Because the install using `drush site-install` that would be run when `drupal_install: true` is set in the site settings in Drutopia hosting, it is currently recommended to set this to false and use the UI installer or run `php docroot/core/scripts/drupal quick-start drutopia --no-interaction` when ssh'd into the server. Create a new site (member entry) per instructions in Drutopia hosting. The simplest method is to use `ahoy new-site <member-slug>` and follow its output to get started. Then use `ahoy deploy-site <member-instance>` to deploy one. Because the install using `drush site-install` that would be run when `drupal_install: true` is set in the site settings in Drutopia hosting, it is currently recommended to set this to false and use the UI installer or run `php docroot/core/scripts/drupal quick-start drutopia --no-interaction` when ssh'd into the server.
@ -98,10 +102,10 @@ This will create a self.site.yml using the expected pattern of "site_name_INSTAN
### Syncing, and setting up configuration ### Syncing, and setting up configuration
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`: Our standard is to place configuration exports in `$project_root/config`. Set the this in `settings.php`:
```php ```php
$settings['config_sync_directory'] = '../config/sync'; $settings['config_sync_directory'] = '../config';
``` ```
While in `web/sites/default/settings.php` also prevent site administrators being told they can install new modules when they can't and add: While in `web/sites/default/settings.php` also prevent site administrators being told they can install new modules when they can't and add:
@ -112,6 +116,10 @@ $conf['allow_authorize_operations'] = FALSE;
(All this should be updated to use a distribution-wide settings.php when we have that. Until the, use `git add -f web/sites/default/settings.php` to include this in your repo) (All this should be updated to use a distribution-wide settings.php when we have that. Until the, use `git add -f web/sites/default/settings.php` to include this in your repo)
```{note}
Do not to use `settings.ddev.php`, as this will be re-generated during `ddev start`.
```
Once you also have a working Drush installation and a live instance, you can then aquire and export the initial configuration with: Once you also have a working Drush installation and a live instance, you can then aquire and export the initial configuration with:
``` ```