Can’t change register link

In the plugin’s General Settings page (/wp-admin/admin.php?page=user-registration-settings&tab=general), changing the Registration Page dropdown triggers a JavaScript error and the AJAX verification call fails. The setting cannot be reliably updated through the admin UI. In addition, the login form’s “Register a New Account” link does not point to the configured registration page — it instead points to the current page where the login form is rendered.

Steps to reproduce

1. Install User Registration & Membership 5.1.6
2. Have a published page containing a registration form (in our case, page ID 17658 at /registration/)
3. Have another page containing the [user_registration_login] form (in our case /submit-or-manage-a-grant/)
4. Go to User Registration & Membership → Settings → General → Pages
5. Open browser DevTools (Network + Console tabs)
6. Change the Registration Page dropdown to the registration page

Expected: Setting saves cleanly, dropdown reflects the new selection, and the “Register a New Account” link on the login form points to the chosen page.

Actual:

• The AJAX call to admin-ajax.php with action=user_registration_membership_verify_pages returns HTTP 400 with response body 0
• A JS error follows in settings.min.js?ver=5.1.6: Uncaught TypeError: Cannot read properties of undefined (reading 'status')
• The “Register a New Account” link on /submit-or-manage-a-grant/ continues to point to /submit-or-manage-a-grant/ (current page) instead of /registration/

AJAX request payload

action:   user_registration_membership_verify_pages
type:     user_registration_member_registration_page_id
value:    17658
security: d4118f3e51

Response: 0 (HTTP 400)

A response of 0 from admin-ajax.php indicates that no PHP handler is registered for the action, OR the handler is exiting early via die('0') (typically a failed nonce or capability check, or an internal validation bail-out).

Likely root cause — option key name mismatch

The AJAX call sends:

type: user_registration_member_registration_page_id

…but the actual option stored in wp_options is:

user_registration_registration_page_id

(note: no member_ prefix). Verified directly in the database:

sql

SELECT option_name, option_value 
FROM wp_options 
WHERE option_name LIKE '%registration%page%';

Returns:

• user_registration_default_form_page_id = 17661
• user_registration_myaccount_page_id = 14705
• user_registration_registration_page_id = 17658

The JS in settings.min.js and the PHP handler appear to be out of sync regarding the option key. The handler likely doesn’t recognize user_registration_member_registration_page_id as a valid key and bails with 0.

Related symptom — login form “Register a New Account” link

On any page containing the URM login form, the “Register a New Account” link is rendered with the wrong URL. Inspected HTML:

html

<div class="user-registration-register register " data-field="registration-setting">
    <a href="https://www.example.com/submit-or-manage-a-grant/">
        Register a New Account
    </a>
</div>

The href points to the current page rather than the configured registration page. Because the settings UI is broken (above), there is no way for a site admin to fix this through the supported interface.

Environmental notes

• Single plugin install — no separate/legacy “User Registration Membership” addon present
• No caching plugin or CDN was masking the issue (verified via incognito + cache clears)
• Logged in as Administrator (full manage_options capability)
• Hard-refreshing the settings page does not help (so it’s not a stale nonce)
• The page being assigned (ID 17658) is published and contains a working [user_registration_form] shortcode/block

Workaround we deployed

Since the Settings UI cannot save the change, we updated the option directly in the database:

sql

UPDATE wp_options 
SET option_value = '17658' 
WHERE option_name = 'user_registration_default_form_page_id';

We also confirmed the existing global URL setting:

sql

UPDATE wp_options 
SET option_value = 'https://www.example.com/registration/' 
WHERE option_name = 'user_registration_general_setting_registration_url';

However, the login form’s “Register a New Account” link continued to render with the current-page URL regardless of these option values, suggesting the front-end render path is not reading the global setting (or is reading a different setting we couldn’t locate).

As a final workaround, we added a the_content filter to rewrite the link’s href at output time:

php

// Workaround for URM 5.1.6 bug: login form's "Register a New Account" link
// renders with the current page URL instead of the configured registration page.
// The Settings UI cannot save the registration page selection because the
// AJAX verifier (user_registration_membership_verify_pages) returns 0.
// Remove this filter once the underlying bug is fixed.
add_filter('the_content', function($content) {
    if (strpos($content, 'data-field="registration-setting"') !== false) {
        $content = preg_replace(
            '#(data-field="registration-setting"[^>]*>\s*<a\s+href=")[^"]*(")#',
            '$1' . esc_url(get_permalink(17658)) . '$2',
            $content
        );
    }
    return $content;
}, 20);

This works but is a band-aid — it only catches login forms rendered inside the_content, hardcodes the registration page ID, and bypasses the plugin’s intended configuration mechanism entirely.

Suggested fixes

1. Reconcile the option key name between assets/js/admin/settings.min.js (sending user_registration_member_registration_page_id) and the PHP handler for user_registration_membership_verify_pages (which appears to expect/operate on user_registration_registration_page_id).
2. Return a meaningful response from the AJAX handler instead of die('0') — even a wp_send_json_error() with a reason string would have made this 10× faster to diagnose.
3. Ensure the login form’s “Register a New Account” link reads from the configured registration page option rather than falling back to the current page URL when the setting is unresolved.

Additional observation

The user_registration_version option in the database is 4.1.5 even though the installed plugin reports 5.1.6. This suggests the version bump did not run during the major upgrade — possibly relevant if any migration logic is keyed off that value.