__group__ ticket summary owner component _version priority severity milestone type _status workflow _created modified _description _reporter Future Releases 42441 Disable autoload for large options flixos90 Options, Meta APIs normal normal 6.6 enhancement reviewing commit 2017-11-06T02:20:50Z 2024-03-27T15:52:51Z "A frequent issue I encounter with WordPress sites is extreme slowdown due to a huge option that is being autoloaded. Sometimes this is some sort of cache option that a careless plugin has let be autoloaded, and has grown to tens of megabytes. Having an option this large be autoloaded not only slows downs the options loading query (when that option may not be required on every load), but on sites with object caching, it causes a lot of wear and tear on the alloptions cache. Combine a large option with a frequently updated option and you have a recipe for a very sluggish site. We should consider preventing options from being autoloaded if they grow to a certain size. Off the top of my head, 100kb sounds like a reasonable upper bounds. We could monitor option settings/updates and peek at the size of the option going in. If it's above a certain (filterable) bounds, we can force autoload to be off." markjaquith 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 9102 Inverse proxy breaks permalinks Permalinks 2.7 normal normal Future Release defect (bug) assigned needs-unit-tests 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 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 50568 Improve WP_Term's sanitization calls Taxonomy 5.5 normal normal Future Release defect (bug) new needs-unit-tests 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 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 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 18857 get_plugin_page_hookname uses menu_title to construct subpage load-hooks chriscct7 Plugins 3.1.4 normal normal Future Release defect (bug) assigned has-patch 2011-10-04T15:16:33Z 2024-02-27T22:04:37Z "The load-hook for PluginSubPages isn't working anymore if the PluginPage is translated. The reason seems to be that the get_plugin_page_hookname function uses the menu_title instead of the menu_slug to create the hookname. I attached a possible fix." apocalip 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 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 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 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 needs-unit-tests 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 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 59402 Plugin cannot be uninstalled if uninstall crashes swissspidy Plugins 2.7 normal normal 6.6 defect (bug) assigned has-patch 2023-09-20T06:59:37Z 2024-02-19T09:31:50Z "If a plugin register the ""register_uninstall_hook"" conditionally (e.g. only on activation,...) a plugin cannot be uninstalled anymore if it exits (e.g. timeout,...) during uninstall. This is because the uninstall file/callback is removed from the option before the actual uninstall happens: https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-admin/includes/plugin.php#L1253 https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-admin/includes/plugin.php#L1269 " kkmuffme Future Releases 24142 Zero value for posts_per_page value in wp_query custom instance and for 'Blog pages show at most' option SergeyBiryukov Query normal normal Future Release defect (bug) reviewing dev-feedback 2013-04-20T09:04:16Z 2024-02-18T16:12:32Z "To show no posts if the posts_per_page value is 0. Currently for custom instances of wp_query, if the value is 0 then this is changed with the value from posts_per_page option from the database. ""get_options( 'posts_per_page' )"" For home page if we set value 0 on the settings page, in wp-admin/options-reading.php, after the saves are changed, this value is changed to 1. I think for both cases if the posts per page value is 0 then no posts should not display. " alexvorn2 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 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 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 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 needs-unit-tests 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 55604 Update SimplePie to version 1.7.0 External Libraries 6.0 normal normal Future Release task (blessed) new needs-unit-tests 2022-04-21T20:05:26Z 2024-02-05T20:11:34Z "A new version of SimplePie has just been released. This version contains a few enhancements and some bug fixes. The most notable change, however, is that this release contains a ''forward-compatibility'' layer for the change to PSR-4 namespaced classes which is targetted for SimplePie 2.0.0. With some similarity to Requests - the namespaced versions of the classes are in a different base directory (`src`) from the original versions (`library`). As WP currently only includes the files in the `library` directory, I would like to suggest to continue doing so for now. This still makes the ''forward-compatibility'' layer available as all files in the `library` directory now create a ''class alias'' to their namespaced version. Once 2.0.0 has been released, the files included in WP, should be switched to the files from the `src` directory (which is currently in place mostly to allow for Composer autoloading) and should start using the namespaced names for the SimplePie classes. I'd recommend for this update to be mentioned in a dev-note, so plugins/themes directly using SimplePie can decide for themselves when they want to change to using the namespaced names for SimplePie classes. Refs: * https://github.com/simplepie/simplepie/releases/tag/1.6.0 * https://github.com/simplepie/simplepie/blob/1.6.0/CHANGELOG.md#160---2022-04-21 * https://github.com/simplepie/simplepie/compare/1.5.8...1.6.0 I've done a cursory check of the changes and they look sane to me, but would very much like to invite a second opinion and I'd recommend testing this change (more thoroughly than usually done for upgrades like these). I'd also like to recommend for a few cursory tests to be added to the WP test suite to ensure that both the PSR-0 as well as the PSR-4 class names load correctly when only including the `library` directory in WP. I'd recommend for this update to be applied in WP 6.1 **early**. Previous: #36669, #51521, #54659" jrf 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 51812 Update jQuery step three SergeyBiryukov External Libraries normal normal Future Release task (blessed) reviewing has-patch 2020-11-18T09:34:57Z 2024-01-27T08:55:38Z "Follow up from #37110 and #50564. Remove jQuery Migrate 3.3.x. This ticket represents step 3 in the following roadmap for updating jQuery to 3.x in Core: https://make.wordpress.org/core/2020/06/29/updating-jquery-version-shipped-with-wordpress/. " azaozz Future Releases 10483 Change post_name's length from 200 to 400 SergeyBiryukov Permalinks normal minor Future Release enhancement reviewing dev-feedback 2009-07-25T06:31:52Z 2023-12-29T16:39:52Z "Hello, guys! Thank you very much for providing such a great piece of software! I love WordPress very much! :) I use WordPress in Russian language and the URLs on my [http://www.ielnur.com blog] consist of Russian characters. There is a [http://www.ielnur.com/blog/2009/05/снова-бросить-курить-30-тидневное-испытание/ post] with not such a long URL in Russian, but since it gets encoded to special characters it becomes too long to get fit into `post_name` field of `post` table. I've found what code needs to be changed to increase the length. I make these changes every time a new version is released. I think it would be better to submit a patch here so that others people can benefit from it and I will not need to make those changes every release. I'm attaching the patch to this ticket and asking you to apply it to the code. Thank you very much again, guys! You do a great job! :) Cheers, Elnur" elnur Future Releases 49985 REST API: Using _embed and _fields query parameters in the same query TimothyBlynJacobs REST API 5.4 normal normal Future Release defect (bug) assigned has-patch 2020-04-23T16:06:43Z 2023-12-11T17:45:00Z "When performing a REST API request and adding the _embed and _fields query parameters. the API attempts to skip unneeded fields but does not embed resources that are linked with embeddable set to true. In some cases we may need _embed and _fields in the same query. I am requesting the feature to be added to allow the filtering of resources and embedding them (the embeddable ones) at the same time when specifying the _embed and _fields. Example: http:///wp-json/wp/v2/posts?_fields=title,author&_embed=author If implemented, the above request should only return title and author, and embed the author." anouarbenothman Future Releases 50683 Parse content for shortcodes instead of using regex johnbillion Shortcodes normal normal Future Release enhancement reviewing has-patch 2020-07-16T16:02:50Z 2023-11-26T23:15:48Z "Shortcodes are currently ""parsed"" out of content using a regular expression and a call to `preg_replace_callback()`. This causes some issues like the inability to use a square bracket in a shortcode attribute. I've written and attached to this ticket a lexer/parser that steps through the content character by character, finding shortcodes and calling `do_shortcode_tag()` for each one as soon as it's completely parsed. It passes every existing shortcode unit test, as well as six additional tests I've added. It fixes tickets #49955 and #43725 and may possibly fix others that deal with shortcode edge cases. This method has the advantage of being able to deal with content that wouldn't be properly extracted by a regular expression. Take this string for example: {{{ [shortcode1][shortcode2 att=""[/shortcode1]"" /][/shortcode1] }}} The current implementation would parse this as a single shortcode: * `[shortcode1]` with inner content `[shortcode2 att=""` The parse I've attached properly recognizes it as two shortcodes: * `[shortcode1]` with inner content `[shortcode2 att=""[/shortcode1]"" /]` * `[shortcode2]` with attribute `att=""[/shortcode1]""` " cfinke Future Releases 40175 Upload Validation / MIME Handling Media 4.7.3 high major Future Release defect (bug) assigned 2017-03-16T21:37:10Z 2023-10-30T16:13:26Z "A security fix implemented in WordPress `4.7.1` relies on a PHP extension (`fileinfo`) with inconsistent reporting behavior. As a result, many users (even after #39550) trying to upload various types of files (office documents, multimedia, fonts, etc.) have received validation errors. In a nutshell, this is because the media types returned by `fileinfo` vary from server to server and file to file. If PHP returns a media type beginning `application/*`, that media type must be whitelisted or the result will fail. Because most incorrect/historical answers from `fileinfo` begin `application/*`, this is resulting in a large number of false-positives. There are three main ways to address this, with a combination approach being preferred: '''1)''' The conditional in `wp_check_filetype_and_ext` could be restricted so that rather than searching `application/*` broadly, it looks only at the narrow file types at the heart of the original security issue. '''This option requires review from the Security Team.''' '''2)''' The WordPress Core could be extended to provide ""MIME alias"" awareness. This would allow WordPress to properly match a given extension/MIME pairing even in cases where the MIME type is historically valid, but not the singular type in the whitelist. See #39963 for related information. '''3)''' WP could be extended to maintain its own `mime.types` file, which can be passed to `fileinfo`, providing more consistent responses. '''This option requires the MIME alias handling to avoid breaking sites or plugins which hook into `upload_mimes`.''' '''Duplicate/related tickets are being collapsed into this thread. Please continue all related discussion here.'''" blobfolio 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 51525 Add new functions apply_filters_single_type() and apply_filters_ref_array_single_type() General normal normal Future Release feature request new dev-feedback 2020-10-15T05:53:25Z 2023-10-03T10:32:50Z "This is a proposal to add two new functions ~~`apply_filters_typesafe()`~~ `apply_filters_single_type()` and ~~`apply_filters_ref_array_typesafe()`~~ `apply_filters_ref_array_single_type()`. == Underlying reasons PHP 8 is a lot more strict about data types and depending on what is done with the data will start throwing more notices/warnings, but more concerning exceptions, which will result in fatal errors (= white screen of death) when uncaught. == Problem outline Now, say you have a filter hook `foo` which passes an integer as its second argument and expects an integer to be returned. {{{#!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 57586 term_exists() return type not consistent regarding wp_insert_term() Taxonomy 3.0 normal normal Future Release enhancement new dev-feedback 2023-01-30T10:14:03Z 2023-09-15T03:57:43Z "`term_exists()` returns an array of strings containing `term_id` and `term_taxonomy_id`. Although `wp_insert_term()` as well as `wp_update_term()` return an array of integers. For consistency, it'd be better to return alway the same type. Also, it'd be less error prone." hugod Future Releases 40351 Term post re-counts scale poorly, are common and difficult to avoid whyisjake Taxonomy 4.8 normal normal Future Release enhancement reopened has-patch 2017-04-04T01:18:28Z 2023-09-11T02:20:51Z "Under normal conditions whenever a post status transition occurs, `_update_term_count_on_transition_post_status` attempts to completely recalculate the post counts for each term related to the post by re-counting each term's total number of post relationships.. For sites with large term relationship tables, large numbers of total terms and high numbers of terms per post, this recalculation does not scale well and can lead to wp-admin lag (while saving a post for example) or failed queries. A typical bad scenario looks like this: Consider a site with a large term_relationship table and a post with (say) 30 terms assigned to it. When that post is updated, an eventual call to `_update_post_term_count` will cause that function to execute 60 total queries on some very large tables. 30 are SELECTs: `SELECT COUNT(*) FROM $wpdb->term_relationships, $wpdb->posts WHERE $wpdb->posts.ID = $wpdb->term_relationships.object_id AND post_status = 'publish' AND post_type IN ('"" . implode(""', '"", $object_types ) . ""') AND term_taxonomy_id = %d` (This is actually the hopeful case, since if we need to count attachments too, those are added to the above query via a subselect which probably makes things worse.) Interspersed among the 30 SELECTs are 30 UPDATEs to the tt table, generated by: `$wpdb->update( $wpdb->term_taxonomy, compact( 'count' ), array( 'term_taxonomy_id' => $term ) );` One result of all of this can be failed queries -- typically the SELECTs -- and incorrect term post counts. Even more frequently the issue manifests as slow post updating behavior (the lag a user feels while waiting for a post to save or publish.) We currently provide two mechanisms (besides just unhooking `_update_term_count_on_transition_post_status` entirely and not updating term post counts at all) to do something about this problem. The first is to defer post counts, but this just delays the badness until a later call of `wp_update_term_count`. The second is to define a per-taxonomy custom update callback using `update_count_callback`. Neither of these mechanisms is intended to improve performance, and both are obscure. It would be better to by default increment or decrement post counts directly in the tt table in response to posts entering or leaving published (or other countable) stati, and reserve complete recalculations for special occasions (such as when a term is edited.) Using this strategy, the 60 total queries in the example above could -- on publish -- be replaced by a '''a single''' query that would look something like: `UPDATE {$wpdb->term_taxonomy} AS tt SET tt.count = tt.count + 1 WHERE tt.term_taxonomy_id IN ( .... )` (where the final list is a list of tt_ids.) This solution is implemented now as a plugin here: https://github.com/Automattic/lightweight-term-count-update. Patch based on this on the way soon." mattoperry 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 47642 Order by comment count - posts list tables johnbillion Posts, Post Types normal normal Future Release defect (bug) reviewing has-patch 2019-07-02T23:20:20Z 2023-07-18T16:21:07Z "Results from posts list tables with enabled ordering by comment count are mixed (posts are missing and aren't unique). Pagination required. Links: wp-admin/edit.php?orderby=comment_count&order=asc wp-admin/edit.php?orderby=comment_count&order=asc&paged=2 No matter which post type. You need to set 'Number of items per page' in screen options in order to get a pagination. [[Image(https://i.imgur.com/HupwtnS.png)]] Set sorting by comment count in comments column. [[Image(https://i.imgur.com/zFDU7Oj.png)]] In lists of posts some of them are missing. Page number 1 and number 2 don't have unique posts. I was testing it for some cases: 30+ posts and 'posts_per_page' = 20 30+ posts and 'posts_per_page' = 10 250+ posts and 'posts_per_page' = 20 24 pages and 'posts_per_page' = 20 Results in all cases were wrong. The official queries are from wp-includes/class-wp-query.php (line: 2984) [https://github.com/WordPress/WordPress/blob/master/wp-includes/class-wp-query.php#L2984], variable: $this->request. Below applied filter are generated ids for current posts. [[Image(https://i.imgur.com/tWevfpW.png)]] SQL queries from debugging (official queries): **Page number 1 (paged=1):** {{{ SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'future' OR wp_posts.post_status = 'draft' OR wp_posts.post_status = 'pending' OR wp_posts.post_status = 'private') ORDER BY wp_posts.comment_count ASC LIMIT 0, 20 }}} Result: [[Image(https://i.imgur.com/rFyTHjE.png)]] **Page number 1 (paged=2):** {{{ SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'future' OR wp_posts.post_status = 'draft' OR wp_posts.post_status = 'pending' OR wp_posts.post_status = 'private') ORDER BY wp_posts.comment_count ASC LIMIT 20, 20 }}} Result: [[Image(https://i.imgur.com/THMM1Ri.png)]] What's funny if I added **'wp_posts.post_title'** to query the problem is solved (unique posts): [[Image(https://i.imgur.com/nxn3tCy.png)]] [[Image(https://i.imgur.com/whvDFaI.png)]] I think that problem is actually in the database queries/ settings what's caused the bad output in admin's panel. For other sorting like title or date this problem doesn't occur. " alektabor Future Releases 41305 Add lazily evaluated translations timothyblynjacobs I18N 4.8 normal normal Future Release enhancement assigned dev-feedback 2017-07-13T11:16:56Z 2023-05-12T12:14:20Z "In the context of #40988, I did a few performance tests and experimented with adding a lazily evaluated translation object. The general principle is this: Instead of returning the resulting string of a translation, return an object for which the `__toString()` and `jsonSerialize()` methods will fetch the resulting string instead. I tested by having the `__()` method return such a proxy object, instead of the actual translated string. From a quick profiling run on `wptrunk.dev/wp-json/wp/v2/posts`, I got the following results: Returning a `translate()` from `__()`: {{{ Wall Time 162ms CPU Time 157ms I/O Time 5.48ms Memory 16.5MB Network n/a n/a n/a SQL 4.41ms 13rq }}} Returning a `TranslationProxy` from `__()`: {{{ Wall Time 144ms -19ms -14.9% CPU Time 138ms -18ms -15.4% I/O Time 5.33ms -154µs -3.0% Memory 16.6MB +81.6KB n/s Network n/a n/a n/a SQL 4.33ms 13rq }}} As you can see, this shaved off almost 15% from this simple request. It saved 2255 calls to `translate()`, 2157 calls to `get_translations_for_domain()` and, more importantly still, 2156 calls to `apply_filters()` (which could involve a lot of additional processing in some cases). The main problem with this approach is that WordPress does not contain real type-hinting, so BC is broken wherever the proxy is not echoed, but used directly. As we cannot possibly foresee how plugins might use their localized strings, I suggest adding new lazy variations of the translation functions. To mirror the ""echo"" variations that prefix the translation functions with an `e`, I'd suggest using the `l` prefix for these variations: {{{#!php // Lazily retrieve the translation of $text. _l( $text , $domain = 'default' ); // Lazily retrieve the translation of $text and escape it for safe use in an attribute. esc_attr_l( $text, $domain = 'default' ); // Lazily retrieve the translation of $text and escape it for safe use in HTML output. esc_html_l( $text, $domain = 'default' ); // Lazily retrieve translated string with gettext context. _lx( $text, $context, $domain = 'default' ); // Lazily translate string with gettext context, and escape it for safe use in an attribute. esc_attr_lx( $text, $context, $domain = 'default' ); // Lazily translate string with gettext context, and escape it for safe use in HTML output. esc_html_lx( $text, $context, $domain = 'default' ); }}} Arbitrary testing has shown that using such lazily evaluated translations strategically can improve the performance by 10-30% for certain scenarios. Implementing them in this BC fashion allows us to fine-tune Core usage and make it available to plugins, while playing it safe with existing code." schlessera 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 37840 Optimize full size images enshrined Media normal normal Future Release enhancement assigned has-patch 2016-08-26T15:12:04Z 2023-03-13T16:26:19Z "Many users upload unoptimized full size images to the media library, which can result in unnecessarily large downloads for users when the full size image is inserted in post content or when the full size image is added to `srcset` attributes. We could potentially improve things by adding a new image size to WordPress that is an optimized version of the original image and use that on the front end instead of the original uploaded image. Some considerations: * We should not modify the original uploaded file. * Consider potential server implications of adding an additional size. * Can we determine if a file is already optimized so we don't end up increasing the file size in those cases?" joemcgill Future Releases 16839 Category Base Should be Slugified SergeyBiryukov* Rewrite Rules 3.1 normal normal Future Release defect (bug) accepted needs-unit-tests 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 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 needs-unit-tests 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 54356 Determine and apply best default quality settings for WebP images adamsilverstein Media 5.8 normal normal Future Release enhancement assigned dev-feedback 2021-11-01T16:21:18Z 2023-01-19T06:45:51Z "In ticket:35725 we added core support for the WebP image format. On the ticket, we discussed studying the best compression level (""quality"") setting to use for WebP images ([https://core.trac.wordpress.org/ticket/35725#comment:152 comment 152], [https://core.trac.wordpress.org/ticket/35725#comment:124 comment 124], [https://core.trac.wordpress.org/ticket/35725#comment:117 comment 117], [https://core.trac.wordpress.org/ticket/35725#comment:101 comment 101]). In the end we decided to use the same default quality as JPEG images use for our initial pass. However, given the differences between the formats (and in anticipation of even newer formats), we should consider what the best default quality setting would be for WebP images. Some details on how we can test compression settings and arrive at an ideal level are [https://developers.google.com/speed/webp/docs/webp_study outlined in this post]. Related: #53669 " adamsilverstein Future Releases 54582 Problem with deleting old files at the end of a core update when the filesystem is case-insensitive SergeyBiryukov* Upgrade/Install high major Future Release defect (bug) accepted changes-requested 2021-12-05T22:53:38Z 2023-01-12T20:13:49Z "WP 5.9 updates the external Requests library (used by [https://developer.wordpress.org/reference/functions/wp_remote_get/ wp_remote_get()], et. al). As part of that update, a number of filenames have changed in case only, e.g. * wp-includes/Requests/IRI.php => wp-includes/Requests/Iri.php * wp-includes/Requests/Transport/cURL.php => wp-includes/Requests/Transport/Curl.php When updating to 5.9-beta1 via `wp-cli` on a system that uses a case-insensitive filesystem (not only Windows, but that's the most obvioous example) via the `wp core update --version=5.9-beta` command, all those files that have been renamed in case only get incorrectly deleted (in [https://github.com/wp-cli/core-command/blob/5d5cc4631381cad926b5c73841df31250cc8ff5e/src/Core_Command.php#L1352 Core_Command::cleanup_extra_files()]) which results in PHP fatal error(s). This was discovered during the 5.9-beta1 release party, and an [https://github.com/wp-cli/core-command/issues/195 issue was created] against that wp-cli command. Core has it's own means on deleting files from previous releases, but it doesn't come into play until a major release package to built. [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/update-core.php#L21 wp-admin/includes/update-core.php] defines the `$_old_files` array that contains files from all previous WP versions that should be deleted by core after an update has been performed. That array is not amended until just before the `major` version package is created (see [https://make.wordpress.org/core/handbook/about/release-cycle/releasing-major-versions/#dry-run Releasing Major Versions] in the Core Handbook]. I've been experimenting and I think the exact same thing will happen when 5.9 is is released and sites are updated via the Dashboard. To test this hypothesis I did the following on a Windows machine (with basically a WAMP stack): 1. Installed 5.8.2 2. Edited `wp-admin/includes/class-core-upgrader.php` and added `global $_old_files; $_old_files[] = 'wp-includes/Requests/IRI.php';` just before [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/class-core-upgrader.php#L172 line 172]. This simulates that file being added to the `$_old_files` array in [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/update-core.php#L21 wp-admin/includes/update-core.php] of the 5.9 release package. 3. Added `define( 'WP_AUTO_UPDATE_CORE', 'beta' );` to `wp-config.php`. This allows core to update to 5.9-beta1 in `Dashboard > Updates` (without the need for wp-cli nor the [https://wordpress.org/plugins/wordpress-beta-tester Beta Tester plugin]. 4. Went to `Dashboard > Updates` and clicked on the `Update to version 5.9-beta1` button 5. When the update finished, I looked on disk and found that neither `wp-includes/Requests/IRI.php` nor `wp-includes/Requests/Iri.php` existed 6. Went back to `Dashboard > Updates` (which causes [https://developer.wordpress.org/reference/functions/wp_version_check/ wp_version_check()], and thus `wp_remote_get()`, to be called...resulting in a fatal error (`Fatal error: Uncaught Error: Class 'WpOrg\Requests\Iri' not found in ABSPATH\wp-includes\Requests\Requests.php on line 682`) One might thing that to avoid this problem, any files whose name case in case only just shouldn'd be added to `$_old_files`. Unfortunately, that would be bad for sites with case-senstive filesystems, because then files with both filenames would exist on disk after the update (e.g., both `wp-includes/Requests/Iri.php` and /wp-includes/Requests-IRI.php`). To prove this to myself, I then did the following on a machine with a case-sensitive filesystem (centos 7): 1. installed 5.8.2 2. Added `define( 'WP_AUTO_UPDATE_CORE', 'beta' );` to `wp-config.php` 3. Went to `Dashboard > Updates` and clicked on the `Update to version 5.9-beta1` button 4. When the update finished, I looked on disk and found that both `wp-includes/Requests/IRI.php` and `wp-includes/Requests/Iri.php` existed 5. Rolled back to 5.8.2 6. Edited `wp-admin/includes/class-core-upgrader.php and added `global $_old_files; $_old_files[] = 'wp-includes/Requests/IRI.php';` just before line 172 7. Went to `Dashboard > Updates` and clicked on the `Update to version 5.9-beta1` button 8. When the update finished, I looked on disk and found that only `wp-includes/Requests/Iri.php` existed, as it should be As mentioned, I've only tested these hypotheses on Windows and linux (centos). It would be great if someone could test on MacOS (in both it's case-sensitive and case-insensitive filesystem configurations)!!! What do I think should be done to solve this? The ""delete old files"" routines in both core and wp-cli should check whether the filesystem is case-insensitive and, if so, not delete files whose names have changed only in case (note: the current [https://github.com/wp-cli/core-command/pull/196 PR] against wp-cli's `wp core update` command doesn't yet do this). I've been experimenting with how to detect whether the filesystem is case-insensitive (hint: just checking the OS is **not** sufficient, for a number of reasons). I'll add some comments about this after I finish opening this ticket. Related: #54546, #54547, https://github.com/wp-cli/core-command/issues/195" pbiron Future Releases 49278 Improve meta query Query 5.3.2 normal normal Future Release enhancement new dev-feedback 2020-01-23T16:32:32Z 2023-01-03T20:14:48Z "When having a couple of Meta Query statements in WP_Query the query becomes very slow. I think this is because of the way the JOINs are created. Currently the JOINs are only done on the Post ID. The JOIN can become enormous, which means that filtering (the WHERE part) will take a lot of time. I checked /wp-includes/class-wp-meta-query.php and posted the code between line 557 and 573 . {{{ // JOIN clauses for NOT EXISTS have their own syntax. if ( 'NOT EXISTS' === $meta_compare ) { $join .= "" LEFT JOIN $this->meta_table""; $join .= $i ? "" AS $alias"" : ''; if ( 'LIKE' === $meta_compare_key ) { $join .= $wpdb->prepare( "" ON ($this->primary_table.$this->primary_id_column = $alias.$this->meta_id_column AND $alias.meta_key LIKE %s )"", '%' . $wpdb->esc_like( $clause['key'] ) . '%' ); } else { $join .= $wpdb->prepare( "" ON ($this->primary_table.$this->primary_id_column = $alias.$this->meta_id_column AND $alias.meta_key = %s )"", $clause['key'] ); } // All other JOIN clauses. } else { $join .= "" INNER JOIN $this->meta_table""; $join .= $i ? "" AS $alias"" : ''; $join .= "" ON ( $this->primary_table.$this->primary_id_column = $alias.$this->meta_id_column )""; } }}} Apparantly when using the 'NOT EXISTS' compare the 'AND $alias.meta_key' part is added to the JOIN, but when NOT using the 'NOT EXISTS' compare this part is not there. This means that when NOT using the 'NOT EXISTS' compare the a lot of data is joined in the temporary data set. I played with this part a bit and when adding the 'AND $alias.meta_key' part to those JOINs as well it sped up my query a lot. My query went from 38 seconds to 0.01 seconds with the same results. My 'test' code: {{{ // JOIN clauses for NOT EXISTS have their own syntax. if ( 'NOT EXISTS' === $meta_compare ) { $join .= "" LEFT JOIN $this->meta_table""; $join .= $i ? "" AS $alias"" : ''; if ( 'LIKE' === $meta_compare_key ) { $join .= $wpdb->prepare( "" ON ($this->primary_table.$this->primary_id_column = $alias.$this->meta_id_column AND $alias.meta_key LIKE %s )"", '%' . $wpdb->esc_like( $clause['key'] ) . '%' ); } else { $join .= $wpdb->prepare( "" ON ($this->primary_table.$this->primary_id_column = $alias.$this->meta_id_column AND $alias.meta_key = %s )"", $clause['key'] ); } // All other JOIN clauses. } else { $join .= "" INNER JOIN $this->meta_table""; $join .= $i ? "" AS $alias"" : ''; $valid_compares = array( '=', '!=', '>', '>=', '<', '<=', 'IN', 'NOT IN', 'EXISTS', ); if( in_array($meta_compare, $valid_compares ) && !empty($clause['key']) && 'LIKE' !== $meta_compare_key ) { $join .= $wpdb->prepare( "" ON ( $this->primary_table.$this->primary_id_column = $alias.$this->meta_id_column AND $alias.meta_key = %s )"", $clause['key']); } else { $join .= "" ON ( $this->primary_table.$this->primary_id_column = $alias.$this->meta_id_column )""; } } }}} I'm not really sure if this works in all cases (with all compare/compare_key variations), but I think it would be good to check it out (on Github I've seen that the last improvements here have been done at least 2 years ago). For now I 'solved' my slow query by parsing the JOIN and WHERE on the filter 'get_meta_sql' and add the 'AND' part in the JOIN. Below the query that gets created before and after the changes. Query before (38 seconds): {{{ SELECT SQL_CALC_FOUND_ROWS riff19_posts.ID FROM riff19_posts INNER JOIN riff19_postmeta ON ( riff19_posts.ID = riff19_postmeta.post_id ) INNER JOIN riff19_postmeta AS mt1 ON ( riff19_posts.ID = mt1.post_id ) INNER JOIN riff19_postmeta AS mt2 ON ( riff19_posts.ID = mt2.post_id ) INNER JOIN riff19_postmeta AS mt3 ON ( riff19_posts.ID = mt3.post_id ) JOIN riff19_icl_translations wpml_translations ON riff19_posts.ID = wpml_translations.element_id AND wpml_translations.element_type = CONCAT('post_', riff19_posts.post_type) WHERE 1=1 AND ( ( riff19_postmeta.meta_key = 'pinplugin_event_start_date' AND CAST(riff19_postmeta.meta_value AS DATE) < '2020-01-23' ) OR ( ( ( mt1.meta_key = 'pinplugin_event_start_date' AND CAST(mt1.meta_value AS DATE) = '2020-01-23' ) AND mt2.meta_key = 'pinplugin_event_start_time' AND ( mt3.meta_key = 'pinplugin_event_end_time' AND CAST(mt3.meta_value AS TIME) <= '17:19:19' ) ) ) ) AND riff19_posts.post_type = 'event' AND (riff19_posts.post_status = 'publish' OR riff19_posts.post_status = 'acf-disabled' OR riff19_posts.post_status = 'private') AND ( ( ( wpml_translations.language_code = 'nl' OR 0 ) AND riff19_posts.post_type IN ('post','page','attachment','wp_block','location','person','news','blog','case','service','event','vacancy','whitepaper' ) ) OR riff19_posts.post_type NOT IN ('post','page','attachment','wp_block','location','person','news','blog','case','service','event','vacancy','whitepaper' ) ) GROUP BY riff19_posts.ID ORDER BY riff19_posts.menu_order, CAST(riff19_postmeta.meta_value AS DATE) DESC, CAST(mt2.meta_value AS TIME) DESC, CAST(mt3.meta_value AS TIME) DESC LIMIT 0, 12 }}} Query after (0.0028 seconds): {{{ SELECT SQL_CALC_FOUND_ROWS riff19_posts.ID FROM riff19_posts INNER JOIN riff19_postmeta ON ( riff19_posts.ID = riff19_postmeta.post_id AND riff19_postmeta.meta_key = 'pinplugin_event_start_date') INNER JOIN riff19_postmeta AS mt1 ON ( riff19_posts.ID = mt1.post_id AND mt1.meta_key = 'pinplugin_event_start_date') INNER JOIN riff19_postmeta AS mt2 ON ( riff19_posts.ID = mt2.post_id AND mt2.meta_key = 'pinplugin_event_start_time') INNER JOIN riff19_postmeta AS mt3 ON ( riff19_posts.ID = mt3.post_id AND mt3.meta_key = 'pinplugin_event_end_time') JOIN riff19_icl_translations wpml_translations ON riff19_posts.ID = wpml_translations.element_id AND wpml_translations.element_type = CONCAT('post_', riff19_posts.post_type) WHERE 1=1 AND ( ( riff19_postmeta.meta_key = 'pinplugin_event_start_date' AND CAST(riff19_postmeta.meta_value AS DATE) < '2020-01-23' ) OR ( ( ( mt1.meta_key = 'pinplugin_event_start_date' AND CAST(mt1.meta_value AS DATE) = '2020-01-23' ) AND mt2.meta_key = 'pinplugin_event_start_time' AND ( mt3.meta_key = 'pinplugin_event_end_time' AND CAST(mt3.meta_value AS TIME) <= '17:18:05' ) ) ) ) AND riff19_posts.post_type = 'event' AND (riff19_posts.post_status = 'publish' OR riff19_posts.post_status = 'acf-disabled' OR riff19_posts.post_status = 'private') AND ( ( ( wpml_translations.language_code = 'nl' OR 0 ) AND riff19_posts.post_type IN ('post','page','attachment','wp_block','location','person','news','blog','case','service','event','vacancy','whitepaper' ) ) OR riff19_posts.post_type NOT IN ('post','page','attachment','wp_block','location','person','news','blog','case','service','event','vacancy','whitepaper' ) ) GROUP BY riff19_posts.ID ORDER BY riff19_posts.menu_order, CAST(riff19_postmeta.meta_value AS DATE) DESC, CAST(mt2.meta_value AS TIME) DESC, CAST(mt3.meta_value AS TIME) DESC LIMIT 0, 12 }}}" jillebehm 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 48456 Update CodeMirror to latest version External Libraries normal normal Future Release enhancement new 2019-10-29T07:55:36Z 2022-10-05T19:48:17Z "From what I can see in the [https://core.trac.wordpress.org/browser/trunk/src/js/_enqueues/vendor/codemirror/codemirror.min.js JS file], we are using CodeMirror version 5.29.1 which is over 2 years old, according to https://codemirror.net/doc/releases.html A lot has happened since then, with the current release being 5.49.2. We should update and set a good example. Getting this in early for 5.4 will allow for testing." TobiasBg Future Releases 53450 [WP_Meta_Query] Add faster LIKE based 'STARTSWITH' and 'ENDSWITH' compare modes for value query Query normal trivial Future Release enhancement new needs-docs 2021-06-18T15:57:59Z 2022-09-20T14:56:48Z "Currently the ""LIKE"" compare mode for meta value compares is only usable for ''contains'' queries as it always adds wildcards around all queries {{{LIKE '%query%'}}}. This makes one use the more complex REGEXP compare mode for queries which easily could be written with {{{LIKE '%query'}}} or {{{LIKE 'query%'}}}. As LIKE is faster than REGEXP it is preferable to use LIKE. See: http://billauer.co.il/blog/2020/12/mysql-index-pattern-matching-performance/ In addition people don't have to use the much more complex regex. Which tends to introduce errors in my experience as most people just copy & paste but do not understand how regex really works (not meant as an offense). So REGEXP should be avoided if possible. I would suggest naming the new compare types {{{STARTSWITH}}} and {{{ENDSWITH}}}. Also adding their {{{NON ...}}} counter parts to match up the ''LIKE'' behaviour. **Maybe** also add an alias for ''LIKE'' named {{{CONTAINS}}} as the current naming ''LIKE'' suggests that you could pass in the wildcards yourself. Which is not the case and thus misleading. But this is just for the sake of the tickets completenes. The pull request only contains code and tests for the new modes. As an alternative I thought about reworking the current LIKE mode to allow custom wildcard passing. But this will clearly break backward compat and thus I discarded this approach." janthiel Future Releases 48222 """Show password"" button overlaps with the LastPass icon" Login and Registration 5.3 normal normal Future Release enhancement assigned has-patch 2019-10-05T14:29:48Z 2022-09-15T20:51:47Z "The new ""Show password"" button added to login screen in [46256] overlaps with the LastPass extension icon. Tested with Google Chrome 77 on Windows 10. This only happens on Log In and Reset Password screens. The Edit User screen is OK, as the button there is separate from the input." SergeyBiryukov Future Releases 54829 Allow classic themes to be optionally block themes if 'templates' and 'parts' folders exists Themes 5.9 normal normal Future Release enhancement new dev-feedback 2022-01-15T18:37:03Z 2022-09-13T08:02:23Z "Hello! I have created folders 'templates' and 'parts' inside classic WordPress theme folder (and 'index.html' file) as noted here: [https://developer.wordpress.org/block-editor/how-to-guides/themes/block-theme-overview/]. This automatically converts classic theme to a block theme. But I want to this conversion was optionally - depending of theme's settings. I was able to create two filters. First filter will disable 'Appearance -> Editor' admin menu item and return 'Appearance -> Customize' menu item. {{{ if ( ! function_exists( 'disable_block_dirs' ) ) : function disable_block_dirs( $path, $file ) { //Custom logic to check settings to make block theme from classic theme here: if ( 'templates/index.html' === $file ) { $path = 'SOME_NOT_EXISTING_PATH'; } return $path; } endif; add_filter( 'theme_file_path', 'disable_block_dirs', 10, 2 ); }}} This filter is used in the '**wp-includes/class-wp-theme.php**' in the **public function get_file_path**, which is used in the **public function is_block_theme** Can we patch this file to add some filter **public function is_block_theme** that we could hook to before returning true or false? Second filter is more harmful. It will disable using custom HTML block templates on the front end. But it can be potentially very harmful because it's changing theme_root folder for the WordPress itself. {{{ if ( ! function_exists( 'disable_block_dirs_second' ) ) : function disable_block_dirs_second( $path ) { //Custom logic to check settings to make block theme from classic theme here before return: return 'SOME_NOT_EXISTING_PATH'; } endif; add_filter( 'theme_root', 'disable_block_dirs_second'); }}} This filter is used in the '**wp-includes/block-template-utils.php**' in the **function get_block_theme_folders** Can we patch this file to add some filter to the **get_block_theme_folders** function to filter array that this function is returning that we could hook to? --- Anyway now '**get_block_theme_folders**' and '**wp_get_theme()->is_block_theme**' are working independent from each other that does not make any sense. This should be fixed, I guess. Hope this make sense. Best regards! " exstheme Future Releases 54589 "Audit and preload current ""from"" version files into memory before upgrading filesystem to the ""to"" version" Upgrade/Install 2.7 normal normal Future Release enhancement new has-patch 2021-12-06T14:31:04Z 2022-06-09T06:42:35Z "Follow-up to #54546. Some terms for clarity: * current ""from"" version: the current version of WordPress on the site * new ""to"" version: the version of WordPress that the site will be upgraded to after the upgrade process is complete == The Problem In the `wp-admin/includes/update-core.php` file, the filesystem is upgraded to the new ""to"" version before all of the upgrader process is completed. What happens if the rest of the upgrader process doesn't yet have its code loaded into memory? * Fatal error, for example #54546 * Unexpected behavior due to intermingling of ""from"" and ""to"" version of code A fatal error happened in #54546 when cURL timed out and attempted to throw an exception when its file hadn't yet been loaded into memory. The exception class was changed, which would be handled by the ""to"" version autoloader but was not recognized by the ""from"" version autoloader in memory. While #54546 is a specific instance, it revealed a fundamental problem in Core's upgrader. == The Goal Ensure all files from the current (""from"") version of WordPress that may be needed during the upgrade process are loaded into memory ''before'' upgrading the filesystem and database to the ""to"" version of WordPress. == Audit and Preload current ""from"" version files into memory An audit will be needed to identify all of the files that are or could be used during the upgrade process, including alternative paths such as errors which may have dependencies. A preloader mechanism will be needed capable of loading nested directories (such as loading an entire library or API into memory such as Requests) and individual files. Consideration will be needed for: * differences in current ""from"" versions of files and code * possibly for downgrades from ""to"" version back to the ""from"" version * case-insensitive filesystems as identified in #54582 Props to @jrf, @pbiron, @costdev, @schlessera, @sergeybiryukov, and @mkaz for extensive investigation and testing." hellofromTonya Future Releases 34676 Optimize bulk plugin updates francina Upgrade/Install 4.4 normal normal Future Release enhancement assigned needs-unit-tests 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 54761 Save the prefered language from login page (since WP5.9) Login and Registration 5.9 normal normal Future Release enhancement new dev-feedback 2022-01-07T17:17:33Z 2022-04-09T08:18:57Z "Hello, On WP5.9 a language switcher is added in the wp-login.php. Here is the dev note by @audrasjb https://make.wordpress.org/core/2021/12/20/introducing-new-language-switcher-on-the-login-screen-in-wp-5-9/ I think it should be great if choosing a language here will update the Language user meta to display the back-office in the same language as previously chosen. As per 1st test made, this doesn't currently update." sebastienserre Future Releases 53348 No form to log in when visiting wp-login.php with a given query string SergeyBiryukov Login and Registration normal normal Future Release defect (bug) reviewing needs-unit-tests 2021-06-07T12:46:39Z 2022-04-08T06:05:11Z "When I visit the wp-login.php page with specific query strings, I get a blank page. I don't get a form to log in. The query strings that cause the blank page are - wp-login.php?action=checkemail - wp-login.php?checkemail=foo - wp-login.php?checkemail=bar - wp-login.php?checkemail=baz - Note though, wp-login.php?checkemail=confirm does give me a form" henry.wright Future Releases 46748 authenticate filter hook does not behave as expected for priority values less than 20 SergeyBiryukov* Login and Registration 3.7 normal normal Future Release defect (bug) accepted dev-feedback 2019-04-01T12:33:38Z 2022-04-04T06:23:03Z "Returning null or a WP_Error object from functions bound to the [https://codex.wordpress.org/Plugin_API/Filter_Reference/authenticate authenticate] filter at priority values less than 20 does not prohibit a user from logging in. Consider the following snippet: {{{#!php ` 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 54351 Checking for temp update directories may throw warnings Site Health 6.0 normal normal Future Release defect (bug) new dev-feedback 2021-10-31T15:47:41Z 2022-04-04T05:25:30Z "in [51815] the Site Health function `get_test_update_temp_backup_writable` was introduced, which is meant to check if upgrade directories exist, and are writable. When visiting the Site Health screen in a scenario where `WP_Filesystem` uses `ftpext` for manipulating the filesystem, this causes multiple warnings as the various calls to check for directories, and if they are writable, are causing PHP's `ftp_*` functions to fire, when there may not be a valid FTP connection available. (see [https://github.com/WordPress/wordpress-develop/blob/07ad6efdf7157d22424496d39d8c5635f28ecfbb/src/wp-admin/includes/class-wp-site-health.php#L1968-L1978 class-wp-site-health.php:1968-1678] I wonder if the best solution here might be to inject a connection call, which could then be used to determine if any other fields should be checked, or revert to a default value, I'm thinking along these lines: {{{#!php $filesystem_is_connected = $wp_filesystem->connect(); $wp_content = ( $filesystem_is_connected ? $wp_filesystem->wp_content_dir() : false ); $upgrade_dir_exists = ( $filesystem_is_connected ? $wp_filesystem->is_dir( ""$wp_content/upgrade"" ) : false ); $upgrade_dir_is_writable = ( $filesystem_is_connected ? $wp_filesystem->is_writable( ""$wp_content/upgrade"" ) : false ); $backup_dir_exists = ( $filesystem_is_connected ? $wp_filesystem->is_dir( ""$wp_content/upgrade/temp-backup"" ) : false ); $backup_dir_is_writable = ( $filesystem_is_connected ? $wp_filesystem->is_writable( ""$wp_content/upgrade/temp-backup"" ) : false ); $plugins_dir_exists = ( $filesystem_is_connected ? $wp_filesystem->is_dir( ""$wp_content/upgrade/temp-backup/plugins"" ) : false ); $plugins_dir_is_writable = ( $filesystem_is_connected ? $wp_filesystem->is_writable( ""$wp_content/upgrade/temp-backup/plugins"" ) : false ); $themes_dir_exists = ( $filesystem_is_connected ? $wp_filesystem->is_dir( ""$wp_content/upgrade/temp-backup/themes"" ) : false ); $themes_dir_is_writable = ( $filesystem_is_connected ? $wp_filesystem->is_writable( ""$wp_content/upgrade/temp-backup/themes"" ) : false ); }}} It should be noted that by providing `false` as the default value for all fields, we are essentially marking this check as valid, which may not be true at all, because if WordPress can't connect to the filesystem, it should instead be a failed test. The directories should probably be considered non-writable if they can't even be reached, this needs different logic further into the checks as well? This may still lead to a warning as well, if the `connect()` function is missing variables, in testing where no information is provided, it only complained about a missing hostname, we'll handle that in a separate ticket for the Filesystem API component." Clorith Future Releases 55207 WP_Query returns published sticky posts when post_status is set to draft Query normal normal Future Release defect (bug) new 2022-02-20T14:06:52Z 2022-03-28T05:37:33Z "Originally reported here - [https://github.com/wp-cli/entity-command/issues/278] **Error:** If a sticky post is published, the following query returns the published sticky post: {{{ 'draft', ) ); ?> ?> }}} Steps to reproduce: 1. Create a sticky post and publish it 2. Create a WP_Query with its 'post_status' set to 'draft' 3. Run the query 4. Observe that the published sticky post is returned **Expected behaviour:** Setting `post_status` to `draft` should not return published sticky posts. " NomNom99 Future Releases 17019 add hooks for Media Library attachment counts SergeyBiryukov Query 2.5 normal normal Future Release enhancement reviewing has-patch 2011-04-02T16:48:24Z 2022-03-03T11:07:24Z "The Media Library attachments listing and edit links can be filtered via existing WP_Query and has_cap hooks. However, corresponding attachment counts are not cleanly filterable. The submitted ticket adds the following filters: * function wp_count_attachments() - result filter 'count_attachments' * WP_Media_List_Table::get_views() - query filter 'attachment_orphans_query' * function update_gallery_tab() - query filter 'gallery_attachment_count_query'" kevinB 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 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 needs-unit-tests 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 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 42947 REST API wrong total pages spacedmonkey REST API 4.9.1 normal normal Future Release defect (bug) assigned has-patch 2017-12-20T17:03:36Z 2021-10-31T05:01:59Z "When I require posts with the draft status the 'x-wp-total' and 'x-wp-totalpages' headers come with extra values ​​being that not all drafts are from the user making a request, so when I try to pick up the second page the answer comes empty. [[Image(https://i.imgur.com/223sEE3.gif)]]" elvishp2006 Future Releases 51317 Remove deprecated JavaScript i18n globals Script Loader 5.5.1 normal normal Future Release enhancement new 2020-09-16T00:35:58Z 2021-05-25T22:55:27Z "Background: #51123 [48923] added backward compatibility for JavaScript i18n globals and properties deprecated in WordPress 5.5. Per the corresponding [https://make.wordpress.org/core/2020/09/01/deprecated-javascript-globals/ dev note on make/core], the plan is to remove this fallback code in two major versions, so it should be deleted in WordPress 5.7. This gives plugin and theme developers ample time to remove the conflicting code and switch to using `wp.i18n`. This ticket serves as a reminder to address this in 5.7." SergeyBiryukov Future Releases 51852 """any"" value in ""post_type"" param in ""get_posts"" by default ignore attachments" Query normal normal Future Release defect (bug) assigned needs-unit-tests 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 37698 wp_kses_split global variable pollution Formatting normal normal Future Release defect (bug) new has-patch 2016-08-17T20:20:15Z 2021-02-09T16:12:22Z "In r10339, `wp_kses_split` was modified so it doesn't longer require the `preg_replace` with the `e` (eval) modifier. This implementation uses globals to pass the values of `$allowed_html` and `$allowed_protocols` to the `_wp_kses_split_callback` function. While in most cases this isn't really a problem, we noticed that a call to `wp_kses_split` (via a filter) from within `_wp_kses_split_callback` may have undesirable effects on the next replacements. The snippet below illustrates this problem, you can see in action in https://3v4l.org/YmYTZ {{{ |$))|(<[^>]*(>|$)|>))%', '_wp_kses_split_callback', $string ); } function _wp_kses_split_callback( $match ) { global $pass_allowed_html, $pass_allowed_protocols; return wp_kses_split2( $match[1], $pass_allowed_html, $pass_allowed_protocols ); } function wp_kses_split2($string, $allowed_html, $allowed_protocols) { wp_kses_split('', array(), array()); // this overrides the globals. print_r( array( $allowed_html, $allowed_protocols ) ); } wp_kses_split(""I link this"", array('a'=>array( 'style' => array() )), array('http') ); }}} One way to fix this would be to use an anonymous function, but I guess that's only available on PHP >= 5.3. Another way is to encapsulate the callback in a class and tie the arguments to an instance of this class." xknown 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 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 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 46484 Cleaning WP from any reference to php4 General normal normal Future Release enhancement new 2019-03-13T17:17:50Z 2019-05-22T20:45:28Z "I think the time as come ! [https://wordpress.org/news/2010/07/eol-for-php4-and-mysql4/ PHP 4 and MySQL 4 End of Life Announcement] Posted July 23, 2010 by Mark Jaquith. Filed under Hosting. {{{ wp51\wp-admin\includes\class-ftp.php 281: // Validate the IPAddress PHP4 returns -1 for invalid, PHP5 false wp51\wp-admin\includes\deprecated.php 504: * PHP4 Constructor - Sets up the object properties. wp51\wp-admin\includes\file.php 201: 'php4', 258: 'php4', wp51\wp-includes\IXR\class-IXR-base64.php 22: * PHP4 constructor. wp51\wp-includes\IXR\class-IXR-client.php 55: * PHP4 constructor. wp51\wp-includes\IXR\class-IXR-clientmulticall.php 22: * PHP4 constructor. wp51\wp-includes\IXR\class-IXR-date.php 32: * PHP4 constructor. wp51\wp-includes\IXR\class-IXR-error.php 24: * PHP4 constructor. wp51\wp-includes\IXR\class-IXR-introspectionserver.php 52: * PHP4 constructor. wp51\wp-includes\IXR\class-IXR-message.php 39: * PHP4 constructor. wp51\wp-includes\IXR\class-IXR-request.php 39: * PHP4 constructor. wp51\wp-includes\IXR\class-IXR-server.php 32: * PHP4 constructor. wp51\wp-includes\IXR\class-IXR-value.php 36: * PHP4 constructor. wp51\wp-includes\pomo\entry.php 67: * PHP4 constructor. wp51\wp-includes\pomo\streams.php 26: * PHP4 constructor. 152: * PHP4 constructor. 231: * PHP4 constructor. 297: * PHP4 constructor. 318: * PHP4 constructor. wp51\wp-includes\Text\Diff\Renderer.php 47: * PHP4 constructor. wp51\wp-includes\Text\Diff.php 59: * PHP4 constructor. 339: * PHP4 constructor. 398: * PHP4 constructor. 430: * PHP4 constructor. 462: * PHP4 constructor. 494: * PHP4 constructor. wp51\wp-includes\atomlib.php 102: * PHP4 constructor. wp51\wp-includes\cache.php 740: * @todo This should be moved to the PHP4 style constructor, PHP5 wp51\wp-includes\class-json.php 152: * PHP4 constructor. 950: * PHP4 constructor. wp51\wp-includes\class-phpass.php 59: * PHP4 constructor. wp51\wp-includes\class-phpmailer.php 3558: 'php4' => 'application/x-httpd-php', wp51\wp-includes\class-pop3.php 69: * PHP4 constructor. 657: // For php4 compatibility wp51\wp-includes\class-wp-widget.php 177: * PHP4 constructor. wp51\wp-includes\class-wp-widget-factory.php 36: * PHP4 constructor. wp51\wp-includes\functions.php 4348: * remove PHP4 style constructors. 4352: * This function is to be used in every PHP4 style constructor method that is deprecated. wp51\wp-includes\general-template.php 3437: case 'php4': wp51\wp-includes\rss.php 102: * PHP4 constructor. 735: * PHP4 constructor. }}} " arena 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): {{{