Add default body_class classes for Theme Names

[cais]

Although this may be more pure enhancement and quite possibly Mallory-Everest in nature, the idea of having a default body_class output for the Theme name seems to be a reasonable one.

IF this is implemented it should also include a default class for a Child-Theme name as well as the Parent-Theme name.

To that end, I am suggesting the following patch to the body_class function.

[GaryJ]

What about themes that didn't want the theme name to be exposed in the source?

It's so trivial for themes to add in a body_class value themselves if they need it, that I can't see the value of forcing all themes to show it.

[cais]

The Theme Name (aka theme slug) is already exposed in the path to the Theme's stylesheet ... this doesn't do anything more than add an additional reference for all intent and purpose.

One use for this is allowing plugin specific styles depending on what Theme is active; Multi Site installations come to mind as potential beneficiaries.

[nacin]

The patch calls the expensive get_theme_data() function that reads directly from the file.

In order to implement this, we should use the existing theme slug. Example:

'theme-' . sanitize_html_class( get_option( 'template' ) )

While it's a cool idea, I don't think it's going to be necessary for most use cases.

[GaryJ]

Replying to cais:

The Theme Name (aka theme slug) is already exposed in the path to the Theme's stylesheet

Assuming that the theme doesn't dequeue the default style sheet reference in favour of one that's created in the wp-contents directory (very few would do that, admittedly, but it's still possible to do (as per a theme I'm building at the moment). As such, forcing a theme name to be exposed by a body class isn't being considerate.

If a theme *does* want to play nicely with certain plugins, then it can add it's own class in 5 lines of code, or the plugins can handle providing theme-specific styles if they are providing any styles at all, including detecting the active theme.

[cais]

Replying to GaryJ:

Replying to cais:

The Theme Name (aka theme slug) is already exposed in the path to the Theme's stylesheet

If a theme *does* want to play nicely with certain plugins, then it can add it's own class in 5 lines of code, or the plugins can handle providing theme-specific styles if they are providing any styles at all, including detecting the active theme.

I look at this as more for a third-party to be able to have themes and plugins able to play nicely with each other rather than pushing the theme / plugin authors to differentiate between which ones they will favor and which they will not; but that also takes us into what is becoming a non-related matter.

Again, as I prefaced above, this may be more a Mallory-Everest idea with a working patch that proves it out. If a developer, such as you have chosen to do, wants to "hide" the theme name they can just as easily remove these or any other classes from the body_class output.

[cais]

Replying to nacin:

The patch calls the expensive get_theme_data() function that reads directly from the file.

In order to implement this, we should use the existing theme slug. Example:

'theme-' . sanitize_html_class( get_option( 'template' ) )

While it's a cool idea, I don't think it's going to be necessary for most use cases.

get_theme_data may be expensive but I could not immediately think of another method to resolve the 'child-theme' name. Therefore I used it for both, but using the get_option( 'template' ) approach is definitely better for the Parent-Theme.

[SergeyBiryukov]

Replying to cais:

get_theme_data may be expensive but I could not immediately think of another method to resolve the 'child-theme' name.

'child-theme-' . sanitize_html_class( get_option( 'stylesheet' ) )

[cais]

Replying to SergeyBiryukov:

Replying to cais:

get_theme_data may be expensive but I could not immediately think of another method to resolve the 'child-theme' name.

'child-theme-' . sanitize_html_class( get_option( 'stylesheet' ) )

Doh! I should have known it was that straight-forward.

Note to self: find/create a list of all available values found via get_option.

[cais]

Uses get_option versus get_theme_data

[c3mdigital]

No activity in 20 months and an existing body_class filter. Closing as wont fix. If anyone want to further discuss this please reopen.

[johnjamesjacoby]

With the advent of block themes in WordPress 5.8 and above, I'm reopening this for discussion and future consideration.

My use case is providing CSS in block plugins to target specific themes. This may be to override something weird in the theme, or to make some HTML output blend in better with existing theme styling.

## Description

This PR introduces new classes to the body tag in WordPress themes. The classes wp-theme-<name> and wp-child-theme-<name> (if child theme) are added, where <name> represents the sanitized name of the active theme and child theme, respectively.

## Changes Made

• Added wp-theme-<name> class to the body tag for the current theme.
• Added wp-child-theme-<name> class to the body tag for the current theme (if child theme).

## Screenshots

• For twentytwentyfour theme

• For a child theme named childtheme having twentytwentyfour as parent theme

## Trac ticket: https://core.trac.wordpress.org/ticket/19736

[nirajgirixd]

It's a small ​PR. Could someone please review and either approve or provide feedback?

cc: @nacin, @SergeyBiryukov, @johnjamesjacoby

If these class names are intended to help plugins with theme specific styles, they also need to be present in the Site Editor.
(They are already available in the Customizer preview)

I checked again, neither of the existing body classes are added in the Site Editor. I am not sure why.
It should be treated as a separate issue and not block this update.

[rinkalpagdar]

Test Report

Description

This report validates whether the indicated patch works as expected.

PR tested: ​https://github.com/WordPress/wordpress-develop/pull/7038

Environment

• WordPress: 6.8-alpha-59274-src
• PHP: 8.2.25
• Server: nginx/1.27.2
• Database: mysqli (Server: 8.0.40 / Client: mysqlnd 8.2.25)
• Browser: Chrome 131.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Five 1.0
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Actual Results

1. ✅ Issue resolved with patch.

[audrasjb]

@rinkalpagdar could you please share some details about your tests?

• Which theme did you install? Was it a child theme?
• Which class name did you get inside the <body> tag? Does it contain the theme slug?

Thanks

[rinkalpagdar]

@audrasjb I am using Twenty Twenty-Five 1.0 theme as mentioned in the environment details in the test report with no child theme. I have attached a screenshot of the <body> class I am getting after applying a patch.

[audrasjb]

Self assigning for final review and commit.

[audrasjb]

Alright, let's ship it in 6.8.

[audrasjb]

In 59698:

Themes: Add wp-theme-<name> and wp-child-theme-<name> classes to body_class.

This changeset introduces new classes to the body tag. The classes wp-theme-<name> and wp-child-theme-<name> (when the current theme is a child theme) are added, where <name> represents the sanitized name of the active theme.

Props cais, GaryJ, nacin, SergeyBiryukov, johnjamesjacoby, nirajgirixd, poena, audrasjb, rinkalpagdar.
Fixes #19736.

[audrasjb]

Hmm… would be nice to add some unit tests.
Reopening for follow-up unit test work.

Trac ticket: https://core.trac.wordpress.org/ticket/19736

[mikinc860]

Test Report
This report validates whether the indicated patch works as expected.
Tested Patch: ​https://github.com/WordPress/wordpress-develop/pull/8193

Environment
OS: Windows 11
Web Server: WordPress Playground
PHP: Playground Default
WordPress: 6.8-alpha-20250125.203533
Browser: Chrome
Theme: Twenty Twenty-Five v1.0
Active Plugins: None

Actual Results
✅ Issue resolved with a patch.