3.6.4 (2026-10-12)
- fixed: the scheduled clean up could exhaust PHP's memory and delete nothing, on a forum holding a large backlog of recorded registration data. It now deletes in batches, and asks the database only for the user ids it needs rather than loading whole rows, so how much one run can get through no longer depends on how much has accumulated
- a backlog builds up on any forum that has the clean up switched off, or that has had Delete User Agent data after left empty — the clean up declines to run in either case, which is safe but silent. Switching it on, or filling that box in, is what sends the first run at the whole backlog, so this fix matters most on a forum where nothing has been pruned for a long time.
approval-queue-plus:configreports how many rows are eligible now
3.6.3 (2026-10-10)
- now requires PHP 7.4 or later — above the PHP 7.0 that XenForo 2.2 itself requires, and needed by the new command line checks below. XenForo 2.3 already requires PHP 7.2, so this affects only a XenForo 2.2 forum still running PHP 7.3 or older
- new: two command line checks.
approval-queue-plus:configprints what the Approval Queue is set up to show and what has been recorded;approval-queue-plus:validatechecks that it all works — that the queue's template modifications still apply, that the Cloudflare header map still produces a location, that the View User Agents permission is present, and that the scheduled clean up will run when it says it will. Neither command writes, deletes or sends anything, so both are safe to run on a live forumapproval-queue-plus:validateexits 1 when a check failed and 0 otherwise, and--strictexits 2 for warnings alone, so a monitoring script can watch a forum's configurationapproval-queue-plus:validatereports a clean up that can never run: switching it on while leaving Delete User Agent data after empty makes the scheduled prune decline every time, which is safe but silent- the add-on now tells the Admin API add-on that none of its settings are credentials, so they can be reported rather than withheld
3.6.2 (2026-10-04)
- fixed: registration failed for any client that sent no
User-Agentheader — browsers always send one, so ordinary sign-ups were unaffected, but a scripted or API registration was refused- fixed: clearing the Delete User Agent data after box no longer deletes every approved user's recorded data on the next scheduled clean up
3.6.1 (2026-09-22)
- the Cloudflare location in the Approval Queue now ends with the continent — for example Sydney, NSW, Australia (Oceania) — for users who registered on 3.6.0 or later, which is when continent began to be recorded
3.6.0 (2026-09-20)
- now requires XenForo 2.2.0 or later
- fixed: Cloudflare continent information was never recorded, because the
CF-IPContinentheader was misspelled internally — it is now recorded, and shown on the Cloudflare location test page under Tools > Checks and Tests- fixed: the user agent clean up option's on/off setting is now honoured — switching it off did not previously stop the scheduled clean up from running
- the
viewUserAgentspermission is nowhampelAqpViewUserAgents, so that it cannot clash with a permission of the same name from another add-on — existing permission settings are migrated automatically during the upgrade
3.5.3 (2025-12-11)
- run enqueuePostUpgradeCleanUp during upgrades if we're running XF2.3+
Minor bugfix to explicitly enforce admin permissions on admincp tools
Fixes a critical upgrade bug (doesn't apply to new installs), where certain columns didn't get created
This version adds support for showing Cloudflare geo-location data for sites running Cloudflare. To enable the display of Cloudflare location data, you must turn on Managed Transforms in your Cloudflare admin console. Go toRules > Transform Rules > Managed Transformsand enable Add visitor location headers.
Changes in this release:
- update permission phrase to make it clear where the permission comes from
- rename user agent table from xf_user_agent to xf_aqp_user_agent to comply with resource standards
- bugfix - gracefully handle case where user agent doesn't exist for user
- fix approval_item_user template modification for compatibility with XF 2.3
Minor bugfix: use regex for one of the template modifications to avoid clobbering changes made by other addons
Updates from v3.2.0 (unreleased)
Updates from v3.3.0
- added User Agent to the list of fields shown
- added permissions for who can view User Agents
- automatic cleanup of old UserAgent data for approved users
- hide core user item header from queue
- split out user email into separate line
We use essential cookies to make this site work, and optional cookies to enhance your experience.