Opened 9 years ago
Last modified 5 years ago
#34233 new enhancement
There is not a body class filter within the customizer.
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | 3.4 |
Component: | Customize | Keywords: | needs-patch |
Focuses: | Cc: |
Description (last modified by )
I'm hoping for a way to filter the body classes for the customizer panel.
https://core.trac.wordpress.org/browser/trunk/src/wp-admin/customize.php#L112
My particular use: I happen to have some custom controls on my widgets. I'd like to style them differently for superadmins versus other users. The rest of my application handles this as a body class, and does so in pure php via filtering.
I know that's a pretty specific use, but I do find it surprising that there's not a filter here, given how useful it is in wp-admin and the front end.
If it were to mimic admin body classes, where the classes are a new string, it would look something like
$customizer_body_classes = apply_filters( 'customizer_body_classes', '' ); ?> <body class="<?php echo esc_attr( $body_class ); ?> <?php echo $customizer_body_classes; ?>">
I happen to prefer the front-end treatment, where existing classes are passed in as an array. In that case it would look more like
$classes = array_map( 'sanitize_html_class', $classes ); $classes = apply_filters( 'customizer_body_classes', $classes ); array_unique( $classes ); $classes_str = implode( ' ', $classes ); <body class="<?php echo esc_attr( $classes_str ); ?> ">
I see some objections to a similar ticket here: #32623
But my request is slightly different because I'm not advocating that we re-use the admin_body_class fliter. Rather, I'm suggesting a new filter just for the customizer body class.
This is my first ticket! I would be happy to attempt to make it my first patch as well if there is traction for this enhancement.
Attachments (1)
Change History (8)
#3
@
9 years ago
- Keywords reporter-feedback removed
Thank you for the response, Weston, and for the edit, Sergey (I see what you did there :D ).
To your point, Weston:
"Why not just add the class name directly to widget itself as opposed to the entire body?"
To be clear, I'm talking about custom fields within all of my widgets, not the entire widget. But basically yes, I've done what you suggested in the meantime. I had to modify my css selector to now also handle
.prefix-is_non_priv.prefix-hide_from_non_priv
Whereas elsewhere, I'm able to do
.prefix-is_non_priv .prefix-hide_from_non_priv
The difference being the space between the class names.
"the CSS selectors stay more modularly encapsulated with your widget."
I half agree, half disagree.
In this case it is appropriate for the custom fields to carry my .prefix-hide_from_non_priv
class, since that's what I'm trying to hide. But the condition of the user not being a superadmin is a global condition. I wouldn't want to have to add .prefix-is_non_priv
to every element on the page where that status is relevant. It's much easier to have it as a body class. Indeed, I think there's a reason why core generally leans on body classes instead of putting classes like "home blog logged-in admin-bar" or "wp-admin wp-core-ui js" on every element where they're needed.
#4
@
9 years ago
- Keywords needs-patch added
While my suggestion would be to inject additional body classes with JS, I can't think of particularly compelling reasons not to allow the body class to be filtered in the customize, since WordPress has that everywhere else. However, it could become an issue in the future if the customizer app moves away from being a separate html document, so we may want to avoid it for those reasons.
#5
@
9 years ago
Thank you for commenting on my humble ticket! I'm excited to try writing my first official patch. Should be able to dig into that process this week.
To your point,
"However, it could become an issue in the future if the customizer app moves away from being a separate html document, so we may want to avoid it for those reasons."
If that were to happen, maybe you could still retain the classes on whatever element happens to wrap the customizer app,even if it's just a div instead of a body.
#6
@
7 years ago
Hi! Forgive me, would it be a breach of protocol for me to just assert that I think this is still a valuable and simple ticket?
#7
@
5 years ago
- Milestone changed from Awaiting Review to Future Release
The patch here needs a couple of adjustments, I think:
- The new filter needs docs. Here are the core standards for documenting filters; the docs for
admin_body_class
would be a good guide too.
- Also like
admin_body_class
, I would say the core classes likewp-core-ui
should be excluded from the filter.
- A filter name of
customize_body_class
, rather thancustomizer_
, might be a little more consistent with actions on the page likecustomize_controls_init
. Perhapscustomize_controls_body_class
might be yet more consistent.
Welcome! Thank you for the suggestion.
Why not just add the class name directly to widget itself as opposed to the entire
body
? If you add the CSS class name to a widget wrapper element if the user is a super admin, then the CSS selectors stay more modularly encapsulated with your widget.