Command Palette: Refactor enqueue function to remove regex.

[cbravobernal]

The wp_enqueue_command_palette_assets() function uses REGEX to remove all HTML tags and their contents from the menu items, so that it only display text.

It was using REGEX for it, and can be replaced with the Tag Processor.

Refactors the code on the command palette enqueue function to strip the HTML by using the Tag Processor instead of a couple of regex functions.

Proposed by @dmsnell . Props to him.

Trac ticket: https://core.trac.wordpress.org/ticket/64196

[davidbaumwald]

In 61126:

Command Palette: Use HTML_Tag_Processor to get the menu label when enqueueing assets, not regex.

HTML_Tag_Processor is more better.

Follow-up to [61022].

Props dmsnell, cbravobernal.
Fixes #64196.

[davidbaumwald]

Small initialization bug. Follow-up commit incoming.

[davidbaumwald]

In 61127:

Command Palette: Ensure $menu_label is initialized before using it.

Unprops davidbaumwald.

Follow-up to [61126].

Props cbravobernal.
See #64196.

[wildworks]

I don't think we can simply replace REGEX with HTML_Tag_Processor. The menu may contain the 0 that are visually hidden. See ​https://github.com/WordPress/gutenberg/pull/71476#discussion_r2318390285 for more details.

[wildworks]

Search for "plugins". The number zero will be displayed visually.

[tusharaddweb]

I test this in my local setup but it still persist

Go through the below image link

​https://postimg.cc/D41TLnZK

[cbravobernal]

I'll revert the commits as soon as possible. Thanks @wildworks for pointing it out and @tusharaddweb for confirming.

[cbravobernal]

In 61142:

Command Palette: Revert Use HTLM_Tag_Processor to get the menu label when enqueueing assets.

Reverts [61126] and [61127], which introduced a bug where the command palette is not stripping numbers. HTML_Tag_Processor cannot replace the REGEX yet.

Unprops cbravobernal.

Follow-up to [61126], [61127].

Props wildworks, tusharaddweb.
See #64196.

[dmsnell]

If the issue is removing content inside of the HTML tags we can still do that. In reading the PCRE pattern and the comment above it, I misunderstood the purpose of the existing code. Thanks for highlighting that @wildworks.

The fix is not much different than the proposed HTML API code. All we have to do is track depth based on opening and closing tags, or use WP_HTML_Processor and rely on its get_depth() report.

That will still resolve a number of issues with the PCRE approach, including misparses, handling HTML void elements like HR, and leaving potentially-encoded labels in place instead of decoding them.

[madhavishah01]

Tested this locally and found Theme : 0

Kindly refer below screenshot:-
​https://postimg.cc/DW6F8JLL

[wildworks]

The fix is not much different than the proposed HTML API code. All we have to do is track depth based on opening and closing tags, or use WP_HTML_Processor and rely on its get_depth() report.

@dmsnell Thank you for telling me this! I'll try this approach tomorrow.

I might address this feedback in the same pull request as well: #64177

[wildworks]

I have submitted a PR: ​https://github.com/WordPress/wordpress-develop/pull/10480/

This PR addresses both this ticket and #64177.

[wildworks]

There's less than an hour until the RC1 commit freeze. I'm not entirely confident about ​PR 10480, so let's punt this ticket to 7.0.

If this patch needs to be included in version 6.9, let's reconsider it.

[wildworks]

I have opened a new #64233 to address the new issue, so I will close this ticket.