[Migrated] Filter Bar, Changing Dates, And Unwanted Query Parameters

[mrwweb]

At Leah’s request, I’m moving this on-going open support thread from the WordPress.org forum to here for speedier updates. I’ll post a note there to that further troubleshooting is occurring in this thread.

A brief summary of the issue with site using PRO and Filter bar (among others):

When either changing to certain views (Week, Day, and Month seem to do it most of the time) or changing the time period viewed either via paging OR the “Find Events” > Date selection, the following gets appended to the URL and most events don’t show up because of it: &tribe_cost=0-50-90.

I’ve done a significant amount of troubleshooting and discovered that the issue seems to be specific to PRO.

Note: For the time being, the Filter Bar is deactivated on the site to avoid the issue.

[Brian]

Hi Mark,

Thanks for the information and I looked over your thread on WP.org.

I tried to reproduce, but was not successful yet.

Do you have default permalinks on? or is this with pretty permalinks.

You setup a test site correct? Would you be able next week to test the 3.10 beta and see if that resolves it?

Let me know and we can go from there.

Thanks

[mrwweb]

Problem appears in the same format—&tribe_cost=0-50-90—with both pretty permalinks and default. Flushing and “resetting” permalinks (turning to default and back) does not resolve the issue.

Don’t know if this is relevant to reproducing at all but the site uses a lot of recurring events.

If at all possible, I’ll try the beta next week.

[mrwweb]

Where can I find the 3.10 beta to download and try?

[Brian]

Hi Mark,

We had a delay with an issue and we are fixing that update today. I hope we have it ready either today or tomorrow, but that could change. Does that work?

Let me know or we maybe to get something else going.

Cheers

[mrwweb]

No promises, but I’ll try.

[Brian]

This reply is private.

[mrwweb]

Was finally able to test the beta and it did seem to fix it at least on my stripped-down local copy. I’m not sure I feel comfortable considering this resolved until the update goes live on the real site, but this seems promising.

[Brian]

Glad it looks promising. I will keep this open for now and we will get back to you in the beta forum about those issues. I believe we already found them, but will double check.

Thanks again for testing it out.

[mrwweb]

🙁 Scratch that last message. I think some JS errors made it look to be functioning. Fixed the JS errors and got the bug back again.

[Brian]

This reply is private.

[mrwweb]

This reply is private.

[Brian]

Ok Good News. I was able to narrow down and fix the issue.

Your event titled Adult Weekend on 2015-03-13 cost is set to 50-90

The max function in php was considering that to be the highest value and so it was using that in the Cost Filter, which broke everything.

Removing that cost from that event fixed the issue on the test site you provided.

Let me know if that does the same for you.

I am also creating a bug report on this so we can take into account issues such as this and not break it as it did for you.

Thanks for getting me the files on this and testing on your own.

Cheers!

[mrwweb]

That is good news and it did resolve the problem!

I can say that just in my experience, I see people do all sorts of stuff with that field including ranges, phrases, etc., so some more aggressive validation and sanitizing of that field seems in order. A way to support cost ranges would certainly be useful.

A weird other issue here was that the WooCommerce Tickets add-on hides the Cost field so it took us a while to remove the value (I hadn’t resorted to going straight into the DB yet but was heading there). That’s another point of confusion.

[Brian]

Ok great, glad it resolves the problem.

A weird other issue here was that the WooCommerce Tickets add-on hides the Cost field so it took us a while to remove the value (I hadn’t resorted to going straight into the DB yet but was heading there). That’s another point of confusion.

Yeah I can see how that can be confusing.

In the future there is this article that has a snippet to always show that field:

https://theeventscalendar.com/knowledgebase/use-the-event-cost-field-with-tickets-installed/

I can say that just in my experience, I see people do all sorts of stuff with that field including ranges, phrases, etc., so some more aggressive validation and sanitizing of that field seems in order. A way to support cost ranges would certainly be useful.

Agreed, in my bug report I mentioned we need to have better validation to not cause this issue and a cost range would be nice too.

Thanks for helping out with the testing on this and in the 3.10 beta.

[Author]

Posts