search

phenaproxima / starshot-prototype

Prototype of a new kind of Drupal, based on recipes and loaded up with contrib's best modules and themes. Not a fork or a distribution.
https://drupal.org/starshot
106 stars 36 forks source link

As a consumer of Drupal CMS I want to be able to customize specific details of my installation (e.g. name of webroot and trusted host patterns, database driver/creds) #47

Open balsama opened 2 months ago

balsama commented 2 months ago

The webroot directory name, in particular, is pretty baked into the Composer scaffold. I'd like to figure out how we're going to support this (or reject it) sooner rather than later.

@phenaproxima had some ideas I think?

phenaproxima commented 1 month ago

I'm not sure we're going to be able to fix this outside of core.

Core's install script, which we use, hard-codes the use of SQLite. To my dismay, I discovered that you can't just drush sql:dump a SQLite database and then import it wholesale into MySQL. They speak two slightly different dialects of SQL, so that kind of quickie migration doesn't work. At least not without some messy fiddling around (think find-and-replace) that we definitely should not do.

So we have two options:

  1. Lean on Drush. The problem with this is that Drush doesn't currently support installing directly from a recipe (hopefully it will catch up soon).
  2. Change core so that you can specify the database credentials at install time, either via environment variables or a command-line option.
phenaproxima commented 2 weeks ago

This is partially done in #108. If you use DDEV, the installer will now use whatever database it's providing, instead of forcing SQLite.

Installing on the host machine still defaults heavily to SQLite, but even that can be overridden now by tweaking drush/drush.yml.

phenaproxima commented 2 weeks ago

Database credentials are changeable both in bare-metal and DDEV environments, as of #108 and #111. (See https://github.com/phenaproxima/starshot-prototype/issues/10#issuecomment-2183683334.)

Changing the doc root is more involved, but certainly doable. We can do that as a separate feature.

simesy commented 2 weeks ago

A couple people were discussing this in slack and it's hard to imagine this as a common task that needs automation as a feature of the prototype. I personally can imagine a scripted migration of a project that uses /web into another format, but the devil is in the detail. What if someone starts committing files/modules/themes in the /web location? It quickly gets beyond a generic script i think.