TruAnon Identity vs WP Firewall

You have profiles. This lets members bring their own confidence of identity to them, and choose how others see and share it. It amplifies a profile. When identity carries weight, members do more of whatever they came to do — and do it more safely. It is voluntary. Members use it because the platform makes it worth using. What shows is theirs to set, and theirs to withdraw at any time, everywhere at once. Confidence of identity is built from a public history that cannot be assembled on demand. Where it is visible, a fraudster gains nothing and carries more risk, and moves on to a less trusted platform. The community sorts itself, without rules or moderation. It is automatic and continuous. Members keep it current by being who they are. The site stores nothing that identifies anyone — a rank, a score, an image address. Everything else is read live when viewed and never written down. Where badges appear Beside member names on comments and post bylines — classic and block themes On the member’s profile (the author page): badge, title, and granted details On UsersWP member profiles and in the members directory — no code Anywhere else via the [truanon] shortcode, the [truanon_card] profile card, or the Badge block [truanon_settings] places the member panel on any front-end page for membership sites What it costs your server Badges render from cached rank and score; no page waits on an API. Styling is self-contained — no Bootstrap, no icon fonts — and every color is a CSS custom property (--truanon-*) a theme can override. Using it with a membership plugin Community plugins render their own profile pages and member directories. WordPress core never fires its author or comment hooks there, so TruAnon reaches them either natively (UsersWP) or with a one-line snippet (everything else). UsersWP — nothing to add. The badge places itself on member profiles and in the members directory (there as a compact rank-colored check, rendered from cache with no per-member API call). On their own profile the owner also sees a Verify / Manage bar that opens their identity panel (anchor + privacy switches). It is on as soon as you enter your key; the setting on the TruAnon admin screen turns the member control off if you’d rather place it yourself. If you ran an earlier version with a [truanon_verification] profile snippet, remove it after updating so the badge isn’t drawn twice. Other plugins (BuddyPress, Ultimate Member, bbPress) — one snippet. Pick the piece you want with a shortcode — [truanon] (pill), [truanon size="inline"] (just the check, no API call), or [truanon_card] (full card); each accepts user="login-or-id" — and place it from your plugin’s profile hook. For BuddyPress, in your theme’s functions.php or a code-snippets plugin: add_action( 'bp_before_member_header_meta', function () { echo do_shortcode( '[truanon_card user="' . bp_displayed_user_id() . '"]' ); } ); Then give those members a place to manage their identity, since they never open wp-admin: put [truanon_settings] on a front-end page (or profile tab). It shows the visitor their own badge and a Verify / Manage button with every privacy switch. (On UsersWP this is the inline switch above, so the shortcode is optional there.) Upgrading from 1.x / 2.x? The old [truanon_verification userid=".." username=".."] shortcode still works. It now renders the current design — an inline check in a members list, the full card on a profile — so existing placement snippets keep working with no edits. Pass size="inline", size="large", or size="card" to force one specific piece. For developers and AI assistants Placement is automatic on stock WordPress (comment authors, post bylines, author archives) and on UsersWP (member profiles and the members directory). On any platform without native support — BuddyPress, Ultimate Member, bbPress, a custom theme — place it explicitly with the surface below. How fetching works (the model): a badge paints from a small per-user cache — rank, score, color — so no page ever waits on the API. TruAnon is called live only when the full badge/card is shown and the member’s identity switch is on; never for a list/inline check, and never for a member who has not turned it on. Each successful call refreshes the cache; the list checkmark reads that cache and never calls out. The call is not gated on a stored “anchored” flag — whether a member is anchored is what the call returns, and it is recorded as a result, never required as a precondition. Shortcodes: [truanon user="login-or-id" size="large|inline"] — the badge. inline is a small check with no API call, for lists. [truanon_card user="login-or-id"] — the profile card: badge and the details the member has granted, read live. [truanon_settings] — the member’s own Verify / Manage control with privacy switches, for front-end membership sites. [truanon_verification userid=".." username=".."] — legacy 1.x / 2.x alias; context-aware. Template tag (PHP): truanon_badge( $user = 0, $size = 'large' ) — $user is a user ID, login, or WP_User; $size is large or inline. Block: “TruAnon Badge” (truanon/badge), attributes user and size. Filters: truanon_userswp_render_badge ( bool, int $user_id ), truanon_inline_manage ( bool ), truanon_inline_link ( string $url, int $user_id ), truanon_absent_text ( string, int $user_id ). To integrate a profile plugin without native support: hook that plugin’s action after the profile name or header and echo truanon_badge( $id ) or do_shortcode( '[truanon_card user="' . $id . '"]' ) on the single profile. In a member directory or loop, use the inline size so each row renders from cache with no per-member API call. Members who never open wp-admin get their own controls from a [truanon_settings] mount on a front-end page.

Do you like the WP Firewall plugin? Leave a 5 star review to recommend it to other users. This plugin adds a set of protection rules to the .htaccess file of your WordPress site. These rules totally protect the CMS from hacker attacks. This is a BETA version, if you find bugs or malfunctions contact the developer from the support section. WP Firewall requirements Apache web server ModRewite SSL connection (https) WP Firewall development functions This plugin uses only functions contained in the CMS core. Do you need other functions? Ask the developer from the support section. If after activating the protection errors or white screens occur, access the .htaccess file and remove all the code between “# BEGIN Firewall” and “# END Firewall”. WP Firewall credits The “WP Firewall” plugin was entirely designed and created by Andrea De Giovine (thought by @riccardobastillo1). If you like the idea and want to support the developer, please donate to this plugin. For collaborations and consultations visit the website of the freelance web developer. For bug reports and support for this plugin, visit the support section to ask the developer and the community directly.