Proposal of WooCommerce-specific commands for the Command Palette API

[Aljullu]

WordPress 6.3 introduced the Command Palette API and WordPress 6.4 updated it with several improvements. The Command Palette allows users to access certain actions directly from the post and site editors using commands.

Currently, WooCommerce doesn't include any specific commerce-related commands. This discussion is about deciding which commands might be good to add and, eventually, adding them.

Heads-up that there is already an open PR which adds one example command in #39268. So what's left is deciding which commands we want to include. There has also been some previous discussion about this topic here: woocommerce/woocommerce-blocks#11521.

Proposal

These are the proposed commands:

Iteration 1

Static commands

• Add new product
• Add new order
• Products: same as the one in this PR, but renaming it to Products to match the Pages command.
  • Sidenote: should we consider making a contribution upstream in Gutenberg, so any Custom Post Types appear automatically in the command line?
• Orders: similarly, it should be possible to access the orders list.
• [settings_title]: searching for a Settings tab name or section name, should redirect to that page/section. Ie: Store Address, Shipping, Payments, etc.
• [analytics_title]: searching for an Analytics page name, should redirect to it. Maybe in the command label we should suffix "Analytics" or "Stats". Ie: Revenue Analytics, Order Analytics, etc.

Dynamic commands

• [product]: searching for a product name should redirect to the product edit page. Ie: Hoodie.

Iteration 2

Dynamic commands

• [product] Analytics: searching for a product should also offer seeing its analytics page. Ie: Hoodie Analytics.
• [product_variation] + [product_variation] Analytics: same as before but with product variation names.
• [product_cat] + [product_cat] Analytics: same as before but with product categories.
• [product_tag]: same as before but with product tags.
• [product_attribute]: same as before but with product attributes.
• [coupon_code] + [coupon_code] Analytics: same as before but with coupon codes.
• [order_id]: searching for an order ID should redirect to the order page.

Keep in mind that I intentionally didn't include commands related to the new Product Editor for now.

Questions

• Do these commands look good to you? Is there any you would modify or remove?
• Would you add any additional commands?

[lsinger]

Products: same as the one in this PR, but renaming it to Products to match Pages and Single Posts commands.

In the same vein, I think Orders are an even more important part of merchants' day-to-day?

Sidenote: should we consider making a contribution upstream in Gutenberg, so any Custom Post Types appear automatically in the command line?

My worry would be that there's some potential for things to become too cluttered. IMHO explicit opt-in by type could be the cleaner option.

[Aljullu]

Thanks for your feedback, @lsinger!

In the same vein, I think Orders are an even more important part of merchants' day-to-day?

Good idea! I added to the list of the original post.

My worry would be that there's some potential for things to become too cluttered. IMHO explicit opt-in by type could be the cleaner option.

Good point. I guess it really depends on what's the custom post type. Being it opt-in makes sense.

[senadir]

I maintain a private plugin that essentially does that, but I don't think WooCommerce in its current form can support searching for products and orders from a palette simply because of how slow it can be. The plugin I have syncs up the inventory and orders with Algolia and searches it directly.

I think other commands are possible like creating products and orders.

[Aljullu]

I maintain a private plugin that essentially does that, but I don't think WooCommerce in its current form can support searching for products and orders from a palette simply because of how slow it can be. The plugin I have syncs up the inventory and orders with Algolia and searches it directly.

Thanks for the feedback, @senadir! That's a good point; searching might take some time and commands will definitely be slower to appear. However, I think that's expected for dynamic commands. Gutenberg has commands to navigate pages and posts which are indeed slower than the other commands:

Enregistrament.de.pantalla.del.2023-11-16.10-24-10.webm

Was your point because you think that we would be adding too many parallel requests? Or because the endpoints to search for products & orders would be specially slow? Something we could iterate on might be to start small in the number of dynamic commands we introduce (ie: first iteration we only include products and orders) and in the future evaluate whether we want to expand it to other things like coupons, tags or categories.

I think other commands are possible like creating products and orders.

Sounds good! I added Add new order to the list.

[pmcpinto]

Here's my proposal:

• Keep a tight scope in the initial iteration: implement all the static commands and the [product] dynamic command*
• Track usage, including the search terms, as this data is an important signal to identify what should be included next.

*- we could also include [order_id], but I wonder how many merchants know all the ids. Eventually, it would make more sense to show orders that have a specific product, when the users search for that product, but this is too complex for the i1 and it needs more validation.

[Aljullu]

Thanks for the feedback, @pmcpinto! Everything makes a lot of sense! I updated the list at the beginning of the discussion and will start working on Iteration 1 next week.