DISABLE_WP_CRONis used or not. On low traffic sites, staging sites or sites that are running on localhost (your own computer), scheduled tasks (cron) are only triggered sporadically and in some cases not at all. Consider enabling scheduled tasks at the system level – see Hooking WP-Cron Into the System Task Scheduler on how to achieve this. If you are using Docker, this article has indications on how to trigger WordPress cron every minute. Or simply trigger the indexer manually by clicking the Run button. Access to your site is protected by password on the server level and scheduled tasks (cron) fail to execute due to lack of permission when the server receives the
wp-cronrequest. Remove the password protection during tests or trigger cron events manually using the Run button. Increase the PHP memory limit as indicated in the article Increasing the WordPress Memory Limit. Errors in third-party plugins, themes or customizations cause issues during processing and thus the indexer cannot successfully process the entries. Disable plugins that are up-to-date but create issues. Update plugins that have not been updated in a while. Fix errors in customizations. Switch to a theme that is error-free. Plugins, themes and customizations should not produce any entries in the debug log. If they do, consider alternatives or fixing them. Please check the next question on how to enable debugging and review the debug log entries produced for errors. When you have variable products with many variations, the indexer will need additional time to index each variation. This is correct as it will take all characteristics of each product variation into account. The time required to process the variable product and all its variations is proportional to the number of variations of the product. Although the engine will try to avoid errors related to excessive usage of resources, on some setups with low limits and depending on the overall resource consumption of your server, you may see a “PHP Fatal error: Maximum execution time of … seconds exceeded”. Even if this occurs, the indexer will eventually index all variations in due time during successive indexing runs. To avoid such errors at all, you can also increase the PHP max_execution_time. In your site’s
wp-config.php(this file is located in the root folder of your site) enable WordPress debugging and specific debugging for the extension by adding these lines:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); define( 'WPS_DEBUG', true );This will log any PHP notices, warnings and errors to the log file along with information about activities and events related to the search engine. The log file typically resides in
wp-content/debug.log. For additional debugging options, please refer to this extension’s Debugging section of the API documentation. Issues are often caused by incompatible themes, conflicting plugins, incompatible customizations or even syntax errors in source files (the latter are most often found in badly coded templates or customizations). To find out what exactly is causing issues that stop the search engine and its features from working, please read the section How to Test for Plugin and Theme Conflicts where steps to discover the causes of conflicts are detailed. Experience has shown that generic optimization plugins rather break sites instead of optimizing them. Such plugins interfere with appropriate functionality and can cause a variety of issues. They can cause failure to load needed resources or even go as far as to modify or delete essential parts of the database.
We recommend to avoid using the following and similar plugins, as they can cause loss of functionality and loss of data:
- Avoid: Autoptimize
- Avoid: Plugin Organizer
- Avoid: WP Optimize
It is strongly recommended to avoid any kind of optimizations or modifications regarding database tables and database entries created by the system and any of the official add-ons.
Modifying the database either manually or through any third-party optimization-oriented plugin can break the database, resulting in unexpected behavior for your site, including plugin malfunction and loss of data.Database optimizations belong to the realm of expert database administrators who know what they are doing. Please note that any modifications to your database are the sole responsibility of your site’s administrators and the utmost care must be observed in taking any modifications to production.
Plugin – JetpackIf Jetpack Search is enabled, it can override the search results produced for products. To avoid this, disable the search functionality in Jetpack to assure that it does not modify the results produced by the extension’s search engine: Go to Jetpack > Dashboard > Performance and make sure that the option Jetpack Search is disabled.
Plugin – Post Types OrderThis plugin provides an option which modifies the order of the search results produced by the Product Search Field widget and equivalent shortcode [woocommerce_product_search]. It also affects the results produced when the automatic search field replacement is active. To avoid this plugin modifying the order of the search results, disable the plugin or disable the option: Disable the option Admin Sort which is found under Settings > Post Types Order. When you use live filters and the product images of the results are missing, then this is most likely due to a lazy loading implementation that is not compatible. Most lazy loading is coded in a way that is incompatible with image elements that are added dynamically on a page, and thus they fail to pull in the images after the live filter has found its matches. The recommended solution when this happens is to simply disable lazy loading of images. Where live filters are used, lazy loading provides no advantage as the products and their images are already loaded dynamically, according to the visitors choices. For those implementations of lazy loading that are actually compatible with dynamically built pages, there should be no issues though. As of version 2.10.0, the search engine extension provides an API action that allows plugins and themes to be compatible with its live filters to selectively disable lazy loading. Plugins and themes that wish to be compatible, should listen to the
woocommerce_product_search_signal_filter_responseaction and disable their lazy loading features during the request when this action is invoked. Lazy Loading for images provided via Jetpack is fully compatible with WooCommerce Product Search as of version 2.10.0. If you are using a previous version, please update. Jetpack’s lazy loading for images can be turned on or off under Jetpack > Settings > Performance & speed using the option Enable lazy-loading for images. This theme provides a lazy loading option which should be disabled. Under Theme Options > Advanced > Performance, disable the option Images lazy loading. In some cases it might be necessary to turn off accurate optimization when live filters are used. You will recognize that when you see strange characters in your product titles or descriptions after a live filter has been applied. Also when the output is corrupted (odd formatting), this might also be related to accurate optimization. To solve this, go to WooCommerce > Settings > Search > General and disable the option “Use accurate optimization”. Save and try to apply a live filter. If there are further problems with the output, also disable the option “Optimize responses for filter requests”. Further details on these options are on the General settings documentation page. The live attribute filters from the Product Filter – Attributes widget, the
[woocommerce_product_filter_attribute]shortcode or the
woocommerce_product_filter_attribute()function will produce links to product attribute archives when the style used is List or Inline. When you try to visit these links and do not get the expected results, i.e. an archive page showing products that have the desired attribute, then you must enable archives for the product attribute in question. To enable archives for a product attribute, go to Products > Attributes, edit the desired attribute and check the option Enable archives? – then go to Settings > Permalinks and click the Save Changes button. It is important that the template used to display products (shop page template, product archive template) applies the appropriate CSS classes to the containers:
- The container of the products shown on a shop page or product archive must have the
.productsCSS class applied. An alternative class can be specified using widget settings or parameters passed to the shortcode or API function, but we recommend to use the default class for consistency.
- The container for individual products displayed on the shop page or a product archive must have the
.productCSS class applied. As with the above, there are settings that allow to specify an alternative although we also recommend to use the default again.
- Could not find the general Products Container, expected the selector .products
- Could not find the individual Product Container, expected the selector .product
[woocommerce_product_filter]shortcode together with our live filter Widgets or Shortcodes, the widget’s option Update the Address Bar must be enabled / the shortcode’s
update_address_barattribute must be left at its default or set to
"yes". As of version 3 of the extension, it is likely that you do not need to disable object caching. If you have not yet updated the extension to version 3 or later, we recommend to update it on your staging site first, allow the search engine to rebuild its index and then enable object caching. Once you have done that, proceed to test your staging site with several searches and combinations of filters. If everything works fine, you can leave object caching enabled and deploy to your production site. If you have object caching enabled and update the extension, please note that the notice to update the database may still appear for a while even though the database has already been updated. If you have already clicked the Update button, you do not need to click it again. The notice will go away once WP Engine’s object cache has been updated. If you still see inconsistent results when you apply filters and your site is hosted on WP Engine, you might need to disable object caching or ask WP Engine support to disable caching for specific pages. For example, if you observe inconsistent results on a page where you are using the extension’s shortcodes, widgets or API functions, you can ask to have that specific page be excluded from caching while you can still take advantage of the performance benefits that object caching provides for the rest of your site. Go to the Utilities section of your WP Engine dashboard, scroll down to Cache options and under Object caching click Disable and then click Save. Now click Clear cache under Clear page cache. It can take a few minutes for the changes to take effect, also make sure to clear your browser’s cache. If your site’s error log or
debug.logshows entries with errors, warnings or notices related to
KILLED QUERY, add this to your site’s
define( 'WPE_GOVERNOR', false );This will prevent WP Engine restrictions to produce incorrect or no search results. If you are using the SG Optimizer plugin, there might be issues in some cases with inconsistent results when filters are used due to incompatible caching. To circumvent the issue, you can exclude the relevant pages from caching using the option Exclude URLs. Add the URLs of relevant pages there, for example the shop page if live filters are used. You might also need to disable SG Optimizer‘s Memcached option so that it does not conflict with the live filter results, although the need to do so might be reduced as of version 3 of the extension: A further setting which should also be disabled is found under SG Optimizer‘s Frontend Optimization settings as it can also conflict with live filters. Disable the option to remove query strings from static resources: In order for live filters to be able to function properly with W3TC’s object caching enabled, the cache group related to widgets should specifically be left out of the caching. This is done by adding widget under Performance > Object Cache > Non-persistent groups: As this is not particularly related to the search engine’s filters, adjusting this is even useful when you have other widgets whose content changes according to the context. All CSS styles and JS scripts used by the WooCommerce Product Search search engine are already minified and can be safely excluded in order to keep the live filters working. Under Performance > General Settings, go to the Minify section and choose Manual mode: Then go to Performance > Minify and under Advanced section add the following entries in Never minify the following JS files:
wp-content/plugins/woocommerce-product-search/js/selectize/selectize.min.js wp-content/plugins/woocommerce-product-search/js/jquery.ix.typewatch.min.js wp-content/plugins/woocommerce-product-search/js/price-slider.min.js wp-content/plugins/woocommerce-product-search/js/product-filter.min.js wp-content/plugins/woocommerce-product-search/js/product-search.min.js wp-content/plugins/woocommerce-product-search/js/selectize.ix.min.jsAlso add the following entries under Never minify the following CSS files:
wp-content/plugins/woocommerce-product-search/css/selectize/selectize.min.css wp-content/plugins/woocommerce-product-search/css/price-slider.min.css wp-content/plugins/woocommerce-product-search/css/product-search.min.css wp-content/plugins/woocommerce-product-search/css/storefront.min.cssThe entries assume the standard plugin directory structure is used:
wp-content/plugins. If you are using customized plugin folders, adjust the paths accordingly. When you use the Product Filter – Search widget make sure that the option Update the Address Bar is enabled. When you use the
[woocommerce_product_filter]shortcode, do not specify the
update_address_barattribute or set it to
"yes". Yes. Here is a template of a custom shop page built with shortcodes and Elementor: WooCommerce Product Search Elementor Shop Example Download and unzip the file. To use the template, go to Pages > Add New > Edit with Elementor > Add Template … Then click the icon to import a template and choose the extracted file
WooCommerce-Product-Search-Elementor-Shop-Example.json… Finally insert the template … Now you have a fully customizable page built with the extension’s shortcodes, including live search and filters. Yes. If the information is related to products using related taxonomies or standard product data such as its title, ID, SKU or short description:
- If the information is related to the products in the form of product categories, product attributes or tags, the search engine will automatically index the related information and find the products. In this case, you do not need to do anything in particular.
- Any additional data from custom fields can also be indexed, so that products can be found by arbitrary criteria stored for example as postmeta. We provide examples of how this is done here. Please note that this requires some basic knowledge of how WordPress filters are used, as the system provides the
woocommerce_product_search_indexer_filter_contentfilter hook for this purpose. A qualified developer can easily help you to fine-tune the system based on the examples we provide.
woocommerce_product_search_compat_woocommerce_product_vendors_indexfilters allow to disable indexing of brands or vendors related to products. Only use global product attributes to relate products to their features. The search engine and its filters fully support features that are related to products using global product attributes, the system does not support the use of custom product attributes. We strongly recommend to only use global product attributes as the proper method to relate any product to its attributes, including those that are used on a single instance of a product. To learn more about how to create and use global product attributes, please refer to this section on Product Attributes. As of version 3, the search engine supports caching based on WordPress roles and group memberships with Groups. Previously, it was often necessary to disable object caching or caching for users who are logged in, because the systems involved were not able to discern between content that can be served to any visitor, versus content that is visible to privileged groups of users only. In those cases, we can now expect cached content to be served correctly, as the search engine supports role and group-based caching. This implies that in your caching system, you might now be able to enable options for object-caching or caching for users who are logged in. Why and when this matters? It matters where you have products which must not be visible to everyone and access to them is restricted by role or group. If role or group-based caching were not supported, you would not be able to use caching, with the implication of slower responses while visitors browse your shop. Whether your system may take advantage of this depends on the individual components used, specifically what caching system and whether it ties in with the extension’s related feature. We would certainly recommend to try things out on a staging or development site to make sure that with object caching or caching for logged in users things still work as expected. The overall benefit for your site’s performance can be substantial. If the Product Search Field returns products in the default language only: Make sure that the Polylang Pro and Polylang for WooCommerce plugins are installed and activated. Ensure that you have added a translation for the product in question. If the product you search for does not appear in the results, edit it and add the missing translations in the Languages box. If the search results page lacks the translated language slug and the search page is not translated: For example, when you reach the search results page after hitting enter in the Product Search Field or the Product Filter – Search field, and you are redirected to the search results page of the default language instead of the translated language. In that case, make sure that all products on your site are appropriately translated and that there is a translation of the search results page for every enabled language. Have a question before you buy? Please fill out this pre-sales form. Already purchased and need some assistance? Get in touch with the developer via the Help Desk.