Remove drupal/legacy-project as a starting point for Drupal 12

We should also mark the package as abandoned on Packagist, not sure how that is done.

Fixing test-failure.

Note that we don't remove the dataprovider \Drupal\BuildTests\Composer\Template\ComposerProjectTemplatesTest::provideTemplateCreateProject, since we (most probably) are going to repurpose it for #3294205: [Packaging broken!] Composer v2.2 prompts to authorize another plugin when stability=dev

+++ b/composer/Template/README.txt
@@ -15,30 +15,18 @@ https://git.drupalcode.org/drupal
+The recommended project creates a new Drupal site with a
+"relocated document root". This means that the files "index.php" and the "core"

The wrapping here is off, the quoted phrase doesn't have to remain on one line.

Otherwise the 10.x and 9.5.x patches look good but it would be good to also get a review from the Composer initiative team.

Adding to the meta for deprecating tarballs

Rerolled the patch #6 in Drupal 10.1.x.

That patch did not appease TestBot...

Rerolled the patch #6 in Drupal 10.1.x.

Moved to MR

I applied patch 14 and corrected wrapping and a duplicate letter. Attached is a diff.

Looks ready

Are we going to do this in the D10 cycle or should we wait until 11.x is open for development and remove it only in 11.x releases?

If #10 is correct we need to actually stop trying to create tarball releases of core via the packaging script altogether, before we break them.

I believe tarball packaging depends on this https://git.drupalcode.org/project/drupalorg/-/blob/2647a1a82a012af30376...

And we’d have to check if this is hard-coded anywhere in subtree splitting, https://bitbucket.org/drupalorg-infrastructure/subtree-splitter/src/master/

@drumm from the DA end what do you think about removing core tarball packaging from 11.x onwards? We'd need to keep the 10.x tarballs probably, unless we do it purely by a date cut-off.

Sure, either policy works. We can get the packaging pipeline, including subtree splits, running on staging and try out this change, so we have less of a chance of debugging in production.

I posted to #3285191-18: [meta] Only support Drupal core installs managed by composer a prominent place we’ll need to update, https://www.drupal.org/download

I tried out the subtree splitter a bit on staging with the diff from the MR. As far as I can tell, it works okay.

The subtree splitter is not a blocker.

I expect more of the parent plan needs to be done before proceeding, this seems like one of the final steps, so leaving this postponed.

Hopefully doing that would not break packaging.

I’d appreciate it if we had a chance to test before potentially breaking packaging.

Since tarballs are still prominently featured on https://www.drupal.org/download, and I haven't seen progress on the parent issue, I didn't think this was moving forward yet.

My comment in #22 here does say this will break packaging, since legacy-project is directly referenced around https://git.drupalcode.org/project/drupalorg/-/blob/2647a1a82a012af30376...

Since tarball packaging is using composer, and is a decent smoke test of subtree splits, we may want to keep it packaging recommended-project instead. The result would still be "composer-ready", so someone downloading it should be able to continue using composer as if they started with composer create-project. We can also hide the resulting tarballs. Or we do skip the step entirely if it is not a useful smoke test.

Found my way here through testing Drupal CMS on shared hosting. Many of the shared hosts provide an automated installer inside CPanel that does a one-click install of Drupal, and now Drupal CMS.

However the addition of Drupal CMS led us to figure out that the vanilla Drupal install is using legacy-project, which is almost certainly to avoid having the /web subdirectory. (Drupal CMS does install with /web, which has obvious and undesired knock on effects in the shared hosting context.)

Just noting this as something we should be aware of if we remove it.

This would slightly improve the security of the Drupal ecosystem.
It is somewhat common for sites using the legacy template to expose files like composer.lock by mistake. The new template hardens this.

The blocker landed.

rebased and it's green now

Updated the CR just to point to 12 but seems like a good removal.

As far as I can see this is still blocked on #29/#30 - we need to either drop tarball packaging entirely or update the packaging code to use drupal/recommended-project instead? However I think an issue with that is alluded to in #30/#31 - shared hosts expect you to unpack everything directly into the webroot, and that isn't as straightforward if the tarball contains the recommended layout (or perhaps even possible on some setups) where index.php is in a subdirectory.

My comments in #29-30 are still a blocker. Before starting that, I’d like to get #3128715: Ensure that dev dependencies are never packaged in dev tarballs out of the way before changing the same area of code for core packaging.

#3578117: Switch core packaging tarball to core-recommended has a draft implementation of the packaging changes to unblock this.

#3128715: Ensure that dev dependencies are never packaged in dev tarballs now has a draft change record for review to get that one out of the way.

Core’s custom subtree splitter is another place to look for blockers. It does mention “legacy” in one place https://gitlab.com/search?search=legacy&nav_source=navbar&project_id=754.... This does look like it needs to be updated.

I threw Claude at it and maybe it did a better job than I could initially: https://gitlab.com/drupal-infrastructure/subtree-splitter/-/merge_reques...

The subtree splitter work is now deployed and I’m not aware of any other hard-coding of “legacy” or other infrastructure blockers.

@drumm I see, so Drupal 12 will package tarballs with recommended-project instead of legacy-project: https://git.drupalcode.org/project/drupalorg/-/blob/7.x-3.x/drupalorg_pr...

I still think this might be problematic for shared hosts where the tarball is expected to be unpacked into the web root, but we have no idea how many people still rely on tarballs of core - it surely can't be that many given Composer is effectively required to manage an install now?