Provide a package of releases without a separate docroot for shared hosting

If we're going to do this, I really don't want to maintain two separate project templates that are identical except for this stupid little detail.

So if this is going to happen, it should:

• Be fully automated.
• Not be a d.o general project, because I don't want to have to, like, maintain this. It should probably be a subtree split that lives on GitHub, in the DA's namespace, and is published directly to Packagist.

Thoughts?

This sounds scary to me. Can we not try and talk to the folks at Softaculous helping them to install it properly? Otherwise, this could potentially cause subsequent issue at any time in the future, that we don't want to get into. Things that come to mind:

• Directory permissions: some tools and/or processes may make assumptions about what needs to be writable and what not.
• Moving a site to a different hosting provider: if the structure there was different, moving may be difficult.
• Documentation: if users wonder around looking for help, they will find references to a directory structure that doesn't apply to them, but we certainly don't want to maintain 2 versions of documentation either.

That's just what comes to mind immediately, I'm sure there a dozens of more rabbit holes.

Looks like legacy-project is slated for removal in Drupal 12. 📌 Remove drupal/legacy-project as a starting point for Drupal 10 Needs work

I can only imagine that they are using it because doing it "properly" can't be (easily/generically) automated on shared hosting? But I guess we could try to look into what that would require?

Although I understand the concerns, I would also say that the two use cases raised of moving hosting and finding documentation are certainly secondary to being able to use Drupal at all on shared hosting.

This would be relatively straightforward to do. We can build it automatically as a CI job.

• Let's call it drupal/cms-cpanel. That should make it clear that this variant of the project template is intended for cPanel and its relatives (like Softaculous).
• It will be identical to the regular project template except that web/ is ./, same as drupal/legacy-project.
• It should be pushed to a GitHub repository under the DA's drupal namespace, and published to Packagist automatically. I don't think this deserves to be a general project on d.o, that will just be confusing.

Two things still needed here:

1. Sign-off on this approach from @tim.plunkett -- just want it sanity-checked.
2. A destination repository. I'm hoping we can host this one on GitHub so that I don't have to cut a new release manually every time we push a tag, but the decision to grant me a GitHub-hosted repo in the drupal namespace lies with @drumm and @hestenet.

Mixing the subtree split & other derivative repositories into GitHub is not a good idea for access management long-term. Everything working the same way will be much better to manage.

(If we had general projects ready for when core required subtree splits, we would not have used GitHub.)

phenaproxima → credited tim.plunkett → .

@tim.plunkett signed off on this with me in Zoom, so in it goes.

Merged into 2.x and cherry-picked to 1.2.x.

Automatically closed - issue fixed for 2 weeks with no activity.

How much does this trade off against "Keeping the vendor directory outside of the web server's document root is better for security." I use shared hosting all the time and I found a way to place Drupal in 'public_html' and not 'web' and this has worked for me since Drupal 8. This new package saves me the extra changes I usually make to place Drupal in 'public_html' but then it puts 'vendor' in there too. It is tempting for me to start using this package as it is easier, 'just install and configure the site', instead of the extra steps I would have had to make to change 'web' to 'public_html' before I install.

Essentially I want to know if this is now recommended, that is, not having a "relocated document root".

I prefer Drupal does away with needing a "relocated document root". It makes the simple task of installing Drupal a technical exercise.