Mailchimp for Woocommerce has not added the webhook to Mailchimp, visit the plug

Also we use Wordfence as firewall. We have this settings for years now, not a single problem or similar has happened until now

@joldeski this is a new addition to the plugin which is setting up webhooks coming from Mailchimp to your server when people subscribe or unsubscribe from campaigns. The reason it’s showing up now is because it’s not able to be set. After helping someone that had a similar problem, we detected that in his case, it had to do with the “User-Agent” header which was being blocked by something at the server level, never allowing the communication with our plugin.

If you’re using wordfence, maybe there’s a spot where you can allow certain headers or deny certain types of requests.

The user-agent header looks like this: MailChimp.com WebHook Validator

Can we start with that and see if you’re getting any blocked requests?

Hi ryanhungate, thanks for the replay.

So, when you mention user-agent I forgot that I’m blocking all user-agents in robot.txt on this site (sorry about that).

So I run the updated on another site which is not blocking them and all seams fine – the message appeared but it was gone upon refresh.

However on the site that I block the user-agents I did this

User-agent: *
Disallow: /

User-agent: MailChimp.com WebHook Validator
Allow: /`

However it doesn’t seams to be helping.

When I see the logs of the plugins (I don’t have log from today) it says this. (I added the xxxxxx s)

`2022-07-21T13:31:49+00:00 NOTICE admin :: syncing webhooks for existing plugin

2022-07-21T13:31:49+00:00 NOTICE action_scheduler.queue_job :: MailChimp_WooCommerce_WebHooks_Sync queued

2022-07-21T13:31:53+00:00 ERROR webhook :: <p>url: We couldn’t verify the URL is working. Please double check and try again. HTTP Code: 503</p>
2022-07-21T15:03:27+00:00 NOTICE action_scheduler.queue_job :: MailChimp_WooCommerce_Cart_Update queued :: obj_id 0f05cce49f1d32447f28d5a405a19574

2022-07-21T15:04:07+00:00 NOTICE abandoned_cart.success :: email: [email protected] :: checkout_url: https://xxxxxxxxxxx.com/checkout/?mc_cart_id=0f05cce49f1d32447f28d5a405a19574

In the access logs of Apache/php I can find logs like this connected
95.180.213.108 – – [22/Jul/2022:09:46:38 +0000] “POST /wp-admin/admin-ajax.php?action=mailchimp _set_user_by_email&[email protected]&mc_language=en&subscribed=0 HTTP/1.0″ 200 771 ” https://xxxxxxxxxxxxxxxxxx.com/my-account/&#8221; “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/ 537.36 (KHTML, like Gecko) Chrome/103.0.0.0 Safari/537.36”

One more thing. Upon saving the audience I finally have log (it was in debug mode). I have this there

2022-07-22T10:15:57+00:00 NOTICE action_scheduler.queue_job :: MailChimp_WooCommerce_WebHooks_Sync queued
2022-07-22T10:16:49+00:00 NOTICE webhooks :: added webhook to audience

and upon second save

2022-07-22T10:17:26+00:00 NOTICE admin :: updated GDPR fields :: Array
(
    [fields] => Array
        (
        )

)

2022-07-22T10:17:26+00:00 NOTICE action_scheduler.queue_job :: MailChimp_WooCommerce_WebHooks_Sync queued

——–
Message seams to be gone and this seams to be solved. How can I know and test its ok?

• This reply was modified 2 years, 8 months ago by figment.

One more thing, sorry for writing so much. I manage to “fix” this on 2 of my 3 sites that are blocking all user agents.

For the sake of the test I didn’t allow the user agent in robots.txt on the 3rd site. Upon saving the settings in STORE tab (Audience is not there), Audience tab appears and I got this log

2022-07-22T10:59:49+00:00 NOTICE webhooks :: added webhook to audience
2022-07-22T11:00:16+00:00 NOTICE sync_store :: posting data :: Array

Again, seams to be working without including the user-agent of Mailchimp.

Hope this will help to somebody

Thanks so much @joldeski – appreciate the details. The user-agent header is present so people can identify where this is coming from ( or at least an attempt to show it ).

Can we confirm that you’re not seeing this error on all 3 sites now? If you can look at your options.php file and see something ending with webhook.token and it’s not blank, that means your webhook is most likely set up properly and you’ll see activity in your logs when folks either subscribe or unsubscribe.

Sorry for the late response. Yes I can confirm that the notice is gone from backend and I have the wbhook.token in wp_option table.

THE SQL I used to check – SELECT * FROM wp_options WHERE option_name LIKE ‘%webhook.token%’

Also I can confirm that just by saving the settings in Store tab I manage to make it work.

I also tested this on Site Ground Cloud Hosting. On that site (also using Wordfence), there was not such problem.

Hope this will help someone. Thanks for the support

@joldeski thanks so much for the confirmations. Have a great week!