Remove Classy from core

At first I thought this was duplicate with #3050378: [meta] Replace Classy with a starterkit theme but I see you propose this as an independent step. Adding that as the parent to make this relationship more explicit.

Thanks,
-Derek

When removing a module from core, the composer facade will have to deal with namespace collisions.

If we keep the project machine name the same, then there will be a namespace "drupal/classy" that refers to the theme that was available in core, and the composer facade will automatically assign a name of "drupal/classy-classy" to the contrib version of this theme.

Right now, I cant find any evidence of any projects with an existing dependency on drupal/classy so we might be safe to swap the namespaces so that drupal/core-classy then refers to the old one ( since nobody was really using that.)

But definitely coordinate with the infra team if we want to preserve that namespace.

I think we can start working on this. I filed an issue to do the deprecation #3307241: Deprecate Classy in favor of the new Starterkit Theme.

#4 is being taken care of in #3302966: Ensure that classy doesn't get special core treatment

Sorry, I didn't realize this is assigned to you @Spokje because I had this issue open for a while... I pushed commit to the fork that should handle deleting all references to Classy.

I don't seem to be able to open MR for this 😢

Sorry, I didn't realize this is assigned to you @Spokje because I had this issue open for a while.

Right... That's about 30 minutes I could have spend elsewhere...

Here's a patch because of #14.

@Spokje I think that might not actually be waster time! What you could do is take your commit/patch and compare if it's different from #16. If there are differences, we should look into that. If it's exactly the same, I believe you could mark this as RTBC.

I think it is better to postpone this on #3307454: Move classy related tests to the theme directory/namespace or handle them otherwise, which, upon being committed, will probably mean a reroll for this one.

Added a few missed classy references/tests to the patch.

Left with a few (hopefully mildly annoying) questions:

- We're sure we're doing this on 10.1.x and not on 10.0.x
- What to do with the Classy reference in this help-topic:
https://git.drupalcode.org/project/drupal/-/blob/10.1.x/core/modules/hel...
- What to do with the Classy reference in this comment in Umami and Claro theme:
https://git.drupalcode.org/project/drupal/-/blob/10.1.x/core/profiles/de...
https://git.drupalcode.org/project/drupal/-/blob/10.1.x/core/themes/clar...

Thank you for working on this @Spokje! Here's what I think we should do:

1. We need to do this for both 10.0.x and 10.1.x but the same patch will likely apply for both
2. I think the core.appearance.html.twig help topic could reference Stable 9. I'm wondering if we should update this to also mention the starterkit theme generator?
3. I think we could remove the comment and if condition from umami_preprocess_links__media_library_menu and claro_form_alter

Thanks @lauriii

1. We need to do this for both 10.0.x and 10.1.x but the same patch will likely apply for both

Putting issue version on 10.0.x-dev

2. I think the core.appearance.html.twig help topic could reference Stable 9. I'm wondering if we should update this to also mention the starterkit theme generator?

Swapped out Classy with Stable 9. I think we should mention the starterkit theme generator, but I think that's something for a follow-up issue?

3. I think we could remove the comment and if condition from umami_preprocess_links__media_library_menu and claro_form_alter

Removed them in newly uploaded patch.

1. We should update core/themes/starterkit_theme/css/components/image-widget.css because it has still couple Classy references.
2. Claro has multiple mentions of Classy in comments. Should we update those?
3. I think the Classy reference should be removed from core/themes/olivero/templates/block/block--search-form-block.html.twig

Thank you @bnjmnm! I think all of the remaining mentions of Classy make sense even though Classy has been removed.

Yes, I hate the admin stuff as well, but to be completely sure we've covered all our bases, I've created #3308518: [Meta] Tasks to remove Classy theme from core and move to contrib.

Looks like we need a resplit of the Core theme to the contrib module (I _think_ it's only the two moved tests that are missing in the contrib project now) and manual testing for this issue to be fully ready?

Reparenting

Blatantly copied and edited #3306630: Split the core 9.5.x ckeditor history into a new 1.0.x branch and cut a 1.0.0 release to #3308540: Split the latest core classy history into the 1.0.x branch and cut a 1.0.0 release for #36.

#38: I did the same and used #3260995: Split the core 9.4.x quickedit history into a new 1.0.x branch and cut a 1.0.0 release as a starting point 🤓

Copy-paste-adapt, the cornerstone of every developer 😈

I tagged 1.0.0-rc1 on the Classy contrib project. It would be helpful if someone running theme depending on Classy could manually test the theme with the following steps:

1. Update to Drupal 10.0.0 HEAD
2. Run composer install
3. Apply patch from #34
4. Run composer require drupal/classy
5. Confirm that the theme still works

Tried to test this but this needs a reroll now that #3278415: Remove usages of the JavaScript ES6 build step, the build step itself, and associated dev dependencies has landed

O well, why not do another reroll :)

(Why is there _always_ one thing I forget to update in the first attempt...)

(More relevant, why did I get the reroll wrong...)

Tested #41 using Garland and everything worked as expected! Confirmed that the reroll should be good 👍

I tagged a stable release on the contrib project and opted-in for security team coverage.

Patch looks good - a few references to remove along with the module but mostly docs so makes sense to do it in one go.

Committed/pushed to 10.1.x and cherry-picked to 10.0.x, thanks!