Search in post type field broken/not accurate

[zaewin]

Bug summary

When you have added the post type file in a block and want to search for a post you probably won't get the result you want if you have a lot of posts with a lot of content.

Steps to reproduce

1. Have a lot of posts with a lot of content
2. Search for a post in the post field.
3. If the keyword exists in multiple posts you probably won't get the right result.

Expected behavior

The search should only look in post titles for accuracy. Or atleast prioritise posts with matching keyword + title.

Actual behavior

The search looks in all content. If the keyword exists in the content of several posts, the one you want with the keyword in the title won't show up. In my example I wanted the post title "Lesjöfors". It does not show up. The posts that do show up have "Lesjöfors" in their content. These should be low priority compared to the one with the keyword in the title.

Versions

• WordPress version: 5.4
• Block Lab version: 1.5.4
• OS: Ubuntu 19
• Browser: Chrome

[kienstra]

Hi @zaewin,
Good point, I also see this issue.

Something similar has been raised in #430.

[zaewin]

Ah, great! I didn't realize there was another thread. But yeah, that issue describes exactly what I'm experiencing here. As long as this issue exists, the only way to link to posts using this field is to do it it in the DB which isn't optimal.

[kienstra]

Yeah, it's hard to tell that issue is similar, but under the hood it's the same problem.

[eriktdesign]

I'm also experiencing this issue, and it's causing problems with client sites.

In our case, it's being used to select Woocommerce products to display in a block. Only the five most recent posts are displayed in the dropdown, no matter what I type into the search box.

I can enter the code editor view in the Block Editor and manually update the JSON to select the products -- doing so allows them to appear in the render, but they still aren't selectable from the input.

[kienstra]

Hi @eriktdesign,
Thanks for letting me know.

We'll probably fix this at some point, and a PR will probably reference #430.

[kienstra]

Closing, as this is a duplicate of #430. It's still a valid issue, though.