|
wmnf
|
December 22, 2015 at 7:20 am
We’re having a very weird issue with the ESPRESSO_EVENTS shortcode. We have an empty page that uses a template file with 4 different div containers where each container has a separate shortcode for a different category-slug. There is jQuery attached to the page with a dropdown that hides/shows each div according to what you select. All of a sudden, it no longer works and shows the same default category slug no matter what is selected. I checked the source of the page and find the jQuery is doing its job hiding and showing the appropriate div container, the problem is all the same events for the first category are listed in all 4 div containers. This is what it looks like:
<select id=”soflow”>
<option value=”1″>WMNF Events</option>
<option value=”2″>Community Events</option>
<option value=”3″>Music Events</option>
<option value=”4″>Nonprofit Events</option>
</select>
<div id=”wmnfevents”>
<?php echo do_shortcode(‘[ESPRESSO_EVENTS category_slug=”wmnf-events” limit=”20″ title=”WMNF Events” order_by=”start_date,id” pagination=”true”]’); ?>
</div>
<div id=”communityevents”>
<?php echo do_shortcode(‘[ESPRESSO_EVENTS category_slug=”community-events” limit=”20″ title=”Community Events” order_by=”start_date,id” pagination=”true”]’); ?>
</div>
<div id=”musicevents”>
<?php echo do_shortcode(‘[ESPRESSO_EVENTS category_slug=”music-events” limit=”20″ title=”Community Events” order_by=”start_date,id” pagination=”true”]’); ?>
</div>
<div id=”nonprofitevents”>
<?php echo do_shortcode(‘[ESPRESSO_EVENTS category_slug=”nonprofit-events” limit=”20″ title=”Community Events” order_by=”start_date,id” pagination=”true”]’); ?>
</div>
</section>
When this page loads, all 4 div containers have the same records for the category-slug of wmnf-events. The weird thing is that the page still works on our development site. I have checked the events to ensure they are assigned to the correct categories and verified the same version of plugins are used on both sites. The only difference between the live site and dev site is basically the HTTPS being used on the live site. Do you have an idea why this would be happening now or how to troubleshoot further?
|
|
Josh
|
December 22, 2015 at 8:55 am
It sounds like something is resetting the query. Do you have the same version of WordPress on both sites?
One other thing you can do that may help is remove those double quotes for each parameter value, with the exception of the title= parameter, and you’ll want to make sure that those are not curly quotes in your code.
|
|
wmnf
|
December 22, 2015 at 8:57 am
No, the dev site is running the latest 4.4 and we have not upgraded from 4.3.1 on the live site yet. I was hoping to wait until I’m back in town from a holiday trip before doing that, but guess I can try if you think that may be an issue.
|
|
Josh
|
December 22, 2015 at 9:01 am
I asked about the WordPress version because I was wondering what other things might be different from the dev site to the live site. If it’s only https and WP version, then that may be an indication that is a WP version issue. But if this worked before on WP 4.3.1, then it may be something else unique to the live site.
|
|
wmnf
|
December 22, 2015 at 9:08 am
Yeah, I realized the WP version was different after I posted my question. I believe I have published all other changes to the live site in an effort to resolve and will try the WP upgrade later. Thanks.
|
|
wmnf
|
December 29, 2015 at 9:00 am
Still trying to debug this issue and have a question. Like I said, it is very perplexing that this still works on our dev site, but any attempts to duplicate the page and template have the issue. To try and understand if there is any server related problem, I have downloaded a fresh copy of the live site to the local dev server and updated accordingly for the different domain. For some reason, EE4 thinks I have version 4.7.9.p, but looking in the plugins, it indicates 4.8.27.p is installed and the db was dumped from the live site in its current state. This is the message I’m receiving on our dev server where all was copied to:
Event Espresso has detected event data from version EE4.7.9.p (Core) that can be migrated (updated) to work with version EE4.8.0 (Core).
Do you know why this would be?
|
|
wmnf
|
December 29, 2015 at 11:18 am
Debugging and searching for an answer to this issue. I found this post that describes exactly the same thing:
https://wordpress.org/support/topic/two-instances-of-shortcode-duplicate-data-where-it-shouldnt?replies=4
I also posted the issue to Stack Exchange and one person noted that “you should never ever use $wp_query as a local variable, this breaks the main query object which might cause issues” when looking at the process_shortcode function in the plugin EES_Espresso_Events.shortcode.php file. Just wondered if either of these tell us anything related to the issue?
Also, while debugging, I put the four instances of the shortcode in the page instead of using the template with do_shortcode calls and it works, the different records for each category showing correctly. However, this presents other issues with getting all the styles and titles to work as we had.
|
|
Josh
|
December 29, 2015 at 2:20 pm
You’ll have a better time with the custom template if you do not use the [ESPRESSO_EVENTS] shortcode within the template using do_shortcode calls. It was never intended to be used this way. If you’re already using a template, you can do multiple loops within the template.
FWIW, The issue with using $wp_query as a variable was earlier brought up with the lead developer of Event Espresso and his reply was:
Because of the fact that we are properly resetting the $wp_query global after our usage, which means that it should not have any adverse affect on other uses of it. It kinda works like this:
// set by theme (or WP or whoever)
$var = "banana";
// later on in our code...
$original_var = $var;
$var = "monkeys";
// do some stuff
// reset $var
$var = $original_var;
// meanwhile back in the theme (or WP or wherever)
echo $var;
// **should** output: banana
so as you can see, even though we redefine $var, it has no effect on any other code because of the fact that we reset it after we are done with it. Of course, a theme could do something funky and unorthodox which complicates this and blows things up, but we shouldn’t have to jump through hoops to accommodate bad code, when ours is following proper WP convention. Redefining the $wp_query global IS proper WP convention and is perfectly acceptable, which is why they have functions available for resetting it. They wouldn’t do that if you weren’t supposed to touch it !
all of the places where we are redefining the $wp_query global are places that for all intents and purposes, should behave as if they were the main query. We currently have LOTS of code that performs checks for the main query and then applies changes and/or runs some logic if the main query is encountered. If we were to change our shortcodes that redefine the $wp_query global, then some of those checks would return false and those changes/logic would no longer be applied. We will have to find some other more complicated way of identifying whether or not the current query should be processed.
|
|
wmnf
|
December 29, 2015 at 2:29 pm
I completely trust your judgement regarding the variable handling. I am working now to replace the way our third party developer handled this and will use the methods you suggested. Thanks!
|
|
Josh
|
December 29, 2015 at 2:45 pm
To be clear, the judgement/remarks regarding $wp_query belong to the lead developer of Event Espresso, they are not mine.
|
|
wmnf
|
December 30, 2015 at 4:32 am
Understood, I certainly hope this is not going to present any issues. Could you let me know what you think about the version discrepancy I noted before?
|
|
Josh
|
December 30, 2015 at 8:38 am
That’s likely coming from the options table.
|
