WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 8 months ago

Last modified 8 months ago

#19736 closed enhancement (wontfix)

Add default body_class classes for Theme Names

Reported by: cais Owned by:
Milestone: Priority: normal
Severity: minor Version: 3.3.1
Component: Themes Keywords: has-patch
Focuses: Cc:

Description

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.

Attachments (2)

body-class-defaults.patch (1.7 KB) - added by cais 2 years ago.
revised-body-class-defaults.patch (805 bytes) - added by cais 2 years ago.
Uses get_option versus get_theme_data

Download all attachments as: .zip

Change History (12)

cais2 years ago

comment:1 GaryJ2 years ago

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.

comment:2 follow-up: cais2 years ago

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.

comment:3 follow-up: nacin2 years ago

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.

comment:4 in reply to: ↑ 2 ; follow-up: GaryJ2 years ago

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.

comment:5 in reply to: ↑ 4 cais2 years ago

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.

comment:6 in reply to: ↑ 3 ; follow-up: cais2 years ago

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.

comment:7 in reply to: ↑ 6 ; follow-up: SergeyBiryukov2 years ago

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' ) )

comment:8 in reply to: ↑ 7 cais2 years ago

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.

cais2 years ago

Uses get_option versus get_theme_data

comment:9 c3mdigital8 months ago

  • Resolution set to wontfix
  • Status changed from new to closed

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

comment:10 SergeyBiryukov8 months ago

  • Keywords needs-testing removed
  • Milestone Awaiting Review deleted
Note: See TracTickets for help on using tickets.