Bug: warning message, uninitialized object in search.php

That’s not a good solution for this problem. A better solution is to move the if (isset( $missing_terms[ $doc ] ) ) { block inside the if ( ! is_wp_error( $post_object ) ) { block.

You’re seeing this error message because you have a search result that is a WP_Error object, and creating an empty object there is just masking the actual problem. It would be best to figure out why there’s an WP_Error instead of a post object in your search results.

Thanks for looking into this so quickly. I agree, that the solution was just a quick workaround to get rid of the warning message on our end.

I looked at the error handling a few lines above in the code, and yes, moving the if (isset( $missing_terms[ $doc ] ) ) { block inside if ( ! is_wp_error( $post_object ) ) { is the better fix. If you could add it to the next release it would be great.

Regarding the WP_Error instead of post object, you were correct. Here’s the dump of the error object:

WP_Error Object ( [errors] => Array ( [post_not_found] => Array ( [0] => The requested post does not exist. ) ) [error_data] => Array ( ) [additional_data:protected] => Array ( ) ) 1

Then I checked the $post_object which was an ID, but no post with such ID existed in the DB. (Actually the ID was way too high based on how many posts and terms there are in the DB and what max/next IDs are currently in the posts table, but I didn’t dig too deep so I could have missed what ID is expected here)

At this point I suspected something to be off with the search index. And indeed reindexing did fix the issue and the warning is gone now.

I guess as a precaution it’s good to have the error handling changed as you suggested to avoid showing the warning message to visitors, but the real fix is more complex as it’s likely caused by deleting already indexed post(s) from the database. Happy to share additional debug info if it helps! Let me know! Again, thanks for looking into it!

The particulars of the case are not very interesting; it may well be hard to replicate. I know that kind of thing sometimes happens, hence the WP_Error check at that point.

I’ll include this fix in the next version of the plugin. Thanks!