LocalHero Org

Helping Organisations get organised!

Changelog

Part of LH User Provisioning
  • 1.3.3: Fixed new users not getting the requested role (unclaimed by default) on the site they were provisioned for. wp_insert_user() was giving every new user the site’s default role, so ensure_user_on_site() saw them as already a member and never applied the requested role. The role is now passed to wp_insert_user() directly when the target site is the current site. BuddyPress last activity is now seeded once, from the account’s registration date, for any user with no last activity yet, whether or not the Extended Profiles component is active. Provisioning and cleanup no longer bump an existing user’s last activity to the current time, so filling in an existing account’s details no longer makes it look recently active.
  • 1.3.2: Shortened the Description header to 150 characters or fewer, the wordpress.org limit that the compiled readme.txt enforces, so the plugin’s readme compiles and it can be pushed (lh-tasks 147801, part 5). No functional change.
  • 1.3.1: Trim readme.md down to the minimal rule-2 shape (one-paragraph description, installation, links to the canonical portfolio doc home and changelog doc-section) now that full documentation lives in lh-portfolio.
  • 1.3.0: Two changes. First, ensure_nicename_matches_id() now writes via a direct SQL UPDATE instead of wp_update_user() — this is the actual fix for the 1.2.1 collision bug (that release added a guard, but the underlying write still routed through wp_update_user(), whose nicename-uniqueness dedup logic was found to still misfire against a user’s own already-correct nicename in some cases, since that logic is designed for human-chosen slugs that can legitimately collide and a numeric ID-derived nicename never can). Second, added user_register/profile_update hooks (priority 20) so login-matches-email and nicename-matches-ID are now enforced in real time for every user created or updated anywhere on the network, not just accounts provisioned through this plugin’s own API — both guarded, both raw SQL, so a no-op check is a single cached read and there’s no re-entrancy risk. This supersedes the old standalone “LH Email Usernames” plugin, which can now be deactivated/removed.
  • 1.2.1: Fixed a real bug: ensure_nicename_matches_id() had no early-return guard (unlike its sibling ensure_login_matches_email()), so it called wp_update_user() unconditionally on every invocation — including the redundant calls that already happen twice per provisioning (create_user() then user_cleanup()) and again on every later cleanup/login/cron pass. WordPress’s own nicename-uniqueness check in wp_update_user() found the user’s own current nicename already present under what it read as a different login context and “resolved” it by appending -2; each further redundant call repeated this against the previous call’s output, compounding into nicenames like 1015925-2-2 or worse. Added the same before-and-after guard ensure_login_matches_email() already used, so the write is skipped whenever the nicename is already correct. Also extended integrity_check()’s query to independently check user_nicename != ID (previously it only checked user_login != user_email), so the accounts already left with a compounded nicename self-heal on the next hourly run instead of needing a manual fix. (Superseded by 1.3.0 — the guard alone wasn’t sufficient; the fix was moving off wp_update_user() entirely for this field.)
  • 1.2.0: Added a “Provisioned Via” column to the Network Admin → Users screen (wpmu_users_columns / manage_users_custom_column), showing each user’s lh_provisioning_source and lh_provisioning_action usermeta. Previously this provenance data was written on every provision but never surfaced anywhere in wp-admin. Users with no provenance meta show an em dash.
  • 1.1.0: Fixed alias-compliance gap: ensure_user() previously called a bare get_user_by(’email’, $email), bypassing LH User Identity’s documented alias-resolution pattern. An email that was a registered alias (rather than an account’s primary email) would return a false “no such user” result and create a duplicate account instead of recognising the existing one. Added resolve_existing_user_by_email(), which checks wp_users then falls back to the lh_user_identity_get_user_by_email_fallback filter, and used it in ensure_user(). Also exposed this as a new public wrapper function, lh_user_provisioning_resolve_user(), for other LH plugins that need alias-aware “does this user exist” checks without creating a user.
  • 1.0.0: Initial release.

If you like this plugin please consider making a donation to further development