Plugin Author
shan
(@suhanduman)
Hello Tim,
18,500 entries in Action Scheduler indicates a severe backlog. If the Action Scheduler is choked, background tasks (including WooCommerce order emails, webhooks, and our CAPI queue) will either fail to register or never execute.
Here is the immediate action plan:
- Force the Scheduler: Deactivate and reactivate the All-in-one CAPI for Meta & Pinterest + GTM plugin. This will not delete your settings, but it will forcefully re-register the
mcapi_process_event_queue hook into the system.
- Clear the Backlog: You need to clean up those 18k entries. You can use a free plugin like WP Crontrol to run stuck crons or clean the
wp_actionscheduler_actions table directly from your database. Until that queue is breathing again, CAPI events will remain stuck.
- Update to v3.5.0: The major update is now live. It resolves the GTM template import issue (
CUSTOM_EVENTschema) and includes full integration and documentation for CookieYes and Consent Mode v2.
Please update to v3.5.0, deactivate -> reactivate the plugin, and let me know if the Event Log starts populating.
Sorry, I wasn’t clear – all of those (bar about 20) are Completed, a few Failed relating to failed Stripe sessions and a handful that are Pending for scheduled events.
I will clean the list anyway for good housekeeping – I have tool for that.
I’ll then install 3.5.0 and let you know what happens.
Tim
Installed 3.5.0 and I now see this error “There has been a critical error on this website. Please check your site admin email inbox for instructions. If you continue to have problems, please try the support forums.” when clicking on the settings menu.
Here is the debug message – looks like CookieYes does not like something:
WordPress verze 6.9.4
Aktuální šablona: Avada Child (verze 1.0.0)
Aktuální plugin: CookieYes | GDPR Cookie Consent (verze 3.4.2)
Verze PHP 8.3.30
Podrobnosti chyby
=================
Na řádku č. 47 v souboru /data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/mywave.cz/www/wp-content/plugins/cookie-law-info/class-autoloader.php došlo k chybě typu E_ERROR. Chybová zpráva: Uncaught Error: Failed opening required ‘/data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/mywave.cz/www/wp-content/plugins/cookie-law-info/’ (include_path=’.:/usr/share/php’) in /data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/mywave.cz/www/wp-content/plugins/cookie-law-info/class-autoloader.php:47
Stack trace:
#0 [internal function]: CookieYes\Lite\Autoloader::load_class(‘CookieYes’)
#1 /data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/mywave.cz/www/wp-content/plugins/easy-meta-capi/easy-meta-capi.php(247): class_exists(‘CookieYes’)
#2 /data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/mywave.cz/www/wp-content/plugins/easy-meta-capi/easy-meta-capi.php(500): mcapi_detect_cmp_plugins()
#3 /data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/mywave.cz/www/wp-includes/class-wp-hook.php(341): {closure}(”)
#4 /data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/mywave.cz/www/wp-includes/class-wp-hook.php(365): WP_Hook->apply_filters(NULL, Array)
#5 /data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/mywave.cz/www/wp-includes/plugin.php(522): WP_Hook->do_action(Array)
#6 /data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/mywave.cz/www/wp-admin/admin-header.php(313): do_action(‘admin_notices’)
#7 /data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/mywave.cz/www/wp-admin/admin.php(244): require_once(‘/data/7/7/77bb2…’)
#8 {main}
thrown
Plugin Author
shan
(@suhanduman)
Actually it’s a bug on CookieYes. (class_exist function)
But i have solved it on my side.
Released 3.5.1 for you.
OK. Do you want me to notify them about it or have you already done it?
I have to pop out for a bit…I will update to 3.5.1 when I get back and continue testing.
Tim
Plugin Author
shan
(@suhanduman)
v3.5.2 just shipped — full GTM API schema rebuild. (template is working)
The previous 3.5.x template wasn’t importing into modern GTM workspaces (Unknown entity type errors).
I tested the new build end-to-end in a fresh GTM workspace and it now imports cleanly with all 19 tags, 10 triggers, 13 variables, and the Meta Pixel custom template.
Please re-download the template from the plugin settings and re-import.
Thanks for the patience while we chased this through. : )
Regards,
Suhan
Hi Suhan,
I’m really impressed with your level of support here! Thanks for your hard work.
I will install it shortly (didn’t get to 3.5.1 yet) and see how things test out.
Kind regards,
Tim
FYI: I was just offered an update to the Meta template version 19af9 > version 0c574. Did you see that already?
Hi Suhan,
Just a quick status update before I head off to bed.
- 3.5.2 installed and all tags, variables and triggers from the GTM template are in use.
- Meta template was not updated yet – there was some error condition being flagged with the revised template.
- Events are being sent to GA and Meta – all visible in GTM Preview.
- Consent mode seems to be working fine – I will test more tomorrow.
- Events are visible in the plugin Event Log but still many hits from bot traffic and price scrapers – do you still plan to look at that?
- The only issue I have noticed so far is that clicking to open the cart page triggers a view_cart event (correct), then a PageView event (correct) followed by a spurious add_to_cart event (incorrect). Not sure why that is happening.
I’ll update more tomorrow.
Tim
Plugin Author
shan
(@suhanduman)
Hi Tim — thanks for the detailed status, very useful.
(1) Meta template update error — Could you grab the exact message (or screenshot) when GTM offers the 19af9 → 0c574 update and you accept it? GTM’s “wait, terms of
service for this template” or schema-validation message would tell me exactly which field it’s unhappy about. Without that I’d be guessing.
(2) Spurious add_to_cart on cart page — Probably needs an improvement, if we hit such a condition:
The woocommerce_add_to_cart PHP hook the plugin uses can fire on cart page reload when a third-party plugin (subscriptions, free gifts, cart persistence) re-adds items in the cart-page lifecycle. I can ship 3.5.3 with an early-exit when is_cart() or is_checkout() is true — real add-to-cart actions happen BEFORE the visitor lands on /cart/, so suppressing fires from those two pages is safe.
(3) Bot / price-scraper traffic — They are still on the list. The current regex catches self-identifying crawlers (Googlebot, AhrefsBot, etc.) but commercial scrapers spoof real browsers. Could you paste a couple of example User-Agent strings from your Event Log’s failed/spurious rows? With real samples I can extend the regex tightly instead of casting too wide a net and catching real visitors.
Regards,
Suhan
Hi Suhan,
Re 1. It seems that GTM was not telling the truth…the Meta template is in fact updated and is at version 0c574.
Re 2. Sounds plausible. Our Cart page has a progress bar that loads to show how much more value needs to be added to the cart to get free shipping – so that may be a factor. Let me know if you want some more specifics.
Re 3. Where does the plug-in store the Event Log…in a directory or in the database?
Tim
Plugin Author
shan
(@suhanduman)
Hi Tim — thanks for the update.
(1) Glad it sorted itself out. Old Meta Pixel plug-ins will be updated with the template.
0c574 is the correct version.
(2) The free-shipping progress bar plugin is a strong lead. 3.5.3 (shipping today)
already includes a fix for one variant of the cart-widget replay issue: the AJAX
add-to-cart payload was previously emitted as an inline script inside a
WooCommerce fragment, and WC caches fragments in browser sessionStorage, so any
later page load that re-rendered the cart widget would silently fire the script
again. 3.5.3 moves the payload to a self-clearing data attribute, so cached
fragments are inert on replay.
That should cover the browser-side noise. If the spurious events continue after
3.5.3, the next likely vector is your progress bar plugin re-invoking
woocommerce_add_to_cart on cart-page render. To confirm or rule out, after
upgrading could you check the Event Log on the cart page (no actual add-to-cart
action) and let me know if any AddToCart rows appear with source_info matching
items already in your cart?
(3) Event Log lives in a custom database table (wp_mcapi_logs by default — your
table prefix may differ). You can view/filter it from WP Admin → All-in-one CAPI
→ Logs. Filter by status=failed and event_name=PageView (or any event you suspect
bots are spamming), then click any row to see the full User-Agent. Two or three
real samples and I’ll extend the bot regex tightly.
Thanks again for the patience — 3.5.3 should be live in your auto-update channel
within a couple of hours.
Hi Suhan,
OK…I’ll check when the next release drops.
For the Event Log, in the backend admin for the plugin I see only Success (Meta) messages – no failures. I just cleared the log, so I’ll monitor to see how many events are being recorded over the next 24 hours – my impression is that it may now be less.
The messages in the Event Log display are not clickable, but I looked at the database and see that there is no additional info beyond that already displayed. User agent does not seem to be captured.
A couple of useful enhancements perhaps:
- Time/date filtering on the log data.
- Ability to change the default 15-day log storage period.
I will be travelling this afternoon, so I will update you this evening.
Tim
Hi Suhan,
Back on-line today!
I was just able to install the new release. Thanks for the log management features – a good addition! I cleared the log and can confirm that events are now captured in the log with User Agent data. I’ll let it run over the weekend to see what insights I can get on bot activity.
Thanks for your support – much appreciated!
Tim
Hi Suhan,
Logging seems to have stopped…not sure if that means events are still being sent or not.
I looked at the database and I can that the log has exactly 1,000 entries.
The log runs from 2026-05-09 07:09:37 with 1,000th entry at 2026-05-09 18:16:40. I checked the PHP error log and I also see the following PHP Warnings now being generated:
http://www.mywave.cz [Sun May 10 16:31:10.045065 2026] [proxy_fcgi:error] [pid 716410:tid 136659114899008] [client xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:65058] [upstream php83] AH01071: Got error ‘PHP message: PHP Warning: Undefined variable $events_to_track in /data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/mywave.cz/www/wp-content/plugins/easy-meta-capi/easy-meta-capi.php on line 1192; PHP message: PHP Warning: foreach() argument must be of type array|object, null given in /data/7/7/77bb2d09-7a89-4964-83b5-44992d7e2a54/mywave.cz/www/wp-content/plugins/easy-meta-capi/easy-meta-capi.php on line 1192’, referer https://www.mywave.cz/wp-admin/admin.php?page=easy-meta-capi&mcapi_filter_nonce_field=yyyyyyyyyy&_wp_http_referer=%2Fwp-admin%2Fadmin.php%3Fpage%3Deasy-meta-capi%26mcapi_filter_nonce_field%3Dyyyyyyyyyy%26filter_event%3DPageView%26filter_from%3D2026-05-04%26filter_to%3D2026-05-10%26filter_action%3DFilter&filter_event=all&filter_from=2026-05-04&filter_to=2026-05-10&filter_action=Filter
Note: IPv6 and nonce fields anonymised by me.
Looking at the wp_mcapi_event_queue table in the database I see 15,313 entries, with the first of those dated at 2026-05-09 18:16:55 and the last dated at 2026-05-10 18:58:53. I have dumped the DB to this CSV file – I guess that will give you a good handle on bot activity.
Note: The site uses WordFence, so I will be able to set some firewall rules to hopefully minimise the bot activity.
I also checked the Woocommerce Scheduled Action list. The mcapi_process_event_queue hook seems to be running fine, with 3,808 completed actions and no failures. The last triggered and ran 1 minute ago, but unclear if any events are being sent as the queue seems to be getting longer rather than shorter.
I cleared the event log – the database table is now empty but no new entries are being added.
Does that give you some data to work out what is happening?
Kind regards,
Tim
