The constants documented here can be defined in your site’s
For constants related to debugging, please refer to Debugging.
The General settings provide options to power back end and JSON product searches. The settings can be overridden by setting the following constant:
define( 'WPS_EXT_PDS', false );
While the constant is set to
false, the extension will not power back end or JSON product searches and the corresponding options are disabled.
The General settings provide the option to power REST API product searches. The option can be overridden by setting the following constant:
define( 'WPS_EXT_REST', false );
While the constant is set to
false, the extension will not power product searches via the REST API and the corresponding options are disabled.
Introduced in version 3, role-based caching improves performance as role-sensitive content can be cached. This can be disabled by setting the following constant:
define( 'WPS_ROLES_CACHE', false );
When this constant is set to false, role-based caching is disabled. This can be used to benchmark performance with and without role-based caching and also verify whether a specific caching system is effectively having an impact for visitors who are logged in.
Group-based caching requires the Groups membership and access control plugin, support is introduced in version 3.
Enabled by default, it improves performance as group-sensitive content can be cached. For example, access to certain products could be restricted to members of specific groups, such as when a store caters to distributors and the general public.
This can be disabled by setting the following constant:
define( 'WPS_GROUPS_CACHE', false );
When the constant is set to false, group-based caching is disabled. As with the related constant for roles, this can be used to benchmark performance with and without group-based caching and also verify whether a specific caching system is effectively having an impact for members who are logged in.
As of version 3, the search engine introduces constants that allow to limit the number of objects it will take into account during request processing. This can have a positive effect on shops with large sets of products or variations.
The following constants can be used to fine-tune or disable object limits:
WPS_OBJECT_LIMIT controls whether fixed or adaptive object limits are used. The constant can be set to a specific integer value to limit the number of objects, it can be set to
0 (zero) to disable object limits so that potentially unlimited numbers of objects could be processed (at the risk of exceeding available processing resources), it can be set to
AUTO for adaptive limits (which are used by default) and
AUTOREPORT for adapative limits and where the system will log the adaptive limit used (this should only be used during tests).
WS_OBJECT_LIMIT_FACTOR is used to modify the adaptive limits with
WPS_OBJECT_LIMIT set to
AUTOREPORT. Its default value is
4, higher values can be used to reduce the number of objects that will be processed during a request. Lower values than the default are not recommended.
As an example, these values could be used during debugging:
define( 'WPS_OBJECT_LIMIT', 'AUTOREPORT' ); define( 'WPS_OBJECT_LIMIT_FACTOR', 5 );
The obtained effective object limit is shown in the site’s debug.log when requests are processed.
The search engine’s indexer will immediately re-index products when changes to them are saved. With variable products, it will also re-index all of its variations. Deferred indexing of a variable product’s variations will occur when the number of variations exceed a certain limit. This is very convenient, as it avoids prolonged waits when editing a variable product. The limit to the number of variations that are processed immediately can be set by using the
The default value of this constant is 3, meaning that when you update a variable product, it will re-index up to 3 of its variations and defer indexing of the remaining variations to the next eligible indexer run. If this constant is set to 0, none of a variable product’s variations will be index upon saving changes, but all will be re-indexed on the next eligible indexer run, this will help to reduce the wait to a minimum when so desired. Higher values will try to re-index as many variations when a product is updated, respecting the PHP resource limits of available time and memory.
So if you set this to a very high value, for example 100, and you have variable products with more than 100 variations, take into account that the limit established is potential and depends on the available PHP memory and execution time limits.
To defer all indexing of variations to indexer processing in the background:
define( 'WPS_DEFER_VARIATIONS_THRESHOLD', 0 );
To process up to 10 variations when you edit and update a variable product and leave the rest for deferred background processing:
define( 'WPS_DEFER_VARIATIONS_THRESHOLD', 10 );
Our recommendation is to leave the value of the constant at its default so as to ensure an acceptable trade-off between working on products and having them indexed through the indexer when it runs in the background.
It is important to note that the indexer should be enabled at all times, to make sure that variations that are pending indexing will be taken care of. Also note that due to the deferred processing, some results pertaining to variations not indexed will only be included by the search engine after they have been processed.
By default, the search engine will not filter the results of instances of the WooCommerce standard [products] shortcode. To enable filtering for all instances of the shortcode, this constant can be defined:
define( 'WPS_SHORTCODES_PRODUCTS_FILTER', true );
This will apply to all instances of the shortcode. Alternatively, the
woocommerce_product_search_filter_shortcode_products filter can be used to enable it in certain conditions. Filtering of the
[products] shortcode can also be enabled or disabled using the
woocommerce_product_search_filter_shortcode_products_disable() API functions, useful for spot-enabling filtering on specific instances for example in templates.
The search engine will filter all instances of the Divi Shop module by default. This can be disabled by defining the following constant:
define( 'WPS_DIVI_SHOP_FILTER', true );
This behavior can be modified individually for a given request context by implementing the