When a Dynamic Tag or widget setting must point at one specific record out of many — \"this product\", \"that landing page\", \"this author\" — you need a searchable picker. On a small set a preloaded SELECT2 is fine. On a 20k-product store it is a trap: Elementor renders every option into the panel on load and the editor hangs. This skill is the AJAX-search alternative and how to degrade it when Elementor Pro is absent.
\n\n\"I'll list the products in a
\nSELECT2so the user can search them.\"
// ANTI-PATTERN at scale — every product becomes a preloaded <option>\n$options = [];\nforeach ( wc_get_products( [ 'limit' => -1 ] ) as $p ) {\n $options[ $p->get_id() ] = $p->get_name(); // <-- 20k entries in the panel\n}\n$this->add_control( 'product_id', [\n 'type' => \\Elementor\\Controls_Manager::SELECT2,\n 'options' => $options,\n] );\nA preloaded SELECT2 ships all options to the editor up front. That is exactly what the reference plugin's ProductAttributes tag does — but only because attribute taxonomies are a handful (ProductAttributes.php:62-74). The same shape over products/posts is what locks the panel. Preloaded SELECT2 is correct only for small, bounded option sets (a dozen statuses, a few taxonomies).
The query control is a SELECT2 whose options are fetched on demand, by search term, over AJAX. Catalog size is irrelevant because nothing is queried until the user types.
use ElementorPro\\Modules\\QueryControl\\Module as QueryControlModule;\n\n$this->add_control( 'product_id', [\n 'label' => esc_html__( 'Product', 'myplugin' ),\n 'type' => QueryControlModule::QUERY_CONTROL_ID, // 'query'\n 'options' => [], // empty — filled by AJAX\n 'label_block' => true,\n 'autocomplete' => [\n 'object' => QueryControlModule::QUERY_OBJECT_POST, // what to search\n 'query' => [ 'post_type' => 'product' ], // scope (search term is added server-side)\n 'display' => 'minimal', // or 'detailed'\n ],\n] );\nVerified contract:
\nQUERY_CONTROL_ID = 'query'; the control class Query extends Control_Select2 (controls/query.php:12-16).'autocomplete'['object'] is one of (module.php:34-39): QUERY_OBJECT_POST ('post'), QUERY_OBJECT_TAX ('tax'), QUERY_OBJECT_AUTHOR ('author' — users who authored content), QUERY_OBJECT_USER ('user' — all users), QUERY_OBJECT_ATTACHMENT ('attachment'), QUERY_OBJECT_LIBRARY_TEMPLATE.'query' is merged into the WP query scope; 'display' is 'minimal' or 'detailed'; 'by_field' => 'ID' stores the chosen post ID.elementor/ajax/register_actions (pro_panel_posts_control_filter_autocomplete, query_control_value_titles). Your code writes no wp_ajax_ handler; you only declare the autocomplete config and Pro does the search and the saved-value label resolution.The autocomplete handler returns early with a WP_Error when the search term is empty (module.php:211) — so nothing runs until the user types. When they do, autocomplete_query_for_post() sets $query['s'] = $data['q'] (module.php:242); the 'posts_per_page' => -1 alongside it (module.php:241) is harmless because the s search term bounds the result set. This is the inverse of the preloaded SELECT2: the query is small and on-demand, not large and upfront.
The query control works in a Tag/Data_Tag exactly as in a widget — store the chosen ID in a setting and resolve it in render() / get_value(). Pro's Internal_URL data tag is the canonical example: a type selector plus per-type query controls (post_id, taxonomy_id, attachment_id, author_id), each with its own autocomplete['object'] and a condition (internal-url.php:72-142):
$this->add_control( 'post_id', [\n 'label' => esc_html__( 'Search & Select', 'myplugin' ),\n 'type' => QueryModule::QUERY_CONTROL_ID,\n 'options' => [],\n 'label_block' => true,\n 'autocomplete' => [\n 'object' => QueryModule::QUERY_OBJECT_POST,\n 'display' => 'detailed',\n 'query' => [ 'post_type' => 'any' ],\n ],\n 'condition' => [ 'type' => 'post' ],\n] );\n\n// …then resolve in get_value()/render():\n$url = get_permalink( (int) $this->get_settings( 'post_id' ) );\nNote: in the bundled reference plugin, no dynamic tag uses the AJAX query control — every SELECT2 tag (ProductAttributes, membership-plan tags) preloads a small, bounded set. The AJAX pattern there lives in the DynamicAddToCartWidget. For a tag, Pro's Internal_URL is the reference.
QueryControlModule only exists with Pro. Feature-detect and fall back to a manual ID field — the exact pattern in DynamicAddToCartWidget:
use Elementor\\Controls_Manager;\nuse ElementorPro\\Modules\\QueryControl\\Module as QueryControlModule;\n\nprivate function has_query_control_support(): bool {\n return class_exists( QueryControlModule::class ); // Pro present?\n}\n\nprivate function product_control_type(): string {\n return $this->has_query_control_support()\n ? QueryControlModule::QUERY_CONTROL_ID\n : Controls_Manager::TEXT; // manual ID entry\n}\n\n// …building the control:\n$control = [ 'label' => esc_html__( 'Product', 'myplugin' ), 'type' => $this->product_control_type() ];\n\nif ( $this->has_query_control_support() ) {\n $control['autocomplete'] = [\n 'object' => QueryControlModule::QUERY_OBJECT_POST,\n 'query' => [ 'post_type' => 'product' ],\n 'display' => 'minimal',\n 'by_field' => 'ID',\n ];\n} else {\n $control['description'] = esc_html__( 'Enter the product ID manually. Activate Elementor Pro for the search picker.', 'myplugin' );\n}\n$this->add_control( 'product_id', $control );\nVerified at DynamicAddToCartWidget.php:43-53,181-198. Either way the stored value is a post ID, so render()/get_value() resolves it identically regardless of which control produced it.
SELECT2 from an unbounded query (products/posts/users). Preloaded options are for small, fixed sets only.QUERY_CONTROL_ID + autocomplete for large datasets. It is search-scoped server-side; size doesn't matter.class_exists( QueryControlModule::class ) and degrade to a Controls_Manager::TEXT manual-ID field (or a deliberately bounded SELECT2).pro_panel_posts_control_filter_autocomplete / query_control_value_titles; you only declare autocomplete.'options' => [] for a query control — options arrive via AJAX; preloading defeats the purpose.object: author = users who authored content, user = all users; post needs a query.post_type scope; tax searches terms.get_permalink( (int) $id ), wc_get_product( (int) $id )) and handle a missing/invalid ID.// WRONG — query control but options preloaded (pointless + slow)\n$this->add_control( 'id', [\n 'type' => QueryControlModule::QUERY_CONTROL_ID,\n 'options' => $all_products, // <-- defeats the AJAX control\n] );\n\n// WRONG — hard-requiring Pro; control silently missing on free → no way to set a product\n$this->add_control( 'id', [ 'type' => QueryControlModule::QUERY_CONTROL_ID, /* … */ ] );\n// (no class_exists guard → fatal/empty when Pro inactive)\n\n// WRONG — writing your own ajax handler for it\nadd_action( 'wp_ajax_my_product_search', /* … */ ); // <-- unnecessary; Pro handles query control AJAX\n\n// RIGHT — feature-detect, degrade, let Pro do the AJAX\n$type = class_exists( QueryControlModule::class )\n ? QueryControlModule::QUERY_CONTROL_ID\n : \\Elementor\\Controls_Manager::TEXT;\nelementor-dynamic-tag-fields for the control types, Tag vs Data_Tag, and reading settings back.elementor-dynamic-tag-register for registering the tag and the Pro-feature reality.wc-product-search-select for the WooCommerce-native product search/select control (a non-Elementor alternative for product pickers).query args per object type, include_type, sorting) — read module.php autocomplete_query_for_*.wp_ajax_, but out of scope; prefer the manual-ID degrade.Group_Control query side) — this skill is about single-item pickers.QUERY_CONTROL_ID/QUERY_OBJECT_* (29,34-39), empty-term early return (211), autocomplete_query_for_post sets s (233-242), AJAX action registration (~1012-1024).class Query extends Control_Select2.