[Résolu] Latest Update Introduces Issues for Date Filtering

[Auteur]

Publications

[zacharyL]

I have a site that uses multiple views utilizing post date filtration functionality and I'm finding that after I update Toolset Blocks to 1.6.15 from 1.6.14 that this functionality no longer works.

Please see the production environment where I had to dial everything back here to get everything to work: lien caché

And here is the same section in staging where everything is up to date and the view loop output is not displaying any items: lien caché

I disabled all other plugins on staging to eliminate the possibility of plugin conflict. The problem persists. Attached is a screenshot illustrating my views' post date filter configuration. Both Date Condition configurations appear to no longer operate as expected.

The WordPress admin credentials will be the same for both environments. sFTP connection will require connection to port 2222.

Any help in this matter would be greatly appreciated. Thanks in advance!

[Nigel]

Hi there

The page content where the Views to generate the reports is different in the production and staging sites.

In the (working) production site, you insert the View as per this first example:

[wpv-view name="resource-links" resourcetype="reports" department="consumer-confidence" postyear="[display_year offset='1']" limit="3"]

In the (non-working) staging site, you insert the equivalent View like so:

[wpv-view name="resource-links" resourcetype="reports" department="consumer-confidence" limit="3" cached="off"]

The View date filters are based on a 'postyear' shortcode attribute, but on the staging site you don't provide such an attribute.

The changes between production and staging are not simply the plugin versions; how the content has been inserted is different, and that looks like it would account for the reports not displaying.

[zacharyL]

Oh, I was troubleshooting trying to figure out why the views weren't outputting any posts and forgot to change them back for you guys before reporting the issue. I can rectify that now so that the application is the same. I thought that maybe my custom function ceased to be supported, but as you can see the view still doesn't output anything with my custom code removed from the equation. Sorry for the mixup.

[zacharyL]

I reverted the view shortcodes back to how they're configured on production and applied cached="off" to be sure that the views aren't caching old data.

Additionally, I should explain what my [display_year] shortcode is doing: it just outputs the current year with an offset attribute that allows us to subtract from the current year, so the filter logic behind [display_year offset='1'] is to show posts that have been published last year and newer by outputting the previous year for the "postyear" view filter.

I should reiterate that after finding that my views weren't outputting posts (after troubleshooting and confirming that the posts exist, and published, that fulfilled the filter parameters) like they were before, I restored a backup I had made prior to updating to the latest version of Toolset Blocks, and the views output just fine. It's only when I update to the latest version of the Blocks plugin do these particular views cease to operate as expected.

[Nigel]

There were some changes made to date filtering in the latest version to fix some long-standing anomalies, which it looks like you may be being affected by.

The query filter for dates includes TWO conditions that should both be true (screenshot).

Where you insert the View to output the reports you use this shortcode:

[wpv-view name="resource-links" resourcetype="reports" department="consumer-confidence" postyear="[display_year offset='1']" limit="3"]

The shortcode attribute postyear is used in the first of the two conditions.

The second condition compares against the values of shortcode attributes meetingyear and meetingmonth, but you don't provide values for them.

I'm guessing that prior to the plugin update these were ignored, but since the plugin update they are defaulting to the current values (i.e. 2024 and 05), which I can see from the debugging screen is leading to a query which is probably not what you intended.

So, is that additional date condition necessary given that the parameters are not being supplied?

[zacharyL]

The additional date conditions are necessary in other applications of this view, as well as in a modified version of this view, labeled "Resource Links (Grouped by Month)". The applications that do still use the meetingyear and meetingmonth attributes for the "Resource Links" view are nested within a view labeled "Meeting Schedules" (also found on other affected pages linked below). The presumption was that if the attributes weren't being used for all the applications, they wouldn't impact the output of the view, as they had operated in this manner up until this point.

This is where these views exhibit similar filtering issues as seen here:

On Staging where it's broken: lien caché

And in working condition on production: lien caché

Please note that the meetingyear and meetingmonth attributes are indeed mission critical for some of the applications for these views, especially for the Board Member Resources.

[Minesh]

As Nigel shared with his previous reply:
- https://toolset.com/forums/topic/latest-update-introduces-issues-for-date-filtering/#post-2700187

It takes current yearn and month value as default date due to the changes made with date filters.

Can you confirm if you override the values to empty for month and year - does it works as expected? OR
Can you please share bit more details what views your are using with nested view and what is your expected result.

Maybe you can create a test page where we will add all those views and run a test and do required modification.

[zacharyL]

We can run tests in the staging environment so that we're not affecting the operation of the production site given how the output of these views are of upmost importance to the client. They are required BY LAW to have these reports on their website and the Board Member Resources are a important. . .well. . .resource for their board members.

"Can you confirm if you override the values to empty for month and year - does it works as expected?"

It does not work as expected, because when I removed the attributes from the views in question, they still didn't output any posts. The presumption being that if the attributes were not in use, they wouldn't affect the output of the view(s). This has always been the case until recently, and what is currently the case in production, regardless of the type of query filter I'm using. This latest update even affects all applications of this view regardless if I need to check against the post date or not, and this is simply unacceptable behavior.

If you have any alternative workarounds for the applications of my views, I'm all ears, though I'd rather not have to create duplicate views that accomplish the same thing but with different query filter options if I don't have to.

Regardless, here are the features I require:

• A list of links that filter results based on terms from the Resource Type and/or the Department taxonomies
• A list of links that filter results based on if the publish date's year is after or equal to a value I input via a shortcode attribute labeled "postyear"
• A list of links that filter results based on if the publish date's year is equal to a value I input via a shortcode attribute labeled "meetingyear". I am unsure if I'm actually using the "meetingmonth" attribute at this time, so we may be able to nix this if I can't find any applications that use it.

Some progress I've been making after making some adjustments to my views (in the staging environment).

What I've noticed is that if I change the operator from AND to OR on the post date conditions, on the "Resource Links" view, I receive results on the views that use the post date conditions (lien caché). I've also removed the "meetingmonth" attribute in this view to hopefully alleviate some configuration conflict issues. The applications that do not use the post date condition attributes still output no results (see the absence of posts under the "Source Water Assessment" header: lien caché).

Additionally, I've removed the "meetingmonth" attribute from the "Resource Links (Grouped by Month)" view and that appears to address the issues I was experiencing on the Board Member Resources pages: lien caché

So am I going to have to split the "Resource Links" up into separate views with one that strictly maintains date based filtration and another that doesn't? That sounds very limiting to me and would require me to go through every application of this view that uses date condition query filters and update them with the new view slug. Also, it seems like quite a severe bug to me when a query filter that is assigned to use a specific attribute still affects the output of a view even when the attribute is not in use, and that creating a separate view to manage those attributes specifically seems more like a Band-Aid solution than a more permanent one.

In any case, I'm open to any alternative solutions or configurations.

[Minesh]

Can you please try to downgrade the Toolset Blocks plugin to previous version for now as our Devs are working on a fix that should be able to resolve your issue.

[zacharyL]

Toolset Blocks is currently out of date on production, so we're good there.

[Minesh]

Just to let you know that the fix for this issue is already published with the latest Toolset plugins.

We publish hotfix version for many Toolset plugins:
- https://toolset.com/2024/07/toolset-1-6-16-essential-updates-for-wordpress-6-6-and-better-workflow/

*** Please make a FULL BACKUP of your database and website.***
Cam you please update ALL Toolset plugins to it's latest official release version and check if that help you to fix the issue.

More info:
- https://toolset.com/faq/how-to-install-and-register-toolset/#automatic-update-requires-registratio

OR

You can download the latest Toolset plugins from your account's page:
- https://toolset.com/account/downloads/

[zacharyL]

Thanks for the update. I'll post back here with my findings.

[Minesh]

ok - please let us know.

[zacharyL]

It doesn't appear to address the issue I'm having in version 1.6.16 (see screenshot1.jpg). Left panel is staging with everything up to date and the right panel is production where Toolset Blocks is left at 1.6.14.

screenshot2.png displays what my filter configuration is. Both production and staging environments have the same user credentials, so you should be able to equally access them to look for yourself. I just duplicated the production environment over to staging to test this latest update, so everything should be configured in the same manner as it is on production.

You can view the page in question, but you'll need to be logged in:
lien caché
lien caché

[Minesh]

Thank you for sharing information.

I loggedin as admin user and when I try to access the page:
- lien caché

It shows nothing on the page and redirect me on login page again.

Do I need to login as frontend user? if yes: can you please share frontend user access details.

I have set the next reply to private which means only you and I have access to it.