ElliePass for WordPress

Development port of the ElliePass Discourse integration to WordPress.

Namespaced capabilities

• wordpress.register
• wordpress.login
• wordpress.post.create
• wordpress.comment.create
• wordpress.content.access

The current Discourse integration is not changed. Laravel should accept both its existing legacy Discourse capability names and the new WordPress namespaced capabilities.

API endpoints used

The plugin intentionally reuses the existing Community API:

• POST /api/v1/community/connect
• POST /api/v1/community/member/status
• POST /api/v1/community/member/authorize
• POST /api/v1/community/member/verification/start

It sends the same community authentication headers used by the Discourse plugin:

• X-ElliePass-Community-Key
• X-ElliePass-Secret
• optional X-ElliePass-Trace-Id

Additive WordPress connect fields

The WordPress client additionally sends:

• platform: wordpress
• site_url
• policy_push_url
• integration_version

Laravel should accept these fields without changing the existing Discourse request contract.

Policy push

WordPress exposes:

POST /wp-json/elliepass/v1/policy

The push token returned from /community/connect is stored only as SHA-256 and is required for policy pushes. Policy versions are monotonic; same-version/different-content pushes are rejected.

Registration behavior

The existing ElliePass member contract requires a durable external_user_id. WordPress does not have that ID until the account is created. Therefore wordpress.register is implemented as:

1. WordPress creates the account.
2. ElliePass marks it registration-pending.
3. Before normal account use/login, ElliePass authorizes wordpress.register.
4. Once qualified, the pending flag is removed.

This preserves a stable WordPress user ID and avoids inventing an email-based identity key.

Content access

wordpress.content.access can be applied globally to singular pages/posts from Settings → ElliePass. For targeted protection, use:

[elliepass_require capability="wordpress.content.access"]Protected content[/elliepass_require]

Important development status

This is the first WordPress port and requires the Laravel Community Admin/API changes for WordPress platform/capabilities before end-to-end use.

The bounded stale-cache grace behavior has intentionally NOT been enabled yet in this package. The current code fails closed if ElliePass is unreachable and no fresh cache exists. Once the WordPress/Laravel flow is tested, stale-grace behavior should be ported exactly and tested separately.

0.1.1 handoff fix

• Sends the current return URL with authorization requests.
• Preserves next_step, verification_url, and checkout_url returned by ElliePass.
• Redirects directly to the authorization-provided account-setup/verification URL.
• Falls back to /member/verification/start only when authorization did not provide a destination.
• Allows external redirects only when the destination origin matches the configured ElliePass API origin.

0.1.2 verification gate

Guarded WordPress actions now show a local WordPress Verification required screen with a Continue with ElliePass button before leaving the site. The short-lived gate payload is stored server-side and bound to the current WordPress user. JavaScript is not required for this core flow; later JavaScript can preserve unsent form/editor text and improve automatic resumption.

0.1.3 return target fix

ElliePass now captures the current WordPress request URL instead of relying on the HTTP referrer.

Example: Posts list → Add New → ElliePass verification → /wp-admin/post-new.php.

0.1.4 guarded login UX

• Guarded WordPress login no longer prints the raw ElliePass handoff URL.
• The login error displays a Continue with ElliePass button.
• Uses the authorization-provided verification/account-setup URL when available.
• After verification the user returns to WordPress login and can sign in normally.

0.1.6 login fatal fix

• Fixes the guarded-login fatal error caused by CSS percentage signs being interpreted as sprintf() format tokens.
• Builds the login verification message with escaped string concatenation instead of formatting HTML/CSS through sprintf().

0.1.7 new account activation

wordpress.register is implemented as New account activation.

• WordPress creates the self-registered account first so ElliePass has a stable WordPress user ID.
• Public self-registered accounts are marked with _elliepass_activation_pending.
• Admin-created users are not marked pending.
• A pending account cannot complete login until wordpress.register is qualified.
• After qualification, the pending flag is removed permanently.
• wordpress.login remains a separate capability for communities that want verification on normal logins.

0.1.8 login return messages

• Displays ElliePass verification failures on the WordPress login page.
• Handles current-location mismatch/unavailable results returned through elliepass_result / elliepass_reason.
• Keeps the user on the login page with a clear explanation instead of silently returning with no visible error.

0.1.9 activation refresh fix

• Fixes new-account activation after ElliePass verification while the WordPress user is logged out.
• guard_login() clears the user's local ElliePass authorization snapshot before checking wordpress.register / wordpress.login.
• Prevents a stale pre-verification denial from blocking login after successful liveness/location/identity verification.

0.2.0 UX polish

• Adds a reusable ElliePass verification modal experience for guarded WordPress actions and protected content.

• Keeps enforcement server-side; JavaScript/CSS only improve presentation.

• Adds clearer states for verification required, account connection, location mismatch, location unavailable, and ElliePass unavailable.

• Keeps WordPress login/new-account activation messages inline on the native login screen.

• Replaces the raw WordPress capability list in Settings with human-readable names, descriptions, internal keys, and current guarded status.

• Simplifies modal hierarchy so the reason/action appears first; redundant ElliePass branding and status pills were removed.

True in-page modal behavior

• Guarded comment submissions are preflighted in JavaScript before WordPress submits the form.
• Classic post create/edit submissions are preflighted in place.
• Gutenberg post/page REST writes are preflighted through wp.apiFetch middleware.
• If verification is required, the current URL does not change; an ElliePass modal opens over the existing page.
• Cancel/Close only dismisses the modal.
• Continue with ElliePass uses the direct handoff URL and returns to the page after verification.
• Existing PHP guards remain active as the authoritative server-side fallback and cannot be bypassed by disabling JavaScript.

Early admin navigation guard

• Create Post now preflights when the user clicks an Add New link, before entering the editor.
• Edit Post preflights when the user clicks an Edit link, before entering the editor.
• Cancel closes the modal and leaves the current wp-admin URL unchanged.
• Continue with ElliePass returns directly to the intended editor URL after verification.
• WordPress internal auto-drafts are ignored by the server guard; actual create/update writes remain protected server-side.

0.2.1 navigation-first modals

• Guarded Create posts is checked when a member clicks Add New / New Post, before the editor opens.
• If verification is required, the modal opens on the current admin page and the URL does not change.
• Cancel simply closes the modal.
• After ElliePass verification, the member returns to the intended editor.
• WordPress internal auto-draft creation is ignored by the PHP post guard.
• Direct editor URLs, disabled JavaScript, REST writes, and form submits remain protected by the existing server-side/editor fallback enforcement.

0.2.2 protected-content modal fix

• Server-rendered protected-content modals are re-parented to document.body so theme containers cannot constrain the backdrop.
• The modal backdrop now explicitly covers the full viewport.
• Protected-content secondary action is labeled Close instead of Not now.

0.2.3 protected discussion

• wordpress.content.access now protects the complete post discussion, not only the post body.
• Existing comments and the comment form remain hidden while content access is denied.
• Comment-related WordPress blocks are also suppressed while protected content is locked.
• wordpress.comment.create remains a separate capability controlling whether an already-authorized member may write comments.

0.2.4 remove Edit posts guard

• Removed the ElliePass Edit posts capability from WordPress.
• ElliePass no longer intercepts or blocks editing an existing post.
• WordPress remains responsible for deciding which existing posts a user may edit.
• Create posts remains guardable before the new-post editor opens.

0.2.5 clearer login and activation messages

• Login now says Verification required to sign in and explains the specific ElliePass requirement when known.
• New account activation now says Verification required to activate your account and explains the specific requirement.
• Human, Verified Identity, age, and location requirements use action-specific copy consistent with the in-page modal experience.

0.2.6 protected listing content

• Protected content no longer leaks through home, archive, category, tag, author, or search listings.
• Both full-content loops and excerpt-based themes are covered.
• Unqualified members see a protected-content placeholder in listings.
• Post title and ordinary public metadata remain visible.
• Clicking the title opens the singular view where the ElliePass verification modal is shown.

0.2.7 protected-content preview and internal cache settings

• Removed Durable cache and Location cache controls from the WordPress Settings UI.
• Cache timing remains controlled internally by the plugin.
• Added Protected content preview with None, 25, 50, or 100 words.
• Default protected listing preview is 50 words.
• Preview text is generated from the original post body after stripping shortcodes and HTML, then hard-limited to the configured word count.
• Singular protected content remains fully hidden behind ElliePass verification.

0.2.8 singular protected-content preview

• The configured protected-content preview now appears on the actual protected post/page as well as archive listings.
• The full body remains hidden.
• After the verification modal is closed, the preview remains visible with a persistent Verify to view full content button.
• Logged-out visitors see Sign in to view the full content instead.
• The same None / 25 / 50 / 100 word setting controls both listing and singular previews.

0.2.9 protected-content verification CTA

• The persistent Verify to view full content button no longer navigates directly to ElliePass.
• It reopens the same verification-required modal on the current post/page.
• Only the modal's Continue with ElliePass action leaves WordPress for verification.