# Custom Login URL — 1.6

Opt-in: `custom_login_enabled` remains `0` after development. Current local slug:
`a360-access-7392`. Enable only after reviewing local tests and keeping a shell open.

The exact custom path dispatches through WordPress `parse_request` before content
queries and canonical redirects. GET and POST go directly to core `wp-login.php`;
no redirect discards a POST body. Core handles cookies, SSL, nonce checks,
registration, interim login, password recovery and logout. Login URL filters and
redirect rewriting retain query parameters and fragments. Avatar verification,
IP rules, lockouts and XML-RPC settings remain active.

Standard `wp-login.php` returns 404 while enabled. Core recovery-mode entry links
and password-protected post submissions remain available and retain core checks.
This hides an endpoint; it does not replace authentication or rate limiting.
Exclude the custom path and its query variants from reverse-proxy/page caches.

Invalid or reserved slugs, existing post/page/attachment collisions, plain
permalinks and multisite fall back to the standard login. Multisite custom routing
is intentionally unsupported in 1.5. No rewrite flush is required.

## Emergency recovery

From the local WordPress root:

```sh
ddev wp option patch update a360_login_avatar_panel custom_login_enabled 0
```

On a server use the corresponding `wp option patch update` command. Alternatively
add this before WordPress boots in `wp-config.php`:

```php
define('A360_CUSTOM_LOGIN_DISABLED', true);
```

This override disables only custom routing and restores standard login. Removing
it restores the stored setting. It is not a public URL bypass.

## Local verification

From the DDEV WordPress root:

```sh
ddev wp eval-file wp-content/plugins/a360-login-avatar-panel/tests/custom-login.php
python3 wp-content/plugins/a360-login-avatar-panel/tests/ddev-smoke.py
```

Requires Python 3 and running DDEV. The test temporarily enables routing, creates
a disposable subscriber, exercises login/avatar checks/logout/password reset,
and restores the full original settings and removes the test user in `finally`.
The test temporarily raises lockout and email thresholds to prevent repeated runs
from locking out the local client or sending alert mail; original thresholds are
restored. Login event counters can increase during these tests. Do not run against production.
The reset token is generated through WP-CLI without a reset-request email. Core
may attempt a password-change notification to the disposable example.invalid address.

## Version 1.6: guest admin access

When custom routing is active, unauthenticated wp-admin PHP screens return an
uncached 404 before core authentication redirects. Logged-in users retain normal
admin access and capability checks. Actual admin-ajax.php and admin-post.php entry
scripts remain available for public handlers; an ajax query flag on another admin
screen does not bypass the block. When routing is disabled or falls back, core
admin login redirects work normally. Static admin assets remain available.