Make WordPress Core

Opened 9 years ago

Last modified 5 years ago

#34233 new enhancement

There is not a body class filter within the customizer.

Reported by: scofennellgmailcom's profile scofennell@… Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.4
Component: Customize Keywords: needs-patch
Focuses: Cc:

Description (last modified by SergeyBiryukov)

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)

customize.diff (506 bytes) - added by scofennell@… 9 years ago.
Patch to add an apply_filters() for the customizer body class

Download all attachments as: .zip

Change History (8)

#1 @westonruter
9 years ago

  • Keywords reporter-feedback added
  • Version changed from 4.3.1 to 3.4

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.

#2 @SergeyBiryukov
9 years ago

  • Description modified (diff)

#3 @scofennell@…
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.

Last edited 9 years ago by scofennell@… (previous) (diff)

#4 @celloexpressions
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 @scofennell@…
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.

@scofennell@…
9 years ago

Patch to add an apply_filters() for the customizer body class

#6 @scofennell@…
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 @dlh
5 years ago

  • Milestone changed from Awaiting Review to Future Release

The patch here needs a couple of adjustments, I think:

  • Also like admin_body_class, I would say the core classes like wp-core-ui should be excluded from the filter.
  • A filter name of customize_body_class, rather than customizer_, might be a little more consistent with actions on the page like customize_controls_init. Perhaps customize_controls_body_class might be yet more consistent.
Note: See TracTickets for help on using tickets.