Wp_footer hook not called

[dhunink]

Hi!

Today I did some more testing on the RC, just to help spotting possible bugs in real life scenarios.
Therefore I toke a bit of a gamble and installed the RC on my live-environment.
All worked, flawless, except for a single page.
On this page (see secure note), as on all the others, I used WP Rocket to enable lazy-loading on images. This works perfect, except for this one page. With the help from the WP Rocket developers we narrowed the issue down to the wp_footer hook not begin called on that page.

Here are the findings of the WP Rocket guys, investigating why images don’t pop-up on that page when using lazy-load:

From my testing, it appears that the wp_footer action hook may not be executing on this page – this is the hook that we at WP Rocket use to add our LazyLoad script code to each page.

As a further test, I installed our Debug Helper plugin, which also adds its output to wp_footer – but that output doesn’t show up on the source HTML of that page either.

But if you view the HTML Source for this specific page, you will see the WP ROCKET DEBUG output, followed by all our LazyLoad additions.

So, the problem in this case appears to be specific to this page, and it appears that what’s different about it is that the wp_footer hook isn’t being called there.

Since it’s your theme which determines when and where the wp_footer hook gets called on each page, I recommend getting in touch with their support team, to see if they can clarify why that hook might be missing from this page, but present on others.

Off course I could try to fix this on my website by simply re-creating the page and therefore eliminating any bug that has popped up on the page. But as the scenario I’m running into might pop-up for many customers, since WP Rocket is quit popular to my understanding, I thought it might be worth sharing here as a user-case. Perhaps it identifies an actual bug that should be fixed before release?

[alexander]

Our footer template looks like this:

<?php do_action( 'x_before_site_end' ); ?>

    </div> <!-- END .x-site -->

    <?php do_action( 'x_after_site_end' ); ?>

  </div> <!-- END .x-root -->

<?php wp_footer(); ?>

</body>
</html>

If you see <!-- END .x-root --> on any pages, that means the theme footer was successfully loaded and we always call wp_footer immediately afterwards. Also the WordPress wp_enqueue_scripts hook fires within wp_footer and there are a bunch of scripts outputting.

It’s probably a plugin that’s somehow unhooking actions on wp_footer at a certain priority.

[dhunink]

Thanks for that! I did some more testing, inspired by your comment.
It appears to be due to inserting a Global Block. Tried all Blocks I’ve created so far. They all result in Lazy Load no longer working.
Next I disabled all plugins, except WP Rocket and WooCommerce (the later was needed to prevent some errors).
Reuslt is the same. So I believe it’s safe to say that this issue is now related to inserting any Global Block.
Does that makes sense?

[alexander]

Would you mind adding FTP details? There’s something I could test further by adding some debug code to the child theme. Thanks!

[dhunink]

Added the credentials to the secure note!

[alexander]

Thanks! I’ve added this code to the child theme:

function test_wp_footer() {
  echo '<!-- wp_footer -->';
}

add_action('wp_footer', 'test_wp_footer');

I checked about a dozen different pages and it’s outputting <!-- wp_footer --> on all of them.

I didn’t make any changes, so I’m not sure why it’s working now rather than before. Anything change on your end?

[alexander]

We’re going to go ahead and move forward with the release, so I’m moving this topic over to the support forum. We can continue discussing there if there is anything outstanding.

[dhunink]

Hi @alexander!

Together with the developers of the WP Rocket caching plugin we were able to track the issue down to a specific pieces of code in Pro Theme. The caching plugin put’s it LazyLoad scripts in the footer.
The lead developer wrote:

any action hooked onto wp_head and wp_footer with a priority greater then 10.000 is removed by this code

He reffers to the following snippet, found at

/wp-content/themes/pro/cornerstone/includes/classes/styling/class-font-manager.php lines 213, 214

public function flush_queue() {

$method = array( $this, 'flush_queue' );

remove_action( 'wp_head', $method, 10000 );
remove_action( 'wp_footer', $method, 10000 );

$this->load_queued_fonts();
$this->queue = array();

}

As I understand it he could be having a point. As this function removes the wp_head and wp_footer action, they will have a hard time outputting their lazy load scripts in the footer. What I don’t get, but might be relevant to a solution, is why this issue occurs mainly on pages where a Global Block is used.
Could it be that the flush_queue() functions is used differently on those instances?

[alexander]

Try version 2.0.1 - I ended up having to make some changes there to solve a problem with TypeKit.

I don’t think that is the problem regardless. Calling remove_action will only remove the function passed as the second parameter. That code in the font manager class is just to make sure the font queue isn’t output more than once.

[dhunink]

Running 2.0.1. Same issue.

But…as soon as I comment out the content of the fcuntion, the Lazy Load script is actually loaded in the footer and everything works like expected. But, as said before, this is only an issue when a global block is used on a page.

public function flush_queue() {

    /*$method = array( $this, 'flush_queue' );
    remove_action( 'wp_head', $method, 10000 );
    remove_action( 'wp_footer', $method, 10000 );

    $this->load_queued_fonts();
    $this->queue = array();*/

  }

Changing the priority will also fix this issue, as per the following code:

public function flush_queue() {

    $method = array( $this, 'flush_queue' );
    remove_action( 'wp_head', $method, 9999 );
    remove_action( 'wp_footer', $method, 9999 );

    $this->load_queued_fonts();
    $this->queue = array();

  }

So here’s the conclusion so far:

• if a global block is used on a page, the wp_footer action is not outputting JS used for LazyLoad
• as soon as the function flush_queue() is not applied at all, or the priority inside this function is lowered from 10000 to 9999 the wp_footer hook works perfectly and other scripts, such as a LazyLoad script, is actually present in te footer

Although a simple fix would be to lower the priority for the calls inside the flush_queue() function, I would lean towards investigating this a bit more and figuring out why this is only an issue when a global block is used on a page. But I lack enough understanding of the new coding-concept behind the global blocks. Could it be that Global Blocks call the flush_queue() function (as does the total page)? Any other thoughts?

[alexander]

Could you try the build provided in the secure note? For 2.0.2 I removed the hook priorities and created a new hook to access wp_head later. Let me know if that makes a difference.

[alexander]

2.0.2 has been pushed to automatic updates. You could try that as well as the changes are included. Let me know how it goes.

[dhunink]

So far this seems to have done the trick. I will double-check a bit more but right after the update the Lazyload script seems to work correctly now!
Looks like you dropped al the files inside the classes/styling folder. Is that correct?
(just checking, since the update was not really smooth at my end and I just want to make sure nothing went wrong).

[alexander]

No, we didn’t remove any files. Did you update via FTP? If you did and you’re missing files, it might be a FTP connection issue. I’d recommend switching to another theme, then installing via the WordPress theme uploader.

[dhunink]

My bad. I updated WordPres style, but checked the files over FTP. Apparently there was a small delay there. Just restarted my FTP client and see the same files again
Looks like the fix indeed consisted of removing the forced priority of 10000. Everything works perfect at my end
I’ve relayed the solution to the dev-team of WP Rocket as well.

Thanks for all the efforts @Alexander, I absolutely appreciated it!

Looking forward to beta-testing the next updates. Cheers!

[alexander]

Ok great! Glad to hear it’s working.