Pattern Overrides: Initial number of number set (or $ + 2 numbers) disappear from edited Paragraph & Heading Blocks

[EVERGIB]

Description

While using Synced Pattern Overrides on a pattern to display prices on a Paragraph Block for a restaurant menu, I noticed that the "$" and next two numbers of the price would not display on the website front end after editing from the original. Additionally, if I used only numbers for the price and no "$", I noticed that the first number of the set of numbers does not display on the front end (looks normal in the editor). The same issue happens with the "Headings" block when part of a Pattern Override.

Step-by-step reproduction instructions

1. Create Group Block
2. Add Heading Block and Paragraph Block to this group
3. Create Synced Pattern from this group and Enable Overrides for the Headings and Paragraph blocks
4. Add an instance of the synced pattern to your page
5. edit either the heading block or paragraph block with three or more numbers, or a $ followed by three or more numbers
6. view the page on the front-end - note that the initial number or $+2 numbers has disappeared

Screenshots, screen recording, code snippet

Images show the Pattern Override after editing the price - and the result on the website front end.

Environment info

Environment

• WordPress: 6.6-beta1
• PHP: 8.1.23
• Server: nginx/1.16.0
• Database: mysqli (Server: 8.0.16 / Client: mysqlnd 8.1.23)
• Browser: Chrome 125.0.0.0 (macOS)
• Theme: Twenty Twenty-Four 1.1
• MU-Plugins: None activated
• Plugins:
  • WordPress Beta Tester 3.5.5

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[Mamaduka]

cc @talldan, @kevin940726

[talldan]

Thanks for the ping @Mamaduka, we just discovered it here too - #62220 (comment)

[SantosGuillamot]

I believe it is caused by this refactoring of the replacement logic: link. My fault for using regex 🤦

The idea behind that pull request was to simplify the logic to support more attributes, but that didn't make it to 6.6. We should probably go back to the previous implementation and refactor the logic once the HTML API adds new methods to help with that.

[kevin940726]

@SantosGuillamot Thanks for the quick PR! I tried it out myself and also found a fix while keeping the regex:

diff --git a/lib/compat/wordpress-6.5/blocks.php b/lib/compat/wordpress-6.5/blocks.php
index d3a8b3f557..a0aca9a4e5 100644
--- a/lib/compat/wordpress-6.5/blocks.php
+++ b/lib/compat/wordpress-6.5/blocks.php
@@ -85,7 +85,9 @@ function gutenberg_block_bindings_replace_html( $block_content, $block_name, str
 				return $block_content;
 			}
 			$pattern = '/(<' . $selector . '[^>]*>).*?(<\/' . $selector . '>)/i';
-			return preg_replace( $pattern, '$1' . wp_kses_post( $source_value ) . '$2', $block_content );
+			return preg_replace_callback( $pattern, function ( $matches ) use ( $source_value ) {
+				return $matches[1] . wp_kses_post( $source_value ) . $matches[2];
+			}, $block_content );
 
 		case 'attribute':
 			$amended_content = new WP_HTML_Tag_Processor( $block_content );

It seems to work. This could be an alternative solution if the regex is needed for other reasons.

[SantosGuillamot]

Thanks for taking a look, @kevin940726! It seems safer to revert the changes and not use regex at all. The only benefits were code readability and potentially supporting more attributes, but maybe it is better to keep it the way it was until we can refactor it when the HTML API is ready. Anyway, I'd love to know more opinions.

[kevin940726]

Should be closed by #62355.