Skip Navigation

[Escalated to 2nd Tier] Taxonomy archive view is not loading properly

This support ticket is created 2 years, 2 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 9:00 – 13:00 -
- 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 14:00 – 18:00 -

Supporter timezone: Asia/Karachi (GMT+05:00)

Author
Posts
#2454171
Image 2.png
Image 5.png
Image 4.png
Image 3.png
Image 2.png
Image 1.png

Tell us what you are trying to do?
I have constructed a taxonomy archive view 'organisation' (legacy version) displaying a list / table of legal information for our customers / companies. Each company has its specific collection of legal information. So when a customer logs in, he will see in the navigation menu just the link to his specific list, which is based on the taxonomy archive 'organisation'. Each company has a specific taxonomy term 'organisation'.

- Image 1 Frontend view of the list (example) with filter section
- Image 2 Code of filter section
- Image 3 Search Settings
- Image 4 Query filter section

There are about 2'100 legal documents in total, the number of documents per organisation is in the range of 150-400. So when the user calls his list, he should just see the specific documents of his company. This works fine for the table / list of documents, BUT: The first frontend / query filter 'Katone / Land' displays after the first loading of the page not only the terms, which belong to this specific company, but ALL terms (despite I have configured the archive 'only options producing a result are displayed'), see image 5. When I then press the button RESET, the filter 'Kanton / Land ' will just contain the terms which belong to the specific company.

This behaviour of the front end filter is irritating for the user, because he will see not only his own taxonomy terms, but a lot of others, which are not relevant to him (and which will not produce any results by the way).

It seems to me that the view is not loaded properly. I have tested different settings inactivating some selected plugins (wp rocket, admin columns, WP external links), without succes. Keeping in mind, that maybe ressources to load the view are not sufficient, I have activated in wp rocket plugin CDN, without success.

I use the same view on our website, not as archive, but as 'normal view', where an additional frontend filter 'organisation' is installed. This view is just used by admin to test the data for our customers. This view works perfect, not showing the problems of the archive view.

Is there any documentation that you are following?
Regular Toolset documentation.

Is there a similar example that we can see?
--

What is the link to your site?
hidden link

#2455127

Hi,

Thank you for contacting us and I'd be happy to assist.

I get the basic understanding of the structure from the screenshots, however, to troubleshoot this, I'll need to see exactly how these elements are set up in the admin area.

Can you please share temporary admin login details in reply to this message?

Note: Your next reply will be private and making a complete backup copy is recommended before sharing the access details.

regards,
Waqar

#2456251

Thank you for sharing these details.

I've performed some tests on my test website and on yours (logged in as the user that you provided), but couldn't reproduce the issue.

While logged in as that user, I checked the archive for the organization "BH-SSBL" and when I changed some search filter fields, the options in the "Kantone / Land" field updated, as expected too.

Could you share some specific steps, to see the issue, where irrelevant options start showing, after the AJAX?

#2456279

Dear Waqar,

thank you for your tests! Maybe I did not explain well enough the problem:

If you call the list of legal information and you perform an AJAX based search, then the filter 'Kantone / Land' will behave as expected. That's what you noticed.

The problem is located elsewhere: if you log in and call the list of legal information for the first time, then the table is loaded. AND JUST AT THAT POINT, when you have not yet made any search, we encounter the problem: if you click on the drop-down filter 'Kantone / Land' just after loading of the table, then ALL OPTIONS' will be displayed, even those which produce no resultes for the organisation selected. So the user without any experience will not know, which option he should select (see also screenshot 5).

With my settings in the view, the 'unnecessary options', which produce no results, should not be displayed. But THEY ARE, what is irritating for me and not appropriate for the user.

Kind regards

Franz

#2457169

Thank you for sharing the details and I now understand what you mean.

While I can see the issue on your website's archive, I couldn't reproduce this on my test website. This suggests that something specific to your website is involved.

Do I have your permission to download a clone/snapshot of your website, to investigate this on a different server?

#2457271

Dear Waqar,

yes of course you can copy my site!

I have the feeling, but I can not reproduce it, that this problem arrised in the last time and was not present before. Something that has changed on the level of plugins, wordpress or theme?

I made an interesting observation:

When I load the page with the table containing legal documents, then the first filter 'Kanton / Land' will show all options or all taxonomy terms, even when they are not relevant for the customer and do not produce any results.

If I then cklick on the RESET button, this filter will display the correct options, i.e. those which are relevant for the customer.

BUT if I make a PAGE REFRESH, then the filter will fall back to the initial state, displaying all terms.

So it seems to me, that the view is working correctly, but that there is another factor disturbing the loading of the view.

Beside the problem with this filter, there is another trouble puzzling me: the first position of the drop-down filter, which normally is called 'all', renders the results of all terms of this taxonomy. What is NOT THE CASE in this view, filtering the view using this first position or ALL in the filter 'Kanton / Land' will get NO ITEMS FOUND.

This just some explanations for you

Kind regards

Franz

#2458935

Thank you for the permission and I've downloaded your website's clone.

I'm currently running some tests on this clone and will share the findings, as soon as this testing completes.

Thank you for your patience.

#2460909

Just wanted to update you that, I'm still working on this and will share the details, as soon as I can.

#2460989

hi Waqar,

many thanks for your support! Hopefully you can find out what's wrong with this archive

Kind regards

Franz

#2461859

I had some busy forum queue after the weekend, but I'll resume work on this today.

I'll be able to share a detailed update, within the next few hours.

#2462911

Thank you for waiting.

After testing, I can confirm that this is the same issue that is already reported to the concerned team:
https://toolset.com/errata/setting-show-only-filter-options-that-would-produce-results-doesnt-work-correctly-for-taxonomy-filters/

Although I don't have a time estimate to share at the moment, I'll keep you updated through this ticket.

For now, you can include the following custom script in your WordPress Archive's "JS editor", which will force the 'change' event on the "Kantone / Land" field, when the page loads. This way, the options of the search fields will update too:


jQuery(document).ready(function( $ ) {
	$('select[name="wpv-kanton"]').change();
});

#2463025

hi Waqar,

many thanks for your answer. I inserted the custom script in the search section. So once the view is loaded and reset , the query works fine: I changed the search settings to 'reload page when visitor clicks on search button' (in this way, the icons for external links in the table are loaded correctly), and if I make a search with the frontend filters, it works just fine, the filter 'Kanton' just displays those terms which are relevant for the specific customer. So 'page reload' will not bring back all terms in filter 'Kanton' as before, that's great.

BUT on INITIAL load, when clicking in the navigation menu on position 'Gesetzesliste xy' and loading the view, the filter 'Kanton / Land' still shows ALL TERMS instead of only those which are relevant for the customer. It seems, that loading the view in this way, the page is not really reloaded.

So is there a way to change the behavior of the filter at INITIAL LOAD? This point of workflow is very important for the user to select the right filter terms. One the user has worked with the view, the filter 'Kanton' works as expected, but not at the beginning.

I hope that I could make clear the actual situation. There is an improvment, but not yet enough for the initial load.

Kind regards

Franz

#2463737

Thanks for writing back and glad that we're making progress.

This seems like a cache issue because the code should work the same no matter if you visit the page through the direct URL or through the navigation link.

I noticed something else too. When I visit the archive page with the direct actual URL ( eg. {yourwebsite.com}/organisation/ssbl/ ), the script doesn't seem to work.

But, if I add some extra URL parameter like "?no-cache=true" at the end ( e.g. {yourwebsite.com}/organisation/ssbl/?no-cache=true ), the script works as expected.

So, I'll recommend clearing all involved caches at the plugin, CDN, and server levels and then checking the archive page again.

#2464033

hello Waqar,

you are right, that's the caching! Everything works well now, many, many thanks for your support. So I hope that I will get information about this bug soon. But for the moment, with your turnaround, we are doing well.

Kind regards

Franz

#2464951

Glad that this is sorted for now and I'll keep you updated on the original issue.