search

ddev / ddev

Docker-based local PHP+Node.js web development environments
https://ddev.com
Apache License 2.0
2.74k stars 597 forks source link

`drupal` defaults for various subversions are not clearly maintained or updated #6635

Open rfay opened 4 days ago

rfay commented 4 days ago

Is your feature request related to a problem?

In a recent DDEV release we introduced the drupal project type for Drupal 8+.

It relies on inspection of the code laid out to determine the version, which means it's not easy to specify the Drupal version at ddev config --project-type=drupal time, except with ddev config --project-type=drupal --php-version=8.3. (And PHP version may not be the only problem in the end. For example, the inspection done in ddev config --update is used to set corepack_enable as well, for Drupal 11, and also determines the use of an appropriate version of Sqlite3.)

There are various complaints about this though, mostly because in the current setup, ddev config --project-type=drupal may result in a PHP 8.2 project (which should then be changed to 8.3 with ddev config --update). But people aren't doing the ddev config --update because it's not in their habits. (The next major release of DDEV will change most defaults to PHP 8.3, eliminating the biggest problems, but there are still complaints about how this is set or queried.)

Discussion is welcome about how we could:

We can probably do something about this for DDEV v1.24.0

Related:

rpkoller commented 4 days ago

i would still suggest either to automatically run ddev config --update after ddev composer create is finished or at least trigger a prompt asking the user if a config update should be run. that way the described problem couldnt happen anymore .

rfay commented 4 days ago

i would still suggest either to automatically run ddev config --update after ddev composer create is finished or at least trigger a prompt asking the user if a config update should be run. that way the described problem couldnt happen anymore .

In general, ddev config --update is too intrusive, but I agree that in this case it would be reasonable.

However, in the current timeframe with current setup, this wouldn't be an adequate solution (if you were trying to get drush installed before update) because while drupal/recommended-project installs fine with PHP 8.2, drush/drush does not.

rpkoller commented 4 days ago

In general, ddev config --update is too intrusive, but I agree that in this case it would be reasonable.

it hasnt do be shown to the user that ddev config --update is run, that could happen under the hood? and i guess running the config update wouldnt do any harm anyway if nothing changes? and if there is something that needs to change it would be more than welcome?

However, in the current timeframe with current setup, this wouldn't be an adequate solution (if you were trying to get drush installed before update) because while drupal/recommended-project installs fine with PHP 8.2, drush/drush does not.

why wouldnt that be an adequate solution? i mean if the config update would happen as part at the end of the composer create command that sets up drupal/recommended-project, at the time the user wants to require drush/drush the environment is properly set up for the task? so no php 8.2 but php 8.3. for example?

hanoii commented 4 days ago

a ddev config --update with a php upgrade would also need a ddev restart. I personally prefer the specific versions with sensible defaults, than having to rely in an obscure command. In any other platform one would still have to do this manually (update php, update composer, etc..) so why not this case. I also think that the fact that ddev config --update needs the core to be already installed. I wasn't expected that one could update drupal on php 8.2 (assume you can based on what @rfay said above), but this could not be the case in future combinations of core versions/php.

I wonder why this has never been a problem with the other frameworks that doensn't have a version specific handling.

What about supporting both? the general drupal and a more specific one where one could define it and that would validate/configure defaults before even updating anything. Like ddev config --project-type=drupal11 --php=8.2 would fail

Maybe add it as kind of tag-based format like --project-type=drupal:11 a bit more like docker images

rfay commented 4 days ago

I wonder why this has never been a problem with the other frameworks that doensn't have a version specific handling.

TYPO3 has been the primary one that does this (but it doesn't rely on any update), never had any complaints.

Maybe add it as kind of tag-based format like --project-type=drupal:11 a bit more like docker images

That's an interesting proposal.

I even think that perhaps drupal was a mistake and we should just go back to explicit project types.

gitressa commented 4 days ago

I'll re-post some parts from another, similar issue:

[...] I don't agree that config --update is a great solution. It seems kludgy to me. In my opinion, setting PHP 8.3 as the default version in July to coincide with the release of Drupal 11 would have been the correct solution. PHP projects still on 8.1 or 8.2 should bear the burden of jumping through hoops, to get a correct configuration.

It feels like Drupal is being punished for doing best practices, and using the current stable PHP 8.3. https://www.php.net/downloads.php#v8.3.12

Then, the four lines I posted above your comment would be enough.

Anyway, I am looking forward to having the PHP 8.3 as the default version, I only wish it had coincided with the release of Drupal 11 in July 2024.

[...]

PROPOSAL: Sync the default PHP version of DDEV with PHP requirements of the current release of Drupal, so that these simple steps get you the latest Drupal, with the correct PHP version:

mkdir drupal11 && cd drupal11
ddev config --project-type=drupal --docroot=web
ddev start
ddev composer create drupal/recommended-project

In that issue I asked:

What do you think about my proposal?

Perhaps moving forward, DDEV could try to keep default PHP version in sync with Drupal PHP requirements, so that the default PHP version is identical to the current release of Drupal? https://www.drupal.org/docs/getting-started/system-requirements/php-requirements#versions

@rfay answered:

The reason we didn't do that earlier is that we try not to change defaults except in major version releases.

All right, but what's stopping us from planning accordingly, and making a major release, when the default PHP version needs to be bumped up?

I think getting the latest Drupal 11 with config --project-type=drupal works great. I don't see why we have to abandon it? config --project-type=drupal7 should get you the correct set up for Drupal 7. If you need a special set up, nothing is stopping you from adding a parameter, like php=8.1, overriding the default set up.