Support

March 26, 2015 at 8:02 am

Hi Sal,

I’m the developer that helped Josh troubleshoot this issue for your client. What we determined in troubleshooting was this.

1. There was a callback on the WordPress “init” hook add_action('init', array($this, 'ad_display_check')); that in turn implemented the WordPress function url_to_postid(). This function in turn instantiates a WP_Query object to assist with getting the postid from the url. There are a number of WordPress hooks that get run when this happens including pre_get_posts.
2. In normal WordPress loading, there is a specific order in which WordPress loads, and $wp_query is usually NOT instantiated until after the parse_request hook (and well after init). This in turn means that pre_get_posts normally and is expected to be triggered AFTER init, and AFTER parse_request

Event Espresso hooks into WordPress based on those expectations, so we have a very tight loading process to try and restrict resource loading to ONLY when required. We have a specific class that gets instantiated and loaded on the WordPress “parse_request” hook. Then we have some CPT Strategy classes that load on the “pre_get_posts” hook that take care of conditionally hooking in extra EE CPT related queries depending on the incoming request that USE the class we instantiate on the parse_request hook.

What happened on your client’s site, is that when the registration checkout loaded, the callback in your theme mentioned above instantiated $wp_query, which in turn triggered the “pre_get_posts” hook firing, which our CPT strategy was hooked into and our strategy tried to use the Request Handler that we load on the “parse_request” hook but that was NOT loaded because “parse_request” had never fired. So there was a fatal error.

The reason the fix we implemented worked, is because we simply moved the code you are running to a little later in the loading process which also greatly simplified getting a post_id because you are able to use what WordPress has already setup for you at that point. Keep in mind, that Event Espresso merely exposed a flaw in how that particular function was being implemented which we’ve assisted in fixing.

We are also looking at implementing some error proofing in our code so that in cases where this happens we’ll fail things more gracefully instead of a fatal error, however that doesn’t change the fact that the implementation of that callback was wrong.

I hope that helps explain things? Feel free to respond if there is any further clarification needed.