Constants

The constants documented here can be defined in your site’s wp-config.php.

For constants related to debugging, please refer to Debugging.

Disabling Back End and JSON Searches

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.

Disabling REST API Searches

↑ Back to top

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.

Role-based Caching

↑ Back to top

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

↑ Back to top

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.

Object Limits

↑ Back to top

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 AUTO or 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.

Deferred Indexing of Variations

↑ Back to top

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 WPS_DEFER_VARIATIONS_THRESHOLD constant.

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.

Enabling [products] Shortcode Filtering

↑ Back to top

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_enable() and woocommerce_product_search_filter_shortcode_products_disable() API functions, useful for spot-enabling filtering on specific instances for example in templates.

Disabling Filtering of the Divi Shop Module

↑ Back to top

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', false );

This behavior can be modified individually for a given request context by implementing the woocommerce_product_search_filter_divi_shop filter.

Hardwired Cache Configuration

↑ Back to top

The WPS_CACHES constant is useful to set a fixed cache configuration which cannot be altered via the UI. It also makes the configuration portable, for example, if you are setting up instances for clients and want to use a standard configuration that you are used to, without having to configure it every time via the UI.

The constant must be defined as an array, where cache IDs are mapped to arrays that contain the desired configuration.

The following example enables Redis as the only active cache, using its default values connecting to localhost on port 6379:

define( 'WPS_CACHES', [
	'redis' => [ 'enabled' => true ]
] );

As no other specific parameters are indicated, this example uses the default configuration.

This next example enables Redis connecting via socket and the File Cache:

define( 'WPS_CACHES', [
	'redis' => [ 'enabled' => true, 'host' => '/tmp/redis.sock', port => 0 ],
	'file_cache' => [ 'enabled' => true ]
] );

Here also, the default configurations for each cache are applied as no other specific parameters are indicated. This example illustrates the use of Redis as the primary cache and the File Cache being used as a secondary cache, as determined by the default configuration.

The IDs of the caches that are supported by default are: redis, memcached, file_cache, object_cache and transitory. For enabled caches, they are applied by highest priority first.

The supported parameters for each of these caches are as follows:

For Redis (redis):

enabled boolean
priority integer caches with higher priority apply first, the default value for this cache is 40
host string hostname or socket, the default is localhost
port integer port number or 0 if socket is used, the default is 6379
username string
password string

For Memcached (memcached):

enabled boolean
priority integer caches with higher priority apply first, the default value for this cache is 30
host string hostname or socket, the default is localhost
port integer port number or 0 if socket is used, the default is 11211
username string
password string

For the File Cache (file_cache):

enabled boolean
priority integer caches with higher priority apply first, the default value for this cache is 20
max_files integer the maximum number of cache files, defaults to 0 for an unlimited number of files
max_size string the maximum total size of cache files in bytes, allowed suffixes are K, M, G, T and P, defaults to 0 for unlimited size
min_free_disk_space string the minimum free storage space given in bytes or as a percentage, allowed suffixes are K, M, G, T and P for bytes and % to provide a percentage, defaults to 5%
gc_interval string garbage collection interval in seconds, defaults to 30
gc_time_limit string garbage collection time limit in seconds, defaults to 0 for no time limit

For the Object Cache (object_cache):

enabled boolean
priority integer caches with the higher priority apply first, the default value for this cache is 10

For the Transitory Cache (transitory):

enabled boolean
priority integer caches with higher priority apply first, the default value for this cache is 100
max_count integer maximum number of cache entries
max_extent string maximum extent of cache entries
max_magnitude string maximum magnitude for cache entries
min_memory string minimum free memory in bytes or as percentage

The Transitory Cache should always be enabled and its configuration values should not be altered. It is not recommended to change the configuration for the Transitory Cache. It is not necessary to enable the Transitory Cache explicitly when providing a hardwired configuration, as it is automatically enabled by default.