Posted: May 13, 2021 at 4:33 pm
|
Hi Not having a date in an email notification is a show stopper. AND we need emails sent in real time not 1 hour later or the next day. |
|
|
Hi there, So just to clarify, the emails you are referring to with no date are the EE messages? For example, the ‘Registration Approved’ email sent by EE? If you go to Event Espresso -> Messages -> Message activity, can you see the email there with no date?
This is strange as that setting should make no difference to the content of the email itself. The message is sent in the same way with both settings (through Do you have WP_CRON disabled on the site?
Which message type are you editing here? Which context within that message type? (Event Admin, Registrant, Primary Registrant) For details see: https://eventespresso.com/wiki/messages-system-working-with-message-contexts/ Before moving onto workarounds for this I’d like to try and reproduce the problem to see if its something we need to fix. The EE message queue system does indeed rely on WP_CRON and so is tied to traffic hitting the site (although you can also set up a cron to trigger wp-cron every X minutes). |
|
|
Tony you are a dream THANK YOU FOR THE RESPONSE! I’ve been in the site testing with this work around and it appears good but I’m very nervous about stability and consistancy. |
|
Thank you.
Ok, just with you saying the messages were not generating/sending this would be the first thing to check.
From all contexts? (Event Admin, Registrant by default) You said you’ve tried using the shortcodes in various sections, where are you loading them now? If the Registration Approved Event Admin context doesn’t show the dates, lets start with that one. Event Espresso -> Messages -> Default message templates -> Registration Approved -> Edit Event Admin. Where are the dates set to load? I’ll see if I can reproduce this locally.
WP_Cron (and therefore any tasks assigned within it, like EE’s message crons) can’t trigger without traffic unless you already have a ‘real’ corn on the server set to trigger wp-cron. If cron’s are currently working fine, just leave them alone for now. The important part was confirming that WP_Cron tasks were indeed running as it sounds like they may not have been.
Ok, thanks for checking. In short this confirms that something isn’t parsing the email after it’s sent which is then accidentally removing the dates.
I understand, the problem is that the most likely difference between my site and yours is WP Fusion, so it could be the case that something is happening when that plugin is in use that breaks the message generation. I’ll see if I can narrow it down any as we generally try to avoid the whole “it’s X plugins problem” as much as we can, sometimes that’s not possible but we’ll at least investigate.
I think it’s important to point out here that the Message Queue system in itself is not a workaround, I understand you mean that in the sense of how you’re using it right now but that system isn’t considered unstable but rather it was designed to run the way it is now. The ‘send on same request’ setting is the ‘original’ method EE used to generate emails, in short when your user completed a registration and triggered emails, those emails would generate and send on that same request that triggered them (the user’s request). Generally thats fine, it adds a little to the page load but no one is the wiser, until… you start adding large numbers of registrations in a single group (more emails) and/or slow mail server responses (longer and longer page loads for your user waiting for the email to send). Any errors from the mailserver can also prevent the users request from completing so they don’t end up loading the page etc. The ‘message queue’ system was added into Event Espresso to prevent those issues and it is the default setup for Event Espresso now, that’s the ‘send on separate request’ option. It means that when your user’s request triggers an email, that request doesn’t generate and send the email, it adds a row to the queue with minimal details needed to generate the email(s). Meaning the user’s request is impacted very slightly and all of the email processing is then done away from the user. ‘Payment’ related emails (payment received/declined etc) skip the queue and send immediately as they are considered a priority, but generally the 10mins it takes for registration emails to come through doesn’t cause issues. Again I’m more than happy to investigate this as that setting should not be causing dates to go missing in the emails, but using the message queue system within EE is a feature rather than something you should see as unstable. The emails can be made to consistently work through the queue at 5 min intervals using a real cron on the server to trigger wp_cron every 5 mins if thats needed. |
|
|
Tony thank you for the response |
|
|
Tony can you please login as admin and investigate before the WP fusion 30 days is up for a refund…. I”m super uncomfortable. How do I get you login creds? |
|
|
Here’s what the cron says AHEE__EE_Messages_Scheduler__generation |
|
WP Control is showing you the WP_CRON schedule task that Event Espresso sets up on your site, we add a task to run every 5 minutes so what you are seeing is the task we added with the description we added for how often we want it to run but that doesn’t mean it is running every 5 mins due to how WP_CRON works. The fact that you are getting the emails sending on your site means that it is working but you can’t simply view WP Crontrol to get the full story for WP_CRON. To explain, WP_CRON is a ‘sudo’ schedule, its works by checking to see if a task is due to run every time a user hits the site. So with every page load, WordPress (in the background) checks for any tasks that are due to run, which means it is reliant on traffic to function. We say ‘add this task to run every 5 mins’ (which is what you see in WP Crontrol) and then every time a check is done it will see if the time between the last run and now is 5 mins, if it’s 5mins or more, it runs the task. No traffic for 15 mins means the task takes 15 mins to run, the next run could happen 5 mins later, or an hour later, depending on traffic. If you need consistent timings a ‘real’ corn job can be set on the server which basically runs the same check as above but on a proper schedule set on the server itself (say every 5 mins).
There are many reasons for WP_CRON not running and unfortunately (or fortunately) as it’s running correctly now we can’t troubleshoot why it wasn’t running. Tony can you please login as admin and investigate before the WP fusion 30 days is up for a refund…. I”m super uncomfortable. How do I get you login creds?
We can, but as this isn’t an issue with EE itself you would need to purchase a support token for this. Even then I can’t guarantee a fix as I have no idea what WP Fusion is doing here and whilst I’m not simply going to point the finger at them, EE works with the above setting without WP Fusion and you seem sure its that plugin causing it so the fix will likely be on their end, although I’ll happily investigate further. |
|
The support post ‘WP Cron and WP Fusion’ is closed to new replies.
Have a question about this support post? Create a new support post in our support forums and include a link to this existing support post so we can help you.
