JoelStransky

Just one issue so far. When I submit a search without a phrase (?s=&...) I get no results. It should be that I get all posts filtered by whatever tax_query data I sent. An empty search string should not affect that.

Fantastic! This appears to work great! Well done @msaari. I tried to understand what was going on but I don’t know SQL very well so my eyes just glazed over.
Going to run some more tests but looks good so far.

Ah, I see you’ve been working in it. Thanks for the file. No errors when I run it which is nice but it doesn’t seem to be writing to the SQL correctly.
Here’s a tax_query example of what I’m doing.

Array
        (
            [relation] => AND
            [0] => Array
                (
                    [taxonomy] => document_type
                    [terms] => Array
                        (
                            [0] => 98
                        )

                    [field] => term_id
                )

            [1] => Array
                (
                    [relation] => OR
                    [0] => Array
                        (
                            [taxonomy] => document_topic
                            [terms] => Array
                                (
                                    [0] => 141
                                    [1] => 102
                                )

                            [field] => term_id
                        )

                )

        )

For those interested, this is saying: “Give me all posts that are in the document_type term id of 98 AND have document_topic’s 141 OR 102.

I have a search form with checkboxes for filters. This search returns accurate results with native search but in Relevanssi (with your new search.php), the nested query has no effect.

Thanks for your interest. I’ll attempt to explain in better detail. But first, my fix required two things.

• 1. 'field' => 'term_id' was required for each of my user-created tax queries.
• 2. I had to prevent any empty tax queries (arrays containing only a relation item) from being merged in.

Primarily, my issue is that 'field' is not a required parameter natively as it defaults to 'term_id' but Relevanssi requires it. Imho that should not be the case.

As far as what I meant earlier about “previous two”: in relevanssi/lib/search.php ~line 1021, you start to assemble a $tax_query array. Within that block there are 4 conditions.

1. Tax query is empty so remove it
2. User-created tax query, loop over and push non-relation values to $tax_query
3. Created by WP, loop over 'queries' and push to $tax_query
4. attempt to collect categories and tags into $tax_query

Conditions 2 & 3 fully assume that a 'field' param is present so when relevanssi_search() gets ahold of it, ~around line 89 there is merely a check for wether $tax_query is an array or not and if so, attempts to reference each $row‘s [‘field’] property. But the only way [‘field’] is guaranteed to exist is if the 4th condition was met. I haven’t tested condition 3 but I assume WP supplies the ‘field’ prop but there’s no guarantee a user will.

I hope that clears it up. Thanks.

imho it’s an inaccurate assumption to check if $tax_query is an array and assume it is a result of your last tax_query condition when the previous two also create arrays. But providing a field param myself should work for my needs.
Thanks.

Here’s the complete error for context. This also happens on each line expecting access to $row['field']

Notice: Undefined index: field in /var/www/html/wp-content/plugins/relevanssi/lib/search.php on line 92
Call Stack
#	Time	Memory	Function	Location
1	0.0013	366632	{main}( )	.../index.php:0
2	0.0019	366920	require( '/var/www/html/wp-blog-header.php' )	.../index.php:17
3	0.3736	4512504	wp( )	.../wp-blog-header.php:16
4	0.3736	4512552	WP->main( )	.../functions.php:955
5	0.3754	4506576	WP->query_posts( )	.../class-wp.php:735
6	0.3754	4506632	WP_Query->query( )	.../class-wp.php:617
7	0.3754	4506632	WP_Query->get_posts( )	.../class-wp-query.php:3248
8	0.3778	4541440	apply_filters_ref_array( )	.../class-wp-query.php:3007
9	0.3778	4541440	WP_Hook->apply_filters( )	.../plugin.php:244
10	0.3779	4542944	relevanssi_query( )	.../class-wp-hook.php:300
11	0.3779	4542968	relevanssi_do_query( )	.../search.php:49
12	0.3804	4544712	relevanssi_search( )	.../search.php:1322

Got hit with this today. Looking forward to a fix.

Just wanted to chime in and suggest that you nailed the fix by checking against post type.
I’m assuming you got your messages snippet from https://codex.www.ads-software.com/Function_Reference/register_post_type#Example which turns out is missing that crucial check.
The original warnings you posted about are because this code would have us attempt to assign a value to an index of a sub-array that doesn’t exist. If you look at /wp-admin/edit-form-advanced.php where $messages is defined, you’ll see that the messages for post, page and attachment are hard coded there. There is no magical creation of entries for custom post types so for their code that runs within the publicly_queryable check to assume it does is just bad code. You should request an edit to their codex as this is probably biting people left and right.