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
↑ Back to topThe 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 topThe 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 topIntroduced 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 topGroup-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 topAs 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 topThe 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 topBy 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 topThe 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 topThe 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
booleanpriority
integer caches with higher priority apply first, the default value for this cache is40
host
string hostname or socket, the default islocalhost
port
integer port number or 0 if socket is used, the default is6379
username
stringpassword
string
For Memcached (memcached
):
enabled
booleanpriority
integer caches with higher priority apply first, the default value for this cache is30
host
string hostname or socket, the default islocalhost
port
integer port number or 0 if socket is used, the default is11211
username
stringpassword
string
For the File Cache (file_cache
):
enabled
booleanpriority
integer caches with higher priority apply first, the default value for this cache is20
max_files
integer the maximum number of cache files, defaults to0
for an unlimited number of filesmax_size
string the maximum total size of cache files in bytes, allowed suffixes are K, M, G, T and P, defaults to0
for unlimited sizemin_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 to5%
gc_interval
string garbage collection interval in seconds, defaults to30
gc_time_limit
string garbage collection time limit in seconds, defaults to0
for no time limit
For the Object Cache (object_cache
):
enabled
booleanpriority
integer caches with the higher priority apply first, the default value for this cache is10
For the Transitory Cache (transitory
):
enabled
booleanpriority
integer caches with higher priority apply first, the default value for this cache is100
max_count
integer maximum number of cache entriesmax_extent
string maximum extent of cache entriesmax_magnitude
string maximum magnitude for cache entriesmin_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.