Problem/Motivation

Classy will be deprecated in Drupal 9 and moved to contrib prior to the Drupal 10.0.0 release. Source: https://www.drupal.org/node/3103178
Core themes no longer have their base themes set to Classy and have copied over Classy templates & CSS. (https://www.drupal.org/project/drupal/issues/3050389)

Proposed resolution

Set the theme's base theme to 'false'.

User interface changes

Removing Classy without copying over its templates and CSS will most likely not affect the base theme. (This is currently being tested here with the unchanged child theme that ships with this theme: https://test-uswds.pantheonsite.io/ ) However it is very likely to cause breaking changes to child themes that might have inherited Classy's templates and CSS.

What is the best approach for this task?

Issue fork uswds-3240834

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

Irisibk created an issue. See original summary.

brockfanning’s picture

brockfanning commented

What jumps to mind for me is to start a 3.0 branch. By making it a major version it's more "OK" to have breaking changes like this. I don't want to cause extra burden on the maintainers though, by having multiple versions simultaneously.

I would wonder if this change will have any ripple effects that cause the codebases to diverge a lot. For example, if we keep 2.0 with Classy and 3.0 without Classy, is the difference between them going to stop at the removal of that one line of code? Or is 3.0 going to need other tweaks to make up for the loss of Classy, which 2.0 would not need? If the divergence stops at the single line of code, maintaining both versions sounds feasible. But as they diverge I think it would become harder to maintain both.

Irisibk’s picture

Irisibk commented

I agree, it's a good idea to start a 3.0 branch.
Good point about maintaining both branches. If we intend to recommend using the 3.0 branch for Drupal 9 (not the 2.0), then we will probably not have much divergence between both branches.

However, if we want to also make it possible to use the 2.0 branch in Drupal 9 sites, we would need to copy over Classy templates(and CSS/JS too) into that branch so it continues to work as expected in D9 when Classy is no longer in core.

brockfanning’s picture

brockfanning commented

Is there any mechanism for adding a separate contrib theme as a base theme?

Irisibk’s picture

Irisibk commented

I think there is. I haven't tried this but if a contrib theme is added as the base theme, I believe it's possible to create a composer.json file and add the contrib theme as a dependency.

brockfanning’s picture

brockfanning commented

Ok, that sounds a lot more maintainable than copying in the files. Maybe we could document how to do that, assuming it works.

jrglasgow’s picture

jrglasgow commented

My recommendation would be to not start a 3.x branch just for this. I would keep the 3.x version of the theme to be in sync and compatible with USWDS 3.xm the it should be easier for everyone to understand which version of USWDS the them goes with.

brockfanning’s picture

brockfanning commented

That's a great point.

I'll give a try to removing classy and report back on how it goes.

brockfanning’s picture

brockfanning commented

Finally reporting back after trying it out - for an existing D9 site I wrote a local patch to set "base theme" to "false" instead of "classy", and also remove the line about "classy/base" under libraries-override. I did notice some issues, but so far all of the issues have been related to site-specific CSS that was targeting classy classes. For example with classy the region divs get classes, and the developers of the site I was testing had targeted those classes in their CSS. So, that just confirms what I guess was obvious - removing Classy has the potential to affect existing sites.

It seems like new sites should be fine though. We'd just want to confirm that none of the classes in our CSS file are generated by Classy: https://git.drupalcode.org/project/uswds/-/blob/8.x-2.x/css/style.css

Also judging from the description of the contrib Classy project, it sounds like it should be easy for sites in this predicament to use it in D10, to keep backwards compatibility. So there would definitely be a fairly easy upgrade path.

The only awkward thing is that, if we're going to stick with the USWDS major version and we wanted to do this during 2.x then we would have to release a (potentially) breaking change without bumping our major version. However now that USWDS 3 is out - maybe we *can* do this in a 3.x branch, and make this change at the same time as supporting USWDS 3?

jrglasgow’s picture

jrglasgow commented

I would suggest making the change with the move to USWDS 3.x - also suggest moving to semantic versioning at that time. I know whenever any of the modules I use moved to Semantic Versioning I check the release notes carefully to see if there is anything potentially breaking compatibility so it would definitely be a good time to drop the Classy base theme.

coolestdude1’s picture

coolestdude1 commented

As an FYI I just wanted to post this here for informational purposes but for some this dependency is a Drupal 10 upgrade blocker. I have found that the easiest way to move into Drupal 10 before this dependency change is made from this ticket's work is to install 'Classy' AND 'Stable' (Classy's base theme is Stable) as contributed themes. This will allow the current version of the USWDS's theme to be installed in Drupal 10.

https://www.drupal.org/project/classy
https://www.drupal.org/project/stable

Even though these themes have been removed from core they can still be side loaded leading to a successful Drupal 10 upgrade even with USWDS dependency requirements.