WordPress body_class Example: Add Context-Aware Theme Classes

Last reviewed: April 25, 2026

The body_class() system is one of the simplest ways to make a WordPress theme context-aware without scattering request logic through templates. The risk is that developers often overstuff it with unstable or user-controlled values, then create CSS and JavaScript selectors that are hard to reason about.

This guide shows how to add deliberate body classes through the body_class filter so your theme can react to request state cleanly without polluting markup.

Add classes through the filter

<?php
add_filter( 'body_class', 'vulnwp_add_context_body_classes', 10, 2 );

function vulnwp_add_context_body_classes( array $classes, array $css_class ) {
	if ( is_singular( 'post' ) ) {
		$classes[] = 'vulnwp-reading-view';
	}

	if ( is_page_template( 'templates/landing-page.php' ) ) {
		$classes[] = 'vulnwp-landing-page';
	}

	if ( is_user_logged_in() ) {
		$classes[] = 'vulnwp-user-authenticated';
	}

	return array_unique( $classes );
}

The callback must return the class array. Forgetting that return wipes out WordPress core classes and can quietly break styling across the site.

Use stable class names

Body classes should describe layout or state, not volatile values. A stable class like vulnwp-reading-view is useful. A class generated from unreviewed user input is not.

if ( is_archive() ) {
	$classes[] = 'vulnwp-archive-view';
}

Keep naming consistent and prefixed. That prevents collisions with plugin or theme framework classes.

Connect layout decisions without template sprawl

Body classes work especially well when a theme needs a small visual variation across page groups but does not need separate template files for every case.

body.vulnwp-reading-view .site-header {
	border-bottom: 1px solid rgba(17, 24, 28, 0.08);
}

body.vulnwp-landing-page .site-navigation {
	display: none;
}

This keeps request detection in PHP and presentation decisions in CSS, which is usually easier to maintain than stuffing conditions directly into every template partial.

Production checklist

• Use the body_class filter for deliberate, prefixed state classes.
• Return the full class array from the callback.
• Prefer stable layout/state names over dynamic values.
• Keep security-sensitive values out of body classes.
• Use classes to support theme variations, not to hide broken template structure.
• Test key routes after adding or removing classes.

Common mistakes

• Not returning the array. That can strip core body classes entirely.
• Adding unprefixed generic names. Collisions are common in WordPress themes.
• Encoding user input in class names. That creates messy selectors and can leak private state.
• Using body classes instead of the right template. Large structural differences still need proper templates.
• Overcoupling JavaScript to visual classes. Layout hooks and behavior hooks should stay intentional.

Related reading

If the request-specific layout should use a different template entirely, read the template hierarchy article. If access control decides whether the page should even render, pair this with the template_redirect guide.

References and further reading

• WordPress Code Reference: body_class()
• WordPress Code Reference: body_class filter
• WordPress Code Reference: get_body_class()