Add User-Specific CSS Hooks Without Custom PHP
A WordPress site can need a small presentation difference for one particular account without needing a completely different theme or dashboard. A client reviewer may need a prominent project notice, or a developer may want a visual marker that makes an individual test account easy to recognize. The first requirement is a reliable way to identify that account in the page markup. Username Body Class supplies that identification on the body element instead of requiring a custom user-detection function.
For a logged-in account named
project_editor with ID 42, the resulting classes follow the formats user-project_editor and user-id-42. A stylesheet can then target either selector together with the specific page element it should affect. The module does not inject a banner, recolor a dashboard, or hide controls by itself. It provides the connection between the active WordPress account and CSS rules you deliberately create for that account.Choose a Username or User-ID Selector
The two classes give developers different ways to express the same individual-user target. A username-based selector can be easier to recognize when reading a stylesheet, particularly on a small project with a handful of known accounts. The numeric selector is useful when you want the rule to refer to the account ID rather than its login spelling. Both are added together, so you do not need to choose a mode or maintain a list of users in module settings.
The name comes from the WordPress login, not the display name or email address. That distinction matters when an author changes the name shown on articles: the module is not designed to follow that public byline. Conversely, changing the actual login name changes the username-derived selector. On sites using Username Changer, review username-based CSS after a rename or use the ID-based selector for rules that should remain tied to the same account.
Use the Same Approach on the Frontend and in wp-admin
User-specific presentation can be useful in more than one part of WordPress. A frontend account area may need a notice for a particular reviewer, while an administrative interface may need a visual cue for a known editor or testing account. Username Body Class works with both WordPress body-class mechanisms, giving you a consistent naming pattern without creating two separate user-identification snippets.
The surrounding styles still need to suit the area where they run. A selector written for a frontend component does not automatically style an equivalent dashboard component, and the module does not load your custom stylesheet for you. Its job is to add the account classes where WordPress produces the relevant body markup. You retain control over the CSS, the elements it targets, and whether a presentation change belongs on the frontend, in wp-admin, or in both places.
Combine Individual and Role-Based Presentation
An individual account rule is useful for an exception, but it is not always the right foundation for an entire team. If every editor should receive the same visual treatment, maintaining separate selectors for each editor would create unnecessary work as staff join or leave. User Role Body Class adds role-based selectors for that broader requirement and can work alongside Username Body Class.
For example, a general role selector can establish the appearance used by the editorial team, while a user-ID selector adds a specific reminder for one review account. If a class should apply to the whole public website regardless of who is signed in, Custom Body Class handles that different scope. Choosing the appropriate level keeps the stylesheet easier to maintain instead of using individual usernames for every site-wide or role-wide decision.
Keep Styling Separate From Access Control
A body class changes what your CSS can target; it does not change what the WordPress account is allowed to do. Hiding a button or section with an account-specific selector does not remove the underlying data, deny a direct request, or replace a capability check. Username Body Class is therefore suited to visual distinctions and interface adjustments, not protecting private content or preventing an administrator from reaching a sensitive action.
The account identifier also becomes visible in the HTML sent to that viewer. The module adds no such classes for guests, but a cache that incorrectly shares logged-in HTML could expose one user's login and ID in another visitor's response. Keep personalized page caching separated appropriately and consider whether publishing these identifiers in the current user's markup fits the project. The module is an explicit styling convenience, not a username-obfuscation feature.
