WordPress membership sites often need public account requests without giving every registrant immediate access. In this case, the original registration flow relied on a hidden, password-protected link, but a new approval workflow still allowed users to log in before approval and did not reliably notify administrators. The solution was to expose a clear registration link, enforce pending and denied account states, improve user-facing messages, and correct an email-delivery problem involving Mailgun.
Issue background
A membership site wanted prospective members to request an account from a visible registration link. The previous process used a hidden URL and a shared password to control who could register.
Once administrator approval was introduced, the hidden-link approach was no longer necessary. However, testing uncovered several problems:
- New registrants received access immediately, before approval.
- A denied account could still log in.
- Users did not consistently receive clear pending or denied status messages.
- Administrators did not always receive new-registration notifications.
- Existing email addresses produced an unclear “invalid” message.
The desired workflow was simple: anyone could submit a registration request, but only approved users could access protected member content.
Diagnosis
The registration form itself was working, but the site was treating account creation and account authorization as the same event. A WordPress user record became active as soon as the form was submitted, which bypassed the intended review process.
The approval state also was not being enforced consistently during login. Marking a request denied did not automatically prevent the associated WordPress account from authenticating.
Notification testing revealed a separate issue. The approval logic and notification recipients were configured correctly, but messages did not reliably leave the staging site. Additional testing and email logging identified Mailgun as the source of the delivery problem in that environment. After Mailgun was disabled on staging, the registration emails sent correctly through the site’s fallback mail method.
Resolution steps
- Add a visible registration link. Place a “Member registration” or “Request an account” link in the main navigation for logged-out visitors. Remove the shared password requirement when administrator approval is the actual access control.
- Separate registration from approval. Store new registrations in a pending state rather than granting full member access immediately.
- Enforce account status during login. Check the approval state every time a user authenticates. Pending and denied users should be blocked even if a WordPress account record already exists.
- Delay the welcome message. Do not send the normal welcome or full-access email when the registration form is submitted. Send a confirmation explaining that the request is under review.
- Send approval and denial notifications. Trigger the appropriate message when an administrator changes the account status. Keep the wording explicit so users know whether access was approved or declined.
- Route administrator notifications correctly. If approval responsibility depends on a selected membership type, region, chapter, or group, verify that the form choice maps to the correct administrator.
- Improve duplicate-email validation. Replace a vague error such as “invalid” with a clear message, for example: “Our records show that you already have an account associated with that email address.”
- Test with clean accounts. Use new email addresses and private browsing sessions. Existing sessions or previously approved accounts can make an unapproved user appear to have access.
- Add email logging. Record the recipient, subject, timestamp, and delivery result for registration, approval, and denial messages.
- Isolate the mail provider. When the site triggers notifications but recipients do not receive them, test the SMTP or transactional email integration separately. In this case, disabling Mailgun on staging restored delivery.
- Clear caches after message changes. Page or object caching can cause old validation text and registration screens to remain visible during testing.
- Run the complete workflow. Test submission, pending access, administrator notification, approval, denial, duplicate-email handling, logout, and login with both approved and blocked accounts.
A user’s display status in a directory and their true authentication status may be controlled by different systems. Confirm that the approval value used by the registration workflow is also checked by the login process, rather than relying only on a label shown in the user list.
Final outcome
Logged-out visitors could access a visible member-registration link without a shared password. New accounts remained blocked until approval, and denied users could no longer log in.
The registration interface displayed clearer pending and duplicate-email messages. Email logging made the notification flow easier to verify, and disabling the problematic Mailgun configuration on staging restored administrator and user notifications during testing.
The completed workflow made registration easier for legitimate applicants while preserving administrative control over protected membership content.
For help building approval-based WordPress registration, troubleshooting membership access rules, or fixing registration email delivery, contact Freshy.
