__group__,ticket,summary,owner,component,_version,priority,severity,milestone,type,_status,workflow,_created,modified,_description,_reporter Future Releases,34591,"BugFix to WP_Scripts::do_item(), remove doubled ""//""",,Script Loader,4.3.1,normal,normal,Awaiting Review,defect (bug),new,reporter-feedback,2015-11-05T11:01:37Z,2017-02-05T09:08:07Z,"Current code in `do_item()` of class.wp-script.php on line 172: {{{ $src = $this->base_url . $src; }}} may produce duplicate slashes `""//""`, resulting in problems. This might be fixed with code: {{{ $src = $this->base_url . $src; }}} Currently: * WP_Scripts contains: `""public $base_url; // Full URL with trailing slash""` and * script-loader.php contains calls `$scripts->add()` with initial `""/""` in relative paths Together this produces doubled slashes `""//""`. For example: http://www.ocelovehaly.cz/ll//wp-includes/js/jquery/jquery.js?ver=1.11.3 This makes W3TC include script in minified version, but not to remove it from the original HTML. Including jQuery twice makes LayerSlider not to work. Please, could you bugfix class.wp-script.php on line 172? Thank you :-)",jan.mazanek Future Releases,31136,Allow plugin authors to register an additional 'Uninstall Notification' plugin header and to display back to the user during plugin uninstall flow,,Plugins,,normal,normal,Future Release,enhancement,new,dev-feedback,2015-01-26T06:14:19Z,2017-02-05T09:58:14Z,"In wp-admin/plugins.php wordpress displays to the user information about the plugins you are attempting to uninstall. Currently it only displays the name of the plugin name ($plugin[ 'Name' ]) and the plugin author ($plugin[ 'AuthorName' ]). In V4.1 this output is generated around lines 289-304. Is it possible to add another field that contains a short piece of information from the plugin author, that can be presented to the user for each plugin? The plugin would need to register this information with wordpress when it was installed or updated. Specifically, I envisage this being used for details that the user might need to follow to preserve any data that they might have before they actually delete the plugin. An example string that I can see being used by a plugin: If you wish to uninstall without losing your data, see the details at http://example.com/plugin-uninstall. Notes: - Such a string should of course be optional to preserve backward compatibility. - Appropriate filtering and length checks should be done on the string to ensure that the uninstall plugin UI isn't easily broken or disturbed. This avoids the plugin author filling the field with a string that stops the user from being unable to uninstall the plugin.",cefiar Future Releases,36641,WP_Term method __toString,,Taxonomy,,normal,normal,Awaiting Review,enhancement,new,has-patch,2016-04-22T20:59:58Z,2017-02-05T14:18:20Z,"I think that this is good idea. For example: {{{#!php '; var_dump(implode(', ', get_the_terms( get_the_ID(), 'category' ))); echo ''; ?> }}} I have ```string(**) ""Cat 1, Cat 2""``` ",sebastian.pisula Future Releases,36564,Last Modified for Comments,,Comments,4.4,normal,trivial,Future Release,enhancement,new,dev-feedback,2016-04-17T20:44:59Z,2017-02-12T10:37:16Z,"Related #28463, #19495. Posts have a last modified and last modified gmt, but comments have no such thing. There are several proposals indicating a need for comment revision, or tracking when the comment is first created. Wanted to explore the idea of having last modified and last modified gmt stored as comment meta triggered by update_comment as a simple, low impact way of adding this feature that could be used by a variety of plugins. This could be implemented by plugin hooking to edit_comment, but if such a feature is to be useful, it needs a standard storage format.",dshanske Future Releases,37454,get_avatar_data() delivers different url for scheme=https and is_ssl(),,Users,4.3,normal,normal,Awaiting Review,defect (bug),new,has-patch,2016-07-25T08:09:46Z,2017-02-15T07:56:44Z,"get_avatar_data() has an option to set the scheme. If https is used, an image URL is returned which is different to the one which is returned in case delivery is conducted via https without the scheme parameter. I think it would be better to serve the same gravatar url for https pages and explicit https-scheme requests. Regarding performance and depending on the infrastructure, it could also be benefical to drop https://%d.gravatar.com completely and serve all requests to gravatar independent of the page's protocol via https://secure.gravatar.com/ to benefit from HTTP/2 (http and https://%d.gravatar.com requests are served via HTTP/1.1 whereas https://secure.gravatar.com/ allows multiplexing via HTTP/2).",neoxx Future Releases,39939,A Contributor cannot preview their own post if it's scheduled,,"Posts, Post Types",,normal,minor,Awaiting Review,defect (bug),new,,2017-02-22T12:52:02Z,2017-02-23T05:36:25Z,"Steps to reproduce: 1. A Contributor writes a post and submits it for review. At this point they can preview their post. 2. An Editor or Administrator approves the post and schedules it for publication at a later date. 3. The contributor viewing the Posts listing table can no longer preview their post. Previously: #33694 ",johnbillion Future Releases,39695,Add preload headers in redirects,,HTTP API,,normal,normal,Awaiting Review,enhancement,new,has-patch,2017-01-25T22:09:45Z,2017-02-27T09:32:49Z,"http2 push enabled servers can immediately push linked assets or documents for the client. This saves clients from one round-trip. At the moment at least Cloudflare and h2o web server can http2 server push assets defined in Link headers: https://www.w3.org/TR/preload/#server-push-http-2. I believe more will follow in the next few years. WordPress powers so much of the web that it's our responsibility to try to make it as fast as we can. This is usually quite hard topic because we have no idea what is stored in the client browser cache. We can start implementing the Link preload headers in internal redirects because in that situation it's quite obvious that the client wants to make that request as their next one. This is what I want to achieve {{{ $ curl --http2 -i https://wordpress.test/wp-admin/ HTTP/2 302 ... Location: https://laextra.test/wp-login.php?redirect_to=https%3A%2F%2Flaextra.test%2Fwp-admin%2F&reauth=1 Link: ; rel=preload; as=document }}} I created a patch which adds these headers automatically in '''wp_redirect()''' function. Links about http2 server push: https://blog.cloudflare.com/announcing-support-for-http-2-server-push-2/ https://h2o.examp1e.net/configure/http2_directives.html",onnimonni Future Releases,26402,Add option to DB if option is only present in cache when updating option,,Cache API,3.8,normal,normal,Future Release,defect (bug),new,has-patch,2013-12-04T17:57:07Z,2017-03-17T17:45:33Z,"In very rare circumstances some options may not be in DB but in cache. On update if updating DB fails remove from cache and try to add option. This would eventually fix cache inconsistencies if they occur. Both update_option and update_site_option are affected.",codix Future Releases,40357,"dbDelta can't change primary keys, create AUTO_INCREMENT columns and doesn't make significant index changes",,Database,4.8,normal,normal,Awaiting Review,enhancement,new,has-patch,2017-04-04T17:20:04Z,2017-04-04T18:21:02Z,"dbDelta has three inter-related issues which center around changing indexes. 1) It isn't possible to change which column is the primary key 2) It isn't possible to add a new AUTO_INCREMENT column 2b) It isn't possible to modify an existing AUTO_INCREMENT to no longer be AUTO_INCREMENT 3) Indices with the same name are not dropped/re-created, even when the index definition is changed significantly. == Use case == A client had been tracking inventory in a custom table where the product ID was the primary key. When he opened a new location, we added a location column, and wanted to be able to track how many of each product was in each location. 1. A table's purpose is being expanded, or otherwise doesn't meet the needs of the data. Since the primary key is unique, we needed to add a new key column and change which column was designated as the primary key. 2. A table was originally defined without an AUTO_INCREMENT column and the need for such a column arises. The new column we wanted to add and use for the key was simply an AUTO_INCREMENT integer column. In testing we defined the new column and also defined a new UNIQUE index (so, not changing the primary key yet). Since dbDelta adds new columns before adding the new indices, and in separate ALTER TABLE statements, MySQL refuses to add a new AUTO_INCREMENT column without an index. The solution is to add the new column without the AUTO_INCREMENT designation, then add the UNIQUE index, then alter the table to use AUTO_INCREMENT. 3. A primary (or other key) could be significantly and intentionally altered, significantly changing how queries are run. I understand that WP doesn't want to drop and recreate indices when changing the sub-part of an index (see: https://core.trac.wordpress.org/ticket/34870#comment:21) However I think that it should change the index, if the definition is significantly altered. In the use case above, we could've changed the primary key to be `PRIMARY KEY(productId,location)` instead of adding a new column and switching the index to that column. In other use cases, changing from a BTREE to FULLTEXT index would change which types of queries need to a full table scan. == This Patch == This patch does the following: 1. You can now add a new AUTO_INCREMENT column to an existing table When a new AUTO_INCREMENT column is added to an existing table, the column creation is done in two parts. First the column is created as a non-AUTO_INCREMENT column, and a separate `ALTER TABLE` statement is set to run after index creation to enable AUTO_INCREMENT. Note: The CREATE TABLE statement given to dbDelta must provide the required indexes that MySQL expects. 2. You can now modify a column with AUTO_INCREMENT to no longer use AUTO_INCREMENT 3. You can change which column is the primary key 4. Significant index definitions cause an index to be dropped and re-created The cases that cause an index to be dropped and re-created are: * An index which wasn't UNIQUE, but now is or vice-versa * An index which changes index type (eg. FULLTEXT => BTREE) * An index which contains a different number of columns * An index which contains a different column order * An index which contains different columns Note: Changing the index sub-part or no longer defining the index in the table does not cause it to be dropped. == Other notes == 1. I've tried to use WP coding standards and comment my code well. I'd love feedback if there are things I can do better. 2. I've included a file, test.php which takes 13 table definitions, takes them two at a time, and converts between each possible combination. To run it, put it in the root WordPress directory and run `php ./test.php`. 3. Also, the dbDelta phpunit tests still pass.",stuporglue Future Releases,35907,Permit sticky posts to affect the query in REST_REQUEST,rmccue,Query,,normal,normal,Future Release,enhancement,reopened,has-patch,2016-02-22T23:44:13Z,2017-04-23T22:19:55Z,Needed for https://github.com/WP-API/WP-API/issues/2210,danielbachhuber Future Releases,35574,Add REST API JSON schema information to WP_Widget,,Widgets,2.8,normal,normal,Future Release,enhancement,new,,2016-01-22T12:24:06Z,2017-04-23T23:27:58Z,"With the REST API, there is an emerging-established way in WordPress for describing a data structure, such as a widget instance. One aspect of the REST API endpoint schema is the `default` values for given fields on a property. Widgets often have duplicated logic between the `WP_Widget::widget()`, `WP_Widget::update()`, and `WP_Widget::form()` methods for checking if a given `$instance` property has been set, and if not, supplying a default value. In some cases, these `isset` checks are ''not'' performed resulting in PHP notices if the methods are programmatically invoked with an empty array. With JSON Schema defined, we would provide `$instance` defaults upon which the current stored `$instance` can be merged. Widgets in WordPress are assumed to be arrays, with the applied filters and function return values. With a schema defined, the data type of a widget instance would be guaranteed. Meta in the REST API is a challenge given that it may or may not contain serialized PHP. Widgets are stored in serialized PHP arrays in WP options (though it is possible to store them in posts, per #32474). Additionally, the instance arrays may also contain PHP objects for classes that cannot be cleanly serialized into JSON, and having a REST API JSON schema defined for a widget would guarantee that a widget instance can be represented in JSON. This would, in turn, allow widgets to be exposed as [https://github.com/WP-API/WP-API/issues/19 endpoints] in the REST API, and it would allow widget instances to be completely manipulated with JavaScript (such as in the Customizer, as described in #33507). By adding schema information to `WP_Widget`, we get a lot more than having default `$instance` data available. For one, the widget form can be automatically generated based on the schema if one is not defined (i.e. if `noform` is returned from the `WP_Widget::form()` method). (This may actually be focus of the Fields API.)",westonruter Future Releases,35390,image_constrain_size_for_editor() should not affect images generated on the front end when `large` size is used.,joemcgill*,Media,4.4,normal,normal,Future Release,defect (bug),accepted,,2016-01-10T04:01:24Z,2017-05-31T21:17:47Z,"{{{ }}} I am using Twenty Fifteen theme, WordPress version 4.4. `post-thumbnail` size is `825x510`. Original image size is `1600x1200`. But I am not getting expected image. After some testing I found that this problem arises if post thumbnail `large` is used. I could not understand how width and height is set to 680 and 510 respectively. I am not sure this is related to https://core.trac.wordpress.org/ticket/35108",rabmalin Future Releases,38303,register_meta and capabilities aren't working as expected,rmccue,Role/Capability,4.6,normal,normal,Future Release,defect (bug),reopened,,2016-10-13T14:43:18Z,2017-06-25T20:31:21Z,"The first part of this is #38284, there aren't capabilities for object types other than posts. The second part is best described by a use case: I want logged in users to be able to flag inappropriate comments. After 10 flags, the comment gets unpublished and a notice goes to a moderator to check it. I'm going to store these flags and the user in the comment meta table using something like {{{#!php 'string', 'show_in_rest' => true, 'auth_callback' => 'check_logged_in' ); register_meta( 'comment', 'flagged', $args ); function check_logged_in(){ return is_user_logged_in(); } }}} However, I don't want them to be able to edit the comment itself so `current_user_can( 'edit_comment' )` should return false. So that's the use case. What happens at the moment is, well, no one can update the comment because there's no edit_comment_meta capability. But it's not a problem making the capabilities work like that. However, `edit_post_meta` currently doesn't work like that. For `current_user_can( 'edit_post_meta' )` to return true, a user also has to have the `edit_post` capability. It's straightforward to change, but does have one backwards incompatibility: if someone is using current_user_can( 'edit_post_meta' ) with a registered meta key which has an auth_callback that returns true but they really ''don't'' want the person to update the post meta so are relying on the fact that they don't have the edit_post capability, then that will change and that person will be able to update the post meta. It's a slightly convoluted edge case, admittedly. Attached is a patch that shows how it would work with unit tests. ",tharsheblows Future Releases,39084,Introduce singular capabilities for managing individual comments,,Comments,,normal,normal,Future Release,enhancement,new,,2016-12-04T22:14:50Z,2017-07-14T19:41:15Z,"As we did in #35614 for taxonomy terms, singular capabilities should be introduced for approving, unapproving, spamming, unspamming, editing, and deleting individual comments. This would allow fine-grained cap checks such as current_user_can( 'edit_comment', $comment_id ) and current_user_can( 'approve_comment', $comment_id ).",johnbillion Future Releases,33240,Introduce a capability for previewing posts,,Role/Capability,,normal,normal,Future Release,enhancement,assigned,,2015-08-03T11:36:52Z,2017-07-14T19:41:15Z,"In order to preview an unpublished post (ie. draft or pending), a user needs the `edit_posts` capability for that post type ([https://core.trac.wordpress.org/browser/tags/4.2.3/src/wp-includes/capabilities.php#L1174 src]). There is a valid use case where a site requires a user role which has the capability to preview unpublished posts but not edit them, for example for editorial review/sign-off, layout review, early access, etc. You can [http://wordpress.stackexchange.com/a/196209/27051 get around this by using a combination of the posts_results and the_posts filters], but this isn't very future-proof because the post results skip a bunch of logic that occurs between those two filters. A `preview_post` meta capability and a `preview_posts` primitive capability could be introduced and implemented wherever the `edit_posts` capability is used in regard to previewing unpublished posts. By default, it will simply map to the `edit_posts` capability. Thoughts?",johnbillion Future Releases,39083,Introduce singular capabilities for managing individual themes,,Themes,,normal,normal,Future Release,enhancement,new,,2016-12-04T22:12:26Z,2017-07-14T19:41:15Z,"As we did in #35614 for taxonomy terms, singular capabilities should be introduced for switching, editing, deleting, and updating individual themes. This would allow fine-grained cap checks such as `current_user_can( 'switch_theme', $theme )` and `current_user_can( 'delete_theme', $theme )`.",johnbillion Future Releases,40676,"wpautop adds opening & closing p tags around the opening a tag and around the closing a tag when the link contains certain flow content elements like div, h1, h2...",,Formatting,4.8,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2017-05-05T10:55:47Z,2017-07-21T11:02:23Z,"Hi, == Description == wpautop leaves {{{}}} (opening tag of the link) in between {{{}}} tags and {{{}}} (closing tag of the link) in between {{{
}}} tags when the link contains certain flow content elements like div, h1, h2... == Example 1 == If I add this to the HTML editor: {{{"" [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 Future Releases,43421,The $capabilities argument in the `add_role()` function is incompatible with `user_can`,,Role/Capability,4.9.4,normal,normal,Awaiting Review,enhancement,reopened,,2018-02-26T17:19:26Z,2018-03-20T17:21:03Z,"Reproduce: Add a role to WP using `add_role()`, and pass it custom capabilities using the third argument. Like: {{{#!php add_cap($cap); } }}} And repeat testing, it returns true as expected. This has to do with how the caps are saved. The first way, when capabilities are retrieved in `WP_User::has_cap()`, they look like this: {{{#!php ""read"", [1]=> ""my_cap"", [""my_new_role""]=> bool(true) [""exist""]=> bool(true) } }}} And when done via `add_cap`, they look like this: {{{#!php bool(true) [""my_cap""]=> bool(true) [""my_new_role""]=> bool(true) [""exist""]=> bool(true) } }}} The subsequent `empty` array check is true for the first, and false for the second. ",eclev91 Future Releases,42404,Introduce singular capabilities for managing individual plugins,,Role/Capability,,normal,normal,Future Release,enhancement,new,has-patch,2017-11-01T22:11:24Z,2018-04-18T20:37:39Z,"In #38652, singular capabilities were added for activating and deactivating individual plugins. The same should be added for other management actions for plugins: * `edit_plugin` (ability to adit plugin via the Plugin Editor) * `delete_plugin` (ability to outright delete the plugin) * `update_plugin` (ability to update a plugin) Network activation and deactivation will be handled in #42403",johnbillion Future Releases,43752,"ID, post_parent, menu_order on global $post object is a string in edit context; expecting int",,"Posts, Post Types",4.9.5,normal,normal,Awaiting Review,defect (bug),new,,2018-04-12T23:34:08Z,2018-04-19T00:27:16Z,"When I'm on an edit post screen, the ID, post_parent, menu_order attributes on the global $post object are strings. I expect them to be integers. To quickly check, put this in a plugin: {{{#!php ID); }); }); }}} Here's what's happening: 1. in wp-admin/post.php the edit case happens, and within that the post gets reloaded here: https://github.com/WordPress/WordPress/blob/4.9.5/wp-admin/post.php#L167 2. that function will run the post object through its own filter with filter edit here: https://github.com/WordPress/WordPress/blob/4.9.5/wp-includes/post.php#L552 3. because at the time $this->filter = ""raw"", and the $filter is edit, that will run the object through sanitize_post here https://github.com/WordPress/WordPress/blob/4.9.5/wp-includes/class-wp-post.php#L354 4. sanitize_post will, in turn, run all the fields through sanitize_post_field here: https://github.com/WordPress/WordPress/blob/4.9.5/wp-includes/post.php#L1940 5. and even though we have 3 fields set as int (https://github.com/WordPress/WordPress/blob/4.9.5/wp-includes/post.php#L1973), by the time we get to this part (https://github.com/WordPress/WordPress/blob/4.9.5/wp-includes/post.php#L2027-L2034), those three will be ran through esc_attr 6. esc_attr will feed it through _wp_specialchars here https://github.com/WordPress/WordPress/blob/4.9.5/wp-includes/formatting.php#L3978 7. which begins with $string = (string) $string; here https://github.com/WordPress/WordPress/blob/4.9.5/wp-includes/formatting.php#L912 The part that throws me off is that `sanitize_post_field` declares these three properties to be integers at the beginning of the function, so I sort of expected them to come out as integers on the other end.",javorszky Future Releases,43818,Invalidate query caches less aggressively by using a `last_changed` key specific to metadata,,"Options, Meta APIs",,normal,normal,Awaiting Review,enhancement,new,,2018-04-20T08:13:55Z,2018-04-20T08:13:55Z,"Currently, the meta implementations for posts, terms, comments and sites (in multisite) invalidate all respective query caches when any value is changed (via setting the `last_changed` key). This is a really aggressive method of cache invalidation and causes in query caches being too frequently invalidated, resulting in lots of unnecessary cache misses. Most queries (or at least many queries) do not make use of meta queries, and those should stay unaffected by when a meta value changes. Therefore I suggest introducing a specific `meta_last_changed` cache key, and have the meta functions set that one instead of the generic `last_changed`. In the query classes, we can then check if a meta query is present, and only then make use of the `meta_last_changed` key - otherwise we can ignore it and use the regular `last_changed` key. Regarding the initial implementation, we should think about whether we would wanna roll this out to all the above object types immediately, or whether we should rather start with an object type less popular for metadata (i.e. ''not'' posts). Related to this is #43813.",flixos90 Future Releases,36273,update_attached_file() on Windows will result in invalid image path when using native Windows directory separators,,Media,4.4.2,normal,normal,Awaiting Review,defect (bug),new,,2016-03-18T10:48:16Z,2018-04-30T23:34:09Z,"Calling ''update_attached_file( $image->ID, $file );'' on platforms like Windows can be really bad if ''$file'' was normalized/validated using PHP's ''realpath()'' function: {{{#!php ID ); // Well, in real world you could have created the path manually... // The only important thing to know is, that we call ""realpath()"" which will // convert any directory separator into the native directory separator: // Linux will end with /dir/subdir/basename.jpg // Windows will end with C:\Dir\Subdir\basename.jpg $file = realpath( $file ); // Again, this is just a demo, for real world cases see plugins like ""Force Regenerate Thumbnails"" // But this is a valid API call: update_attached_file( $image->ID, $file ); // On Windows this will result in an update statement like // UPDATE `postmeta` SET `meta_value` = 'C:WWWSitesdemohtdocswordpresswp-contentuploads201603example.jpg' WHERE `post_id` = 123 AND `meta_key` = '_wp_attached_file' // when $file was set to ""C:\WWW\Sites\demo\htdocs\wordpress\wp-content\uploads\2016\03\example.jpg"" // Now imagine a plugin which is re-generating thumbnails :] // The problem is // $meta_value = wp_unslash($meta_value); // in wp-includes/meta.php update_metadata(). }}} When using ''update_attached_file()'' we should make sure that ''update_metadata()'' don't update the path value to an invalid value... PS: After you updated all image paths to an invalid value, the media library won't work anymore: {{{ [18-Mar-2016 07:31:10 UTC] PHP Warning: file_exists() expects parameter 1 to be a valid path, string given in C:\WWW\Sites\demo\htdocs\wordpress\wp-includes\media.php on line 3063 }}} ",Whissi Future Releases,37825,Introduce functions to check whether there are multiple taxonomy terms,,Themes,,normal,normal,Future Release,enhancement,new,has-patch,2016-08-25T12:33:10Z,2018-06-14T18:04:43Z,"We've had a function `is_multi_author()` since version 3.2.0, which is regularly used by themes to check if a site has multiple authors with published posts. A similar function is often needed by themes for taxonomies (mostly categories), for example the latest default themes have contained a function `*_categorized_blog()`. I think this functionality is essential for several themes, and we can make their lifes easier by providing these functions to them (especially since several theme authors don't really wanna mess with hooks for invalidating transients). Of course, for backward compatibility a theme should check whether that function exists, and if not, it still needs to take care of things by itself. However, I think this will still be a good solution long-term to include this functionality in WordPress Core.",flixos90 Future Releases,43880,Add functionality to add an anonymous user an get its ID for anonymization of data related to a WordPress user.,tz-media,Privacy,,normal,normal,Future Release,enhancement,assigned,dev-feedback,2018-04-27T14:05:28Z,2018-07-09T17:58:08Z,"When we need to anonymize data that is (or can be) associated with a WordPress user, we anonymize it by changing the user ID of that data to a user that represents anonymized content. But currently no such user exists, so we set the ID to 0. In order to display an actual user name (at least for posts), we would need an actual user 'Anonymous' that we can re-assign the content to. This might be created on WordPress install by default (maybe even with a User ID of `0` that we can then hardcode into the anonymized functions), or by calling a function like `_wp_privacy_get_anonymous_user_id()` that creates the user if not already created and returns the user ID (that might be stored in a site_option).",TZ Media Future Releases,15332,dbDelta($query) - do not create view,,Database,3.0.1,normal,normal,Future Release,feature request,reopened,has-patch,2010-11-07T14:23:52Z,2018-07-30T08:45:42Z,"during plugin creation I create few tables with dbDelta($query). that is working without problems. But on the end I create two views on this tables with dbDelta($query) - that is not working. The views are not created. The sql is ok, manually the create works.",christian_gnoth Future Releases,40588,Trashing and restoring a draft post replaces the slug,,"Posts, Post Types",4.5,normal,normal,Awaiting Review,defect (bug),new,,2017-04-27T20:39:43Z,2018-07-31T14:57:32Z,"Using the latest version of WordPress, if you create a draft post with a slug, lets say 'test-post', then trash it and restore it, the slug becomes {{{__trashed-xxx}}}, where xxx is a number Related to https://core.trac.wordpress.org/ticket/11863",TJNowell Future Releases,44899,redirect_canonical redirects to another URL when it should not,,Canonical,4.9.8,normal,critical,Awaiting Review,defect (bug),new,,2018-09-05T14:34:56Z,2018-09-06T07:32:25Z,"Hi, on a fresh install of WordPress 4.9.8 : http://sub.yourdomain.com/?xtor=AD-4970-%5BSocial%5D-%5B%5D-%5BPPL%5D-%5BFacebook%5D-%5B228284160&105478095%5D-%5B0%5D will be redirected to : http://sub.yourdomain.com/?xtor=AD-4970-%5BSocial%5D-%5B%5D-%5BPPL%5D-%5BFacebook%5D-%5B228284160&105478095]-%5B0%5D Problem is : it does an 301. And, combined with Facebook mobile on Iphone link to the WordPress, it retries forever. 21 000 hits / 5 minutes on our server. Glad it was strong enough to sustain until we find the bug and temporarily deactivated {{{ redirect_canonical }}} with : {{{#!php set_permalink_structure( ... )` in the test suite. The majority of these calls are present simply to enable pretty permalinks, regardless of the permastructure for posts. Pretty permalinks should be enabled by default for the test suite. Let's try it and see if anything breaks.",johnbillion Future Releases,45140,REST API: Increase upper bound allowed on per_page argument,,REST API,,normal,normal,Future Release,enhancement,new,,2018-10-21T17:16:19Z,2018-10-31T11:38:29Z,"In contexts where a REST API client needs to fetch ''all'' entries for a resource, it would be more practical to fetch entries in sets of 200, 300, or 400, instead of sets of 100. Fetching entries in sets of 100 can cause excessive memory usage because WordPress is loaded over and over again. Increasing the limit will provide a better balance between memory consumption in a single request vs. total memory consumption across all requests. The original `per_page=100` limit was [https://github.com/WP-API/WP-API/issues/1609#issuecomment-177169125 somewhat arbitrary]; if I recall correctly, we picked `100` as a nice round number that was reasonably certain not to cause performance issues. Before we pick `per_page=200` vs. `per_page=300` vs. `per_page=400`, we should: 1. Profile memory consumption of each. 2. Identify what amount of memory we can reasonably expect on shared hosting these days. After we've done this, we can pick the best available option. Notably, we can't go above `500` as we'll hit `split_the_query` which has negative performance implications. Previously https://github.com/WordPress/gutenberg/issues/6694",danielbachhuber Future Releases,34972,Permalink for unattached media same as a post,,Permalinks,4.4,normal,normal,Future Release,defect (bug),new,,2015-12-10T11:53:16Z,2018-12-17T21:55:36Z,"First step - upload media ""tralala.jpg"" I got pretty link example.com/tralala/ Second step - create a post with Title ""Tralala"" it creates post with slug example.com/tralala/ this works. So post with the same title as unattached media filename creates the same permalink - slug as already exists for unattached media. In this case, unattached media is unreachable as permalink point to new post with the same slug.",petercralen Future Releases,44847,Redirect old date-based permalinks on structure changes,,Permalinks,,normal,normal,Awaiting Review,defect (bug),new,,2018-08-27T13:43:48Z,2019-01-08T07:14:12Z,"If someone switches from `/%year%/%monthnum%/%day%/%postname%/` to `/%postname%/`: * `/%year%/%postname%/` redirects to the correct URL. * `/%year%/%monthnum%/%postname%/` shows a 404 error. * `/%year%/%monthnum%/%day%/%postname%/` shows a 404 error. All of these URLs should redirect to the correct one.",SergeyBiryukov Future Releases,42278,Speed up tests by using shared user fixtures,,Build/Test Tools,,normal,normal,Future Release,enhancement,new,dev-feedback,2017-10-19T09:09:44Z,2019-01-08T10:13:51Z,"There are a lot of tests that require user fixtures. These are then created, and afterwards deleted, as part of the test class set up and tear down methods. These fixtures could all be reused between tests, if a user for every role in Core would be created in the database as part of the unit test setup process. If we had that, all the tests that need for example a user with the `editor` role could just grab the existing user from the database, instead of creating this as a test fixture.",Frank Klein Future Releases,43588,Anonymize commenter IP address once a comment is no longer pending,,Privacy,,normal,normal,Awaiting Review,enhancement,new,,2018-03-20T19:06:12Z,2019-01-09T19:17:26Z,"A commenter's IP address is stored with each comment. The commenters IP address can often be used to identify a single individual or device at a location. To enhance commentor's privacy, and to reduce the amount of personal data stored by a WordPress site in preparation for upcoming laws like the GDPR, this issue proposes that once a comment transitions out of pending, core WordPress should zero the commentor's IP address final octet similar to how Google Analytics Anonymizes IP addresses The rationale for keeping it while a comment is pending is to continue to allow anti-spam access to the IP address which can be used to detect spam. The rationale for keeping all but the last octet is to still allow statistics to be gathered about the general geographic location of commenters based on the first three octets of the IP address.",allendav Future Releases,36376,current_user_can/has_cap fails when user has multiple roles,dd32*,Role/Capability,,normal,normal,Future Release,defect (bug),accepted,dev-feedback,2016-03-30T17:16:45Z,2019-01-14T04:46:21Z,"To replicate the issue, install a role editor. Setup a user with primary role 'author' and secondary role 'customer' (this is a WooCommerce role which has ONLY 'read' access, nothing else). https://dl.dropboxusercontent.com/s/xgucqvvh6no3skm/2016-03-30%20at%2017.49.png?dl=0 You can add a role with only: {{{#!php 'read' => true }}} permissions if you don't have WooCommerce installed. Dump: {{{#!php current_user_can( 'edit_posts' ) }}} It will be false. During get_role_caps() in class-wp-user.php, each role is retrieved and merged. The merge itself doesn't look at values, so if multiple roles have the same 'cap' but different value, these overwrite each other. In my case, edit_posts was true for the author role, but false for customer role. Customer role false overwrote author role true. Since caps only allow access to things if 'true', I think we can safely discard all 'false' caps when getting roles. If false caps are discarded, only true caps are left which works around the issue and fixes user capabilities if they have multiple roles at once. Fix to follow (added array_filter to discard all 'false' caps, allowing us to merge only 'true' caps). Had this reported to us in https://github.com/woothemes/woocommerce/issues/10612#issuecomment-203518038 but wasn't a WooCommerce issue. ",mikejolley Future Releases,43274,Changing $(comments|feed)_base of WP_Rewrite causes errors because of hardcoded strings in redirect_canonical(),,Canonical,,normal,normal,Future Release,defect (bug),new,has-patch,2018-02-09T21:11:37Z,2019-01-14T22:41:57Z,"When you change `$comments_base`/`$feed_base` for `WP_Rewrite` instance, URLs with that base will not work because `comments` and `feed` strings are hardcoded in a few places in `redirect_canonical()`. Changing these to use `$wp_rewrite->comments_base` and `$wp_rewrite->feed_base` respectively will fix this issue. NOTE: When testing feed URLs, changing `feed` with `feed_base` in `example.com/feed/` will not work. Feed URLs work in two places: `example.com/(feed|rss2?|rdf|atom)` and `example.com/feed_base/(feed|rss2?|rdf|atom)` ([https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-wp-rewrite.php?rev=42343#L860 see rules]). When you open `example.com/feed/` you match first rule where `feed` is type of feed. You need second rule to test it. There is quick workaround though: {{{#!php add_action( 'after_setup_theme', function() { $GLOBALS['wp_rewrite']->feed_base = 'mycustomfeedbase'; $GLOBALS['wp_rewrite']->feeds[] = 'mycustomfeedbase'; } ); add_action( 'parse_query', function( $q ) { if ( $GLOBALS['wp_rewrite']->feed_base == $q->get( 'feed' ) ) { $q->set( 'feed', 'feed' ); } } ); }}} Don't forget to flush rewrite rules.",dimadin Future Releases,45389,trackback_url_list() trackback excerpt for multibyte correspondence,SergeyBiryukov,Pings/Trackbacks,,normal,normal,Future Release,defect (bug),reviewing,dev-feedback,2018-11-21T08:15:18Z,2019-01-16T02:57:17Z,"In the case of multibyte, the last letter of the trackback excerpt may be garbled.",ishitaka Future Releases,42183,wp_update_user() conditional compares a plain-text password to the hashed old,SergeyBiryukov,Users,4.5.2,normal,normal,Future Release,defect (bug),reviewing,dev-feedback,2017-10-11T14:20:02Z,2019-01-16T03:25:00Z,"In file wp-includes/user.php, function [https://developer.wordpress.org/reference/functions/wp_update_user/ wp_update_user()] On line 1767: {{{ if ( ! empty( $userdata['user_pass'] ) && $userdata['user_pass'] !== $user_obj->user_pass) }}} The second conditional is comparing a plain-text password to a hashed version of password, so this would almost always evaluate to true except for the case where the new password itself matches the old hashed password. This block will then evaluate to false and therefore password itself won't be updated. It's a rare case but the logic here is incorrect. And obviously this code block would run when passwords are the same since it's comparing plain-text to the hashed version.",yudge Future Releases,43571,`add_feed` with regex characters breaks rewrite rules,SergeyBiryukov,Rewrite Rules,,normal,normal,Future Release,defect (bug),reviewing,has-patch,2018-03-18T17:44:20Z,2019-01-16T03:54:36Z,"`add_rule( 'test.json', ... )` does not get escaped with `preg_quote`. Fine for this example, but something like `add_rule( 'test[json]', ... )` will definitely yield unexpected results. Something like `add_rule( 'test???', ... )` will break the whole feed (maybe even more) regular expression.",soulseekah Future Releases,43746,Custom post type single post feed returns a 404 if has_archive is set to false when calling register_post_type(),SergeyBiryukov,Rewrite Rules,4.9.5,normal,normal,Future Release,defect (bug),reviewing,dev-feedback,2018-04-12T13:58:17Z,2019-01-16T03:58:48Z,"When using {{{register_post_type()}}}, the single post feed returns a 404 if {{{has_archive}}} is set to false. This seems to happen regardless of the value of {{{feeds}}} in the {{{rewrite}}} array. For example: {{{ register_post_type( 'example', array( 'rewrite' => array( 'slug' => 'my-custom-post-type', 'feeds' => true ), 'has_archive' => false ) ); }}} {{{ $ curl -IL https://example.com/my-custom-post-type/some-text/feed/ HTTP/1.1 404 Not Found }}} I'd expect a feed for the post to be built if {{{feeds}}} is set to {{{true}}}. Note I have flushed permalinks.",henry.wright Future Releases,45498,Wrong order of arguments in call_user_func() for Walker_Comment::start_el(),SergeyBiryukov,Comments,,normal,normal,Future Release,defect (bug),reviewing,has-patch,2018-12-06T16:52:14Z,2019-01-16T05:46:01Z,"Arguments order for rendering all types of comments is `$comment, $depth, $args` except for the custom callback: `call_user_func( $args['callback'], $comment, $args, $depth );` This causes every custom callback to throw an error when you use `$args` and `$depth` as you'd expect. For example, `comment_reply_link()` inside callback can not be used like it's suppose to be used, like so: {{{#!php 'div-comment', 'depth' => $depth, 'max_depth' => $args['max_depth'], 'before' => '`, but the corresponding opening and closing tags won't exist. For example, `
b
a
\nb
\nGet Flash 9.0 to see this player.
` tags into my post. It should either insert correctly closed tags, or none at all. I honestly would prefer the former. In detail: I had HTML code very similar to this: {{{
more text
` tag in the above, which is unclosed (making the W3C validator choke on my website). Also note, I was not using the WYSIWYG editor (turning it off was the first thing I did), so it's unlikely to be due to that. As a workaround, manually inserting properly closed `
` tags works just fine: {{{
more text