Forum Replies Created
-
Posts
-
Thanks for your input. And yes, I know the issue was caused by the Enfold theme, I had already tried debugging with fallback themes where the Hivepress listing search worked just fine. Unfortunately, we had to stick with the Enfold theme as the whole website was already fully built with it and its ALB visual editor, making it impossible to switch themes just for Hivepress compatibility.
However, yesterday I took a full day to investigate the Enfold theme files, and I am happy to report that I have found the cause, and thus could fix the problem. Enfold developers might want to read on to understand and fix this potentially problematic code, as it might cause incompatibility issues with not just Hivepress but also other WordPress extensions that use their own search logic.
The file causing the Hivepress search problem is found in the Enfold theme file structure, namely
/themes/enfold/includes/helper-template-logic.php
In this file exists a function called “avia_search_query_filter”, starting around line 37. Its purpose is to “make sure that empty searches are sent to the search page as well”. Empty searches would mean standard text searches without a keyword (search term).
Unfortunately, this function does not check for custom post_types, it just addresses all searches. The URL
https://wiras.dora.group/?post_type=hp_listing&s=should definitely display the search results for the custom “Listing” post type, which is Hivepresses’ own custom post_type (since the parameter is in the URL after clicking Search), and not be treated as a standard text search.The problem is that most Hivepress searches would be considered “empty” searches as they don’t have a keyword parameter, but are searches by checkbox, select menue or radio button values (these are generated by the listings “custom fields”). Thus, the above mentioned function of the Enfold theme hijacks those searches and instead of handing them over to Hivepress, redirects them to the themes’ own “Nothing found” search result page.
All I had to do now is to comment out the whole function in the file “helper-template-logic.php”, starting from line 41 until line 66:
41 if(!function_exists(‘avia_search_query_filter’))
42 {
43 function avia_search_query_filter($query)
[…]
64 add_filter(‘pre_get_posts’, ‘avia_search_query_filter’);
65 }For now this works for us, as we don’t use a standard text search on the site anyway. We just have to be careful when updating the theme.
You might consider finetuning your function to check for “custom post types” and exclude them from the search redirecting, as it seems your current approach is a bit too general and has the potential to hijack other plugins custom search patterns.
Best regards,
SebastianHi Yigit,
thanks for your message and the copy-and-paste example on how to activate ALB for LearnDash pages.
Allow me to add the following line of code, which activates ALB on the “topics” level:$supported_post_types[] = ‘sfwd-topic’;
Strangely enough, LearnDash’s custom taxonomies for courses and lessons are plural (sfwd-lessons, sfwd-courses), whereas the taxonomy for the lowest level of content, the topics, are labelled as singular (sfwd-topic).
So if you are using LearnDash, the whole code to go into your functions.php should read like this:
function avf_alb_supported_post_types_mod( array $supported_post_types ) { $supported_post_types[] = 'sfwd-lessons'; $supported_post_types[] = 'sfwd-courses'; $supported_post_types[] = 'sfwd-topic'; return $supported_post_types; } add_filter('avf_alb_supported_post_types', 'avf_alb_supported_post_types_mod', 10, 1);Best regards,
SebastianHey Rikard,
thanks for the link and your help, this is exactly what I was hoping for.While I understand the code, it seems that your instructions on that page contain an error. To be absolutely sure:
Instead of
“Make sure to replace the word ‘post’ with your custom post type.”
shouldn’t it read:
“Make sure to replace the word ‘CUSTOM_POST_NAME’ with your custom post type.”Thanks,
Sebastian
