docs should give clearer signposting of how to update DDEV config when updating a CMS

[joachim-n]

Is there an existing issue for this?

• [X] I have searched the existing issues

Output of ddev debug test

No response

Expected Behavior

It's not clear from the docs how to deal with DDEV when updating a project's core codebase. For example, when updating Drupal from 9 to 10, or 10 to 11, the PHP version will need to change.

Running ddev config apparently does this, but it's not obvious to go looking there since it's mostly described as a command for initial setup.

A section should be added to https://ddev.readthedocs.io/en/stable/users/usage/managing-projects perhaps.

Actual Behavior

n/a

Steps To Reproduce

No response

Anything else?

No response

[rfay]

how to deal with DDEV when updating a project's core codebase

When you change your CMS, you have to configure the PHP version you want, right? Does that have to do with DDEV?

[kevinquillen]

I'd also agree that when updating any software component (CMS, DB, Solr, etc) it's on the developer to manage that. It might be too much (and maybe presumptive?) for DDEV to overwrite that. For example, how would DDEV manage changing Solr versions if you go from D9-11? Or other CMS?

[rfay]

I just don't think it's DDEV's job to manage these things. It would increase scope too much. Closing for now, but thanks for the suggestion.

[joachim-n]

I'm confused, because I'm sure someone on Slack told me that the ddev config command already supported this -- that is, you can re-run it on a existing project that is, say on D9, when you want to upgrade it to D10.

So this issue was just about documenting that more clearly.

[rfay]

ddev config --update will inspect your code (any time) and if the DDEV autoconfiguration understands what to do, will set the defaults. It's not specifically about updating a CMS. But for Drupal 11, for example, DDEV would detect Drupal 11, and update defaults for it.

DDEV would try to do these things for Drupal: https://github.com/ddev/ddev/blob/a96ab265933cc9c94c7533740fd40d78add0ccc5/pkg/ddevapp/drupal.go#L366-L377

But it's certainly nothing of the scope you suggested in the issue here. Just a bit of finesse.

The ddev config docs attempt to explain this situation. Click the pencil in the upper right if you have more to add to it. Or suggest where else you might want an edit.

[joachim-n]

Yup, I saw it's mentioned in the docs for the config command. My point is that this feature would be more discoverable if it were mentioned in users/usage/managing-projects. I can have a look at editing that, but I am not sure where you'd like a new section to go in that document.

[rfay]

This new feature was added to v1.23.0 specifically for the new "drupal" project type. Because the quickstarts are often ddev composer create recipes, they don't have any code at first ddev config time. Now that "drupal" is a thing instead of adding a new type every time there's a new version, DDEV can detect the various varieties after composer install using ddev config --update.

The quickstarts for drupal do have this.

[joachim-n]

I'm not sure whether you mean we shouldn't add new docs, or where we should add them :)

[rfay]

If you can see where to do it, please discuss or click the pencil.

[rfay]

Note that DDEV says this after a ddev composer create:

ddev composer create was successful.
Consider using `ddev config --update` to autodetect configuration for your project

Maybe you would want it to say that somewhere else?