Skip Navigation

[Resolved] Display/Search Multiple CTP for Search Archive

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.

Our next available supporter will start replying to tickets in about 8.55 hours from now. Thank you for your understanding.

This topic contains 7 replies, has 2 voices.

Last updated by aprilA 1 month, 3 weeks ago.

Assigned support staff: Waqar.


Tell us what you are trying to do?
I am trying to create a search archive page that pulls 3 different post types. 2 of which are custom post types created with toolset.

I am trying to follow the previous documentation located here:

I have created my 3 seperate views that return all results and added them into the search archive created by toolset. When I install Relavannci and then place the code in my functions.php page, no results are returned. If I remove the functions code I get all my results from my views.

Trying different items, I have tried to set my views to "display the results by custom search" as well with no luck. I have also created a template page using Divi Builder, that would override toolsets archive page with its own, then display the 3 views on the page with the Toolset View module. This also display all the results for my views, but immediately returns nothing once I add the functions code into my theme.

I have verified I am using the correct view IDs to replace the search IDs with.

What is the link to your site?
hidden link



Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)


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

To troubleshoot this, I'll need to see how these views are set up and the code is added in the admin area.

Can you please share temporary admin login details, along with the link to the example search page?

Note: Your next reply will be private and please make a complete backup copy, before sharing the access details.



I know you guys are in a different timezone, just curious if there is any update on this?

Thank you


I know its the weekend now, but I was curious if there was anything found on this issue?



Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

Thank you for sharing these details.

During testing on my website, I found that a few changes have been introduced to how post-filtering works in views since the solution from the older thread were shared. To make it work, you'll need some updated steps:

1. I slightly updated the custom code snippet from the older thread to:

add_filter( 'wpv_filter_query', 'add_url_query_search_term_filter',99,3 );
function add_url_query_search_term_filter( $query_args, $views_settings) {
	$view_ids = array( 456, 458, 460 );
	if (in_array($views_settings['view_id'], $view_ids)){
		$query_args['s'] = isset($_GET['s']) ? $_GET['s'] : '';
	return $query_args;

2. In the 3 views (with IDs 456, 458, 460), I included a query filter for the text search, so that view expects the search filter values.
( example screenshot: hidden link )

After these changes, the search results are working from the search archive on your website.

Important note: Your website seems to have a very aggressive cache as you have "Autoptimize" plugin active and the host WP Engine also applies cache and optimizations on its own. If you don't see the correct search results, please make sure to clear all involved caches and then test again.

As for the top padding issue, it is not related to content added by the Toolset plugins.

By default, your theme includes the following CSS code to apply the top padding to the content section, to compensate for the fixed header on the top:
( from file: {}/wp-content/themes/Divi/style.css )

body:not(.et-tb) #main-content .container, body:not(.et-tb-has-header) #main-content .container {
    padding-top: 58px;

But your website's header is much taller than 58 px, which is why the fixed header still overlaps the content section to some extent.

To overcome this, you can include the following custom CSS code to increase that top padding, in the general custom CSS:

body:not(.et-tb) #main-content .container, body:not(.et-tb-has-header) #main-content .container {
    padding-top: 130px;


So I am seeing progress here, but I am not getting the fields to display correctly for each view. It appears the Pages view is working, but the FAQ and Compounds are showing up blank. They are going through the loops and making the li's but I don't believe the correct amount of rows and not displaying the data itself. I did find that if I manually set the search in the URL it returns the correct values, but not using the default search in the nav. Is this something that DIVI is changing the search function? Is there a work around?

You can compare the amount of results the page should return by checking against the current site here.
Live Site URL after search:
hidden link

My Site after using search bar(Doesn't return results correctly):
hidden link

My Site if I manually set URL to just have ?s=METRONIDAZOLE (Returns the correct results)
hidden link



Languages: English (English )

Timezone: Asia/Karachi (GMT+05:00)

Glad that we're making progress.

I've performed some further tests on my website, but couldn't reproduce any issue with the results.

Also, I see only 1 compound post result, if I view the search page from the live website:
hidden link
( screenshot: hidden link )

And I see exactly 3 results (2 pages and 1 compound post), whether I perform the search through search from the header or by adding the URL manually:

hidden link
( screenshot: hidden link )

hidden link
( screenshot: hidden link )

Based, on this I can confirm that I'm not seeing any blank results or differences in the search results.

The intermittent difference in the results or display, would mostly likely related to cached content, as I pointed out in my earlier reply.


I don't believe it was an issue of caching because I temp. disabled all caching to test.

My only solution was to remove divi's custom search for it to pull the correct results. You can see this in my functions.php. This probably isn't the best method, but it is working. Let me know if there is a better solution or resolution.