Control, secure, and streamline WordPress admin from one modular suite.

Introduction

Polanger Admin Suite is not a single-purpose tweak plugin. It is a modular administration platform designed for agencies, site owners, multisite operators, and product teams that need stronger control over WordPress admin behavior, security, visibility, and workflow. Use it to standardize wp-admin across projects, reduce plugin clutter, and deliver a cleaner, safer, more intentional experience for every user role.

Installation

Method 1: WordPress Admin Upload

1. Download the plugin ZIP file from CodeCanyon
2. Go to Plugins → Add New → Upload Plugin
3. Choose the ZIP file and click Install Now
4. After installation, click Activate Plugin

Method 2: FTP Upload

1. Extract the plugin ZIP file
2. Upload the polanger-admin-menu-manager folder to /wp-content/plugins/
3. Go to Plugins in WordPress admin and activate the plugin

Requirements

Menu Manager

The Menu Manager gives you complete control over the WordPress admin menu. Hide items from specific users, rename menu labels, change icons, and reorder items with drag-and-drop.

Menu Hiding

Hide menu items from all users or specific roles. When a menu is hidden, users won't see it in the sidebar.

• Hide from Everyone - Completely removes the menu item from all users
• Hide from Specific Roles - Hide from Administrator, Editor, Author, Contributor, or Shop Manager
• Submenu Support - Hide individual submenu items independently
• Visual Indicators - Red background shows hidden items in the manager

URL Access Blocking

Hiding a menu doesn't prevent direct URL access. Enable URL blocking to completely restrict access.

Renaming & Icons

• Custom Labels - Change any menu item's display name
• 200+ Dashicons - Choose from WordPress's built-in icon library
• Icon Search - Quickly find icons with the search feature
• Original Restore - Reset to original name/icon anytime

Drag & Drop Reordering

Reorganize your admin menu by dragging items to new positions. The new order is saved automatically and applies to all users.

Admin Bar

Customize the WordPress admin bar (toolbar) that appears at the top of your site.

Custom Logo

• Replace WordPress Logo - Upload your own logo (recommended: 20x20px or 40x40px)
• Custom Link URL - Set where the logo links to
• Hide Logo Submenu - Hide items like "About WordPress", "Documentation", etc.

Manage Admin Bar Items

The plugin automatically detects all admin bar items added by WordPress, themes, and plugins.

• Auto-Detection - Finds items from Elementor, WooCommerce, and other plugins
• Hide Items - Click the eye icon to hide any item
• Rename Items - Change the display text of any item
• Frontend Support - Manage items that only appear on the frontend

Custom Links

Add your own links to the admin bar with icons and optional submenus.

Login Page

Secure and customize your WordPress login page with a custom URL, beautiful design, and reCAPTCHA protection.

Custom Login URL

Change the default wp-login.php URL to something unique for added security.

• Custom Slug - Use any URL like /my-login or /secure-access
• Block Default URLs - Redirect wp-login.php and wp-admin to 404
• Permalink Support - Automatically handles trailing slashes based on your settings

Design Options

Create a beautiful, branded login experience with these customization options:

reCAPTCHA Protection

Protect your login page from bots and brute force attacks with Google reCAPTCHA.

reCAPTCHA can be enabled for:

• Login Form
• Registration Form
• Lost Password Form

Activity Log

Track all administrative actions on your WordPress site. The Activity Log is GDPR/KVKK compliant and never stores sensitive data like passwords or email content.

Logged Events

Severity Levels

• Critical - Security-sensitive actions (URL changes, user deletion, password changes)
• Warning - Actions requiring attention (failed logins, plugin deactivation)
• Info - General activity (content changes, logins)

Log Viewer

View and filter logs with a powerful search interface:

• Search - Find by username, action, or object name
• Filter by Action - Show only specific event types
• Date Range - Filter by start and end dates
• Export CSV - Download logs for external analysis
• Pagination - 20 logs per page with navigation

Email Alerts

Get notified when critical events occur:

• Site URL or Home URL changed
• Admin email changed
• User deleted or role changed
• Plugin deleted
• Password changed

Privacy & Retention

• IP Logging - Optional, disabled by default for GDPR compliance
• Auto-Delete - Automatically delete logs after 7, 30, 60, or 90 days
• No Sensitive Data - Passwords, emails, and form content are never logged

Dashboard Widgets

Take control of the WordPress dashboard by managing widgets, hiding admin notices, and creating custom branded widgets.

Widget Visibility

Hide default WordPress dashboard widgets:

• Welcome Panel
• Quick Draft
• Activity
• WordPress Events and News
• Site Health Status

Auto-Hide Third-Party Widgets

Enable this feature to automatically hide all widgets added by plugins and themes. Use the whitelist to allow specific widgets.

Admin Notices

Control the notices that appear at the top of admin pages:

• Hide All Notices - Remove all plugin and theme notices
• Super Admin Exception - Let Super Admins see all notices
• Dashboard Only - Show notices only on the main dashboard
• Log Hidden Notices - Track what notices were hidden

Custom Widgets

Create branded dashboard widgets for your clients or team:

Use Cases:

• Welcome message with agency branding
• Quick links to important pages
• Support contact information
• Training resources and documentation

Custom Admin Menu

Create your own WordPress admin sidebar menus and submenus from the Menu Manager page. This addon is designed for agencies and site owners who need quick access links, custom tool hubs, and client-friendly navigation.

Menu Builder

• Modal-Based Builder - Add new menus using a modern modal UI from Menu Manager
• Main Menu + Submenus - Create a parent menu and unlimited submenu items
• Icon Picker - Select from an expanded Dashicons library
• Menu Position - Control where the custom menu appears in the admin sidebar
• Inline Help Text - Built-in guidance for non-technical users

Targets & New Tab

Each custom menu/submenu can point to an internal admin route or an external URL.

Manage & Edit

• Custom Menus Table - Review all saved menus, targets, and submenu counts
• Edit Button - Reopen modal with prefilled data to update existing menus
• Delete Button - Remove a custom menu and all related submenus in one action
• Duplicate Parent Cleanup - Automatically removes WordPress auto-duplicated parent submenu entries
• Route Safety - Prevents blank fallback pages by redirecting parent/submenu routes to their configured targets

Multisite Control

Multisite Control adds network-wide governance for agencies, developers, and site networks while keeping each module independent and extendable.

Network Defaults

• Define global defaults from Network Admin
• Capture a site's current module settings as reusable network defaults
• Apply effective settings through lightweight filters instead of duplicating module logic

Site Overrides

• Allow or disable site-level overrides per network policy
• Show Network, Override, and Locked status per module
• Keep local site settings intact unless network policy is enabled

Lock System

• Lock Menu Manager, Admin Bar, Login Security, Activity Log, and Dashboard Center
• Disable local forms when a module is network locked
• Use manage_network_options for network settings and manage_options for site-level controls

Design System

Design System provides token-based admin theming through an addon-first architecture, so visual customization can grow without adding core complexity.

Token-Driven Styling

• Manage primary, background, surface, text, muted, sidebar, and admin bar colors from one screen
• Configure font family and border radius as reusable design tokens
• Generate CSS variables and shared UI styles from saved tokens

Smart Contrast

• Auto-generate readable foreground colors for dark/light surfaces
• Apply scoped readability corrections to postboxes, notices, tables, and form controls
• Enable or disable smart contrast correction from addon settings

Performance & Scope

• Generate cache-friendly CSS files only when token hash changes
• Use inline fallback when filesystem write is unavailable
• Apply styles to Polanger pages only or all admin pages based on selected scope

Comment Security

Comment Security is a layered protection addon for the WordPress comment system. Its job is simple: let normal visitors leave comments as usual, but make automated spam bots, repeated flood attempts, suspicious links, and blocked keywords much harder to get through.

The addon does not rely on just one rule. Instead, it combines several small checks that work together. A comment can be inspected for bot behavior, submission speed, repeated attempts, suspicious content, blocked words, blocked domains, and final risk score. This means you are not betting your entire protection on only one trick such as a honeypot or only one filter such as a keyword list.

For most site owners, the easiest way to use this addon is to enable it and choose a mode such as Light, Balanced, or Strict. After that, you only add your own blocked words or blocked domains when needed. Advanced settings are there for site owners who want tighter control, but you do not need to understand every number on day one to get value from the addon.

General

The General tab controls the overall on/off state of the addon and a few important global behaviors. This is the best place to start if you are setting up the addon for the first time.

• Enable Comment Security Layer - This is the master switch for the entire addon. When this is turned off, none of the bot checks, rate limits, content filters, or silent actions run. WordPress handles comments the normal default way.
• Quick Protection Modes - These modes apply a ready-made protection profile. Light is the least aggressive, Balanced is the recommended everyday option for most sites, and Strict is for sites that receive heavier spam or want faster blocking.
• Also apply to logged-in users - By default, many sites trust logged-in users more than anonymous visitors. Turn this on if you want the same comment screening to apply to members, customers, or other signed-in users as well.
• Enable protection logs - This saves decision records such as allow, spam, trash, or drop so you can later understand what the addon did. If you are troubleshooting false positives or checking how often bots are being blocked, keep this enabled.
• Log retention (days) - This controls how long the addon keeps log entries before deleting old ones. A shorter number keeps the database smaller. A longer number gives you more history for analysis.

Bot Protection

The Bot Protection tab focuses on low-friction defenses that work without forcing the visitor to solve a challenge. These checks try to detect behavior that looks automated rather than human.

• Honeypot field - Adds a hidden form field that normal people never use. Many simple bots try to fill every field they see or manipulate the form payload incorrectly. If that hidden field is filled, or if the payload looks tampered with, the addon treats it as a strong bot signal.
• Honeypot field name - This is the hidden field's name. A realistic-looking name such as url2 or homepage_alt makes it harder for basic spam scripts to identify and skip the trap field. You usually only change this if you want a custom disguise.
• Submission timing check - Measures how quickly the comment was submitted after the form was displayed. Humans need time to read and type. Bots often submit almost instantly or reuse invalid tokens, so this helps catch robotic submissions that move too fast or use tampered timing data.
• Minimum seconds before submit - This is the shortest acceptable time between form load and comment submit. If a comment arrives faster than this limit, the addon assumes the visitor likely did not have enough time to read and type a genuine comment.
• Maximum seconds (token expiry) - This is how long a timing token stays valid before it becomes too old. If someone submits after that window, the token is treated as expired. This helps reduce reuse of old form states and old bot sessions.
• Signed one-time timing tokens - The addon uses signed timing tokens that are tied to the current post and browser fingerprint, and each token is consumed after one successful check. In plain English, this makes it much harder for a bot to grab one token and reuse it again and again.

Rate Limiting

The Rate Limiting tab controls how many comments the same visitor can try to send in a short period. This is very useful against burst spam, repeated abuse, and comment-flood attacks.

• Enable flood control - Turns the rate limit system on or off. When enabled, the addon tracks how often the same visitor submits comments within short and longer time windows.
• Max comments per minute - Sets the short burst limit. If the same visitor posts too many comments inside one minute, the addon starts treating those requests as suspicious.
• Max comments per hour - Sets the longer window limit. This helps catch slower spam waves that stay under the per-minute cap but still post too often over time.
• Why rate limiting matters - A bot does not always post only one bad comment. Many attack scripts try repeated submissions in a burst. Rate limiting helps stop that behavior even if the content itself looks different every time.

Content Rules

The Content Rules tab checks what is inside the comment itself. This is where you define what kind of text, links, words, or domains you do not want to allow.

• Maximum links - Controls how many links a comment is allowed to contain before it becomes suspicious. Spammers often pack comments with promotional URLs, so lowering this number can reduce link spam quickly.
• Penalize comments dominated by non-Latin characters - Adds a score signal when a comment is mostly made up of non-Latin characters. This can help on Latin-only sites that are often targeted by irrelevant spam in other scripts. Do not enable it on multilingual sites unless you are sure it fits your audience.
• Keyword match mode - Chooses how blocked words are detected. Whole word / repeated word mode is the safer and recommended option because it catches a blocked word used normally and also catches the same blocked word repeated back-to-back in spammy strings. Substring mode is looser and can catch more cases, but it can also create more false positives.
• Keyword blocklist - This is where you enter words or phrases you never want to allow in comments. If any listed keyword appears in the author name, comment text, or author URL, the addon treats that as a block rule instead of just a weak score signal.
• URL host blocklist - This is where you list domains you never want commenters to advertise or link to. Use hostnames such as spamdomain.com. If a comment contains a URL from one of those domains, the addon blocks it according to your configured action.
• Why lists do not change the selected mode - Adding words or domains is considered data entry, not a protection profile change. In other words, you can keep using Balanced or Strict mode while still maintaining your own custom keyword and domain lists.

Silent Mode

The Silent Mode tab decides what the addon should do after a comment is judged suspicious enough to stop. This is where you choose the final action.

• Enable behavior scoring - When enabled, the addon combines multiple weaker signals into a final score. This is useful because not every suspicious sign means the same thing. Some comments may only need to go to spam, while stronger signals deserve a harder response.
• Spam threshold (0-100) - If the total score reaches this number, the comment is marked as spam. This is usually the best balance for normal sites because admins can still review the comment later.
• Drop threshold (0-100) - If the score reaches this higher number, the addon uses the selected hard action. This is meant for comments that look much more clearly abusive or automated.
• Mark as spam - Sends the blocked comment to the WordPress spam queue. This is the safest choice if you want a review trail and do not mind checking spam occasionally.
• Move to trash - Sends the blocked comment to trash instead of spam. This can be useful if your moderation workflow is based on the trash queue rather than the spam queue.
• Silently drop - The comment is never stored. From the admin side, this is the strongest cleanup option because junk comments do not pile up in the database at all.
• Show a human-readable rejection page on hard drops - If enabled, visitors see a rejection page when a hard drop happens. This is useful while testing or debugging. On production sites, many admins prefer to leave this off so obvious spam bots get no useful feedback.

Logs & Statistics

The Logs & Statistics tab helps you understand what the addon has been doing in the background. If you want proof that protection is working, this tab matters a lot.

• Statistics cards - Show how many comments were allowed, marked as spam, moved to trash, or dropped over the selected period. This gives you a quick health check without opening individual entries.
• Recent Events table - Lists individual protection decisions with time, action, score, reason, IP, author details, and related post. This helps you see exactly why a comment was blocked or allowed.
• Decision filters - Lets you filter the table by action such as allow, spam, trash, or drop. This is especially helpful when you only want to inspect blocked comments.
• Reason tracking - Stores the reason codes that explain what happened, such as honeypot, timing, keyword, or blocked URL. This is what helps you learn whether your spam problem is mostly bot behavior, flood attempts, or content abuse.
• Clear logs - Lets you remove old protection entries when you no longer need them. Useful during testing or after a major cleanup.
• When to use the logs - If a valid user says their comment disappeared, check the logs first. If your site suddenly receives heavy spam, check the logs to see whether the attacks are mostly link spam, repeated floods, keyword abuse, or timing failures.

Frontend Content Visibility

Frontend Content Visibility is a core content access layer for the public side of your WordPress site. It lets editors decide, per post, page, or supported custom post type, who can see that content and what should happen when an unauthorized visitor tries to open it.

This is not just a redirect toggle. The feature combines per-content visibility rules, global fallback behavior, theme compatibility modes, and discovery controls for archives, search results, REST API responses, and WordPress XML sitemaps.

The normal workflow is simple: an editor opens a content edit screen, chooses the visibility rule from the Content Visibility panel, and optionally overrides the denied behavior for that single item. Site-wide defaults live in the main Polanger settings screen so administrators can define one consistent protection policy.

Visibility Modes

The per-content visibility panel is where you decide the audience for one specific post, page, or custom post type entry.

• Public - Leaves the content fully visible to everyone. No access restrictions are applied.
• Logged-in users only - Visitors must be signed in before they can view the protected content.
• Show only selected roles - Only the roles you explicitly choose can open the content. Other roles and guests are treated as denied visitors.
• Hide from selected roles - Useful when most people may access the content, but one or more roles should be excluded.
• Classic and block editor support - The same rule system is available from the classic editor side metabox and the Gutenberg document sidebar panel.

Denied Behavior

When someone reaches protected content without permission, Polanger can respond in several different ways depending on your chosen policy.

• Redirect to login - Sends the visitor to the WordPress login screen so they can authenticate before trying again.
• Show 404 - Makes the protected content behave like it does not exist for unauthorized visitors.
• Show access denied message - Displays a branded access denied state instead of silently redirecting the visitor away.
• Redirect to custom URL - Sends the visitor to a custom destination such as a pricing page, members-only landing page, or help article.
• Per-content custom message - Editors can override the global message for a single content item and write it with TinyMCE, including HTML and supported shortcodes.
• Homepage fallback - If no custom redirect URL is provided, the system safely falls back to the homepage instead of leaving a broken destination.

Global Defaults

The global settings screen defines the default behavior used when an editor does not override the rule on a specific content item.

• Default denied behavior - Controls the standard response for blocked visitors across the site.
• Default access denied message - Uses a TinyMCE editor so administrators can create a reusable message with formatting, links, HTML, and shortcodes.
• Default redirect URL - Sets the destination that should be used when the denied behavior is a custom redirect.
• Default compatibility mode - Decides whether Polanger should replace only the main content area inside the current theme or force a dedicated full access denied page.
• Default Settings quick link - Editors can jump from the content panel straight to the global defaults in a new tab without searching through the settings menu.

Compatibility & Discovery Control

Restricting access is only part of the job. Polanger also helps prevent protected content from being discovered indirectly.

• Theme-friendly replacement - Keeps the active theme layout and swaps only the content area, which is ideal for standard themes and lightweight site setups.
• Force full access denied page - Uses a stricter standalone response when a builder or custom template might bypass normal content rendering.
• Hide from archives and search - Removes restricted content from public loops, archives, feeds, and search-style frontend queries when enabled.
• Hide from the public REST API - Prevents restricted content from appearing in public API responses that headless frontends or integrations may consume.
• Hide from WordPress XML sitemaps - Stops protected URLs from being listed in native WordPress sitemap output.

Polanger Shield

Polanger Shield is an admin-side control addon for WordPress backends. Instead of making you guess selectors or configure everything from a distant settings screen, it lets an authorized manager open the real admin page, click the floating Shield button, and create the rule directly on the interface that needs to change.

This makes Shield useful when you want to block one plugin page for a specific administrator, protect one screen with Demo Lock, turn the full admin area into a controlled read-only product demo, hide one confusing metabox, or leave an internal note on an exact setting field.

The addon works only inside wp-admin. Its rules are context-aware, user-targeted, and designed to avoid changing unrelated screens.

Rule Types

Access Control

Shield includes its own access-control tab inside Settings -> Shield. This tab decides who is allowed to use the floating Shield tools and manage rules.

• Who can use this addon? - Select which administrator accounts may use the Shield panel, create rules, and open the Shield dashboard.
• Protected admin fallback - One protected administrator is always retained so the site owner cannot accidentally lock every manager out of Shield.
• Send key Shield events to Activity Log - When enabled and the Activity Log addon is active, important Shield events such as rule creation, disabling, and permission changes are forwarded into the centralized activity system.
• Setup reminder notice - If Shield is active but no managers are configured yet, the addon can show a reminder notice so setup is not forgotten.

Page Blocking

The Hide This Page action creates a page-block rule for the current admin screen. This is the strongest action in the addon because it can remove menu access and also stop direct URL access.

• Screen-based targeting - Rules are matched against the current screen context, page slug, page hook, or normalized request URI so the block stays tied to the intended page.
• Selected users only - A page block does not affect every administrator automatically. It only applies to the users selected when the rule is created.
• Optional URL blocking - When enabled, targeted users are not only prevented from clicking the menu item but are also denied if they try to access the page by direct URL.
• Menu cleanup - Matching blocked pages are removed from the admin menu for targeted users where possible, so the UI is cleaner and less confusing.
• Access denied fallback - If a blocked user still reaches the page, Shield stops the request early and shows a clear access denied screen with a safe route back to the dashboard.

Demo Lock

The Lock This Page for Demo action is designed for public or client-facing admin demos where you want people to inspect a screen without being able to change anything important.

• View-only admin screen - The page still loads for the targeted user, but write actions are intercepted so the screen behaves like a protected demo.
• Optional on-page notice - You can show a clear banner explaining that the screen is in demo mode and that changes are intentionally disabled.
• Block standard form submissions - Prevents classic settings forms, editor saves, and similar POST-based admin changes from completing.
• Block likely AJAX save requests - Stops common admin-ajax.php update flows from silently writing changes in the background.
• Block REST write requests - Protects modern interfaces that save through the WordPress REST API, including builder-style or JavaScript-heavy admin screens.
• Friendly blocked-change notice - If the user still tries to save, Shield returns them safely and shows a warning that the change was prevented by Demo Lock.
• Per-screen targeting - The lock applies only on the matched admin screen, so it does not automatically freeze other parts of the admin area.

Global Demo Mode

Global Demo Mode turns the complete WordPress administration area into a controlled read-only demo environment for eligible administrator accounts. It is intended for plugin demos, client walkthroughs, training installations, and other situations where visitors need to explore real wp-admin screens without being allowed to save or perform destructive actions.

Open Settings -> Shield, enable Global Demo Mode, and choose a protection level. Shield then applies the configured protection layers automatically to every administrator who is not a Shield manager. Unlike Demo Lock, you do not create or maintain a separate rule for every screen.

Who Global Demo Mode Affects

Target accounts are calculated automatically from the Shield manager list. This keeps access control in one place and preserves a reliable recovery route.

• Shield managers bypass the mode - Administrators selected in the Shield managers list continue to use wp-admin normally and can change Shield settings or disable the mode.
• Protected recovery administrator bypass - Shield always excludes the protected recovery administrator so the site cannot be left without an unrestricted recovery account.
• Other administrator accounts become demo users - Every remaining eligible administrator account is placed into the read-only session automatically.
• No eligible target means no active mode - If every administrator is a Shield manager or recovery administrator, Shield disables Global Demo Mode instead of presenting a false protected state.
• Safe Mode bypasses enforcement - Shield Safe Mode temporarily bypasses Global Demo protections for troubleshooting and recovery.
• Admin-side scope only - The engine runs for logged-in targeted administrators inside wp-admin and related admin AJAX or REST requests. It does not turn the public frontend into a demo site.

Protection Levels

Global Demo Settings

How Requests Are Protected

• Unsafe screen-load protection - Screens such as post-new.php can create auto-drafts during the initial GET request. Shield redirects affected users before those creator screens reach the write path.
• Dangerous GET action protection - Actions such as activate, deactivate, delete, trash, install, upgrade, switch, and reset are blocked unless explicitly allowed.
• Client-side prevention - Clicks, form submissions, Fetch requests, and XMLHttpRequest writes are intercepted early so the user receives immediate feedback instead of waiting for a failed save.
• Server-side enforcement - PHP hooks independently block classic POST, admin AJAX, and REST writes. The visual disabled state is guidance; it is not the only protection layer.
• Signed transport context - Protected forms and same-origin admin requests receive a user-specific WordPress nonce through hidden fields or request headers. The backend also recognizes valid wp-admin referrers when a request fires before the browser wrapper can attach its token.
• Strict transport backstop - Strict Mode treats targeted users' non-GET AJAX and REST requests as writes even without transport hints, unless the action or route is allowlisted.
• Friendly blocked responses - Browser-side blocks show a toast, AJAX and REST calls receive a 403 response, and classic admin requests return with a clear warning notice.

Allowlist Settings

Allowlists are escape hatches for requests that must remain available during a demo. Add one value per line and keep the lists as small as possible.

• Allowed GET actions - Allows an exact sanitized action name that would otherwise look destructive. Leave this empty unless a known safe admin action is being blocked.
• Allowed AJAX actions - Allows an exact admin-ajax.php action name. WordPress heartbeat is restored automatically as the safe default when the list is empty.
• Allowed REST route fragments - Allows a REST write request when its route contains one of the configured fragments. Because a fragment can match more than one endpoint, use a narrow value and verify the enabled behavior carefully.

Activity, Status, and Recovery

• Active status summary - The Shield dashboard shows the Global Demo Mode summary only while protection is genuinely active and at least one administrator is affected.
• Blocked event channels - Shield records the blocked channel, such as screen load, GET action, POST, AJAX, REST, database, mail, HTTP, or upload, when Admin Activity Log is active, its logging switch is enabled, and Shield event forwarding is enabled.
• Strict database logging safeguard - When Strict Mode is blocking database writes, Shield deliberately avoids persistent activity logging because writing the log would conflict with the protection it is enforcing.
• Recovery access - Shield managers, the protected recovery administrator, temporary Safe Mode, and the server-side POLANGER_SHIELD_DISABLE constant provide separate routes for reviewing or disabling protection.

Scope and Technical Limits

Global Demo Mode is a layered WordPress demo guard, not a virtual machine, database snapshot, or complete operating-system sandbox. Balanced Mode blocks common WordPress write paths. Strict Mode adds deeper WordPress-level backstops, but third-party code that opens its own database connection, writes files directly, calls raw network libraries, or bypasses WordPress APIs may operate outside these hooks.

For a public demo, test every important workflow with the actual demo account. For especially sensitive installations, combine Shield with an isolated staging site, restricted outbound services, and a scheduled snapshot or reset process.

Element Hiding

The Select & Hide Area action is for partial interface cleanup. Instead of blocking the whole page, Shield lets you click the exact element you want to hide and stores a selector for that location.

• Live screen selection - Managers choose the target by clicking the real admin element, which is usually faster and safer than writing CSS selectors by hand.
• Selector generation - Shield tries to create the strongest selector it can, preferring IDs and unique attributes before falling back to broader DOM paths.
• Per-screen behavior - The selector is applied only on the matched admin screen, so hiding one panel on one page does not automatically hide similar markup everywhere else.
• User-targeted cleanup - You can simplify the screen for some administrators without affecting the people who still need that interface block.
• Good fit for plugin-heavy dashboards - This is especially useful when third-party plugins add boxes, upsells, or controls that some users do not need to see.

Contextual Notes

The Leave Note action attaches an internal note to a specific admin element. Shield then displays a visible note marker near that element for the selected users.

• Element-specific notes - Notes are attached to one chosen area, so the guidance appears exactly where the user needs it instead of being buried in a generic help page.
• Visible users list - Notes are shown only to the users selected in the note rule. This is useful for internal training, handoff instructions, or client-safe guidance.
• Clickable marker and popover - Users can click the note marker to open a readable note panel without changing the underlying admin page layout.
• Context menu for managers - Managers can quickly disable or inspect note rules from the note marker itself, which helps with fast cleanup during testing.
• Non-destructive guidance - Notes do not block the page. They simply add structured context to the existing interface.

Rule Dashboard

The Shield dashboard is the central place for reviewing and maintaining saved rules after they have been created from live admin screens.

• Rule list with type and target - Each record shows whether it is a page block, demo lock, element hide, or note rule, plus the matched screen or selector.
• User visibility summary - The dashboard shows which users are affected by each rule so access changes stay auditable.
• Test mode links - Managers can open a rule target in test mode to highlight the matched area and confirm that the selector still points to the expected element.
• Disable and delete actions - Rules can be disabled temporarily or deleted entirely, either one by one or through bulk actions.
• Focused review flow - Dashboard links can open a rule in context so the manager can inspect and verify it quickly.

Safe Mode & Recovery

Because Shield can hide pages and interface areas, it also includes recovery paths to reduce lockout risk.

• Temporary Safe Mode - Managers can open admin pages in a temporary safe mode so page-block and other enforcement rules can be bypassed while troubleshooting.
• Protected admin requirement - Shield always keeps one protected administrator in the manager path so there is a reliable recovery account.
• Constant-based emergency bypass - Developers can disable Shield blocking through a server-side constant when deep recovery is needed.
• Recommended rollout - Start with a small set of rules, test with one target user, then expand once the result is confirmed.

Authenticator App (TOTP)

The Authenticator addon adds Google Authenticator and Microsoft Authenticator support to the core 2FA system. Instead of receiving codes via email, users verify their identity using time-based one-time passwords (TOTP) generated by their authenticator app.

This method provides stronger security than email-based verification and works offline without requiring email delivery.

Multi-User Architecture

The authenticator system is designed for multi-user WordPress installations. Each user has their own authenticator setup, and the system separates global policy settings from individual user enrollment.

Global Settings (Admin Panel)

• Role Enforcement - Select which user roles require 2FA (Administrator, Editor, etc.)
• 2FA Method Selection - Choose between Email or Authenticator App
• Lockout Policy - Configure maximum attempts and lockout duration
• Super Admin Control - Option to include or exempt Super Admin from 2FA requirements

Per-User Enrollment

• Individual Secret Keys - Each user has their own unique encrypted secret
• Profile Page Management - Users manage their 2FA from their profile page (Users → Profile)
• Enrollment Status - Admins can view enrollment status of users without seeing their secrets
• Privacy Protection - Admins cannot view other users' secret keys, only their enrollment status

Enrollment Flow

When a user's role requires 2FA and they haven't set up their authenticator yet, they are guided through a mandatory enrollment process on first login:

1. Login with Password - User enters their username and password as usual
2. Enrollment Required Screen - System detects unenrolled user and shows setup wizard
3. Add to Authenticator App
   • Secret key is displayed for manual entry
   • Provisioning URI available for QR code tools
4. Verify Setup - User enters the 6-digit code from their app
5. Recovery Keys - 10 recovery keys are generated and displayed (one-time viewing)
6. Access Granted - User confirms they saved their keys and gains access

Profile Page Management

After initial enrollment, users can manage their authenticator from their WordPress profile page:

For Own Profile

• View Status - See if authenticator is active or needs setup
• Generate New Secret - Rotate to a new secret key (uses safe pending system)
• Disable Authenticator - Remove authenticator from account
• Recovery Key Count - See how many recovery keys remain

Admin Viewing Other Users

• Enrollment Status Only - See if user has configured authenticator
• Recovery Key Count - View remaining recovery keys
• No Secret Access - Cannot view or modify user's secret key (privacy protection)

Safe Secret Rotation

When generating a new secret key, the system uses a "pending secret" architecture to prevent accidental lockouts:

Rotation Flow

1. Generate New Secret - Creates a "pending" secret, old secret remains active
2. Add New Secret to App - User adds the new secret to their authenticator
3. Verify New Secret - User enters code from the new secret
4. Activation - On successful verification:
   • Pending secret becomes active
   • Old secret is removed
   • New recovery keys are generated (security context changed)
5. Cancel Option - User can cancel rotation at any time, keeping their existing setup

Why Pending Secrets Matter

• No Accidental Lockout - If user abandons rotation midway, old authenticator still works
• Phone Change Safety - Safe process for migrating to a new device
• Recovery Context - New recovery keys generated because security context changed

Secret Key Security

• Encrypted Storage - Secret keys are encrypted at rest using AES-256-CBC (OpenSSL) or HMAC-based XOR keystream fallback
• Unique Per User - Each user has their own unique 32-character Base32 secret
• Key Derivation - Encryption keys derived from WordPress auth salts
• MAC Verification - HMAC-SHA256 integrity verification prevents tampering

Recovery Keys

When you complete authenticator setup, 10 recovery keys are automatically generated. These keys provide emergency access if you lose your phone or cannot use your authenticator app.

• 10 Keys Per User - Each user receives 10 unique recovery keys
• One-Time Use - Each key works only once and is then invalidated
• Regeneratable - Generate new keys from the 2FA settings page
• Shared with Email 2FA - The same recovery keys work for both email and authenticator methods

Login Flow

When authenticator 2FA is active, the login process works as follows:

1. Enter username and password as usual
2. You're redirected to the authenticator verification screen
3. Open your authenticator app and enter the current 6-digit code
4. Optionally check "Trust this device for 30 days"
5. Click "Verify & Login"

Alternative Access Methods

Security Features

• Replay Attack Prevention - Each code can only be used once per time window
• Time Window Tolerance - Accepts codes from ±1 time slice to handle clock drift
• Lockout Protection - Too many failed attempts triggers temporary lockout
• Super Admin Bypass - Optional exemption to prevent network lockouts

reCAPTCHA Protection

The reCAPTCHA addon provides centralized Google reCAPTCHA management for your WordPress site. All reCAPTCHA configuration is consolidated into this single addon, eliminating scattered settings and ensuring consistent protection across all forms.

API Key Setup

To use reCAPTCHA, you need API keys from Google:

1. Visit the Google reCAPTCHA Admin Console
2. Register your site (choose v2 or v3 based on your preference)
3. Copy the Site Key and Secret Key
4. Enter them in the reCAPTCHA addon settings

Protected Forms

Enable reCAPTCHA protection on any combination of these forms:

Settings

v3 Score Threshold

For reCAPTCHA v3, set the minimum score required to pass verification:

• 0.9 - Very strict, may block some legitimate users
• 0.7 - Strict, good for high-security sites
• 0.5 - Balanced (recommended starting point)
• 0.3 - Permissive, allows more traffic through

Badge Position (v3)

Control where the reCAPTCHA badge appears on your site:

• Bottom Right - Default position (required by Google ToS)
• Bottom Left - Alternative corner position
• Inline - Embedded within the form

Firewall

Firewall is a free optional addon included with Polanger Admin Suite. It adds a lightweight, WordPress-aware request firewall that watches the requests coming into your site and reacts when a request looks like a bot scan, login abuse, XML-RPC abuse, anonymous REST pressure, or a direct IP policy violation.

Think of it as a guard standing at the WordPress door. Normal visitors continue using the site, administrators can safely bypass protection when configured, and suspicious traffic is either logged, blocked, or temporarily cooled down depending on the selected mode.

This is not a replacement for a server firewall, CDN firewall, malware scanner, or hosting-level WAF. It is a WordPress-side safety layer designed to reduce common automated noise and protect the most abused WordPress entry points without turning the settings screen into a security laboratory.

Setup

Firewall is managed like the other bundled optional addons.

1. Open the built-in Addons screen.
2. Activate the Firewall addon.
3. Open Polanger Settings -> Firewall.
4. Turn on Enable Polanger Firewall when you are ready to start monitoring or enforcing protection.
5. Choose a mode: Monitor Only, Balanced, or Strict.
6. Save the settings.

Once enabled, the runtime protection starts automatically. You do not need to add code, edit .htaccess, or copy rules into the theme.

Protection Modes

The mode selector controls how the firewall behaves. The important detail is this: when you switch modes, Polanger applies the recommended preset values for that mode, but it does not blindly overwrite settings you changed yourself. If you tune a limit manually, the addon respects that value.

For most sites, this is the whole workflow: choose Monitor Only, Balanced, or Strict, save, and let the preset do the work. The many detailed controls are optional tuning panels for unusual sites, not required setup steps.

What the Mode Preset Controls

Firewall modes are more than labels. They automatically shape the core protection profile so users do not have to understand every technical setting before getting value.

• Auth limits - The selected mode controls how strict native WordPress login, registration, lost-password, and IP attempt limits should be.
• REST behavior - Balanced keeps public compatibility high, while Strict can block anonymous REST write requests unless the route is explicitly allowlisted.
• XML-RPC behavior - All modes can reduce XML-RPC authentication and multicall exposure; Strict also disables pingbacks by default.
• Probe tolerance - Balanced allows a small number of suspicious probes before cooldown; Strict lowers the tolerance and keeps cooldowns longer.
• Request scoring - The mode defines the score required before a suspicious request is monitored or blocked. Strict uses a lower threshold.
• Security headers - Balanced enables practical low-risk browser security headers. Strict can add stronger frame-ancestor protection.
• Application Password policy - Application Password usage can be logged, and Strict can limit Application Password availability to administrators.

Core Guards

The Core Guards section controls which major protection families are active. A beginner can leave these on. A developer can disable one family temporarily while testing a specific endpoint.

• Auth rate limiting - Watches native WordPress login, registration, and lost-password requests. If the same identity or IP repeats too often inside the configured time window, the firewall stops more attempts for a while.
• XML-RPC protection - Reduces abuse against the legacy xmlrpc.php endpoint. This helps against password guessing and multicall amplification attempts.
• REST API hardening - Keeps the REST API available, but limits anonymous pressure, optional anonymous write attempts, and public user-listing probes.
• Bot and probe blocking - Catches common automated scans for exposed files, backup archives, shell scripts, phpMyAdmin/Adminer paths, path traversal, null-byte probes, very long URLs, very long query strings, and unsafe HTTP methods such as TRACE or TRACK.
• Request scoring engine - Instead of looking at only one signal, it adds up suspicious clues such as a bad user agent, sensitive paths, injection strings, unsafe methods, very long URLs, and long query strings. If the combined score crosses the mode threshold, the request is monitored or blocked. This catches requests that are suspicious as a pattern, even if one signal alone would not be enough.
• User enumeration guard - Blocks simple username discovery tricks such as numeric ?author=1 probes and anonymous REST user listing when enabled. This helps reduce username harvesting without changing normal browser login behavior.
• Application Password guard - Watches WordPress Application Password API authentication. It can log successful and failed Application Password usage, and Strict mode can limit Application Password availability to administrators so lower-privilege API credentials are less exposed.
• Security response headers - Sends practical browser hardening headers such as X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and Permissions-Policy. Strict mode can also add a frame-ancestors CSP rule for stronger clickjacking protection.

Lockout Safety

The firewall is intentionally built with recovery in mind. Security that locks the site owner out is not good security.

• Allow logged-in administrators to bypass - Lets administrators with the required capability bypass firewall enforcement while tuning settings. This reduces accidental lockout risk.
• Temporary IP cooldowns - If an IP repeatedly hits suspicious probe URLs, the firewall can temporarily block that IP instead of permanently banning it.
• Log important firewall events - Stores a small recent-event buffer when something meaningful happens. This is not a full traffic log and is designed to stay lightweight.

Rate Limits

Rate limits are counters. In plain language: "How many times can this kind of request happen during this many minutes before we slow it down?"

These fields are optional. The selected mode fills them with recommended values. Open this section only if a specific site needs softer or stricter numbers.

• Login attempts - How many failed native WordPress login attempts are allowed for the same submitted identity from the same IP before the firewall blocks more attempts.
• IP attempts - A wider IP-level cap. This helps when the attacker rotates usernames or emails from the same IP address.
• Password reset attempts - Limits repeated native WordPress password reset requests.
• Registration attempts - Limits repeated native WordPress account registration attempts.
• Auth window minutes - The time window used for login, lost-password, and registration counters.
• Anonymous REST requests - How many anonymous REST API requests are allowed before rate limiting starts.
• REST window minutes - The time window used for anonymous REST request counting.
• Temporary block minutes - How long a repeated probe IP should remain in cooldown after it crosses the configured probe threshold.
• Request score threshold - How suspicious a request must be before the scoring engine reacts. Strict mode uses a lower value than Balanced.
• Temporary block score - The score at which a suspicious request can also place the IP into temporary cooldown, not just block one request.

REST and XML-RPC Details

These settings control two heavily abused WordPress entry points. The goal is not to break WordPress APIs, but to reduce risky anonymous behavior. They are optional because Balanced and Strict already choose sensible defaults.

• Block anonymous REST write requests - Optional stricter protection for unauthenticated POST, PUT, PATCH, and DELETE REST requests. Balanced leaves this off by default; Strict turns it on.
• Allowed anonymous REST write route prefixes - Lets safe public endpoints continue working even when anonymous REST write blocking is enabled, such as WooCommerce Store API cart routes or contact form submission routes.
• Block anonymous REST user listing - Blocks anonymous requests to /wp/v2/users, a common username discovery target.
• Disable XML-RPC authenticated methods - Prevents XML-RPC from being used as an alternate password-guessing surface.
• Disable XML-RPC multicall - Removes system.multicall, which attackers often abuse to pack many attempts into one request.
• Disable XML-RPC pingbacks - Optional. Useful for stricter sites that do not rely on pingbacks or legacy discussion workflows.

IP Rules and Event Logs

The IP rules section is for explicit trust and explicit deny decisions. Use it carefully because IP rules are powerful.

• Allowlist IPs / CIDR - IPs listed here bypass firewall enforcement. Add your office, developer, or server monitoring IPs here if you need a guaranteed safe route.
• Denylist IPs / CIDR - IPs listed here are blocked unless the firewall is in Monitor Only mode. Use this for known abusive IPs, not for broad guessing.
• CIDR support - Both exact IPs and CIDR ranges are supported, so advanced users can allow or deny small network ranges.
• Trusted proxy IP detection - If the site is behind Cloudflare, a load balancer, or a reverse proxy, you can trust a client IP header only when the direct server IP matches a proxy IP you explicitly trust.
• Trusted proxy headers - The firewall can read client IPs from known proxy headers such as Cloudflare Connecting IP, X-Forwarded-For, or X-Real-IP, but only when the direct server address belongs to a trusted proxy you entered. This avoids trusting spoofed visitor headers.
• Recent Firewall Events - Shows the latest blocked or monitored events, including decision, reason, IP, request method, and request path.
• Clear Events - Deletes the small recent-event buffer. This does not change firewall rules or counters.

Firewall Diagnostics

The Firewall Diagnostics panel is a built-in self-test area for the addon. It helps a site owner or developer answer a simple question: "Are the protection decisions I selected actually being evaluated the way I expect?"

The diagnostics are intentionally safe. They do not open real dangerous URLs, do not send requests to /.env, wp-config.php, shell.php, or similar paths, and do not try to attack the website. Instead, they create internal test fixtures and ask the Firewall decision engine how it would react.

• Run All Tests - Runs every available diagnostics group and shows a pass/fail summary with the current firewall mode.
• Safe Request Tests - Simulates a suspicious request with SQL-style patterns and a normal visitor request, then checks whether request scoring behaves according to the current settings.
• Rate Limit Tests - Simulates login threshold logic without submitting real credentials to wp-login.php.
• REST/XML-RPC Tests - Checks anonymous REST user listing, anonymous REST write behavior, allowlisted REST write prefixes, XML-RPC multicall filtering, and XML-RPC pingback filtering.
• IP/Cooldown Tests - Verifies exact IP matching, IPv4 CIDR matching, IPv6 CIDR matching, allowlist priority, and temporary cooldown decision logic using documentation-only IP ranges.
• Header Tests - Confirms whether the selected mode and custom settings currently configure browser-side hardening headers such as nosniff, frame protection, referrer policy, permissions policy, and Strict-mode frame ancestors.
• Clear Test Data - Removes temporary diagnostics state. It does not delete firewall rules, counters, mode settings, or event logs.

Optional Advanced Mode Details

The advanced controls are intentionally tucked away. They let developers override specific preset pieces such as individual security headers, Application Password logging, Application Password admin-only enforcement, numeric author query blocking, request score threshold, and temporary block score. A regular site owner does not need to configure these one by one.

• Header toggles - You can individually control nosniff, frame protection, referrer policy, permissions policy, and Strict-mode CSP frame-ancestor behavior.
• Application Password toggles - You can log Application Password usage or limit Application Password availability to administrator accounts.
• Author query toggle - You can specifically control numeric author ID probe blocking if a site has a custom author archive workflow.
• Score thresholds - You can tune when the request scoring engine blocks a request and when it also creates a temporary IP cooldown.
• Live preset reflection - When a mode is selected in the settings UI, the optional fields update immediately so administrators can see what the preset will save before clicking the button.
• Custom override respect - If an administrator manually changes an optional field, later mode changes keep that custom value instead of silently overwriting it.

Recommended Starting Pattern

1. Enable Firewall in Monitor Only mode for the first day on sensitive or high-traffic sites.
2. Review Recent Firewall Events and make sure normal traffic is not being flagged in a surprising way.
3. Add your own static office or developer IP to the allowlist if you need a recovery path.
4. Switch to Balanced for normal production protection.
5. Use Strict only when the site is under attack or you intentionally want more aggressive thresholds.

WooCommerce Security

WooCommerce Security is a free optional addon included with Polanger Admin Suite. Instead of creating a second disconnected security system, it reuses the existing Polanger reCAPTCHA and 2FA infrastructure and adds a dedicated rate limiting layer for store-facing authentication requests.

This means store owners can protect customer login, registration, and password recovery screens from one familiar Polanger settings workflow instead of scattering controls across multiple plugin pages.

The addon is dependency-aware by design. It only runs when both Polanger Admin Suite and WooCommerce are available, so stores are not left with half-loaded security features or broken form hooks.

Dependencies & Activation Behavior

WooCommerce Security is managed as an optional suite addon, but it is intentionally strict about dependencies so it cannot be activated in an incomplete environment.

• Requires Polanger Admin Suite - The addon expects the core Polanger security helpers to be available before it boots.
• Requires WooCommerce - WooCommerce must be installed and active because the addon hooks directly into WooCommerce authentication forms and request handlers.
• Activation gate - If WooCommerce is missing or inactive, activation is refused and a clear admin-facing dependency message is shown.
• Auto-deactivation safety - If WooCommerce or the core suite disappears later, the addon deactivates itself on admin load instead of continuing in a broken state.
• One-time setup notice - After successful activation, administrators receive a direct link to the WooCommerce tab inside Polanger Settings so setup is not forgotten.

WooCommerce reCAPTCHA Integration

When this addon is active, the main Polanger reCAPTCHA tab gains extra WooCommerce-specific locations. You still manage API keys, version selection, and other global reCAPTCHA behavior from the existing reCAPTCHA addon. WooCommerce Security simply adds the store-side form hooks and verification points.

Both reCAPTCHA v2 and v3 continue to work through the same Polanger service layer. The WooCommerce addon only renders and verifies the protection in the correct store form locations.

WooCommerce 2FA Flow

WooCommerce Security also carries the existing Polanger 2FA challenge flow into WooCommerce customer login. It does not replace the core 2FA system. Instead, it preserves the WooCommerce context so the user can complete verification and still return to the correct store destination.

• My Account aware - If login begins from WooCommerce, the pending 2FA context is marked as a WooCommerce-origin login.
• Redirect preservation - The original WooCommerce redirect target is captured and reused after successful verification where allowed.
• Correct back link behavior - The "back to login" path on the 2FA screen points back to the original WooCommerce login screen instead of a generic WordPress login page.
• Shared 2FA policy - Code expiry, failed attempt limits, lockout duration, trusted-device behavior, recovery methods, and required-role rules still come from the main Polanger 2FA settings.
• No duplicate 2FA settings page - Store owners do not need to configure a second 2FA system just for WooCommerce.

Rate Limiting

The WooCommerce tab in Polanger Settings adds a focused rate limiting layer for customer authentication traffic. This runs automatically on WooCommerce login failures, registration attempts, and lost password requests, using both identity-based and IP-based tracking windows.

• Single master switch - Enable or disable the entire WooCommerce rate limiting layer from one toggle.
• Identity + IP buckets - Limits are evaluated against the submitted username or email where possible, and also against the client IP.
• Automatic login reset - A successful WooCommerce login clears the login identity bucket so legitimate users are not penalized after finally authenticating.
• No form clutter - Customers do not see extra fields. The protection works in the background and only shows a message if limits are reached.

Protection Modes

Instead of asking store owners to tune every number manually, the addon offers three ready-made rate limiting profiles.

Maintenance Center

Maintenance Center is a free optional operations addon for Polanger Admin Suite that turns maintenance mode into a guided workflow instead of a pile of raw fields. From one settings tab, you can build a branded holding page, control who may bypass it, define when it starts and ends, and decide which public actions should stay blocked during deployment work.

It is designed for agencies, product teams, and site owners who need something more professional than a plain “we’ll be back soon” message. The addon gives you a visual builder, countdown controls, preview links, role and IP-based bypass rules, and deployment-specific locks without scattering settings across multiple plugin pages.

Visual Builder

The builder focuses on speed and clarity so non-technical users are not forced to paste raw asset URLs or hand-type colors.

• Logo picker with alignment controls - Choose the site logo directly from the WordPress Media Library and place it left, center, or right.
• Headline controls - Enter the main message visitors should see and choose its alignment without touching code.
• Rich description editor - The main body uses the WordPress editor, so paragraphs, links, basic HTML, and shortcodes can be used naturally.
• Footer content area - Add support details, launch notes, contact information, or a branded signature in a separate rich-text footer block.
• Background builder - Choose between a solid color, a two-color gradient, or a full background image with a readability overlay.
• Custom CSS and JavaScript - Add final design polish or small controlled scripts without editing plugin files.

Access Rules

Maintenance Center is not just a page design tool. It also controls who may continue using the site while the public sees the holding screen.

• Role-based bypass - Allow selected roles to continue browsing while maintenance remains visible to visitors.
• Logged-in bypass option - Let authenticated users through when your rollout process requires a lighter gate.
• IP allowlist - Whitelist specific IP addresses for team members, QA, or client reviewers.
• Signed preview links - Generate time-limited preview URLs so approved reviewers can inspect the live frontend without permanently bypassing maintenance.
• Robots and sitemap handling - Decide whether crawlers should index the temporary page and whether sitemap requests should remain available.

Countdown & Scheduling

The addon supports both manually enabled maintenance windows and scheduled sessions that activate and finish automatically.

• Manual or scheduled activation - Turn the page on yourself or define a start and end time for automated maintenance windows.
• Timezone-aware scheduling - Maintenance windows respect the timezone selected in the addon settings.
• Countdown timer - Show a visitor-facing countdown block and choose whether years, days, hours, minutes, and seconds should appear.
• Dedicated countdown target - Use a custom timer target or automatically fall back to the scheduled end time when appropriate.
• ETA and status note fields - Explain what is happening and when visitors should expect the site to return.

Deployment Locks

When the addon runs in Deployment Mode, it can do more than show a holding page. It can also reduce risky public interactions while release work is in progress.

• Comments lock - Prevent new comment submissions during deployment.
• Registration lock - Temporarily disable public account registration, including WooCommerce registration when applicable.
• Checkout route lock - Stop WooCommerce checkout entry points from remaining publicly interactive during release work.
• Not purchasable mode - Mark WooCommerce products as unavailable for purchase while the deployment window is active.
• 503 or 200 response strategy - Choose between a search-engine-friendly 503 response or a public holding page that remains technically accessible with a 200 status.

Settings

Configure access control, two-factor authentication, and other plugin-wide settings.

Access Control

Restrict who can access and modify the plugin settings:

• Allowed Users - Select which administrators can access the plugin
• Access Levels - Full Access or Read-only for each user
• Super Admin Protection - Super Admin (ID 1) can never be locked out
• URL Blocking - Restricted users can't access plugin pages via direct URL

Two-Factor Authentication (2FA)

Add an extra layer of security with email-based 2FA:

Setup Process

1. Click "Send Test Email" to verify email delivery works
2. Enable Two-Factor Authentication
3. Select which roles require 2FA
4. Save your recovery keys

Features

• 6-Digit Codes - Sent via email on each login
• Code Expiry - 5, 10, or 15 minutes
• Role-Based - Require 2FA for specific roles
• Recovery Keys - One-time use backup codes
• Super Admin Bypass - Super Admin is exempt to prevent lockouts

Miscellaneous

• Custom Footer Text - Replace "Thank you for creating with WordPress"
• Hide WordPress Version - Remove version number from admin footer
• Live Preview - See footer changes in real-time

Hooks & Filters

For developers who want to extend or customize the plugin behavior.

Polanger Custom Developer Hooks

Menu Manager Hooks

Admin Bar Hooks

Login Page Hooks

Database

The plugin stores settings in WordPress options and creates one custom table for activity logs.

Options

Activity Log Table

Table name: {prefix}_pdt_admin_logs

CREATE TABLE {prefix}_pdt_admin_logs (
  id bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  user_id bigint(20) unsigned NOT NULL,
  user_login varchar(60) NOT NULL,
  action varchar(100) NOT NULL,
  object_type varchar(50) DEFAULT NULL,
  object_id bigint(20) unsigned DEFAULT NULL,
  object_name varchar(255) DEFAULT NULL,
  ip_address varchar(45) DEFAULT NULL,
  user_agent varchar(255) DEFAULT NULL,
  meta longtext DEFAULT NULL,
  created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (id),
  KEY user_id (user_id),
  KEY action (action),
  KEY created_at (created_at)
);

Security

The plugin follows WordPress security best practices:

• Nonce Verification - All forms use WordPress nonces to prevent CSRF attacks
• Capability Checks - Only users with manage_options can access the plugin
• Input Sanitization - All user inputs are sanitized before storage
• Prepared Statements - Database queries use $wpdb->prepare()
• Super Admin Protection - Super Admin cannot be locked out of the plugin
• Read-Only Mode - Server-side enforcement prevents unauthorized changes
• GDPR Compliance - No sensitive data is logged, IP logging is optional

Changelog

Version 1.5.7 Latest

• New: Design System now includes the PG Aurora admin theme preset with a modern light dashboard style, gradient menu states, improved sidebar icon handling, refined submenu hierarchy, and polished classic WordPress admin screen compatibility
• Improved: Firewall request protection was refined with safer preset behavior, compatibility-aware REST handling, and clearer optional tuning boundaries for production sites
• Improved: Strict REST protection now preserves WooCommerce Store API compatibility automatically when WooCommerce is active, preventing cart, checkout, and account flows from being blocked by anonymous REST write hardening
• Fixed: Design System preset application now updates saved theme tokens reliably, reflects changes immediately on the settings page, and includes an inline fallback so generated admin theme CSS cannot silently fail on stricter live hosting setups
• Improved: Menu Manager mobile layout now uses responsive card-based rows with cleaner visibility controls, submenu expansion, custom name fields, and cache-safe admin UI stylesheet loading

Version 1.5.6

• New: Firewall addon adds Monitor Only, Balanced, and Strict WordPress-aware request protection for common bot probes, native auth rate limits, XML-RPC hardening, REST pressure, anonymous user enumeration, IP rules, temporary cooldowns, and lightweight event logging while respecting custom administrator overrides
• Improved: Firewall defaults, Monitor Only behavior, REST compatibility, CIDR validation, proxy IP detection, and event logging safety were refined to reduce false positives and lockout risk
• Fixed: Plugin update notifications remain visible on the Plugins screen when admin notice hiding is enabled
• Improved: The Shield dashboard displays the Global Demo Mode summary only while demo protection is active
• New: Menu Manager identifies menu and submenu items already protected by active Shield page rules and shows affected users and direct URL protection details without duplicating restrictions

Version 1.5.5

• Improved: Admin Suite interface refined with cleaner layouts, smoother navigation, and more consistent settings screens
• Improved: Better compatibility across login security, frontend visibility, dashboard controls, and modular addon workflows
• Improved: Module loading optimized to keep the WordPress admin experience faster and lighter when only selected features are enabled
• Improved: Responsive behavior polished across key Admin Suite screens for a more comfortable tablet and mobile admin experience
• Fixed: Minor visual and settings synchronization issues reported in selected admin screens

Version 1.5.4

• Improved: Frontend Content Visibility editing was streamlined with a clearer access-rule workflow, making role-based hiding easier to understand on posts, pages, and supported custom post types while preserving compatibility with older saved rules
• Improved: Frontend Content Visibility now serves a dedicated Polanger protected 404 screen when denied behavior is set to 404, avoiding broken or inconsistent theme-level 404 layouts
• Improved: Login Security redirect handling and protected-route interception were hardened for unauthorized access attempts to custom login and admin entry points
• Improved: The built-in protected 404 experience was refined with cleaner messaging, a simplified layout, and WordPress 6.4+ compatibility hardening for deprecated emoji style output

Version 1.5.3

• New: Frontend Content Visibility core module for posts, pages, and supported custom post types with role-based audience control, denied behavior routing, and discovery hiding for archives, REST API, and XML sitemaps
• Improved: Admin design system and user interface components enhanced for a better user experience.
• Improved: Mobile and responsive layouts optimized across various plugin screens.
• Improved: Enhanced security measures and hardening implemented for the Two-Factor Authentication (2FA) module.
• Improved: Translation catalogs and compiled language packs were refreshed for the current release across bundled locales

Version 1.5.2

• Improved: Menu Manager now captures late-registered and dynamically reordered top-level admin menus more reliably, fixing cases where some third-party plugin menus did not appear in the manager list
• Improved: Menu Manager list ordering now better mirrors the effective live WordPress sidebar order for plugins that reposition themselves through custom menu filters
• Improved: Design System was expanded into a richer WCAG-aware admin theming engine with semantic color tokens, advanced typography controls, and a live preview playground
• Improved: Design System presets were redesigned into curated professional themes, with stronger compatibility across admin menus, admin bar states, metaboxes, tables, widgets, and classic editor screens
• Improved: Design System Midnight compatibility was hardened for third-party admin UI, including low-contrast text recovery and dark dropdown/menu readability fixes that only activate for the Midnight preset
• Improved: Mobile admin usability refinements across settings layouts and action controls for better spacing, responsiveness, and alignment on smaller screens

Version 1.5.1

• Fixed: Resolved an issue where reCAPTCHA could fail to appear on the custom login page under certain configurations
• Improved: Better integration and compatibility between Authenticator App (TOTP) and reCAPTCHA verification flows
• Improved: Comment Guard reCAPTCHA integration is now more stable and reliable across comment submission scenarios
• Fixed: Resolved login page logo cropping issues on responsive and custom layout configurations
• Improved: On mobile devices, the login page language selector is now displayed inside a compact drawer for a cleaner layout
• New: Added option to completely disable the language switcher on the login page

Version 1.5.0

• New: Authenticator App (TOTP) addon – Google/Microsoft Authenticator support with multi-user architecture (per-user enrollment, profile page management, admin sees status only), mandatory enrollment flow for required roles, safe secret rotation with pending secret system (old authenticator keeps working until new verified), AES-256-CBC encryption, recovery keys with auto-regeneration on rotation, trusted device memory (30 days), email fallback, brute-force protection, and replay attack prevention
• New: reCAPTCHA addon – centralized Google reCAPTCHA v2/v3 key management; all reCAPTCHA configuration consolidated from multiple locations into one dedicated addon; supports login, registration, lost password, and comment forms; integrates seamlessly with Comment Security addon
• Improved: Design System – expanded color customization with Sidebar Background, Sidebar Text Color, Admin Bar Background, Admin Bar Text Color, Admin Bar Submenu Background, and Admin Bar Submenu Text Color options
• Improved: Design System color compatibility – enhanced contrast handling and readability corrections across admin UI components including postboxes, notices, tables, and form controls
• Improved: Menu Manager stability – resolved conflict issues with certain third-party plugins and themes that were causing menu rendering inconsistencies
• Improved: Mobile responsiveness – comprehensive layout and interaction improvements across all admin screens for better tablet and smartphone usability; improved touch targets, spacing, and navigation
• Fixed: 2FA settings form submission – resolved nested form issue that prevented Save Settings button from working when Authenticator addon was active

Version 1.4.3

• New: Comment Security Layer addon – multi-layer comment protection with honeypot trap, HMAC-signed timing tokens, per-IP flood control (per-minute and per-hour windows), keyword and URL blocklists, behavior scoring engine with configurable thresholds, and silent action modes (spam queue, trash, or silent drop)
• Improved: Login page design – refined mobile layout with corrected form card proportions, improved spacing around inputs and buttons on small screens, and more consistent hover and focus state rendering across breakpoints
• Improved: Login page background rendering – smoother gradient transitions and better full-coverage rendering for background images on narrow viewports; improved visual layering between background and form card
• Improved: Admin panel mobile responsiveness – layout and spacing adjustments across Settings, Addons, and Activity Log screens; better usability on tablet and mobile viewports with more appropriate touch target sizing
• Improved: Sub-tab settings saves – partial save operations now only process and re-validate the submitted field group, reducing redundant sanitization passes on every tab change
• Improved: Addon list layout – card grid now wraps and spaces more cleanly on narrow viewports with improved readability of addon status indicators on mobile

Version 1.4.2

• New: Multisite Control addon for network-wide defaults, lock policies, and site-level overrides
• New: Network-aware settings engine using effective settings filters across supported modules
• New: Network lock support for Menu Manager, Admin Bar, Login Security, Activity Log, and Dashboard Center
• New: Site override status controls and network-managed module notices
• Improved: Addon activation flow with optional network-wide active addon support
• Improved: 2FA login session handling now respects the original Remember Me preference during verification
• Improved: 2FA resend verification flow hardened with nonce-protected requests and stricter token validation
• Improved: 2FA verification flow now includes stronger user/session guard checks to reduce edge-case failures
• Improved: 2FA trusted device and security logging IP resolution strengthened with trusted-proxy aware validation
• Improved: 2FA email delivery failure behavior is now configurable with secure-by-default login handling
• New: Design System addon scaffold with token-based settings, preset support, and generated CSS output
• Improved: Addon-first theming extensibility via polanger_admin_theme_assets for clean admin UI customization without core CSS overrides

Version 1.4.1

• Improved: Activity Log export flow (CSV/JSON) output handling on Settings page for more consistent downloads
• Improved: Settings export callback visibility and admin_init lifecycle compatibility
• Improved: Activity Log query hardening with validated table-name usage and allowlisted ORDER BY handling
• Improved: 2FA verification comparison updated with timing-safe hash validation (hash_equals)
• Improved: Activity Log IP resolution now prefers REMOTE_ADDR and supports trusted-proxy based forwarded-header parsing
• Improved: Settings input validation for allowed_users with strict array-type guards before normalization

Version 1.4.0

• Major update: Polanger expanded into a full Admin Suite with optional addons managed from one interface
• New: Full Admin Suite experience (menu, login, security, dashboard, activity log)
• New: Custom Admin Menu Builder
• New: Role-based access control improvements
• Improved: UI/UX across all modules
• Improved: Performance and stability
• Improved: Security layers and validation
• Fixed: Minor bugs and edge cases