Front-end user accounts: sign in, register, reset a password and edit a profile on your own pages, styled by your own theme. Five shortcodes, five ordinary pages, and no wp-login.php in sight for your visitors.
[r2ob_login] — sign-in form[r2ob_register] — registration, with optional e-mail activation[r2ob_forgot_password] — request a reset link[r2ob_reset_password] — choose a new password[r2ob_profile] — name, e-mail and password for the signed-in userThe pages are created for you on activation. The markup is plain and class-named, and the stylesheet does layout and focus rings only — typography and colour come from the theme.
wp_login_failed, so Limit Login Attempts, a firewall rule or R2 Security Hardening’s Login Guard keep working.Redirecting visitors away from wp-login.php is optional and off by default. Even when on, administrators are never redirected and it refuses to act if the login page is missing, so lockout is impossible; define( 'R2OB_DISABLE_LOGIN_BLOCK', true ) switches it off from outside the admin. Worth knowing before enabling it: moving sign-in traffic off wp-login.php also moves it out of view of anything watching that URL.
No ACF, no Composer, no bundled SMTP. Configuration is the plain WordPress Settings API, and mail goes through wp_mail() — pair it with FluentSMTP or WP Mail SMTP, which give you connection tests, delivery logs and retries that a bundled transport never does.
data-no-minify: WP Rocket names its minified copy after the file path, not the version, and could keep serving the previous version’s file after an update.wp_login_failed fired so third-party guards still see failures.wp_signon() and only then checked whether the account was still awaiting activation, meaning to log it back out. That check was unreachable: wp_signon() fires wp_login, the post-login redirect ran wp_safe_redirect(); exit; inside it, and execution never returned — so an unactivated account was signed in and stayed signed in. The check now runs on authenticate and refuses the credentials outright.wp_insert_post() calls plus flush_rewrite_rules() were hooked to init, so they ran for whichever anonymous visitor arrived first, with a race that could double-create. Page creation now happens only on activation, adopts an existing page at the same slug, and flushes nothing.wp_signon() with no counter while the plugin redirected wp-login.php away, so every guard scoped to that URL was bypassed and the real credential surface moved to admin-ajax.php. Fixed, and that redirect now defaults to off, never applies to administrators, and has a wp-config escape hatch.wp_unslash() throughout (passwords containing quotes were corrupted), a PHP 8.2 dynamic property plus $_POST-driven method dispatch, and sessions left alive across a password change — all fixed.