search on posts table by function_name

db=200MB

Now I can enter my DB with phpmyadmin but I dont know what to do

Where are search terms like “Nashira C8H”? In phpMyAdmin, navigate to your DB and the wp_postmeta table. Open the Search tab. In the meta_value field’s operator drop down, select %LIKE% (not the default LIKE). Enter a search term in the Value field, then click Go.

You should get all records with with that search term. The post_id field ties the records back to the related post records by ID. The meta_key field we’re interested in is “function_name”. If you get records with other meta_keys, you can further restrict the search by including “function_name” meta_key as another search criteria.

Does the search find all of the records that you expect? If so, the code I suggested earlier should work for you.

at the moment I’m here: https://ibb.co/X7FRY5n

OK, you’re at the wp_postmeta table. From there open the search tab (“Cerca” at the top). Continue as instructed in my last post. “Go” will of course will be the Italian UI equivalent.

I got this result: https://ibb.co/bHSG9zm

and this: https://ibb.co/7KVdfsR

If you use the code I suggested a while back and search for “Nashira” you should then get 5 results. But if you search for “Nashira C8H” you only get one result. Unlike typical search, you don’t get all posts with “Nashira” OR “C8H”. You only get a match on exactly what was entered as a search term in its entirety.

If you do require logic such as “Nashira” OR “C8H”, instead of setting “meta_value” query var, you’ll need to explode the search string and use the individual terms in a “meta_query” arg array.

That’s the theory. When I enter “Nashira” I dont get 5 results, just one: “Nashira c7x”, I dont know why. Maybe an interference with other codes? I saw I have duplication of queries

Are you getting a different main SQL in query monitor than the last one you posted? The last one did not have my code active at all.

Other code can possibly alter the query, but query monitor should reflect the final SQL actually made after all related PHP has executed.

It does happen that redundant queries are made, but there should only be one main query.

I’ll speak with the server manager. The code was to be set in functions.php? Or search.php?

I remembered myself about a thing, I renamed the label “posts” with “appartamenti” (apartments), but it’s just a label, not a different custom post type, maybe this can be the cause of code inactivity?

And what does that part of code help for?

//convert from search functionality to archive
                        $query->set('s', '');
                        $query->is_search == false;
                        $query->is_archive == true;

“function_name” was already present in the system when I decided to use it. WP has some native settings for creating custom posts, I dont know if this info can help you

I found a PHP error using Query Monitor! https://ibb.co/93pm72g

My suggested code is appropriate in functions.php or a custom plugin. Placing it in search.php would have it execute too late.

And what does that part of code help for?

Just what the comment says it does ?? The reason is because adding meta args to a normal search query means that and the search arg are logically ANDed together. For example if you searched for “Nashira” and did not unset the search args, the only matching posts would have Nashira in both (title OR excerpt OR content) AND in postmeta. You would not get posts that only had Nashira in postmeta and not elsewhere.

If that sort of logic is acceptable, you can remove those lines. OTOH, if you desire OR logic, (Nashira could occur anywhere in title, excerpt, content, or postmeta, one or more times) it’s actually rather difficult to accomplish. WP_Query isn’t setup to apply OR logic between the different constraints. OR logic is difficult, but not impossible.

“function_name” isn’t very descriptive, but it’s OK as long as you know what it’s for ??

Where is extend_admin_search() coming from? It looks like from your theme? A PHP error in “pre_get_posts” certainly could corrupt the final SQL so it doesn’t behave as expected. “Undefined variable post” is suspicious because in “pre_get_posts” no post has yet been found. There wouldn’t be anything to assign to $post in its conventional usage. It might be acceptable as an unconventional use if done correctly. But it’s incorrect now and needs to be fixed.