Twenty Twenty-One: Load different CSS for different WP versions, to be compatible with blocks

[poena]

Twenty Twenty-One was introduced in WordPress 5.6.
It includes CSS for some blocks, but as those blocks were in WordPress 5.6:
This causes styling conflicts as block HTML markup, settings and even block CSS classes are updated over time:

https://core.trac.wordpress.org/ticket/56109
https://core.trac.wordpress.org/ticket/53220
https://core.trac.wordpress.org/ticket/56023

To keep backwards compatibility and work with current and future block styles, we could consider loading different CSS files for different WordPress versions.

Another option would be to update theme for WordPress 6.1 -and increase the minimum required WordPress version and no longer be backwards compatible.
I am not sure if this is acceptable for a bundled theme, and I don't think it has been done before?

[aristath]

Another option would be to update theme for WordPress 6.1 -and increase the minimum required WordPress version and no longer be backwards compatible.

This sounds like a viable option to me... People who don't update their site will likely not keep their theme up to date as well, so if they are on WP 5.7 for example, then everything is fine.
If they update to the latest version of WP, then they'll see the theme version update too - which is what should happen :+1:

[peterwilsoncc]

I'd prefer to maintain support for the older versions of WordPress.

Given the backward compatibility changes in the block-editor; it's possible a site is choosing to remain on an older version of WP while updating themes and plugins.

To keep backwards compatibility and work with current and future block styles, we could consider loading different CSS files for different WordPress versions.

An alternative approach could be to include the mayor version of WordPress in the body classes; wordpress-59, wordpress-60, etc. This would allow for a single file to be maintained rather than a new one for each version of WordPress. Would that be acceptable?

[poena]

With a minimum required version increase, users who do not update WordPress still use the previous version of the theme, so nothing changes for them. Their theme continues to work like today.
They wont see any further breaking of block styles since they will not be able to install the latest version of Gutenberg either.

---

I am not sure I understood the body class suggestion correctly. It may be easier for me if you sketched out the proposed CSS file and file loading structure.

So if I brainstorm freely around this suggestion: Did you mean that if a theme has for example a separate sass file called navigation-block.scss,
that file would include:
.wordpress-58 .wp-block-navigation .old-class-name {style}
.worspress-59. wp-block-navigation .new-class-name-to-match_new_markup {style}
?
And both would be loaded on the front for all WP versions?
I may have misunderstood the intention but I don't think loading all the CSS on pages where only a small portion of the CSS would be used is performant.

I don't mean to sound negative, because I find the suggestion interesting, but wouldn't adding that extra specificity prevent users from changing styles with the block settings? The styles from the settings would have a lower specificicity.

[peterwilsoncc]

@poena Don't worry about sounding negative: you have questions and I am happy to answer them.

With a minimum required version increase, users who do not update WordPress still use the previous version of the theme, so nothing changes for them. Their theme continues to work like today.

That's true.

However, there have been security issues in default themes in the past (fixed in WP 4.4.2) so been able to update the themes for users on older versions of WP can be helpful.

So if I brainstorm freely around this suggestion: Did you mean that if a theme has for example a separate sass file called navigation-block.scss,
that file would include:
.wordpress-58 .wp-block-navigation .old-class-name {style}
.worspress-59. wp-block-navigation .new-class-name-to-match_new_markup {style}

Yes, that is what I was thinking.

If it's only a few selectors that require special treatment then the performance hit would be negligible.

If it's a significant number of selectors and blocks that require different treatment per version of WordPress then separate files would probably be worth it.

You have a much better understanding of the problem than I, so happy for you to tell me that the answer to my question is "no, the class based approach would introduce other problems and is unacceptable". It's not negative; it's working out the best solution :)

[poena]

Let's say I was using 6.0.1 and theme version 1.6.
In 6.1 the new theme version is 1.7, but since I don't update core I can't activate 1.7.

Would I get the security release if there was a version 1.6.1 published to the theme directory?

[poena]

I will open a PR in the ​theme experiments repo to try some things out.

Perhaps a file structure without the minimum required version increase might look like

twentytwentyone\assets\sass\
   05-blocks
     audio
       _56.scss
       _58.scss
       _style.scss

The build process would need to change.

[peterwilsoncc]

Replying to poena:

Let's say I was using 6.0.1 and theme version 1.6.
In 6.1 the new theme version is 1.7, but since I don't update core I can't activate 1.7.

Would I get the security release if there was a version 1.6.1 published to the theme directory?

Good question, I'll confirm with the meta folks.

Based on my reading of the code, it seems unlikely 1.6.1 would be offered but I am not an authority on how the WordPress update APIs work & how they choose what data to present.

[dd32]

Replying to peterwilsoncc:

Replying to poena:

Let's say I was using 6.0.1 and theme version 1.6.
In 6.1 the new theme version is 1.7, but since I don't update core I can't activate 1.7.

Would I get the security release if there was a version 1.6.1 published to the theme directory?

Good question, I'll confirm with the meta folks.

Based on my reading of the code, it seems unlikely 1.6.1 would be offered but I am not an authority on how the WordPress update APIs work & how they choose what data to present.

@peterwilsoncc is correct here, The WordPress.org Plugin & Theme directories only know about the latest release of a plugin/theme, in the event that a theme increases it's minimum WP or PHP requirements in a newer release, older sites would cease to receive update notifications - even to a newer (but older) version that does support their site.

This is unfortunate, but is a technical simplification of the way the directories work. If in the future a Security release of a default theme was required, we could override this though (see below) and make it happen.

It should be noted, that Plugin Security releases which are done as "forced pushes" (ie. the WordPress.org Security team / Plugins team decide to enable automatic updates for the release) can override this, and in the past have statically defined the versions for a plugin - ie. 5.0 is the latest release, all 4.x-5.0 sites get autoupdated to 5.1 which requires WP >= 5.0, and all 2.0-3.9 sites get updated to 3.9.1 which supports WP < 5.0 and is as secure as version 5.1.
(Note: I've said Plugin here, as that's what we've got the most experience with, but it applies equally to themes)

[poena]

For anyone reading this 4 months later, I never managed to do the planned experiments or submit them to the theme experiments repository.

This ticket is still open to any suggestions.