@agn_woj99 Are you desiring to include only one custom field in the search, or are you thinking that the code we’ve been talking about would only add one at a time? I’m not sure which you’re asking, but the code I’m using (which is the same as what rocio1011 posted several times) is from this page: https://adambalee.com/search-wordpress-by-custom-fields-without-a-plugin/ (Be aware that you need to make a small change described in the last comment below the post to work with newer versions of WordPress.) This code causes the regular WordPress search to include custom fields, including even custom taxonomies, which was important for me. It includes all of them, not just one.
I’m still hoping someone will come up with code that can exclude media from the search results, but that’s a different issue.
Your English is fine. (But if you want help translating, I recommend https://www.deepl.com/translator) All your comments were posted! 🙂 You can probably keep the first one and delete the rest.
The code you posted is exactly the same as what I’m using. But the search results include media items, not just posts. For example, see: https://japanharvest.org/?s=ellrick The first eight results are just images whose filename includes “ellrick”. I want to exclude media, but I don’t know how.
@rocio1011 It works for you to do what? Your code connects to a different hook than the other code snippets discussed earlier, so I’m not sure I can tell what it does or how to try it for myself. Can you explain a little more?
Yes, I know it’s not editing the database at all – I wouldn’t want it to. I just want it to find posts whose custom fields (including taxonomy terms) have a match to the search word. It does that successfully. The only thing I wish was different is that it lists not only posts but also media files, but I don’t want the media files to show up.
Judging from the way Adam Balée’s code augments the SQL query, it appears that the term names are already in the post meta table. Here are the two PHP statements in his code that modify the query (they are in separate functions, but clearly end up in the same piece of SQL):
$join .=' LEFT JOIN '.$wpdb->postmeta. ' ON '. $wpdb->posts . '.ID = ' . $wpdb->postmeta . '.post_id ';
$where = preg_replace( "/\(\s*".$wpdb->posts.".post_title\s+LIKE\s*(\'[^\']+\')\s*\)/", "(".$wpdb->posts.".post_title LIKE $1) OR (".$wpdb->postmeta.".meta_value LIKE $1)", $where );
In my case it’s not a custom post type, so that’s simpler. The code in https://adambalee.com/search-wordpress-by-custom-fields-without-a-plugin/ works, but it includes media files in the results (matching image filename or title – I’m not sure). Is there a way to restrict the results to only posts?
Even though, like ggeiger, I prefer code (cutting with a scalpel instead of a hatchet), I also tried ACF: Better Search. But it did even worse – it not only included media, but failed to even find posts that matched on a custom field I particularly care about, which happens to be structured as a taxonomy. Apparently that’s too hard for the plugin.
I’m apparently not doing it right. I added tjkelly’s final code snippet (minus the third “delete_user_meta” line, because I don’t have any custom post types code) to functions.php, saved the change, and then tried both Edit Post and Add Post. The custom fields group is still at the bottom (below the post content area where Gutenberg blocks go). I’m using WP 5.3.2 with Meks’ Voice theme, if that matters. I put the new code at the very bottom of functions.php, right before
Yes, I think I had tried to reset the conditional logic (at least, I know I went to Edit and verified that the logic was still there – I can’t remember for sure if I hit Save to refresh). I don’t think I checked for JS errors, or if I did, there weren’t any, because I would have reported them to you.
But now that I haven’t looked at that part of the site for awhile, it appears to have gotten well on its own – I have no idea why. But it was definitely failing consistently for a week or two, and it was frustrating because one field that should have been hidden is a required field, so I had to put dummy data in it to proceed.
If it happens again, I’ll check for JS errors and let you know my findings.
Okay, I finally figured this out on my own. I studied the get_field_object() function more deeply, and on this documentation page, in the “field_key vs field_name” section, there is a hint. It is not said directly, but apparently even if posts have been created that use the Field Group, if a filter causes the current query of posts (using the pre_get_posts hook) to return none of them, field_name won’t work. Even Elliot used the field_name in his tutorial, but in the case of a filter like this, you MUST use the field_key, even though it makes the code harder to read.
Ignore the first question – I gave up completely on allowing multiple selections, as it ran into too many problems and the case where we might need more than one is purely theoretical, so I decided to keep it simple for now.
But the second issue needs solving if I’m going to have these filters at all. As I said, the problem can easily be seen on the tutorial video at timecode 11:05, so it’s not something unique to my code. If anyone else has implemented such a filter, how did you deal with get_field_object() failing when the result set is empty? This looks like a bug in get_field_object() to me.
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!