Support

February 20, 2017 at 8:54 am

Hi David,

Do you know which page on your website triggers the fatal error?

February 20, 2017 at 9:26 am

There’s a way to turn on EE logging, but if you turn the EE logging on it may not point to the page that’s causing the error.

What appears to be happening is there’s a page somewhere on your site that’s trying to load an event, but that event does not have a primary date time.

February 20, 2017 at 9:56 am

It may be an event that’s not current. Like for example if there’s a page on the front end of the website that’s trying to loading information about an event that’s in the trash.

February 21, 2017 at 5:07 am

Hi David,

This will happen if you preview an event before it has been saved as draft or published.

So for example if you go to Event Espresso -> Events -> Add Event.

Give the event a title (say ‘example event’) and then use the permalink to preview the event.

The datetimes have not been created for the event yet as it has not been saved so there is no primary datetime and that error is thrown. Once you save/publish the event the datetimes are created and the error will no longer be thrown.

So have you recently been creating new events and previewed one of them?

February 22, 2017 at 4:03 am

In the next version of EE we have included some code to prevent the fatal error from happening (the function will check for a valid datetime, if there isn’t one it will not output any details from EEH_Schema).

So that will prevent the error I mentioned and should prevent the fatal error on your site however other than the above scenario this is not something we have been able to reproduce so I’m not sure why you’re getting the error on your site.

I can give you some steps you can use to help narrow down the Event that is causing this if you are comfortable working with PHP?

On most of my test sites I uses a snippet similar to this in my theme’s functions.php file: http://www.stumiller.me/sending-output-to-the-wordpress-debug-log/

It’s just a way to write to the error log but the above will only write to the log if WP_DEBUG is enabled. To enable WP_DEBUG I use THIS to log errors within /wp-content/debug.log but not display the errors on the page.

If you add that to your site you can then add something like this:

if(! $event->primary_datetime() instanceof EE_Datetime) {
	write_log($event);
}

Within \core\helpers\EEH_Schema.helper.php on line 27, above the $template_args – http://take.ms/N3Jzs

Now what will happen is under the condition that fatal error would be thrown on your site, it will write the $event variable values to the debug.log file which means you can see the EVT_ID and EVT_name that is throwing the error – http://take.ms/Wlytw

Run through the steps I posted above to get the fatal error to be thrown so you can confirm its working, then just wait for another instance of the error to be thrown and check the log file to see which event causes it.

Your modifications to EEH_Schema.helper.php will be lost when you update Event Espresso and the fix we are including will be used but it does not show why the error is being thrown, it just prevents it from happening the above is just an option for finding the cause.