Some call it light OCD, some might call it security risk. I just don't like how it throws it all in there, especially template names.

How to only assign page id or even better - slug?

Note that this is in header template, it should output current page's id / slug.

All "professional", high quality WP sites I've examined, doesn't have that kind of mess.

<body <?php body_class(); ?>>


<body class="home page page-id-495 page-template page-template-template-home-slideshow page-template-template-home-slideshow-php logged-in">

Honestly, it's source code. The only people who see it are you and other developers. Anybody casually visiting your website will never know or understand this stuff so really there's no harm keeping it there. Buttttt... if you want to get rid of it you could filter body_class:

function custom_body_class( $classes ) {
    global $post;

    if( isset( $post ) && is_object( $post ) ) {
        $classes = array( "page-{$post->ID}" );

    return $classes;
add_filter( 'body_class', 'custom_body_class' );
| improve this answer | |
  • Maybe that's just paranoia but isn't it better if random people doesn't know the name of templates? Ofcorse there are pros who will get it one way or another but main crowd, casual 15 year old "hackers" who just want to destroy everything around them. – N00b Dec 11 '15 at 19:45
  • 2
    @N00b If somebody has enough access to your system to do anything using $post_ids then they can just loop through and guess. WordPress auto-increments page / post ids automatically 1 by 1. So it's really a non-issue, whether they know a post_id or not guessing would be faster and easier. Plus, at that point you have more to worry about than just posts and pages. – Howdy_McGee Dec 11 '15 at 19:48

"Some" may call this all kinds of things, but that doesn't make "them" correct.

As a "page load" problem, these classes are trivial. They add very few characters to a page.

As a security problem, also trivial. Most have zero security consequence at all-- so what it this is a "page"--, and those that do have only minor consequences and only if the custom template is written very, very poorly. Additionally, most template names can be guessed by thinking about the template hierarchy built into Core, so removing the classes gains you very little. What you've got is something closely related to "premature optimization".

You should also be aware that removing the classes could potentially break formatting provided by themes or plugins, as these can, and reasonable should be able to, depend upon Core classes.

You are also removing admin-bar and logged-in classes, which could effect Core functionality.

However, the body_class filter lets you do what you want. The following will very aggressively remove all but the postid-{ID} class.

function body_class_wpse_211556($classes) {
  $qobj = get_queried_object();
  //   var_dump($qobj); die;
  $classes = array();
  if (!empty($qobj) && is_a($qobj,'wp_post')) {
    $classes[] ='postid-'.$qobj->ID;
  return $classes;
| improve this answer | |

Here's how to filter the body_class(). This will only use the page slug if you have it, (and whatever classes that are added through additional filters in your functions, such as customize-support).

    function wpse211556_body_classes($classes) {
            $slug = strtolower(str_replace(' ', '-', trim(get_bloginfo('name'))));
            $classes[] = $slug;
            return $classes;
    add_filter('body_class', 'wpse211556_body_classes');

Reference: https://codex.wordpress.org/Plugin_API/Filter_Reference/body_class

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.