Remove inline code for specific CMS types

[rfay]

What happened (or feature request):

Currently the code has inline tests for CMS type, and we are going to be expanding our CMS types very soon. We don't want inline code because it means we have to edit multiple places to add a new CMS.

We may want to have ddev emit a list of supported CMSs? Maybe in ddev version, and ddev-ui could get the list from that? But there will still be custom code to download specific tarballs...

What you expected to happen:

How to reproduce this:

Version: Please include the output of ddev version, docker version and the project's .ddev/config.yaml.

Anything else do we need to know:

Related source links or issues:

Please use a complexity rating of 1-5 (5 is high) for a feature request. (High complexity implies more PR planning)

[andrew-c-tran]

At the minimum, the UI will have to be updated to add in the new logo and update URI's for any additional CMSes that we update. However, for the rest of the code such as getting cms tarball path and cms type validation, we can create a global that will hold an array of current CMS types that we can reference in the other locations in the code? that way at least we only have one source of truth for the current valid CMS options. This global can then be replaced with either a config or output from ddev version at startup when we decide which route to go from there.

[rfay]

An array of CMS description objects keyed by shortname (like 'drupal7' and containing any additional attributes (like the function to get a tarball, and the icon, etc.) That way it can be added to easily.

[andrew-c-tran]

Not sure if we can put the image in that object very efficiently. The list of supported CMS platforms is ideally coming from the CLI, and in that case that means that should the need to modify/update the image at all arise then we'd have to release a CLI update? Furthermore, to get the image information into that object we'd need to either do something like a super inefficient base64 encoding or a URL to the image which then introduces an internet connectivity requirement for ddev-ui which it doesn't have right now for anything other than starting from a new CMS distribution.

[rfay]

I'd expect the icon image to be an imagefile in a directory, and the item in the array would be a path to it?

While I support ddev-ui consulting ddev for a list of supported CMSs, I think there will be custom code for each, at least the tarball downloaders are radically different.

[andrew-c-tran]

Sure, in that use case i'm a proponent of just having a local config that ddev-ui manages. all ddev version needs to return is an array of CMS platforms that it supports, and the config can handle the rest, and different UI versions and custom configurations can handle the tarball/image paths. Any time we need to support a new CMS though, both CLI and UI will need to be updated

[rfay]

My assumption would be that ddev would have a list (and config array), and ddev-ui would have a list and config array, and that they would always be at parity or else ddev would have more. So ddev-ui could just take the set of apptypes that it knew that were also in ddev and it would work out fine.