| | 1 | == Revised patch |
| | 2 | |
| | 3 | In testing it was found that the first attempt of the patch was incomplete. It wasn’t accounting for opening and closing tags and how that traversal was managed by the state of the stack. The second attempt, commit bfc4a1c04f8ab3f808529edde74dce550d4f3d65, no longer tries to replace the core processing logic. Instead, its an attempt to optimize the way the code navigates the HTML. The patch now replicates the traversal. |
| | 4 | |
| | 5 | The original code used a while ( $p->next_tag() ) loop to walk through the template’s HTML, visiting every opening and closing tag in sequential order. The patched code does this once to create the “traversal blueprint,” which is simply an ordered list of bookmarks for every tag the processor visits. In the main loop, the code iterates through this cached list of bookmarks and uses $item_p->seek() to jump to each tag in the exact same sequence. This aims to mimic the original code's traversal. |
| | 6 | |
| | 7 | Crucially, once the code seeks to a tag, it calls the original, unmodified $this->process_directives() function. This means that all the complex, necessary features, like handling enter and exit modes, checking for unbalanced tags, and respecting directive priority, are still being handled by the battle-tested core code. Finally, the patch adds a small but important check: if ( ! empty( $item_p->get_attribute_names_with_prefix( 'data-wp-' ) ) ). This ensures that the code only calls the expensive process_directives function on tags that actually have directives. For all other tags (like a simple <p> or <span>), the code still seeks to them to maintain the correct traversal order, but it skips the unnecessary processing call. |
| | 8 | |
| | 9 | |
| | 10 | |