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

Created on 27 February 2025, about 1 month ago

Problem/Motivation

Softaculous now offers Drupal CMS as an option in the installer for CPanel on shared hosts. However, Drupal CMS installs in /web instead of directly in the root, which causes a bunch of issues.

The vanilla Drupal install uses drupal/legacy-project to get around this.

Proposed resolution

We should provide a separate package for tagged releases that does not use a separate docroot for install.

✨ Feature request
Status

Active

Component

Infrastructure

Created by

πŸ‡¦πŸ‡ΊAustralia pameeela

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Merge Requests

Comments & Activities

  • Issue created by @pameeela
  • πŸ‡ΊπŸ‡ΈUnited States phenaproxima Massachusetts

    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?

  • πŸ‡©πŸ‡ͺGermany jurgenhaas Gottmadingen

    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.

  • πŸ‡¦πŸ‡ΊAustralia pameeela

    Looks like legacy-project is slated for removal in Drupal 12. πŸ“Œ Remove drupal/legacy-project as a starting point for Drupal 10 Postponed

    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.

  • πŸ‡¦πŸ‡ΊAustralia pameeela
  • πŸ‡ΊπŸ‡ΈUnited States phenaproxima Massachusetts

    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.
  • Merge request !532Add a cPanel template CI job β†’ (Open) created by phenaproxima
Production build 0.71.5 2024