[Resolved] Text search returns wrong post type in results
This support ticket is created 4 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.
No supporters are available to work today on Toolset forum. Feel free to create tickets and we will handle it as soon as we are online. Thank you for your understanding.
I am trying to: Use Views and Types to develop an advanced custom search of a custom post type.
Link to a page where the issue can be seen: hidden link
This page utilizes a view displaying just the filter form and links to a separate search results page (compare to hidden link which utilizes a view that displays the results on the same page and does NOT exhibit the bug).
I expected to see:
Entering the keyword "camp" (no quotes) into the keyword search field should return two results on the search results page; the results should strictly be from a custom post type. (Running the same search on hidden link -- using the Toolset search, not the Google search -- will return the correct results: DIY Girls and CreateCa ToolKit.)
Instead, I got:
The search results page displays a set of generic WordPress posts instead of the posts in the custom post type that was designated in the view.
Some interesting notes:
1. On hidden link, if you simply click the "Search the Resource Hub" button without entering a keyword or altering any other filters, you'll get results of all posts from the correct custom post type, which is what we would expect.
2. On hidden link, if you use one or more of the filters ("Select a category" and/or any of the filters revealed when you click "More ways to find the resources you want…") and NO keyword, the correct results are returned.
3. So apparently, the bug only occurs when activating the keyword text search (i.e., the first input field that has the placeholder "Search by keyword")
Attached is a screenshot of the View configuration. Thanks in advance for the support!
Thank you for contacting us and I'd be happy to assist.
While I can see the reported issue on your website, I couldn't reproduce it on my test website with a similar view.
To troubleshoot this, I'll suggest the following steps:
1. Please make sure that WordPress, active theme and plugins are all updated to the latest versions.
2. It would be interesting to test this with all non-Toolset plugins disabled and a default theme like Twenty Twenty.
If it's fixed, you can start adding the disabled items, one-by-one, to narrow down to a possible conflicting one.
3. In case the issue still persists, I'll need to see exactly how this view, search form and results page is set up, to be able to reproduce and investigate this on a test website.
Let me know how it goes and your next reply will be private. Please make a complete backup copy, before sharing the access details.
Okay, I've gone through the testing protocol and confirmed that the bug does not occur when all non-Toolset plugins are deactivated and we're using the 2020 theme.
Unfortunately, I did not develop the theme for this site (CA PTA 2015, which is evidently custom developed, not a purchased theme), so I'm at a disadvantage in anticipating where the issue might lie. It's also worth noting that the CA PTA 2015 theme requires the Advanced Custom Fields PRO plugin, otherwise it throws a critical error.
As soon as I switch to the CA PTA 2015 theme with only Advanced Custom Fields PRO and the Toolset plugins activated, I get the bug.
Are there any known issues in terms of conflicts with Advanced Custom Fields PRO, and/or can you think of anything that might point me in the right direction in terms of where to look for what might be causing the issue?
I couldn't find any similar report or a known compatibility issue with Advanced Custom Fields and it is most likely related to the custom-developed theme.
( a quick test to confirm this would be to keep only Toolset and Advanced Custom Fields plugins active with a default theme like Twenty Twenty )
I'm afraid, troubleshooting the code in the custom-developed themes is beyond the scope of support that we can provide ( ref: https://toolset.com/toolset-support-policy/ ), but we do our best to guide in the right direction whenever possible.
As requested earlier, would it be possible for you to share temporary admin login details so that I can perform some quick tests and troubleshooting?
Thank you for waiting while reviewed how these pages and their views are set up.
During troubleshooting, I couldn't notice anything in those views which could result in this behavior.
My recommendation would be to test:
- if the view "Resource Hub Search v2" works correctly when the search form and the results are shown on the same page.
( hidden link )
- also, it would be interesting to test if the same issue is faced when you try to use view "Resource Hub Search v1" with the search form and the results on a different page.
This will give you useful insights into whether the theme is having difficulty in showing search results and forms on a different page or is it specific to a particular view, a particular page or the page template used on that page.
For more personalized assistance around troubleshooting the custom code used in the theme, you can also consider hiring a professional from our list of recommended contractors: https://toolset.com/contractors/
I ran the additional testing you recommended and the results were puzzling to me!
The test conditions:
- All plugins off except the Toolset Plugins and Advanced Custom Fields:
- Using CA PTA 2015 theme
- Search on the word "camp" to test
- For comparison, run a search using no keyword and only filters.
Test 1: hidden link
Q: Does the view “Resource Hub Search v2” work correctly when the search form and the results are shown on the same page?
A: No, it does not work correctly... Same bug.
(Note that the search form is at the bottom underneath the results.)
Test 2: hidden link
Q: Does the same bug occur using view “Resource Hub Search v1” with the search form and the results on a different page?
A: Yes, the same bug occurs using view “Resource Hub Search v1” with the search form and the results on a different page.
Test 3: hidden link
Q: Does the same bug occur using view “Resource Hub Search v1” with the search form and the results on the same page?
A: No! The bug does not occur using view “Resource Hub Search v1” with the search form and the results on the same page!
So, the bug only disappears when using view “Resource Hub Search v1” and showing the results on the same page! Can you make any deductions from that?
After a good night's sleep I'm looking at this again and comparing the two views to see what's different. Here are the differences I'm observing:
Pagination:
- Resource Hub Search v1 is set to "No pagination"
- Resource Hub Search v2 is set to "Pagination enabled with manual transition and page reload"
Custom Search Settings:
- Resource Hub Search v1 is set to "AJAX results update when visitors change any filter values"
- Resource Hub Search v2 is set to "Let me choose individual settings manually", and then: "Update the View results only when clicking on the search button" > "Reload the page to update the View results" and "Always show all values for inputs"
There are also differences in the Search ad Pagination code, but I think these are mostly cosmetic. So I'm going to run some additional tests to see if I can isolate the bug to one of the above settings and will post the results here.
Test 4: hidden link
This test runs using Resource Hub Search v3, a duplicate of Resource Hub Search v2, but with the pagination setting changed to “No pagination”; showing the results on the same page.
We get the bug: (search on "camp"), results show posts instead of custom post type.
Test 5: hidden link
This test runs using Resource Hub Search v4, a duplicate of Resource Hub Search v2, but with the pagination setting changed to “No pagination” AND with custom search settings changed to “AJAX results update when visitors change any filter values”; showing the results on the same page.
No bug! Returns the matches in the custom post type!
Test 6: hidden link
This test runs using Resource Hub Search v4, same as test 5, but now separating the search results onto a separate page...
And now the bug is back.
Not sure what that tells us. I'm going to take a break, but I'll run additional testing to see if I can isolate the issue to either the pagination or the custom search settings.
One more question I'd like to get clarification on as I'm putting this back into my subconscious to work on: When Toolset shows the custom search results on a separate page, is everything determined by the query string? In Test 6, searching on the word "camp" (no quotes), the query string is:
I don't see anything in the query string that defines the post type, so I'm wondering if that gets designated via a session variable, or some other way?
Just trying to figure out why it would work when the results are shown on the same page, but not when they're shown on a separate page.
As for your question regarding query string, Toolset relies on them for the front-end filters but based on the view's settings, all of the query parameters may not always get exposed in the query string.
Just a note to let you know that when I installed and activated Duplicator (which I've used before and am familiar with), when I clicked on the Duplicator link I get the WordPress "white screen of death" (blank white screen, no HTML underneath, not even a PHP error message when debug is turned on). So I'm digging into that and once I figure it out (which may not be until next week), I'll get you that clone.
I scanned through the details of the ticket and see that your custom theme is creating problems with a split custom search View.
As Waqar already stated, debugging custom themes is outside the scope of our support policy, I note from the above that it works with a standard theme.
I'll take a closer look at this when I have some time, and will get back to you.
