Àpèjúwe
EDH Restricted Site gates access to your entire WordPress site behind a simple email-domain verification flow.
Visitors enter their email address via a shortcode or Gutenberg block. If their emailÌtumọ̀ Yorùbá: ’s domain is on your configured allow-list, they receive a one-time verification link by email. Clicking it grants them a cookie-based access pass for a period you control. Anyone without that pass is redirected to the verification form. Users who can manage options always have full access, regardless of settings.
Features
- Email-domain allow-list, managed from an admin settings page (one domain per line)
- Choose which pages are exempt from the access check (e.g. the verification page itself, a privacy policy page)
- Verification form available as a shortcode (
[edhrs_verification_form]) or as a block (“Email Verification Form”) - Configurable “From” address for verification emails
- Configurable access-cookie duration
- Configurable rate limiting on verification emails, per address and per IP address
- Configurable button colour via WordPressÌtumọ̀ Yorùbá: ’s native colour picker
- A verification-request log (linked from the Settings page and the Plugins screen) showing each email requested and whether its link has been used, with automatic retention-based cleanup
- No build tooling required
Àwọn ìdí
Plugin yìí pèsè 1 ìdí.
- Email Verification Form Displays the email verification form used to gain access to this site.
Ìgbéwọlẹ̀
- Upload the plugin files to
/wp-content/plugins/edh-restricted-site, or install the plugin through the WordPress plugins screen. - Activate the plugin through the “Plugins” screen.
- On activation, defaults are seeded automatically: your siteÌtumọ̀ Yorùbá: ’s own domain is added to the allow-list, your front page is set as the unrestricted page, access denied page, and post-verification redirect, and your siteÌtumọ̀ Yorùbá: ’s admin email is used as the sender address.
- Visit Settings Restricted Site to review and adjust:
- Allowed email domains
- Pages that donÌtumọ̀ Yorùbá: ’t require verification (at least one must remain selected)
- The access denied page visitors without access are sent to
- The page shown after a successful verification
- The “From” email address for verification emails
- How many days the access cookie lasts
- How many verification emails a single address, or a single IP address, can request per hour
- How many days verification-request log entries are kept before automatic deletion
- Add the
[edhrs_verification_form]shortcode, or the “Email Verification Form” block, to one of your unrestricted pages. - Use the View Logs link at the top of the Settings page (or Logs next to Activate/Deactivate on the Plugins screen) to see whoÌtumọ̀ Yorùbá: ’s requested access and whether their link has been used.
FAQ
-
Does this restrict access for administrators too?
-
No. Logged-in users who can manage options — administrators on a single site, plus Super Admins on multisite — always have full access, regardless of the verification/cookie state.
-
All my visitors are in one office and theyÌtumọ̀ Yorùbá: ’re hitting the rate limit
-
TheyÌtumọ̀ Yorùbá: ’ll all be sharing one internet connection, so they share an IP address, and the per-IP limit counts them as a single visitor. Raise Requests per IP address (per hour) under Settings Restricted Site, or set it to 0 to switch that limit off entirely. The per-address limit is unaffected either way.
-
Can I allow more than one email domain?
-
Yes. Enter one domain per line in the “Allowed email domains” field under Settings Restricted Site.
-
What happens if I donÌtumọ̀ Yorùbá: ’t select any unrestricted pages?
-
The settings page wonÌtumọ̀ Yorùbá: ’t let you save an empty selection — at least one page must remain unrestricted, since the “Access denied page” setting (where visitors without access are sent) must always be one of them.
-
Do I need to use the shortcode and the block?
-
No, either one works on its own; use whichever fits your page-building workflow.
-
Does the log record rejected or invalid attempts?
-
No, only successful sends Ìtumọ̀ Yorùbá: – a valid, allowed-domain email that a verification email was actually sent for. Invalid emails and disallowed domains are never logged.
-
What happens to old log entries?
-
TheyÌtumọ̀ Yorùbá: ’re deleted automatically once theyÌtumọ̀ Yorùbá: ’re older than the “Log retention (days)” setting (default 90 days), via a daily background task. Deactivating the plugin doesnÌtumọ̀ Yorùbá: ’t delete any log data; deleting the plugin entirely does.
Àwọn àgbéyẹ̀wò
Kò sí àwọn àgbéyẹ̀wò fún plugin yìí.
Àwọn Olùkópa & Olùgbéejáde
“EDH Restricted Site” jẹ́ ètò ìṣàmúlò orísun ṣíṣí sílẹ̀. Àwọn ènìyàn wọ̀nyí ti ṣe ìkópa sí plugin yìí.
Àwọn OlùkópaTúmọ̀ “EDH Restricted Site” sí èdè rẹ.
Ṣe o nífẹ̀ẹ́ sí ìdàgbàsókè?
Ṣàwárí koodu, ṣàyẹ̀wò ibi ìpamọ́ SVN, tàbí ṣe àgbékalẹ̀ sí àkọsílẹ̀ ìdàgbàsókè nípasẹ̀ RSS.
Àkọsílẹ̀ àwọn àyípadà
2.1.2
- Documentation only, no code changes: corrected a stale pre-2.0.0 shortcode in README.md and brought its feature and setup lists back in line with this file.
2.1.1
- Fixed a fatal error in wp-admin for any logged-in user without the
manage_optionscapability — an Editor, Author or Subscriber opening the dashboard got a white screen.add_options_page()returns false for them, and assigning that to a string-typed property is a TypeError under strict types. Present since 1.5.x, not new in 2.1.0. - Applied the same guard to the settings option read, which would otherwise fatal on every request rather than only in wp-admin if the option row were ever corrupted.
- Fixed an infinite redirect loop on an unconfigured install — with no unrestricted pages set, the access-denied redirect pointed at a page that was itself gated. The gate now fails closed with a 403 message instead of looping.
2.1.0
- Security: fixed a bypass that let anyone unlock the whole site by setting the access cookie to an arbitrary value — it was only ever checked for presence, never validated. Cookies are now signed with
wp_salt('auth')and verified on every request. - Verification links no longer carry the visitorÌtumọ̀ Yorùbá: ’s email address, keeping it out of browser history, access logs and
Refererheaders. Requesting a second link no longer invalidates the first. - Added configurable rate limiting on verification emails — per address and per IP address, either settable to 0 for no limit.
- The plugin is now fully translatable; previously no string used the declared text domain.
- The administrator bypass now checks the
manage_optionscapability rather than theadministratorrole name, so multisite Super Admins are covered. - Further plugin-review fixes: allowed-domain validation, output escaping in the form, no email address in the “failed to store token” error log, removed the empty
Plugin URI:header. - Expired options-table fallback tokens are now cleaned up by the existing daily cron event.
2.0.0
- Renamed every global identifier prefix from
edh/edh_rstoedhrs(options, log table, cookie, shortcode, AJAX action, cron hook, classes, constants) per WordPress.org plugin review requirements. Breaking: existing installs lose their saved settings and log history when updating Ìtumọ̀ Yorùbá: – reconfigure under Settings Restricted Site. - The shortcode is now
[edhrs_verification_form]. - Removed the “If you get stuck, email…” line from the verification email.
- Added a “Button text colour” setting, controlling the text colour of both the frontend formÌtumọ̀ Yorùbá: ’s submit button and the emailÌtumọ̀ Yorùbá: ’s “Verify Email Address” button. The “Button colour” setting now also applies to the emailÌtumọ̀ Yorùbá: ’s button.
- Verification email styles are now fully inline for better email-client compatibility.
- Additional input-sanitization and SQL-hardening changes from the WordPress.org plugin review.
1.5.5
- Fixed a “Text Domain” typo (
edh-resticted-siteedh-restricted-site) and renamed the main plugin file to match.
1.5.4
- Added a “Back to Settings” button to the Logs page.
1.5.3
- Fixed the Logs page showing no heading above the table.
1.5.2
- Fixed two more Plugin Check warnings from 1.5.1Ìtumọ̀ Yorùbá: ’s log-viewer query fix.
1.5.1
- Fixed remaining Plugin Check warnings from 1.5.0Ìtumọ̀ Yorùbá: ’s log-viewer queries.
- “Restricted Site Logs” is no longer a separate entry in the Settings menu Ìtumọ̀ Yorùbá: – use the “View Logs”/”Logs” links instead.
1.5.0
- Added a verification-request log (Settings Restricted Site Logs): email address, requested date, Pending/Used/Expired status, and used date for every successful verification send.
- Added a “Log retention (days)” setting Ìtumọ̀ Yorùbá: – old entries are purged automatically.
- Added “Settings”/”Logs” links on the Plugins screen and a “View Logs” link on the Settings page.
- Added uninstall cleanup for the new log table and its scheduled task.
1.4.0
- Replaced the fixed-palette button colour picker with WordPressÌtumọ̀ Yorùbá: ’s native colour picker, accepting any valid hex colour.
1.3.0
- Fixed an edge case where the static front page or “posts page” couldnÌtumọ̀ Yorùbá: ’t be correctly selected as an unrestricted page.
- Hardened the access check against caching plugins/CDNs serving a gated response to the wrong visitor.
- Added optional debug logging for diagnosing access-check behaviour.
1.2.2
- “Unrestricted pages” and “Access denied page” now only offer published pages.
- Renamed the “Default page” setting to “Access denied page” for clarity.
1.2.1
- Fixed a remaining Plugin Check input-sanitization warning on the verification linkÌtumọ̀ Yorùbá: ’s email parameter.
1.2.0
- Added an explicit “Access denied page” setting for where visitors without access are sent, replacing the previous implicit reliance on the first selected unrestricted page.
- Fixed several WordPress.org Plugin Check compliance issues (block API version, output escaping, input sanitization, packaging).
1.1.0
- Added a “Button colour” setting, chosen from WordPressÌtumọ̀ Yorùbá: ’s default editor colour palette.
- Fixed the verification formÌtumọ̀ Yorùbá: ’s stylesheet not loading in the block editor.
1.0.0
- Initial release.
- Email verification flow with a domain allow-list, shortcode and Gutenberg block, and cookie-based access passes.
- Admin settings page for allowed domains, unrestricted pages, redirect-after-verification page, sender email address, and cookie duration.
- Verification tokens stored as transients with an automatic options-table fallback for reliability.
