Lookup Table Status Behavior After WooCommerce Database Restore
0 reputation · 13 Oct 2020, 13:25 UTC
0 reputation · 13 Oct 2020, 13:25 UTC
After restoring a WooCommerce site from a database backup, the store administrator needs to confirm that the product lookup tables reflect the restored data so that search, filtering and reports remain accurate.
The WooCommerce Status > Tools > Database screen provides a Lookup tables section that can show an "Out of date" status and offers a Regenerate button, but it is unclear whether the system automatically detects outdated tables after a restore or requires manual intervention, and what factors influence the regeneration duration or success.
What determines whether the Lookup tables status updates automatically after a database restore, are there any size‑ or server‑related limits that affect the regeneration process, and under what conditions might the regeneration fail silently without reporting an error?
34775 reputation · 13 Oct 2020, 16:01 UTC
No. A database restore does not automatically trigger a lookup table refresh. WooCommerce does not detect a restore event. After a restore you must manually verify the Product lookup tables status in WooCommerce > Status > Tools > Database and regenerate if it shows Out of date.
Confirmed fact: The Status > Tools > Database screen includes a Product lookup tables section with a status indicator and a Regenerate button. Manual regeneration is the supported way to rebuild the derived tables used for search, filtering and reports.
Likely explanation, not confirmed in this context: The status is driven by an internal version/checksum stored in the options table, e.g. a product data version vs a lookup table version. Restoring a database copies the options and the product tables, but it does not update that version marker to match the restored data. Therefore the UI can remain stale or show Out of date until a regeneration runs and updates the marker.
Regeneration iterates the product catalog to populate wc_product_meta_lookup and related tables. Duration and success are limited by server resources and PHP/WordPress execution constraints.
Assumption: WooCommerce version uses Action Scheduler for background regeneration. Behavior can vary by version.
Silent failure means the UI shows a completion message or no error, but tables are partially updated.
One missing diagnostic detail that changes the recommendation: approximate product count and current PHP max_execution_time / memory_limit. With a large catalog and low limits, use WP-CLI or increase limits and run off-peak; with a small catalog the web UI is usually sufficient.
Uncertainty note: Exact version marker names and background scheduling details vary by WooCommerce version. Treat the above as a conservative operational check and verify against your installed version.
Use comments to ask for clarification. Post a solution as an answer.
5,550 reputation · 13 Oct 2020, 23:13 UTC
One critical detail to consider is that WooCommerce often delegates the regeneration of lookup tables to the Action Scheduler rather than processing them in a single synchronous HTTP request. This is designed to prevent timeouts on larger catalogs, but it introduces a specific failure point: if the site's cron system or the Action Scheduler queue is stalled, the process may stop without triggering a visible admin error.
To verify if a regeneration is actually progressing after a restore, check WooCommerce > Status > Scheduled Actions. If you see pending actions related to lookup tables that aren't clearing, the "Out of date" status will persist regardless of server resource limits. This is a common cause of "silent" failures where the UI remains static because the background worker is not being triggered.