Memory Wiki

Let me start by reading the existing mu-plugin and understanding its current state.

Now let me check if Nextend is installed and look at how it creates users, to understand if the email-as-username change is needed.

The Nextend plugin is just a skeleton. Let me now make all the changes to the mu-plugin. I'll proceed with all three tasks. First, let me add the **Task 1** code — changing "Username" to "Email" on the BP login form:

Good, now I need to add the `nsl_ensure_email_as_username()` call into both existing Nextend hooks (sections 5). Let me update both:

Now let me verify the complete file and run PHP syntax check:

PHP lint passes clean. Let me do a final full read to confirm the end of the file is intact:

All changes are complete. Here's a summary of what was done: --- ## Summary **File modified:** `/var/www/html/wp-content/mu-plugins/nextend-pro-unlock.php` (337 → 426 lines, PHP lint: clean) ### Task 1: BP login form — Username → Email (lines 290–336) Three-layer approach to ensure the label changes reliably: 1. **`bp_login_form_args` filter** (line 298): Directly sets `label_username` to `'Email'` in BP's login form args — the cleanest PHP-side approach for the `<!-- wp:bp/login-form /-->` block 2. **`gettext` fallback** (line 306): Catches any remaining "Username" string rendered on the BP login page across WordPress's default, buddypress, and core text domains — scoped with `bp_is_login_page()` so it doesn't touch anything elsewhere 3. **Inline JS via `wp_footer`** (line 322): Adds `placeholder="Enter your email"` to the `#user_login` input field — only fires on the BP login page ### Task 2: Google signups — email as username (lines 338–369) Added `nsl_ensure_email_as_username()` helper function: - Compares `user_login` vs `user_email` after Nextend creates the user - If different, sanitizes the email with `sanitize_user($email, false)` (preserving `@` and dots) and updates via `wp_update_user()` - Called from **both** Nextend hooks: - `nsl_register_new_user` — only when `$provider === 'google'` - `nsl_google_register_new_user` — always runs (provider-specific) This ensures the login credential (email) and username are the same, so the "Email" label change works seamlessly — users type their email in the field and it matches their stored username. ### Task 3: Existing PMPro + BP hooks intact The original `pmpro_changeMembershipLevel(2, ...)` and `bp_core_new_user_activity(...)` calls are **completely untouched** in both hooks (lines 159–171, 183–192). The email-as-username logic runs *before* them as an independent step, so the membership assignment and BP profile initialization continue to fire normally.