Add DDEV install option

I am with you on DDEV. It has much better MacOS support, right? I use ubuntu for daily driver. Even then installing lando takes a deb tweak.

I struggled to get multisite to work in Lando. It would not work properly with a single container.

If you had the bandwidth to submit a MR with ddev config, I would merge it.

The steps for installing operations in a multisite configuration with DDEV when you already have Composer installed locally is fairly easy. These are the steps to get the structure. While the settings.php for the planet sites includes some Lando specific settings and there are composer install steps, I'm not incorporating any of that yet.

git clone https://git.drupalcode.org/project/operations.git
cd operations
composer install
composer require drush/drush
ddev config [select the defaults for prompts]
Project name (operations): 
Docroot Location (web): 
Project Type [backdrop, craftcms, drupal10, drupal6, drupal7, drupal8, drupal9, laravel, magento, magento2, php, shopware6, typo3, wordpress] (drupal9): 
ddev start

If we include a .ddev directory in the repo, users wouldn't have to do this next step. Because DDEV uses PHP8.0 for D9 installs and this project requires PHP8.1 or >, we need to edit the .ddev/config.yml to change php_version: "8.0" to php_version: "8.1".

Congratulations, the container for https://operations.ddev.site is now configured. If you go to https://operations.ddev.site, you could now complete the install using the OX Stock install profile...

...but to see Site Manager working we also want to configure 3 subsites for https://mercury.ddev.site, https://mars.ddev.site and https://venus.ddev.site.

A lot of this can be scripted, but to manually configure this with DDEV we still need to do the following steps.

First, add a file named .ddev/config.multisite.yaml with the following contents...

additional_hostnames:
  - mercury
  - mars
  - venus

The same PHP container is also used to answer all routes so with the Drupal sites.php configuration, we need to add the following to sites.php so the multisite operations knows which directory in the Drupal sites is handling each request.

cp web/sites/example.sites.php web/sites/sites.php

Add the following to sites.php.

$sites['mars.ddev.site'] = 'mars';
$sites['mercury.ddev.site'] = 'mercury';
$sites['venus.ddev.site'] = 'venus';

Now create 3 empty directories for each site in web/sites and copy the DDEV database configuration from default into each site.

mkdir web/sites/mercury
mkdir web/sites/mars
mkdir web/sites/venus

cp web/sites/default/settings.php web/sites/mercury/settings.php
cp web/sites/default/settings.php web/sites/mars/settings.php
cp web/sites/default/settings.php web/sites/venus/settings.php

At the end of each settings.php, replace...

// Automatically generated include for settings managed by ddev.
$ddev_settings = dirname(__FILE__) . '/settings.ddev.php';
if (getenv('IS_DDEV_PROJECT') == 'true' && is_readable($ddev_settings)) {
  require $ddev_settings;
}

with...

// Automatically generated include for settings managed by ddev.
if (file_exists($app_root  . '/sites/default/settings.ddev.php') && getenv('IS_DDEV_PROJECT') == 'true') {
  include $app_root . '/sites/default/settings.ddev.php';
}
$databases['default']['default']['prefix'] = 'mars';

That change allows each planet site to create tables in the database created for the operations site using the table prefix method. This is not ideal, but it's quick.

Restart DDEV using ddev restart. When you restart the project, the routes and databases will be created for the planet sites.

Restarted operations 
Your project can be reached at https://operations.ddev.site https://mars.ddev.site https://mercury.ddev.site https://venus.ddev.site https://127.0.0.1:61302

Now when you visit the 4 sites, they are all responding from a single DDEV application.

The next steps are to figure out how to deal what's currently wrapped in a check for getenv('LANDO') in https://git.drupalcode.org/project/operations/-/blob/2.x/web/sites/defau... and see which of the files that DDEV is creating and altering can just be included.

It might more sense to include the settings and use ddev config --disable-settings-management.

Not sure it's possible to preconfigure both Lando and DDEV to both work with the same site aliases. If it is possible, I'm not sure that's a good idea.

I've never seen wildcards like https://git.drupalcode.org/project/operations/-/blob/2.x/drush/sites/sel... done with DDEV. If I need aliases in a project, I'd add a ddev.site.yml with...

operations:
  root: /var/www/html/web/sites/operations
  uri: https://operations.ddev.site
mercury:
  root: /var/www/html/web/sites/mercury
  uri: https://mercury.ddev.site
mars:
  root: /var/www/html/web/sites/mars
  uri: https://mars.ddev.site
venus:
  root: /var/www/html/web/sites/venus
  uri: https://venus.ddev.site

That technically allows you to use ddev drush @ddev.mars si standard --yes, but you can't actually do that because the database is shared with just prefixes. So dropping all tables isn't just the mar tables, it's all tables in the database named db. Something like ddev drush @ddev.mars key:set admin 123testingkey works fine.

Another option is to add 4 .yml files named named mars.site.yml with ddev as the namespace in each file like...

ddev:
  root: /var/www/html/web/sites/mars
  uri: https://mars.ddev.site

Then you end up with aliases like @mars.ddev. Either way, there you'd need a 2nd set of composer commands in https://git.drupalcode.org/project/operations/-/blob/2.x/composer.json?r...

I'm going to try creating additional dbs in the DDEV onfig.multisite.yaml like https://github.com/ddev/ddev-contrib/blob/master/recipes/drupal8-multisi... and then use $databases['default']['default']['database'] = 'mars';instead of $databases['default']['default']['prefix'] = 'mars';.

If that works, the best solution might a 2nd set of composer install commands that use the ddev aliases for DDEV users.

Making progress.

git clone git@git.drupal.org:issue/operations-3389217.git
cd operations
composer install
ddev config

This is where an alias naming trick would need to be addressed to lack of .ddev in the aliases of the composer scripts.

ddev drush @ddev.operations si ox_stock --site-name=Operations.Local --yes
ddev drush @ddev.operations key:set admin 123testingkey

If I use the browser install for the planet sites, they are installed in the correct databases. Unfortunately ddev drush @ddev.mercury si standard --yes is still trying to install in database named db which overwrites the operation site install. Even after updating the alias names in the composer install scripts, it does the same thing.

I found https://stackoverflow.com/questions/53525456/getting-ddev-and-drush-site...

If I use ddev drush si standard --sites-subdir=mars --db-url=mysql://db:db@db/mars, the site install works as expected.

After confirming the drush si just doesn't work even when defining the databases of multisite instances in multiple settings.php files, I added -dev versions of commands without touching the Lando configuration. I'm still working through all of the commands and testing, but the initial install can now be done in DDEV from this branch with just...

git clone git@git.drupal.org:issue/operations-3389217.git
cd operations
composer install
ddev config
ddev composer operations:install-ddev

This configuration uses FAR fewer resources than Lando since the web and db containers are shared between the 4 sites in a multisite configuration.

I have NOT tested these changes with Lando. I am also NOT completely happy with the duplicate commands and needing to prefix aliases, but I think this is progress making it easier for more people to spin up a demo of an operations site running Site Manager and 3 planet sites running just Site.

Pushed some updates that improve site creation with site name, admin password being set. Also, updated `druid uli`to generated first login url.

Recommend changing the install steps to avoid continuous DDEV config changes. I had a more current DDEV version, which updated the config file.

Here are the steps I recommend:

git clone git@git.drupal.org:issue/operations-3389217.git
cd operations
composer install
ddev start
ddev composer operations:install-ddev

Did not test with Lando either and agree about the duplicate commands. However, not sure how to get around it with the alias difference.

On my Ubuntu workstation, I prefer not to install any LAMP stuff or Composer because DDEV handles all of that so well, (and everything is configurable at <project-name>/.ddev/config.yml). On any Debian derived Linux distribution all anyone needs to do is sudo apt install ddev. Simple as that.

For this reason the commands in #8 ✨ Add DDEV install option Needs review won't work for me. Here's what worked for me once DDEV has been installed:

git clone git@git.drupal.org:issue/operations-3389217.git

## Give the repo a more meaningful local project name:
mv operations-3389217 dxpr

cd dxpr

ddev config \
    --project-type=drupal10 \
    --docroot=web

ddev start
ddev composer install

Last command runs for a bit and the last 4 lines are links to the 4 local websites that all work nicely.

https://operations.ddev.site/project/add/default

...requests a Drupal Site Name, Drupal Site UUID, API Key, and GIT remote. :)

Where might this be better documented?

My comment just above, ( #9 ✨ Add DDEV install option Needs review ) adheres to previous examples in this thread.

However this recipe works to install the latest Drupal10 release of the DXPR Marketing CMS → on DDEV:

mkdir <project-directory>
cd  <project-directory>
ddev config \
    --project-type=drupal10 \
    --docroot=web

ddev start
ddev composer create dxpr/dxpr-marketing-cms-project

# Since I'm pressed for time now, this is what I used to install the website (which provides a 
# username and password to start with:
ddev drush site:install -y

# because I'm too lazy to bother with that, I used this to get a login link:
ddev drush uli