⚠️ VIP Search is in limited beta
This documentation is subject to change. Features described here may not be available, may not be fully functional, or may change without notice, prior to general availability.
VIP Search can be enabled via code.
By default, VIP Search will not index every post type, taxonomy, or meta. You will need to identify and create “allow lists” for the custom post types, taxonomy, and post meta that should be indexed and made available for search.
Index only what is necessary for searches
So what is needed to ensure the right things are indexed, but only the right things? Should we gather up all possible meta keys and post types and add them all to an allow list?
Why only index what is necessary?
Generally, indexing content that will not be used in searches, or post types that should not be searched, will be wasteful:
- additional time will be spent during modification events indexing the items
- if there are many of these items, versioning an index will take longer
- the items will occupy space in the index
- Possibly, search results will be polluted by content that wasn’t meant to be included
For example, there’s no need to reindex a post just because a particular post meta changed, if you’re not using that meta for searches. If you have a post meta for a custom post type that is only used to display information to users, that would not be something ever searched on, and your WordPress code can obtain and display it with standard post meta functions.
How the indexing decisions are made during code execution
The only taxonomy or meta that actually needs to be indexed in Elasticsearch, are those that are used as criteria in actual queries or searches, either in a WHERE clause or used for sorting. Those can be identified with allow lists, which in ES are lists of which slugs should be indexed.
As posts, post meta, and post taxonomies are updated, the VIP Search code checks allow lists to determine which of these should be indexed. The post meta and taxonomies are configurable on a post by post basis. All we need to do is to ensure the appropriate items are in the allow lists.
Your codebase is the foundation from which we can review and discover what needs to be enabled for indexing to support this search use case.
Conduct an audit in code
A good starting approach would be to make an audit of any custom queries, or query modifications, in use. Identify in those queries the post type(s) and then the taxonomies and post meta that may be involved. In each of the more detailed How Tos that follow, we’ll demonstrate, with sample code, an approach that should help you pinpoint the desired indexing and also identify the queries so they can be explicitly tested after adding the necessary configurations.
Let’s say your site has a list of events. To manage this, you’ve created a custom post type of
event, given these posts some standard meta such as
event_location and others, and an event
format taxonomy that includes
in_person event formats.
You’ve got a custom user interface to handle updating this content, and a custom, filterable, event search page which allows a user to find the in person events for a week when they’ll be in a particular city.
Depending on how you’ve organized your code, you may approach these allow lists in different ways. There are two basic approaches, either is appropriate:
You’ve got one file specifically for search, as a must-use plugin, which defines each allow list. Whenever you make adjustments to search configurations, you do it here.
You’ve separated each feature, so all the code associated with events is in one directory, set of classes, or perhaps in a plugin. When you need to define indexing for the events, you do that in the code associated with the feature, where you’re already declaring the
register_taxonomy for these.
In our examples, we show one or the other method depending on the context. The right method for you will depend on how you’re already organizing your code.