[Bob]

Thanks Geoff. I think what we’ve decided to do is switch to using MailChimp’s RSS-driven post notification. Appears to be a lot more flexible.

[Bob]

Thanks Colby. Even though you weren’t sure why your fixed worked, I believe you DID find the bug. Between v3.4 and v3.5, in nav.php, if the listing is of past events, Modern Tribe changed the class assigned to the left navigation link from “tribe-events-nav-next” to “tribe-events-nav-previous”. It also changed the class assigned to the right navigation link from “tribe-events-nav-previous” to “tribe-events-nav-next”. The result of this change, in conjunction with the logic in tribe-events-ajax-list.js, is a bug.

I believe the code in tribe-events-ajax-list.js uses this class in forming a portion of the URL for the next page of events. As a result of the change to nav.php, this now leads to the following erroneous result: If the user clicks on the left navigation link (older events), the Ajax code should INCREMENT the “tribe_paged=#” portion of the URL, but instead it DECREMENTS it if greater than 1, or leaves it alone if it is 1. If the user clicks on the right navigation link (newer events), the Ajax code should DECREMENT the “tribe_paged=#”, but instead it INCREMENTS it.

The first screen of past events has a URL of …events/past/?action=tribe_list&tribe_paged=1. From that screen, the left navigation link should change the URL to …tribe_paged=2, but because of the bug, it leaves “paged” at 1. That’s why there’s no change in the events shown.

The right navigation link should result in …events/upcoming/?action=tribe_list&tribe_paged=1, but because of the bug it increments “paged”, resulting in an erroneous …upcoming/?action=tribe_list&tribe_paged=2.

Casey, while there may be some details we’ve missed, I believe we’ve now identified essence of the bug, and you should be able to pass it to Development to get it fixed.

Thanks.

Bob

[Bob]

128M in my development environment. As I mentioned, the problem occurs both there and in the test environment I gave you access to. I highly doubt it’s memory-related.

When you say “I’m not seeing these issues on my end”, specifically what have you done that you’re referring to?

As I suggested previously, I believe you should be able to download files & database to your own environment, if necessary, and then trace the code execution at the point the error occurs. I think it’s very likely you’re going to find a program bug that was introduced in v 3.5.

Thanks.

[Bob]

I did. Didn’t fix it. Sorry…

[Bob]

Casey,

I have already tested on a local server (using MAMP)–that’s how I first discovered the problem.

As far as a fresh install of WordPress and an empty database goes, I’m not really clear what you’re asking. Are you suggesting I start from scratch and then create a bunch of bogus Events and see if the same thing happens? That would take a great deal of time, and even if it didn’t lead to the same results–which would imply there’s something in the data triggering the problem–I think that would still mean there’s a problem Modern Tribe needs to fix. I think a more fruitful step at this point would be for you or someone else at MT to do some diagnostics on the test setup I’ve given you and see what’s happening at the point the “Previous Events” link fails. If you want to move things to your own dev environment, you can use WP Migrate DB (already on the site) to obtain the database and the March 31 BackWPUp backup archive (also on the site) to obtain the files.

Thanks.

– Bob

[Bob]

This reply is private.

[Bob]

I’ve set this up for you. I’m switching to a private reply with further details. Thanks.

– Bob

[Bob]

joinfof and anyone else for whom it’s useful: Here’s what I’ve done to work around the bug until Modern Tribe is able to fix it:

1) In Admin/Events/Settings, I’ve set “Number of events to show per page” to 20. This lessens the need for paging to see additional Events.

2) I’ve removed the buggy “Previous Events” and “Next Events” links by adding a dummy (empty) file to my theme. The relative path and filename are: “[theme name]/tribe-events/list/nav.php”. (You need to follow this exactly for it to work.)

Users wanting to see upcoming Events, as is the case 80% of the time, won’t even notice anything is missing, since they will simply scroll down to their Event of interest within the up-to-20 Events displayed by default. Users who want to look at historical Events will need to use the “Events From” selector at the top of the screen rather than click a “Previous Events” arrow–a minor inconvenience.

[Bob]

Thanks–glad to hear you know about it and a fix will be forthcoming as part of a broader change. It’s easy to fix in the short run–I just wouldn’t want to have to keep making the fix through future updates.

[Bob]

Hi Julie,

Glad to hear you’ve identified it.

Do you have a guestimate as to how long before the fix? I need to decide whether to code something for my customer to use in the interim.

Thanks.

Bob

[Bob]

I just ran into this on a site that’s still running EC Pro 2.0.11–so it’s not just a V3 issue. And the workaround Barry referenced worked for it as well (thanks!).

[Bob]

I’ve just tested with the 3.0 beta, and the problem appears to be fixed! Thanks.

(By the way, while making sure I could duplicate the error before upgrading the test environment to the 3.0 beta, I discovered one more condition necessary for the error to occur: the user needs to be logged in. Since the error appears to be fixed in the 3.0 beta, I haven’t bothered to figure out why.)

[Bob]

Sure, I’ll do that.
Thanks.
Bob

[Author]

Posts