Hi,
Sorry Oren (SOGO) for my late reply, I had missed your response until today’s Robert Sather‘s message.
I confirm that I have “wp_footer()” in my page (template) and, as I said, it has been blocked by one of the theme’s shortcodes, I know it because the pages in which I use the shortcode present the issue, whereas as soon as I remove that shortcode –from the those same pages– the issue goes away.
@robert Sather‘s proposed solution solves the issue on my side, BTW thanks Robert!
Oren, in case you want to further investigate the issue, I would be glad to grant you full access to my site (WP admin and and FTP credentials), if so, just let me know how should I send you the details (slack, email…)
Best regards,
Diego
Plugin Author
SOGO
(@orenhav)
Hi Robert,
it should not happen, it seems that you (plugin/ shortcode …) changing the global $post without using the wp_reset_postdata()
this function restore this global variable and it is the recommended way,
using your code is only a workaround for that issue and will solve it only on my plugin but honestly I think you should solve the issue but using the reset function.
please let me know if that help, or if you need anyway for me to implement this workaround
Hello SOGO!
You are correct, wp_reset_postdata() in the end of the template-file did solve the problem.
Thanks for the quick solution! 🙂
However, if it was up to me, i would implement my proposed solution to prevent any failure around all the sites that are using this plugin. As you know, it’s hard to know what kind of themes this plugin will be used with. With the proposed solution you will have total control of the post ID as you always want the originally requested post ID. ( As long as nobody changes the original query 😛 )
What do you think? Do you agree? 🙂
And the most simple solution, as you may already have though of, is to add wp_reset_postdata() in the beginning of your functions oh_add_script() and oh_add_script_footer().
It worked for me with that solution, and a lot less work 🙂
Hi Robert,
Would you be so kind as to post the code you have employed using wp_reset_postdata()?
I have tried it in different ways but it does not work on my side, sorry my programming skills are very basic.
Thanks!
Sure thing!
Update the function called “oh_add_script_footer”.
Give me a shout if it doesn’t work.
function oh_add_script_footer() {
wp_reset_postdata();
global $post;
if (!isset($post)) return;
$output = get_post_meta($post->ID,'_oh_add_script_footer',true);
echo stripslashes($output);
if(oh_show_me_on('oh_posttype_footer') && get_post_meta($post->ID,'_oh_add_script_footer_hide',true) != 'on' ) {
$sogo_header_footer = get_option('sogo_header_footer');
if (isset($sogo_header_footer['oh_footer'])) {
echo stripslashes($sogo_header_footer['oh_footer']);
}
}
}
Thanks Robert,
Unfortunately that piece of code is exactly the same as the one I had previously tried and it does not work on my side. Still, your first solution works perfectly, it is not as minimalist as this one but it does the job.
I wonder why both solutions work for you but only the first one works for me.
Do you think the issue may be related to the fact that the theme’s shortcode (that is causing the problem) code uses the query_posts() function?
I think I found where the problem was. The shortcode was using query_posts() without making a call to wp_reset_query(); –its purpose is to clean up after having employed query_posts so the original main query is restored– I just added it (to the shortcode’s file) and now the issue has gone away, without having to alter any code at all within the plugin.
It also works fine if I only add wp_reset_query(); at the beginning of oh_add_script_footer().
Of course this would confirm SOGO’s remark, although Robert might have a good point proposing to add wp_reset_postdata() and perhaps also wp_reset_query() to both, oh_add_script() and oh_add_script_footer() functions.
I hope you will excuse my lack of programming skills and knowledge, in case I am talking nonsense or saying what is obvious.
Thanks!
Plugin Author
SOGO
(@orenhav)
I am glad we found the solution for that.
but I do not think that it is a good idea to set a new global variable to support wrong theme coding 🙂
