Bug, fails if menu_order is set in query

Hi @ov3rfly,

Thank you for your message.

I have to admit that I haven’t encountered such a problem yet, even though I’ve used pre_get_posts many times. Your idea for change is very good.

I have released an update that introduces your change. Thank you very much for the suggestion!

I see you added spaces in front and after the $where now.

Only the one space in front is required in my suggestion.

The real problem seems to be the surrounding spaces of the statement before the $where though, this part:

AND wp_posts.menu_order = 123

There are two in front and none after, while there should be one in front and one after.

I did not find where this statement before the $where is added in your code or by WP to do a real fix, so I only did the above described workaround.

I added before and after for sure. An extra space will not hurt.

Your idea was the best solution, that is why I added it.

Is everything working now? Can I still help?

I prefer to really fix bugs instead of adding only workarounds, that’s why I tried to explain the bug in detail. Maybe one day you can find the real bug.

It works now. The extra space after is not necessary.

Thanks for quick response.

@ov3rfly, why do you think this is a workaround? We have a problem because there is no space between one part of the query and the other. Thank you for explaining this problem to me.

I also used the pre_get_posts hook and added the same argument as you – everything works. I assume that since 10,000 people have also not reported this problem, it is not strictly in my plugin, but in something else.
?
I can’t analyze your entire site to find a problem. This update is not a temporary fix that may break anything. I added extra spaces – even two side-by-side spaces in an SQL query do not cause any problem.

Remember that a website is a combination of WordPress, often many plugins, a theme and your code. Any of these items can cause problems. Do you think I should thoroughly analyze every website whose author has a problem?

I try to make the plugin have no errors and work as well as possible and be resistant to irregularities in other codes. Hence the addition of extra spaces.

No need to analyze an entire site.

Bug can be reproduced with default ACF/ACF Pro, ACF Better Search 3.4.1, Twenty Seventeen, no other code besides

function my_pre_get_posts( $query ) {
	if ( !is_admin() && $query->is_search ) {
		$query->set( 'menu_order', 123 );
	}
}
add_action( 'pre_get_posts', 'my_pre_get_posts' );

Have sent you a sandbox login and detailed description via email found at your website.

• This reply was modified 5 years, 5 months ago by Ov3rfly.

Problem has been solved. This does not occur in my environment.

If you have time for analysis, do it. Thank you for reporting problems and best regards!

Problem does occur 100% reproducable with 3.4.1, you can see it with one click in provided sandbox login.

Problem is not visible any more with 3.4.2 because of various added extra spaces in posts_join (not necessary) and posts_search (not mentioned in changelog).

What was the reason to change posts_search filter priority from 10 to 0 (not mentioned in changelog)?

I think the problem is solved. Everything works for you, and extra spaces do not have a negative impact on the operation of the page.

I changed the priority because I had planned it for some time. This ensures that the search appliance will always start first. It also doesn’t change anything for you.

It doesn’t include things in the changelog that don’t change the way the plugin works, because there would be so many changes.

I changed the priority … It also doesn’t change anything for you.

How do you know? There are various plugins which also use ‘posts_search’, so I would guess a fundamental change like priority to 0 would at least be mentioned in changelog so people will find valuable hints if things start to break.

OK, I added this information in readme.txt file.