Some of the most useful things about a post never appear in its title or body — a company name, a region, a model number, a speaker. Those live in custom fields.
The Search Bar has a setting for matching an Advanced Custom Fields field. This page covers how it is set up and what it currently does.
For every Search Bar setting in one place, see the Search Bar guide.
Measured on Nexter Blocks 5.0.6 with ACF active: custom field search returns no results for any term. The cause has been identified and reported to the developers. Until it is fixed, do not build a search your visitors depend on around this setting. Everything below describes the setup so it is ready when the fix ships.
Before You Start
- Edition: Free. Measured with Nexter Blocks Pro deactivated, the Search Bar renders identically — form, input, dropdowns, suggestions and results all work without Pro.
- Block to enable: Search Bar, switched on under Nexter > Blocks in your WordPress dashboard.
- Advanced Custom Fields installed and active. The setting only does anything when ACF is present.
- A field with values saved on published posts. An empty field has nothing to match.
Steps
- Select your Search Bar block and open the custom field settings.
- Enter the field name exactly as ACF has it.
- Decide whether matching should be partial or a full match.
- Publish, then search for a value you know is stored in that field.
How It Behaves
What is intended, and what was measured, differ. Both are set out here so you can tell which you are looking at.
- Measured result: zero, every time. Tested with a real ACF text field carrying values on two published posts, across four terms and both match modes. Every search returned 0 results, with no error shown to the visitor.
- The cause is a database query fault, not a configuration mistake. The query that collects candidate posts is escaped twice and is rejected before it runs, so the block ends up searching an empty set of posts. Full detail has gone to the development team.
- Intended behaviour, from the same code path: the field value is split on the pipe character, and each part is compared against the term — partial match anywhere in the value, or full match against the whole value.
- The field name is ACF’s field name, the one shown in the field group editor, not its label and not its internal key.
- Custom field matching replaces the standard fields. It is not added on top of title matching.
Limitations
- The feature does not currently return results. Measured on 5.0.6. This is the limitation that matters; the rest apply once it works.
- ACF is required. Without it the setting is ignored entirely.
- Only one field at a time. There is no way to search across several custom fields.
- It is built for text fields. Relationship, repeater and other structured field types do not produce a value this comparison can use.
- It will be slow on a large site. The approach loads published posts and reads the field on each one per request, rather than querying the field directly. This has also been raised with the development team.
Troubleshooting
I set it up correctly and get no results
That is the known fault described above, not something you have done wrong. It affects every field and every term on 5.0.6.
How do I confirm it is the known fault and not my setup?
Turn the custom field setting off and search for a word in a post title. If ordinary search works and only custom field search comes back empty, you are seeing the reported issue.
What can I do in the meantime?
If the value also appears in the post title or body, search that instead with the standard field matching, which is measured working. It is not equivalent, but it is something.
Which name do I enter?
ACF’s field name, as shown in the field group editor. Not the label a visitor sees and not the internal key.
