Opened 11 years ago
Last modified 23 months ago
#19736 reopened enhancement
Add default body_class classes for Theme Names
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | minor | Version: | 3.3.1 |
Component: | Themes | Keywords: | has-patch 2nd-opinion needs-refresh |
Focuses: | css | 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)
Change History (13)
#2
follow-up:
↓ 4
@
11 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.
#3
follow-up:
↓ 6
@
11 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.
#4
in reply to:
↑ 2
;
follow-up:
↓ 5
@
11 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.
#5
in reply to:
↑ 4
@
11 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.
#6
in reply to:
↑ 3
;
follow-up:
↓ 7
@
11 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.
#7
in reply to:
↑ 6
;
follow-up:
↓ 8
@
11 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' ) )
#8
in reply to:
↑ 7
@
11 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
.
#9
@
10 years 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.
#11
@
23 months ago
- Focuses css added
- Keywords 2nd-opinion needs-refresh added
- Milestone set to Future Release
- Resolution wontfix deleted
- Status changed from closed to reopened
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.
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.