__group__ ticket summary owner component _version priority severity milestone type _status workflow _created modified _description _reporter Future Releases 16980 Empty Values are ignored by class-ixr.php XML-RPC 3.1 normal normal Future Release defect (bug) assigned 2011-03-27T12:34:47Z 2020-09-30T18:41:01Z "I tried to fix the following bug #10599 Found out when you send and empty value via xmlrpc it converts it to null value. Say you send and array of arguments for mw_editpost, set {{{ $content_struct[mt_keywords] = ''; }}} IXR client passes a null value instead of an empty value. In mw_post method consider this statement {{{ $tags_input = isset( $content_struct[mt_keywords] ) ? $content_struct[mt_keywords] : null; }}} Even if you send an empty value this statement fails because {{{ $content_struct[mt_keywords] }}} is set to null by IXR client." nprasath002 Future Releases 36030 Expose site icon on wp.getUsersBlogs XML-RPC normal normal Future Release enhancement new dev-feedback 2016-03-01T09:06:46Z 2019-06-20T14:07:35Z "WordPress 4.3 has added the ability for site owners to manage their site’s favicon, but never exposed it over the XML-RPC protocol. It's useful for XML-RPC clients to receive it back in the response of wp.getUsersBlogs, so they can show the proper icon beside the name of the site. In the patch I've provided an empty value is returned if site_icon is not set on the blog. I've avoided returning a default value, since it's better to leave this responsibility to clients. If siteIcon is empty, the client should show their default icon, or nothing." daniloercoli 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 31020 Introduce discrete capability for managing widgets johnbillion Widgets normal normal Future Release enhancement assigned dev-feedback 2015-01-15T07:11:15Z 2022-01-30T16:44:08Z "As with management of nav menus (#29213), managing widgets currently requires `edit_theme_options` capability, a capability associated with administrators which grants the power to make many wide sweeping changes. There should be a discrete capability `manage_widgets` just for managing widgets, one that is inherited for anyone who has `edit_theme_options` by default. This was done for Customizer access in #28605 with the introduction of a `customize` capability. Originally brought up in #14386. The same is proposed for menus in #29213." westonruter Future Releases 53771 What about an equivalent of `is_active_widget()` for Widget Blocks ? Widgets 5.8 normal normal Future Release enhancement new has-patch 2021-07-24T13:13:26Z 2021-07-29T17:06:25Z "This doesn't seem to exist in WordPress Core and I haven't found a ticket asking about this. (I hope I haven't missed one, sorry if I did). `is_active_widget()` can't be used because all Block are added into the same Widget: `WP_Widget_Block`. For BuddyPress when migrating our Legacy Widgets to Widget Blocks, I had 2 cases where some output wasn't made if a widget was active into a sidebar (Sitewide notice, and BP Primary Nav). To satisfy our need we are using [https://buddypress.trac.wordpress.org/browser/tags/9.0.0/src/bp-core/bp-core-template.php#L3869 this function] to check if a block or a widget is active into a Sidebar Widgets. I thought maybe it can be interested to have an equivalent of `is_active_widget()` into WordPress. I quickly put up a patch about it." imath Future Releases 42549 Widgets: Allow gallery widget to display images from currently-queried singular post if no images selected audrasjb Widgets 4.9 normal normal Future Release enhancement assigned has-patch 2017-11-14T18:22:48Z 2020-02-05T00:49:17Z In #42548 (pending) a `[gallery]` placed inside of a Text widget will result in the attachments for a given post to be used in the gallery when the widget appears on a singular template. The same behavior could be allowed for the Gallery widget as well. If you add a gallery widget to a sidebar but don't add any images to it, the widget could conditionally show if it is being rendered on a singular template for a post that has image attachments. westonruter Future Releases 29319 filter dayswithposts in widget calendar SergeyBiryukov Widgets 3.0 normal normal Future Release enhancement reviewing has-patch 2014-08-22T14:28:53Z 2020-10-20T04:57:51Z "Hello here is Konrad, WPML developer. We are fighting now with bug related WordPress calendar widget: it always displays all posts, and we want to filter its results regarding to language of post. Steps to reproduce: 1. install WPML 2. publish some post in En language July 1st 3. translate this post July 2nd to Polish language 4. activate calendar widget Result: calendar will show that there are posts in July 1st and 2nd. Expected result: when user displays English posts, calendar should display only July 1st. When user switches to Polish language, calndar should display only July 2nd. We want to fix this in WPML but we need filter inside of get_calendar() function. Wordpress gets days with posts by this query inside of get_calendar(): {{{ $dayswithposts = $wpdb->get_results(""SELECT DISTINCT DAYOFMONTH(post_date) FROM $wpdb->posts WHERE post_date >= '{$thisyear}-{$thismonth}-01 00:00:00' AND post_type = 'post' AND post_status = 'publish' AND post_date <= '{$thisyear}-{$thismonth}-{$last_day} 23:59:59'"", ARRAY_N); }}} The result should be able to filter, then WPML will hook here. I am attaching proposed diff file. (I see that we can hook into get_calendar filter but this variable has full html output of calendar. This will unefficient to parse this HTML) " kkarpieszuk Future Releases 49588 "Cannot remove
" Widgets normal minor Awaiting Review feature request new has-patch 2020-03-06T18:02:23Z 2020-03-07T19:52:07Z "I cannot remove wrapping class in html widget:
...
It is defined here: https://github.com/WordPress/WordPress/blob/master/wp-includes/widgets/class-wp-widget-custom-html.php I think it is job for some `apply_filters`. Do we really need another `
` wrap? There can be `
` wrap added by `register_sidebar` or using `widget_text` filter" jasom Future Releases 11160 Inconsistancies in Naming and Using Sidebar Names and IDs. azaozz Widgets 2.9 normal normal defect (bug) new 2009-11-17T12:58:55Z 2019-06-05T06:37:18Z "register_sidebar() allows more sidebar names and IDs to be registered than dynamic_sidebar() recognizes as valid names and IDs. For example, register_sidebar() allows me to name a side bar ""1"" with a id of ""first"". I don't know why anyone would choose those values, but register_sidebar() allows it [1]. {{{ register_sidebar( array('name' => 1, id => 'first') ); }}} dynamic_sidebar() will not be able to find the sidebar given its name (1). {{{ if ( is_int($index) ) { $index = ""sidebar-$index""; /// 1 becomes 'sidebar-1' ... }}} The main problem is that dynamic_sidebar() is trying to process both IDs and names through the same variable ($index) while register_sidebar() separates the two with an array ( array('name' => 'Top', 'id' => 'sidebar-1' ). According to the in-line docs for dynamic_sidebar(): It is confusing for the $index parameter, but just know that it should just work. When you register the sidebar in the theme, you will use the same name for this function or ""Pay no heed to the man behind the curtain."" Just accept it as an oddity of WordPress sidebar register and display. It does ""just work"" if you never use your own sidebar IDs. I started looking at this because I wanted to use is_active_sidebar() which tests to see if a dynamic_sidebar() has anything in it. There is no get_dynamic_sidebar(). dynamic_sidebar() sends everything to the browser or returns false. {{{ register_sidebar( array('name' => 'Top') ); // id defaults to ""sidebar-1"" ... if ( is_active_sidebar('Top') ) dynamic_sidebar('Top'); }}} Which fails because is_active_sidebar() just completely skips over searching for an id to go with a name. To get it to work you need to know when it was registered. Not something theme authors and designers are going to follow easily. There's a ticket to fix this: [http://core.trac.wordpress.org/ticket/10440 #10440] {{{ if ( is_active_sidebar(1) ) dynamic_sidebar('Top'); }}} Like dynamic_sidebar(), is_active_sidebar() converts 1 to ""sidebar-1"". Unlike dynamic_sidebar() it assumes everything is entered as an id. unregister_sidebar() assumes its parameter (incorrectly named $name, not $id) is an id. But it wants a literal id, like ""sidebar-1"". unregister_sidebar(1) unregisters a sidebar with an id of 1, while dynamic_sidebar(1) tries to display a sidebar with an id of ""sidebar-1"". === Widgets (Admin Page) === The dynamic_sidebar() function is used by the Widgets management page. So, it is possible to create a sidebar with register_sidebar() that dynamic_sidebar() cannot find. You can populate it with drag and drop [2] and not have it appear on the web site. == After Patch == If committed, this patch would remove the need for tickets [http://core.trac.wordpress.org/ticket/10440 #10440] and [http://core.trac.wordpress.org/ticket/10956 #10956]. It changes the current argument behavior of unregister_sidebar(), but doesn't break backward compatibility. It allows is_active_sidebar(), unregister_sidebar() and dynamic_sidebar() all point to the same sidebar. === Before === These all refer to the same sidebar: {{{ is_active_sidebar(1); unregister_sidebar('sidebar-1'); dynamic_sidebar('Sidebar Top'); }}} In an admittedly contrived case, dynamic_sidebar() would silently fail to allow this sidebar to show: {{{ register_sidebar( array('name'=>'Sidebar Top', 'id' => 1) ); }}} === After === These all refer to the same sidebar (the first two would have broken before the patch): {{{ is_active_sidebar('Sidebar Top'); unregister_sidebar('Sidebar Top'); dynamic_sidebar('Sidebar Top'); }}} After the patch this shows fine: {{{ register_sidebar( array('name'=>'Sidebar Top', 'id' => 1) ); }}} After the patch it is possible to force an argument to be only a name or only an id: {{{ is_active_sidebar(array( 'name' => 'Sidebar Top' )); unregister_sidebar(array( 'name' => 'Sidebar Top' )); dynamic_sidebar(array( 'id' => 1 )); }}} === Notes === [1] register_sidebar() allows the user to override the default setting of: 'id' => ""sidebar-$i"", [2] When you refresh the Widgets management page the widgets will disappear from the sidebar. They are still attached to a sidebar, but dynamic_sidebar() cannot see the sidebar." CharlesClarkson Future Releases 23423 sanitize_title() in dynamic_sidebar() restricts the use of specific characters for sidebar IDs chriscct7 Widgets 2.2 normal normal defect (bug) reopened 2013-02-08T13:25:00Z 2019-06-05T06:39:05Z "In the dynamic_sidebar() function in wp-includes/widgets.php uses sanitize_title() on the given index when it looks for a sidebar with a name that matches the index. After that it leaves the index value sanitized making it impossible to use characters not allowed by sanitize_title() in a sidebar ID. By not overwriting the given index value with the sanitized version it would still be possible to use any character for the ID. To achieve this, lines 847-853 {{{ $index = sanitize_title($index); foreach ( (array) $wp_registered_sidebars as $key => $value ) { if ( sanitize_title($value['name']) == $index ) { $index = $key; break; } } }}} should be replaced with {{{ $sanitized_index = sanitize_title($index); foreach ( (array) $wp_registered_sidebars as $key => $value ) { if ( sanitize_title($value['name']) == $sanitized_index ) { $index = $key; break; } } }}}" paulvandermeijs Future Releases 33915 Add a filter in dynamic_sidebar() function to modify sidebar index Widgets 4.3 normal normal enhancement new has-patch 2015-09-17T15:04:28Z 2019-06-05T06:41:40Z Changing sidebars depending on the page/post/etc loaded through a plugin. Nothing too complex, just no way to do it. There is a filter dynamic_sidebar_params but that isn't called until later on in the function after the widgets have been collected for that sidebar. fahidjavid Future Releases 34093 New filter: `get_calendar_post_type` in get_calendar() Widgets normal normal enhancement new has-patch 2015-09-30T06:19:27Z 2023-05-17T05:47:36Z Filter for post type in calendar. If I want show posts from others post type sebastian.pisula Future Releases 60299 Default assignment of `use_ssl` user meta value causes unnecessary DB write. Users normal normal 6.6 defect (bug) new has-patch 2024-01-19T15:14:18Z 2024-02-19T17:35:21Z "When the `$meta` in `wp_insert_user()` is processed using `update_metadata()` it first does a comparison against the current values in the database prior to running an update query. However, because the DB returns a string value ('1' or '0') while the meta_value is set to a boolean value by default the comparison always fails causing a write when not needed. While this is relatively minor in itself, in multi-datacenter setups using hyperdb, this can cause a bit of overhead since all future reads to the usermeta table are then sent to the master database." prettyboymp Future Releases 16293 In multisite installs, users with id 1 can't be deleted Users normal normal Future Release defect (bug) reopened dev-feedback 2011-01-19T00:21:34Z 2024-02-08T20:18:09Z "You can't delete a user with user id of 1. See: source:trunk/wp-admin/network/edit.php@17326#L359" PeteMall Future Releases 40477 REST API: Does NOT Trigger New User Notifications! Users 4.7 normal normal Awaiting Review defect (bug) new dev-feedback 2017-04-19T07:35:19Z 2017-12-04T05:11:43Z "If you create new users with WP REST API. The notification for new WordPress users via email does NOT get triggered. I tried it on a fresh install. Used the [Email log](https://wordpress.org/plugins/email-log/) WP plugin to test that no emails were sent. " mrahmadawais Future Releases 50072 Users with email addresses containing a single quote cannot reset their passwords Users 5.4 normal major Awaiting Review defect (bug) new 2020-05-04T09:28:31Z 2020-05-05T11:27:55Z "I just found that users with a single quote in their email addresses cannot reset their passwords. This happens because there is a difference in the email addresses compared by the wp_insert_user() function. Take a look at this example. I have a user with an email address equal to **daniel.o'brian@gmail.com** When he tries to reset his password, he receives the reset key, but his activation key is not stored in the database. Looking at lines 1805-1808 of the file users.php I found the problem: {{{ if ( $update ) { if ( $user_email !== $old_user_data->user_email || $user_pass !== $old_user_data->user_pass ) { $data['user_activation_key'] = ''; } }}} In the above code the variable $user_email is **daniel.o'brian@gmail.com**, but the $old_user_data->user_email is escaped and appears to be **daniel.o\'brian@gmail.com**, so there isn't the match and user activation key is cleared. Can you confirm and provide a fix? In the meantime, I can change this behavior by escaping the $user_email myself in the filter wp_pre_insert_user_data which is a few lines above the checking, I guess. Thanks!" daniele.perilli Future Releases 38851 WP_User_Query cannot retrieve multisite users who have not been assigned a role on a site Users normal normal Future Release defect (bug) new 2016-11-18T15:11:32Z 2017-12-01T05:20:30Z "If you add a user to a multisite at network level, but do not proceed to assign them a role on a site within the network, `WP_User_Query` cannot retrieve those users (even if the query is run at network level), as they have no associated `wp_capabilities` meta_key. To reproduce the problem: 1) Add a user to a multisite via Network Admin > Users > Add New. 2) Run a WP_User_Query at network level (e.g. by doing something like: {{{ add_action('load-users.php', 'myAction'); function myAction() { $screen = get_current_screen(); if( $screen->base === 'users-network' { $query = new WP_User_Query(); $users = $query->results; } } }}} The returned results will not include the user added in step 1. In fact, it will only return users who have capabilities set on the first site in the network, even though this query is not occurring at site level. This could be fixed by allowing something like `'blog_id' => 'all'` in a `WP_User_Query`." robdxw Future Releases 54310 WP_User_Query does not return results in the same format if fields set to all_with_meta and doesn't return any metadata Users normal normal Awaiting Review defect (bug) new 2021-10-22T17:54:26Z 2021-10-25T23:32:25Z "Digging into WP_User_Query if you set the fields to all_with_meta it returns an array index by the user_ID veers a keyed list for all other results this is the {{{ if ( 'all_with_meta' === $qv['fields'] ) { cache_users( $this->results ); $r = array(); foreach ( $this->results as $userid ) { $r[ $userid ] = new WP_User( $userid, '', $qv['blog_id'] ); } $this->results = $r; } elseif ( 'all' === $qv['fields'] ) { foreach ( $this->results as $key => $user ) { $this->results[ $key ] = new WP_User( $user, '', $qv['blog_id'] ); } } }}} I feel we should return the same shape array for both so propose to set the all to array index to the User_ID's with a change like this {{{ if ( 'all_with_meta' === $qv['fields'] ) { cache_users( $this->results ); $r = array(); foreach ( $this->results as $userid ) { $r[ $userid ] = new WP_User( $userid, '', $qv['blog_id'] ); } $this->results = $r; } elseif ( 'all' === $qv['fields'] ) { foreach ( $this->results as $user ) { $this->results[ $user->ID ] = new WP_User( $user, '', $qv['blog_id'] ); } } }}} And better still it doesn't return the meta values !!! So let's add this as well {{{ if ( 'all_with_meta' === $qv['fields'] ) { cache_users( $this->results ); $r = array(); foreach ( $this->results as $userid ) { $r[ $userid ] = new WP_User( $userid, '', $qv['blog_id'] ); $r[ $userid ]->meta = get_user_meta( $userid ); } $this->results = $r; } elseif ( 'all' === $qv['fields'] ) { foreach ( $this->results as $key => $user ) { $this->results[ $key ] = new WP_User( $user, '', $qv['blog_id'] ); } } }}} " pbearne 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 39370 wp_insert_user() appends suffix to nicename when updating already existing user Users 4.6.1 normal normal Future Release defect (bug) new reporter-feedback 2016-12-22T14:11:21Z 2020-03-12T02:58:27Z "wp_insert_user() appends suffix to nicename when updating already existing user, even though the user_nicename prop is set to exactly the same value as it currently has. Steps to reproduce: - Asuming you have a user in your wordpress database with the ID 1 and user_nicename set to 'test-nicename'. - If you then make an update using wp_insert_user() of that user and in the update set the user_nicename to 'test-nicename', then wordpress will update the user, but append -2 as a suffix to the nicename. This happens because of a check located on line 1597 - 1609 in wp-includes/user.php {{{#!php get_var( $wpdb->prepare(""SELECT ID FROM $wpdb->users WHERE user_nicename = %s AND user_login != %s LIMIT 1"" , $user_nicename, $user_login)); if ( $user_nicename_check) { $suffix = 2; while ($user_nicename_check) { // user_nicename allows 50 chars. Subtract one for a hyphen, plus the length of the suffix. $base_length = 49 - mb_strlen( $suffix ); $alt_user_nicename = mb_substr( $user_nicename, 0, $base_length ) . ""-$suffix""; $user_nicename_check = $wpdb->get_var( $wpdb->prepare(""SELECT ID FROM $wpdb->users WHERE user_nicename = %s AND user_login != %s LIMIT 1"" , $alt_user_nicename, $user_login)); $suffix++; } $user_nicename = $alt_user_nicename; } }}} This code is there to make sure that there are no duplicate nicenames in the wp_users table, which is fine. However it does not take into account updating the nicename of a user with the same value as it currently has. The way to solve it is very easy, only simply changes the if() statement to check the id fethced in $user_nicename_check against the ID of the user currently being updated, like so: {{{#!php get_var( $wpdb->prepare(""SELECT ID FROM $wpdb->users WHERE user_nicename = %s AND user_login != %s LIMIT 1"" , $user_nicename, $user_login)); if ( $user_nicename_check && $ID != $user_nicename_check) { $suffix = 2; while ($user_nicename_check) { // user_nicename allows 50 chars. Subtract one for a hyphen, plus the length of the suffix. $base_length = 49 - mb_strlen( $suffix ); $alt_user_nicename = mb_substr( $user_nicename, 0, $base_length ) . ""-$suffix""; $user_nicename_check = $wpdb->get_var( $wpdb->prepare(""SELECT ID FROM $wpdb->users WHERE user_nicename = %s AND user_login != %s LIMIT 1"" , $alt_user_nicename, $user_login)); $suffix++; } $user_nicename = $alt_user_nicename; } }}} This makes prevents the code from appending the suffix when the $user_nicename_check ID matches the ID of the user currently being updated " alfhen 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 39242 Add caching to count_user_posts() whyisjake* Users 3.0 normal normal Future Release enhancement accepted dev-feedback 2016-12-11T23:24:32Z 2023-01-17T18:46:29Z "The `count_user_posts()` function does not cache the results of its query. On the surface, this seems easy enough, but since it accepts multiple parameters and intersects with page/post editing, it starts to get complex quickly as authors change, posts are transitioned from public to private, and custom post types do more elaborate things. Since some themes use this directly (Twenty Fourteen, et al) and the REST API exposes this data too, there's at least a small win from not hitting the database for each and every check. Eventually, `count_many_users_posts()` may be able to check for cached counts for existing users, and only query for (and prime the caches of) users who do not already have cached counts." johnjamesjacoby Future Releases 42326 Allow for user deletion in multisite Users 3.0 normal normal Awaiting Review enhancement new dev-feedback 2017-10-24T18:30:56Z 2017-10-24T21:19:24Z When multisite is enabled, it is impossible to completely delete user a user. A user is only removed from a site. However, if a user is has no sites on the network, then it should be safe to remove them. spacedmonkey Future Releases 39123 Allow usernames to be changed by administrators Users normal normal Awaiting Review enhancement new dev-feedback 2016-12-06T21:25:53Z 2017-11-21T17:13:11Z "Usernames cannot be changed. I'd like to propose that users who have the `edit_users` capability (administrators on single site installations, and super admins on multisite installations) are given the ability to update a user's username from their profile editing screen. The historical reason for disallowing changes to usernames is not clear, but it's most likely related to the generation of the `user_nicename` field which ideally needs to remain persistent so author archives don't 404. However, this can be addressed in the same way as changes to post slugs, where a user's old usernames and nicenames are recorded in usermeta when their username is updated (and their nicename is regenerated) and a canonical redirect can kick in to redirect to the new author archive URL. Any other considerations to make if usernames are allowed to be changed by administrators?" johnbillion Future Releases 34316 User status inconsistent between single-site & multisite Users 1.5 normal normal Awaiting Review enhancement new dev-feedback 2015-10-15T19:00:15Z 2017-09-27T15:30:10Z "The way a user's status is defined in WordPress differs between single-site and multisite: * In single-site, the `user_status` column is used * In multisite, there are two additional columns for `spam` and `deleted` Not only this, but the `update_user_status()` function is multisite only, and the `user_status` column is an integer without an API to help announce what values equate to what results. On the plus side, user statuses aren't really ever used in core. Marking users as spammers in multisite installations is the only real benefit of this feature as it exists today. I'd like to propose the following: * Stop creating the the `spam` and `deleted` columns in `wp_users` on new installations * ALTER the `user_status` column from `INT(11)` to `VARCHAR(20)` ala `wp_posts` * A bevy of `wp_register_user_status()` like functions to introduce bonafide support for them * A database upgrade routine to move user status `0` to `active` and `1` to `spammer` * A new index on the `wp_users` table for the updated `user_status` column type. We may need a few, based on how users are commonly queried in core, BuddyPress, etc... * Update the `WP_User` and `WP_User_Query` classes to suss out any `user_status` inconsistencies A few considerations worth noting: * Large installations would need to manually perform these DB upgrades. I'm embarrassed to say I've personally frozen WordPress.org for several minutes years ago by missing a `DO_NOT_UPGRADE_GLOBAL_TABLES` check on the `wp_users` table * Several plugins use their own values in the `users_status` column, assuming their numeric ID is unique and special. The authors of these plugins would need notifying, and their code updating to support the above ideas * This work *could* parlay into the Post Status API that's on infinite back-burner. There are some really excellent ideas floating around about how `post_status` could work that would translate nicely to users, too" johnjamesjacoby Future Releases 44347 WP allows creating username that is already used email address Users normal normal Awaiting Review enhancement new dev-feedback 2018-06-10T22:43:02Z 2019-03-02T02:03:26Z "As reported in Support Forum (https://wordpress.org/support/topic/wp-allows-creating-username-that-is-already-used-email-address/) it seems I can create a user with wp_create_user where the user's ""username"" is set as a value that is an existing Email Address for another user in the WordPress system. (I have not submitted a bug here before, so let me know if more info is needed on this and what to do next)." phillipburger Future Releases 31772 Browser unresponsive with long password Users 3.7 normal normal defect (bug) new has-patch 2015-03-26T00:47:25Z 2019-06-05T06:40:45Z "== Steps to reproduce 1. Login 1. Navigate to profile 1. Click in the text input for ""New Password"" 1. Paste in a long password * E.g. 600 characters: {{{ 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 }}} 1. Press the ""tab"" key - **Expected behaviour**: - The cursor moves to the ""Repeat New Password"" field. - ""Strength indicator"" changes to ""Strong"" or ""Weak"" (probably should be ""weak""). - **Actual behaviour**: - The cursor does not move. - The cursor stops blinking. - ""Strength indicator"" does not change. - The browser is not responsive. - After several seconds or a minute, the cursor eventually starts blinking, moves to the ""Repeat New Password"" field and the strength indicator changes to ""Strong"" (probably should be ""weak""). 1. Press the ""shift+tab"" keys - **Expected behaviour**: The focus moves to the ""New Password"" field and its content is selected. - **Actual behaviour**: - The cursor does not move. - The cursor stops blinking. - The browser is not responsive. - After several seconds or a minute, the focus eventually moves to the ""New Password"" field and the content is selected. 1. Press the delete/backspace key - As expected, the password is deleted and the browser is immediately responsive. My testing was as an administrator using Chrome on Mac OS X. I think this issue applies to any role and any browser on any OS. I expect the delay is longer with slower hardware. == Solutions == Certainly the strength checker need not run on `focus` events. It should only be necessary on `change`. It could also run after a short timeout (~500 ms) if no other `change` event has occured, so that it only runs when the user stops typing. An elaborate solution might be to make the password strength checking code more efficient. Or only run it on the first N characters. Or alternatively, seek a third party library that checks password strengths more performantly. A simple solution could be to set the `maxlength=""""` attribute on password ``s. Rough testing on Chrome on an 18-month old MacBook Air suggests The limit would probably need to be less than about 64-256 in order to keep the browser responsive (without modifying the unperformant code). The disadvantage of this approach is that long passwords can not be input by the keyboard, or will be truncated if pasted in. This might be an issue for users that use password managing software like OnePassword. We would need to investigate how long the passwords generated by such software is. For reference and comparison; - The server-side limit is currently 4096: https://github.com/WordPress/WordPress/blob/master/wp-includes/class-phpass.php#L217 - If a password is set that is longer than 4096 characters, WP silently fails to save the password." BevanR Future Releases 31127 Can't add a new user to two sites before they've accepted their account jeremyfelt Users 3.0 normal normal defect (bug) assigned has-patch 2015-01-25T18:57:47Z 2019-06-05T06:40:34Z "In multisite, when adding a new user to a site, the user account isn't created immediately. Their info is stored in the `wp_signups` table until the user checks their email and clicks their sign-up acceptance link. If an admin attempts to invite the user to a second site before the person has accepted their user account for the first, they'll get this message: > That username is currently reserved but may be available in a couple of days. > That email address has already been used. Please check your inbox for an activation email. It will become available in a couple of days if you do nothing." ericlewis Future Releases 15001 Duplication and incompatibilities in register_new_user() and wp_insert_user() Users 3.0 normal normal defect (bug) new has-patch 2010-09-30T19:16:11Z 2019-06-05T06:37:31Z "As a result of [12778], the commit of a patch that was part of #11644 (the MU-merge ticket), `wp_insert_user()` was modified to introduce user verification checks. The addition of these checks also introduced a number of duplications and incompatibilities between it and `register_new_user()`. (Bear in mind that `register_new_user()` calls `wp_create_user()` which calls `wp_insert_user()`.) These issues include: * Duplication (both run-time execution and code): both functions perform `username_exists()` and `email_exists()` checks. Ideally, we should only perform each check once, and from a single piece of code. * Whereas both functions perform `username_exists()` and `email_exists()` checks, `register_new_user()` performs more checks (empty_username, invalid_username, empty_email, invalid_email). If the former 2 are being checked, all 6 criteria should be checked. * `wp_insert_user()` can now return a WP_Error object, but `register_new_user()` can't handle it (I reported this in #14290) * `register_new_user()` generates a new generic error if `wp_create_user()` (via `wp_insert_user()`) returns an error (assuming proper patch #14290), rather than passing along the more specific error it was told about If an error is returned by `wp_create_user()`, `register_new_user()` throws a generic 'registerfail' error (`'ERROR: Couldn’t register you... please contact the webmaster !'`). However, most likely it received a more informative WP_Error object. * `register_new_user()` allows errors to be suppressed via filters, but `wp_insert_user()` does not `register_new_user()` has the filter 'registration_errors' which allows plugins to suppress any encountered errors. Having done so, `register_new_users()`'s subsequent call to `wp_create_user()` can generate an error (of the type already suppressed) which is then un-suppressable. This renders the 'registration_errors' filter useless for the username_exists and email_exists errors (and possibly other in the future). ---- These different issues may warrant separate tickets, but cumulatively I think they point to the need to refactor `register_new_user()` and `wp_insert_user()` to be more efficient and compatible. This is a rare instance where I don't include an immediate patch for a ticket, but I wanted to get it out there and see if we can try and get these fixed for 3.1. " coffee2code Future Releases 18791 Add custom post type support for Author Template functions Users 3.2.1 normal normal enhancement new 2011-09-27T12:32:48Z 2019-06-05T06:38:28Z "Functions defined in `wp-includes/author-template.php` assumes that post type == post. It will be good to enhance them so they will be able to work with specified post type. At first sight following functions will need update: {{{ get_the_author_link() the_author_link() get_the_author_posts() the_author_posts() the_author_posts_link() get_author_posts_url() wp_list_authors() }}} I suspect there will be other updates needed, to support new `post_type` argument added to author's url." sirzooro Future Releases 21730 More modular and reusable email validation functions Users normal normal enhancement new has-patch 2012-08-29T16:04:04Z 2019-06-05T06:38:46Z "Email validation, especially as it's handled in Multisite (most of which is verbatim from MU), is pretty messy. We have some functions like `is_email_address_unsafe()` for checking banned domains, but we don't have a parallel function for checking against limited_email_domains. There are no filters outside of `wpmu_validate_user_signup`, which means that if you want to use email validation outside of the normal MS registration workflow and want to tweak the way that it works (see eg #15706, #20459), you pretty much have to roll your own. And there's no single function that a plugin like BuddyPress can use to do all relevant email checks in one fell swoop. The attached patch suggests the following changes: - Put the limited_email_domains check into a function, `is_email_address_allowed()`. - Put filters on the output of this new function as well as `is_email_address_unsafe()`. - Introduce function wp_validate_email_address(), which wraps the following four checks: is_email(), email_exists(), is_email_address_allowed(), is_email_address_unsafe(). - Rearranges `wpmu_validate_user_signup()` a bit so that all email checks (as opposed to username checks) happen together. I'm not married to anything in this particular implementation (the way that wp_validate_email_address() sends back error messages is not particularly beautiful, but I didn't want to introduce a ton of overhead), but I would really like to see some sort of treatment along these lines, to make things more modular and reusable. If something like this gets approved by the devs, I would like to further suggest the following: - Give a similar treatment to username validation - Move the generic validation functions out of ms-functions.php (with function_exists() checks on the MS-specific stuff) I'm happy to work more on this kind of patch, but didn't want to go too far in case it's a non-starter for some reason." boonebgorges Future Releases 32796 User deletion API is inconsistent between MS and non-MS Users normal normal enhancement new has-patch 2015-06-26T12:56:44Z 2019-06-05T06:41:04Z "On non-multisite, `wp_delete_user( $u )` does what you'd expect: it deletes user `$u` from the database. On multisite, the same function basically wraps `remove_user_from_blog()`; if you want to delete a user from the database altogether, you've got to use `wpmu_delete_user()`. I understand the historical reasons behind the divergence, but it's pretty lame from a developer's point of view to have to check `is_multisite()` before removing a user from the database. There's a note in the docblock for `wpmu_delete_user()` that says ` * @todo Merge with wp_delete_user() ?`. Maybe we could actually make this happen? " boonebgorges Future Releases 44894 Add support for an optional `$roles` parameter to `populate_roles()` flixos90 Upgrade/Install normal normal Future Release enhancement assigned 2018-09-05T08:05:50Z 2019-01-23T23:22:19Z It should be possible to provide custom roles (and capabilities) to `populate_roles()` when populating a new site with its roles. This came up during work on #41333. flixos90 Future Releases 34676 Optimize bulk plugin updates francina Upgrade/Install 4.4 normal normal Future Release enhancement assigned has-patch 2015-11-13T16:03:40Z 2022-06-07T17:22:52Z "When selecting more then one plugins to update the following things are done: * Maintenance mode on (if -a- plugin is active) * Per plugin: 1. Get plugin info 2. Download package 3. Unpack package 4. Install package * Maintenance mode off **Scenario:** 10 plugins require updates. Only the last one is active = requires maintenance mode to be enabled. Server might not have the best connection to WordPress.org or other plugin resource. This means that the site will not be available during: * Downloading of all plugins * Unpacking of all plugins * Installing of all plugins This means at least (10*download request) + (10*unpacking) + (10*installing) = 30 actions. Not including optional plugin info request * 10. Also not including plugins that need to do delta's on tables or other upgrading scripts. Though only one plugin actually required the site to not be available, which would be (1*installing) = 1 action. **Ideal flow:** * Download all packages * Unpack downloaded packages * Determine per plugin if maintenance is required * Install plugin * Disable maintenance if next plugin is not active * Finally: disable maintenance if enabled * Remove all unpacked packages and downloads I can think of a performance argument to include the unpacking of packages in the maintenance mode because it might be a strain on the server, but functionally I don't think it should be. As far as I can see the only file that this is effectively handled in is `class-wp-upgrader.php`." jipmoors Future Releases 36428 Weird default value of option 'default_link_category' Upgrade/Install 3.5 normal normal defect (bug) new 2016-04-06T15:15:19Z 2020-06-05T06:22:07Z "The option `default_link_category` has value `2` after installing WordPress. It makes no sense since 3.5. Generally, it's not a big problem, but we check referential integrity in our plugin and this fails because there's no `term_taxonomy` with ID `2`. " JanVoracek Future Releases 33932 Filters for Plugin/Theme Update Email Notifications ocean90 Upgrade/Install 3.7 normal normal enhancement reviewing has-patch 2015-09-20T04:51:05Z 2019-06-05T06:41:41Z "I've had several requests to enable core update emails, but disable emails for plugins/themes. If this idea is approved, '''I would love to be the one to tackle this''' as I have yet to contribute to core. Goal is to keep `send_core_update_notification_email` intact, but allow filters for both plugin/theme background update notifications. Apparent use-case is a user wants core emails, but not plugin/theme emails. One filter rules them all currently from what I can see in the code-base. Example use-case in the wild: https://wordpress.org/support/topic/for-on-the-wishlist?replies=8" ronalfy Future Releases 28569 Calling show_admin_bar( false ) should dehook toolbar entirely davidbaumwald Toolbar normal normal Future Release enhancement reviewing has-patch 2014-06-17T20:14:16Z 2021-11-05T05:21:30Z "Because I'm only hiding the toolbar in certain contexts, I'm calling `show_admin_bar( false )` right before `get_header()`. #16249 was closed suggesting the function should only be called on `init`. #21746 suggests calling after `plugins_loaded` However, I think calling it after the query is set and the template is picked is a valid use case. As such, I'd propose calling `show_admin_bar( false )` should run `remove_action('wp_head', '_admin_bar_bump_cb');` and similar setup callbacks." danielbachhuber Future Releases 58905 Ensure locate_template only loads theme files Themes normal normal 6.6 defect (bug) new has-patch 2023-07-25T19:44:43Z 2024-02-17T13:41:42Z "It's possible to have locate_template load files that are not template files which could be unexpected behavior that breaks the display of a page. The chance this breaks something is, I think, not infinitesimal. Therefore, this should go in early. An initial patch is attached. " jorbin Future Releases 56990 Render blocking CSS `classic-themes.css` unnecessarily enqueued Themes 6.1 normal normal Future Release defect (bug) assigned has-patch 2022-11-03T22:21:14Z 2023-06-20T17:57:20Z "Since WordPress 6.1, a new CSS file [https://github.com/WordPress/WordPress/blob/master/wp-includes/css/classic-themes.css classic-themes.css] is now enqueued on all pages on the front end of non-block themes. This stylesheet seems to only include styles related to the `wp-block-button__link` class and the stylesheet is added regardless of whether a block button is used on the page. Although the file itself is tiny, the cumulative impact of every WordPress site using a non-block theme is huge and no explanation is given in the doc block as to why the style is needed. This change was originally added in https://github.com/WordPress/gutenberg/pull/44731 and ported over to core. Even in [https://github.com/WordPress/gutenberg/pull/44731#pullrequestreview-1133944306 this comment] though, the front end view already looks fine, so it is unclear why the style needs to be added manually here. The original Gutenberg patch only enqueued the styles in the editor, so it is unclear why styles were added to the front end in this commit: https://github.com/WordPress/WordPress/commit/bbb40de012670768a525193639c0d5e4ea932df7. In my testing, removing the style had no front end impact, the button looked exactly the same before and after I removed the stylesheet. The button is already styled from `blocks.css`. This stylesheet adds an unnecessary render blocking stylesheet with a huge cumulative impact on WordPress sites. I suggest we remove it. Worth noting that this enqueue was added during RC, probably something we avoid doing if we hope to avoid performance regressions. Also points to the need for better performance metrics, even something as simple as catching new front end enqueues could be useful here." adamsilverstein Future Releases 57141 WP_Theme cannot locate a parent block theme Themes 6.0 normal normal Awaiting Review defect (bug) new has-patch 2022-11-18T04:02:53Z 2022-11-21T23:37:35Z "As reported here: https://github.com/WordPress/gutenberg/issues/45811 after a discussion in slack: https://wordpress.slack.com/archives/C02QB8GMM/p1668569269811889 On wp-themes.com we're running into a use-case where the Parent theme cannot be located when both the parent and child theme are block themes, and the parent does not have an index.php file. (See screenshot attached below, where the parent theme is 100% most definitely installed) This appears to work on some installations, but not on others. I believe it working might be down to caching, I haven't figured that out. The attached PR updates the code in WP_Theme to support the same theme files as supported via [53416] for themes in parent themes. " dd32 Future Releases 42513 WP_Theme::get_post_templates() is extremely inefficient for large themes Themes 4.8.3 normal normal Awaiting Review defect (bug) new has-patch 2017-11-11T14:07:01Z 2017-11-12T13:13:42Z "WP_Theme::get_post_templates() uses file_get_contents() to read the complete contents of each theme php file in the root of a theme into memory, twice, and processes the result with a custom Regular Expression. As a result, significantly more data than necessary is processed when loading large themes. In addition, because the standard get_file_data() function is not called (as it is with all other header comments), the ""extra_{$context}_headers"" filter is never called, which is inconsistent behavior with other file_header related operations, such as the WP_Theme constructor." gschoppe Future Releases 59507 global-styles-and-settings.php in wp_theme_has_theme_json Themes 6.3.1 normal normal Awaiting Review defect (bug) new close 2023-09-29T18:45:19Z 2023-10-02T17:29:27Z "Wordpress 6.3.1 , php 8.1.23 {{{#!php Double Quotes', '') Error: Call to undefined function wp_rel_ugc() /var/www/tests/phpunit/tests/formatting/WPRelUgc.php:31 4) Tests_Rel_Ugc::test_wp_rel_ugc with data set #1 ('', '') Error: Call to undefined function wp_rel_ugc() /var/www/tests/phpunit/tests/formatting/WPRelUgc.php:31 5) Tests_Rel_Ugc::test_wp_rel_ugc with data set #2 ('', '') Error: Call to undefined function wp_rel_ugc() /var/www/tests/phpunit/tests/formatting/WPRelUgc.php:31 7) Tests_Rel_Ugc::test_wp_rel_ugc with data set #4 ('', '') Error: Call to undefined function wp_rel_ugc() /var/www/tests/phpunit/tests/formatting/WPRelUgc.php:31 8) Tests_Rel_Ugc::test_wp_rel_ugc with data set #5 ('', '') Error: Call to undefined function wp_rel_ugc() /var/www/tests/phpunit/tests/formatting/WPRelUgc.php:31 9) Tests_Rel_Ugc::test_wp_rel_ugc with data set #6 ('', '') Error: Call to undefined function wp_rel_ugc() /var/www/tests/phpunit/tests/formatting/WPRelUgc.php:31 10) Tests_Rel_Ugc::test_wp_rel_ugc with data set #7 ('', '') Error: Call to undefined function wp_rel_ugc() /var/www/tests/phpunit/tests/formatting/WPRelUgc.php:31 11) Tests_Rel_Ugc::test_wp_rel_ugc with data set #8 ('', '') Error: Call to undefined function wp_rel_ugc() /var/www/tests/phpunit/tests/formatting/WPRelUgc.php:31 12) Tests_Rel_Ugc::test_append_ugc_with_valueless_attribute Error: Call to undefined function wp_rel_ugc() /var/www/tests/phpunit/tests/formatting/WPRelUgc.php:81 ERRORS! Tests: 9960, Assertions: 44191, Errors: 12, Skipped: 11. }}} **Patch** Should I include changes to the `package-lock.json` even though I made no changes to the dependencies in `package.json`? " dhurlburtusa Future Releases 33017 Images displayed with page.php instead of index.php Themes normal normal defect (bug) reopened dev-feedback 2015-07-16T15:04:19Z 2019-06-04T21:15:50Z "I am developing a theme and currently do not have an `attachment.php` or a `single.php`. When I insert an unattached image into a post and select ""Link to: Attachment Page"", I expect the image to be displayed with `index.php` according to the template hierarchy [https://developer.wordpress.org/files/2014/10/wp-template-hierarchy.jpg]. However, the attachment page is displayed with the `page.php` tempalte instead, and the URL is under my static front page. The issue does not show up with images attached to the post." creon Future Releases 24143 When define('WP_CONTENT_DIR', 'your-dir') twentythirteen - The theme directory does not exist. Themes 3.4 normal normal defect (bug) reopened 2013-04-20T10:08:16Z 2021-04-20T06:02:42Z "If you use either of following in you wp-config.php you'd automatically get a Broken Themes. {{{ define('WP_CONTENT_DIR', 'your-dir'); define('WP_CONTENT_URL', 'your-url'); }}} The following themes are installed but incomplete. Themes must have a stylesheet and a template. Name Description twentythirteen The theme directory does not exist." azizur Future Releases 15086 get_template_part() should let you specify a directory westi* Themes 3.0 normal normal enhancement accepted dev-feedback 2010-10-10T21:36:45Z 2019-06-04T21:06:02Z "IT would be nice for `get_template_part()` to allow you to specify a directory to look for a file in. Right now you actually *can* do this, but it requires passing a 'slug' to the function like `directory/slug`. Since everywhere else in the code slugs are sanitized, this seems like an unexpected way to allow this functionality (I didn't realize this worked until @nacin pointed it out). Since this slug isn't actually sanitized at all, you can currently do `get_template_part( '../../../test' );` which seems rather unsafe (`get_template_part` should be able to include from outside the themes directory). I suggest sanitizing $slug and adding a third [optional] parameter that allows you to specify the directory to look in. The directory parameter should be sanitized enough to not allow it to start with a . or a / (although this more likely belongs in `locate_template()` as something done to $template_name inside the foreach). What does everyone think about this approach? How many themes do we think are currently using the $slug parameter to specify a directory? Right now the optional $name parameter is set up as a fall through, so if $slug-$name.php doesn't exist $slug.php is used. Should $directory be set up similarly ($directory/$slug-$name.php -> $directory/$slug.php -> $slug-$name.php -> $slug.php)?" aaroncampbell Future Releases 38243 Attempting to create a term with invalid UTF8 characters creates a blank term Taxonomy normal normal Future Release defect (bug) new has-patch 2016-10-06T13:52:37Z 2019-04-01T17:41:28Z "Attempting to insert a term which contains invalid UTF8 characters will incorrectly create a term in the database with a blank name & slug. This happens as we check that the term name & slug is provided, but fail to check after sanitizing the term. In the scenario that I've run into, something similar to this happens: {{{ $term_name = urldecode( ""360%BF"" ); // Invalid UTF8 character wp_insert_term( $term_name, 'my_taxonomy' ); }}} What this causes is * the checks on `$name` to pass * it then hits `sanitize_term()` and after passing through `sanitize_text_field()` and then `wp_check_invalid_utf8()` the `name` field of the term is set to an empty string. * `wp_insert_term()` then takes this empty name and creates an equally empty slug from it. * `wp_insert_term()` then calls `get_terms( array( 'name' => '' ) )` and needlessly & badly loads up all 60,000 terms into memory of the custom taxonomy * `wp_insert_term()` then see's an empty slug and ultimates settles on a setting the slug to the numeric ID of the term somehow * `wp_insert_term()` finally inserts a term with a numeric slug and empty `name` field I think at a minimum, we should verify that the term name is still valid after term sanitisation. See patch for that." dd32 Future Releases 46010 "Auto-generated term slugs can be greater than 200 characters, giving ""Could not insert term into the database."" error" Taxonomy normal normal Awaiting Review defect (bug) new dev-feedback 2019-01-16T14:37:23Z 2019-01-16T16:31:12Z "When a slug is not user defined, WordPress attempts to generate it from the term name within `wp_insert_term`. If the slug exists, when inserting subcategories, WordPress prefixes the slug with the top level term name. https://core.trac.wordpress.org/browser/tags/5.0.2/src/wp-includes/taxonomy.php#L2093 Because of this, long term names can go over the slug length limit and error. WordPress admin simply shows: > Could not insert term into the database. There is no reasoning provided, and when using wp_insert_term programatically it's hard to know what's at fault. This issue is more apparent when using cyrillic characters since they are stored encoded in the DB. Take ""Категория на продукта"" as an example. In the database this gets stored as: {{{ %d0%ba%d0%b0%d1%82%d0%b5%d0%b3%d0%be%d1%80%d0%b8%d1%8f-%d0%bd%d0%b0-%d0%bf%d1%80%d0%be%d0%b4%d1%83%d0%ba%d1%82%d0%b0 }}} This is 116 characters. The maximum allowed slug length defined in the wp_terms database schema is 200 characters. Steps to reproduce: - Add a top level category ""Категория на продукта"" - Add another ""Категория на продукта"" term as a subcategory of ""Категория на продукта"" - See error This is what WordPress attempted to insert into the database: {{{ ( [name] => Категория на продукта [slug] => %d0%ba%d0%b0%d1%82%d0%b5%d0%b3%d0%be%d1%80%d0%b8%d1%8f-%d0%bd%d0%b0-%d0%bf%d1%80%d0%be%d0%b4%d1%83%d0%ba%d1%82%d0%b0-%d0%ba%d0%b0%d1%82%d0%b5%d0%b3%d0%be%d1%80%d0%b8%d1%8f-%d0%bd%d0%b0-%d0%bf%d1%80%d0%be%d0%b4%d1%83%d0%ba%d1%82%d0%b0 [term_group] => 0 ) }}} The slug is too long. We either need error checking for this, or we need to truncate the slug length to avoid the issue and keep slug < 200 chars." mikejolley Future Releases 50568 Improve WP_Term's sanitization calls Taxonomy 5.5 normal normal Future Release defect (bug) new has-patch 2020-07-06T07:04:45Z 2024-03-12T17:49:50Z "Akin to `WP_Post::filter()`, I think `WP_Term::filter()` should have a bypass, too. This will significantly improve performance wherever terms are used (list edit screens, category widgets, blocks) because the bypass prevents redundant re-sanitization. The attached patch will shave off a 30% load time at `wp-admin/edit.php` after #50567's implementation. This patch tests for the `WP_Term` object's `::$filter` state, and only re-sanitizes the term when the state differs from the input argument. You'll also find that `sanitize_term()` now looks a lot like `sanitize_post()`--the same goes for `get_term()`'s resemblance to `get_post()`. Overall, it seems posts have received a lot more love over the years, and this patch steals some of that. There are a few issues with terms, however. For example, `update_term_cache()` caches terms regardless of being shared, while `WP_Term::get_instance()` tries to prevent that. The `$filter = 'display'` argument is used in contexts where `raw` would do fine, too (e.g. @ `WP_Terms_List_Table::single_row()`). If we iron those issues out, we can fully phase out the re-sanitization of terms." Cybr Future Releases 49799 get_the_terms() object term cache check too strict? Taxonomy 2.3 normal normal Awaiting Review defect (bug) new reporter-feedback 2020-04-03T15:24:05Z 2020-04-16T05:58:55Z "I ran into a weird issue when doing integration tests on one of a client's project. I was setting up custom post and custom taxonomy from the factory (for posts I used the default one, and for custom taxonomy I have created my own factory that extends `WP_UnitTest_Factory_For_Term`), set everything up, but the part of the plugins code that used `get_the_terms` returned nothing. So after racking my brains, I tried `wp_get_post_terms`, and lo and behold, this worked (the test posts had assigned terms for them, I checked before invoking my function I needed to test using `get_the_terms`). So something was up with caching. I started to dig and it turned out that {{{#!php $terms = get_object_term_cache( $post->ID, $taxonomy ); }}} inside `wp-includes/category-template.php` returned an empty array. Now, since the line 1246 says {{{#!php if ( false === $terms ) { }}} The empty array, while being a ''falsy'' value, it's not a `false` value (https://3v4l.org/RVuG7), so the above check will return false and the returned value from the `get_the_terms` function will be `false`. So when I 'loosened' the condition in my test suite WP, the `$terms = wp_get_object_terms( $post->ID, $taxonomy );` works, and I get my terms inside the tests. If the condition is loosened, nothing seems to be lost in terms of checking the emptiness of the terms from the term object cache (if it's full, it's `false` all the times https://3v4l.org/34UQk). Now, on the face value, this could be the oddity of the test suite (which in my case is set up using wpcli scaffold command), but I'm thinking that changing this requirement cannot hurt (from what I can tell) in the long run. " dingo_d Future Releases 58404 Add pre_update_term filter hook Taxonomy normal normal Future Release enhancement new dev-feedback 2023-05-25T10:13:14Z 2023-09-25T22:52:28Z "Hi In file: {{{ wp-includes/taxonomy.php }}} In function: {{{ wp_update_term }}} How can to validate a custom term before updated? A filter needs here like pre_insert_term in wp_insert_term() functin. I think this filter has been forgotten in here. {{{ $term = apply_filters( 'pre_edit_term', $term, $taxonomy, $args ); }}} " kobi1 Future Releases 53319 "Add support for a ""reverse"" argument in get_term_parents_list() function" Taxonomy normal normal Future Release enhancement new has-patch 2021-06-02T10:36:36Z 2023-07-26T02:14:13Z "Please bare with me, I probably do everything wrong since it is my first Trac Ticket involving code. --- Recently I used `get_term_parents_list()` to create a list of hierarchical terms. I noticed that by default the function outputs the terms like so: `Parent Category/Child Category/Grandchild Category` I could not find any argument or way to invert that order, with the goal to display the terms like so: `Grandchild Category/Child Category/Parent Category` This is useful for example if we have Geographic zones and the utmost parent is a Country, the utmost child an area. In that case we may want to display Area/Region/Country which looks like an address structure rather than the opposed which is the default I don't think it should be too hard adding this new argument to the function. I have uploaded a file with the modified function and updated code comment to the ticket. I also tested my changes on a existing install and can confirm this introduced no unexpected issues. It would be awesome to see if we can add this tiny change in future release." bedas Future Releases 38310 "Improve ""wp_update_term"" documentation" ruudjoyo Taxonomy 4.7 normal normal Future Release enhancement reopened has-patch 2016-10-14T10:10:06Z 2021-09-29T05:26:16Z "Hi all, When using the wp_update_term function and reading through its inline docs, it struck me that some part of the inline docs is kind of vague (highly subjective, I know). I will add a patch with a proposal for a more specific inline docs. Thanks, Ruud" ruud@… Future Releases 45107 Taxonomies should only be allowed to support one object type Taxonomy normal normal Awaiting Review enhancement new dev-feedback 2018-10-17T16:48:28Z 2019-02-12T21:00:32Z "Currently, taxonomies can be registered to any object type (posts, comments, users, etc.). But core does not enforce a one to one limit for object types to taxonomies, which can be problematic. For example, if a taxonomy is registered to both users and posts, there can be unintended consequences. Adding a term to a post with an ID of 3 would also cause a user with an ID of 3 to have that term. Removing that term from the user would also affect the post. Unique IDs are only enforced on a per object type basis, not accross all types. The approach here would be to introduce a `_doing_it_wrong()` notice (and possibly even return a `WP_Error`) when a taxonomy is registered to multiple object types. **Good:** `register_taxonomy( 'custom_tax_name', array( 'post', 'page', 'cpt' ) );` **Bad:** `register_taxonomy( 'custom_tax_name', array( 'post', 'user' ) );` == Why == Adding this to Core would open the door for the following potential features: - `WP_Tax_Query` support could be added to users (see #31383), comments, etc. - Built-in fields for taxonomy could be added to the REST API for users, comments, etc. - UIs could be added for users (also see #31383), comments, etc. == Backward Compatibility == To continue supporting backward compatibility for sites that are registering a taxonomy for multiple object types, `register_taxonomy()` could continue working as is. The only change would be to return a `WP_Error` and a `_doing_it_wrong()` notice. In the future, `register_taxonomy()` could be changed to only register objects with the same type as the first specified object type. Example: `register_taxonomy( 'custom_tax_name', array( 'post', 'user', 'page' ) );` would only register the taxonomy for posts and pages (same object type)." desrosj 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 40661 WP_Term_Query->parse_query() needs filter like 'get_terms' Taxonomy normal normal Awaiting Review enhancement new 2017-05-04T10:28:28Z 2017-08-04T17:50:55Z "The new class/method WP_Term_Query->parse_query() does not provide a filter like the old function get_terms() does. Using WP_Term_Query directly has thus different functionality from using the old wp_terms function. Using a plugin like: https://wordpress.org/support/plugin/custom-taxonomy-order-ne/ with a custom term_order field and sorting based on that, gives the default sort based on name. Adding a filter to the method like get_terms, provides backwards compatibility for plugin and theme authors, that are switching to WP_Term_Query directly. This filter gives options to apply a custom order to the list of terms. Reference on support forum: https://wordpress.org/support/topic/doesnt-reorder-when-using-wp_term_query/ If adding a filter is somehow not wanted by core devs, then I will have to answer to add this filter manually to the code when support requests are coming. To be clear, I would consider that a valid response." mpol Future Releases 31665 Duplicate slugs in DB, created for hierarchical terms with long, non-latin names, when the default slug already exists Taxonomy 4.1.1 normal normal defect (bug) new 2015-03-17T10:43:33Z 2019-06-04T21:14:42Z "When WP automatically generates a slug for a child term, and if the produced slug (which is normally generated just from the term's name) already exists in that taxonomy, it forms a slug by concatenating all the parent terms' slugs hierarchically For example, in a term structure like: Parent -Child If a term with the name ""Grandchild"" is to be inserted under ""Child"", normally it would get the slug ""grandchild"". However if that slug already exists in the taxonomy, WP generates the slug ""parent-child-grandchild"". When the slugs have long, non-latin names, they are stored urlencoded in wp_terms, and the stored string's length can easily overflow the field's size ( varchar(200) ). Any terms created under that condition end up having the same slug stored in the DB (the produced urlencoded one, truncated to 200 chars). To reproduce the issue: Create a term (e.g. category) with this name (without the quotes): ""Ένα δύο τρία τέσσερα πέντε"" Create another term with the same name, defining the first term as its parent. Create a third term with the same name, defining the second term as its parent. The second and third terms end up having duplicate slugs in the DB, a situation which is normally an error. This issue is also not detected if the same procedure is repeated using wp_insert_term(). Normally an attempt to insert a duplicate slug to the same taxonomy would raise a ""duplicate_term_slug"" WP_Error, which is not the case." nevma Future Releases 16101 Numeric term fields are strings Taxonomy normal normal defect (bug) new has-patch 2011-01-04T23:25:00Z 2020-11-10T16:15:04Z "The numeric fields (term_id, parent, etc.) on term objects are strings. I only noticed this because term_exists() uses is_int() to determine if the $term value is an ID or slug. Only ticket I could find about this is #5381. sanitize_term() should fix this, but it bails early in the ""raw"" context. sanitize_term_field() sanitizes the numeric fields in every context. I don't see a reason for sanitize_term() to bail early so I made a patch that takes that out. The patch also adds some missing fields to the list of those to be sanitized and changes term_exists() to use is_numeric() (which will correctly identify strings containing only numbers) instead of is_int(). " foofy Future Releases 31270 Unexpected slugs for same-title different-parents term creation boonebgorges Taxonomy 4.1 normal normal defect (bug) assigned has-patch 2015-02-09T03:35:53Z 2019-06-04T21:13:57Z "When creating a new term which matches an existing terms name, it uses that slugs slug as the slug prefix, which can result in an unexpected term slug. For example, take this: {{{ Foo (slug: foo) - Bar (slug: foo-bar) }}} If we now create a root level ""Bar"" term, it'll get a slug of {{{foo-bar-2}}}, when one would expect it to receive {{{bar}}} since no conflicting slug exists. This is related directly to [28733] / #17689. Unit test attached showing behaviour." dd32 Future Releases 32789 Abstract get_category_by_path into get_term_by_path Taxonomy normal normal enhancement new 2015-06-25T15:59:01Z 2019-06-04T21:15:41Z "Having a function like `get_term_by_path` would be great as currently you have to fork the `get_category_by_path` function on your own to get a term by path for any other custom taxonomy. Would there be any opposition to a patch for this? The abstracted function wouldn't house the `_make_cat_compat` usage, which would remain in the backwards compatible `get_category_by_path` function after checking to see if $category is not null." sc0ttkclark Future Releases 30705 Add parameter to get_the_term_list() to allow templating Taxonomy 2.5 normal normal enhancement new 2014-12-13T21:32:57Z 2019-06-04T21:13:09Z "Similar to #27238 the parameter $term_template is suggested to allow for user created formatting for get_the_term_list(), as opposed to the previous standard of simply linking to each list in the term. The reasoning for the change is that general linking is not always the desired action for displaying term lists. The method for inclusion is similar to [30209]." davidjlaietta Future Releases 36978 Add pre filter to get_term_by Taxonomy normal normal enhancement new has-patch 2016-05-30T22:25:13Z 2019-06-04T21:23:44Z Like other get get_*_by functions the get_term_by should have a pre filter. This filter should specially be useful to short-circuit the default logic, perhaps to add caching. spacedmonkey Future Releases 23422 Add query filter argument to register_taxonomy Taxonomy normal normal enhancement new 2013-02-08T12:38:35Z 2019-06-04T21:08:16Z "Following on from the #21240 ticket which introduced the show_admin_column functionality I would like to suggest an additional argument to easily add the select list query filter for a taxonomy to the post-type list. Currently a taxonomy query can be added via the 'restrict_manage_posts' action and 'parse_query' filter. It would be useful to add an additional register_taxonomy argument of 'show_column_filter' to define a standard select option list of the taxonomy terms. Things like default option and hierarchy could be optional settings is an array is passed instead of boolean. " tifosi Future Releases 33975 Improve capabilities management when registering custom taxonomy Taxonomy normal normal enhancement new 2015-09-23T12:02:12Z 2019-06-04T21:17:04Z "Currently we have such caps when using `register_taxonomy()` [https://codex.wordpress.org/Function_Reference/register_taxonomy#Arguments codex]: {{{ 'manage_terms' - 'manage_categories' 'edit_terms' - 'manage_categories' 'delete_terms' - 'manage_categories' 'assign_terms' - 'edit_posts' }}} IMO, setting `manage_terms` to false block access to page (cheating message), setting `edit_terms` to false displays this message: ""You are not allowed to edit this item."", which is very odd. Editing means editing, So I should not be able to use Quick Edit and Edit links (they should be hidden). Also, I propose to add a `create_terms` capability maping - for displaying the add term form and giving ability to create them, separately from editing/deleting. Related: #22511" slaFFik Future Releases 24386 Make _pad_term_counts work for non-post type objects and attachments Taxonomy normal normal enhancement new 2013-05-22T18:23:31Z 2020-11-05T15:55:22Z "If you register a hierarchical taxonomy against a non-post object (such as users), or attachments that aren't associated with another post, _{{{pad_term_counts}}} does bubkus, due to the INNER JOIN on {{{$wpdb->posts}}}, and the check for 'publish' status (which is relevant for attachment post types). I'm suggesting an alternative approach would be to use $term->count, and eschew going back to the database altogether." TomAuger Future Releases 36171 Proposed clean up of get_the_category_list() and link filter Taxonomy 4.4.2 normal normal enhancement new has-patch 2016-03-08T17:09:25Z 2019-06-04T21:20:57Z "The current source code of the {{{get_the_category_list()}}} function is quite messy and there is also a lot of duplicate code which we can avoid. Also, on a micro optimization level, in stead of passing the category ID to {{{get_category_link()}}}, we can pass the whole category object. Doing this will avoid the extra overhead of having to get the complete category object from the term cache. There is also no filter to filter each category link on category level, we only have the {{{the_category}}} filter which filters the string of links. We have being receiving a couple of questions on wordpress.stackexchange.com regarding filtering these category links according to category. [http://wordpress.stackexchange.com/q/219554/31545 Here] is such one question. My proposal is included in my code, a filter called {{{the_category_list_links}}} which we can use to filter each category link individually according to the category. One such use-case of the filter can look something like {{{ add_filter( 'the_category_list_links', function ( $the_link_list, $category, $cat_parents ) { $category_color = get_field( 'category_color', $category ); if ( !$category_color ) return $the_link_list; $the_link_list = str_replace( 'using_permalinks() ) ? 'rel=""category tag""' : 'rel=""category""'; $links = array(); foreach ( $categories as $category ) { /** * Break the link for better link building */ $start_link = 'term_id ) ) . '"" ' . $rel . '>'; $end_link = $category->name . ''; /** * Build the category links */ $the_link_list = ''; switch ( strtolower( $parents ) ) { case 'multiple': $cat_parents = $category->parent ? get_category_parents( $category->parent, true, $separator ) : ''; $the_link_list = $cat_parents . ' ' . $start_link . $end_link; break; case 'single': $cat_parents = $category->parent ? get_category_parents( $category->parent, false, $separator ) : ''; $the_link_list = $start_link . $cat_parents . $end_link; break; case '': default: $the_link_list = $start_link . $end_link; } /** * Filter the category links on category level. * * @since X.X.X * * @param string $the_link_list Post category link. * @param object $category The current category object * @param $cat_parents Link list of parents of the current category */ $links[] = apply_filters( 'the_category_list_links', $the_link_list, $category, $cat_parents ); } $thelist = ''; if( '' === $separator ) { $thelist .= '
    '; $thelist .= ""\n\t
  • ""; $thelist .= implode( ""
  • \n\t
  • "", $links ); $thelist .= '
  • '; $thelist .= '
'; } else { $thelist .= implode( $separator, $links ); } /** * Filter the category or list of categories. * * @since 1.2.0 * * @param array $thelist List of categories for the current post. * @param string $separator Separator used between the categories. * @param string $parents How to display the category parents. Accepts 'multiple', * 'single', or empty. */ return apply_filters( 'the_category', $thelist, $separator, $parents ); } }}}" pietergoosen Future Releases 29586 Sync get_the_category_list with get_the_term_list Taxonomy 2.5 normal normal enhancement new 2014-09-08T13:39:35Z 2019-06-04T21:12:17Z "It would be great to have {{{get_the_term_list()}}} support the same features {{{get_the_category_list()}}} has. I created a proof of concept patch what works. The only thing I hate is the part I need to specify that I want to have a list instead of a separator because when it's empty {{{get_the_category_list()}}} assumes to show a list but {{{get_the_term_list()}}} will then just show only the links." markoheijnen Future Releases 48153 Allow the admin email verification capability to be filtered Site Health 5.3 normal normal Future Release defect (bug) assigned has-patch 2019-09-26T14:35:07Z 2020-02-21T17:53:27Z "Currently, the capability used to determine if the admin email verification screen should be displayed is hard coded as `manage_options`. There are scenarios where a plugin or site owner would want to change this capability." desrosj Future Releases 43989 "Allow plugin searches to be filtered by ""Requires PHP"" version information" Site Health normal normal Future Release task (blessed) new 2018-05-07T14:24:41Z 2019-06-24T16:10:01Z "**Note: This ticket is a subtask for the overarching #40934 ticket.** If plugins now start making use of the ""Requires PHP"" version information in their plugin header, we should make sure that plugin searches can be filtered by their required PHP version. This might include changes to the indexing infrastructure (indexing that information and allowing indexed queries against it) as well as changes to the UI (giving users the possibility to either use search flags in text form or faceted search mechanisms to communicate such a query." schlessera Future Releases 47880 Extend unit tests for Site Health component. Site Health 5.2 normal normal Future Release task (blessed) new 2019-08-15T00:49:49Z 2020-07-06T23:20:09Z "A file for site health check unit tests has been added in `tests/phpunit/tests/site-health.php`. At the time of writing it only includes tests for various states of cron, expanding these would help with future development of the component." peterwilsoncc Future Releases 58366 Shortcode Support Regained but Content Filters are messing with Shortcode HTML Shortcodes 6.2.2 normal normal 6.6 defect (bug) new has-patch 2023-05-20T15:45:26Z 2024-02-22T20:41:52Z "I am extremely grateful that the Security Team were able to quickly regain support for shortcodes in the Block Theme templates. However, whatever change has been agreed and pushed out means that the filters to automatically inject `
` and `

` tags into the content are now affecting shortcodes and we are seeing text being automatically wrapped in `

` tags and carriage returns replaced with `
` tags. Rather than revert to the insecure v6.2.1 we are going through shortcodes to remove any carriage returns. Please advise. Oliver" domainsupport Future Releases 59509 Shortcode attributes named 0 are ignored Shortcodes 6.3.1 normal normal Awaiting Review defect (bug) new 2023-09-30T12:14:06Z 2023-10-04T10:02:59Z "Shortcode attributes in the form `0=...` are not picked up during parsing. This is because the parser checks for an empty name with `empty(..)`, which also returns true for the string `'0'`." ourous Future Releases 47616 Enhancement: doing_shortcode() function similar to doing_filter() audrasjb* Shortcodes normal normal Future Release enhancement accepted dev-feedback 2019-06-27T12:42:53Z 2021-11-09T08:46:59Z "Currently there is no way to determine whether the current code is run from a shortcode callback. Similar to actions and filters it would be nice to have a `doing_shortcode()` function. My idea is to have an optional parameter for the shortcode tag. If the parameter is passed it will check if that exact shortcode is running. If no parameter is passed it will return true if any shortcode is running. Though I believe it's not officially supported, if shortcodes are triggered within shortcodes it would be best to keep an array of current shortcodes and only remove an active shortcode tag if the callback is finished." keraweb Future Releases 24990 Nested Shortcode Inside [caption] Shortcodes 3.6 normal normal defect (bug) new dev-feedback 2013-08-08T09:38:06Z 2021-05-08T23:37:35Z "Nested shortcodes inside caption observation: {{{ [caption] Caption Text [shortcode][/caption] }}} 1. shortcode inside alt and title processed. 2. Caption Text doesn't" prionkor Future Releases 26649 escaped shortcodes should not be expanded during 'get_the_excerpt' Shortcodes 3.7.1 normal normal defect (bug) reopened 2013-12-16T15:13:48Z 2019-06-04T21:10:00Z "It is possible for ""the_content"" filter to be invoked while processing ""get_the_excerpt"". If the do_shortcodes() filter hook is attached to both ""the_content"" and ""get_the_excerpt"" then this can lead to an unexpected expansion of an escaped shortcode. This can lead to unwanted side effects, as reported here. http://www.oik-plugins.com/2013/12/escaped-shortcodes-unexpectedly-expanded-get_the_excerpt/ This minor problem can be alleviated by a simple change to strip_shortcode_tag(), returning the HTML code [ as the first character rather than the left square bracket. {{{ function strip_shortcode_tag( $m ) { // allow [[foo]] syntax for escaping a tag if ( $m[1] == '[' && $m[6] == ']' ) { return ""["" . substr($m[0], 2, -1) ; } return $m[1] . $m[6]; } }}} I don't believe that it's necessary to make the same change in do_shortcode_tag(). " bobbingwide Future Releases 50027 Retire Phpass and use PHP native password hashing Security normal normal Awaiting Review defect (bug) new dev-feedback 2020-04-29T10:36:12Z 2023-10-13T01:11:52Z "PHP comes with built-in password hashing functions since PHP 5.5. Now that we have updated the minimum requirements to PHP 5.6, we can rely on PHP to provide us with password hashing mechanisms that ensures a cryptographically secure random numbers are are used for salt, and the hashes are backwards compatible. I created and maintain [https://wordpress.org/plugins/password-hash/ PHP Native Password Hash] plugin to swap WordPress's baked in Phpass with PHPs. **0.Phpass recommends to use PHP native hashing** > At this time, if your new project can afford to require PHP 5.5+, which it should, please use PHP's native password_hash() / password_verify() API instead of phpass. I propose that we upgrade the hashing mechanisms to password_hash()/password_verify/password_needs_rehash() combo. **1.We do not need to force users to change their passwords.** Phpass-hashed passwords have the signature `$P`, and the very old MD5 hashes are fewer than 32 characters long. We will inspect the signature first, and if the password is using the old standard, we will validate the password one last-time, and then use password_hash() to rehash it. From this point forward, that user is ""upgraded"" to the new mechanism. **2.Expose a filter for plugins** The plugin I maintain supports BCrypt, Argon2I, and Argon2ID for hashing. We can expose a filter that WordPress core emits so plugins can change the hashing algorithm if necessary. **3.Use BCrypt as the default algorithm** If a plugin does not take over, WordPress core will use BCrypt. BCrypt is secure, and is available in any PHP version 5.5, 5.6, 7.* and 8.*. **4.Do not remove Phpass** We will **not** remove Phpass from WordPress core. This is needed for backwards compatibility to ensure that existing users will eventually be updated. The end goal is that we seamlessly migrate active users passwords to better mechanisms without breaking functionality for existing users. Frameworks such as Drupal and phpBB (which used phpass in the past) have moved to better mechanisms since the minimum required PHP versions have been updated, and we can easily follow suit. If the maintainers agree, I would be overjoyed to collaborate on patches. " ayeshrajans Future Releases 51438 Use CSP directive upgrade-insecure-requests when using HTTPS Security 5.7 normal normal Future Release enhancement new 2020-10-02T20:08:07Z 2021-11-09T00:01:22Z "While looking at ways on how to streamline HTTPS support in WordPress core, [https://core.trac.wordpress.org/ticket/47577#comment:4 one suggestion has been to include a `Content-Security-Policy` directive of `upgrade-insecure-requests`] for sites using HTTPS. This directive would ensure that browsers automatically replace (old) insecure requests for inline content (e.g. images) to use HTTPS (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests). This could be as simple as injecting `` into `wp_head` for sites that use HTTPS (see `wp_is_using_https()` from #47577). Alternatively, since this is mostly beneficial for sites that may still (""accidentally"") have insecure URLs in their content after migrating from HTTP to HTTPS, it might make sense to rely on `wp_should_update_insecure_urls()` from #51437 instead." flixos90 Future Releases 52388 Use HTTPS URL already during installation if supported Security normal normal Future Release enhancement new 2021-01-28T03:06:59Z 2021-01-28T03:06:59Z "Following up on #51437, WordPress should try to check already during installation whether the current domain and server can be used over HTTPS. If so, it should suggest to use the HTTPS version of the URL by default. This was originally brought up by @westonruter in https://core.trac.wordpress.org/ticket/51437#comment:1, but was out of scope for that ticket which focuses on migration from HTTP to HTTPS." flixos90 Future Releases 37756 Allow inline scripts on script aliases Script Loader 4.5 normal normal Future Release defect (bug) new 2016-08-21T06:46:10Z 2019-12-13T22:21:50Z "It appears if {{{add_inline_script}}} is called on {{{jquery}}} then it gets ignored, and requires to use {{{jquery-core}}} The same may apply to styles but not tested. Inline scripts should work on both the main script and the aliases. " pcfreak30 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 46089 Memory exhaustion when setting script translations on `wp-i18n` Script Loader normal normal Future Release defect (bug) new has-patch 2019-01-24T00:47:26Z 2021-02-04T05:53:32Z "A memory exhaustion occurs given the following snippet of code: {{{#!php Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 262144 bytes) in /srv/www/editor/htdocs/wp-includes/class.wp-dependencies.php on line 324
}}} Memory exhaustion occurs here: https://github.com/WordPress/WordPress/blob/4e3e9ca9cf893190609728848caf224034fd1ef0/wp-includes/class.wp-dependencies.php#L338 I think it stems from this line: https://github.com/WordPress/WordPress/blob/4e3e9ca9cf893190609728848caf224034fd1ef0/wp-includes/class.wp-scripts.php#L517 Where `wp-i18n` is adding itself as a dependency. Could probably do for a simple check to ensure that the incoming handle is not `wp-i18n`." aduth Future Releases 54956 "[5.9] wp_block_type args - ""style"" and ""script"" are always loaded on Frontend" Script Loader 5.9 normal normal Awaiting Review defect (bug) new dev-feedback 2022-01-27T17:15:29Z 2022-07-19T13:58:22Z "Before 5.9 - `style` and `script` are loaded when the block is added to specific page. After 5.9 - `style` and `script` are always loaded, on all pages, all the time, everywhere, regardless if the block is displayed on specific page or not. More info about my use case: - `style` and `script` both reference a registered script/style, which have multiple dependencies (`wp_register_style` has `$deps` array defined that references more registered styles) Temporary fix I did to the client code: - Replacing `style` and `script` with `styles` and `view_script` fixed the issue However this ""fix"" requires specific WP Core version - 5.8.3 should use `style` and `script`, while 5.9 should use `styles` and `view_script`." pkostadinov Future Releases 51124 Can we get an additional parameter in wp_add_inline_script to set the script type? audrasjb* Script Loader normal normal Future Release feature request accepted early 2020-08-24T15:55:12Z 2021-11-08T02:55:50Z "Hi everyone, This is probably a feature that not many developers out there will use but I think it would be nice to have. One of my plugins uses `wp_add_inline_script` to inject an inline script into the page. Said inline script gets assigned `text/javascript` as type automatically and there doesn't seem to be a way to change that (if there is please let me know and I'll gladly close this ticket.) My plugin needs said inline script to contain a JSON string and so it currently hooks into `script_loader_tag` to change its type to `application/json` which feels a bit like a hack. It would be nice if we could set the script type via parameter (eg. `wp_add_inline_script( 'some-handle', '...', 'before', 'application/json' );`) (or maybe via filter hook before `script_loader_tag` happens?) Thoughts?" hcabrera Future Releases 35963 Only remove item from WP_Dependencies::to_do if it was successfully processed Script Loader normal normal defect (bug) new has-patch 2016-02-26T12:37:32Z 2019-06-04T21:20:31Z "If WP_Dependencies::do_item returns false, the item is removed from being processed again. Due to this, if an item gets switched to the footer, it is never actually outputted. A common scenario is depending on jquery which depends on jquery-core and jquery-migrate. jquery is processed right, but jquery-core and jquery-migrate are moved to the bottom but still removed from the list. The following example demonstrates: {{{#!php registered['jquery']; wp_dequeue_script('jquery'); wp_deregister_script('jquery'); wp_register_script('jquery', $jquery->src, $jquery->deps, $jquery->ver, true); } }, 0); }}} Attached is a very simple patch to resolve this" pcfreak30 Future Releases 37185 "wp_print_styles() doesn't call ""wp_print_styles"" action when ""$handles"" argument passed" Script Loader 3.3.1 normal normal defect (bug) assigned has-patch 2016-06-26T13:53:32Z 2019-06-04T21:24:27Z "In {{{wp_print_styles()}}}, there is ""wp_print_styles"" action calls when function is used with optional ""$handles"" argument. {{{if ()}}} statement should be deleted ( like {{{wp_print_scripts()}}} ). Unit tests are passed." evgenniy Future Releases 40340 """Attach to existing content"" modal shows posts and pages of other users" Role/Capability normal normal Awaiting Review defect (bug) reopened 2017-04-02T15:19:15Z 2017-08-03T17:54:02Z "From the Media library, a user can attach media (through the Attach link) that were uploaded by himself only. The first image shows the Attach links appearing for certain media only. In the same way, the ""Attach to existing content"" should also list only those posts/pages for which the user has the permissions to attach. Instead it lists all posts (including private) and pages of all users, and then, upon selection, gives the message ""Sorry, you are not allowed to edit this post."" " menakas Future Releases 43877 Do not run unnecessary `user_has_cap` filter if the caps to check for include `do_not_allow` already Role/Capability normal normal Awaiting Review defect (bug) new has-patch 2018-04-27T12:27:30Z 2018-09-17T11:21:33Z "`do_not_allow` is a fake capability used essentially as a blacklist, saying that nobody can perform that action. It's typically returned in the `map_meta_cap()` result for an actual capability check. If `do_not_allow` is part of that array, it is immediately clear that the final result of the `WP_User::has_cap()` method will be `false`. Currently however, the following code in the function still executes, including a `user_has_cap` filter. Since we already know the return value if `do_not_allow` is present in the `$caps` array checked for, everything happening afterwards is entirely unnecessary overhead. Especially since [40993] it should be clear that nothing can get around a `do_not_allow` being present. For efficiency and possibly performance reasons, I suggest we check for `do_not_allow` right after the `map_meta_cap()` call, and if it is present, return false." flixos90 Future Releases 50123 Roles & Caps: give anonymous users the `read_post` meta cap for public posts. Role/Capability normal normal Awaiting Review defect (bug) new 2020-05-07T23:30:23Z 2024-01-26T07:45:24Z "The meta capability `read_post` is used to determine if a user is permitted to read a post. For public posts (ie, both a public post type and public post status), it returns the `$post_type->cap->read` as the required primitive capability. As logged out users do not have any primitive capabilities, this causes `current_user_can( 'read_post', $post_id )` to return a false negative for logged out users wishing to read a public post. **Approach one:** For public posts the `read_post` meta capability returns an empty array of primitives. **Approach two:** Logged out users are given the `$post_type->cap->read` capability for public post types. **Approach three:** WP gives logged out users the `read` primitive capability, if a developer uses an alternative primitive for public custom post types, then the developer is responsible for ensuring anonymous users have the capability. **Notes:** * ~~Private multisite sites should not allow logged out users to see such posts~~ ''Edit: removed as it's not a core feature of Multisite'' * Many, many unit tests will be required " peterwilsoncc Future Releases 59585 Unchecked variable creates fatal error in wp-includes/class-wp-user-query.php Role/Capability 6.3.2 normal normal Awaiting Review defect (bug) new has-patch 2023-10-10T13:32:17Z 2023-10-10T21:12:27Z "Hello! I've ran into a bug that had me need to modify core. I have no clue why this bug happens in this setup in particular, i've got other WP websites running on the same server with no problem, but this one crashes with no plugins and twenty twenty two active. Here is what I found; at line 483 there is an array_filter that passes a variable to the function... without verifying the variable is actually what is expected. Bug is present in 6.3.2 {{{#!php $role_data ) { $role_caps = array_keys( array_filter( $role_data['capabilities'] ) ); foreach ( $capabilities as $cap ) { [...] }}} I fixed it by checking the variable is something before doing the array_filter {{{#!php $role_data ) { $role_caps = ''; if(isset($role_data['capabilities'])){ $role_caps = array_keys( array_filter( $role_data['capabilities'] ) ); }else{ return false; } foreach ( $capabilities as $cap ) { }}} I would like this to be added to core, so it doesnt crash anymore and wont crash when I update WordPress next time." Frederic Pilon 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 38997 delete_private_posts capability doesn't prevent user from deleting private posts Role/Capability 4.6.1 normal normal Future Release defect (bug) assigned 2016-11-30T21:09:31Z 2019-05-25T14:02:40Z "Attempting to prevent users from deleting a published post works, but if they set a post to 'private' they can delete it even if 'delete_private_posts' capability is set to 0. {{{#!php allcaps['delete_published_posts'] = 0; // doesn't work $current_user->allcaps['delete_private_posts'] = 0; }}} ""doesn't work"" means that ""Trash"" link appears on hover over the post in edit.php and ""Move to Trash"" shows up on post.php " yboris 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 38433 Complete test coverage for current_user_can_for_blog() Role/Capability 4.3 normal normal Future Release enhancement new has-patch 2016-10-21T14:15:43Z 2020-06-04T15:49:23Z In `Tests_User_Capabilities`, all roles and capabilities are tested using `current_user_can()`. They should all be tested using `current_user_can_for_blog()`, too. johnbillion Future Releases 45197 Introduce `user_can_for_blog()` johnbillion Role/Capability normal normal 6.6 enhancement reviewing has-patch 2018-10-26T11:05:51Z 2024-03-07T16:46:56Z "The available user capability checking functions include: * `current_user_can()` * `user_can()` * `current_user_can_for_blog()` What's missing is `user_can_for_blog()` so that both a user ID and a site ID can be passed in order to check a given user's capabilities on a given site." 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 42405 Introduce singular capabilities for enabling individual themes on Multisite Role/Capability normal normal Future Release enhancement new 2017-11-01T22:14:24Z 2017-11-01T22:14:24Z "Related: #39083 The ability to enable or disable individual themes for a site from the Network Admin -> Sites -> Edit -> Themes screen should be controlled by singular capabilities. * `enable_theme` * `disable_theme`" johnbillion Future Releases 41701 Introduce singular capabilities for further management of individual plugins Role/Capability normal normal Future Release enhancement new 2017-08-22T14:14:11Z 2017-08-22T14:14:28Z "This is a follow-up to #38652 which introduced singular capabilities for activating and deactivating individual plugins. Singular capabilities should be added for controlling the ability to do the following: * Edit an individual plugin. * Delete an individual plugin. * Update an individual plugin. Low priority stretch goals which might end up in another follow-up ticket: * Edit an individual file in a plugin. * Install an individual new plugin. * Upload an individual new plugin. Network activation and deactivation for Multisite will be handled in a separate ticket." johnbillion 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 41703 Introduce singular capabilities for network activation and deactivation of individual plugins Role/Capability normal normal Future Release enhancement new 2017-08-22T14:16:06Z 2020-09-20T12:12:58Z "This is a follow-up to #38652 which introduced singular capabilities for activating and deactivating individual plugins. Singular capabilities should be added for controlling the ability to network activate and network deactivate individual plugins on Multisite. See also #41701." johnbillion 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 39174 Introduce network roles Role/Capability normal normal Future Release feature request new 2016-12-08T02:00:45Z 2019-03-15T02:07:55Z "We have been discussing introducing network roles during multisite office-hours several times. The original concept for roles on multisite/multinetwork was the following: ''Site Administrator < Network Administrator (currently also called ""Super Admin"") < Global Administrator < Super Admin (special access via `$super_admins` global, has all capabilities automatically)'' This ticket is about network roles in particular, but we need to figure out the entire concept we'll be going with beforehand. After the initial discussions which happened several weeks ago, I started playing around with that idea and created a plugin with network roles which is available at https://github.com/felixarntz/wp-network-roles. The details on that plugin are described in this Google doc (and are probably worth reading to understand the following discussion better): https://docs.google.com/document/d/1MWwwKmhBJookr5dEcYga4sBtCwvx-K8uSucBFx6SP9U/edit# I just had a long conversation with @johnbillion around this topic where we agreed on some ideas, disagreed on others, were entirely unsure about others. The following bullet points sum up what we talked about / which questions we raised. * The original idea of network roles was that these roles behave similar to regular site roles: They all have a set of capabilities they can perform. These capabilities can apply to either the site or network level. This allows for roles like the current ""Super Admin"" / ""Network Administrator"" that has access to everything a site administrator has, but also to any network admin functionality - however it also allows for roles like a possible ""Network Editor"" which would be the same as if a user had the ""Editor"" role on every site of the network. * Should we support both of these concepts? Or should network roles only affect the actual network admin area? If the latter, which roles would we even need in Core itself (in addition to the ""Super Admin"" / ""Network Administrator"")? This decision would also affect whether we should support inheritance of network capabilities to site capabilities or whether network roles would just be additional kind of roles for a user. An example to clarify: * First approach: The ""Super Admin"" / ""Network Administrator"" has all the capabilities a regular site administrator has, plus the network admin area capabilities (like `manage_network` or `manage_network_options`), so they automatically behave as if they were a site administrator on every site in the network. * Second approach: The ""Super Admin"" / ""Network Administrator"" role only has network admin area capabilities (like `manage_network` or `manage_network_options`), so the user also needs to have the site administrator role for each site they want to access. (probably not?) * If we support inheritance, can we handle the two kinds of roles together? A ""Network Administrator"" that has access to the network admin area is conceptually a bit different from a ""Network Editor"" who can only access all site admin areas on that network. If we find solid descriptive names, we're probably good here. For example, instead of having a ""Network Administrator"" being the role where one can access the network admin and at the same point be an administrator on all the network's sites, maybe that role should rather be called ""Network Manager"", while ""Network Administrator"" is a different role which basically means that user is an administrator on all the network's sites, but cannot access the network admin area. * We would certainly need to handle that in a slow migration path: If we introduce a network role system with a predefined set of capabilities in let's say 4.8, we write a dev-note at the same time that tells plugin authors that they now need to add their custom capabilities to the new network role because that role no longer automatically can do anything. At this point however we still keep the current super admin functionality in sync so that the role actually still can do anything. We wait until 2-3 releases later to actually remove the sync thing, which means we get rid of the `site_admin` network option and from that point on use `is_super_admin()` and `get_super_admins()` only to retrieve users specified in the `$super_admins` global. * Is this the right approach at all? Currently the ""Super Admin"" / ""Network Administrator"" can do ""anything but..."" rather than having a predefined set of capabilities. While we can address that with a migration like described above, we still need to think about whether it ''is'' the right way to do it. Maybe we need a concept like ""Role X can do anything under certain circumstances unless specifically denied"". * How should we handle Multisite / Multinetwork? Multisite is the ""easy"" thing here - for all of the changes here we need to consider Multinetwork especially, even though it is not really supported by Core at this point. * What do we think a ""Super Admin"" is? Is that a network administrator with specific capabilities, is it kind of a global administrator or is it a special thing that can do anything, thus not having a predefined set of capabilities? Core itself doesn't really know what a super admin is at this point. In most setups it is a network administrator / network manager as it's stored in a network option. But if you use the `$super_admins` global, it suddenly turns into some kind of a global administrator. Which of the two are we going to stick with for that terminology? * Can we rename the term ""Super Admin"" at all (in terms of BC)? It would probably become either ""Network Administrator"" or ""Network Manager"" depending on the approach. If we can't rename it and keep the name for the ""network administrator"" role, how are we going to handle the higher role level? This will likely become a feature project, but this ticket is for more discussion beforehand." flixos90 Future Releases 26365 map_meta_cap() should use parent post status when post has a post status of inherit Role/Capability 3.8 normal normal defect (bug) new has-patch 2013-12-02T19:38:49Z 2019-06-04T21:09:43Z "When a post has a status of inherit `map_meta_cap()` fails to use the parent's status and so logic that uses the status to determine the mapping doesn't behave as expected. For example `read_post()` will often fail when it should pass. Similarly for `delete_post()` and `edit_post()`. This has recently caused a variety of difficulties in a project I've been working on where we have a custom post type that uses the inherit post status on children so authors only need to manage the post status of the main parent post. The fix is two parts. One a fix to `get_post_status()` that causes it to check the parent status so it'll work backwards to the first post that has a valid (not 'inherit') post status. The second is a fix to `map_meta_cap()` that checks for a post status of inherit on the post object and then uses `get_post_status()` on the post_parent id value. A couple related/similar issues: #23458 (these patches would fix the root issue) #17668 (fixed) " methnen Future Releases 16839 Category Base Should be Slugified SergeyBiryukov* Rewrite Rules 3.1 normal normal Future Release defect (bug) accepted early 2011-03-12T21:42:52Z 2023-03-02T15:52:09Z "Vanilla install of 3.1. Change category base to Foo Bar. Link generated is example.com/Foo Bar/cat (note the %20/space). Clicking link tries to access /FooBar/cat and 404's. I see there are a few other tickets regarding categories, including #16662 but no specific mention of custom category base. " miklb 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 33728 Rewrite endpoints cannot be added to custom taxonomies with public rewrites johnbillion Rewrite Rules 4.4 normal normal Future Release defect (bug) reviewing has-patch 2015-09-04T14:37:20Z 2018-01-23T22:07:25Z "Take the following scenario: 1. A plugin registers a custom taxonomy that is public and has pretty rewrite rules enabled: {{{ function genre_taxonomy() { $tag_args = array( 'label' => 'Genre', 'public' => true, 'rewrite' => array( 'slug' => 'genre' ), ); register_taxonomy( 'genre', array( 'post' ), $tag_args ); } add_action( 'init', 'genre_taxonomy', 5 ); }}} 2. A second plugin registers a rewrite endpoint that is added to all URLs on the site: {{{ function ajax_endpoint() { add_rewrite_endpoint( 'ajax', EP_ALL ); } add_action( 'init', 'ajax_endpoint' ); }}} `EP_ALL` means ""add this to all pages"", which should logically include all custom taxonomies. This however, is not the case. Works: - site.com/ajax/1 - site.com/tag/blug/ajax/1 - site.com/blog/hello-world/ajax/1 - site.com/2015/05/01/ajax/1 - all other standard rewrites Fails: - site.com/genre/rock/ajax/1 It fails because custom taxonomies do not get included in `EP_ALL` unless they are explicitly included. If we look at `register_taxonomy()`, we see this is done intentionally: {{{ if ( false !== $args['rewrite'] && ( is_admin() || '' != get_option( 'permalink_structure' ) ) ) { $args['rewrite'] = wp_parse_args( $args['rewrite'], array( 'with_front' => true, 'hierarchical' => false, 'ep_mask' => EP_NONE, ) ); if ( empty( $args['rewrite']['slug'] ) ) $args['rewrite']['slug'] = sanitize_title_with_dashes( $taxonomy ); if ( $args['hierarchical'] && $args['rewrite']['hierarchical'] ) $tag = '(.+?)'; else $tag = '([^/]+)'; add_rewrite_tag( ""%$taxonomy%"", $tag, $args['query_var'] ? ""{$args['query_var']}="" : ""taxonomy=$taxonomy&term="" ); add_permastruct( $taxonomy, ""{$args['rewrite']['slug']}/%$taxonomy%"", $args['rewrite'] ); } }}} In my opinion, '''this is fundamentally wrong'''. If a rewrite endpoint is added with `EP_ALL`, it should actually be registerred on '''all''' rewrites, not just some. Let's see another example to help illustrate that this is wrong. 1. A plugin (such as WooCommerce) registers a custom taxonomy with public rewrites called ""Product Category"". With this taxonomy, the following rewrite is available: `site.com/products/product-category/mugs` 2. A second plugin (such as AffiliateWP) registers a rewrite endpoint with `EP_ALL` to permit the following: - site.com/ref/1 - site.com/page-name/ref/1 - site.com/2015/01/01/ref/1 - site.com/category/news/ref/1 - etc, etc - AND - site.com/products/product-name/ref/1 (works) - site.com/products/product-category/mugs/ref/1 (fails) The rewrite endpoint works fine on custom post type rewrites '''but not taxonomy rewrites'''. There are two ways for rewrite endpoints to work on the custom taxonomy: 1. Have the taxonomy include `'ep_mask' => 'EP_ALL'` (or similar) when it is registered. This requires that the plugin that registers the taxonomy to include this, which very, very, very few do as it is not necessary for pretty permalinks to work. 2. Manually add rewrite rules for the endpoints to all custom taxonomies: {{{ $taxonomies = get_taxonomies( array( 'public' => true, '_builtin' => false ), 'objects' ); foreach( $taxonomies as $tax_id => $tax ) { add_rewrite_rule( $tax->rewrite['slug'] . '/(.+?)/ref(/(.*))?/?$', 'index.php?' . $tax_id . '=$matches[1]&ref=$matches[3]', 'top'); } }}} While manually adding the rewrite rules does work, '''it should not be necessary''' when `add_rewrite_endpoint( 'ref', EP_ALL );` should be sufficient. I propose that `EP_TAXONOMY` be introduced, as suggested in #21050, and that `EP_TAXONOMY` be included in `EP_ALL`. Related #19275" mordauk Future Releases 41791 Unicode + add_permastruct breaks rewrite rules Rewrite Rules 4.9 normal normal Awaiting Review defect (bug) new dev-feedback 2017-09-04T11:15:57Z 2017-09-15T13:14:58Z "This was reported here https://github.com/woocommerce/woocommerce/issues/16673 To recreate the issue, create a taxonomy with a cyrillic name such as Сертификат. View the taxonomy archive. You'll see no results; it will go to the homepage rather than an archive. In WooCommerce you can recreate this by creating an attribute (Product > Attributes) with a cyrillic name, and enabling the 'archive', assigning a term from this taxonomy to a product, and trying to view products by that term. I managed to trace it back to the `add_permastruct`. The `struct` is added with unicode % encoded characters. When the rewrite rules are processed, it thinks these are placeholders so the `matches` variables do not align. See this screenshot for clarity: https://www.dropbox.com/s/5vztnfm6895488a/query%20is%20wrong.png?dl=0 Notice all the $matches? Compare to a working taxonomy: https://www.dropbox.com/s/24zyr5v7taw7b60/correct.png?dl=0 This can be fixed by using `urldecode` when adding the permastruct. I don't know if this has side effects but it worked in testing. Patch to follow. " mikejolley 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 35482 Archival pagination fails in 4.4 and up Rewrite Rules normal normal defect (bug) new 2016-01-15T20:59:37Z 2019-06-04T21:19:22Z "Stemming from research into a weird 'category' issue in #35344 1. Make your permalinks {{{/%category%/%postname%/}}} or anything _as long as_ you start with `/%category%/` 2. Go to `example.com/category/SOMECAT/` and everything works. 3. Go to `example.com/SOMECAT/` and WP thinks it’s an _archive_! And pagination fails. Either it's a 404, or it redirect you to the 'most appropriate' page (I ended up on http://local.wordpress-trunk.dev/page-a/2/ a lot) I tested this with `/%author%/%postname%/` and `/bob/%postname%/` - the former had the same issue, the latter shows a 404 for `http://local.wordpress-trunk.dev/bob/` and this is expected! If the permalink 'base' is any of our structure tags ( https://codex.wordpress.org/Using_Permalinks#Structure_Tags ) then WordPress is attempting to generate an archival page for something it knows, and the pagination is failing. Logically this is becuase any ‘base’ page that ​_can_​ generate an archive of itself (cats, tags, dates, but ​_not_​ `bob`) should be doing so. Contrary to initial reports, this is a 4.4+ bug, it was _not_ introduced by 4.4.1 Slugs like bob and 'archive' (the slug you get if you pick the 'Numeric' permalink option) have never, that I can see, paginated. Digging even deeper.... 1. Permalinks set to `/%year%/%category%/%postname%/` 2. Visit `example.com/2016/SOMECAT` and the page displays an archive 3. Pagination from here does _not_ work (tested on 4.4 and 4.3 so I think its okay to assume that never worked....) I'm not sure if these should have worked. I know that if you do `/%year%/%month%/%postname%/` then the year ''and'' the year/month archive URLs will work, but that may be a separate issue." Ipstenu Future Releases 35916 WP_Rewrite::generate_rewrite_rules() ignores boolean $endpoints / $feed parameters for CPT Rewrite Rules normal normal defect (bug) new 2016-02-23T08:34:12Z 2019-06-04T21:20:24Z "Hello, I'm trying to declare custom rewrite rules for a custom post type without endpoints and feeds. As result, WP ignore the endpoint flag in the WP_Rewrite::generate_rewrite_rules(). What I did is as following. I created a custom post type called 'event' with the following arguments for register_post_type() : {{{#!php array( // Array of WP post type args 'labels' => array( 'name' => 'Events', 'singular_name' => 'Event', ), 'public' => true, 'publicly_queryable' => true, 'show_ui' => true, 'show_in_menu' => true, 'query_var' => false, 'rewrite' => false, 'capability_type' => 'post', 'hierarchical' => false, 'menu_position' => 5, 'menu_icon' => 'dashicons-tickets-alt', 'supports' => array( 'title', 'editor', 'thumbnail', ), 'taxonomies' => array( 'post_tag', 'my_category', ), ); }}} Then I called {{{#!php $args_post_type = array( 'feed' => false, 'paged' => false, 'ep_mask' => EP_NONE, 'endpoints' => false, ); add_permastruct('events', 'events/%event%', $args_post_type); }}} The resultings rewrite rules are : {{{ 'events/[^/]+/attachment/([^/]+)/?$' => string 'index.php?attachment=$matches[1]' (length=32) 'events/[^/]+/attachment/([^/]+)/trackback/?$' => string 'index.php?attachment=$matches[1]&tb=1' (length=37) 'events/[^/]+/attachment/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$' => string 'index.php?attachment=$matches[1]&feed=$matches[2]' (length=49) 'events/[^/]+/attachment/([^/]+)/(feed|rdf|rss|rss2|atom)/?$' => string 'index.php?attachment=$matches[1]&feed=$matches[2]' (length=49) 'events/[^/]+/attachment/([^/]+)/comment-page-([0-9]{1,})/?$' => string 'index.php?attachment=$matches[1]&cpage=$matches[2]' (length=50) 'events/[^/]+/attachment/([^/]+)/embed/?$' => string 'index.php?attachment=$matches[1]&embed=true' (length=43) 'events/([^/]+)/embed/?$' => string 'index.php?event=$matches[1]&embed=true' (length=38) 'events/([^/]+)/trackback/?$' => string 'index.php?event=$matches[1]&tb=1' (length=32) 'events/([^/]+)(?:/([0-9]+))?/?$' => string 'index.php?event=$matches[1]&page=$matches[2]' (length=44) 'events/[^/]+/([^/]+)/?$' => string 'index.php?attachment=$matches[1]' (length=32) 'events/[^/]+/([^/]+)/trackback/?$' => string 'index.php?attachment=$matches[1]&tb=1' (length=37) 'events/[^/]+/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$' => string 'index.php?attachment=$matches[1]&feed=$matches[2]' (length=49) 'events/[^/]+/([^/]+)/(feed|rdf|rss|rss2|atom)/?$' => string 'index.php?attachment=$matches[1]&feed=$matches[2]' (length=49) 'events/[^/]+/([^/]+)/comment-page-([0-9]{1,})/?$' => string 'index.php?attachment=$matches[1]&cpage=$matches[2]' (length=50) 'events/[^/]+/([^/]+)/embed/?$' => string 'index.php?attachment=$matches[1]&embed=true' (length=43) }}} Looking at class-wp-rewrite.php, I noticed in generate_rewrite_rules() that piece of code that forces the $post flag for CTP {{{#!php if ( ! $post ) { // For custom post types, we need to add on endpoints as well. foreach ( get_post_types( array('_builtin' => false ) ) as $ptype ) { if ( strpos($struct, ""%$ptype%"") !== false ) { $post = true; // This is for page style attachment URLs. $page = is_post_type_hierarchical( $ptype ); break; } } } }}} and that piece of code that unconditionnaly add extra endpoints / feeds... for post {{{#!php // If we're matching a permalink, add those extras (attachments etc) on. if ( $post ) { // Add trackback. $rewrite = array_merge(array($trackbackmatch => $trackbackquery), $rewrite); }}} Could confirm that problem? Thanks" solo14000 Future Releases 14991 extra_rules_top should take priority over extra_permastructs Rewrite Rules 3.1 normal normal defect (bug) new dev-feedback 2010-09-29T18:00:08Z 2022-12-05T12:09:28Z Since extra_rules_top are specifically added instead of generated like the those from the extra_permastructs which runs through generate_rewrite_ruls(), shouldn't the extra_rules_top take priority in conflicts? prettyboymp Future Releases 25106 web.config for multisite configurations on IIS7 Rewrite Rules 3.5 normal normal defect (bug) new 2013-08-21T00:43:28Z 2019-06-04T21:08:57Z "The code that WordPress gives me for the web.config is incorrect. I downloaded the new 3.6 and this issue happened. I found the issue and solved it but wanted to let you know of this error as not many people run multisites on IIS7. So the rewrite code that was the issues is the following and was Rule 2 {{{ }}} what i can tell this is trying to do is if a user types in just ""domain.com/wp-admin"" that it would redirect them to ""domain.com/wp-admin/"" but the desired results did not happen. the above code would redirect you to ""domain.com/domain.com/wp-admin/"" which obviously would cause issues after the user logs in as the redirect_to would point to http://domain.com./domain.com/wp-admin/ which would cause an endless loop. To fix this problem you need to add a / to the beginning of the rewrite like so {{{ }}} that extra / before the wp-admin/ forces it to the root of the site.. now i am not sure what this would do to a site in a sub directory but im not in a sub directory so not an issue for me." mrevets Future Releases 13701 Full support for middle and little endian permalink structures Rewrite Rules 2.9.2 normal normal enhancement reopened reporter-feedback 2010-06-02T14:34:08Z 2019-06-04T21:05:49Z "This only happened after I switched over to the WordPress 3.0 development version, so I'm inclined to think it's a bug. When I use the traditional wp_get_archives or the dropdown version it shows that posts exist. However, when I click to go to any of those past posts, I only get a 404 Error. This problem is very consistent, happening 100% of the time. Disabling all plugins has no affect on the problem. The only other information that might be helpful is that I've integrated WordPress into a website that I built and I am using a custom theme that I built. It only has the index.php, single.php, and style.css files. Again, the wp_get_archives function worked just fine with the exact same setup that I have now prior to switching to the 3.0 version, so I'm not sure what changed." RevelationTravis Future Releases 16830 url_to_postid() doesn't resolve attachments when rewrite rules are disabled Rewrite Rules 1.2 normal normal enhancement reopened dev-feedback 2011-03-11T01:09:14Z 2019-06-04T21:06:33Z "The code of {{{url_to_postid()}}} is pretty clear in the case of disabled rewrite rules: all URLs not using the {{{p=N}}}, {{{page_id=N}}} or {{{attachment_id=N}}} forms are not parsed and the function return 0. That make sense. Now there is a special case for attachments. Attachments can be saved under a the {{{/wp-content/uploads/year/month/}}} folder structure while rewrite rules are disabled at the same time. This means there is a missed opportunity for {{{url_to_postid()}}} to resolve attachment's URLs of the long-form when rewrite rules are disabled. This was tested and reproduced on WordPress 3.1." anonymized_154007 Future Releases 9824 make better use of stubs when verbose rules should apply Rewrite Rules normal normal task (blessed) reopened 2009-05-15T01:03:56Z 2019-06-04T21:05:28Z "Related to: http://core.trac.wordpress.org/ticket/6603#comment:27 Problem fixed is: > posts show up as www.apexprd.org/page/2 and not /news-and-events/page/2 as it should. with permalinks set to /something/$postname%/ we arguably don't necessarily need verbose rules here, since there is a stub." Denis-de-Bernardy Future Releases 40577 Introduce a capability for viewing the revisions of a post adamsilverstein Revisions 2.6 normal normal Future Release enhancement assigned 2017-04-26T11:36:57Z 2023-03-02T06:35:53Z "In order to view the revisions of a post, a user needs the ability to edit the post. This makes sense because it may be undesirable for users to be able to view older revisions of a post which they cannot edit. However it may be desirable to allow certain users to view the revisions of a post which they cannot edit, for example for auditing purposes, or to allow contributors to browse the revisions of their own published post." johnbillion Future Releases 52925 Autosaves controller: Post checks will never catch invalid IDs REST API 5.8 normal normal Future Release defect (bug) new 2021-03-27T00:28:03Z 2021-06-08T22:56:03Z "The `create_item` and `create_post_autosave` methods both try to check if the id parameter in a request is for a valid post, by calling the get_post function. The problem is that both methods expect that if it's not a valid post, it will return a WP_Error object, when in fact get_post only returns null on failure. The Posts controller has a protected get_post method that will generate an appropriate WP_Error for this case, but neither the Autosaves, nor its parent Revisions controller has a similar method. Copying that method to the Revisions controller, and then using it in the `create_*` methods seems like the best approach here." coreymckrill Future Releases 54516 Full site editing/REST-API: modify permission checks to use post type. REST API 5.9 normal normal Future Release defect (bug) assigned has-patch 2021-11-25T23:39:15Z 2024-02-19T20:33:19Z "The new `wp_global_styles` post type is registered to use `edit_theme_options` in the capability settings. The `WP_REST_Global_Styles_Controller` class's permission checks methods use the capability in a hard coded form rather than using `$post_type->cap->edit_posts`, etc, for the primitives and `edit_post, $post_id` for the meta caps. To allow theme and plugin developers to modify the capability used for editing global styles via a filter, it would be good to defer to the post types setting. At the moment, such code would cause a conflict between the permission checks in the API and those in `wp_insert_post()`. I'll put this on the 5.9 milestone for visibility as the endpoint was introduced during the current cycle." peterwilsoncc Future Releases 39889 Improve/Fix REST Response on Multisite when an endpoint for a non-existent site is hit. REST API 4.7 normal normal Future Release defect (bug) new 2017-02-16T15:52:54Z 2019-07-09T18:42:18Z "Currently if you hit the endpoint for a domain on a site that doesn't exist it will behave the same as on a normal request. - visit https://nonexistentsubdomain.eventsmart.com/wp-json in a REST client. - Take note of the ""Location"" header in the response: https://eventsmart.com/wp-signup.php?new=nonexistentsite. It's also returned with a HTTP 302 Granted this is kind of edgecase, but I think it'd be better to handle things a bit better on REST requests. The question is how? I think from the standpoint of the REST client it'd be better to just return a 404 and a ""site doesnt' exist"" message (or something to that affect)." nerrad Future Releases 53622 Query Param status default is a string value, but an array is required rachelbaker* REST API normal minor Awaiting Review defect (bug) accepted 2021-07-07T17:24:41Z 2023-02-20T21:33:06Z "The default value in the collection params that is a string. https://github.com/WordPress/wordpress-develop/blob/953e1c5f8313a89d4d3b99ab5996b4660045c976/src/wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php#L2847 Really, we should make that `['publish']`. Original commit: https://github.com/WordPress/wordpress-develop/commit/ede099a7047a150a37d43a380e661b99387bce41" austyfrosty Future Releases 49538 Can't get a subset of `_embedded` using `_fields` REST API 5.3 normal normal Future Release enhancement new 2020-02-27T21:26:38Z 2020-10-22T00:23:12Z "I'd expect to be able to limit which values get returned in embedded fields, the same way that I can with standard fields. e.g., https://wordpress.org/news/wp-json/wp/v2/posts/8384?_fields=slug,_embedded.author.name&_embed That would make the response faster and smaller." iandunn Future Releases 42785 Change default of `show_in_rest` in register_post_type and register_taxonomy REST API normal normal Future Release enhancement assigned has-patch 2017-12-03T19:34:14Z 2020-01-07T23:56:41Z "Right now `show_in_rest` is defaulted to `false` in `register_post_type` and `register_taxonomy`. To improve usefulness of the REST API I think the time has come to include default publicly readable data into the REST APi. This helps with https://github.com/WordPress/gutenberg/issues/1342#issuecomment-319920850 for Gutenberg too. I propose we default `show_in_rest` to `true` in the following scenarios: - Object types registered with `public => true` (only). - Object types registered with `publicly_queryable => true`. I have other future ideas for further cases (including authenticated-only cases) but I think this is a good start. " joehoyle Future Releases 54293 Expand functionality of themes REST API REST API 4.7 normal normal Awaiting Review enhancement new 2021-10-20T09:30:08Z 2022-06-07T11:59:12Z "Current the REST API for themes is extremely limited. It only allows for listing themes and getting the current theme. However, there are lots theme related functions that are not possible to access via this api. This includes ( but it not limited to ) - Installing new themes - Network activating theme ( multisite only ) - Network deactivating theme ( multisite only ) - Active ( switch to theme ) - Deleting theme Any themes api should allow the patterns / structure of the plugins REST API, in it's params and responses. It is also worth noting, that have a multisite element, as themes can be network activated / deactivated." spacedmonkey Future Releases 41463 Improve REST API tests that don't perform any assertions johnbillion* REST API 4.7 normal normal Future Release enhancement accepted 2017-07-27T18:02:35Z 2022-09-01T22:54:20Z "There are a bunch of REST API tests that don't perform any assertions. This creates noise in the test results as they get marked as risky tests. These tests are present because their test class extends the abstract `WP_Test_REST_Controller_Testcase` class, which requires several methods to be implemented which don't make sense for all REST API routes. These tests can be improved so they do actually perform assertions related to their behaviour." johnbillion Future Releases 52840 Include filesize information in REST API response for all media types rachelbaker* REST API normal normal Future Release enhancement accepted dev-feedback 2021-03-17T21:50:29Z 2023-01-13T21:45:46Z "Requesting the `/media` REST API endpoint, only **audio** attachments include filesize information in the response data (in `media_details->filesize`). I suggest to check for each item if `filesize` is present, or else fill it in using the actual file. This would be pretty much in line with what is done in [https://github.com/WordPress/wordpress-develop/blob/fa05e5e7336a18c19fe6a94d68d30351876ee090/src/wp-includes/media.php#L3972-L3980 wp_prepare_attachment_for_js]. Making the information available locally, when creating the response data, is much more performant than having to request the file in one or more follow-up requests." tfrommen Future Releases 49179 Manage Post trackbacks within the REST API REST API 4.7 normal normal Future Release enhancement new has-patch 2020-01-12T18:23:05Z 2020-10-24T05:51:08Z "Hi, I've noticed, unlike the Classic Editor, the Blocks Editor does not include a place to add trackbacks to a post. After looking more into it, I've found a possible reason for it could be that the `WP_REST_Posts_Controller` doesn't support adding trackbacks. I believe it's weird the Blocks Editor includes a Discussion panel saying `Allow pingback and trackbacks` although it's only possible to add trackbacks from the Classic Editor. I suggest the attached as a primarily step before working from the Gutenberg GH repo to suggest a way to deal with this feature. In the meantime, if some of you need to send trackbacks from the Blocks Editor, you can use this [https://github.com/imath/retroliens plugin]. " imath Future Releases 39061 REST API pagination: Large INT passed to `paged` query arg doesn't fail properly joehoyle REST API 4.7 normal normal Future Release enhancement reopened 2016-12-04T18:43:51Z 2017-10-04T20:46:33Z "When an absurdly large value is passed to the REST API (e.g. `/wp/v2/pages?page=23924321212413345333`), it returns the first page of results instead of an error. The problem is during validation and sanitization of the value, where the passed value is run through `absint`, which returns another absurdly large value, which then gets nullified by PHP, which becomes `1`. {{{ wp> print_r( rest_sanitize_value_from_schema( 23452345346346345456567356, array( 'type' => 'integer' ), 'page' ) ); 3481259413623275520 => bool(true) wp> print_r( rest_validate_value_from_schema( 23452345346346345456567356, array( 'type' => 'integer' ), 'page' ) ); 1 => bool(true) wp> absint(23924321212413345333); => int(5477577138703794176) }}} Edge case, but worth noting since smaller values that are larger than the number of pages return an empty array (like if there are only 2 pages of posts, but 3 are requested). Related: #19728." morganestes Future Releases 38702 REST API: Add accessor functions for post_status and post_parent REST API 4.7 normal normal Future Release enhancement new has-patch 2016-11-08T02:26:23Z 2022-01-18T13:48:55Z "In order to enable better permission checks for Customiser Changesets, these need to be filterable. See [https://github.com/xwp/wp-customize-snapshots/issues/32 xwp/wp-customize-snapshots#32]. Split from #38701." rmccue Future Releases 41821 REST API: Add support for threaded comments REST API 4.7 normal normal Future Release enhancement new has-patch 2017-09-07T06:39:29Z 2020-09-24T18:08:59Z "(I don't think we have a tracking ticket for this already.) We should add support for threading comments, particularly in ""flat"" mode. Flat mode would allow threading in frontend code relatively easily. The only issue with this is that it will overflow `per_page`. We intentionally treat this as an indicator and occasionally have less items already (if they're filtered inside the `get_items()` loop, e.g.), so I don't think this is a huge issue. In addition, threaded mode should be opt-in in any case. Previously: https://github.com/WP-API/WP-API/issues/1612" rmccue Future Releases 46238 REST API: Allow conditional field registration REST API normal normal Awaiting Review enhancement new 2019-02-12T00:42:00Z 2020-10-25T12:49:27Z "`register_rest_field()` allows us to add additional fields to API call responses but it doesn't allow us to do so conditionally. in prior art we add a field and then remove it later when it's not needed. why would inclusion of a field be conditional? what is wrong with returning `null`? we came across this when wanting to add metadata to video files, which are `post` types and conflated with posts and other media attachments. we'd like to be able to just add fields to video file media requests and not pollute the responses for all of the other ""subtypes."" we'd also like to do it without resorting to surprising behaviors like adding and later removing them. in this ticket I'd like to propose two approaches to accomplishing this goal. the first is a bit clever but should make it possible to extend existing behaviors without breaking any code and without introducing further confusion on how to add fields. it uses a ""sentinel value"" passed into the `get_callback()` function which can be returned to indicate that the field should not exist. the second approach creates a new function `register_conditional_rest_field()` and provides a wrapped response format to indicate whether the field should be added. this approach is less idiomatic in my opinion as we're not used to returning wrapped values. --- I thought for sure I'd seen a discussion around this before but I couldn't find any tickets with my search. that being said I'm curious why this doesn't already exist as it seems like it could be a common need, though I'm not sure how the fact that media attachments are a bit odd in comparison to custom post types comes into play." dmsnell Future Releases 41616 REST API: Expose old slugs REST API 4.8.1 normal normal Future Release enhancement new has-patch 2017-08-12T05:32:45Z 2021-10-08T10:20:07Z "Expose the old slugs for all posts including custom post types in the REST API. For example, when building a React-powered app using the WordPress REST API the old slugs are required so that users can be automatically redirected if they clicked on an old link. To expose the old slugs I created a small plugin (see below): {{{#!php true, 'show_in_nav_menus' => true ) ) ; $args = array( 'get_callback' => 'get_old_slugs_for_api', 'schema' => null ); foreach ($post_types as $type) { register_rest_field( $type, 'old_slugs', $args ); } } function get_old_slugs_for_api( $object ) { //get the id of the post object array $post_id = $object['id']; //return the post meta return get_post_meta( $post_id, '_wp_old_slug' ); } }}} " crosescu 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 38813 REST API: Test schema registration for required fields. jnylen0 REST API normal normal Future Release enhancement assigned 2016-11-16T06:21:36Z 2019-11-30T10:53:13Z "Follow-up from #38792. For all endpoints included in WordPress core, we want to make sure arguments and parameters are consistently registered and expose a nice, stable API to the world. While we can check this manually, building it into the unit tests is even better. @jnylen0 wrote an initial version [https://gist.github.com/nylen/9021f6d19157a023a0a8a607a3adb28a in Node-based JS], so we can port this to PHP and use the built-in schema rather than sending a HTTP request." rmccue Future Releases 40748 Use REST API for Community Events REST API 4.8 normal normal Future Release enhancement new dev-feedback 2017-05-12T17:39:23Z 2020-10-25T03:56:50Z "#40702 introduced new Community Events to the News widget on the Dashboard screen, but it uses admin-AJAX. Converting to the REST API is a good opportunity to lay some groundwork for migration the rest of wp-admin in the future. The work for this was started in #40702, but it'll be easier to keep track of with a new ticket. I'm working on an updated version of `40702.11.diff` and will upload it soon." iandunn Future Releases 39473 get_routes() called multiple times within single REST request causing the rest_endpoints() filter to also fire more than once REST API 4.4 normal normal Awaiting Review enhancement new dev-feedback 2017-01-04T21:59:38Z 2023-01-19T23:28:07Z "Hi all, Many thanks for creating the REST API, and also for getting it into core! :) When I had a closer look at how to integrate this in our projects I noticed something peculiar with the rest_endpoints() filter: it is called multiple times over; in some cases twice, in others three times. So I did a little digging around and found that the root cause seemed to be the use of get_routes() at multiple locations: - in the rest_pre_dispatch filter (rest_handle_options_request) - in the rest_post_dispatch filter (rest_send_allow_header) - in the dispatch() itself - in the get_index() method - in the get_namespace_index() method After looking how these locations interact with each other, I couldn't detect any code which altered the generated route map between consecutive calls to get_routes(). I will add a patch in which I propose to store the generated route map in the class, and re-use that one instead of generating yet again the same array (and also re-filtering the same array). Since the name 'endpoints' is already taken, and being used in the initialization as well, I thought it would be prune to use another variable name: $route_map, which is also being used in the current doc-block. I did not profile this patch (not really sure how to do that), so I'm not sure if storing this rather large associative array is a good thing to do. However generating it multiple times (and re-filtering it also) may also be quite 'expensive'. Thanks, Ruud " ruud@… Future Releases 40365 Introduce a REST API endpoint for sites REST API normal normal Future Release task (blessed) new dev-feedback 2017-04-05T00:18:18Z 2020-04-03T05:00:47Z "It should be possible to manage sites in a multisite configuration through the REST API. * List sites: `GET wp/v2/sites/` * Retrieve a site: `GET wp/v2/sites/` * Create a site: `POST wp/v2/sites/` * Update a site: `PUT wp/v2/sites/` * Delete a site: `DELETE wp/v2/sites/` Data included in a site object should at least mirror the data available for the site in `wp_blogs`. Additional ideal pieces of data for a site include `blogname`, `blogdescription`, `home`, and `siteurl`. It's possible that creating a new meta table for sites can help developers register meta for inclusion with a site object (See #37923). Sites should be accessible by default for authenticated users only. Network (global) admins should have access to all sites. Site users should have access to the sites they are members of. The ""My Sites"" list is a great candidate for exploring how this will work. See #15317. As of the introduction of `get_sites()` in 4.6.0, retrieving sites is a much better experience. The methods used to create, update, and delete sites in multisite are not as pleasant right now. We should investigate each of these and determine what can be done to streamline the process. The first improvement is probably in creating a site. See #40364." jeremyfelt Future Releases 39186 Bulk actions not correctly applied when selecting bulk actions in both the top and bottom bulk actions dropdowns engelen Quick/Bulk Edit 4.7 normal normal Future Release defect (bug) assigned has-patch 2016-12-08T14:48:44Z 2023-02-28T16:25:04Z "In `WP_List_Table` objects, the bulk actions dropdown and ""Apply"" button is displayed twice: once below the table and once above the table. The `name` attribute of the bulk actions dropdown element is always set ""action"". This wouldn't be a problem if the top and bottom actions were two in different forms. However, both dropdown elements are in the `posts-filter`-form. You can start to see the problem here. Two form elements both have the same name, which yields unexpected behaviour when trying to apply bulk actions. Take the following use case, for example: - Select some posts from the posts list in `/wp-admin/edit.php`. - Select ""Edit"" from the bulk actions dropdown above the list table. - Select ""Move to Trash"" from the dropdown below the list table. - Click the apply button next to the dropdown on the bottom of the list table. - The submit request is sent. You would expect the posts to be moved to the trash, but instead, nothing happens. Screencast of bug: http://recordit.co/EjHAbw2KNr The solution I see would rename the dropdowns for the top and bottom dropdowns (they already have different names) and name the ""Apply"" buttons. Then, when one of the buttons is pressed, execute the corresponding bulk action. In any case, we shouldn't have any two form elements with the same name in a single form." engelen Future Releases 51852 """any"" value in ""post_type"" param in ""get_posts"" by default ignore attachments" Query normal normal Future Release defect (bug) assigned early 2020-11-23T09:45:48Z 2021-02-18T00:24:52Z "When creating a simple call to get all posts for all post types by default to the parameters are adding `post_status` parameter with `publish` value. {{{#!php 'any']); }}} To the `WP_Query` instance are supplied followed arguments: {{{#!php 5 ""category"" => 0 ""orderby"" => ""date"" ""order"" => ""DESC"" ""include"" => [] ""exclude"" => [] ""meta_key"" => """" ""meta_value"" => """" ""post_type"" => ""any"" ""suppress_filters"" => true ""post_status"" => ""publish"" ""posts_per_page"" => 5 ""ignore_sticky_posts"" => true ""no_found_rows"" => true ] }}} All attachment posts have `inherit` post status so by default are ignored in this query. To actually get all post types the first function parameters should be expended by `post_status` parameter with `['publish', 'inherit']` value. {{{#!php 'any', 'post_status' => ['publish', 'inherit']]); }}}" dam6pl Future Releases 18408 Can't wp_reset_postdata after custom WP_Query in an admin edit page audrasjb Query 4.7.2 normal normal Future Release defect (bug) assigned has-patch 2011-08-15T02:38:07Z 2024-02-19T22:14:25Z "While on an edit post page (or any post type), if you create a custom WP_Query object before the editor has been output, the post data from the custom WP_Query will fill out the edit post form, not the original content of the post that is actually trying to be edited. I found this out when trying to create a custom metabox in the 'side' context. You can reproduce this by inserting this code into a plugin: {{{ add_action( 'add_meta_boxes', 'myplugin_add_custom_box' ); function myplugin_add_custom_box() { add_meta_box( 'myplugin_sectionid', __( 'My Post Section Title', 'myplugin_textdomain' ), 'myplugin_inner_custom_box', 'post', 'side' ); } function myplugin_inner_custom_box() { global $post; $a = new WP_Query('post_type=page'); while($a->have_posts() ) : $a->the_post(); endwhile; wp_reset_postdata(); } }}} This happens because $wp_query->post is never defined in the admin load, which wp_reset_postdata relies on to reset the original post data. I am attaching a patch that defines $wp_query->post after the $post global has been defined. " ericlewis Future Releases 42164 Conditional Tags not working when using ugly URL Query 4.8.2 normal normal Awaiting Review defect (bug) new 2017-10-10T10:23:14Z 2017-10-10T13:54:21Z "When accessing a category archive via its pretty URL e.g. {{{ example.com/category/whatever }}} the conditional tag {{{ is_category() }}} returns '''true'''. Accessing the same category archive via its ugly URL {{{ example.com?cat=whatever }}} the conditional tag {{{ is_category() }}} returns '''false'''. I'm pretty sure this concerns other conditional tags too. This is not only a cosmetic flaw because it causes WP to use the wrong template. I've tested it with Twenty Seventeen and the homepage template was used in case of using an ugly URL. Due tue the ugly URL always work independently of permalink settings this is a bug in my opinion." petersplugins Future Releases 39540 NOT EXISTS meta condition doesn't work if meta has NULL value. Query 4.7 normal normal Future Release defect (bug) new 2017-01-10T16:42:19Z 2020-07-14T05:36:51Z "It seems problem exists since meta query class release. Right now NOT EXISTS works only if meta doesn't exist at all, but if it has NULL value we got incorrect result. I understand that better not use NULL values with metas at all, but you allow to write NULL as meta value, so please add possibility to check it. Just need to change string in class-wp-meta-query.php: {{{ $sql_chunks['where'][] = $alias . '.' . $this->meta_id_column . ' IS NULL'; }}} For example on: {{{ $sql_chunks['where'][] = ""$alias.meta_value IS NULL""; }}} And both cases will be covered. Thank you in advance. " avahura Future Releases 56992 The Loop displays incorrect data for queries started with `fields => 'id=>parent'`. Query 3.1 normal normal Awaiting Review defect (bug) new 2022-11-04T01:17:36Z 2022-11-04T01:17:36Z "Using the Loop on custom `WP_Query` objects started with `fields => 'id=>parent'` will set the global post object incorrectly. Instead of containing all data, the global post object will only contain the post's ID and parent fields. All other fields are the default value. The following test demonstrates the issue: {{{#!php post->create( array( 'post_type' => 'page' ) ); $child = self::factory()->post->create( array( 'post_type' => 'page', 'post_parent' => $parent ) ); $query = new WP_Query( array( 'fields' => 'id=>parent', 'post_type' => 'page', 'page_id' => $child, ) ); $query->the_post(); $global_post = get_post( null, ARRAY_A ); $specific_post = get_post( $child, ARRAY_A ); $this->assertEqualSetsWithIndex( $global_post, $specific_post ); } }}} The cause of the error is within `WP_Query::next_post()` which assumes the `WP_Query::$posts` property contains full post objects which isn't nessesarily the cause if a sub-set of fields is requested. See the [https://core.trac.wordpress.org/browser/tags/6.0.3/src/wp-includes/class-wp-query.php?marks=3447-3449#L3447 source code]. Due to #56948 the test above will currently throw an error on trunk but it will demonstrate the problem if you check out the 6.0 branch. I suspect this has been an issue since the fields parameter was introduced in #14777 for version 3.1 but I am unable to test that far back due to PHP versions I have available on my local config." peterwilsoncc Future Releases 51094 WP_Query.query with invalid post_status will return all metalandcoffee* Query 3.9 normal critical Future Release defect (bug) accepted dev-feedback 2020-08-21T12:18:59Z 2022-06-14T20:01:36Z "Hello, I noticed an issue with WooCommerce method {{{ wc_get_products }}} and dove into the issue. The problem was {{{ wc_get_products(array('status' => 'published')); }}} would return **ALL** posts, even trashed ones because of the ""published"" status is not a valid post status. I believe that behavior is unexpected that it should return **NO** posts. The issue appears to be this portion of {{{WP_Query.get_posts}}} that only known post statuses are added to the query: {{{#!php posts}.post_status = '$status'""; } else { $r_status[] = ""{$wpdb->posts}.post_status = '$status'""; } } } }}} I believe it would best if this method checks for any unrequested post status supplied in the query and either applies them to the query or produces an error. I would imagine this is a pretty major change." carsonreinke Future Releases 27015 WP_Query::get_queried_object() does not always work in 'pre_get_posts' Query 3.8 normal normal Future Release defect (bug) new has-patch 2014-02-05T00:58:42Z 2021-07-10T07:37:03Z "Related: #26627 The referenced ticket fixes the situation for categories. Inline docs indicate the method returns objects for the following query types: '''category, tag, taxonomy, posts page, single post, page, author'''. Some of these work, some do not. This became apparent from the forums: http://wordpress.org/support/topic/get_queried_object-no-longer-working-with-pre_get_posts-and-pretty-permalinks/ Props jeich Test setup. Trunk at r27067 used. (and 3.7 for regression check) Default setup of fresh install except for the following as plugin: * Hook 'pre_get_posts' and dump get_queried_object return if it is_main_query * Add custom taxonomy and associate with posts * Register CPT Change permalink setting to complete CPT rewrite registration Also modify the DB as follows to test various query types: * Add a tag to the Hello World post. * Add a custom taxonomy term to the Hello World post. * Add a CPT post The site was browsed through various pages using the default (none) permalink, then the month and name permalink. The result of getting a queried object was recorded: || ||=no permalink =||=month and name=|| ||uncategorized category ||stdClass object ||stdClass object|| ||tag archive ||NULL ||NULL|| ||taxonomy term archive ||stdClass object ||stdClass object|| ||CPT archive ||stdClass object ||stdClass object|| ||single post ||NULL ||NULL|| ||single CPT ||NULL ||NULL|| ||page ||NULL ||WP_Post object|| ||author archive ||WP_User object ||False|| ||posts page ||WP_Post object ||WP_Post object|| NULLs indicate failure of `get_queried_object()`. Except for tag archive, all NULLs returned are due to regression prior to 3.7. Why the tag archive failed in 3.8 is unclear, but the proposed patch addresses this issue as well as all other NULL returns. For those that don't know, the reason for different results with pretty permalinks enabled is different query vars are defined when rewrite rules are applied. The default no pretty permalinks does not use rewrite rules and the query vars can only be what is parsed from the request. " bcworkz Future Releases 44695 WP_Term_Query unexpected 'orderby' behaviour. Query 4.9.7 normal normal Awaiting Review defect (bug) new 2018-08-01T21:19:14Z 2019-08-27T18:33:22Z "I expected that `orderby` would behave in a similar way with `WP_Term_Query` as it does on other `*_Query` classes but it seems that `meta_value_date` and possibly some others is unsupported. Additionally `meta_type` doesn't function as expected either. These args: {{{ $args = array( 'taxonomy' => 'issues', 'number' => 5, 'meta_key' => 'issue_date', 'meta_type' => 'DATE', 'orderby' => 'meta_value_date', ); }}} Result in this query that has disregarded both `meta_type` and `orderby` in it's generation: {{{ SELECT DISTINCT t.*, tt.* FROM wp_terms AS t INNER JOIN wp_termmeta ON ( t.term_id = wp_termmeta.term_id ) INNER JOIN wp_term_taxonomy AS tt ON t.term_id = tt.term_id WHERE tt.taxonomy IN ('issues') AND tt.count > 0 AND ( wp_termmeta.meta_key = 'issue_date' ) ORDER BY t.name ASC LIMIT 5 }}} Could we get similar support for same named keys in `WP_Term_Query` as we have in other queries?" williampatton Future Releases 52559 When doing JOINs for meta queries the meta_key should be in the ON clause whenever possible. Query normal normal Awaiting Review defect (bug) new 2021-02-17T17:17:35Z 2021-04-26T07:45:57Z "Currently when doing `JOIN`s for meta queries the meta_key is only included in the `ON` clause if the meta compare is `NOT EXISTS`. In all other cases only the `post_id` is included. This means that the meta key is only filtered after the JOIN is done. Case in point, a meta_query that with 5 different keys generates the following query: {{{#!sql SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts LEFT JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id ) LEFT JOIN wp_postmeta AS mt1 ON ( wp_posts.ID = mt1.post_id ) LEFT JOIN wp_postmeta AS mt2 ON ( wp_posts.ID = mt2.post_id ) LEFT JOIN wp_postmeta AS mt3 ON ( wp_posts.ID = mt3.post_id ) LEFT JOIN wp_postmeta AS mt4 ON (wp_posts.ID = mt4.post_id AND mt4.meta_key = 'events_time_frame_end' ) WHERE 1=1 AND ( ( wp_postmeta.meta_key = 'events_date_till' AND wp_postmeta.meta_value >= '20210217' ) AND ( ( mt1.meta_key = 'events_date_till' AND mt1.meta_value > '20210217' ) OR ( ( mt2.meta_key = 'events_date_till' AND mt2.meta_value = '20210217' ) AND ( mt3.meta_key = 'events_time_frame_end' AND mt3.meta_value >= '14:59:19' ) ) OR mt4.post_id IS NULL ) ) AND wp_posts.post_type = 'events' AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'acf-disabled' OR wp_posts.post_status = 'dp-rewrite-republish') GROUP BY wp_posts.ID ORDER BY wp_postmeta.meta_value ASC LIMIT 0, 10; }}} This query takes 60 seconds on very well provisioned database with posts that each have 50 postmeta rows in a database with 50 million total postmeta rows. In contrast the following query: {{{#!sql SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts LEFT JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id AND wp_postmeta.meta_key = 'events_date_till' ) LEFT JOIN wp_postmeta AS mt1 ON ( wp_posts.ID = mt1.post_id AND mt1.meta_key = 'events_date_till' ) LEFT JOIN wp_postmeta AS mt2 ON ( wp_posts.ID = mt2.post_id AND mt2.meta_key = 'events_date_till' ) LEFT JOIN wp_postmeta AS mt3 ON ( wp_posts.ID = mt3.post_id AND mt3.meta_key = 'events_time_frame_end' ) LEFT JOIN wp_postmeta AS mt4 ON (wp_posts.ID = mt4.post_id AND mt4.meta_key = 'events_time_frame_end' ) WHERE 1=1 AND ( ( wp_postmeta.meta_value >= '20210217' ) AND ( ( mt1.meta_value > '20210217' ) OR ( ( mt2.meta_value = '20210217' ) AND ( mt3.meta_value >= '14:59:19' ) ) OR mt4.post_id IS NULL ) ) AND wp_posts.post_type = 'events' AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'acf-disabled' OR wp_posts.post_status = 'dp-rewrite-republish') GROUP BY wp_posts.ID ORDER BY wp_postmeta.meta_value ASC LIMIT 0, 10; }}} Takes 400ms and returns identical results. I believe the cause here is that because in the first query filtering is only done after the join and each event has 50 postmeta fields MySQL is first creating a virtual table with 50^4^ ( 4 because the last JOIN does include the meta_key ) rows joined resulting in 60.000.000 total that are then filtered back down. Adding the meta_key condition to the `ON` clause means we're only joining 1 ( or a small number in the case of the meta_key existing in multiple rows ) rows for each JOIN meaning the virtual table being created is significantly smaller thus having much better query performance. At the very least when there is any LEFT JOIN occurring then ALL `meta_key` conditions should be moved in the `ON` clause. Although it may be simpler to always have the `meta_key` condition in the `ON` clause." herregroen Future Releases 44964 `redirect_guess_404_permalink` doesn't support array in `post_type` var Query 4.9 normal normal Awaiting Review defect (bug) new dev-feedback 2018-09-19T09:35:59Z 2018-10-01T12:37:02Z `redirect_guess_404_permalink` doesn't support array in post_type var, but other core WordPress parts support it. viliamkopecky Future Releases 37530 is_front_page() is based on wrong data -> gives wrong results Query 4.5.3 normal normal Future Release defect (bug) new has-patch 2016-07-31T14:28:49Z 2020-01-07T20:25:04Z "1) is_front_page() is based on the SQL query, so it always gives back false when you try to use it eg at pre_get_posts. If it has no way to figure it out if it's the front page or not, it should return null instead 2) is_front_page() in themes gives the wrong result false back when you set an static page for the front page and then modify the main query on start page to posts or any other custom post type except page. This forces you to make an additionally SQL query instead of using the main query to build a custom front page. Both is because of this: https://core.trac.wordpress.org/browser/tags/4.5.3/src/wp-includes/query.php#L4458 . This does not really make sense to get the front page." TheInfinity Future Releases 58234 sanitize_title_with_dashes fatal error when query var value is an array in php 8 Query normal normal Awaiting Review defect (bug) new reporter-feedback 2023-05-02T13:38:13Z 2023-08-08T23:23:11Z "Using latest WordPress development version 6.3-alpha-55505-src, when submitting a form with field values that are array, and the array key is one of WordPress query vars, that causing sanitize error for 'post_name' parameter in get_posts function. Example to replicate: - make sure to register custom post type E.g custom_post_type. - submit the following form on your test WordPress website. {{{

}}} " mouhdev Future Releases 56105 Call update_post_parent_caches in the_post function in WP_Query class Query normal normal Awaiting Review enhancement new 2022-06-30T12:01:38Z 2023-04-20T12:55:57Z "Hello Team, In {{{the_post}}} function {{{class WP_Query}}}, {{{update_post_author_caches}}} is already in use but not {{{update_post_parent_caches}}}. I am not sure if it is because of {{{update_post_parent_caches}}} calls the private function {{{_prime_post_caches}}} or what." priyankkpatel Future Releases 57416 Do not split query if requesting one post spacedmonkey Query 3.0 normal normal Future Release enhancement assigned dev-feedback 2023-01-03T13:49:30Z 2023-11-16T12:36:42Z When using WP_Query and requesting posts_per_page = 1, there is little to no value in splitting the query and priming posts using _prime_post_caches. This results in one query to get the posts and another to prime it. This means two database queries when this could simply be one. spacedmonkey Future Releases 39447 Improvement to the get_the_posts_navigation SergeyBiryukov Query normal normal Future Release enhancement reviewing 2017-01-03T14:36:31Z 2021-01-27T06:28:38Z "[https://core.trac.wordpress.org/browser/tags/4.7/src/wp-includes/link-template.php] Here at ''get_the_posts_navigation'' the function check global wp query('''Globals['wp_query'\]''') for displaying markup. But in many cases we may need to display the navigation for '''custom wp query''' which has unique query options(max_num_page, post_per_page). So it would be great, if we can check the our custom query's max_num_page. Hope it make sense. Thank you " thirumani02 Future Releases 41678 Make sure all field returns use filters in WP Query Query 1.5 normal normal Awaiting Review enhancement new dev-feedback 2017-08-20T13:01:32Z 2023-04-20T13:19:18Z Currently if fields is set to either `id` or `id=>parent`, it doesn't run through all the filters as these return early. spacedmonkey Future Releases 19653 Order by meta field forces ignore of null records Query normal normal Future Release enhancement new has-patch 2011-12-23T15:11:45Z 2019-03-29T18:34:21Z "When doing a sort on posts with a meta value, the way the SQL is currently generated in meta.php creates a condition where records that DO NOT have the queried meta value are excluded from the results. This may or may not be the desired behaviour, but we don't give developers the choice without resorting to custom queries or manual rewrites of large swathes of the $clauses array. The issue: the way WP_Meta_Query->get_sql() creates the join on the meta key is by setting an inner join on wp_postmeta and then adding the key test to the where clause. I would suggest writing an outer (left) join on wp_postmeta, with the key condition in the join. This would also eliminate any potential future ambiguity if, for example, you are sorting on one meta key but filtering on another, since the key condition would be within the join clause, not the where clause: {{{ LEFT JOIN wp_postmeta ON wp_posts.ID = wp_postmeta.post_id AND wp_postmeta.meta_key = 'my_custom_field_name' }}} Related to ticket #18158 is the question of how we expose this to the developer in the query API. {{{ 'meta_key' => self::get_meta_key( 'my_custom_field_name' ), 'orderby' => 'meta_value', 'exclude_empty_meta' => false }}} If this gets any traction I would be happy to submit a patch." tomauger 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 45084 WP_Term_Query multiple 'orderby' support Query normal normal Future Release enhancement new has-patch 2018-10-11T16:15:36Z 2021-03-03T20:27:19Z "Just like in the regular WP_Query it would be awesome if it supported multiple orderby values (array or space separated). I'm currently busy with a patch but the I would like some feedback and help with creating unit tests. Examples: {{{#!php 'meta_value name', 'order' => 'ASC', ); }}} {{{#!php array( 'meta_value' => 'ASC', 'name' => 'ASC', ), ); }}} " keraweb Future Releases 49149 Write tests for WP_Query Query normal normal Awaiting Review enhancement assigned 2020-01-07T22:01:10Z 2020-02-20T02:32:06Z "WP_Query is one of the most critical classes in WordPress. It holds a lot of features and complicated rules to generate the SQL queries to fetch posts from the databases. Working on bug fixes and new features for it is very tricky because one is always afraid that any change to it could silently break things and tear the world apart. One way to make us feel more secure when working with this class is to have better test coverage for it. Looking at the tests we currently have I found very few tests for this class. I've created this ticket to organize and receive patches to add tests to this class. Below I organized the WP_Query parameters we should, at first, create tests for. Once we have tests for them individually, we can think of a way to write tests that combine different parameters. {{{ * Author params * author * author_name * author__in * author__not_in * Category params * cat * category_name * category__and * category__in * category__not_in * Tag params * tag * tag_id * tag__and * tag__in * tag__not_in * tag_slug__and * tag_slug__in * Tax_query * Meta_query * date_query * post_mime_type * fields * name * page_id * pagename * post_parent * post_parent__in * post_parent__not_in * post__in * post__not_in * post_name__in * has_password * post_password * post_type * post_status * comment_count * nopaging * posts_per_page * offset * paged * ignore_sticky_posts * order and orderby paramaters }}} PS - what motivated me to open this ticket (and start working on these tests) was #48556 and #44737" leogermani Future Releases 30184 Author page and category Query 3.1 normal normal defect (bug) new has-patch 2014-10-29T19:20:41Z 2019-06-04T20:47:56Z "Got errors like next in debug.log PHP Notice: Undefined property: stdClass::$ID in /www/test1/wp-includes/query.php on line 4074 PHP Notice: Undefined property: stdClass::$nickname in /www/test1/wp-includes/query.php on line 4076 PHP Notice: Undefined property: stdClass::$user_nicename in /www/test1/wp-includes/query.php on line 4078 In wp-includes/query.php we have the method {{{ public function is_author( $author = '' ) { if ( !$this->is_author ) return false; if ( empty($author) ) return true; $author_obj = $this->get_queried_object(); $author = (array) $author; if ( in_array( $author_obj->ID, $author ) ) return true; elseif ( in_array( $author_obj->nickname, $author ) ) return true; elseif ( in_array( $author_obj->user_nicename, $author ) ) return true; return false; } }}} But if we query a author page with category param queried_object actually will be the category term object, so next patch prevent such problems {{{ public function is_author( $author = '' ) { if ( !$this->is_author ) return false; if ( empty($author) ) return true; $author_obj = $this->get_queried_object(); if ( ! is_a( $author_obj, 'WP_User' ) ) return false; $author = (array) $author; if ( in_array( $author_obj->ID, $author ) ) return true; elseif ( in_array( $author_obj->nickname, $author ) ) return true; elseif ( in_array( $author_obj->user_nicename, $author ) ) return true; return false; } }}} " dimitrov.adrian Future Releases 23309 Not all WP_Query::query_vars get updated during WP_Query::get_posts() Query normal normal defect (bug) new early 2013-01-28T15:40:56Z 2019-06-04T20:43:47Z "There is a lot of logic within the WP_Query::get_posts() method that fills in missing query vars with defaults and manipulates others based on the rest of the query. However, some of the final states for many of the variables aren't updated in the WP_Query::query_vars array. For example, the post type is lost as a local variable and post_status is used for building compiling mysql expressions, but never directly updated. The result is that any plugins that want to recreate the query for another system, (ie, an external search provider) must directly copy much of the business logic that WP_Query::get_posts() has embedded in it in order to fill in for the incomplete query_var array. " prettyboymp Future Releases 30911 Overhaul post_status logic in WP_Query Query normal normal defect (bug) new 2015-01-05T15:24:11Z 2019-06-04T20:48:22Z "`WP_Query` filters based on post_status in two different places: 1. When building the main SQL query (`SELECT ID FROM $wpdb->posts`...). https://core.trac.wordpress.org/browser/tags/4.1/src/wp-includes/query.php#L2946 This block is responsible for parsing the 'post_status' query var, and rectifying these passed post_statuses with the 'perm' param, the logged-in user's permissions, and whether `is_admin()`. (The ability to query by 'post_status' dates from [5575].) 2. On `single` queries (`is_page()`, `is_single()`), additional filtering happens *after* the query. https://core.trac.wordpress.org/browser/tags/4.1/src/wp-includes/query.php#L3511 The intended purpose of this block is to ensure that Preview works (since posts being previewed generally are not published). The current incarnation of the preview logic (ie, living in `WP_Query`) was introduced in [2523]. These two 'post_status' blocks have two different purposes and two different histories, but they interact in a number of problematic ways. Just a few of the problems: a. Querying posts with 'fields=ids' means that the post ids are returned before the second filter block gets a chance to run. As a result, certain `WP_Query` objects (eg 'p=123&post_status=trash') can return different post IDs depending on whether you request 'fields=ids'. b. Values passed to the post_status parameter of `WP_Query` are sometimes overridden forcibly, based on logged-in user status. In an ideal world, `WP_Query` would not make any essential reference to the logged-in user. Realistically, we can't change some of this behavior for reasons having to do with backward compatibility. But there are places where the current user logic could be reworked so that it provides defaults, which can then be overridden by the params passed to `WP_Query`. Some relevant tickets: #28568, #29167 c. Filtering out non-previewable posts after the main query has taken place means doing more SQL queries than necessary in cases where post_status=draft and `is_single()`. d. Filtering out non-previewable posts after the main query has taken place can result in certain sorts of data leakage. See eg #30910. e. Having two separate blocks that filter results based on post_status makes unnecessarily complicated to fix post_status bugs. See eg #30530, #22001, #23309. My initial thought is that the second block should be removed. Preview logic should either be merged with the first block of post_status parsing logic that runs when building the main post query, or it should be moved into a separate query_var, which would then be passed when making a Preview request. In general, the challenge here is to ensure that the default post_status whitelist is properly sensitive to the permissions of the logged-in user - which sometimes means building clauses like `(post_status = 'publish' OR ( post_status = 'private' AND post_author = 123 ))`. I've started to write some unit tests that describe the (weird and complicated) existing behavior. See #29167 [31047]." boonebgorges Future Releases 34660 Query breaks when nopaging = false and posts_per_page = -1 Query 4.4 normal normal defect (bug) new has-patch 2015-11-11T16:06:20Z 2019-06-04T20:53:11Z "Whenever `nopaging = false` and `posts_per_page = -1`, the SQL query breaks because the LIMIT clause is set to: `LIMIT 0, -1` This patch ensures that `nopaging` is set to TRUE whenever `posts_per_page = -1`." mgibbs189 Future Releases 18513 Searching with explicit post types unsets page post type Query 3.2.1 normal normal defect (bug) new dev-feedback 2011-08-24T22:13:08Z 2022-02-12T20:43:32Z "Tested on WP 3.2.1, Twenty Eleven with no plugins, multisite. If I explicitly limit a search query via a GET request using an array of post_type values, the post_type for page is automatically excluded. To reproduce: * Do a search on a WP install (perhaps through a modified search form), such that the URL is like: http://example.com/?post_type[]=post&post_type[]=page&post_type[]=attachment&s=Test or http://example.com/?post_type[]=post&post_type[]=page&post_type[]=book&s=Test That's searching for ""Test"" on post, page and attachment/book post types. * Adding the following to a theme's functions.php: {{{ add_filter( 'pre_get_posts', 'wpcpt_search' ); /** * * @param array $query */ function wpcpt_search( $query ) { if ( ! $query->is_search ) return $query; print_r( $query->query_vars ); return $query; } }}} That spits out (and seemingly confirmed via the values shown in the Debug Bar plugin) the following at the beginning: {{{ Array ( [s] => Test [post_type] => Array ( [0] => post [2] => attachment ) }}} and only returns results for posts and attachments (or books). The fact that key 1 is missing makes me think that page was in the array at some point, but it's been unset, but I can't see where, or why, this might be done. (When no post_type is set, giving a post_type of 'any', which in turn gives all of the non-excluded_from_search post types, then page is one of the array values, and the search results correctly include pages.) " GaryJ Future Releases 15667 wp_list_pages, if it finds no pages to display, shows random child pages instead because of a bug in get_pages() jackreichert Query 3.0.2 normal minor defect (bug) assigned has-patch 2010-12-03T19:12:46Z 2019-06-04T20:41:37Z "How to reproduce:[[BR]] - About page is published - additionally, there is a number of parent pages[[BR]] - these each have a number of children[[BR]] - when calling wp_list_pages(), the ""exclude"" attr excludes all parent pages, and display only the About page. This works as long as there is at least 1 other page published that is not in the list of excluded IDs. In this example, as soon as the About page is set to ""draft"", wp_list_pages stops working correctly. So... with no other pages besides the excluded ones published, we do this: 1) wp_list_pages('title_li=&depth=1&exclude=3,5,7'); => wp_list_pages SHOULD return nothing, but instead it displays all child pages of the first parent page ID in the ""exclude"" attr (here: 3). Now we now add the ""exclude_tree"" attr just for fun: 2) wp_list_pages('title_li=&depth=1&exclude=3,5,7&exclude_tree=3,5,7'); => should again return nothing, but instead, it displays the first-ever published child page globally (here: a child page of 5). It looked like random behavior at first but I've been able to identify the above pattern. I'm guessing it's a failing condition somewhere in the function." bobsoap Future Releases 15249 Filtering get_search_sql for advanced queries Query 3.1 normal normal enhancement assigned 2010-10-29T07:00:35Z 2019-06-04T20:41:32Z "Currently in the code for 3.1 (trunk) there are no filters running on the new function get_search_sql which would be useful for plugins to perform more complex MySQL functionality on specific columns. I suggest adding a filter ;)" sc0ttkclark Future Releases 25190 Improve name/pagename query variable mapping Query normal normal enhancement new 2013-08-30T08:12:13Z 2019-06-04T20:44:46Z `WP_Query` performs some mappings from custom query variables to `pagename` and `name` for custom post types. This could be improved so that `pagename` is not used for hierarchical post types when a top-level item has been requested. We could also do some mappings between `pagename` and `name` in case the incorrect query variable was used (see #16323). duck_ Future Releases 36881 Improved hot-wiring of set_found_posts Query normal normal enhancement new has-patch 2016-05-18T22:45:22Z 2019-06-04T20:59:10Z Currently you can filter posts_request and posts_result to hot wiring the query object add caching. However, this means that in many cases the set found posts method then never gets called. This means that found posts is un-filterable. The set found posts needs to be called after the post results filter. spacedmonkey Future Releases 33306 Only Query for author ID if user is member of blog Query 4.3 normal normal enhancement new 2015-08-07T17:45:42Z 2019-06-04T20:51:04Z In WP_Query if a user is part of the multisite install but is not part of the current blog the query is still altered from only finding public posts to finding public posts and those that are private and from that author_id. While this never has an impact on the returned end results, not having private and author ID as a parameter lets MySQL optimize the queries and in the circumstances this has been tested on (large site, lots of posts lots of users) makes them run faster. On a site without multisite installed this will have the same behavior. sboisvert Future Releases 20352 Use str_getcsv() to parse search terms in WP_Query Query normal normal enhancement new has-patch 2012-04-03T23:05:25Z 2019-06-04T20:43:04Z "We use an [http://core.trac.wordpress.org/browser/tags/3.3.1/wp-includes/query.php#L2183 ugly regex] to split search terms like these: {{{ term1 term2 ""exact match"" }}} We could use str_getcsv() instead, for better readability." scribu Future Releases 23044 adjacent_image_link() needs optimization Query 3.5 normal normal enhancement new has-patch 2012-12-22T05:04:20Z 2019-06-04T20:43:34Z "`adjacent_image_link()` is really slow and stupid. It queries for '''all''' of the images attached to that post. And then it picks the previous or next one in PHP. And there's no caching, so you'll typically get this happening '''three times''' on an attachment page, (image [linked to next], prev link, next link). We should actually just make the query grab the ONE image we want." markjaquith Future Releases 44236 Maintain consistency between privacy export report and archive filenames GripsArt Privacy 4.9.6 low minor Future Release defect (bug) assigned has-patch 2018-05-26T00:03:07Z 2019-01-27T09:03:40Z "Prior to r43180, the export `.zip` filename changed every time it was regenerated; after that commit, it was reused to ensure links aren't broken (see #43905). That commit didn't do anything to the `.html` filename, though, so after the initial regeneration, the value of `$obscura` will not match between the two filenames. I don't think this presents any issues for Core, and might not for plugins either, but it seems like they should be consistent, just to be safe. If a plugin hooks into `wp_privacy_personal_data_export_file_created`, it may reasonably assume that the filenames to match, and do something like `str_replace( '.html', '.zip', $foo )`. That seems unlikely, since both filenames are passed to the callback, but it's better to be safe than sorry." iandunn Future Releases 44084 Privacy: The personal data export file should be generated in the user's locale garrett-eclipse Privacy 4.9.6 normal normal Future Release defect (bug) assigned 2018-05-15T00:26:10Z 2020-10-08T07:01:36Z Similar to #43985, the HTML file containing the personal data export should be translated into the locale the user has selected for their profile, with a fallback to the site's locale. coreymckrill Future Releases 56694 Uncached database read for logged in users when Privacy Policy Page is deleted Privacy 5.7 normal normal Awaiting Review defect (bug) new 2022-09-29T20:47:20Z 2022-09-29T21:24:19Z "As a logged in WordPress user navigating around WordPress Admin, a hook fires on every admin page that attempts to notify you whether or not the suggested Privacy Policy text (in WordPress) has changed, sourced from the ""Privacy Policy Guide"" settings page. The Privacy Policy itself is a Page, and the numeric ID of that page is saved as a Setting. If the WordPress Page (that matches the ID that is set as the Privacy Policy Page setting) is permanently deleted, WordPress still attempts to query the database to look for this Page. This results in a single database read query that will never find what it is looking for, and is not cached because it does not exist, causing it to happen again on every subsequent page that any logged in user navigates to inside of WordPress Admin. * This user would normally never know this database chatter is happening because it isn't anything they are intentionally looking for * I discovered this misbehavior while using the Query Monitor plugin on a dev site, and noticed that there was always 1 uncached database read Screenshot of the query & call stack will be attached below." johnjamesjacoby 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 43879 Add tools for anonymizing of post authors tz-media Privacy normal normal Future Release enhancement assigned dev-feedback 2018-04-27T13:46:24Z 2020-09-07T08:30:09Z "Logged-in users that post content can request the removal of their personal data. So we should add functionality to add the posts to the erasure infrastructure that is already committed to trunk. See #43442 for reference (anonymize commenters)." TZ Media 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 44034 Privacy: Introduce a function to count user requests by type garrett-eclipse Privacy normal normal Future Release enhancement assigned has-patch 2018-05-10T11:13:55Z 2020-10-12T21:39:38Z "The user request list tables use {{{WP_Privacy_Requests_Table::get_request_counts( $type )}}} to count user requests by type. If export- and erase bubble counts will be added in #44000 and if e.g. plugins or core will add request stats to the dashboard ( e.g. ""At a glance"" or ""Activity"" metaboxes), then it makes sense to introduce a function like: {{{ wp_count_user_requests( $type ) }}} where type is either {{{'remove_personal_data'}}} and {{{'export_personal_data'}}}. An alternative would be if {{{wp_count_post( $post_type = 'user_request' )}}} would support {{{$post_name}}} as well, for the request types. " birgire Future Releases 47279 $post object passed to clean_post_cache action can contain outdated values Posts, Post Types normal normal Future Release defect (bug) new 2019-05-15T14:28:45Z 2019-05-15T21:57:01Z "This occurs when publishing or deleting a post. In the `clean_post_cache()` function, `get_post( $post )` is called and assigned to `$post`. At that moment, the value of the `$post` parameter `post_status` = `draft` if publishing, `publish` if deleting the post. There is then a call to `wp_cache_delete( $post->ID, 'post_meta' );`, which correctly updates the value of post_status, if you perform another `get_post()` right after. But, the `$post` object is then passed to the action `clean_post_cache`, with the outdated values instead. So if someone hooks a function on `clean_post_cache`, and uses the `$post` object passed, it's going to receive incorrect values compared to what would be expected. But if you perform a `get_post()` inside that function, you will get the correct values. I only tested this with the `post_status` parameter, but this might be affecting others too. I would expect that the `$post` object passed to the `clean_post_cache` action contains up-to-date values." tabrisrp 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 41448 Contributors shouldn't be able to change the date of their drafts Posts, Post Types 2.7 low normal Future Release defect (bug) new has-patch 2017-07-26T12:33:48Z 2017-08-04T13:24:10Z "(I'm guessing that) contributors shouldn't be able to change a post's publication date—that's why the ''Publish'' box doesn't include the date when logged in as a contributor in the first place. However, if a contributor quick edits a post in the ''All Posts'' screen, they'll be able to change the post's date. We should remove the date field from the ''Quick Edit'' form. Or, alternatively, we should allow contributors to edit this date while they're editing a post. Either way, both screens should be consistent." davilera Future Releases 50002 Hack in get_sample_permalink() can cause filters like post_link, and pre_post_link to have inaccurate post_status in admin Posts, Post Types 5.4 normal normal Awaiting Review defect (bug) new has-patch 2020-04-24T20:07:13Z 2020-04-26T12:35:32Z "For context: https://github.com/aubreypwd/WordPress/issues/5 When editing a post (that is a draft) in the admin, add a filter to `post_link` you'll notice that the pass for `get_sample_permalink()` shows that `$post->post_status` is set incorrectly (un-truthfully) to `publish`. This is because of a 12 year old block of code in `get_sample_permalink()`: {{{ // Hack: get_permalink() would return ugly permalink for drafts, so we will fake that our post is published. if ( in_array( $post->post_status, array( 'draft', 'pending', 'future' ) ) ) { $post->post_status = 'publish'; $post->post_name = sanitize_title( $post->post_name ? $post->post_name : $post->post_title, $post->ID ); } }}} In order for `post_link` and even `pre_post_link` filters to pass accurate info about a post, the patch I have attached is my first attempt at ensuring `get_sample_permalink()` still gets the same result, while not affecting `post_status`. Obviously I tested this, but I still feel some more testing will need to be done. " aubreypwd 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 41471 Page dropdown walker must check selected against value field Posts, Post Types 4.9 normal normal Future Release defect (bug) new has-patch 2017-07-28T03:36:18Z 2019-02-20T21:18:08Z `Walker_PageDropdown` only checks `selected` with the page `ID` and ignores `value_field` option. geminorum Future Releases 11235 "Pages whose ancestors are not all ""published"" cannot be used as parents for other pages." Posts, Post Types 2.9 normal normal Future Release defect (bug) new dev-feedback 2009-11-23T01:04:01Z 2019-06-04T18:12:41Z Pages with trashed parents cannot be used as parents for other pages (they do not appear on the list). caesarsgrunt Future Releases 42323 Posts vs CPT user permissions issue Posts, Post Types 4.9 normal normal Awaiting Review defect (bug) assigned has-patch 2017-10-24T14:51:56Z 2017-10-24T15:10:29Z "We have the following use case: 1. User does not have access to create new ""Posts"" 2. User does have access to create new Product Submissions (CPT post type) With these prerequisites, when the user clicks on ""New Product Submission"" from the list view (or the edit view), they get the No access message. This happens because in core we check for `edit.php` no_priv instead of `edit.php?post_type=product_submission`." bor0 Future Releases 3670 Removing CDATA close tag ( ]]> ) unbalances the CDATA block andy Posts, Post Types 2.1 normal minor Future Release defect (bug) new has-patch 2007-01-25T05:55:47Z 2023-02-10T03:00:14Z "I'm not sure if this is a bug per se, but it breaks included JS in my posts that are escaped with a CDATA section. I've basically commented out the following line in the_content() every time I upgrade: //$content = str_replace(']]>', ']]>', $content); A user on the wp-testers list indicated that this was part of making sure that included CDATA blocks didn't break RSS feeds. I don't use CDATA sections directly in my RSS feeds, so I haven't tested this. In my particular case, the JS is used to embed Flash movies (e.g. YouTube videos) in an XHTML compliant way (without embed tags). I have a custom plugin I've written that strips out the JS and replaces it with the embed tag in the RSS feed. Perhaps we should use a flag to activate this when the app is going through a feed. Ideally, though, it would simply be removed. Odds are that the CDATA block is being used for a JS block in a post body, and since most RSS aggregators don't allow JS by default, it would be safe to simply remove CDATA blogs if is_feed() is set." scenic Future Releases 41226 "Static ""posts page"" preview not working" Posts, Post Types normal normal Awaiting Review defect (bug) reopened has-patch 2017-07-03T09:41:05Z 2019-02-17T13:21:59Z "My site has both a static front page and a static posts page. The former is intended to be the site's home page, the latter the blog section home page. The static posts page is a regular page, created through the admin interface. Some parts of it are editable by admin - this is a design choice driven by project needs. Whenever I update the static posts page through the editor, the preview doesn't work: '''clicking on the ""preview"" shows the preview of the ""front page"" instead.''' Apart from that, everything works on the front-end side, and I can edit and save the posts page as needed. Unfortunately, as the project is being currently developed, I can't publicly publish urls or screenshots at the time." emross 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 59354 Unnecessary queries performed when updating a post without providing categories or tags Posts, Post Types normal normal Awaiting Review defect (bug) new 2023-09-14T22:43:53Z 2023-09-14T22:43:53Z "Given an existing post with at least some categories or tags present, updating the post via `wp_update_post()` (which calls `wp_insert_post()`) with data that does not include categories or tags, many unnecessary taxonomy-related database queries are performed. This slows down the saving significantly. * If `$postarr` doesn't contain a `post_category` element, there's no point in calling `wp_set_post_categories()`. * If `$postarr` doesn't contain a `tags_input` element, there's no point in calling `wp_set_post_tags()` == Todo == * Need tests to verify the above is correct * Need a list of queries that are performed before and after the change == To reproduce == 1. Publish a post with at least one category 2. Update the post via: {{{#!php $id, 'post_content' => 'Hello, World!', ] ); }}} 3. Observe that a significant number of unnecessary taxonomy queries are performed" johnbillion Future Releases 59027 Weekly wp_get_archives has invalid link (link for month instead of year) Posts, Post Types 0.71 normal normal 6.6 defect (bug) new dev-feedback 2023-08-09T13:43:54Z 2024-02-05T20:34:38Z "If you call `wp_get_archives` function with `type` set to weekly, the resulted link contains two parameters: m => year, w => week. This results in unwanted behaviour, as you get a month like `2023` which is invalid. The link should contain ?y={year}&w={week}. " filipac Future Releases 37671 Emptying Bin with large amount of posts results in whitescreen Posts, Post Types normal normal Future Release enhancement new 2016-08-15T16:01:56Z 2017-08-06T00:31:10Z "When the Bin has a large amount of posts, e.g over 1,500, clicking Empty takes a long time to load, several minutes. After it finishes, it loads a blank white page and has only deleted about 75% of the posts. There's ~500 remaining." atomicjack Future Releases 41674 More granular capabilities for restoring and permanently deleting trashed posts Posts, Post Types normal normal Awaiting Review enhancement new 2017-08-19T16:00:27Z 2017-08-19T16:00:27Z "Currently the user capability required for restoring a trashed post or permanently deleting a trashed post is `delete_post`, which maps to `delete_posts`. There should be a separate capability for each of these actions. Suggestion: * `restore_trashed_post` which maps to `restore_trashed_posts` which maps to `delete_posts`. * `delete_trashed_post` which maps to `delete_trashed_posts` which maps to `delete_posts`. Emptying the trash should use the `delete_trashed_posts` capability. This allows for more granular control over which users can or cannot restore or permanently delete posts." johnbillion Future Releases 14017 "New template ""tag"": get_custom_field()" obenland Posts, Post Types 3.0 normal normal Future Release enhancement assigned dev-feedback 2010-06-21T04:13:03Z 2022-08-14T14:59:34Z "It would be helpful to have a way to retrieve a custom field value that is somewhat agnostic of current context. '''Current way to do this''' In the header (i.e., before the Loop), one has to access the currently-queried object to get a custom value, with something like this: `$value = get_post_meta($GLOBALS['wp_query']->get_queried_object_id(), 'field', true);` In the Loop: `$value = get_post_meta(get_the_ID(), 'field', true);` And, lots of tutorials out there tell people to do things like the following, with varying degrees of success (depending on variable scope): `$value = get_post_meta($id, 'field', true);` or `$value = get_post_meta($post->ID, 'field', true);` '''My proposed function (or ""template tag"")''' mixed '''get_custom_field''' ( string ''$fieldname'' [, int ''$post_id'' ] ) `$value = get_custom_field('field');` It picks the current object like so: {{{ Passed post object ID? / \ yes no | | use it | | within Loop? / \ yes no | | use current | Loop ID | | currently queried object is singular? / \ yes no | | use its ID ID = 0 }}}" filosofo Future Releases 28172 edit_post() should call {un}stick_post() before calling wp_update_post() Posts, Post Types 4.0 normal normal Future Release enhancement new changes-requested 2014-05-08T01:37:34Z 2023-01-26T17:48:29Z "In a plugin I'm writing I have a need to hook into the `save_post` action and decide whether to allow a given post to be sticky based on postmeta associated with that post (and possibly other posts). However, if the function I attach to the `save_post` action calls `{un}stick_post()` it doesn't have the desired effect because of the way `edit_post()` is written. In particular, lines 320-332 of [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/post.php#L320] are: {{{ wp_update_post( $post_data ); // Now that we have an ID we can fix any attachment anchor hrefs _fix_attachment_links( $post_ID ); wp_set_post_lock( $post_ID ); if ( current_user_can( $ptype->cap->edit_others_posts ) ) { if ( ! empty( $post_data['sticky'] ) ) stick_post( $post_ID ); else unstick_post( $post_ID ); } }}} The `save_post` action is fired within `wp_update_post()` (technically, it is fired by `wp_insert_post()` which is called by `wp_update_post()`). Since `edit_post()` calls `{un}stick_post()` '''after''' it calls `wp_update_post()`, anything I do in my `save_post` function with regard to whether the post should be sticky is undone! Hence, I suggest changing the relevant portion of `edit_post()` to {{{ if ( current_user_can( $ptype->cap->edit_others_posts ) ) { if ( ! empty( $post_data['sticky'] ) ) stick_post( $post_ID ); else unstick_post( $post_ID ); } wp_update_post( $post_data ); // Now that we have an ID we can fix any attachment anchor hrefs _fix_attachment_links( $post_ID ); wp_set_post_lock( $post_ID ); }}} Is there a specific reason why `edit_post()` currently calls `wp_update_post()` before `{un}stick_post()`? (it isn't apparent to me) Another option I investigated was whether it was possible to have my plugin change `$post_data` via a filter but I couldn't find one. If others agree that this change would be good and wouldn't break anything else, I'll submit a patch. [Note: I went back and forth on whether to call this a bug or an enhancement. It's a bug in the sense that there is certainly an unexpected result ({un}sticking a post in a `save_post` action is undone...I lost about an hour trying to figure out why my `save_post` function wasn't doing the right thing); But it is an enhancement in the sense that core, itself, is not broken]." pbiron Future Releases 37376 Make it possible for custom post type to have an archive but no single Posts, Post Types 4.6 normal normal Awaiting Review feature request new has-patch 2016-07-15T17:55:34Z 2021-08-24T05:07:13Z "Very commonly we'll have testimonials, faqs, and such custom post types, which warrant an archive, but don't make sense to have a single. It's possible to have a post type with no archive and a single, but not the other way around. Funnily enough, I find that we far more often could use what isn't available versus what is. There are workarounds. One option is to make it a non-publicly-queryable post type and use a page template or something to display the results. Another option I've seen around is to hook into template_redirect on the single and redirect the user. Chances are there's no links on the front-end, so this really only occurs when users click on the link from edit-post admin-side. Another thing to consider here is SEO plugins and the like which look to the definition of the CPT to build the sitemap. The redirect method ends up putting useless links in the sitemap. The page template method works fine, but obviously means the CPT has to be queried separately. Would there be a downside to adding a sibling `has_single` option? If it's true by default then it's backwards compatible, and the single rewrites simply reflect the option." jason_the_adams Future Releases 12706 Custom post status bugs Posts, Post Types 3.0 normal normal Future Release task (blessed) reopened has-patch 2010-03-25T14:41:39Z 2022-06-02T13:42:36Z "A developer should be able to register a custom post status using `register_post_status()`. The admin UI (including post submit box and quick edit) should reflect this new custom post status. Furthermore, there are many hard-coded references to 'draft' and 'pending' statuses in core that should properly use the post status API. All existing arguments to `register_post_status()` should be fully implemented, should also support per-post-type arguments. As things get implemented across core, there will likely be a need for supporting capabilities and bits of API. Related: #23169 (register_post_status_for_object_type), #23168 (unregister_post_status)." ptahdunbar Future Releases 25798 Certain single CPT items result in 404 since 3.7 Posts, Post Types 3.7 normal normal defect (bug) new 2013-11-01T14:58:10Z 2019-06-04T20:45:08Z "Related: #25749 The changes in [25182] to the query_var mapping of hierarchical post types have broken single permalinks in some cases, when Permalink setting is set to ""Post name"". To reproduce: 1. Register a post type as follows: {{{ register_post_type( 'bbg_test', array( // ... 'hierarchical' => true, 'public' => true, 'rewrite' => true, // any value other than false 'query_var' => false, // ... ) ); }}} 2. Set permalink settings to ""Post name"" (and flush) 3. Create a new post of the type above, and attempt to visit at the url `http://example.com/bbg_test/foo` (or whatever). Result: 404. 4. Change to any other permalink setting. Result: page loads as expected. Cause: When the CPT is registered with `'rewrite'` other than `false`, it passes the test at http://core.trac.wordpress.org/browser/tags/3.7/src/wp-includes/post.php#L1275. When it's hierarchical, it passes the test at line 1293. When, because `'query_var'` is set to `false`, the rewrite tag set on line 1294 is of the form 'post_type=bbg_test&pagename=foo' (instead of 'bbg_test=foo'). Then, when an item is loaded, during `WP::parse_request()`, it passes the `preg_match()` test here http://core.trac.wordpress.org/browser/tags/3.7/src/wp-includes/class-wp.php#L198, but a page (ie, an item with `post_type` 'page') is not found by `get_page_by_path()`, and as a result the correct rewrite rule is not matched. As noted, this is a regression in 3.7 [25182], before which `preg_match( '/pagename=\$matches...` wouldn't have matched. Obviously it's an edge case that (a) a post type is hierarchical AND has query_var set to false, and also (b) permalinks are set to ""Post name"", but it is a change in behavior that broke one of my plugins, and has been a bit of a bear to track down :) I'm going to set `query_var` to true for my purposes (no harm done on my end) but that may not be possible for others." boonebgorges Future Releases 16843 wp_unique_post_slug() doesn't check pagination base when CPT has archive Posts, Post Types 3.1 normal minor defect (bug) new has-patch 2011-03-13T06:22:22Z 2019-06-04T20:41:56Z Title says it all. scribu Future Releases 36314 If orderby undefined, alter get_posts to defer to WP_Query's default Posts, Post Types normal normal enhancement new 2016-03-23T22:22:46Z 2019-06-04T20:56:15Z "If the argument is undefined, defer `get_posts` orderby & order to that of WP_Query's. For search strings, this will order posts by relevance. In other cases it will have no effect." peterwilsoncc Future Releases 16784 Introduce post_type_archive_description() Posts, Post Types 3.1 normal normal enhancement new has-patch 2011-03-07T10:36:40Z 2021-04-24T16:12:27Z "if using the standard archive.php page, the common function for getting archive page name (e.g. single_tag_title) or description (e.g. tag_description) do not work - the best now is to use get_queried_object()->name resp. get_queried_object()->description Also it is not obvious, that when you create a custom post type and taxonomy (with public=true) they are not visible on menu navigation page - you must make them visible using the top View menu (it took me a while to realize it) " thomask Future Releases 36406 $network_wide is unreliable Plugins 3.0 normal critical Future Release defect (bug) reviewing has-patch 2016-04-03T09:20:33Z 2019-07-09T10:20:39Z "This issue may be related to ticket #31104 Scenario: In a WordPress network an admin decides a plugin must not be network activated. Only a per site or even a site specific activation shall be allowed. Idea: Conditional check during plugin activation and die with an error message if $network_wide is true. Result: Plugin does not get activated but the custom error message is not displayed Assume the following function run during activation (it is simplified and the real activation sequence does not have echos!) {{{ function test_activation_hook( $network_wide ) { echo '1 | '; // exit( 1 ); if ( is_multisite() ) { echo '2: | '; // exit( 2 ); if ( $network_wide ) { echo '3: | '; // exit( 3 ); } else { echo '4: | '; // exit( 4 ); } } else { echo '5: | '; // exit( 5 ); } echo '6: | '; exit( 6 ); } }}} If you exit after if(is_multisite) the message displayed will be '1 | 2 |' If you exit after if($network_wide) during a networkwide activation the message displayed is '1 | 2 | 4 | 6' instead of '1 | 2| 3|' Exiting at 4, 5, or 6 will display '1 | 2| 4|', '1 | 2| 5|' and '1 | 2| 6|' as expected. After many hours of debuging I realized the function (the action filter 'activate_' . $plugin) gets executed 3 times if you exit it early. And only the first call has the argument $network_wide set to true if it is an network_wide activation. If you like to exit at 3, that is you do not want a network activation, the flow is therefore as follows: - The first run (click on network activate) has $network_wide set to true and will exit at 3 - the second run (no idea why) has $network_wide set to false and will pass 1 | 2 | 4 | 6 - the third run (no idea why) has $network_wide set to false and will pass 1 | 2 | 4 | 6 Imho calling the activation function (or the code) three times in case you exit it (better say terminate because you cant end a plugin installiton clean) is wrong at all. However if this is by design then $network_wide must be reliably set to true if it originally was. " mensmaximus Future Releases 43489 Strengthen resilience of wp_register_plugin_realpath to support Gutenberg Plugins normal normal Awaiting Review defect (bug) new 2018-03-07T18:25:25Z 2020-12-01T05:24:00Z "For many years now I've been working in a Windows development environment with multiple subdirectory installs referencing plugins using symlinks. Every now and then I get problems due to plugin files apparently not being present when they quite clearly are. I have not been able to track it down. I think it's a bug in PHP associated with OpCache. Anyway, the bottom line is that sometimes this problem, or something similar, results in the `$wp_plugin_paths` array containing entries with a null value for `$realdir`. This can lead to the following: `Warning: strpos(): Empty needle in C:\apache\htdocs\hm\wp-includes\plugin.php on line 658.` This message has the uncanny knack of happening at the most inappropriate times. Now, with Gutenberg looming, the problem is further reducing my ability to create content locally; Gutenberg can't handle the unexpected Warnings and Notices from a development server and fails. See https://github.com/WordPress/gutenberg/issues/5439 To reduce the likelihood of the problem I'd like to propose a change to `wp_register_plugin_path()` to cater for a false value being returned from the `realpath()` PHP function. The proposal being that if `$plugin_realpath` does appear to be null, then don't add an entry in `$wp_plugin_paths`. This change will prevent the warning message being issued from plugin_basename()'s test {{{ if ( strpos( $file, $realdir ) === 0 ) { }}} and therefore increases the robustness of the system. Bottom line. - `realpath()` may return false. - This should be catered for. " bobbingwide Future Releases 45374 apply_filters_ref_array() no longer passes arguments by reference Plugins 4.7 normal normal Awaiting Review defect (bug) new 2018-11-19T10:58:35Z 2019-01-25T13:54:36Z "It appears that since the introduction of the `WP_Hook` class in WordPress 4.7 (#17817), `apply_filters_ref_array()` no longer passes its arguments by reference. Example: {{{ add_filter( 'posts_clauses', function( $clauses, &$query ) { return $clauses; }, 10, 2 ); }}} The above code will trigger the following PHP warning: {{{ Parameter 2 to {closure}() expected to be a reference, value given }}} cc @jbrinley FYI" johnbillion Future Releases 9968 dynamically adding/removing filters breaks plugins Plugins low normal Awaiting Review defect (bug) reopened 2009-05-28T23:43:11Z 2020-03-02T15:43:22Z "noticed this while doing something similar to this: {{{ add_action('foo', 'bar1', 10); add_action('foo', 'bar2', 20); function bar1() { remove_filter('foo', 'bar1', 10); } }}} in the above, bar2() doesn't get called. it is because of the usage of next()/current() to loop through filters. attached patch uses a foreach loop instead, to make it work." Denis-de-Bernardy Future Releases 34358 plugin_dir_url( __FILE__ ) returns plugins directory when plugin symlinked to mu-plugins Plugins 4.3.1 normal normal Future Release defect (bug) new has-patch 2015-10-19T17:53:00Z 2017-10-02T15:02:25Z "With a plugin symlinked to the mu-plugins folder, paths to find assets via the URL are broken if using `plugin_dir_url()`. This does not happen when using the `WPMU_PLUGIN_URL` constant. However, if using the constant then the plugin is not portable to the normal `plugins` directory without additional checks. {{{#!php 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 20241 make it possible for plugins to activate other plugins Plugins normal normal Future Release enhancement assigned has-patch 2012-03-15T12:48:59Z 2022-08-05T22:43:52Z "When creating a plugin that depends on other plugins, i would like to enable those plugins during activation of the main plugin. This is currently not possible, as updates to active_plugins done by the other plugins get overwritten. Please apply the attached patch to fix this." magnus78 Future Releases 19388 plugin_basename returns full directory in URL Plugins 3.3 normal normal enhancement new has-patch 2011-11-29T00:36:36Z 2019-06-04T20:42:35Z "If a trailing slash is specified on either then WP_PLUGIN_DIR or WPMU_PLUGIN_DIR settings, the plugin_basename function returns the whole directory path in the URL. The documentation does state not to use a trailing slash, however I think this function could be improved. By removing the explicit / in the preg_replace the correct plugin name will be returned even if a trailing slash is specified on the WP_PLUGIN_DIR or WPMU_PLUGIN_DIR constants. This should not affect the relative path as the trim before the return takes care of stripping off the first slash if it exists (effectively duplicating the remove in this case). While this is a very trivial change that won't affect most people (who read the docs properly) it was quite annoying to track down. Please see the attached diff." damianzaremba Future Releases 5130 Linking to multiple posts on your site breaks pingback due to comment flooding Pings/Trackbacks 2.3 normal normal Future Release defect (bug) new has-patch 2007-10-01T17:36:13Z 2023-03-22T11:30:42Z "http://scott.sherrillmix.com/blog/programmer/web/wp_pingpreserver/ is this useful in WP 2.3?" Denis-de-Bernardy 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 37938 Make existing HTML parsing functionality from REST API and Press This reusable kraftbj* Pings/Trackbacks 4.2 low minor Future Release enhancement accepted 2016-09-03T17:08:26Z 2023-05-30T11:34:09Z "WordPress already has an HTML parsing function in the form of WP_Press_This::source_data_fetch_fallback and its private called functions. Suggesting this be split off so it can be used elsewhere. Specifically, my use case is over on the Ping and Trackbacks component. One of the proposals I keep advocating for is improving the presentation. As we already have this code in WordPress that allows for parsing of HTML for images, embeds, meta tags, etc, it should be used over writing new code to do the same. But if it were to be called right now, it would reretrieve source HTML already retrieved by the Pingback code and passed into the comment array." dshanske Future Releases 35435 Support Webmentions Pings/Trackbacks normal normal Future Release feature request new 2016-01-13T05:25:25Z 2018-02-19T11:52:22Z "Webmention is now a W3C Recommendation as of January 12, 2017. https://www.w3.org/TR/webmention/ . Previous linkback protocols(trackback and pingback) did not achieve this status. The Webmention is a simplified evolution of the Pingback. It drops XML-RPC in favor of simple form encoding. The recommendation calls for asynchronous processing to prevent DoS attacks. There is already a webmention plugin for WordPress in the repository. https://wordpress.org/plugins/webmention/ and this could be used as a basis for a feature plugin to merge into core. Trackbacks and Pingbacks both have their unique problems. The idea of linkbacks in general remains a good one, spoiled by less robust implementations. To go to the logical extreme, suggesting that adoption of webmentions be concurrent with the disabling by default of the earlier and less secure protocols. Finally, no feature should be adopted in WordPress unless it has users...the pingback implementation in WordPress displays pingbacks in a way that does not convey useful meaning. Current implementations of Webmention parse the HTML to generate a comment or other richer forms of response that are more useful to a site than what is currently available. The proof of concept for this is in the Semantic Linkbacks plugin https://wordpress.org/plugins/semantic-linkbacks . " dshanske Future Releases 31384 Pingback does not work for schemeless URLs Pings/Trackbacks 1.5 normal normal defect (bug) new has-patch 2015-02-19T17:03:29Z 2019-06-04T20:49:17Z "I noticed that a pingback will not be send if the target URL is given as a schemeless URL (like {{{//www.example.com/path/file.ext}}}. This is because discover_pingback_server_uri() in comment.php is using the PHP function parse_url() which cannot handle schemeless URLs correctly." tobiaskochsonlinenet Future Releases 36765 Remove Legacy Code from pingback_ping Pings/Trackbacks 4.1 normal normal defect (bug) new dev-feedback 2016-05-05T14:59:53Z 2019-06-04T20:58:45Z "Proposing we remove the legacy conditional url_to_postid and //$way debugging line leftover from [30139]. {{{ / let's find which post is linked to // FIXME: does url_to_postid() cover all these cases already? // if so, then let's use it and drop the old code. }}} Related: #34419 " dshanske Future Releases 23915 discover_pingback_server_uri cases an error when discovery URI sets multiple Content-type headers dd32 Pings/Trackbacks 2.7 normal normal defect (bug) assigned 2013-04-01T14:25:25Z 2019-06-04T20:44:00Z "Line 1673 in wp-includes/comment.php uses preg_match() on the output of wp_remote_retrieve_header(). When multiple headers are set of the same name, wp_remote_retrieve_header() returns an array. Thus occasionally the following error occurs: PHP Warning: preg_match() expects parameter 2 to be string, array given in xxxxxxx/wp-includes/comment.php on line 1673 I have no idea how to make pingbacks happen so to reproduce, add this line to functions.php: discover_pingback_server_uri('http://localhost:8080/'); And in a terminal window run this (you may need to install the netcat-openbsd package in Debuntu): `while true; do echo -en 'HTTP/1.1 200 OK\r\nContent-type: text/html\r\nContent-type: text/plain\r\n\r\n' | nc -lp 8080; done` Then visit your WP installation and you shall get the aforementioned error message." tomdxw Future Releases 27158 do_enclose() throws warnings when content_type is text/html and not audio or video Pings/Trackbacks 3.8.1 normal normal defect (bug) new 2014-02-19T17:25:58Z 2019-06-04T20:45:45Z "cron calls do_pings()/do_all_pings() which in turn goes on to do_enclose(). PHP Warning: strpos() expects parameter 1 to be string, array given in /var/vhost/site/wp-includes/functions.php on line 505 $url is valid, $type is ""text/html; charset=UTF-8"", $len is valid as well. $allowed_types is array(0=>video, 1=>audio) server environment: PHP 5.5.3-1ubuntu2.1 Apache 2.4.6 running WP 3.8.1, no multisite " tamas_dxw Future Releases 34419 Update Pingback Processing Code Pings/Trackbacks normal minor enhancement new 2015-10-23T21:36:25Z 2019-06-04T20:52:31Z "Related to #34141, which would pass the retrieved pingback source to preprocess_comment and comment_post for additional processing, pingback_ping currently strips all content from the source as part of its processing. Suggesting that specifically: 1. Sanitization be done using core sanitization functions(wp_kses, etc) 2. The code that returns relevant errors(URL not found, etc), be processed ahead of anything else. 3. The older code that duplicates the functionality of url_to_postid noted as FIXME be removed. If there really is another difference, that should be an enhancement to url_to_postid. This, combined with the enhancements in #34141, would allow moving toward improving linkback presentation(#32653), which is a long term goal." dshanske Future Releases 37812 404 when using a numeric slug and /%category%/ base Permalinks normal normal Future Release defect (bug) new 2016-08-24T15:29:53Z 2023-03-11T11:36:36Z "To reproduce: 1. Create a top and sublevel category. Lets say Parent > Child 2. In permalink settings, set custom permalink structure /%category%/%postname%/ 3. Create a post with slug 12345 and assign to category ""child"" 4. View post. There is a 404. Tested in 4.6 only. No other plugins active." mikejolley Future Releases 55189 "Automatic removal of ""Zero-width non-joiner"" in URL" Permalinks 5.9 normal critical Future Release defect (bug) new dev-feedback 2022-02-17T14:30:25Z 2023-02-23T23:37:32Z "There is a big problem in recent version of WordPress, ""[https://en.wikipedia.org/wiki/Zero-width_non-joiner Zero-width non-joiner]"" in the URLs is removed automatically. This will have a very bad effect on SEO (and has affected many sites) because the page with ""Zero-width non-joiner"" in their URL will goes to be 404. " man4toman Future Releases 9102 Inverse proxy breaks permalinks Permalinks 2.7 normal normal Future Release defect (bug) assigned has-patch 2009-02-12T01:58:37Z 2024-03-19T19:43:03Z "I have a WP installation at my university's webspace (on an apache server), say http://myuni.ac.at/mydir/wordpress/ , and an inverse proxy domain http://mydomain.at/ for it. This means that any request to the latter, eg for http://mydomain.at/2009/02/12/inverse-proxy-trouble/ , is forwarded to http://myuni.ac.at/mydir/wordpress/ , which in turn means that the REQUEST_URI there becomes /mydir/wordpress/2009/02/inverse-proxy-trouble/ . My ''home'' variable is of course set to http://mydomain.at/ (''siteurl'' is set to http://myuni.ac.at/mydir/wordpress/ -- otherwise I wouldn't be able to login to WP). Unfortunately, when analyzing REQUEST_URI, wordpress chops off the ''home'' path, not the ''siteurl'' one. This may be okay for some purposes, but in the inverse proxy case, permalinks break. For a fix, I had to hack two wordpress core files, namely wp-includes/classes.php in function parse_request: change line 162 from {{{ $home_path = parse_url(get_option('home')); }}} to {{{ $home_path = parse_url(get_option('siteurl')); }}} and wp-includes/rewrite.php, in function get_pagenum_link, line 987, same modification. This is a dirty hack, of course; so I wonder if in general, using the ''siteurl'' path is valid in any case where the ''home'' host differs from the ''siteurl'' host. If so, I suggest changing the affected files in such a manner." Bernhard Reiter Future Releases 3329 Need to strip % from the auto-permalink in the editor. pishmishy* Permalinks 2.0 normal normal Future Release defect (bug) accepted dev-feedback 2006-11-04T20:41:06Z 2023-02-02T12:43:17Z "I made an article with ""x = 18,98 * y - %10"" as title, and this generated http://www.example.com/blog/2006/11/03/x-1898-y-%10/ which doesn't work." Heyneken Future Releases 10249 Page slug in cyrillic = Error 404 - Not Found! westi Permalinks 4.9.5 normal normal Future Release defect (bug) reopened has-patch 2009-06-23T19:44:34Z 2022-06-22T01:20:33Z "When I create a page with page slug for example ""киро"" then when I try to open domain/киро - Error 404 - Not Found The permalinks are %postname% Post slug with this slug is working just fine, the same BUG exists in 2.7, 2.7.1 and 2.8" kalifi 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 43789 the_posts_pagination() outputs the slash at the first link Permalinks 4.9.5 normal normal Future Release defect (bug) new 2018-04-17T19:25:04Z 2021-09-17T12:21:50Z "Hello. Permanent link settings: `http://wp-test.ru/%postname%` (without a slash on the end) On the second and other pages of pagination, any category has a link to the first page with a slash on the end. {{{ http://wp-test.ru/category/bez-rubriki/ (with a slash on the end, why?) http://wp-test.ru/category/bez-rubriki/page/2 http://wp-test.ru/category/bez-rubriki/page/3 (current page) ..... }}} " campusboy1987 Future Releases 42148 url_to_postid plain permalinks for CPTs Permalinks 1.0 normal normal Awaiting Review enhancement new 2017-10-08T11:42:20Z 2017-10-08T11:46:15Z "Would be nice to have {{{url_to_postid}}} working with plain permalinks for custom post types. There's are currently some issues in {{{url_to_postid}}} where the wrong ID is returned for custom post type plain permalinks (query-based). {{{ true ) ); /** Create a post */ $post_id = wp_insert_post( array( 'post_type' => 'findme', 'post_status' => 'publish' ) ); $findme = get_permalink( $post_id ); $found = url_to_postid( $findme ); /** Guess it */ printf( ""%s (%s) == %s (%s)"", $post_id, $findme, $found, get_permalink( $found ) ); exit; } ); }}} {{{30 (http://localhost:8080/?findme=30) == 0 ()}}} and {{{30 (http://localhost:8080/?findme=30) == 2 (http://localhost:8080/)}}} if the frontpage is setup to point ot a post. Why is it not working? Why is the frontpage post being returned? Let's see how the {{url_to_postid}} function works: {{{ // First, check to see if there is a 'p=N' or 'page_id=N' to match against if ( preg_match('#[?&](p|page_id|attachment_id)=(\d+)#', $url, $values) ) { $id = absint($values[2]); if ( $id ) return $id; } }}} Then? {{{ if ( trim( $url, '/' ) === home_url() && 'page' == get_option( 'show_on_front' ) ) { $page_on_front = get_option( 'page_on_front' ); if ( $page_on_front && get_post( $page_on_front ) instanceof WP_Post ) { return (int) $page_on_front; } } }}} Uh, wait what... already? So a short-circuit without checking the custom post types. And that's understandable, since there is inherently no support for custom post type ID mappings as pointed out by: {{{ // Check to see if we are using rewrite rules $rewrite = $wp_rewrite->wp_rewrite_rules(); // Not using rewrite rules, and 'p=N' and 'page_id=N' methods failed, so we're out of options if ( empty($rewrite) ) return 0; }}} What stands in our way to find the URL earlier? 1. The query var is not one of p, page_id, attachment_id 2. The query var value for CPTs is not necessarily, and most often not numeric (the post_title) A proposed solution would be to look at the query parameters much higher, maybe by injecting the custom ones, ones that support slugs as well, since WordPress sets the {{{page_title}}} for a CPT itself, so that {{{\d+}}} check would fail. Use case? Well, this was encountered when trying to paste plain oEmbed URLs for a custom post type (https://github.com/gravityview/GravityView/issues/927)." soulseekah Future Releases 17450 Almost pretty permalinks with non-ASCII characters do not work in Apache westi Permalinks 3.1 normal normal defect (bug) reopened 2011-05-16T05:53:14Z 2019-06-04T20:42:05Z Almost pretty permalinks (using PATH_INFO) with non-ASCII characters do not work in Apache; a not found error is returned. The same permalink works in IIS when UTF-8 is used for server variables. It also works when mod_rewrite is used. peaceablewhale Future Releases 28156 In date-containing permalink structures, /dddd/dd/comment-page-d/ urls don't work Permalinks 3.9 normal normal defect (bug) new dev-feedback 2014-05-06T22:42:17Z 2019-06-04T20:46:56Z "I was in the process of writing a plugin to allow people to test their rewrite rules as they develop a site, and when I setup examples of core rewrite rules, one of them was failing. If you set your permalink structure to one containing dates, e.g. ""Day and Name"", one of the generated rewrite rules for posts is: {{{ '([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/([^/]+)(/[0-9]+)?/?$' => 'index.php?year=$matches[1]&monthnum=$matches[2]&day=$matches[3]&name=$matches[4]&page=$matches[5]' }}} And later on, another rule is: {{{ '([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/comment-page-([0-9]{1,})/?$' => 'index.php?year=$matches[1]&monthnum=$matches[2]&day=$matches[3]&cpage=$matches[4]' }}} The URI /2014/5/6/comment-page-2/ would end up matching the earlier rule, looking for a post named ""comment-page-2"" published on 2014-05-06, instead of looking for comment page 2 in the... I actually don't even know what the comment-page URLs do. For me, the ones that work just redirect to the date archive. I'm happy to patch this, but would like to hear from someone else on what exactly should be done done. Do the comment-page-n rules do anything? Can they just be removed?" mboynes Future Releases 36157 Permalink UI shown without typing a title Permalinks 2.5 normal normal defect (bug) new has-patch 2016-03-07T15:11:15Z 2019-06-04T20:55:42Z "When creating a new post and jumping straight to the content to write a post the permalink UI will still be shown. '''Steps to reproduce:''' * 'Add New' post in the admin * Type content inside the post content field. * Wait until an autosave triggers and finishes. This step can also be achieved by putting `wp.autosave.server.triggerSave();` inside the console. '''Expected behaviour:''' The permalink UI isn't shown because no title has been set yet. '''Actual behaviour:''' The permalink UI is shown with a post ID as the slug." atimmer Future Releases 17183 previous_comments_link and next_comments_link return wrong url with PATHINFO permalinks Permalinks 1.5 normal normal defect (bug) new dev-feedback 2011-04-19T20:13:15Z 2019-06-04T20:42:01Z "When using PATHINFO permalinks, previous_comments_link() and next_comments_link() return a wrong link, which renders paged comments useless. Steps to reproduce: Set permalinks to: /index.php/%post_id%/%postname%/ The functions return URLs similar to: /comments-page-1/#comments This URL results in a file not found (if no rewrite rules are available, which should not be necessary if the PATHINFO permalink structure is used). Expected URL: /index.php/comments-page-1/#comments Manual opening the URL results in the expected/correct paged comments page." FireMotion Future Releases 9825 Enforce permalink history, outright Permalinks 2.8 normal normal enhancement assigned dev-feedback 2009-05-15T01:06:37Z 2019-06-04T20:40:43Z "currently, we enforce old slugs and www pref (not even sure that works, since I ended up fixing it in a plugin). canonical doesn't work for pages, or hardly. we should enforce permalink history, outright. store it in a a db field, and query against it to optimize url2post()." Denis-de-Bernardy Future Releases 52723 Admin options.php default value to NULL for option_value may lead to MySQL Integrity constraint violation error, potential other bugs Options, Meta APIs 2.7 normal normal 6.6 defect (bug) new has-patch 2021-03-05T14:26:35Z 2024-02-27T12:01:48Z "It looks like `wp-admin/options.php` set a `null` value by default for any unchecked option: https://core.trac.wordpress.org/browser/trunk/src/wp-admin/options.php#L306 Now, this leads to execute queries like this by `update_option`: UPDATE `wp_options` SET `option_value` = NULL WHERE `option_name` = 'default_pingback_flag' Which is wrong, given the schema explicitly set `option_value` to `NOT NULL`: https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/schema.php#L144 This would trigger an integrity constraint violation error by MySQL when in (default) strict mode: Error! SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'option_value' cannot be null To get around this (and for other reasons too, I presume), WordPress currently tries to disable any MySQL strict mode in the `$wpdb` class, with the effect that MySQL silently ""fix"" the error itself: https://core.trac.wordpress.org/browser/trunk/src/wp-includes/wp-db.php#L567 https://core.trac.wordpress.org/browser/trunk/src/wp-includes/wp-db.php#L826 But **not every environment support this**, so there are people out there who cannot save options and they are confused about the reason why, for example: https://www.reddit.com/r/Wordpress/comments/l61rvs/cannot_disable_avatars/ https://wordpress.org/support/topic/discussion-comment-settings-saved-changes-are-not-taking-effect-at-all/ https://wordpress.org/support/topic/wordpress-database-error-column-option_value-cannot-be-null/ A simple solution would be to set a different default value (`0` or even an empty string) in `wp-admin/options.php` and, ''better yet'', **cast any `NULL` value to the same different default value in both `update_option` and `add_option`**. Please note that, without a fix, **this bug may also lead to other nasty side effects**. As a quick fix/test, I successful got around this with this simple filter: {{{#!php ID )` will return: {{{ Array ( [0] => foo [1] => bar ) }}} while the following, with the `meta_id` as array key, would be helpful imho: {{{ Array ( [1022] => foo [1029] => bar ) }}} The modification is trivial in `update_meta_cache()`, and some other functions would only need something like `metas[0]` => `reset( metas )`." GregLone Future Releases 51926 Network Site Search should search more than just wp_blogs.path Networks and Sites normal normal Future Release defect (bug) new has-patch 2020-12-03T18:21:59Z 2022-10-07T21:53:14Z "From /wp-admin/network/sites.php, searching sites for 'foo' looks to only search the wp_blogs.path column. This was fine up until WordPress let you put sites any any domain. Now searching for 'foo' would show me sites such as this: https://mysite.com/foo https://mysite.com/foodsite but does NOT show me sites such as https://foo.com https://foo.mysite.com I believe the search should include the domain for the site as well as the path. " MadtownLems Future Releases 52464 The value of argument passed to the update_option_new_admin_email() is not a valid email. SergeyBiryukov Networks and Sites normal normal Awaiting Review defect (bug) reviewing reporter-feedback 2021-02-07T12:08:54Z 2022-09-29T17:38:21Z "While creating a patch for ticket #43706, I found out that the function `update_option_new_admin_email()` is responsible for the template. It does accept two parameters, however, the first parameter `$old_value` does not seem to get the correct value. When checking the value, it holds the value `new_admin_email` instead of the old email address. Thanks!" tremidkhar Future Releases 41771 Global configuration table Networks and Sites 4.9 normal normal Awaiting Review enhancement new 2017-08-31T22:19:51Z 2017-09-19T16:37:54Z "In multisite, there is no way to have settings or configuration what goes applies to all networks. There are network level settings (Network options) and site levels settings (Options) but nothing global. In #37923 the need for global configuration arose, as storing data the network level ends up with the same data in every network. Also having a global config table, would help rid ourselves of our dependence on PHP defines for configuration. If this config table was installed on single site as well, the following defines, could be moved the config table. - MULTISITE - SUBDOMAIN_INSTALL - WP_CACHE - FORCE_SSL_ADMIN - WP_DEFAULT_THEME This could make the process of installing multisite, much easier. A number of feature flag that are currently store in options / network options could be moved to the global store. Features such as. - link_manager - enabled / disabled - global_terms - enabled / disabled - use blog_versions - enabled / disabled - site meta - enabled / disabled - ms_files_rewriting - enabled / disabled This global table could also store multi network wide settings such as - Global super admin - Global user roles - Global plugins (Not mu plugins) - Global database version - Default Language " spacedmonkey Future Releases 40646 Move code from `ms-settings.php` into functions Networks and Sites normal normal Future Release enhancement new has-patch 2017-05-03T10:03:16Z 2017-08-29T16:16:58Z "As briefly discussed during yesterday's office-hours, it would be a good idea to move most of the bootstrap code from `ms-settings.php` into separate functions. `ms_load_current_site_and_network()` which was added in [37475] was a good first step in that direction. Let's introduce further functions (possibly small units) to make `ms-settings.php` less complex and more functionality testable. Once `ms-settings.php` becomes more lightweight, we may even think about removing that file and handling all of it in `wp-settings.php`, as this would give a better overview of the entire core bootstrapping process. This ticket is a subticket for #40623." flixos90 Future Releases 45640 get_blogs_of_user improvements alexstine Networks and Sites 3.0 normal minor Awaiting Review enhancement assigned has-patch 2018-12-14T11:59:18Z 2021-11-16T13:59:24Z "get_blogs_of_user function is often pulling more data than it needs. This often won't cause any issues but in some cases when user is attached to big number of blogs, it may lead to out of memory error. Attached patch has changes that can lead to more improvements like pagination for ""My Sites"" admin page, limitation of listed sites in admin bar and on ""access denied"" page." maniu Future Releases 40513 switch_to_blog should accept a WP_site as param Networks and Sites 3.0 normal normal Future Release enhancement new has-patch 2017-04-21T10:52:30Z 2022-02-01T13:18:39Z The switch_to_blog function currently only accepts a blog id. By passing a WP_Site object where available, it means switch has more context. The WP_site object has all the site information, including the network id. spacedmonkey Future Releases 15691 Network admin should have its own settings API Networks and Sites 3.0 normal normal Future Release feature request new dev-feedback 2010-12-05T19:31:17Z 2017-09-07T10:27:33Z preferably using options.php and the same API as normal admin, this way making a plugin multisite compatible (ie. adding a Network admin screen to it) would be much easier. joostdevalk Future Releases 27287 siteurl is missing WordPress path when creating a new site Networks and Sites normal normal defect (bug) new 2014-03-06T00:03:35Z 2019-06-04T20:06:59Z "Our setup is a single subdomain network. WordPress is installed to `/wp`, and we don't have rewrites configured to mask the subdirectory. On the initial install, `wp_install()` sets the value of `siteurl`based on `wp_guess_url()`. The main site ends up with these expected values: * `siteurl`: domain.com/wp * `home`: domain.com On subsequent creation of a new site, `install_blog()` incorrectly sets the option values for the new site to: * `siteurl`: domain.com * `home`: domain.com This means the admin loads, but CSS and resources are broken, until I update the `siteurl` option value to be ""domain.com/wp"". I'd expect `install_blog()` to follow the same behavior as `wp_install_blog()`. #23221 is related, although this suggested fix doesn't also fix that." danielbachhuber Future Releases 37344 Side effects on 'nav_menu_item_args' filter when appending to arguments Menus 4.4 normal normal Future Release defect (bug) new has-patch 2016-07-12T16:25:52Z 2021-10-10T23:08:44Z "The 'nav_menu_item_args' filter allows you to filter the arguments for a single nav menu item which works well when you are '''overwriting''' arguments. When you try to '''append''' an argument the original arguments object is updated. This means that the next menu item passes in the updated object to the 'nav_menu_item_args' filter which leads to unexpected side effects. For demonstration purposes here's how to reproduce the issue. {{{ function format_menu_item_args( $args, $item, $depth ) { $args->before .= rand(0,9); return $args; } add_filter( 'nav_menu_item_args', 'format_menu_item_args', 10, 3); }}} What you should see before every menu item is a random integer between 0-9. What happens instead is the integer from the previous menu item is passed into the next. So by the time the 'nth' menu item is processed you get 'n' integers outputted whereas only one integer per menu item should be outputted. I have added a patch to solve this by casting the $args object to an array early in start_el(). If left as an array this would break code already using the 'nav_menu_item_args' filter as an '''$args object''' is passed into the filter. Also code further down start_el() would need updating to use array rather than object notation. So, to get around this I've casted $args to an object again. This is a new object and so there won't be any issues with referencing the original nav menu args object. Plus, existing code using the 'nav_menu_item_args' filter will still work fine. See attached screenshots for views of a nav menus before and after the patch is applied. ''Note: The default type for $args in start_el() is already specified as an empty array but it's actually an object that's being passed in.''" dgwyer Future Releases 38486 current_page_parent class wrongly added to menu item williampatton Menus 4.6.1 normal normal Awaiting Review defect (bug) assigned has-patch 2016-10-25T15:46:20Z 2020-07-31T16:06:44Z "If the current page being viewed is either of the following: - a custom post type archive - a custom post type single item a {{{current_page_parent}}} class is added to the menu item assigned as the {{{page_for_posts}}}. I believe this is wrong because the page assigned as the {{{page_for_posts}}} is associated with ''posts'' only. It has nothing to do with CPTs." henry.wright Future Releases 36012 Add .current-ancestor class to any relative menu item ancestor SergeyBiryukov Menus 4.4.2 normal normal Future Release enhancement assigned has-patch 2016-02-29T16:52:22Z 2023-04-28T18:17:43Z "Right now there is .current-page-ancestor and .current-post-ancestor for pages and posts and no any class for archives, category, taxonomy or custom post types ancestors added to items in nav-menu. I think it will be usefull, for indication navigation depth purposes, to add .current-ancestor class to ANY menu item if ""current page"" is child/successor to anything in menu (parents, archive, category, taxonomy etc. menu items)." vovkasolovev Future Releases 29213 Introduce capability for access to nav-menus.php johnbillion Menus 3.0 normal normal Future Release enhancement assigned dev-feedback 2014-08-14T16:22:16Z 2022-01-30T16:44:01Z "Management of the nav menus currently requires `edit_theme_options` capability, a capability associated with administrators which grants the power to make many wide sweeping changes. There should be a discrete capability `edit_nav_menus` just for managing menus, one that is inherited for anyone who has `edit_theme_options` by default. This was done for Customizer access in #28605 with the introduction of a `customize` capability. Originally brought up in #14386. For introducing a `manage_widgets` capability, see #31020." westonruter Future Releases 35384 Archive for post in Menu Editor Menus normal normal enhancement new has-patch 2016-01-09T09:50:03Z 2019-06-04T20:20:36Z In menu edit in posts meta box I suggest add Archive for Posts sebastian.pisula Future Releases 31391 Make the list of registered nav menus filterable Menus 3.6 normal normal enhancement new has-patch 2015-02-20T05:33:50Z 2019-06-04T20:11:26Z Adding a filter to the list of registered menu locations before they are displayed in the admin section allows for easy reordering and/or selectively hiding menu locations to none admin users. csschris Future Releases 48522 Attachment size not generated when large images uploaded Media 5.3 normal normal Future Release defect (bug) new dev-feedback 2019-11-07T01:33:39Z 2020-10-16T20:03:30Z "I've noticed that some images during upload do not generate attachment sizes at all, or generate the sizes partially. An example of such an image: https://upload.wikimedia.org/wikipedia/commons/f/ff/Pizigani_1367_Chart_10MB.jpg Upload is successful, but there's no scaled image, as well as no attachments. " vanyukov Future Releases 48489 Big image size threshold should take into account registered image sizes. Media 5.3 normal normal Future Release defect (bug) new has-patch 2019-11-03T20:22:54Z 2023-11-16T11:42:00Z "The ""big image"" upper size threshold is set to `2560`. If an image size is registered that has a width or height larger than this, then the image will be unexpectedly cropped to `2560`. The value that gets passed through to the `big_image_size_threshold` filter should be set to the maximum value of either `2560` or the largest width or height from all registered image sizes. " johnbillion Future Releases 39422 Consistency for returned value of attachment meta : mime_type VS mime-type Media 4.6.1 normal normal Future Release defect (bug) new 2016-12-29T22:55:29Z 2017-10-31T10:14:23Z "Hello here, While using the function wp_get_attachment_metadata, the returned associative array is not consistent. For video attachment it will give mime_type key with a ""_"" and for images it will return mime-type key with a ""-"". The returned mime type key should either be ""mime_type"" or ""mime-type"", but should be the same for any type of media attachment. Thanks for the great job ! " gabrielstuff Future Releases 55290 Not all image edits are applied to all subsizes joedolson* Media normal normal Future Release defect (bug) accepted has-patch 2022-03-01T22:05:28Z 2024-02-05T20:24:32Z "When editing an image using the admin editor, not all edits are applied correctly to all image subsizes. Specifically, the problem occurs when an edit results in a smaller size than the defined image size. Given the following image subsizes, and the attached image. {{{ => array(6) { [""thumbnail""]=> array(3) { [""width""]=> int(150) [""height""]=> int(150) [""crop""]=> bool(true) } [""medium""]=> array(3) { [""width""]=> int(300) [""height""]=> int(300) [""crop""]=> bool(false) } [""medium_large""]=> array(3) { [""width""]=> int(768) [""height""]=> int(0) [""crop""]=> bool(false) } [""large""]=> array(3) { [""width""]=> int(1024) [""height""]=> int(1024) [""crop""]=> bool(false) } [""1536x1536""]=> array(3) { [""width""]=> int(1536) [""height""]=> int(1536) [""crop""]=> bool(false) } [""2048x2048""]=> array(3) { [""width""]=> int(2048) [""height""]=> int(2048) [""crop""]=> bool(false) } } }}} ''The defined sizes above are the ones coming by default with the setting provided below. '' == Steps to replicate the problem: 1. Upload the image into your installation. 2. After the image is uploaded, click on edit to open the image editor or go to the image editor from within the media library. 3. Click on Edit image 4. Click on rotate image (either right or left) only once. 5. Make sure the changes are applied to all images by checking that the setting Apply changes to: All image sizes is set 6. Click on save After the image is saved observe the changes were applied only to the following image sizes: - `thumbnail` - `medium` - `large` - `full` The only size that was not updated as expected was: - `medium_large` == Setup {{{ ### wp-core ### version: 5.9.1 site_language: en_US user_language: en_US timezone: +00:00 permalink: /%year%/%monthnum%/%day%/%postname%/ https_status: true multisite: false user_registration: 0 blog_public: 1 default_comment_status: open environment_type: production user_count: 1 dotorg_communication: true ### wp-paths-sizes ### wordpress_path: /app wordpress_size: 152.90 MB (160327567 bytes) uploads_path: /app/wp-content/uploads uploads_size: 22.75 MB (23851112 bytes) themes_path: /app/wp-content/themes themes_size: 6.47 MB (6780262 bytes) plugins_path: /app/wp-content/plugins plugins_size: 208.42 MB (218539593 bytes) database_size: 3.96 MB (4149380 bytes) total_size: 394.49 MB (413647914 bytes) ### wp-active-theme ### name: Twenty Twenty-Two (twentytwentytwo) version: 1.0 (latest version: 1.1) author: the WordPress team author_website: https://wordpress.org/ parent_theme: none theme_features: core-block-patterns, post-thumbnails, responsive-embeds, editor-styles, html5, automatic-feed-links, block-templates, widgets-block-editor, wp-block-styles, editor-style theme_path: /app/wp-content/themes/twentytwentytwo auto_update: Disabled ### wp-themes-inactive (3) ### Twenty Nineteen: version: 2.2, author: the WordPress team, Auto-updates disabled Twenty Twenty: version: 1.9, author: the WordPress team, Auto-updates disabled Twenty Twenty-One: version: 1.5, author: the WordPress team, Auto-updates disabled ### wp-plugins-inactive (1) ### Performance Lab: version: 1.0.0-beta.1, author: WordPress Performance Group, Auto-updates disabled ### wp-media ### image_editor: WP_Image_Editor_Imagick imagick_module_version: 1691 imagemagick_version: ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org imagick_version: 3.7.0 file_uploads: File uploads is turned off post_max_size: 100M upload_max_filesize: 100M max_effective_size: 100 MB max_file_uploads: 20 imagick_limits: imagick::RESOURCETYPE_AREA: 122 MB imagick::RESOURCETYPE_DISK: 1073741824 imagick::RESOURCETYPE_FILE: 786432 imagick::RESOURCETYPE_MAP: 512 MB imagick::RESOURCETYPE_MEMORY: 256 MB imagick::RESOURCETYPE_THREAD: 1 imagemagick_file_formats: 3FR, 3G2, 3GP, AAI, AI, APNG, ART, ARW, AVI, AVIF, AVS, BGR, BGRA, BGRO, BIE, BMP, BMP2, BMP3, BRF, CAL, CALS, CANVAS, CAPTION, CIN, CIP, CLIP, CMYK, CMYKA, CR2, CR3, CRW, CUR, CUT, DATA, DCM, DCR, DCX, DDS, DFONT, DJVU, DNG, DOT, DPX, DXT1, DXT5, EPDF, EPI, EPS, EPS2, EPS3, EPSF, EPSI, EPT, EPT2, EPT3, ERF, EXR, FAX, FILE, FITS, FRACTAL, FTP, FTS, G3, G4, GIF, GIF87, GRADIENT, GRAY, GRAYA, GROUP4, GV, H, HALD, HDR, HEIC, HISTOGRAM, HRZ, HTM, HTML, HTTP, HTTPS, ICB, ICO, ICON, IIQ, INFO, INLINE, IPL, ISOBRL, ISOBRL6, J2C, J2K, JBG, JBIG, JNG, JNX, JP2, JPC, JPE, JPEG, JPG, JPM, JPS, JPT, JSON, K25, KDC, LABEL, M2V, M4V, MAC, MAGICK, MAP, MASK, MAT, MATTE, MEF, MIFF, MKV, MNG, MONO, MOV, MP4, MPC, MPG, MRW, MSL, MSVG, MTV, MVG, NEF, NRW, NULL, ORF, OTB, OTF, PAL, PALM, PAM, PANGO, PATTERN, PBM, PCD, PCDS, PCL, PCT, PCX, PDB, PDF, PDFA, PEF, PES, PFA, PFB, PFM, PGM, PGX, PICON, PICT, PIX, PJPEG, PLASMA, PNG, PNG00, PNG24, PNG32, PNG48, PNG64, PNG8, PNM, POCKETMOD, PPM, PREVIEW, PS, PS2, PS3, PSB, PSD, PTIF, PWP, RADIAL-GRADIENT, RAF, RAS, RAW, RGB, RGBA, RGBO, RGF, RLA, RLE, RMF, RW2, SCR, SCT, SFW, SGI, SHTML, SIX, SIXEL, SPARSE-COLOR, SR2, SRF, STEGANO, SUN, SVG, SVGZ, TEXT, TGA, THUMBNAIL, TIFF, TIFF64, TILE, TIM, TTC, TTF, TXT, UBRL, UBRL6, UIL, UYVY, VDA, VICAR, VID, VIDEO, VIFF, VIPS, VST, WBMP, WEBM, WEBP, WMF, WMV, WMZ, WPG, X, X3F, XBM, XC, XCF, XPM, XPS, XV, XWD, YCbCr, YCbCrA, YUV gd_version: bundled (2.1.0 compatible) gd_formats: GIF, JPEG, PNG, WebP, BMP ghostscript_version: 9.53.3 ### wp-server ### server_architecture: Linux 5.15.12-1-MANJARO x86_64 httpd_software: nginx/1.17.10 php_version: 7.4.28 64bit php_sapi: fpm-fcgi max_input_variables: 10000 time_limit: 3 memory_limit: 1G max_input_time: 900 upload_max_filesize: 100M php_post_max_size: 100M curl_version: 7.74.0 OpenSSL/1.1.1k suhosin: false imagick_availability: true pretty_permalinks: true ### wp-database ### extension: mysqli server_version: 10.3.27-MariaDB client_version: mysqlnd 7.4.28 max_allowed_packet: 33554432 max_connections: 151 ### wp-constants ### WP_HOME: undefined WP_SITEURL: undefined WP_CONTENT_DIR: /app/wp-content WP_PLUGIN_DIR: /app/wp-content/plugins WP_MEMORY_LIMIT: 40M WP_MAX_MEMORY_LIMIT: 1G WP_DEBUG: true WP_DEBUG_DISPLAY: true WP_DEBUG_LOG: true SCRIPT_DEBUG: false WP_CACHE: false CONCATENATE_SCRIPTS: undefined COMPRESS_SCRIPTS: undefined COMPRESS_CSS: undefined WP_ENVIRONMENT_TYPE: Undefined DB_CHARSET: utf8mb4 DB_COLLATE: undefined ### wp-filesystem ### wordpress: writable wp-content: writable uploads: writable plugins: writable themes: writable mu-plugins: writable }}} " mitogh Future Releases 36477 Responsive images (srcset) can include images larger than the full size Media 4.4.2 normal normal Future Release defect (bug) assigned dev-feedback 2016-04-11T13:27:58Z 2023-09-01T15:35:00Z "In many cases, I saw the resized and smaller images are much larger than the origin image, especially for the optimized images, it will make no sense to do that resize in this case, the worst case I've seen is about 13x larger than the origin and bigger image. If an example can help to explain the problem, please take this picture: https://cdn2.peterdavehello.org/wp-content/uploads/2016/04/status.png Many thanks!" peterdavehello Future Releases 60291 Support Lossless WebP in WP_Image_Editor_GD Media 5.8 normal normal 6.6 defect (bug) new has-patch 2024-01-19T01:08:14Z 2024-02-19T17:09:20Z "While WordPress has supported WebP lossless since WebP support was introduced in WP 5.8 (https://make.wordpress.org/core/2021/06/07/wordpress-5-8-adds-webp-support/) - outputting lossless sub-size image when you upload a lossless WebP - this only worked correctly when Imagick was installed as at the time lossless was not supported in PHP's bundled GD. PHP's bundled GD supports lossless output for WebP images since PHP 8.1, see see php.watch/versions/8.1/gd-webp-lossless. The capability to handle lossless WebPs can be detected in GD by the presence of the `IMG_WEBP_LOSSLESS` constant. To fix this - similar to Imagick, GD should output WebP lossless images when lossless WebP images are uploaded. " adamsilverstein Future Releases 60158 The description field for media doesn't automatically make paragraphs in the generated code joedolson* Media normal normal 6.6 defect (bug) accepted changes-requested 2023-12-27T11:47:53Z 2024-03-19T15:20:16Z "There are two ways to edit a media: - via a modal window where all the contribution fields are only simple textareas; - via a dedicated web page where ""alternative text"" and ""caption"" fields are simple textareas and the ""description"" field is a WYSIWYG editor in text mode where TinyMCE is deactivated. For some media, you can need to add a long description just like a transcript (for videos, audios, complex images like infographic, etc.). So, in these cases, the description field can be used because it's totally appropriate. But, there is a problem: usually, in editor fields, the paragraphs (

elements) are automatically added when you display the web page (in the front view). In this field, they are not. For accessibility reason, paragraphs need to be HTML paragraphs ([https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html WCAG Success Criterion 1.3.1: Info and Relationships (level A)]). I've tried to modify the code in the core to add TinyMCE that is explicitly deactivated and this is fixing the problem. It's in wp-admin/includes/media.php, on line 3261 where you can just change ""false"" to ""true"" for ""tinymce"": {{{#!php 'strong,em,link,block,del,ins,img,ul,ol,li,code,close' ); $editor_args = array( 'textarea_name' => 'content', 'textarea_rows' => 5, 'media_buttons' => false, 'tinymce' => false, 'quicktags' => $quicktags_settings, ); }}} So, is it possible to activate TinyMCE for this field? Why is it deactivated? Or, if it's not possible, is it possible to make this option hookable? Thank you " juliemoynat Future Releases 44801 `image_constrain_size_for_editor()` forcing the `$content_width` messes up dimensions Media normal normal Future Release defect (bug) new has-patch 2018-08-15T09:27:19Z 2019-04-15T21:58:52Z "The `image_constrain_size_for_editor()` currently looks at the `$content_width` global that themes may define. For `medium_large`, `large` and any custom image sizes, the actual image size's width will be evaluated against the `$content_width`, and the minimum will be used. This results in the following (example): * Let's say `$content_width` is 640. * Let's say your `large` image size constraints are 1280x1280. * Let's say your image in `large` size is 1280x960. * Instead of using the image size width (1280), it will use the `$content_width` since it's smaller (640), resulting in 640x480 being used for the dimension of the image in `large` size. This makes sense for the default behavior, but that computed size is used in many different areas, including `wp_prepare_attachment_for_js()`, where the `sizes` property then would show something like this for the `large` size (continuing the above example): ```js { width: 640, height: 480, url: '.../my-image-1280x960.jpg', orientation: 'landscape' } ``` Regarding what I want to accomplish with the custom image sizes, this results in unexpected behavior. For example in my case, I was looking into dynamically generating media queries for a background image, using the sizes. I was expecting for my code to generate `@media (max-width: 1280px) ...` for the image, but it would generate `@media (max-width: 640px) ...` due to the changed size. As I already said, the `$content_width` global makes sense to take into account by default. However, it is currently hardcoded into the function. I think it should be moved into a filter (we already have `editor_max_image_size` which is perfect for that), so that someone could temporarily unhook that behavior for custom use-cases." flixos90 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 47713 image_get_intermediate_size does not return size if it equals original size SergeyBiryukov Media 5.2.2 normal major Future Release defect (bug) reviewing has-patch 2019-07-16T12:44:11Z 2020-09-10T14:45:20Z "Function `image_get_intermediate_size` does not return size if it equal original size. 1. WordPress itself doesn't generate `sizes` metadata item for size equal original image size. 2. `image_get_intermediate_size` looks throught `sizes` metadata and doesn't see necessary size. 3. It doesn't check original image size. More details here: https://github.com/Yoast/wordpress-seo/issues/10863" mahnunchik Future Releases 54943 image_get_intermediate_size(): size data is a bool, not an array throws notice / warning Media 5.9 normal normal Awaiting Review defect (bug) new reporter-feedback 2022-01-27T08:03:50Z 2023-08-07T19:20:26Z "While testing my website on PHP 8.0 (in my example opening the blog page), I noticed the following two warnings in the error log: {{{ [27-Jan-2022 08:56:34] WARNING: [pool xxx] child 1031078 said into stderr: ""PHP message: PHP Warning: Trying to access array offset on value of type bool in /var/www/xxx/wp-includes/media.php on line 779"" [27-Jan-2022 08:56:34] WARNING: [pool xxx] child 1031078 said into stderr: ""PHP message: PHP Warning: Trying to access array offset on value of type bool in /var/www/xxx/wp-includes/media.php on line 785"" }}} PHP 7.4 throws a Notice. I also noticed with a fresh install of wordpress. " fhwebdesign Future Releases 41445 post_parent can prevent media from embedding correctly adamsilverstein Media 4.9.4 normal normal Future Release defect (bug) reopened dev-feedback 2017-07-26T06:29:28Z 2024-01-26T07:46:47Z "If media is uploaded for a post, then used as a featured image on another post, and the original parent is not accessible via the REST API (e.g. because it's in the trash, not published etc), then it cannot be embedded on the post that ''is'' accessible. To reproduce * make a new post with a featured image * trash the post * make a new post, using the first image as the featured image * request the second post over the rest API with media embedding enabled The media will not be embedded, instead a forbidden result will be embedded error {{{#!json { ""wp:featuredmedia"":[ { ""code"":""rest_forbidden"", ""message"":""You don't have permission to do this."", ""data"":{ ""status"":403 } } ] } }}} See https://github.com/WP-API/WP-API/issues/2596 for the original issue. Also related is https://core.trac.wordpress.org/ticket/30691. " loboyle 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 36437 wp_delete_attachment causes warning Media 2.0 normal normal Awaiting Review defect (bug) new has-patch 2016-04-07T06:24:34Z 2017-07-27T16:26:17Z wp_delete_attachment assumes that attachments uses category and post_tag taxonomies. This causes a warning in wp_delete_object_term_relationships when post type attachment is not using category or post_tag taxonomies. thorbrink Future Releases 42920 Add support for the picture element adamsilverstein Media normal normal Awaiting Review enhancement assigned dev-feedback 2017-12-17T06:10:52Z 2024-02-26T18:25:22Z "The `` element is in the HTML standard and should be supported in WordPress (https://html.spec.whatwg.org/multipage/embedded-content.html#the-picture-element). Similar to the `