Description

The regex used in gutenberg_restore_group_inner_container() and the corresponding wp_restore_group_inner_container() does not appear to work as intended when there is a large amount of inner content. This can lead to the first regex failing to detect the inner__container, leaving the second regex to add a second container. For themes that expect only one, this can cause layout issues.

An initial example of content that breaks with the regexes in that function: https://3v4l.org/1s7cT

The sample content is structured as :

• Group
  • Heading
  • Latest Posts (filtered to change the output HTML and add extra elements)

My understanding is that the backtracing steps get so overwelmed that they can trigger limits set on hosts, and failing the first match causes the second to be applied.

Partially this only occurs because if the content was originally written in WordPress 5.7 'the_content' will contain the inner__container, so the PHP should not run. Whilst creating/editing the content WP 5.8 the inner__container will never be there for the first regex to match against.

I'm thinking that to reduce the steps for the regex the Ungreedy flag can be added, but also the last groupings ((.|\S|\s)*) don't appear to be required which would further reduce the overal steps.

Related: #30443, #30461

Step-by-step reproduction instructions

1. Within WordPress 5.7 create content of a group and a large number of any other blocks that cause a lot of HTML, such as Latest Posts
2. Update the site to WP 5.8
3. Check the frontend HTML to see double inner__container for the group

Screenshots, screen recording, code snippet

Markup and regex example with possible changes on https://3v4l.org/1s7cT

Environment info

• WordPress version: 5.8
• Gutenberg version: 11.3.0 (not active)

Pre-checks

• I have searched the existing issues.
• I have tested with all plugins deactivated except Gutenberg.