__group__,ticket,summary,owner,component,_version,priority,severity,milestone,type,_status,workflow,_created,modified,_description,_reporter
Future Releases,20902,redirect_canonical() on using permalink: Not all $_GET being redirected,chriscct7,Canonical,3.4,normal,normal,,defect (bug),reviewing,has-patch,2012-06-11T09:30:08Z,2019-06-04T19:23:06Z,"Using permalink, I suppose that all query_var entered manually on URL or using $_GET will be redirected to proper permalink. Apparently not all being redirected at all. AFAIC:
1. /?post_format=image : should be redirected to /type/image/
2. /?pagename=blog : should be redirected to /blog/
3. /?author_name=admin : should be redirected to /author/admin/
Unfortunately, they are not.
It can be done by filtering redirect_canonical() but it will be better if it's being done by default as we can see that /?category_name=cat will be redirected to /category/cat/",arieputranto
Future Releases,18315,Add an index to the GUID column in the posts table,,Database,3.2.1,normal,normal,,enhancement,reopened,dev-feedback,2011-08-02T04:31:01Z,2019-06-04T19:22:38Z,"Running queries on the GUID column in the posts table is slow because the column is not indexed. The attached patch adds an index.
Note, this affects ticket #18286 - I will update that ticket with appropriate patches to reflect this request.",alexkingorg
Future Releases,23309,Not all WP_Query::query_vars get updated during WP_Query::get_posts(),,Query,,normal,normal,,defect (bug),new,needs-unit-tests,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,60096,Remove back-compat for database servers that don't support utf8mb4,johnbillion,Database,trunk,normal,normal,6.6,task (blessed),assigned,has-patch,2023-12-18T19:45:03Z,2024-02-28T00:31:19Z,"Since [57173] the minimum supported version of MySQL is 5.5.5, which means the utf8mb4 charset is supported by all supported database servers. The back-compat code for handling servers that don't support it can therefore be removed, along with related tests and health checks.",johnbillion
Future Releases,60352,Fix the architectural design of `/wp-includes/blocks/index.php`,,General,5.5,normal,normal,6.6,defect (bug),new,,2024-01-26T00:15:33Z,2024-02-17T13:45:35Z,"Follow-up to #55067.
Generally the `*.php` files in all ""include"" directories are meant to be ""included"" in other files as the name suggests, not loaded directly. This is true for `/wp-includes` too. In addition these include-only files should not contain any ""loose"" PHP code that runs in the global scope, only functions and classes. These are pretty simple and easy to follow architectural PHP rules that ensure all code works well and avoid some exploit vectors.
However `/wp-includes/blocks/index.php` doesn't seem to be following them, similarly to many of the other files in the `blocks` directory. As far as I see this should be considered as a PHP code architecture bug and should be fixed. The changes should ensure that there is no output or errors when that file is loaded directly.",azaozz
Future Releases,58763,Inconsistent add/get/update/delete_post_meta() functions leads to deleting post metadata.,,General,,normal,major,6.6,defect (bug),new,has-patch,2023-07-08T09:48:05Z,2024-02-19T20:57:08Z,"The add_post_meta(), delete_post_meta(), and update_post_meta() functions all use wp_is_post_revision() to add/delete/update the metadata of the post, not its revision. That's fine, but the get_post_meta() function does NOT use wp_is_post_revision().
As a consequence, if you use get_post_meta() and update_post_meta() during the saving process for a revision, the post metadata ends up being overwritten/deleted: The get_post_meta() function gets the **revision** metadata, and then the update_post_meta() function updates the **post** metadata, NOT the revision metadata.
js.",jsmoriss
Future Releases,59774,Undefined array key when using wp_list_pluck function,hellofromTonya,General,5.1,normal,normal,6.6,defect (bug),reopened,changes-requested,2023-10-31T12:30:29Z,2024-02-28T01:30:17Z,"**Bug Description:**
**Issue**: When using the `wp_list_pluck` function to extract values from an array, a PHP warning is triggered if the specified key is not found within the array. The warning message is as follows:
`PHP Warning: Undefined array key ""required"" in /var/www/html/wp-includes/class-wp-list-util.php on line 171`
**Steps to Reproduce**:
1. Use the `wp_list_pluck` function on an array.
2. Specify a key that may or may not exist within the array.
3. Observe the PHP warning generated when the key is not found.
**Expected Behavior**:
The `wp_list_pluck` function should gracefully handle cases where the specified key is not present in the array and not trigger a PHP warning.
**Actual Behavior**:
The function generates a PHP warning with an ""Undefined array key"" message, which could lead to unnecessary log clutter and confusion.
**Environment**:
- WordPress version: 6.3 and Higher
- PHP version: >= 8
- Operating system: UBUNTU
**Proposed Solution**:
To handle this situation gracefully without errors, you can check if the key exists in the array before attempting to access it. You can use the isset() function to determine if the key exists. Here's how you can modify the code:
{{{
#!div style=""font-size: 80%""
Code highlighting:
{{{#!php
if (is_object($value)) {
$newlist[$key] = isset($value->$field) ? $value->$field : array();
} elseif (is_array($value)) {
$newlist[$key] = isset($value[$field]) ? $value[$field] : array();
} else {
_doing_it_wrong(
__METHOD__,
__('Values for the input array must be either objects or arrays.'),
'6.2.0'
);
}
}}}
}}}
In the modified code, we use isset() to check if the key $field exists in either the object or the array. If the key exists, it assigns the value to $newlist[$key]. If the key doesn't exist, it assigns empty array().
This modification will prevent the code from triggering an error when attempting to access non-existent keys in an array or object. Instead, it will gracefully assign empty array().
",iamarunchaitanyajami
Future Releases,46550,"Uncaught TypeError: setcookie() expects parameter 5 to be string, bool given in...",,Networks and Sites,5.2,normal,minor,6.6,defect (bug),new,has-patch,2019-03-18T05:18:36Z,2024-02-17T13:42:20Z,"https://github.com/WordPress/WordPress/blob/5e62e6b2034516c0bb366f808673752030d2d2b7/wp-includes/default-constants.php#L303
{{{#!php
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,59442,Duplicate query in WP_Query,,Query,6.2,normal,normal,6.6,defect (bug),assigned,changes-requested,2023-09-25T11:32:47Z,2024-03-13T15:27:55Z,"When a site using a classic theme and has sticky posts, that can result in duplicate query. ( See attached screenshot ). This is because post_type variable passed the sticky sub query, is empty string on the first run. See the [https://github.com/WordPress/wordpress-develop/blob/de9e06a4c021295af3ac11fdd08ea29a57529668/src/wp-includes/class-wp-query.php#L3493 line]. This results in different cache query key being generating, resulting in duplicate queries.
Steps to replicate.
1. Set theme to 2016.
2. Import theme data test data.
3. Go to home page.
4. Open query monitor, see duplicate query. ",spacedmonkey
Future Releases,58087,Fix the 'data' dynamic property in WP_Term,hellofromTonya*,Taxonomy,6.3,normal,minor,6.6,defect (bug),accepted,changes-requested,2023-04-04T18:13:54Z,2024-02-23T09:36:08Z,"The `WP_Term` class employs the `__get` magic method to compute the object data.
However, since PHP 8.2 does not support dynamic properties, it is better to eliminate this approach and explicitly declare the `WP_Term::data` class property to store the object's data instead.",antonvlasenko
Future Releases,58905,Ensure locate_template only loads theme files,,Themes,,normal,normal,6.6,defect (bug),new,needs-unit-tests,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,58281,Rollback Auto-Update (Rollback part 3),afragen,Upgrade/Install,6.3,normal,normal,6.6,enhancement,assigned,dev-feedback,2023-05-10T02:31:58Z,2024-02-21T18:22:14Z,"This is Rollback part 3. It began with `move_dir()` in WP 6.2 for part 1. Part 2 was completed with #51857 in WP 6.3. This brings us to part 3.
Part 3 is Rollback for auto-updates. When manually updating plugins if the plugin has a fatal error on reactivation, the plugin is prevented from reactivating. Unfortunately, during an auto-update, this reactivation check doesn't occur and the the next time the site runs users will see the WSOD.
Rollback Auto-Update performs a similar re-activation check and if there is a fatal error it is captured in an error handler and the previously installed plugin is restored. If this occurs an email will be sent notifying the site admin of the failed update and rollback.
After the rollback, the pending auto-updating for core and theme updates are restarted.
This code is currently running for everyone who has the [https://wordpress.org/plugins/rollback-update-failure/| Rollback Update Failure] feature plugin installed.
I personally have been testing this using a plugin that will fatal if the update occurs. The plugin is on my test site, active, and set to auto-update. I have been running like this since the beginning of the year.
The PR is slightly different than the code in the feature plugin. Please test, run the feature plugin on your site, and review the code in the PR. Mostly give us your comments and feedback.
props @costdev and @pbiron for continuing code review, rubber ducking, and sanity checks.",afragen
Future Releases,60414,Core PHP autoloader proposal,,General,,normal,normal,Awaiting Review,enhancement,new,has-patch,2024-02-01T13:15:07Z,2024-03-27T15:14:48Z,"Using a PHP autoloader can improve performance, and can be seen as a first step towards modernizing the WP codebase in the future.
This ticket is a continuation of the discussion on [https://core.trac.wordpress.org/ticket/36335 #36335]
The discussion in the original ticket was derailed many times, so this fresh ticket is an opportunity to discuss the Core proposal submitted on the [https://make.wordpress.org/core/?p=110295 Make blog]",aristath
Future Releases,53333,Better handling for forced plugin autoupdates,,Upgrade/Install,,normal,normal,Awaiting Review,defect (bug),new,has-patch,2021-06-04T07:23:35Z,2021-11-04T00:41:57Z,"When an auto-update for a plugin is forced from WordPress.org (for security purposes), and the update is not to the latest current release, we're forced to adjust the API response in a way which can confuse some WordPressers
For example, Let's say `ACME Widget` has released three major versions, `1.0, 2.0, 3.0` and a security vulnerability is found that allows an RCE attack. Since each version of the plugin is significantly different they release `1.1, 2.1, 3.1` and request the Plugins Security team to perform an autoupdate.
Currently, the flow is that a site with 1.0 installed is:
- Yesterday the UI showed an update to 3.0
- Today the UI shows an update available, 1.1 NOT 3.0
- If possible, the Auto Update will push the site from 1.0 => 1.1, and email the user about the update occurring.
- If not possible, the site will just show 1.1 as the latest release (Although WordPress.org will show 3.1)
- Once the site is running 1.1, they'll see an update to 3.1.
I would like to adjust this so that:
- The UI always shows the latest version, 3.1
- The autoupdate attempts to push the site to 1.1
- The site isn't forced to go 1.0 -> 1.1 -> 3.1 to upgrade manually, and can instead upgrade from 1.0 directly to 3.1
This causes confusion for some people when they receive an email saying a plugin was autoupdated, but it wasn't to the latest version of a plugin, and even more confusing when the latest release was a few days ago.
#51695 would be of benefit here too, as the email will then include a note that it was a security update.
The way I envision this happening, is adjusting the API response for plugins/themes.
For example, here's a current response:
{{{
{
""plugins"": {
""acme/widgets.php"": {
""id"": ""w.org/plugins/acme-widgets"",
""slug"": ""acme-widgets"",
""plugin"": ""adme/widgets.php"",
""new_version"": ""1.1"",
""url"": ""https://wordpress.org/plugins/acme-widgets/"",
""package"": ""https://downloads.wordpress.org/plugin/acme-widgets.1.1.zip"",
""autoupdate"": true,
}
}
}}}
and here's what I'm thinking:
{{{
{
""plugins"": {
""acme/widgets.php"": {
""id"": ""w.org/plugins/acme-widgets"",
""slug"": ""acme-widgets"",
""plugin"": ""adme/widgets.php"",
""new_version"": ""3.1"",
""url"": ""https://wordpress.org/plugins/acme-widgets/"",
""package"": ""https://downloads.wordpress.org/plugin/acme-widgets.3.1.zip"",
""upgrade_notice"": ""Fix a bug"",
""autoupdate"": [ {
""new_version"": ""1.1"",
""package"": ""https://downloads.wordpress.org/plugin/acme-widgets.1.1.zip"",
""upgrade_notice"": ""Security update, fix bugs"",
} ],
}
}
}}}
Notes
- The additional data is minimal and not duplicating existing fields
- The plugins update API would need to be bumped to a `1.2` endpoint, to change the output based on the client revision.
- If the site has auto-updates enabled for the plugin, it'd attempt the 3.1 update rather than the minimal 1.1 first.
- The API response supports the ability to have multiple versions presented, but currently this is based on the assumption of a singular item, just a bit of future proofing.
An attached PR explores this idea, although will be pending implementation on WordPress.org prior to it being testable. I've got a draft `1.2` endpoint that works like this, and will follow up with that next week pending feedback from others.",dd32
Future Releases,24251,Reconsider SVG inclusion to get_allowed_mime_types,,Upload,,normal,normal,Awaiting Review,enhancement,reopened,dev-feedback,2013-05-02T19:36:57Z,2023-03-27T19:24:23Z,"There are some who think SVG should be included in core as an allowed mime type. Makes fine enough sense to me, since there is a good argument for it, and we have support for WordPerfect documents...so there's that.
Related: #20990",JustinSainton
Future Releases,24447,Avoid losing data after nonces expire,iseulde,Administration,,normal,major,Future Release,defect (bug),assigned,,2013-05-29T07:55:35Z,2020-05-14T19:23:54Z,"Happens when an admin page containing a form is left open for more than 24 hours and the user decides to submit the form. This is quite rare for most admin pages as the users typically spend short time there. However this can happen on the Edit Post screen too despite that we refresh the basic nonces every `wp_nonce_tick` (12 hours):
- The user starts new post.
- At some point the Internet connection is lost.
- The user decides to finish later and puts the computer to sleep (closes the laptop, etc.).
- The user decides to continue writing more than 24 hours after that.
At this point all nonces have expired and cannot be updated as we've missed the previous nonce_tick update.",azaozz
Future Releases,42278,Speed up tests by using shared user fixtures,,Build/Test Tools,,normal,normal,Future Release,enhancement,new,needs-unit-tests,2017-10-19T09:09:44Z,2019-01-08T10:13:51Z,"There are a lot of tests that require user fixtures. These are then created, and afterwards deleted, as part of the test class set up and tear down methods.
These fixtures could all be reused between tests, if a user for every role in Core would be created in the database as part of the unit test setup process.
If we had that, all the tests that need for example a user with the `editor` role could just grab the existing user from the database, instead of creating this as a test fixture.",Frank Klein
Future Releases,55999,wp_suspend_cache_addition should also disable cache setting?,,Cache API,,normal,normal,Future Release,defect (bug),new,dev-feedback,2022-06-17T09:30:15Z,2024-02-07T19:31:56Z,"Right now wp_suspend_cache_addition is only checked when ""add"" to cache.
However most plugins/developers only use wp_cache_set for updating/adding to the cache.
This means in most plugins/cases, wp_suspend_cache_addition has no use, in fact it's rather unexpected behavior that only some functions can add to cache (namely: set, incr, decr)
I propose we also check wp_suspend_cache_addition before setting the cache.
This would also be in line with its function description:
>Stops more data being added to the cache, but still allows cache retrieval.
As ""set"" also ""adds"" (or at least modifies if already exists therefore adds/subtracts) data in cache.",malthert
Future Releases,43539,Custom feed types breaks redirect_canonical behavior,SergeyBiryukov,Canonical,4.9.4,normal,normal,Future Release,defect (bug),reviewing,has-patch,2018-03-13T15:54:47Z,2022-11-01T03:24:16Z,"Hi.
There's plugin ""fb-instant-articles"" which adds ""instant-articles"" feed type for facebook.
final url looks like http://localhost/feed/instant-articles.
But because ""redirect_canonical"" doesn't respect custom feed types it triggers 301 redirect to http://localhost/feed/instant-articles/feed/instant-articles/.
""instant-articles"" is registered with $wp_rewrite->feeds but this property isn't respected in ""redirect_canonical"" method: http://take.ms/kq0zJ http://take.ms/cbRPm
We need there to support custom types too like that for example: http://take.ms/ljija
",satantime
Future Releases,50163,Perform a canonical redirect when paginated states of the front page are not found,hellofromTonya,Canonical,,normal,normal,Future Release,defect (bug),assigned,needs-unit-tests,2020-05-14T06:44:54Z,2022-04-04T05:37:27Z,"As a followup to #45337, [34492], and [47727].
When example.com/ has a static front page assigned and uses `` accessing non-existing pages uses example.com/page/3/ and Canonical won't kick in.
This is because paged states of the front page use the `paged` query var, not the `page` query var.
Should also fix https://meta.trac.wordpress.org/ticket/5184 :)",dd32
Future Releases,4328,"Redirect Old Slugs feature needs to redirect slugs for pages, not just posts, and redirect old permalink structure",SergeyBiryukov,Canonical,2.2,normal,normal,Future Release,enhancement,reviewing,needs-unit-tests,2007-05-24T01:52:44Z,2022-01-25T14:30:12Z,"Create a page, browse to it, edit it, change its slug, WP redirects to the old page's slug and serves a 404. Wasn't WP 2.1 or WP 2.2 supposed to make the redirect old slug feature built-in?
Along the same lines, it would be sweet if instead of simply redirect old slugs, WP would redirect old urls. When the date changes, when the page parent changes, or when the permalink structure changes, the url changes but neither of WP, the redirect old slug plugin, the permalink redirect plugin, or anything else catches this.",Denis-de-Bernardy
Future Releases,57979,Can't upload images to WordPress Comments,,Comments,6.0.3,normal,normal,Future Release,defect (bug),new,changes-requested,2023-03-24T13:39:57Z,2023-10-16T15:35:22Z,"As the admin, I am unable to upload images from my image library to a WordPress comment posted by a user. Please Note: I can upload images to my own comments, but not a user-generated comment. On the admin page, I edit a user comment, click IMG button, add the image URL, and the correct code is added to the comment. When I click UPDATE, the image code disappears. Please note that all existing images in Comments display properly. This is a new problem. Theme is Genesis Magazine Pro. I tried: deactivating all plugins, multiple browsers, multiple operating systems (PC and Mac), and multiple computers. Also contacted my web host, WP-Engine, who has had other reports of this problem and believes it is a WordPress issue. Site is buildingadvisor.com. Thank you!",sbb
Future Releases,54042,Extending wpdb::prepare() to support IN() operator,,Database,,normal,normal,Future Release,enhancement,new,changes-requested,2021-08-31T14:23:26Z,2023-09-17T10:53:12Z,"wpdb::prepare() helps avoid SQL Injection vulnerabilities, by escaping most variables correctly.
WP 6.1 added support for Identifiers (table/field names) with `%i`, in #52506.
But it's also fairly common to make a mistake to include values with the `IN()` operator, for example:
{{{#!php
prepare('WHERE id IN (%...d)', $ids);
}}}
Where `%...d` or `%...s` would safely (and easily) include a comma separated array of integers or strings - taking the idea of using '...' for variadics in PHP.
https://wiki.php.net/rfc/variadics
https://www.php.net/manual/en/functions.arguments.php#functions.variable-arg-list
https://dev.mysql.com/doc/refman/8.0/en/comparison-operators.html#operator_in",craigfrancis
Future Releases,47280,SQL_CALC_FOUND_ROWS is deprecated as of MySQL 8.0.17,johnbillion,Database,,normal,normal,Future Release,enhancement,reviewing,changes-requested,2019-05-15T14:34:03Z,2024-02-22T07:49:16Z,"Per https://dev.mysql.com/doc/refman/8.0/en/information-functions.html#function_found-rows
> The SQL_CALC_FOUND_ROWS query modifier and accompanying FOUND_ROWS() function are deprecated as of MySQL 8.0.17 and will be removed in a future MySQL version. As a replacement, considering executing your query with LIMIT, and then a second query with COUNT(*) and without LIMIT to determine whether there are additional rows.
This is not yet immediately important because most hosts are on 5.5, or 5.6, rarely 5.7, but given the speed with which trac tickets move that impact very core functionalities, I thought it best to open this ticket to get the work started.
This impacts all the 6 places where it's being used, though one of them is in the WP_Query definition.",javorszky
Future Releases,42352,Support use of native MySQLi prepared queries,,Database,,normal,normal,Future Release,enhancement,new,,2017-10-27T04:15:52Z,2023-09-09T22:23:23Z,"When we added `$wpdb->prepare()` back in WordPress 2.3, we were forced to roll our own MySQL Prepared queries as the MySQL extension didn't support it.
While the MySQL extension still doesn't, the majority of WordPress sites are likely using the newer MySQLi engine (by default, enabled for PHP 5.5+ which accounts for 70~80% of sites). That makes now a good time to start investigating the potential implementation and usage of native prepared queries in the future.
Attached is a first-draft of implementing native prepared queries into WPDB, it has no fallbacks for MySQL at present, but it would be possible to force support in for it using a ""simple"" SQL parser.
Unfortunately I expect that this draft is incompatible with many DB drop-ins, which is okay, this is only a draft and proof-of-concept.
I'll attach some examples of how this first draft could be used in a comment below.",dd32
Future Releases,56091,Using %i for table/field names in wpdb::prepare(),craigfrancis,Database,6.1,low,minor,Future Release,enhancement,assigned,has-patch,2022-06-28T19:10:52Z,2024-01-29T20:10:29Z,"Now `wpdb::prepare()` supports `%i` for Identifiers (e.g. table/field names), via commit [53575], and ticket #52506.
Queries within WP Core should use this, to ensure variables are always quoted, and avoid static analysis tools flagging unescaped SQL input (a non-`literal-string`) for the `$query` parameter:
{{{#!php
prepare( ""SELECT ID FROM $wpdb->posts WHERE post_type = %s"", $post_type );
$wpdb->prepare( ""SELECT ID FROM %i WHERE post_type = %s"", $wpdb->posts, $post_type );
}}}
I'll write a patch for the first set, but I suspect there will be a lot of changes, and they should be checked carefully.",craigfrancis
Future Releases,37868,Avoid default width styles in the markup of the audio player,wonderboymusic,Embeds,4.6,normal,normal,Future Release,enhancement,assigned,has-patch,2016-08-29T18:51:47Z,2019-04-19T16:03:03Z,"The markup for every audio player contains inline styles for setting its width to 100%, like below (simplified):
{{{