Queue Ajax Calls Performantly

Reduce server load and increase reliabilty considerably by queuing selected Ajax and REST calls and process them in bulk later on. Load the entire WP system once for every x request. The mechanism is based on catching the calls early in the WP lifecycle via an MU plugin, santizing and queuing. The queue system is based on Automattic's own Action Scheduler plugin. The fields for sanitiation should be defined for security reasons. Processing the calls : the calls are processed in bulk via a hook that is run by CRON. Who is it for At this stage the plugin is a developer level plugin and is intended to be used as such. It requires defining fields for sanitation. However, it comes with a basic implementation for the latest PixelYourSite API calls and can be easily activated without further configuration for most cases. The flow

• AJAX or REST call evoked in the client browser ->
• MU plugin catches the call if the configuration includes the specific action or route of the call ->
• Processor ( built-in or user defined ) checks the data and sanitizes it ->
• Data is stored in DB to be handled in queue. The data includes the call's data and cookies ->
• Data is processed in batch via a recurring Action Scheduler hook. The processing is done via the same "Processor".
• A row is completed only when its processor returns true. Failed rows retry with backoff and then remain visible for manual recovery.

Queue reliability Queue rows move through pending, processing, completed, retry, failed, and cancelled states. Rows are claimed atomically one at a time so concurrent runners cannot process the same call. A PHP process that terminates unexpectedly leaves only its active row locked; stale locks are recovered automatically and later calls continue to advance. The settings page shows queue totals grouped by AJAX/REST request and action. Failed rows can be retried, cancelled, or deleted without direct database access. Anonymized endpoint diagnostics When an endpoint request fails validation, the settings page can capture an anonymized diagnostic report. Start capture, reproduce the rejected request, and then use Copy debug report. Capture stops after the first validation failure or after ten minutes. The report includes environment and processor configuration, the validation reason, and request field names, types, and sizes. It does not include request values, cookies, URLs, domains, IP addresses, user IDs, event IDs, nonces, or authorization data. Replay processors The admin Replay Processors builder supports sanitation-only integrations. Define an AJAX action or REST route, validation policy, and allowed parameter types. QACP then validates the captured request and internally replays its original WordPress handler during queue processing. Custom PHP processors remain available when an integration needs specialized processing logic. Basic terminogoly Processor : A class/instance that is used to define the data map of fields for sanitation and later on, for batch processing. In many cases, the Processor will be quite simple. Please check the built-in Processor class "class-pys.php" under the "qacp/Processors" directory. Data Map : The map of fields and their respectable sanitation functions. There's an example in the "qacp/qacp-how-to.txt" file. REST route key : A configured REST route prefixed with "rest:", for example "rest:pys-facebook/v1/event". Things to Remember

• The Processor should define clearly what are the received fields and their sanitation functions.
• The action and processor should be registerd. There's an example in the "qacp/qacp-how-to.txt" file.
• A Processor must return true after successful processing. False, WP_Error, and exceptions are treated as failures.

Hooks

• qacp/processors/active_processors
• qacp/processors/actions
• qacp/processors/identify_processor
• qacp/processors/instance_by_action_name
• qacp_before_batch_processing
• qacp_before_process_entry_{$_action_name}
• qacp_before_process_entry
• qacp_process_one_entry_{$_action_name}
• qacp_process_one_entry
• qacp_mark_event_finished
• qacp_after_process_entry_{$_action_name
• qacp_after_process_entry
• qacp_after_batch_processing

1.1.14

• Added screenshots

1.1.13

• Add a Tests section with a guest-request button, editable sample text, HTTP and validation results, and copyable diagnostics.
• Send the test from the browser without cookies or login credentials, authorized by a short-lived, single-use token issued only to administrators.
• Exercise a dedicated MU test endpoint, the configured PixelYourSite REST validator, and the shared queue writer. Verify and remove an inert cancelled test row without sending tracking events.
• Report configuration, validation, storage, cleanup and request errors. This test does not verify scheduled queue processing or delivery to Meta.

1.1.12

• Fix the WooCommerce HPOS compatibility declaration to reference the main qacp.php plugin file instead of class-qacp.php, resolving the FeaturesController "Invalid plugin file" log message.

1.1.11

• Verify installed MU catcher contents during normal plugin startup and repair stale, missing, or relocated copies, even when the version number has not changed.
• Replace the MU file through a verified temporary file instead of deleting the working file first. Retry failed updates without recording a successful version upgrade.
• Request OPcache invalidation after replacement and on activation, version upgrades, and diagnostic capture startup.
• Fix activation and deactivation hook paths on Linux servers.
• Add an admin notice for failed MU updates and anonymized MU file verification and cache invalidation results to debug reports.

1.1.10

• Fix the MU catcher skipping AJAX and REST requests when installed under the WordPress repository directory name. Detect the active plugin using its actual installation path instead of hardcoding qacp/qacp.php.
• Recognize network activation when checking whether the MU catcher should run.
• Refresh the installed MU catcher on upgrade through the existing version update mechanism.

1.1.9

• Repackage the complete plugin after the initial WordPress repository 1.1.8 download omitted 16 PHP files.
• Include missing Action Scheduler classes, including ActionScheduler_RecurringActionScheduler, whose absence caused a fatal error during WordPress startup.
• Include the PixelYourSite REST and generic replay processors missing from that download.
• Issue a new version so sites running the incomplete 1.1.8 package receive the repair through the normal WordPress update process. No queue processing behavior changes from the complete 1.1.8 release.