Support

November 1, 2019 at 10:25 am

Setting messages settings send to ‘On same request’ basically tells Event Espresso to use WP_Cron for messages (including the upcoming event notifications). To send Upcoming notifications, that option needs to be changed to ‘On Separate request’.. However, often if that option was changed there may have been a valid reason to do so.

If you go to Dashboard → Tools → Site health.

Then wait about 30 seconds, does it show a message that says anything about a scheduled task or loopback requests failing?

If not, you can change the setting to ‘On separate request’ and save.

Now to test message function using WP_Cron you’ll need to add a test registration to an event and finalize the registration.

Then go to Event Espresso → Messages → Message activity

You should have a message waiting to generate in the queue, wait 5 minutes and refresh the page, does it change to show it has generated and/or sent?

November 1, 2019 at 11:28 am

No because if any scheduled event fails to run, then other scheduled events will likely also fail.

Before you change the setting you’ll need to insure that scheduled events (or wp_cron) is working on your website.

One possible solution to this can be found here:

https://wp-mix.com/wordpress-cron-not-working/

November 12, 2019 at 8:33 am

If you check Tools -> Cron Events and view the next run date/time are the in the past or future?

The check on the health check page basically compares next run with now() and if it’s in the past, it throws the above notice.

Is your site low traffic?

November 12, 2019 at 9:26 am

Yah that should be more than enough to keep wp_cron ticking over.

Ok, so the times for next run on all crons (not just EE crons) are stuck in the past? If so then that sounds like an issue with wp_cron. It may have been disabled although there are other causes, hosts like to disable it as it reduces load, I’m assuming it does NOT show a notice at the top of the above page statin WP_CRON has been disabled?

November 12, 2019 at 12:18 pm

Right, so that means WP_CRON has been disabled on your site, so that’s why they aren’t working, unless your host setup an alternative.

Check in wp-config.php and look for something like define('DISABLE_WP_CRON', true);

Comment that out and check your crons again, do they now work?

November 13, 2019 at 2:44 am

Did you originally add the constants mentioned above to wp-config.php or was that set up by your host/someone else?

The above uses a redirect to trigger the crons when a user visits a page, I’d recommend testing it without that set and see if it works.

November 13, 2019 at 2:57 am

Yeah, that’s used if you have issues with WP_CRON, so far we don’t actually know if your site did/does.

For some reason WP_CRON was disabled on your site, adding ALTERNATE_WP_CRON does nothing as if WP_CRON is disabled you can’t have an alternate wp cron is also disabled.

November 14, 2019 at 3:35 am

Great, I’m glad that worked.

You can use a custom field on the event itself and then the [EVENT_META_*] shortcode in the Event List section of the template.

If you edit whichever AUEN template your are using you’ll see multiple sections within the template, each of those sections has access to specific data, Event List has access to everything to do with the event object (if you click on the icon you’ll see a list of shortcodes vailable on the section you click it for).

So you could use Avanced Custom Fields to add a test editor to EE events, then in Event List set the [EVENT_META_*{custom-field-key]] shortcode wherever you want to output that date.

Make sense?