Make WordPress Core

Opened 20 months ago

Closed 3 weeks ago

#56130 closed enhancement (wontfix)

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

Reported by: poena's profile poena Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Bundled Theme Keywords:
Focuses: css Cc:

Description

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?

Change History (14)

#1 @poena
20 months ago

  • Type changed from defect (bug) to enhancement

#2 @aristath
20 months ago

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:

This ticket was mentioned in Slack in #core-themes by poena. View the logs.


20 months ago

#4 @peterwilsoncc
20 months ago

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?

#5 @poena
20 months ago

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.

#6 @peterwilsoncc
20 months ago

@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 :)

#7 follow-up: @poena
20 months ago

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?

#8 @poena
20 months ago

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.

#9 in reply to: ↑ 7 ; follow-up: @peterwilsoncc
20 months ago

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.

This ticket was mentioned in Slack in #meta by peterwilsoncc. View the logs.


20 months ago

#11 in reply to: ↑ 9 @dd32
20 months ago

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)

Last edited 20 months ago by dd32 (previous) (diff)

This ticket was mentioned in Slack in #meta by dd32. View the logs.


20 months ago

#13 @poena
16 months ago

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.

#14 @poena
3 weeks ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.