Every module, every setting

Sign in, sign up, forgot password and check-your-email. Every screen has its own title and subtitle, and the set shares a background image, a logo and an optional tabbed layout.

The same builder the account form uses, on the login and registration forms.

Built on intl-tel-input and driven entirely from settings. Country detection runs on the SERVER — fastest, from a CDN or GeoIP header — or in the BROWSER, which is the correct answer when full-page caching serves the form to logged-out visitors.

Weak passwords are stopped at the site level rather than left to each member.

Login, registration and password reset each get their own. The reset and registration caps are what stop somebody making your server send mail or SMS on another person’s behalf.

A spoofed X-Forwarded-For cannot walk past a limit. Trusting the header your proxy actually sets takes one explicit filter, and that opt-in is the point rather than an inconvenience.

One master switch, and turning it off does not touch accounts that already exist.

Dedicated destinations after login, after registration and after a reset. The return URL is carried across steps and judged by a single class, which is what keeps your login link from becoming an open redirect.

Login, registration and password reset each have their own switch and their own channel, so registration by SMS with password reset by email is a normal configuration rather than a compromise.

A resend re-sends the LIVE code instead of replacing it, so a member who presses it twice does not lock themselves out — one of six published architecture decisions, with tests behind it.

Turn password login off and the site has no password to forget, reset or leak. Behaviour in every combination of these settings is defined by a decision table and tested.

Theme and child-theme CSS and JS stop loading on panel pages and on the authentication screens, independently. Panel pages get lighter as a side effect, not as a promise.

Removing a handle does not break the handles that depended on it. It has its own unit tests, because the failure mode is a blank screen.

Nothing to configure

The list is built from your own plugins directory rather than from a maintained allow-list, so a plugin you installed yesterday is already in it.

“Scan panel page” and “scan auth page” report the handles that ACTUALLY loaded, and you tick what to remove. You stop guessing which plugin broke the layout.

For the asset that has no handle worth naming, or a handle that changes between versions.

Everyone, named roles, or buyers of a specific WooCommerce product — and a preview shows how many people that is before you publish.

A title, an icon with its own colour and background, and a body. Pin what matters and it stays at the top.

Draft, published or scheduled with a time, so a campaign is planned rather than remembered.

Pick the channels that fire when it publishes. Leave it empty and the announcement stays in the panel only, which is the right answer more often than it sounds.

You know who saw it. Unread items are emphasised in the panel, on the dashboard card and on the header badge.

Nothing to configure

Stat tiles for total, published, scheduled, drafts and pinned, plus filters and an empty state that offers the next action rather than a shrug.

A gateway registry with capability-based interfaces. Adding your own carrier means implementing one interface — you are not waiting on us, and these two are the reference implementations to read.

For carriers that require pre-approved templates. Each provider parameter binds to a message variable or to a fixed value, and the approved patterns are read from your own provider account rather than typed in twice.

Health badges per pattern: off, no code set, not approved by the provider, or pattern-only — plus the last send. You find out here rather than from a member who did not get a code.

Nothing to configure

Send one to yourself before a real user is involved.

A voice channel on gateways that support it. Where a gateway has no pattern support, messages fall back to free text — and the admin says so plainly rather than failing quietly.

Six checks, each with a precise message and a fix button: no published page assigned to the panel, none assigned to authentication, permalinks set to Plain — which 404s every section — sections with no rewrite rule, slugs claimed by both HUBU and WooCommerce, and theme assets still loading on the panel.

Tiles for the user panel, authentication, the active modules and the installed version — so “which of these is on?” is answered on the page you already have open.

Nothing to configure

The panel and authentication pages are created if they do not already exist, with a dedicated installer for the panel page. You assign them; you do not build them.

Nothing to configure

No special PHP extensions, no cron requirement beyond WordPress’s own, and no external service unless you enable SMS.

Domain, application and infrastructure layers with a dependency-injection container and typed exceptions, unit tests inside every module, and six published architecture decision records covering response shape, error behaviour, hook stability and code semantics. It passes WordPress.org’s own plugin-check tooling.

Every string is translatable on the hubu text domain. Put your files in wp-content/languages/plugins/ and a plugin update will not overwrite them. RTL layouts are mirrored rather than patched.

Nothing is sent anywhere while a visitor simply browses. The only outbound calls are connecting your site to your account, checking the licence and fetching an update — each triggered by an explicit action in the admin.

Nothing to configure

Deleting the plugin leaves your settings, your user data and your tables in place, and reinstalling picks up where you left off. A clean removal happens only if you explicitly opt in from a must-use plugin — which is deliberately more work than a checkbox.