As per the attached query filter screenshot, we are wanting to display every custom post (course) based on "course state" retrieving a value from the URL_PARAM as well as a constant. In this example, this is "Aus".
With the recent upgrade to Toolset View (Version 3.1.2), this is no longer working?
Hello, I can see a similar difference between the results rendered in Views 2.9.4 and Views 3+ when a constant is added to the URL parameter like this in my local test site. Let me escalate this issue to my second tier support team for additional investigation, and I will update you when I have more to share.
Our second tier team has escalated a ticket to the developers for some explanation here. It's not clear if this was ever intended to work as it did prior to Views 3, since the Query Filter's "IN" condition isn't available when creating a front-end filter. Only after the filter is created can you then edit the Query Filter settings and choose "IN", which would seem to break the front-end filter...though this exact scenario did work correctly in the past. We are waiting for some clarification on that and I will let you know what I find out. Regardless, it's obvious to everyone the behavior is different in versions less than 3.0 and versions 3.0 and greater.
Hello, I can see that there has been some activity on this issue from our developers. It seems there are two separate issues with the "IN" comparison in Query Filters, and we are working to cover all the possible scenarios when combining URL params and constants. I haven't received any concrete timeline or whether or not this will be included in the next release of Types and Views/Blocks, but I can say there has been progress. I haven't had a moment to look for a custom code solution yet but if the queue slows down this afternoon I will try to find some time for investigation. That's all I have for now!
Hi, Shane was checking in on several tickets in my queue yesterday while I was out. Unfortunately I have not yet had time to dedicate to a custom code solution, but I can see that the developers have a fix pending release with Views 3.2 and the next version of Types. I did not receive a patch, so unfortunately there's nothing immediately available. Once we have a timeline established for those releases I will give you an update.
Hello, this is a two-part fix scheduled for release in Views 3.2 and the next release of Types. That means both plugins must be updated in order to fully resolve the issue. You are correct that Views 3.1.3 does not include the fix yet, and Views 3.2-beta does not contain a complete fix because Types has not yet been updated. I'll keep you posted here as I receive more information about any upcoming releases.
