Support

September 11, 2020 at 2:26 am

Hi Nick,

Have you been receiving the event admin emails when users register onto the events before this happened? As in are you sure EE emails were working before this happened?

The reason I’m asking is we’ve noticed an increase of reports like this:

https://eventespresso.com/topic/queued-for-sending/

Where one (or more) of the message queue cron jobs have randomly disappeared from the site which then leaves your messages sitting in the message queue until you update EE4 (or de-activate and re-activate) and they are re-added, which then means your message queue works and start generating and sending the backlog.

Do you have a recent database backup of the site that I install locally (meaning no emails will send) and take a look? It needs to be from before the emails started working, if you have multiple backs then one from before you did the updates and then one right after would be idea.

—

To work through some of your questions/comments (I can’t give you an accurate answer for some):

As Tony kindly noted in the previous support issue we have recently upgraded our WordPress to the current version though have disabled the backwards compatibility plugin since we thought any compatibility problems were resolved when we deactivated a Database plugin.

This isn’t a WP5.5 compatibility issue and that plugin wont help/cause this.

Have the Automated Event Reminders not been going out, and the new version of WordPress fixed this sending out historical e-mails that were unnecessary now that the event passed ?

Possibly (see above) but not batch emails, unless those were also sitting in the queue to send.

Perhaps the WordPress upgrade affected the Cron job timings ?

Not the timings, we add our own, but this could be related to missing cron jobs altogether.

Is there a way to download the Historical Messages that went out into Excel ?

We don’t have an option to export messages currently.

Is there an eaiser way to delete messages on the message queue ? Deleting 20 at a time can be quite cumbersome when there are 600 to do ? When selecting all, is there an option to extend this to all the pages behind the current screen instead of the current list of 20 ? Or perhaps have a toggle to allow 200 entries on the screen to work with ?

There’s no ‘select’ or ‘clear’ all but you can increase the number of items per page.

On the message queue look at the top right of the page for ‘Screen options’, click that and you’ll see an option page dropdown. Within there is a Pagination section that lets you set the number of items per page, by default its 20 and you can increase it there.

Note, increasing the number of items per page pulls in more data, pulling in more data takes more time so if you start pulling in to many at once you’ll starting hitting limits on your server. How many that is I can’t tell as it depends on your server but I can pull 500 per in less than 3 seconds on my servers without a problem.

September 11, 2020 at 4:42 am

It looks like the SendinBlue transnational server was not turned on so presumably the e-mails are sent directly the website server.

Yeah, in that case, you’ll be using your hosts PHP Mail server.

Additionally, I do not have the technical knowledge/space to restore a test site.

I wasn’t asking for you to set up a test site but rather send me a database backup that I could import and view locally on my machine, I’ll be able to see via the data in those tables if all of these messages were simply sitting waiting to send and if the cron jobs were indeed missing.

I sorted the message logs, and looks like about 1500 e-mails went out. And by searching via specific recipient I only saw one e-mail so they appear to be delayed e-mails rather than duped e-mails.

Whilst not ideal by any means, delay e-mails are probably the best as it likely means the cron jobs were at fault as opposed to something much more difficult to troubleshoot.

The e-mails start about 3:08 am in the morning near the time I deactivated the Database Plug In and the WordPress Backward Compatibility Plugin for the previous issue.

Did you de-activate EE4 at all during testing? If EE4 was de-activated it will have ‘fixed’ any missing crons when it re-activated. I’ve not seen that happen when other plugins were deactivated.

By the way, would you recommend leaving the Backward Compatibility Plugin Deactivated for now ? Or is it safer to keep activated ?

It’s not safer to have it enabled per se, you’ll know if you are running into issues as functions that use javascript will simply stop working. So you could leave it deactivated and if you find things that aren’t working activate it and view the notices it throws but that plugin actually does very little, it adds an additional ‘migrate’ JavsScript file with ‘old’ functions that plugins may be using.

That’s not very much but if plugins are using those old functions and they aren’t available, things break and its usually very obvious that it happens as interactions with your site stop working.

What kind of possibilities are there outside the cron jobs stopping that would cause this ?

Other than missing crons we’ve had one report from a user in which every request on the site somehow managed to retrigger a batch of emails. Turned out that was something very strange going on with the caching set up on his server. Your symptoms so far, don’t match that report.

If the cron jobs are the primary culprit behind this, what kind of controls can be put in place ? Can the control check every few hours if any of the cron jobs are down, and restart it ?

We are investigating some solutions but right now the recommended solution is to add another cron to check that the others aren’t missing. To me adding a cron to check if crons are broken doesn’t seem logical but apparently the issue with missing crons happens with ‘shorter’ crons like 5-minute schedules which EE uses.

Or if its not possible to automatically restart it, can a red error message (with recovery instructions) be put in the Event Espresso Event or Registration Screens ?

De/Reactivating EE4 isn’t really a viable solution for this, any time you de-activate any add-ons for EE4 will also de-activate and then need to manually re-activated again. It’s a workable solution for now but not the best way forward for this.

Are these general WordPress cron jobs or specific to EE ?

We add our own crons to the native WP cron schedules, WordPRess handles the ‘rescheduling’ of crons when they run and apparent that is what is failing.

What is the best way to ensure this doesn’t reoccur in the future ?

In short, we don’t know just yet.