__group__,ticket,summary,component,_version,_priority,_severity,milestone,type,_status,_created,modified,_description,_reporter,workflow Unclaimed — jump right in!,38622,XML-RPC wp_newComment should return an error when a field exceeds the maximum length,XML-RPC,4.5,low,normal,Awaiting Review,defect (bug),reopened,2016-11-02T16:09:56Z,2024-01-13T06:26:52Z,"We return a `WP_Error` in `wp_handle_comment_submission()` when the comment content, author name, author email, or author url exceeds the maximum length of its respective database column. See #10377. We should do the same in the XML-RPC `wp_newComment()` method.",rachelbaker,has-patch Unclaimed — jump right in!,58255,wp_send_json_error should respect error state passed in WP_Error.,Administration,,normal,normal,Awaiting Review,enhancement,new,2023-05-04T11:00:43Z,2023-06-19T11:03:55Z,WP_Error objects support setting the error state. This is used heavily in the REST API. The function `wp_send_json_error` supports error status code and passing WP_Error as an argument. The `wp_send_json_error` function could respect the status code in WP_Error. ,spacedmonkey,has-patch Unclaimed — jump right in!,11207,WordPress may display incorrect message when post is saved/published/etc,"Posts, Post Types",2.9,normal,normal,Future Release,defect (bug),assigned,2009-11-20T20:23:23Z,2023-11-30T01:24:00Z,"When post is saved, WP calls `wp_insert_post_data` filter. Plugin can use it to change post status. But even post status has been changed via plugin, WP still displays message basing on action originally executed by user. Need to change this and take into account final post status too.",sirzooro,has-patch Unclaimed — jump right in!,52976,user emails comparison should be case insensitive,Users,4.3,normal,normal,Awaiting Review,defect (bug),new,2021-04-06T00:08:20Z,2023-06-29T03:39:02Z,"In [https://core.trac.wordpress.org/browser/tags/5.7/src/wp-includes/user.php#L2188 user.php] for WordPress 5.7, email update comparisons are case sensitive. Is there a specific reason for this? Because emails are case insensitive. Here is the line that does that: {{{ #!php if ( isset( $userdata['user_email'] ) && $user['user_email'] !== $userdata['user_email'] ) }}} Can the function: {{{ #!php strcasecmp }}} be used instead? The problem is that there is a plugin that uses the function: {{{ #!php wp_update_user }}} And it would send a notification for email change even if it was the casing of the characters only. Thanks for your time and consideration",asaifm,has-patch Unclaimed — jump right in!,55376,Use wp_filesize in core,General,,normal,normal,Future Release,enhancement,new,2022-03-11T14:42:42Z,2023-07-10T13:05:00Z,"Introduced in [52837] as part of #49412, the `wp_filesize` function is a wrapper around filesize. It has some improves on this function, like casting to int and filters. The filesize function is call throughout core functions. This function may be useful in more contexts. ",spacedmonkey,has-patch Unclaimed — jump right in!,16191,Uploaded files with quote marks in the filename are undisplayable in MS,Upload,,normal,normal,Future Release,defect (bug),reopened,2011-01-11T19:28:49Z,2019-11-03T18:40:43Z,"If you upload a file with quote marks in the filename, e.g. `""Test"".jpg`, WordPress records the filename as `%22test%22.jpg` but the file is called `""Test"".jpg` (on 'nix-like systems anyway) so is undisplayable. I'm unsure about the implications (security and otherwise) of my suggested patch (attached), so please give feedback. (I guess the other approach would be to retain the url-encoded characters and ensure that the file is named with the URL encoded version of the filename.)",simonwheatley,has-patch Unclaimed — jump right in!,60516,Upgrade Moment.js to the latest version,External Libraries,,normal,normal,Awaiting Review,enhancement,new,2024-02-12T20:02:55Z,2024-02-19T08:46:30Z,"A new version of the `moment` (2.30.1) is now available. The [https://github.com/moment/moment/blob/develop/CHANGELOG.md changelog] and [https://github.com/moment/moment/compare/2.29.4...2.30.1 full of changes] are on [https://github.com/moment/moment GitHub].",desrosj,has-patch Unclaimed — jump right in!,60514,Update whatwg-fetch library,External Libraries,,normal,normal,Awaiting Review,enhancement,new,2024-02-12T19:49:10Z,2024-02-19T09:23:11Z,"A new version of the `whatwg-fetch` polyfill (3.6.20) is available. The [https://github.com/JakeChampion/fetch/blob/main/CHANGELOG.md changelog] and [https://github.com/JakeChampion/fetch/compare/v3.6.17...v3.6.20 full of changes] are on [https://github.com/JakeChampion/fetch/ GitHub].",desrosj,has-patch Tickets with a contributor working on them.,51284,Update style for side meta boxes,Editor,5.5.1,normal,normal,Future Release,enhancement,assigned,2020-09-10T02:56:22Z,2021-12-19T07:29:07Z,"In the latest version 5.5.1, WordPress adds the arrows to the meta box handles to allows users to move a meta box up or down. That works nicely for meta boxes below the content area. However, for the side boxes, the arrows takes a lot of space and reduce the space for the meta box title. The 2nd problem is that the toggle icon (collapse/expand) is different from the Gutenberg panel icon. I attach a screenshot to see the problems clearer. ",rilwis,has-patch Unclaimed — jump right in!,38197,Update Pingback function To Add Return,Pings/Trackbacks,,normal,normal,Future Release,enhancement,assigned,2016-09-30T11:07:47Z,2022-09-30T14:43:00Z,"Related to #36824. Updated to reflect focus on the return issue. In #36824, the proposal was to improve performance of the do_all_pings function. Part of this involves the fact that if a pending trackback URL is sent a pingback successfully, it should not also send a trackback. The function should also optionally return which URLs were successfully pinged or a WP_Error object in the event the sending fails, etc. This would change the signature of the function but would allow for debugging, response to errors, as well as assist in optimizing the do_all_pings function. The original proposal was to deprecate pingback because it includes $content, a parameter better retrieved from the post itself for purposes of integrity. However, that can be addressed in other ways.",dshanske,has-patch Unclaimed — jump right in!,56320,Update mediaelement.js to the latest version,External Libraries,,normal,normal,Future Release,defect (bug),new,2022-08-01T18:20:19Z,2022-08-26T08:44:23Z,"Follow up to #56319 (updating to the latest 4.x release). The latest version of `mediaelement`, as of today, is [https://github.com/mediaelement/mediaelement/releases/tag/5.0.5 5.0.5]. Version 5.0 made the player WCAG 2.1 compliant, but some of the changes required are breaking. It's possible this update can be merged into WordPress without issue, but this update needs to be fully tested, and there may be a developer note required to communicate action that needs to be taken by plugin and theme developers.",desrosj,has-patch Unclaimed — jump right in!,60512,Update backbone.js to the latest version (1.6.0),External Libraries,,normal,normal,Awaiting Review,enhancement,new,2024-02-12T17:27:37Z,2024-02-19T09:11:23Z,Version 1.6.0 of Backbone.js is available (see [https://backbonejs.org/#changelog changelog]).,desrosj,has-patch Unclaimed — jump right in!,60515,Update `regenerator-runtime` polyfill,External Libraries,,normal,normal,Awaiting Review,enhancement,new,2024-02-12T19:51:19Z,2024-02-19T10:00:47Z,"A new version of the `regenerator-runtime` polyfill (0.14.1) is available. The [https://github.com/facebook/regenerator/compare/v0.14.0...v0.14.1 full of changes] are on [https://github.com/facebook/regenerator/ GitHub].",desrosj,has-patch Unclaimed — jump right in!,29798,unified theme and plugin uploader,General,,normal,normal,Future Release,feature request,new,2014-09-29T15:35:12Z,2022-07-15T16:33:11Z,"Hi, many users try to install plugins as themes and than they get a message stylesheet missing. ""The theme is missing the style.css stylesheet"" The same with installing themes as plugins. ""The package could not be installed. No valid plugins were found."" I think it would make it much easier for the people to make the upload unified and check the header to find out if its a theme or plugin and than just redirect to the correct page after the instal. Or at least add a message ""This is a plugin please go to this page to install it"" and ""This is a Theme please go to this page to install it"" ",svenl77,has-patch Unclaimed — jump right in!,60800,Twenty Twenty-One: prevent PHP 8 fatal error from non-string in $tags_list,Bundled Theme,,normal,normal,6.6,defect (bug),new,2024-03-18T16:07:35Z,2024-03-19T09:40:33Z,"In `/inc/template-tags.php` there is a call to `get_the_tag_list()` - https://themes.trac.wordpress.org/browser/twentytwentyone/2.1/inc/template-tags.php#L154 The only check on the return value is an `if` condition. The problem is that a few lines down ( 159 ) it is required to be a string. But the `get_the_tag_list()` function is documented as being able to return `string|false|WP_Error` - https://developer.wordpress.org/reference/functions/get_the_tag_list/ When a `WP_Error` object is returned and used in the string context of the `printf()` a fatal error happens in PHP 8.1: {{{ PHP Fatal error: Uncaught Error: Object of class WP_Error could not be converted to string in twentytwentyone/inc/template-tags.php:159 }}} The `if` condition should be updated to ensure that the `printf()` only gets called if the return value of `get_the_tag_list()` is indeed a string. Something like: {{{ if ( is_string( $tags_list ) ) { }}}",josephscott,has-patch Unclaimed — jump right in!,56290,Twenty Twelve: Button blocks inside widget areas don't apply custom colours,Bundled Theme,5.8,normal,normal,Awaiting Review,defect (bug),new,2022-07-27T05:31:47Z,2023-05-26T12:22:18Z,"A similar issue was reported in #45432 but it was only partially fixed. I have noticed that, while this is fixed for buttons adding to the main content, the problem is still reproducible with buttons added to widget areas. We would need to reduce the specificity of the selectors on widget areas to prevent this.",mrfoxtalbot,has-patch Unclaimed — jump right in!,45907,"Twenty Nineteen: Right-aligned, uncaptioned images inserted via the Classic Editor do not extend beyond the text column",Bundled Theme,5.0,normal,normal,Future Release,defect (bug),new,2019-01-10T16:33:20Z,2020-02-21T15:15:42Z,"Originally reported by @joyously on the Twenty Nineteen GitHub repo: https://github.com/WordPress/twentynineteen/issues/688 The Twenty Nineteen is designed to have right-aligned elements extend beyond the text column like so: [[Image(https://cldup.com/jqNamSAitA-1200x1200.png)]] This works in all cases ''except'' under the following conditions: 1. An image has been inserted via the Classic Editor. 2. The image is floated right. 3. The image does not have a caption. In that case, the image will appear tucked into the text column: [[Image(https://cldup.com/b_oMnbi4XQ-1200x1200.png)]] In that case, the images are housed within paragraph tags. For example: {{{
This is some text that the image will float around.
}}} The `` inherits our max-width styles, and prevents the image from extending beyond the content column. In order to have the image extend beyond the paragraph's width, we'd need to pull it out via negative margins or relative positioning of some sort. The markup would be very different from the markup we're currently using for all other cases though — I'm not personally sure it's worth sorting out for this single use case, but leaving the issue here in case anyone comes across a simple solution. ",kjellr,has-patch Tickets with a contributor working on them.,41155,Themes modal hides admin sidebar sub-menu navigation,Themes,,normal,normal,Awaiting Review,defect (bug),reopened,2017-06-25T05:17:30Z,2024-02-24T17:19:16Z,"Hello Team As this is really awesome as working with the community of wordpress CMS. While reviewing themes of WordPress Me and my colleague @amolebonde face issue about accessing sub-menu navigation when we are theme detail page WordPress Admin > Appearance > Themes > Theme Details. Once we are on Theme Detail page then in case if the user wants to access any Sub Menu Navigation it not shows well, which goes behind the popup theme detail page. For Ref. Screen Shot Attach [[Image(https://s4.postimg.org/qvkwram4d/Screen-_Shot-2017-06-25-at-10.26.18-_AM.jpg)]] Wordpress Version 4.8 Browser Check: SAFARI 10.1.1, Google Chrome 58.0 ",codexdemon,has-patch Unclaimed — jump right in!,37758,The Link Checker tool does not detect some links,Editor,4.6,normal,normal,Awaiting Review,defect (bug),new,2016-08-21T14:25:45Z,2023-09-16T12:09:45Z,"hello, The Link Checker tool in WordPress 4.6 doesn’t detect an error when you put something before ‘http(s)‘. Example: xhttps://www.google.com And the tool does not detect error if a missing letter in ""http"". examples : ttps://core.trac.wordpress.org/newticket htps://core.trac.wordpress.org/newticket htts://core.trac.wordpress.org/newticket",Djibs13,has-patch Tickets with a contributor working on them.,36259,Switching language should update date and time formats,I18N,,normal,normal,Future Release,defect (bug),assigned,2016-03-16T07:43:07Z,2023-11-16T16:49:08Z,"Previously: #11226 1. Install WordPress in English. 2. Switch language to Russian. 3. Date and time formats in General Settings are still `F j, Y` and `g:i a`, which doesn't make sense for Russian and doesn't match the locale defaults (`d.m.Y` and `H:i`, respectively).",SergeyBiryukov,"has-patch, needs-unit-tests" Unclaimed — jump right in!,33073,"Some strings need ""no HTML entities"" translator comments",I18N,,normal,normal,6.6,enhancement,new,2015-07-22T14:44:59Z,2024-02-12T13:49:08Z,"This is a renewal of #10005, which was apparently my first patch to WP 6 years ago, but never got accepted. #10005 was closed as fixed, but it truth it was not (see my last comment there). So, I'm opening a new ticket about this... and updating the description and patch from 6 years :) Here goes! Several strings need to have an indication warning translators against the inclusion of HTML entities within their translation, because of where the strings are user (RSS feeds, e-mails, JavaScript...). Case in point: in French, there should be a non-breaking space ( ) before any double sign (; : ! ?). So, translators would turn ""URL: %s"" into ""Adresse web : %s"". But since it is used in e-mails, it is displayed as-is. And for strings that are used in feeds, it breaks them... Suggestions comment: ""Do not add HTML entities ( , etc): used in [context]"". Patch fixes all strings that I could find. I do hope it is a simple enough patch, and not too close to RC, that it could make it into 4.3. Thanks!",xibe,has-patch Tickets with a contributor working on them.,40353,Site URL and Home URL inputs are not properly validating,"Options, Meta APIs",,normal,normal,Awaiting Review,defect (bug),assigned,2017-04-04T12:33:11Z,2020-04-08T20:34:50Z,"In wp-admin/options-general.php > General settings the URLs not properly validating. I tried the following with WordPress address (URL) input: http://local.mysite. com http://local.my?site.com http://local.my*site.com In all three cases WP saves the entry and then the page breaks! A proper handling is required.",subrataemfluence,has-patch Unclaimed — jump right in!,58265,Show defined but empty values for constants in Site Health,Site Health,,normal,normal,Awaiting Review,enhancement,new,2023-05-06T11:22:27Z,2023-06-30T09:53:51Z,"Right now, for example if {{{DB_COLLATE}}} is defined as {{{''}}}, the value will not be shown in the WordPress Constants list, there's just an empty space. What about exchanging empty, but defined values for ""Defined, but empty"" or ""empty value"" or something similar for more clarity? Patching class-wp-debug-data.php, ~L. 333 does the job: {{{ 'value' => ( defined( 'DB_COLLATE' ) ? ( DB_COLLATE === '' ? __( 'Defined as empty' ) : DB_COLLATE ) : __( 'Undefined' ) ), }}} ",Presskopp,has-patch Unclaimed — jump right in!,37669,Shiny Updates: Cancelling the filesystem credentials when updating within the pop-up prevents updating again (without closing/opening) and leaves UI artefacts,Themes,4.6,normal,normal,Future Release,defect (bug),new,2016-08-15T14:16:55Z,2021-02-06T11:39:52Z,"Reproducible on RC3: 4.6-RC3-38260 Reproducible: every time Steps to reproduce: 1) Set up WordPress, and set permissions to that the 'filesystem credentials' dialog will be required when performing theme updates. 2) Tweak a version number so that you will have a theme that needs an update. Then, go to /wp-admin/themes.php 3) Do *not* click on the immediately visible ""Update now"". Instead, click on the theme such that the pop-up pops up. 4) Click on the ""Update now"" link within the pop-up. If step 1) was done correctly, then the filesystem dialog should now pop up. 5) Close the filesystem credentials dialog. Result: ""Updating..."" will still show there. But nothing will be updating. You cannot update until you close the pop-up and re-open it. Excepted result: The ""update now"" link re-appears, and ""Updating.."" disappears. Result: nothing happens. #37285 is similar, but a separate (and now fixed) issue. ",DavidAnderson,has-patch Unclaimed — jump right in!,58844,Revisions: Compare Revisions layout issues on mobile,Revisions,3.6,normal,normal,Future Release,defect (bug),new,2023-07-18T20:45:48Z,2023-11-30T22:50:02Z,"This is a follow-up to #33830. ""Restore This Revision"" button in wp-admin revision page can become hidden behind the diff panel in mobile view, particularly if the post author has a longer name. The problem occurs when the author info (Name & Timestamp) stacks below the Avatar. ",plari,has-patch Tickets with a contributor working on them.,41580,Review the usage of the `::-moz-focus-inner` CSS fix for the buttons extra padding in Firefox,Administration,,normal,normal,Awaiting Review,enhancement,assigned,2017-08-07T14:55:54Z,2022-07-04T11:31:32Z,"For a number of years, Firefox used to set some extra padding on the buttons (or inputs of type button/submit/reset). To address this, WordPress uses a known fix targeting the proprietary Firefox pseudo element `::-moz-focus-inner`. Seems something has changed recently and starting with Firefox 53, FF doesn't apply the extra padding any longer. I ''think'' the relevant Bugzilla ticket Firefox 53 release notes, though. Testing a bit on Windows, in the screenshot below: - on the left, Firefox 48: buttons without and with the CSS fix: there's a clear size difference - on the right: Firefox 54: buttons without and with the CSS fix: no size difference [[Image(https://cldup.com/7AkzV22mi3.png)]] Codepen available here: https://codepen.io/afercia/full/Gvrzwz/ Seems these rules used across the admin stylesheets could be simplified a bit. The only part that needs to stay is `border-width: 0;` or, maybe better, `border: 0;` which is necessary on Windows to remove the dotted line on :focus: [[Image(https://cldup.com/aynypgSW6Y.png)]] This could be also a good opportunity for some clean-up. For example, seems to me in `press-this.css` there are two identical rules. ",afercia,has-patch Tickets with a contributor working on them.,41672,REST create user: existing_user_login is returned before existing_user_email,Users,4.7,normal,normal,Future Release,enhancement,assigned,2017-08-19T01:37:10Z,2021-11-08T20:17:57Z,"When I post to `/wp-json/wp/v2/users` to create a user: {{{ { ""email"": ""brianhenryie@gmail.com"", ""username"": ""brianhenryie"", ""password"": ""password"" } }}} and a user with that username and email address exists, the response is: {{{ { ""code"": ""existing_user_login"", ""message"": ""Sorry, that username already exists!"", ""data"": null } }}} whereas a more useful response would be the existing_user_email response: {{{ { ""code"": ""existing_user_email"", ""message"": ""Sorry, that email address is already used!"", ""data"": null } }}} which is learned once the original POST is updated with a new username. i.e. existing_user_email tells a user if they already have an account. This information could be used to attempt to log in.",bbrian,has-patch Unclaimed — jump right in!,41554,REST API: Use `wp.apiRequest` helper to build URLs for media embed requests,REST API,,normal,normal,Awaiting Review,enhancement,new,2017-08-03T17:41:04Z,2019-09-25T19:12:51Z,"Follow-up to #40919. Let's explore getting rid of the `oEmbedProxyUrl` [https://github.com/WordPress/wordpress-develop/blob/1c28b4a/src/wp-includes/media.php#L3449 property] used to pass a REST API URL down to `wp-admin` code that calls out to this endpoint ([https://github.com/WordPress/wordpress-develop/blob/1c28b4a/src/wp-includes/js/media/views/embed/link.js#L56 example]). We can use the helper library introduced in #40919 instead: {{{#!js wp.apiRequest( { namespace: 'oembed/1.0', path: '/proxy', // ... } ); }}} This helper will allow us to eliminate all `rest_url` calls passed to client code through script localization. This will eventually lead to a lot of duplication, but it seems like it should be very clear from the requesting code which API endpoint is being called.",jnylen0,has-patch Tickets with a contributor working on them.,38813,REST API: Test schema registration for required fields.,REST API,,normal,normal,Future Release,enhancement,assigned,2016-11-16T06:21:36Z,2019-11-30T10:53:13Z,"Follow-up from #38792. For all endpoints included in WordPress core, we want to make sure arguments and parameters are consistently registered and expose a nice, stable API to the world. While we can check this manually, building it into the unit tests is even better. @jnylen0 wrote an initial version [https://gist.github.com/nylen/9021f6d19157a023a0a8a607a3adb28a in Node-based JS], so we can port this to PHP and use the built-in schema rather than sending a HTTP request.",rmccue, Unclaimed — jump right in!,41616,REST API: Expose old slugs,REST API,4.8.1,normal,normal,Future Release,enhancement,new,2017-08-12T05:32:45Z,2021-10-08T10:20:07Z,"Expose the old slugs for all posts including custom post types in the REST API. For example, when building a React-powered app using the WordPress REST API the old slugs are required so that users can be automatically redirected if they clicked on an old link. To expose the old slugs I created a small plugin (see below): {{{#!php true, 'show_in_nav_menus' => true ) ) ; $args = array( 'get_callback' => 'get_old_slugs_for_api', 'schema' => null ); foreach ($post_types as $type) { register_rest_field( $type, 'old_slugs', $args ); } } function get_old_slugs_for_api( $object ) { //get the id of the post object array $post_id = $object['id']; //return the post meta return get_post_meta( $post_id, '_wp_old_slug' ); } }}} ",crosescu,"has-patch, needs-unit-tests" Unclaimed — jump right in!,59960,Replace em-based `line-height` with unitless values,Administration,,normal,normal,Awaiting Review,defect (bug),new,2023-11-24T19:27:42Z,2023-12-01T03:56:15Z,"Follow-up to #44643 The default `line-height` of `1.4em` can cause issues, at least in the iframe-based editor. Other instances probably could be unitless too (while keeping their numeric value). {{{ body { line-height: 1.4; } }}}",sabernhardt,has-patch Tickets with a contributor working on them.,37280,Remove boldness from update notices,General,,normal,normal,Future Release,enhancement,assigned,2016-07-04T22:08:13Z,2021-11-14T10:49:16Z,"Previously: https://wordpress.slack.com/archives/design/p1466093104000007 The notices are currently inconsistent, some are bold, some are not, and some use bold only to highlight words. OH: ''Bold text is just wasted bandwidth.''",ocean90,has-patch Unclaimed — jump right in!,59594,Remove $taxonomies from cache key generation in WP_Term_Query,Taxonomy,,normal,normal,Future Release,enhancement,new,2023-10-11T11:39:34Z,2023-10-26T05:52:15Z,"When generating cache keys in generate_cache_key method in WP_Term_Query, a serialized version of $taxonomies is used. This is not needed as the array of taxonomies are stored in the arguments used to generate the $cache_args variable. This part of the cache key can safely be removed. Before {{{#!php $taxonomies = (array) $args['taxonomy']; $key = md5( serialize( $cache_args ) . serialize( $taxonomies ) . $sql ); }}} After {{{#!php $key = md5( serialize( $cache_args ) . $sql ); }}}",spacedmonkey,has-patch Unclaimed — jump right in!,51811,Query inconsistency between WP_Query and WP_Term_Query,Query,4.6,normal,normal,Awaiting Review,enhancement,new,2020-11-18T01:25:43Z,2020-12-01T15:05:19Z,"For the sake of standardization and simplicity would it be beneficial to use 's' for searches in WP_Term_Query rather than using 'search'? {{{ $wpquery = new WP_Query( array( 's'=>'search term' ) ); }}} {{{ $wptermquery = new WP_Term_Query( array( 'search'=>'search term' ) ); }}} Not entirely sure why there's a differentiation between how a search term is used in the query args. For the sake of standardization and a reduction in confused developers (like I was about 30 minutes ago) I think this is worth some consideration.",tonydjukic,has-patch Unclaimed — jump right in!,54442,Provide feedback if initiating an email for a personal data request action has failed,Privacy,4.9.6,normal,normal,Future Release,defect (bug),new,2021-11-15T08:53:04Z,2023-02-16T12:14:21Z,"When creating a request for an export or a delete personal data request and the confirmation email is enabled, the user doesn't get any feedback if `wp_send_user_request()` was successful. The function returns a `WP_Error` object on failure which should be checked and displayed to the user. Source: https://core.trac.wordpress.org/browser/tags/5.8.2/src/wp-admin/includes/privacy-tools.php?marks=168-171#L168",ocean90,has-patch Tickets with a contributor working on them.,23749,Post Format Archive Conditional Tag,Post Formats,,normal,normal,Future Release,enhancement,assigned,2013-03-12T20:27:04Z,2020-06-26T13:39:59Z,"As far as I know there is no conditional tag for detecting when a post format archive is shown. I bumped into this problem while creating a theme for quick-blogging and realized that I couldn't create a menu (easily) and style the 'current' post format menu item differently. I will try and submit a diff if I can although I've never done it before so it may take me a while :) ",danielpataki,has-patch Tickets with a contributor working on them.,60783,plugins_api() and parameters,Plugins,,normal,normal,6.6,defect (bug),accepted,2024-03-15T13:57:13Z,2024-03-18T04:04:23Z,"Hello there, (running WP6.5+, might be useless to say) By reading the doc for `plugins_api()` you can read that some fields are included or not in the response, the doc says ''""$fields: Array of fields which should or should not be returned.""'' and then you have a list of fields, some true some false by default. Let's try it, this is my simple request on my plugin on repo: {{{#!php 'secupress', 'fields' => [] ) ); }}} Since the doc says ''""@type bool $contributors Whether to return the list of contributors. **Default false**.""'' I should not receive this field. Let see the response: {{{#!php string(37) ""SecuPress Free — WordPress Security"" [""slug""]=> string(9) ""secupress"" [""version""]=> string(7) ""2.2.5.1"" [""author""]=> string(44) ""SecuPress"" [""author_profile""]=> string(41) ""https://profiles.wordpress.org/secupress/"" [""contributors""]=> array(4) { ... }}} There is. Same for those params that are ""false"" by default but still included: ""sections"", ""versions"", ""reviews"", ""banners"", ""active_installs"" (I don't know for ""group"", can't get the thing). Also there is one param that is not affected by the arguments passed and always returned: ""num_ratings"". Finally there is some fields that are always returned where the doc can't help, I tried to use they array keys to cancel them, no chance, this is : ""author', ""author_profile"" (those 2 may be forced, that's ok), ""support_threads"", ""support_threads_resolved"", ""upgrade_notice"", and ""requires_plugin"" (I know it's new, but don't forget it) The patch may have to be done on w.org since this is the site that add too much data and to not respect the passed parameters. Thanks for your time",juliobox,needs-patch Tickets with a contributor working on them.,31977,"Ping status of pages changes to ""closed"" in quick edit","Posts, Post Types",4.2,normal,normal,Future Release,defect (bug),assigned,2015-04-15T11:14:50Z,2022-10-14T17:26:39Z,"WP version: 4.2-beta4 Every page is created with ping_status set to ""open"". If the page is edited in the ""full"" edit form, the ping_status remains untouched. However, if the page is edited in the quick edit form, the ping_status field is changed to ""closed"" since WP 4.2. Since pages don't support the ping functionality, I suppose it shouldn't change the field. Maybe ""closed"" is the propper one, but it should be set on the creation. It makes testing of our plugin a little bit tricky. Thanks. Jan",JanVoracek,has-patch Tickets with a contributor working on them.,60827,"Patterns menu item, put back the context parameter.",I18N,trunk,normal,normal,6.5.1,defect (bug),reopened,2024-03-22T14:14:46Z,2024-03-27T22:44:53Z,"This is a follow up for the next minor release, 6.5.1 and the previous ticket #60825 The commit message by @audrasjb in [57864] stated: `A follow-up changeset will be needed to replace the current __() function with _x() and put back the context parameter.` This is what should replace the call to `__()`: `_x( 'Patterns', 'site editor menu item' )`",kebbet,has-patch Unclaimed — jump right in!,55358,Passing int term term_exists parent param not respected,Taxonomy,,normal,normal,Future Release,defect (bug),new,2022-03-09T18:31:11Z,2024-02-05T21:30:21Z,"If a developer calls terms_exists, with an int as term and parent as an int, the parent value is not respected. So example this will not work. {{{#!php $term = term_exists( 123, 'category', 1); }}} The code will check to see if term 123 exists, but will ignore parent value. This may result in correct / unexpected results. ",spacedmonkey,has-patch Unclaimed — jump right in!,60038,Pass original array of arguments to hooks that fire within `wp_insert_post()`,"Posts, Post Types",,normal,normal,Future Release,enhancement,new,2023-12-08T16:55:31Z,2024-02-23T07:48:49Z,"The `$postarr` value passed to the `wp_insert_post()` function contains context that can be useful to callbacks attached to the actions that fire within this function, but this value isn't passed to any of them. Strangely enough it ''is'' passed to most of the filters there. As an example, a plugin of mine needs to perform logic within a callback on the `wp_insert_post` action based on a mixture of the `tax_input` argument and a custom argument. The `wp_insert_post_data` filter needs to be used to access these values. The `$postarr` value gets copied to `$unsanitized_postarr`. This is the value that should be passed to the actions because it contains the original input array, rather than `$postarr` which includes defaults and sanitised values. Or both should be passed, as per the filters in the function. This affects the following actions: * `pre_post_update` * `edit_attachment` * `attachment_updated` * `add_attachment` * `edit_post_{$post->post_type}` * `edit_post` * `post_updated` * `save_post_{$post->post_type}` * `save_post` * `wp_insert_post` And the following filters: * `add_trashed_suffix_to_trashed_posts` ",johnbillion,has-patch Tickets with a contributor working on them.,40862,Partially visible controls within a pane do not scroll into view,Customize,,low,normal,Future Release,enhancement,assigned,2017-05-25T13:51:57Z,2020-11-25T19:39:42Z,"If the widget pane has many widgets, sometimes the widget dialogue will not be visible when the edit shortcut icon is clicked on the page. If any part of the control is visible, it does not fully scroll into view even though the focus is properly set. A few notes: - If the widget is not in view at all wihtin the pane, it properly scrolls it into view and focuses. - The problem also occurs if the pane is not currently visible when the edit shortcut is clicked. Clicked edit shortcut on a widget in view in the sidebar: https://cldup.com/EPHX4omF81.png Clicked edit shortcut on a widget with part of the header visible in the pane: https://cldup.com/gOsa9rovWG.png",desrosj,has-patch Tickets with a contributor working on them.,41266,Not hard coding the table alias prefix in WP_Meta_Query would make class more extendable,Query,4.8,normal,normal,Future Release,enhancement,assigned,2017-07-07T13:36:44Z,2021-11-07T19:58:01Z,"Hi, I am extending the WP_Meta_Query class for my own uses with custom tables that have the same structure as meta tables. It is an incredibly useful class for this. However the fact that the table alias prefix {{{mt}}} on line 535 is hard coded forces me to do awkward and complex string replaces if I want to use my extensions alongside built in meta queries. I think changing the prefix from being hard coded to a property/function of the meta query object would make this class much more versatile for plugin developers. ",thomaslhotta,has-patch Tickets with a contributor working on them.,32544,No function exposes all supported MIME types,Media,4.2.2,low,normal,,enhancement,assigned,2015-06-01T04:38:30Z,2019-06-04T20:27:35Z,"`wp_get_mime_types()` returns the default WP MIME types, and `get_allowed_mime_types()` returns the default WP MIME types + added MIME types through the `upload_mimes` filter, but the kicker with the latter is that it is filtered based on the currently authenticated user. There needs to be a way to retrieve all MIME types supported, both the default and the ones added through the `upload_mimes` filter, regardless of who is authenticated. I understand there are security reasons for not allowing users to *add* (or write) attachments of a given MIME type, but when a user is reading there needs to be a way to retrieve an unrestricted list of all MIME types. An example use case is below, where all supported MIME types for a service are retrieved from its API and then the subset of types that are both supported by the WordPress install and the service are kept. {{{ function get_service_mime_types() { // the desired function to get un-sanitized MIME types $wp_types = wp_get_all_mime_types(); // get intersection of WP / service MIME types $allowed = array_intersect($wp_types, get_service_mime_types()); $allowed = array_keys($allowed); return $allowed; } }}} As a work-around, I'm currently using the following, but it's flawed -- if a custom MIME type is added conditionally by user type, it won't be included which is not the desired behavior. {{{ array_merge(wp_get_mime_types(), get_allowed_mime_types()) }}}",dan.rossiter,has-patch Tickets with a contributor working on them.,40696,no chance to control wp_count_terms (),Taxonomy,4.7.4,normal,normal,Future Release,enhancement,accepted,2017-05-08T22:15:56Z,2022-09-19T19:18:21Z,"Hey! I'm wondering if i have no chance to filter the resulting number of wp_count_terms (). Theres no filter available there. wp_count_terms () calls get_terms () but it returns the result of $term_query before (""Count queries are not filtered, for legacy reasons."") the ""get_terms"" filter is appliable. So i see no chance to control result of wp_count_terms () without (heavy) diggin in to WP_Term_Query(). Is there a chance for a filter before the function returns in this case? thank you a lot, Christian",krizkroz,has-patch Unclaimed — jump right in!,35567,New argument `is_embeddable` for `register_post_type()`,Embeds,4.4,normal,normal,Awaiting Review,enhancement,assigned,2016-01-21T20:47:31Z,2024-01-26T07:38:05Z,"I really love the new oembed functions! But as much as I love the feature, it would be awesome to have an argument in the register_post_type function to choose, if the posttype should be embedable or not. I have no problem with it to be true by default, but I just would love to deactivate it for certain post types which are not that publicly used. There are already arguments like ""publicly_queryable"" or ""has_archive', so this doesn't seem off.",pampfelimetten,has-patch Unclaimed — jump right in!,43801,Need better documentation to show importance of checking for args while using wp_schedule_event and wp_next_scheduled,Cron API,,normal,normal,Future Release,enhancement,new,2018-04-18T15:47:51Z,2021-01-29T12:44:57Z,"While the user notes https://developer.wordpress.org/reference/functions/wp_next_scheduled/#user-contributed-notes do relay the importance. I believe it is important that the documentation also be more clear about the issue. When coded incorrectly something like {{{ function schedule_my_event(){ if ( ! wp_next_scheduled( 'myevent' ) ) { // This will always be false wp_schedule_event( time(), 'daily', 'myevent', array( false ) ); } } add_action('init','schedule_my_event'); }}} It's potentially disastrous for a site. The cron value in the options would keep on increasing until the database could no longer withstand it. So keeping that in mind I feel the documentation for both wp_next_scheduled and wp_schedule_event should highlight this point more.",digamberpradhan,has-patch Tickets with a contributor working on them.,36036,Multiple CDATA regressions in wp-includes,General,3.4,normal,normal,Future Release,defect (bug),assigned,2016-03-01T23:45:26Z,2020-11-25T19:40:06Z,"There is invalid XHTML at lines 2084-2097 of wp-includes/theme.php ( https://github.com/WordPress/WordPress/blob/3f3fe5a7ed6473e995f9b96ee4bcf36fe4c71a35/wp-includes/theme.php#L2084-L2097 ) This script block needs to be escaped with /**/ Otherwise it will cause rendering errors for people serving XHTML as application/xhtml+xml This was not always like this, as 5 years ago when I made my strict XHTMl theme there were no errors. I recently re-enabled serving as application/xhtml+xml and to my surprise find this regression in the WP codebase.",sephr,has-patch Tickets with a contributor working on them.,60668,Missing translation in login_header() first parameter,Login and Registration,2.1,normal,minor,6.6,enhancement,accepted,2024-03-01T10:22:14Z,2024-03-02T09:19:02Z,"Hey there Actuel code from WP (wp-login.php): {{{#!php current_level ); }}} https://github.com/WordPress/WordPress/blob/master/wp-admin/includes/class-wp-posts-list-table.php#L918-L919 Source: http://wordpress.stackexchange.com/questions/248405/replace-dashes-before-title-in-page-list",gk.loveweb,has-patch Tickets with a contributor working on them.,41081,"Improve Custom Menu widget, show notification if menu is empty or no menu selected",Widgets,4.9,normal,normal,Future Release,enhancement,assigned,2017-06-16T13:33:58Z,2022-06-08T19:34:41Z,"If you choose a menu for Custom Menu widget and we remove all items in that menu OR the menu is not selected -> nothing shows on the page. Maybe we should add a text message that will inform the user that the menu is empty or is not selected?",alexvorn2,has-patch Tickets with a contributor working on them.,41314,"If the required fields are not set on user profile's save, every field's value will be dropped",Users,4.8,normal,normal,Awaiting Review,defect (bug),assigned,2017-07-13T17:43:36Z,2023-10-11T19:45:23Z,"Hi, In the user profile screen, there are some required fields such as email and nickname. Let's say I have added some extra fields using `edit_user_profile` and `show_user_profile` action hooks. These fields are filled by the user, and do not have to be required. If the user fills every field (let's say 20 fields, took 10 minutes to fill) but clears the email field and save the form, there will be shown an admin error: '''ERROR''': Please enter an email. Every field that was filled by the user will be dropped, and has to be refilled. The point is, until the required fields are empty, there is no reason to let the user save the form in the first place. This issue has been discussed in the WordPress Development StackExchange. I've posted 3 solutions for this issue, which can be improvement or bug resolve. Below is a link to the question on WPSE. I would be happy to write an accurate solution, in case the development team decides to push this into their future patches. https://wordpress.stackexchange.com/q/272940/94498 King regards, Jack",jackjohansson,has-patch Unclaimed — jump right in!,44042,Hook for ‘delete_option’ behaviour required,"Options, Meta APIs",1.2,normal,normal,Future Release,enhancement,new,2018-05-11T07:45:45Z,2022-06-02T13:51:37Z,"Hi, I posted this about one month ago in the wordpress support forum: [https://wordpress.org/support/topic/hook-for-delete_option-behaviour-required/] I did not receive any answers there but referred to this forum, so I post it here again:\\ Hi, I would need to prevent and change the deletion of certain options by the WP core function ‘delete_option’. There is a hook {{{ do_action( 'delete_option', $option ); }}} available here: [https://core.trac.wordpress.org/browser/tags/4.9.4/src/wp-includes/option.php#L532]\\ But this does neither provide a way to exit the delete_option function before the option is deleted nor to change the option name to be deleted. In fact this existing hook seems to be pretty useless. Therefore I would need a filter in the first line of the delete_option core function like {{{ $option = apply_filters( 'delete_option_name', $option ); }}} . Or change the line 535 from {{{ $option = trim( $option ); }}} to {{{ $option = trim( apply_filters( 'delete_option_name', $option )); }}} Any chances to get this into core immediately?\\ Thx, Robert ",RobertoDonPedro,has-patch Unclaimed — jump right in!,39473,get_routes() called multiple times within single REST request causing the rest_endpoints() filter to also fire more than once,REST API,4.4,normal,normal,Awaiting Review,enhancement,new,2017-01-04T21:59:38Z,2023-01-19T23:28:07Z,"Hi all, Many thanks for creating the REST API, and also for getting it into core! :) When I had a closer look at how to integrate this in our projects I noticed something peculiar with the rest_endpoints() filter: it is called multiple times over; in some cases twice, in others three times. So I did a little digging around and found that the root cause seemed to be the use of get_routes() at multiple locations: - in the rest_pre_dispatch filter (rest_handle_options_request) - in the rest_post_dispatch filter (rest_send_allow_header) - in the dispatch() itself - in the get_index() method - in the get_namespace_index() method After looking how these locations interact with each other, I couldn't detect any code which altered the generated route map between consecutive calls to get_routes(). I will add a patch in which I propose to store the generated route map in the class, and re-use that one instead of generating yet again the same array (and also re-filtering the same array). Since the name 'endpoints' is already taken, and being used in the initialization as well, I thought it would be prune to use another variable name: $route_map, which is also being used in the current doc-block. I did not profile this patch (not really sure how to do that), so I'm not sure if storing this rather large associative array is a good thing to do. However generating it multiple times (and re-filtering it also) may also be quite 'expensive'. Thanks, Ruud ",ruud@…, Tickets with a contributor working on them.,27888,Feature request: `get_current_admin_url()` and `get_current_admin_hook()`,Administration,3.9,normal,normal,Awaiting Review,feature request,assigned,2014-04-18T12:22:45Z,2019-12-11T20:16:46Z,"It would be sweet if to be able to get the current page's url using some kind of API. And its hook, for that matter. For instance: {{{ public function get_current_admin_page_url() { if (!is_admin()) { return false; } global $pagenow; global $typenow; global $taxnow; global $plugin_page; $url = $pagenow; if (!empty($plugin_page)) { $url .= '?page='.$plugin_page; } elseif (!empty($typenow)) { $url .= '?post_type='.$typenow; } elseif (!empty($taxnow)) { $url .= '?taxonomy='.$taxnow; } return $url; } }}} And something similar for `get_current_admin_hook()`.",Denis-de-Bernardy,"has-patch, needs-unit-tests" Unclaimed — jump right in!,51884,Events Widget: There isn't a UI for clearing the selected city,Administration,6.2,normal,normal,Awaiting Review,enhancement,new,2020-11-27T15:48:17Z,2024-01-25T10:52:52Z,"If someone has manually selected a city in the Events Widget, there isn't an obvious way for them to clear that selection through the UI. They can manually change it to another city, but they can't go back to where the city would be automatically determined by IP geolocation. ---- ''Side note: One workaround is to enter an invalid city, like `narnia`, and then refresh the page.''",iandunn,has-patch Tickets with a contributor working on them.,43706,Email with link to change admin email does not include proposed new email address.,Users,4.9.5,normal,normal,Future Release,enhancement,reviewing,2018-04-05T23:56:22Z,2022-03-21T02:14:38Z,"This is a follow-up to #39112. This can be precarious -- I've received this note twice since locking out the previous administrator (not sure how he is attempting to change the address yet) and there's no way to determine who is requesting the admin email change. The email with the link to change the admin email follows. Howdy [name], You recently requested to have the administration email address on your site changed. If this is correct, please click on the following link to change it: https://siteurl.com/wp-admin/options.php?adminhash=[hash] You can safely ignore and delete this email if you do not want to take this action. This email has been sent to [current admin email] Regards, All at sitename http://siteurl.com",sshanky,has-patch Tickets with a contributor working on them.,42254,Duplicate news entries in Events & News dashboard widget,Administration,4.8,low,minor,Future Release,defect (bug),assigned,2017-10-17T18:15:20Z,2023-10-11T14:26:43Z,"The first item in the News widget is always the latest post from the `wordpress.org/news` blog. The next 3 posts are selected from the `planet.wordpress.org` feed, which itself includes the `wordpress.org/news` blog. This can lead to duplicate entries: [[Image(https://cldup.com/R67ghZqMRh.png)]] One potential solution is to search the list of Planet feed items, to check ifany of them match the current News item. If one does, it would be removed, so that the next oldest item takes its place. Reported by @sergeybiryukov on Slack https://wordpress.slack.com/archives/C02RQBWTW/p1507073219000123 ",iandunn,has-patch Tickets with a contributor working on them.,17146,Don't limit screen meta tab CSS to content within #screen-meta,Help/About,3.1,normal,normal,Future Release,enhancement,new,2011-04-15T20:36:40Z,2021-10-18T19:21:31Z,"Currently, the styles for screen meta tabs are limited to items within #screen-meta. I think we should use the .screen-meta-toggle class instead, so these styles can be used elsewhere in the admin without duplicating the CSS. I ran into this problem when working on the fullscreen plugin and adding a help tab, but not inside #screen-meta.",koopersmith,has-patch Tickets with a contributor working on them.,51289,Documentation issue: get_post_time is getting the time when published not when created,Date/Time,,normal,normal,Future Release,defect (bug),reviewing,2020-09-10T19:50:39Z,2022-02-13T22:08:35Z,"I'm having a doubt with https://developer.wordpress.org/reference/functions/get_post_time/ (probably the same with https://developer.wordpress.org/reference/functions/get_the_date/) They both say 'Retrieve the date on which the post was written.', but from some programming I'm doing now it looks more like 'Retrieve the date on which the post was PUBLISHED.'. Test: create a post in draft or pending and check that date using the function. (I'm doing it with a CPT) ",casiepa,has-patch Unclaimed — jump right in!,60646,Docs: Incorrect return type specified for get_post_custom with negative post ID value,"Posts, Post Types",5.8,normal,trivial,Future Release,defect (bug),new,2024-02-27T15:11:58Z,2024-03-08T12:03:04Z,"On the documentation page for `get_post_custom`, the return type section says: ""False for an invalid $post_id (non-numeric, zero, or negative value)."" https://developer.wordpress.org/reference/functions/get_post_custom/ However, the function applies `absint` to the `$post_id`. So if its value would be negative (i.e. -10), this would be converted a positive value (10), and `get_post_meta` would be called for that post. This post ID can then either exists (resulting in an array being returned) or not (empty string). Perhaps a negative numerical value should not converted? There's a potential for mix-ups? If we keep the code as is, the docs should probably specify that negative values are converted to positive.",roytanck,has-patch Tickets with a contributor working on them.,57416,Do not split query if requesting one post,Query,3.0,normal,normal,Future Release,enhancement,assigned,2023-01-03T13:49:30Z,2023-11-16T12:36:42Z,"When using WP_Query and requesting posts_per_page = 1, there is little to no value in splitting the query and priming posts using _prime_post_caches. This results in one query to get the posts and another to prime it. This means two database queries when this could simply be one. ",spacedmonkey,"has-patch, needs-unit-tests" Tickets with a contributor working on them.,38073,Deprecate and replace wp_reset_vars(),General,4.9,normal,normal,Awaiting Review,enhancement,assigned,2016-09-16T12:34:35Z,2021-09-01T10:18:46Z,"`wp_reset_vars()` sets global variables based on `$_POST` and `$_GET` values. The function is used around 20 times in core and in my opinion this should be zero. Even better, the function should be deprecated. Why? First of all, it's easy to shoot yourself in the foot if you forget to properly sanitize the input value. Second, globals set by `wp_reset_vars()` aren't explicitly globalized in the files / functions using it. You might stumble upon code like this: {{{#!php 50 is being reported as an error. With an empty 'user_nicename' in the users WP table the function 'update_user_caches' will fail with an empty key when calling 'wp_cache_add'. This empty field will give a PHP Warning: ""Function WP_Object_Cache::add was called incorrectly. Cache key must not be an empty string. Please see ..."" Stack trace when the plugin Ultimate Member is calling 'get_users': {{{ wp-includes/functions.php:5835 WP_Object_Cache->is_valid_key() wp-includes/class-wp-object-cache.php:204 WP_Object_Cache->add() wp-includes/cache.php:44 wp_cache_add() wp-includes/user.php:1864 update_user_caches() wp-includes/pluggable.php:141 cache_users() wp-includes/class-wp-user-query.php:856 WP_User_Query->query() wp-includes/class-wp-user-query.php:79 WP_User_Query->__construct() wp-includes/user.php:763 get_users() wp-content/plugins/ultimate-member/includes/core/um-actions-form.php:874 um_submit_form_errors_hook_() wp-includes/class-wp-hook.php:308 do_action('um_submit_form_errors_hook_') wp-content/plugins/ultimate-member/includes/core/um-actions-form.php:293 um_submit_form_errors_hook() wp-includes/class-wp-hook.php:308 do_action('um_submit_form_errors_hook') wp-content/plugins/ultimate-member/includes/core/class-form.php:569 um\core\Form->form_init() wp-includes/class-wp-hook.php:308 do_action('template_redirect') wp-includes/template-loader.php:13 }}} Stack trace when displaying the backend page WP All Users {{{ wp-includes/functions.php:5835 WP_Object_Cache->is_valid_key() wp-includes/class-wp-object-cache.php:204 WP_Object_Cache->add() wp-includes/cache.php:44 wp_cache_add() wp-includes/user.php:1864 update_user_caches() wp-includes/pluggable.php:141 cache_users() wp-includes/class-wp-user-query.php:856 WP_User_Query->query() wp-includes/class-wp-user-query.php:79 WP_User_Query->__construct() wp-admin/includes/class-wp-users-list-table.php:140 WP_Users_List_Table->prepare_items() wp-admin/users.php:521 }}} ",missveronicatv,has-patch Unclaimed — jump right in!,48879,Changing Site Admin Email Assumes Username and Who Took the Action (which may be incorrect),Users,5.3,normal,minor,Future Release,enhancement,new,2019-12-04T20:12:16Z,2024-03-15T16:47:52Z,"(Note that this is on MultiSite and I don't know exactly how it functions on a single site install.) I think the email message that is sent when someone updates a Site Admin Email Address should be modified as to NOT be addressed: Dear CURRENT_USER_NAME, and shouldn't say that ""YOU"" have recently requested to update the email. If I want to change the site admin email for a site, the confirmation email goes to the new email address (say, a client), but the email says ""Dear MadtownLems,"". We have had a few cases now where these emails alarmed users and thought they were phishing attempts or had been hacked. This is very confusing for our users, as they have received an email addressed to someone else, and it tells them that they tried to do something that they may not have tried to do. Rather, I believe the text would be much cleaner if it said something like: ""Someone ('MadtownLems') has requested to update the email address for the site..."" ",MadtownLems,has-patch Tickets with a contributor working on them.,41937,"Change name of ""wp-settings-"" and ""wp-settings-time-"" cookie",Users,,normal,normal,Awaiting Review,enhancement,assigned,2017-09-21T04:14:42Z,2021-12-03T07:23:26Z,"There is no option to change the cookie names of: - wp-settings-time- - wp-settings- Can you add options? It will be nice to add in wp-config.php like other cookies? Thanks in advance.",Neustradamus,has-patch Unclaimed — jump right in!,48489,Big image size threshold should take into account registered image sizes.,Media,5.3,normal,normal,Future Release,defect (bug),new,2019-11-03T20:22:54Z,2023-11-16T11:42:00Z,"The ""big image"" upper size threshold is set to `2560`. If an image size is registered that has a width or height larger than this, then the image will be unexpectedly cropped to `2560`. The value that gets passed through to the `big_image_size_threshold` filter should be set to the maximum value of either `2560` or the largest width or height from all registered image sizes. ",johnbillion,"has-patch, needs-unit-tests" Unclaimed — jump right in!,48937,Auto-refresh maintenance mode screen,Upgrade/Install,,normal,normal,Future Release,enhancement,new,2019-12-11T15:35:48Z,2022-08-08T07:48:44Z,"''I [https://wordpress.org/support/topic/feature-request-with-solution-auto-refresh-maintenance-mode-screen/ already posted this] on the community forums, and was advised to post here instead.'' While WordPress updates a theme, a plugin or its core, it conveniently displays a message to any visitor: > Briefly unavailable for maintenance. Check back in a minute. Unfortunately, when presented with such a bland screen, most visitors will immediately leave and find a different website. If the visitor hasn’t disabled Javascript in his browser, it would be most helpful to make this a little more informative and add some automation: > Briefly unavailable for maintenance. > This page will automatically load when it is available. Have the webpage automatically refresh the page every (say) 10 seconds. Obviously, if the user has disabled Javascript, you can only display the brief message. = Solution I’m not really a programmer, but I’ve taken the default WordPress method and modified it to do just this — see below. You are welcome to use it as is, or to use the ideas and code within, to implement this feature automatically. I have tested this and it seems to work perfectly. A programmer might find a better way to implement it than I have done. There is one problem with what I’ve done, and that is the lack of translation for other languages. I don’t know how to cater for that. Thank you = Revised contents I took the file /wp-content/maintenance.php and modified it as follows. All that I did was to add a
Sorry… Briefly unavailable for scheduled maintenance.
Please try again in a minute.
Thank you for your patience.