-
Notifications
You must be signed in to change notification settings - Fork 3.2k
HTML API: Use case insensitive next_tag tag_name comparison #7754
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTML API: Use case insensitive next_tag tag_name comparison #7754
Conversation
`get_tag` returns an uppercase string, any passed tag_name should be uppercased.
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Did we originally do this intentionally ASCII case-sensitively, and if so, why? |
|
As far as I can tell this was an oversight. I can't think of a reason to match this case-sensitively. I suspect this was not noticed because the shorthand exists for the next tag with a tag name in the HTML Processor: Under the hood that uses wordpress-develop/src/wp-includes/html-api/class-wp-html-processor.php Lines 547 to 549 in e9dfa8c
And that is handled correctly by the
(I had included a change in this patch to change the shorthand implementation to use |
dmsnell
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sirreal your archaeology fits the picture well. The tag_name query in the array form was added late, and because we were using the breadcrumb trick for the short form, it makes sense to me that this was indeed an oversight. We can’t reuse the breadcrumb trick in the array form since breadcrumbs could also be there.
Glad to have that investigation because it seemed so weird to me that we’d change the rules.
|
Committed to core in https://core.trac.wordpress.org/changeset/59422 |
Trac ticket: https://core.trac.wordpress.org/ticket/62427
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.