Add app from CMS distribution

[rickmanelius]

What happened (or feature request):

Feature request

What you expected to happen:

• On the dashboard showing all apps, there is an "add app" button.
• When a user clicks this button, the user is directed to an "add application" screen.
• On the "add application" screen, the user is presented an option to "add from distribution".
• When clicking the "add from distribution" button, the user is brought to a new screen.
• The "add from distribution screen" displays a logo and name for Drupal 7, Drupal 8, and WordPress.
• When a user clicks one of these 3 buttons, they are prompted with a text field to name the project.
• Based on the selection, a git clone w/squashed history is performed with the repo pulled and stored in ~/User/git/SITENAME
• Based on the selection, ddev config uses known docroot and app type values.
• ddev start is triggered.
• Once ddev start completes, the user is prompted with a link to the site.

[rickmanelius]

It sounds like this is where there is some question or confusion over (1) the intention and (2) value of this feature. I'll attempt to break it into two pieces in my next comment, but I know this is in active conversation and I wanted to highlight that my attention is now on this.

[rickmanelius]

Intention

While this may not be officially documented in this repo or within our docs, there is an assumption that the UI will provide an easier onboarding and ongoing usage for end-users that are not as familiar or comfortable on the command line. To that end, when it seems useful without adding significant technical debt, I would prefer to allow them to be as functional as possible from a site-building perspective without having to go to the terminal. Additionally, those that may be completely new to WordPress or Drupal may find the barrier to entry to download and place the codebase. Also note situations like Kalabox's integration w/Pantheon, which essentially allows them to trigger Pantheon to spin up a site of a specific type and then pull it down.

I'm rambling a little, but summarizing:

• Site-builders: can we keep them in the GUI as much as possible (if they want to be there)?
• Showcasing: can we show users all the different CMSs we support.
• Ease on Initialization: can we make it super simple to start from a fresh codebase?

Value

• Speed of initialization: I could download ddev UI and one click get to a new site (versus download, unzip, place, configure, then start).
• Staying within GUI: While they can't avoid the file system and terminal forever, this helps.
• Showcasing CMSs: We get an opportunity to highlight additional CMS's we support.

To that end, if we're saying that packaging them within the GUI doesn't make sense... I'm not opposed to pivoting the storage to a trigger to download and then keeping a cached copy locally (perhaps in ~/.ddev) so we don't get wound up around whether or not it's delivered with the installation.

[andrew-c-tran]

Work is blocked until a decision is made on #24

[rickmanelius]

Unblocked #24. Updated to actionable!

[rickmanelius]

Regarding the style/design of this element, we had a discussion in #8 that would remove it from the upper right as a button and instead show up as the first card before the active sites. There were two motivating factors: 1) We will replace the button in the upper right of the screen with a menu and 2) when there are no sites active, we wanted a more prominent call-out.

As for card appearance, we can keep the modal and make the default card a simple blue background with a white plus in the middle. Upon hover it would have the dark blue background. Upon click it would bring up the current modal.

As for the modal appearance, we currently have the following options:

• App Type (w/logo)
• App Name
• Directory

I think we need to rethink this because this works for existing sites but doesn't really make sense for a new site from a distribution. I imagine two flows.

Specify an Existing Codebase

• User clicks add
• User specifies location
• We autofill in a suggested name based on the parent directory, but they can modify.
• We attempt to detect the app type and suggest, otherwise they pull from a drop down.

Quickstart From Distribution

• User picks a distribution (WordPress, Drupal 7, or Drupal 8)
• User specifies a site name
• We autofill in a suggested file path and they have the ability to override/specify

The downside of this approach is that we may need to have an initial question to only show info related to the specific use case. Alternatively, we could provide the user a choice on the "Add" card by providing two buttons.

Title: "Add a New Site"
Button 1: "Manually Specify a Codebase"
Button 2: "Quickstart From Distribution"

I need to think through the text strings, but this would highlight the two use cases.

[andrew-c-tran]

blocked by #24 - PR ready, needs approval before we can move forward with this

[rickmanelius]

@andrew-c-tran When you have a moment, can you point me to the PR to review this one? I'm perhaps a little dense...

[rickmanelius]

It looks like from the reviews starting here #62 (review) that there is a bit of code/test cleanup before we merge.

[andrew-c-tran]

v0.1.0 accepted and released, closing issue