| 开发者 | madrasthemes |
|---|---|
| 更新时间 | 2026年9月26日 11:10 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.1 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
posts and postmeta at request time, which is what keeps a large catalogue fast.[maswcas_search]), and a classic widget.[maswcas_search] shortcode, or the widget) wherever you want it.Yes, completely. The hosted subscription adds typo tolerance, synonyms and faceting, which plain MySQL cannot do. Nothing that MySQL can do is held back to sell you an upgrade.
No. This is product search. The index holds products and variations and nothing else, and the takeover of the search results page applies only to product searches. Searches for posts and pages go to WordPress's own search exactly as before, so a general-purpose search plugin can run alongside this one without either fighting the other. Nothing inside a PDF, .docx or .xlsx is read or searched, wherever the file is stored.
Title, short description and description, SKU, and the names of categories, brands, tags and attributes, each with its own weight slider. Price, stock status and visibility are indexed too, but to filter and order results rather than to match what a shopper typed. The field list is fixed, and no filter adds an arbitrary meta key to a document. Two lists are extendable, because stores legitimately keep that data elsewhere: maswcas_brand_taxonomies (the taxonomies treated as brands, WooCommerce's own product_brand by default) and maswcas_attribute_facet_taxonomies (the attribute taxonomies indexed for search and facets).
No. Product, variation, stock and taxonomy changes are picked up automatically through background jobs (Action Scheduler, which WooCommerce already provides). The Rebuild index button under Settings → Search index is there for the initial build and for after a large import.
Searches read one dedicated, FULLTEXT-indexed table and never join posts/postmeta, so search cost does not grow with your catalogue the way the default search does. Indexing always happens in background jobs, never inside a product save.
The analytics table stores a search term, a day, and counters. There is no ID, no IP, no session, and no timestamp finer than the day, so it cannot answer "who searched for this". Terms that look like an email address, a credit card number (Luhn-checked) or a credential are dropped entirely rather than recorded. Conversion measurement, which is the one part that stores anything in a shopper's browser, is off by default and additionally requires WooCommerce's own tracking consent. Settings → Privacy → Policy Guide carries suggested policy text for the parts you do enable.
Yes. It is a template part (product-search-dropdown) built from blocks, editable in the Site Editor on a block theme, or overridable from a theme file. If you already override templates/search-dropdown.php, your override keeps working.
Your local MySQL index stays the canonical copy and stays warm, so search falls back to it automatically. A hosted outage costs typo tolerance, not search.
Yes, per site. Each site in a network gets its own index table, its own settings and its own analytics; nothing is shared across the network and there is no network-wide settings screen. Network activation activates the plugin normally, and only skips the one-time setup redirect, which would otherwise hijack the screen reporting what happened to every site. On each site, open Settings → Search index and use Rebuild if the index has not built.
Yes. The plugin declares compatibility and reads orders only through WooCommerce's own CRUD.