__group__,ticket,summary,owner,_component,_version,priority,severity,milestone,type,_status,workflow,_created,modified,_description,_reporter Slated for Next Release,58902,add_query_arg() should esc_url_raw() REQUEST_URI,,Formatting,,normal,normal,6.6,defect (bug),new,has-patch,2023-07-25T17:43:33Z,2024-02-22T11:22:14Z,"add_query_arg assumes that the query argument is an acceptable query argument. In order to help developers from accidently making a URL an unacceptable URL. Some related tickets: #16859, #22951, and #22300. The security team has reviewed this and ok'd it being worked on in public. ",jorbin Slated for Next Release,51019,convert_smilies() fails on large tags,,Formatting,5.5,normal,normal,6.6,defect (bug),new,needs-unit-tests,2020-08-15T12:51:26Z,2024-02-29T12:08:49Z,"I have an image with huge data-url src (1.6M) in the post content. The post content is not displayed, but (with `WP_DEBUG` on) there is a php error instead. PHP Error output: {{{ Warning: count(): Parameter must be an array or an object that implements Countable in /Users/joern/www/vhosts/wordpress.local/httpdocs/stable/wp-includes/formatting.php on line 3357 }}} Som digging revealed, that `preg_split()` in `function convert_smilies()` fails with a `PREG_RECURSION_LIMIT_ERROR`. IMHO there should a check for `preg_last_error()` whether `preg_split()` was successfull, and if not the function should just return its input. Any thoughts on this? I'd be happy to craft a patch.",podpirate Slated for Next Release,60814,several typo corrections in formatting.php file,audrasjb*,Formatting,,normal,trivial,6.6,defect (bug),accepted,commit,2024-03-20T17:06:23Z,2024-03-20T17:36:50Z,"several typo corrections in wp-includes/formatting.php file inline comments `parethesis` -> `parenthesis` `paretheses` -> `parentheses` `puctuation` -> `punctuation`",shailu25 Tickets Awaiting Review,48261,"""noopener noreferrer"" mis-parses links with ""rel="" parameters",,Formatting,5.2.3,normal,normal,Awaiting Review,defect (bug),new,has-patch,2019-10-08T21:39:20Z,2019-10-09T22:55:14Z,"If a link contains a url parameter named ""rel"" and the rel=""noopener noreferrer"" attribute is triggered (ie. the link has the target=""_blank"" attribute as well) then it botches the parsing, and you wind up with a link that looks like: {{{ Anchor Text }}} ",mvandemar Tickets Awaiting Review,57235,'excerpt_remove_blocks' removes list blocks,,Formatting,,normal,normal,Awaiting Review,defect (bug),new,has-patch,2022-11-30T12:59:08Z,2022-11-30T13:50:19Z,"As reported here: https://github.com/WordPress/gutenberg/issues/46167 When an excerpt of a block containing a listing is output, the listing is removed. This seems to be caused by the fact that list items became blocks in WordPress 6.1.",wildworks Tickets Awaiting Review,51287,Administrators & Editors can't create localfile links in a multisite installation,,Formatting,,normal,major,Awaiting Review,defect (bug),new,,2020-09-10T11:08:31Z,2020-09-24T00:02:56Z,"Steps to reproduce: Clean WordPress Multisite installation. Create a user with Administrator (or Editor) capabilities, not Super Admin. Login as the new user. Create a new page, and create a local file link in the visual editor. Enter a local file URL, e.g. **localfile:E:\foobar\** Publish and refresh the page. The link has now been stripped into a **\foobar\.** Note, if you try this with a Super Admin user it works as expected, and the link is correctly created. Why does WP strip the **localfile:E:** part of the link if the user is not an admin? ",peikgabriel Tickets Awaiting Review,56531,"Aiming to “kill” entities, `sanitize_title_with_dashes()` happens to eat content",,Formatting,,normal,major,Awaiting Review,defect (bug),new,,2022-09-08T00:01:54Z,2022-09-25T04:52:37Z,"{{{ $title = preg_replace( '/&.+?;/', '', $title ); }}} This regex deletes the part of the title between an ampersand and a semicolon. I ran into this issue when testing ASCII symbols and punctuation but it may affect titles using a semicolon instead of an inner period, and happen to use an ampersand before. Semicolon is less common, even less in titles, but WordPress should not make assumptions nor impose limitations. In the process, `sanitize_title_with_dashes()` does again (cf. #56530) part of the job of `remove_accents()` but badly, deleting `é` instead of replacing it with `e`, and so on. I’d suggest decoding all HTML entities, then reencoding `<`, `>`, `&`: {{{#!php /', '/&/' ), array( '<', '>', '&' ), $title ); }}}",anrghg Tickets Awaiting Review,59158,Altering Details block styles doubling .wp-block-details class in the output,,Formatting,6.3,normal,normal,Awaiting Review,defect (bug),new,,2023-08-21T12:32:34Z,2023-08-21T13:47:23Z,"By defaut Details block styles outputs styles for inner paragraph like: {{{ .wp-block-details>:not(summary) { margin-block-end: 0; margin-block-start: var(--wp--style--block-gap); }}} ---- If I want to change margin-block-start on the block level styles I use: {{{ .wp-block-details>:not(summary) { margin-block-start: 0;} }}} BUT it outputs: {{{ .wp-block-details.wp-block-details>:not(summary) { margin-block-start: 0;} }}} ---- HOWEVER, If I use the same in the Additional CSS section of Styles Editor it produce expected: {{{ .wp-block-details>:not(summary) { margin-block-start: 0;} }}} ",randewoo Tickets Awaiting Review,60191,Ampersand in non-entities such as &a; is not escaped,,Formatting,,normal,normal,Awaiting Review,defect (bug),new,,2024-01-04T10:55:42Z,2024-02-27T11:53:02Z,"Wordpress escapes ampersand as {{{&}}} in many places. It checks if the ampersand is part of any entity before conversion, as the ampersand in an entity shouldn't be escaped. However the regex also passes things such as {{{&a;}}} which is not an entity, and wrongly doesn't convert the ampersand there. To correct that it has to be checked if the pattern matched is really an entity. Which can be done by using something like html_entity_decode and the decode for an entity would be different from the original string. The block editor somehow right checks and prevents strings such as {{{&a;}}} to pass but older posts and something inserted by plugins will have this bug. ",superpoincare Tickets Awaiting Review,43810,Apostrophe issue,,Formatting,4.9.5,normal,normal,Awaiting Review,defect (bug),new,,2018-04-19T13:31:05Z,2022-02-18T21:17:15Z,"Take a look. Instead of to have normal apostrophe, we have open and close if is between tags [[Image(https://i.imgur.com/c6QDmR5.png)]] [[Image(https://i.imgur.com/1F1zfWj.png)]]",colomet Tickets Awaiting Review,41304,Bad protocol sanitization in KSES for URLs NOT RFC 3986 compliant,,Formatting,4.8,normal,normal,Awaiting Review,defect (bug),new,,2017-07-13T10:41:29Z,2017-07-13T14:10:32Z,"For URL's that are passed through the kses sanitizer. As specified in RFC 3986, Section 3.3 The path component contains data, usually organized in hierarchical form, that, along with data in the non-hierarchical query component (Section 3.4), serves to identify a resource within the scope of the URI's scheme and naming authority (if any). The path is terminated by the first question mark (""?"") or number sign (""#"") character, or by the end of the URI. If a URI contains an authority component, then the path component must either be empty or begin with a slash (""/"") character. If a URI does not contain an authority component, then the path cannot begin with two slash characters (""//""). In addition, a URI reference (Section 4.1) may be a relative-path reference, in which case the first path segment cannot contain a colon ("":"") character. The ABNF requires five separate rules to disambiguate these cases, only one of which will match the path substring within a given URI reference. We use the generic term ""path component"" to describe the URI substring matched by the parser to one of these rules. So colon(':') is allowed inside URL's. When trying to split the URL like this: {{{#!php [code-highlight line-numbers=""table"" linenostart=""53"" highlight-lines=""1,3,8"" style=""native"" lang=""html+php"" pyg-id=""1"" ] checkstyle [code-highlight style=""native"" lang=""perl"" pyg-id=""2"" ] (?:s+)(?:(/*([^*]|[rn]|(*+([^*/]|[rn])))**+/)|(//(?!.*(CHECKSTYLE)).*)) [/code-highlight] }}} Here dump after this line {{{ $textarr = wp_html_split( $content ); var_dump($textarr); exit; }}} {{{ array(25) { [0]=> string(0) """" [1]=> string(3) ""
"" [2]=> string(28) ""Some amount of useless text "" [3]=> string(11) """" [4]=> string(0) """" [5]=> string(4) ""
"" [6]=> string(1) "" "" [7]=> string(3) """"
[8]=>
string(121) ""[code-highlight line-numbers=""table"" linenostart=""53"" highlight-lines=""1,3,8"" style=""native"" lang=""html+php"" pyg-id=""1"" ]""
[9]=>
string(6) ""
""
[10]=>
string(1) ""
""
[11]=>
string(464) """"
[12]=>
string(10) ""checkstyle""
[13]=>
string(9) """"
[14]=>
string(0) """"
[15]=>
string(4) ""
"" [22]=> string(15) ""Some Text Again"" [23]=> string(4) ""
"" [24]=> string(1) "" "" } }}} As you can see one shortcode was not splitted, and here the problem. If php closing tag is present (?>) than everything works fine. Problematic regex provider {{{#!php is found. . '-(?!->)' // Dash not followed by end of comment. . '[^\-]*+' // Consume non-dashes. . ')*+' // Loop possessively. . '(?:-->)?'; // End of comment. If not found, match all input. $cdata = '!\[CDATA\[' // Start of comment, after the <. . '[^\]]*+' // Consume non-]. . '(?:' // Unroll the loop: Consume everything until ]]> is found. . '](?!]>)' // One ] not followed by end of comment. . '[^\]]*+' // Consume non-]. . ')*+' // Loop possessively. . '(?:]]>)?'; // End of comment. If not found, match all input. $escaped = '(?=' // Is the element escaped? . '!--' . '|' . '!\[CDATA\[' . ')' . '(?(?=!-)' // If yes, which type? . $comments . '|' . $cdata . ')'; $regex = '/(' // Capture the entire match. . '<' // Find start of element. . '(?' // Conditional expression follows. . $escaped // Find end of escaped element. . '|' // ... else ... . '[^>]*>?' // Find end of normal element. . ')' . ')/'; } return $regex; } }}} Without any doubts this case should be included in regex. ",crosp Tickets Awaiting Review,48873,CSS Selectors in style tags containing greater than signs are escaped,,Formatting,5.3,normal,normal,Awaiting Review,defect (bug),new,,2019-12-04T09:25:20Z,2019-12-04T09:45:03Z,"If you have unfiltered html disallowed, and you have in your content a style tag with a `>` selector, the selector will be escaped into `>` preventing the CSS from working. I've used the `wp_kses_allowed_html` filter to allow `style` tags in wp_kses. I also have this defined to disallow unfiltered html: {{{ define( 'DISALLOW_UNFILTERED_HTML', true ); }}} Sample content: {{{ }}} Saving this with unfiltered html disallowed would result in: {{{ }}} Since it's escaped, the CSS stops working. I don't think there's a way to allow allow `>` signs in ` paragraphparagraph
paragraph
paragraph test
italic
normal
paragraph
paragraph
paragraph
paragraph
paragraph
paragraph
Honor this whitespace
paragraph
paragraph
paragraph
` tags as it will run after wpautop(). Also, preg_split() will split the text in more chunks which will be easier to process. Disadvantage: the `no_texturize_shortcodes` filter will stop working. ",azaozz Unpatched Enhancements,39636,Smilies not converted when directly followed by punctuation marks,,Formatting,4.7.1,normal,normal,Future Release,enhancement,new,dev-feedback,2017-01-19T10:29:30Z,2022-04-11T03:02:17Z,"Steps to recreate: - Create a new post or comment - Insert a smilie directly followed by a period or other punctuation mark such as :). - View the post or comment Expected: Ideally the smilie would show followed by the punctuation mark. I've attached a screenshot showing how a post with the following text appears. Smiles with a space between them and the punctuation mark show, but the others do not. {{{ This is a test :). It uses smilies :) If a smilie has punctuation directly after, it is not converted :(! :( The expected behavior would be to look like this: :) ! :) , However instead they appear as this :)! :), }}} ",ourvalley Unpatched Enhancements,25856,debug of wpautop function with Unit Tests,,Formatting,3.8,normal,normal,,enhancement,new,,2013-11-07T03:04:23Z,2024-03-20T17:54:47Z,"== Cleanup / Refactor of wpautop function == Upon review of the WordPress Trac needs-unit-test filter I saw that the wpautop function was needing both cleanup and unit tests. I have created a comprehensive test suite for the function that covers in my opinion the full breadth of use cases for the function. During this process I have been working on modifying the wpautop function to resolve out open defects and remove ''fix'' code that was placed to resolve an issue without resolving the underlying cause of the error. I've attached the following files for support of the changes. ''autop-20622.out'' --> OUTPUT from running the unit tests against current code base (revision 20622) ''autop-diff.out'' --> OUTPUT from running the unit test against modififed wpautop function as given in the diff. ''Autop.diff'' --> diff of changes made to the Autop test class :: Unit Tests ''formatting.diff'' --> diff of changes made to the formatting.php function file :: wpautop changes ''As a note I've added a trim call to the end of wpautop as it was always appending a new line, which I did not think was needed. This causes a good amount of test cases to fail as the expected output is not containing the additional new line given by current implementation.'' ---- == Enhancements / Fixes to wpautop function == 1. Corrected core logic to identify when double new lines wrap open or close block element tags due to nested block level elements. Original Logic adds \n\n before open tags and \n\n after close tags which allows for output of
tags
2. Added logic to not add
tags after comments
3. Added logic to not convert \n for svg, math, style, select or script codes
4. Added logic to not format audio, video or object elements. This is implemented as the elements are in-line but can contain block level content for displaying in browsers that don't support the HTML5 elements.
5. case insensitive recognition of block tags
6. inclusion of variable re-naming as outlined in #25516
----
== Overview of Tickets reviewed and covered by the Unit Tests ==
Ticket : Current Status : Summary
#6877 : Closed : large posts causes empty return
#3476 : Closed : Improper formatting of Object elements, additional
and no ending
tags inside of block elements that only contain inline elements/text #6809 : Closed : wpautop correctly handles auto
of basic text
#11024 : Closed : Incorrect handling of div tags with nested inline tags
#1305 : Closed : Handling of tags with attributes introduce additional tags, no closing
#3621 : Closed : Don't format new lines in Script and Object tags
#3854 : Closed : Don't format new lines in Script and Style tags
#3935 : Closed (wf) : Erroneous blocks>
#1706 : Closed :
#2285 : Closed : Strip excessive
in content
#2813 : Closed :
elements added instead of
#3007 : Closed : Spacing of text in block elments reveals improper handling of nested elements
#3035 : Closed : Extra
tags introduced in Object tags.
#3238 : Closed : Dangling