docs: show initial and project-checkout Backdrop installation

[tyler36]

The Issue

The current Backdrop quickstart fails:

git clone https://github.com/example/example-site
Cloning into 'example-site'...
remote: Repository not found.
fatal: repository 'https://github.com/example/example-site/' not found

How This PR Solves The Issue

This PR fixes 2 issues with the current documenation:

• Corrects clone target
• Sets DDEV config to "backdrop"

As I don't use Backdrop, I'm not sure if this "best practises". However, these steps did result in the "site setup" screen displaying.

Manual Testing Instructions

Automated Testing Overview

Related Issue Link(s)

Release/Deployment Notes

[tyler36]

Pinging @klonos because they have been active in the issue queus recently regarding backdrop.

[rfay]

Thanks for this, and so glad to have Backdrop folk around again after a very long time!

The idea here was that people had an existing project. Why don't we change it to show two alternates.

1. Your example (cloning backdrop itself, although their site might suggest downloading a tarball instead)
2. The intention here, checking out an existing project built on backdrop.

[rfay]

Seems like it's going to be fine to me, thanks!

[rpkoller]

I've left one comment about the styling of the new projects tab. Aside that I've tested the install with the git clone approach and it worked like a charm.

In regards of the existing projects tab i am not that much of a fan of that kind of quickstarts due to the fact that it is none functional and sort of abstract in part. personally they often confuse me more than they help. one idea instead of having a tab for existing projects might be to provide another quickstart for installing backdrop via an archive.

a few weeks back when i worked on the restructuring of the quickstarts i also tried to provide quickstart guides for none functional ones like backdrop had and make the quickstart guides more consistent. the steps i came up with for backdrop are as follows:

curl -LJO https://github.com/backdrop/backdrop/releases/latest/download/backdrop.zip
unzip ./backdrop.zip && rm backdrop.zip && mv -f ./backdrop/{.,}* . && rm -r backdrop
ddev config --auto
ddev start
ddev launch

that archive always provides the latest stable version of backdrop and the second chained command unpacks the archive and moves things around a bit and cleans up things at the end.

[tyler36]

curl -LJO https://github.com/backdrop/backdrop/releases/latest/download/backdrop.zip
unzip ./backdrop.zip && rm backdrop.zip && mv -f ./backdrop/{.,}* . && rm -r backdrop
ddev config --auto
ddev start
ddev launch

Not sure which style the community prefers. My attempt was to "correct" as opposed to "improve".

[rpkoller]

Not sure which style the community prefers. My attempt was to "correct" as opposed to "improve".

yeah i agree that fixing the current completely none functional state is the right thing to do. improving and making recipes more consistent might be better the step afterwards.

but still the current state of the quickstart is

git clone https://github.com/example/example-site
cd example-site
ddev config
ddev start
ddev launch

the quickstart in the new projects tab fixes that problem. you get a functional project. the problem with the existing projects tab i have is that is more or less the same level of functionality like the current quickstart. the only difference the user learns about ddev config and how to set the backdrop as the project type, that you can run composer install (not sure if there are any backdrop project utilizing it? ) and how to import a database. but all abstract and not directly test and actionable. that is the point i tried to make. that kind of quickstarts were from my own personal user perspective always challenging and abstract. they raised more questions than they helped for CMSes i never tried yet and consider to give a spin.

That was the idea behind my suggestion instead of adding the abstract existing projects quickstart adding the quickstart about downloading an archive. that is a pattern many quickstarts apply. providing one quickstart for composer or the download of an archive if no composer workflow is available and one quickstart for git. that was the reason why i've suggested the archive download instead of the existing projects example.

from my perspective quickstarts should be what the name implies a quick actionable recipe you are able to spin up a CMS you have literally no idea about.