Init User Engine – Gamified, Fast, Frontend-First -- WordPress 插件

开发者	brokensmile.2103
更新时间	2026年10月4日 01:16
PHP版本:	7.4 及以上
WordPress版本:	7.1
版权:	GPLv2 or later
版权网址:	版权信息

1.6.7 – October 3, 2026

Performance (large sites): rebuilt the database indexes used by the Inbox, after a production slow query log showed "Mark All as Read" (UPDATE … WHERE user_id = … AND status = 'unread') taking 2.5 seconds on a 1.2M-message Inbox
New composite index user_status (user_id, status): the unread badge count, "Mark All as Read" and the Unread tab now read the index only instead of loading every message row of the user (about 181 → 3 pages read per unread count in our 1.25M-row benchmark)
New composite index user_pinned_created (user_id, pinned, created_at): the Inbox list (ORDER BY pinned DESC, created_at DESC) is read straight from the index, no more filesort
Dropped single-column user_id indexes on the Inbox, Transaction log and EXP log tables. They were fully covered by composite indexes that start with user_id, so they only cost extra writes and disk space (every Coin/EXP change writes to these tables)
Safe on big databases: the index upgrade runs in the background through WP-Cron, never inside a page load (small and new sites are upgraded instantly). It uses online DDL (ALGORITHM=INPLACE, LOCK=NONE), so reads and writes keep working while indexes are built; it gives up after 3 seconds if it has to wait for a table lock, instead of making other queries queue behind it, then retries an hour later (up to 24 times); and a lock option makes sure only one process ever runs it. If WP-Cron is not running, the upgrade runs on the next admin page load after the event is more than an hour late
You can also run it yourself during quiet hours (replace wp_ with your table prefix); the plugin detects the new indexes and marks the upgrade as done: ALTER TABLE wp_init_user_engine_inbox ADD KEY user_status (user_id, status), ADD KEY user_pinned_created (user_id, pinned, created_at), DROP KEY user_id, ALGORITHM=INPLACE, LOCK=NONE; then ALTER TABLE wp_init_user_engine_transaction_log DROP KEY user_id; and ALTER TABLE wp_init_user_engine_exp_log DROP KEY user_id;
Performance: the weekly orphaned-Inbox cleanup no longer runs a single DELETE … LEFT JOIN over the whole Inbox table. That statement scanned and locked every row (even when nothing needed deleting), blocking every member's Inbox actions while it ran; in our benchmark a member's "Mark All as Read" waited 7.9 seconds. It now walks the distinct user IDs through the index, checks them against the users table in batches of 500 and deletes only orphaned messages, at most 1,000 rows per statement (0.45 s and no table-wide locks when there is nothing to delete)
Performance: Inbox Statistics → Delete All of This Type now deletes in batches of 1,000 by primary key instead of one DELETE … WHERE type = …, which locked the whole table until done (members' Inbox actions waited 7 seconds while 200k messages were deleted in our benchmark; now under 0.1 second)
Fixed: the orphaned-Inbox cleanup used $wpdb->prefix . 'users' as the users table, which does not exist on Multisite sub-sites (the users table is shared network-wide). It now uses $wpdb->users
The new background event is cleared on deactivation along with the plugin's other cron events

1.6.6 – October 1, 2026

Added Lost Password in Modal (Init User Engine → Settings, right below Login After Register). The "Forgot password?" link in the login modal now opens a lost password form inside the same modal instead of sending visitors to wp-login.php
Enabled by default. Turn it off if your site cannot send emails yet — the link then goes to the default wp-login.php?action=lostpassword page as before
Custom Lost Password URL (Custom Links) still takes priority: when it is set, the link always goes there, whatever this option says
Uses the native WordPress password reset flow: the form posts to wp-login.php?action=lostpassword, so the reset email, lostpassword_form / lostpassword_post hooks and the Turnstile "Lost Password Form" protection all keep working
After submitting, visitors land back on the same page with the modal open: a success notice in the login form when the email was sent, or an inline error in the lost password form (unknown user, empty field, email sending failure, captcha failure). Any other error keeps WordPress's default wp-login.php behaviour so its exact message is still shown
Template lostpassword-form.php can be overridden from your-theme/init-user-engine/; any element can also open it with data-iue="lostpassword"
Added filter init_plugin_suite_user_engine_lostpassword_modal_enabled
Performance: the guest script no longer runs a MutationObserver on the whole <body> (it fired on every DOM change of the page just to attach the password toggle to the registration form, which is already in the page)
Performance: the get_avatar_url filter no longer re-runs every plugin's pre_get_avatar_data callbacks for each avatar; it only applies Init User Engine's own avatar logic (the result is the same)
Performance: the check-in countdown now saves its state on pagehide instead of beforeunload, so browsers can keep the page in the back/forward cache
Fixed: the deactivation hook was registered against includes/core.php instead of the main plugin file, so it never ran and the plugin's cron events stayed scheduled after deactivation. All three recurring events are now cleared on deactivation (they are scheduled again automatically on reactivation)
Fixed: the twice-daily cleanup compared transient expiry times (stored in UTC) with the site's local time, so on sites ahead of UTC it could delete registration captchas and rate-limit counters that had not expired yet
Fixed: on sites using "Plain" permalinks (REST URL like ?rest_route=/inituser/v1), requests that add their own query string were malformed: the registration math captcha never loaded, and Inbox, Transaction History and Experience Log pagination failed. Query strings are now appended with & when the REST URL already has one
Updated .pot/.po/.mo translation files with the new strings introduced above (Vietnamese translation included), regenerated with WP-CLI

1.6.5 – September 24, 2026

Added Streak Recovery (Init User Engine → Settings → Streak Recovery). When a member misses a few days, they can now spend Coin to keep their check-in streak instead of losing it
Two new settings: Missed Days Allowed (how many missed days can be covered, 0 = feature off) and Coin Cost per Missed Day (0 = free). Off by default, so nothing changes on existing sites until an admin turns it on
Clicking Check In after a gap opens the plugin's standard modal showing the current streak, missed days, total cost and the member's balance, with two choices: keep the streak (pay), or reset it and check in anyway. Closing the modal does nothing. Missing more days than allowed simply resets the streak as before
Keeping a streak covers the missed days but does not count them as check-ins: the streak continues from where it was and today adds +1, so streak milestone rewards (7/30/90…) behave exactly as before
Every charge is written to the Coin transaction log as a deduction with a readable reason (e.g. "Kept check-in streak (2 missed days)"), shown in the member's Transaction History and in the admin user metabox
The frontend only ever shows the configured Coin Label, never a hardcoded "Coin"; all new frontend and error strings are label-aware
Safety: the price is re-checked on the server against what the member was shown (rejected if it changed), the balance is verified just before charging, and if the log entry cannot be written the Coin is handed back and the streak is left untouched
POST /checkin gained three optional JSON fields: prompt_restore (answer with status restore_available instead of checking in when the streak can be kept — nothing is changed), restore_streak and restore_cost. Clients that don't send them behave exactly as before
Added filters init_plugin_suite_user_engine_streak_restore_max_days and init_plugin_suite_user_engine_streak_restore_cost, and action init_plugin_suite_user_engine_streak_restored
New logic lives in includes/streak-restore.php
Fixed: POST /checkin had no protection against overlapping requests, so two requests fired at the same moment could both pass the "already checked in today" test and reward the same day twice. Check-ins are now serialized per user with the same short-lived mutex pattern used by the exchange endpoints; a request that arrives while another is running gets a 409 busy response
Fixed: modals opened from the logged-in dashboard never played their open animation. The fadeIn/slideDown keyframes referenced by #iue-modal only existed in style-guest.css, which is not loaded for logged-in users. Added namespaced iue-fade-in/iue-slide-down keyframes to style-user.css (so a theme's own fadeIn/slideDown can no longer interfere) plus a prefers-reduced-motion opt-out
Fixed: leaving the Coin Label or Cash Label field empty made the frontend (dashboard data, Referral benefits, exchange and VIP screens) display a blank currency name, and the VIP purchase inbox message could show an empty label. Both now fall back to "Coin" / "Cash" through the shared init_plugin_suite_user_engine_get_coin_label() / ..._get_cash_label() helpers
Fixed: after a failed check-in request (a server error, or a network failure) the check-in button used to switch to "Checked in" or fall back to an untranslated "Check-in" (it read a translation key that was never defined); it now returns to its normal, translated label and shows the error
Fixed: the plugin's activation hook was registered against includes/init.php instead of the main plugin file, so it never ran and the database tables were only created later, on the first admin_init. It now runs on activation as intended (the admin_init version check stays as the upgrade path)
Updated .pot/.po/.mo translation files with the new strings introduced above (Vietnamese translation included), regenerated with WP-CLI

1.6.4 – September 10, 2026

Fixed: permanently deleting a user (from Users → All Users, bulk delete, or the REST Users endpoint) used to leave that user's EXP history and Inbox messages behind in the database forever, since nothing ever cleaned them up after the account itself was gone
Now hooked into WordPress core's deleted_user action (fires for both single-site wp_delete_user() and multisite wpmu_delete_user(), so one hook covers both): as soon as a user is permanently deleted, their EXP log rows and all Inbox messages are deleted right along with it
Coin/Cash transaction log stays untouched on purpose — wallet history feeds into site-wide statistics and reconciliation (total coin/cash ever issued, revenue reports, etc.), so it's intentionally kept even after the user account is gone
iue_* user meta (check-in streak, login bonus flags, profile bonus flag...) needed no extra handling — WordPress core already wipes all usermeta for the user before deleted_user fires
Added action hook init_plugin_suite_user_engine_user_data_purged (fires with the deleted user's ID right after cleanup) so other plugins/add-ons can hook in and clean up their own related data too
No new user-facing strings in this release, so .pot/.po files are unchanged

1.6.3 – September 7, 2026

Added a new "Login After Register" option (Init User Engine → Settings → General, disabled by default). When enabled, a successful registration through the plugin's REST endpoint (/register) immediately signs the new user in (wp_set_auth_cookie() + wp_set_current_user(), followed by the standard wp_login action for compatibility with other plugins/themes) instead of leaving them on the Login form
The frontend register form now reloads the page after a successful auto-login (instead of switching to the Login form) so the UI, nonces, and avatar immediately reflect the signed-in state
Left disabled by default so registration and login remain two explicit, separate steps unless a site owner opts in
Fixed: a failed login attempt from the plugin's login modal (via wp_login_form()) used to fall back to WordPress's default behavior and redirect the visitor to wp-login.php, which felt out of place on sites that never expose that page. Failed logins now redirect back to the exact page the visitor was on, with the login modal automatically reopened and an inline error message (wrong username, wrong password, or missing fields)
Implemented via the wp_login_failed action combined with wp_get_referer(); only intervenes when the login attempt came from a normal frontend page, so logins made directly on wp-login.php or inside wp-admin keep WordPress's native behavior untouched
The redirect uses two short-lived query arguments (iue_login_failed, iue_login_code) that assets/js/guest.js reads once to open the modal and show the right message, then immediately strips from the URL via history.replaceState() so refreshing or sharing the link never re-shows the notice
Refreshed readme.txt — the Features section was rewritten from scratch to match the plugin's actual current feature set (Turnstile/captcha, Require Login gate, Redeem/VIP Codes with CSV export, Inbox Statistics, admin user metabox, and more), several of which had been implemented in past releases but never documented here
Updated .pot/.po translation files with the new strings introduced above (Vietnamese translation included)

1.6.2 – September 4, 2026

Changed: a pinned Inbox message now only stays pinned to the top while it is unread. As soon as it's marked as read (single message or "mark all as read"), it automatically unpins and behaves like any other message, so read messages no longer take up space at the top of the Inbox modal
Implemented by clearing pinned back to 0 in the exact same UPDATE query that already sets a message to read (init_plugin_suite_user_engine_mark_inbox_read() and the "mark all as read" REST endpoint) — no extra query, no change to the Inbox SELECT/ORDER BY, and no new database index needed
Added a one-time backfill (runs once on upgrade, same mechanism already used for schema updates) that clears pinned for any pre-existing message that was already pinned and read before this update
Added a client-side safety net in the Inbox renderer so the pin icon never shows on a read message, even for the brief moment before the backfill above has run
Updated .pot/.po translation files (no new strings were needed for this change; existing ones were already sufficient)

1.6.1 – September 4, 2026

Added Export CSV for both code list screens (User Engine → Redeem Codes / VIP Codes)
New "Export CSV" button next to the "Existing Redeem Codes" / "Existing VIP Codes" heading, exporting the entire list (every page, not just the current one) as a downloadable .csv file
Redeem Codes CSV columns: ID, Code, Type, Locked User ID, Locked Username, Coin Amount, Cash Amount, Max Uses, Used Count, Status, Valid From, Valid To, Created By, Created At, Updated At
VIP Codes CSV columns: same as above, with VIP Days in place of Coin/Cash Amount
Data is streamed straight to the browser in batches of 500 rows so memory usage stays low even on sites with a large number of codes
File is written with a UTF-8 BOM so it opens correctly in Excel, and every cell is sanitized against CSV/formula injection (values starting with =, +, -, @, or a tab are safely prefixed)
Gated behind the manage_options capability plus a dedicated nonce per screen (iue_redeem_code_export_csv / iue_vip_code_export_csv)
Updated .pot/.po translation files with the new strings introduced above (Vietnamese translation included); .mo not rebuilt as part of this change

1.6.0 – September 2, 2026

Added a new "Require Login to Access Site" option (Init User Engine → Settings → General). When enabled, visitors who are not logged in no longer see the site's actual content on any page
Instead, they see a blank page in the plugin's theme color with the built-in login modal opened automatically, so they can sign in without leaving the page
Implemented via template_redirect, so wp_head()/wp_footer() still run in full — the plugin's own login modal, and every other theme/plugin hook attached to those actions, keeps working normally
REST API, AJAX, cron, feed, and robots.txt requests are always excluded and are never blocked by this option
Added filter init_plugin_suite_user_engine_require_login_bypass so other plugins/themes can exclude specific requests (e.g. a payment callback URL) from the gate
New dedicated assets/css/require-login.css and assets/js/require-login.js files render the gate's background and auto-open the login modal, kept separate from PHP output for coding-standards compliance
Fixed: the frontend guest script (guest.js) only exposed window.openLoginModal (and wired up Escape-to-close, Alt+L, and hash-triggered opening) when an avatar element was present on the page. Pages without the avatar shortcode/widget — including the new Require Login gate — could not open the login modal at all. The avatar element is now optional; the modal and its triggers work on any page as long as the modal itself is rendered (always the case via wp_footer)
Updated .pot/.po translation files with the new strings introduced above (Vietnamese translation included); .mo not rebuilt as part of this change View full changelog (all versions): Init User Engine – Changelog

Init User Engine – Gamified, Fast, Frontend-First

标签

下载

详情介绍:

安装:

屏幕截图:

常见问题:

更新日志: