Support

October 2, 2018 at 4:05 pm

Hi Grant,

I’m Event Espresso’s lead developer and the one who wrote the code that injects our notices container into the loop.

As Josh has explained, we are hooking into the 'loop_start' action at priority 2, as you can see here:

https://github.com/eventespresso/event-espresso-core/blob/master/core/EE_Front_Controller.core.php#L87

the display_errors callback that is called can be seen here:

https://github.com/eventespresso/event-espresso-core/blob/master/core/EE_Front_Controller.core.php#L396

I’ll walk you through what’s going on in that method:

– first, we set a static variable called $shown_already that is used for ensuring our notices container only displays once. Because it is static, it doesn’t matter how many times this method gets called, it will retain its value, which is initially set to false.
– next we have a custom action that fires before anything else happens. This gives devs a guaranteed spot to inject some code that will run prior to our notices container being generated.
– then we hit a multi stepped conditional that has been in place for 5 maybe 6 years without much issue and has probably not seen any changes at all in the last 3 years or so (although I’m guessing). Considering that Event Espresso has run on thousands of sites with all sorts of various templates, I am pretty confident that this code operates reasonably well. I’ll break down what is happening in it line by line. Please note that these conditionals are joined using && (AND) meaning that each of these conditionals must evaluate to true in order to advance to the next line, and ALL of them must evaluate to true in order for the inner code to run. Code execution will stop as soon as one of these conditionals evaluates to false, meaning the inner code will not run.

! $shown_already

this checks the value of our static variable set at the top o f the method. Since it is initially set to false, this becomes a double negative, so ! false evaluates to true and we advance to the next conditional

apply_filters('FHEE__EE_Front_Controller__display_errors', true)

this is a custom filter that gives devs an opportunity to exit out of this conditional in case they want to remove our notices container in order to position it somewhere else.

is_main_query()

this verifies that the current query is the WordPress main query for the request and not one of the many other queries that run on a page, such as the one that retrieves menu items for the site navigation.

! is_feed()

this prevents our notices container from displaying on RSS feeds because those do not allow for any user interaction (such as registering for an event) and therefore do not require notifications to be displayed to the user

in_the_loop()

this was added to handle an edge case where some themes are running a custom main query in addition to the WordPress main query but are not tagging it as being in the loop.

did_action('wp_head')

another bit added to accommodate themes that run their main query prior to calling get_header(). This prevents our notices container from being output prior to the WordPress header. This is the conditional that is not operating as expected because of your custom theme. I’ll come back to this line in a minute.

$this->Request_Handler->is_espresso_page()

this final conditional examines the current request and performs a bunch of poking and prodding on the current global post to determine if the current request is for an Event Espresso page that needs our notices container injected into the DOM.

So again, if any of those conditions does not evaluate to true then the inner code which injects our notices container will not run.

Now, your Registration template can be summed up as follows:

if ( have_posts() ) : while ( have_posts() ) : the_post();

    get_header();

    // template HTML

    get_footer();

endwhile; endif;

As explained above, our notices container hooks into the loop_start action that fires immediately after calling the_post() but only upon the first iteration of the loop. The reason that you are not seeing our notices container getting injected into the correct place in the DOM is because of the did_action('wp_head') conditional I listed earlier. That action is typically fired from within a theme’s header.php file. For example, here what happens in the official WordPress Twenty Seventeen theme header.php file:

<!DOCTYPE html>
<html <?php language_attributes(); ?> class="no-js no-svg">
<head>
<meta charset="<?php bloginfo( 'charset' ); ?>">
<meta name="viewport" content="width=device-width, initial-scale=1">
<link rel="profile" href="http://gmpg.org/xfn/11">

<?php wp_head(); ?>
</head>

The problem with your Registration template code is that it is calling get_header() from within the the loop. This means that the_post() is being called before the header.php file is being loaded. Therefore the_post() is being called before wp_head() is firing. So when EE_Front_Controller::display_errors() hooks into loop_start that is called by the_post(), our notices container do not get injected because the did_action('wp_head') conditional returns false, because your theme is not loading its header until after it has begun looping through post results for the main query.

The reason that our notices container is getting injected later on in your footer code is because you are running an additional query within that template, and by that time all of the conditions for our conditional that control its appearance have now been met.

I cannot stress enough that it is completely unconventional and unexpected for a theme to call get_header() from within the the loop. I’m not a gambling man but I would bet that you would have to look through thousands and thousands and thousands of WordPress themes before you could find one that is doing what your theme is doing, that is if you could even find another theme doing it at all.

Why?

Because calling get_header() from within the the loop is a pretty guaranteed way to shoot yourself in the foot.

Is there even any reason why your theme is calling get_header() and get_footer() from within the the loop? I can see absolutely no benefit for doing so.

The standard most basic expected structure for a top level theme template is:

Header
The loop and everything else
Footer

I have no doubts that any of the archive templates for your theme do not do the exact same thing as your Registration template, because if they did, you would have a header and footer being printed out for every post returned by your query.

The comment that you made earlier:

WordPress ignores multiple calls to include the header and footer by default

is not correct in any way. Here is the entirety of the WordPress get_header() function:

function get_header( $name = null ) {
	/**
	 * Fires before the header template file is loaded.
	 *
	 * @since 2.1.0
	 * @since 2.8.0 $name parameter added.
	 *
	 * @param string|null $name Name of the specific header file to use. null for the default header.
	 */
	do_action( 'get_header', $name );

	$templates = array();
	$name = (string) $name;
	if ( '' !== $name ) {
		$templates[] = "header-{$name}.php";
	}

	$templates[] = 'header.php';

	locate_template( $templates, true );
}

not much to it so it’s pretty easy to see that there is no mechanism in that code to prevent it from running multiple times. So every call to get_header() will result in the ‘header.php’ template (or specified alternative) being included and therefore displayed.

This means that your archives templates absolutely can not be calling get_header() and get_footer() from within the loop like your Registration template is, and are either making those calls outside of the loop as is the expected norm, or have added some additional code to ensure that those are only firing once. Which is silly because you can simply move those two function calls outside of the loop and not have to bother with any of that.

So anyways, before we can go any farther, we will need you to restructure your Registration template file to be as follows:

get_header();

if ( have_posts() ) : while ( have_posts() ) : the_post();

    // template HTML

endwhile; endif;

get_footer();

so that our notices container can even have a chance of being injected properly. I can guarantee you that it will not function properly the way you have that template structured now. If after making that change, things continue to not operate correctly, then we will need ftp access to your site, or access to the entire theme in order to be able to fully troubleshoot what other problems are happening.

Lastly, I just want to say that I apologize if my comments above come across as condescending or offensive in any way as that is absolutely not my intent. It is imperative however that you understand that the existing code you have shown us will absolutely not function properly and would almost certainly be considered “doing it wrong” by the vast majority of WordPress developers out there. We need this issue corrected before we can continue to troubleshoot the issues on your site.

• This reply was modified 5 years, 6 months ago by  Brent Christensen. Reason: trying to fix display of code blocks
• This reply was modified 5 years, 6 months ago by  Brent Christensen.
• This reply was modified 5 years, 6 months ago by  Brent Christensen. Reason: note re: access to theme files

October 3, 2018 at 1:35 pm

Hi Grant,

My sincere apologies if any of my replies came across like they were a dead end with no way forward. We try very hard to have a solution for issues like these.

With regards to getting more context, maybe you didn’t see my earlier reply about sending the theme files?

In any case the offer still stands to help you get this sorted out without resorting to hacking core plugin files. Your client will really appreciate everyone’s efforts in making sure this is resolved the right way. As you’re probably aware, editing plugin files can make for missing functionality and present maintenance headaches with plugin updates going forward.