Opened 18 months ago

Closed 18 months ago

Last modified 18 months ago

#19460 closed enhancement (wontfix)

Move filter for 'admin_body_class' to make it accessible for scripts and other stuff

Reported by: F J Kaiser Owned by:
Priority: normal Milestone:
Component: General Version:
Severity: normal Keywords:
Cc: 24-7@…

Description

Currently this is what the body for the admin interface looks like:

<body class="wp-admin no-js <?php echo apply_filters( 'admin_body_class', '' ) . " $admin_body_class"; ?>">

This is makes it impossible to do the same as you can do to public template pages:

return " onload='init();'";.

Moving the filter behind the var, would make it an easy one-liner.

Change History (18)

onload='init();' != CSS class

Doesn't make sense to me.

comment:2 follow-up: ↓ 4   azaozz18 months ago

And is a bad way of doing things in general. onload='init();' = jQuery('body').load(init);

  • Keywords close added

comment:4 in reply to: ↑ 2 ; follow-up: ↓ 5   F J Kaiser18 months ago

  • Keywords close removed

Replying to azaozz:

And is a bad way of doing things in general. onload='init();' = jQuery('body').load(init);

Your personal opinion.

Anyway: It should be

<body class="<?php echo add_cssclass( apply_filters( 'admin_body_class', '' ), "wp-admin no-js {$admin_body_class}" ); ?>">

comment:5 in reply to: ↑ 4 ; follow-up: ↓ 6   nacin18 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

Replying to F J Kaiser:

Replying to azaozz:

And is a bad way of doing things in general. onload='init();' = jQuery('body').load(init);

Your personal opinion.

No, not even close. It's called unobtrusive JavaScript.

comment:6 in reply to: ↑ 5   F J Kaiser18 months ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

Replying to nacin:

No, not even close. It's called unobtrusive JavaScript.

Even if so, the ticket is about more than that line. Adding a filter for body classes and then not allowing to filter the actual classes is non sense.

Suggested change:

<body class="<?php echo add_cssclass( apply_filters( 'admin_body_class', $admin_body_class ), 'wp-admin no-js' ); ?>">
Last edited 18 months ago by F J Kaiser (previous) (diff)
  • Milestone set to Awaiting Review

comment:8 follow-ups: ↓ 9 ↓ 10   scribu18 months ago

I agree that you should be able to remove certain classes through the 'admin_body_class' filter, not just add more.

Last edited 18 months ago by scribu (previous) (diff)

comment:9 in reply to: ↑ 8   F J Kaiser18 months ago

Replying to scribu:

I agree that you should be able to remove certain classes through the 'admin_body_class' filter, not just add more.

Great to see people sharing that thought.

comment:10 in reply to: ↑ 8   azaozz18 months ago

  • Keywords close added

Replying to scribu:

Why would you remove default classes from there? Even if not used in core on the particular screen, other plugins may be using them, so one plugin would be breaking another.

It seems the filter was meant only for adding classes, not filtering or removing them for exactly that reason.

  • Keywords close removed

A plugin can already remove classes added by other plugins:

function im_a_nasty_plugin() {
  return 'only-mine';
}
add_filter( 'admin_body_class', 'im_a_nasty_plugin' );

Correct would be of course:

function im_a_nice_plugin( $classes ) {
  $classes .= ' me-too';

  return $classes;
}
add_filter( 'admin_body_class', 'im_a_nice_plugin' );

If the intention really was to only allow adding classes, it should have been an action, not a filter.

A plugin can already remove classes added by other plugins:

There's a difference between removing plugin-added classes and removing WordPress required admin classes (ie. .no-js, although I don't think we use .wp-admin)

comment:13 follow-up: ↓ 14   scribu18 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from reopened to closed

I guess you're right. I can't think of a good use-case for removing those classes.

And the original use-case for allowing onscript() attributes etc. is totally wrong.

Therefore, closing.

comment:14 in reply to: ↑ 13   F J Kaiser18 months ago

Replying to scribu:

I guess you're right. I can't think of a good use-case for removing those classes.

And the original use-case for allowing onscript() attributes etc. is totally wrong.

Please read the title. This was just an example (and not the best).

comment:15 follow-up: ↓ 16   scribu18 months ago

Please give a better example, then, keeping in mind that the name of the filter is 'admin_body_class'.

comment:16 in reply to: ↑ 15   F J Kaiser18 months ago

Replying to scribu:

keeping in mind that the name of the filter is 'admin_body_class'.

Maybe that's the problem. The other examples would like to

return " id='page-xy'";
# or: 
return " style='margin: 10px;'";

Anyway, the ticket was written in a way that tried to sum up all possibilities. Maybe some are too much. The following is what I hoped it would be the minimum result:

<body class="<?php echo add_cssclass( apply_filters( 'admin_body_class', "wp-admin no-js {$admin_body_class}" ), '' ); ?>">

add_cssclass should be used only for admin menu or moved out of menu.php.

return " id='page-xy'";
# or:
return " style='margin: 10px;'";

The filter is for body classes to the admin, not additional HTML attributes. It is called 'admin_body_class'. All other uses are invalid.

Pretty much everything you ever want to do can be achievable with either unobtrusive JS or styling using an added CSS class. Wontfix.

Note: See TracTickets for help on using tickets.