__group__ ticket summary owner component _version priority severity milestone type _status workflow _created modified _description _reporter 4-7 Days Ago 29051 get_raw_theme_root : Windows paths Themes 3.9.1 high critical Awaiting Review defect (bug) new 2014-07-29T01:46:10Z 2024-03-14T13:37:39Z "I believe, this problem exists only if there are more than one theme directories. For example, in my code I have: {{{ register_theme_directory( ABSPATH . 'wp-content/themes/' ); }}} Then, on Windows, the options table has: {{{ INSERT INTO `xxx_options` VALUES (678,'template_root','C:\\the\\path\\to\\www.mysite.com\\wp/wp-content/themes/','yes'); INSERT INTO `xxx_options` VALUES (869,'_site_transient_theme_roots','a:2:{s:14:\""twentyfourteen\"";s:57:\""C:\\the\\path\\to\\www.mysite.com\\wp/wp-content/themes/\"";s:8:\""wpglobus\"";s:7:\""/themes\"";}','yes'); }}} On UNIX, of course, I see {{{ INSERT INTO `wpg_options` VALUES (678,'template_root','/the/path/to/www.mysite.com/wp/wp-content/themes/','yes'); INSERT INTO `wpg_options` VALUES (869,'_site_transient_theme_roots','a:2:{s:14:\""twentyfourteen\"";s:55:\""/the/path/to/www.mysite.com/wp/wp-content/themes/\"";s:8:\""wpglobus\"";s:7:\""/themes\"";}','yes'); }}} And what happens is: when I `mysqldump` my database on Windows and load it on UNIX, WordPress gives me White Screen (no errors even in the error log). I believe, '''always storing UNIX paths would solve this problem'''. They work the same on Windows and UNIX." tivnet Yesterday 60794 Central Payment Gateway API for WordPress and All Plugins Plugins normal major Awaiting Review enhancement new 2024-03-18T03:02:49Z 2024-03-18T18:13:30Z "I think it's time to add a built-in payment gateway API to WordPress. Each plugin develops its own API and we develop custom plugins for each plugin. This is ridiculous. Imagine if there was a centralized API and PayPal, Stripe or any payment gateway was integrated for that API. All other plugins will use that API." beycanpress 4-7 Days Ago 10511 Enclosure Custom Fields are automatically deleted Feeds 2.8 high major Future Release defect (bug) reopened has-patch 2009-07-29T14:20:16Z 2024-03-15T06:49:23Z "This bug was introduced by Ticket [http://core.trac.wordpress.org/ticket/6840 6840]. I and many other people only wanted specific fields added as an enclosure (like media files for podcasting) and have added those enclosures as custom fields. Now any time we edit those hundreds of posts, or create a new post, those custom fields are deleted by this ""bug fix"" and there is no way around it without changing code in the functions.php file and then having to redo it anytime an update comes out. Was there no thought put into the great idea of ""let's delete any enclosure field that doesn't have a link in the body of a post""? Wasn't the whole idea of custom fields originally for things like enclosures?" animepulse 4-7 Days Ago 60766 i have faching this error how can i fix this General 6.4.3 normal major Awaiting Review defect (bug) new close 2024-03-13T07:32:45Z 2024-03-13T16:08:17Z " `Warning: require(C:\xampp\htdocs\Nieuprawny/wp-includes/sodium_compat/autoload.php): Failed to open stream: No such file or directory in C:\xampp\htdocs\Nieuprawny\wp-includes\compat.php on line 338` `Fatal error: Uncaught Error: Failed opening required 'C:\xampp\htdocs\Nieuprawny/wp-includes/sodium_compat/autoload.php' (include_path='C:\xampp\php\PEAR') in C:\xampp\htdocs\Nieuprawny\wp-includes\compat.php:338 Stack trace: #0 C:\xampp\htdocs\Nieuprawny\wp-settings.php(34): require() #1 C:\xampp\htdocs\Nieuprawny\wp-config.php(96): require_once('C:\\xampp\\htdocs...') #2 C:\xampp\htdocs\Nieuprawny\wp-load.php(50): require_once('C:\\xampp\\htdocs...') #3 C:\xampp\htdocs\Nieuprawny\wp-blog-header.php(13): require_once('C:\\xampp\\htdocs...') #4 C:\xampp\htdocs\Nieuprawny\index.php(17): require('C:\\xampp\\htdocs...') #5 {main} thrown in C:\xampp\htdocs\Nieuprawny\wp-includes\compat.php on line 338`" rajgt1 Last Week 60708 REST page 2 item 0 === page 1 item 99 when requesting 100 posts from a post type REST API 6.4.3 normal major Awaiting Review defect (bug) new 2024-03-06T16:39:22Z 2024-03-11T06:51:24Z "in our case of a custom WP post type default REST API call page 2 item 0 === page 1 item 99 when requesting 100 items per page. (as of writing this.) Demo: https://deananddavid.com/wp-json/wp/v2/catering_article?lang=de&orderby=menu_order&order=asc&_fields=acf,catering_category,featured_media,id,title&per_page=100&page=1 https://deananddavid.com/wp-json/wp/v2/catering_article?lang=de&orderby=menu_order&order=asc&_fields=acf,catering_category,featured_media,id,title&per_page=100&page=2 This is no issue when requesting 99 items per page." vialars Yesterday 60800 Twenty Twenty-One: prevent PHP 8 fatal error from non-string in $tags_list Bundled Theme normal normal 6.6 defect (bug) new has-patch 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 Yesterday 60315 Editor: Update the WordPress packages to the latest versions for 6.5 Editor normal normal 6.5 task (blessed) assigned has-patch 2024-01-22T10:21:29Z 2024-03-19T09:23:21Z This ticket tracks updates to @wordpress npm packages for 6.5 release. youknowriad Yesterday 60804 wp-admin shows as plain text or shows 403 forbidden Administration 6.4.3 normal normal Awaiting Review defect (bug) new 2024-03-19T08:33:59Z 2024-03-19T08:33:59Z Hello! Im new in WP and im trying to make a website for my business. I made the website and had a little work on it. On the next day some how the admin panel shows up like a plain text. When i try to click on an menu it shows up 403 forbidden. Im hosting it on my own server (xampp). I reinstalled WP and started over again. Last night I worked on the site and everything was fine. This morning I went to school and tried to open the admin. It shows up like plain text and when im trying to access for an example plugins menu it ends up with 403 forbidden. I have a screenshots . In the first time I installed it it was loading super slow, now after the installation it also loads slow but its a little bit better. My joomla site has no such a problems so please fix it. Joomla loads faster and it has no bugs or problems like that. driftaa Yesterday 60614 Button block's Outline style does not have border in non-framed editor Editor trunk normal normal 6.5 defect (bug) new dev-feedback 2024-02-23T03:44:34Z 2024-03-19T07:53:58Z "Hello, I have reviewed the button block and found that the button ""outline"" does not appear on the editor side. Here, I have attached its screenshots: **Environment info -----------------** Device: Macbook M1 OS: 14.3.1 (23D60) Browser: Google Chrome Version 121.0.6167.184 (Official Build) (arm64) WordPress version: 6.4.3 running, Gutenberg 17.7.0, Theme active: Twenty Twenty-Two, Thanks," viralsampat Yesterday 60776 Pullquote block having minor difference in spacing between editor and front side Editor 6.4.3 normal normal Awaiting Review defect (bug) new close 2024-03-14T15:34:47Z 2024-03-19T05:00:13Z "Steps to reproduce the issue :- 1. Activate Twenty Twenty Four theme. 2. Choose Pullquote block. 3. Add text and background to check the proper difference in both side. Now check both the side editor and front. You can able to see spacing difference in editor and frontend. I have attached video for better understanding. Video URL :- https://share.cleanshot.com/D39PTHnJ6TrspTC8XYMw" nidhidhandhukiya Yesterday 60803 Include fonts directory in `get_space_used()` calculation Editor normal normal Awaiting Review defect (bug) new 2024-03-19T02:46:16Z 2024-03-19T02:46:16Z "As font files can be uploaded by users other than the network administrators on multisite installs, the `get_space_used()` function may need to be modified to include the new folder. This will ensure that all files are considered when calculating the amount of upload space available for individual sites on a multi-site install. This isn't super urgent in the early days of the font library so can wait until a 6.5 point release." peterwilsoncc Yesterday 60652 font_dir filter enters an infinite loop if wp_get_upload_dir() is used in the filter callback youknowriad General trunk normal normal 6.5 defect (bug) reopened has-patch 2024-02-28T13:20:40Z 2024-03-19T01:58:08Z "Calling wp_get_upload_dir() inside a font_dir filter callback produces an infinite loop. Use this snippet and try to install a font using the font library to reproduce the issue: {{{#!php For installations that don’t support modification of the wp-content directory, the Font Library will use wp-content/uploads/fonts as a fallback location, ensuring we stay true to our project philosophy of designing for the majority while still making the feature available to anyone out of the box without extra steps from the user. Reference: https://make.wordpress.org/core/2024/03/07/unblocking-wp6-5-font-library-and-synced-pattern-overrides/" mmaattiiaass Yesterday 60787 get_registered_meta_keys() should allow for late registration to improve performance Options, Meta APIs normal normal Awaiting Review enhancement new has-patch 2024-03-15T22:50:45Z 2024-03-19T00:26:05Z "For a site with many custom post types, custom taxonomies, and tons of custom fields -- the burden of register_meta() can become heavy especially when using a plugin like Advanced Custom Fields, Pods, and others. But we shouldn't have to register every single field on every single page load regardless of whether it's needed. That just drains performance on a given site and requires needless DB/transient/cache requests. The introduction of things like the Block Bindings API rely on fields registered through the REST API. You can register fields with the REST API during the `rest_api_init` action (which yeah, you pretty much have to register everything all at once) but at least it's not every page load. With the Block Bindings API rendering on the front of the site, this requires you having run your fields through `register_meta()` on any given page that might have that field bound. Related dev tutorial: https://developer.wordpress.org/news/2024/02/20/introducing-block-bindings-part-1-connecting-custom-fields/ **Proposed solution:** Run an action at the top of `get_registered_meta_keys()` so a plugin can run `register_meta()` ONLY at the time of that data being needed at the code level." sc0ttkclark Yesterday 57789 Make theme.json related caches persistent joemcgill Themes normal normal 6.6 enhancement assigned has-patch 2023-02-22T18:56:45Z 2024-03-18T23:08:29Z "The `theme_json` cache group is currently non-persistent, which means that, even when a site uses a persistent object cache, the data in this cache group will only be cached ''within'' a single request. In other words, there is only a benefit to this caching when a function is called several times, at least more than once, in a single request. Needless to say, we have noticed in the past that parsing `theme.json` and running related logic can be expensive, and the preferable outcome would be to make those caches persistent so that they also can be cached beyond requests. The biggest challenge to this is to implement proper cache invalidation. Originally, within Gutenberg, the cache group was persistent, but it led to problems due to: * cache invalidation hard to figure out (what are all the events can lead to the cached values becoming stale?) * caching logic, rather than database values, is not yet a common practice in WordPress, and one of the quirks is that e.g. action/filter hooks may no longer be run when the logic that contains them is cached, which can lead to a clunky developer experience See related comment https://core.trac.wordpress.org/ticket/57648#comment:17" flixos90 Yesterday 60789 Administration Email Address: Allow method to deactivate Administration normal normal Awaiting Review feature request new close 2024-03-16T01:23:43Z 2024-03-18T21:12:43Z "As a manager of many client sites, my email address is used on a lot of sites in the ""Administration Email Address"" in Settings > General. Over time, clients move to other vendors, and sometimes this happens without the opportunity to change the Administration Email Address before it is moved. In many cases, this email address remains unchanged for years, and I continue to receive software update, user account, and other emails for accounts I have no contact with, and no way to access to change the setting. This has been mentioned by other WordPress developers as well, and I believe it is a widespread problem, although one easy to dismiss on a day-to-day basis. I did a search through Trac tickets and didn't see anything like it, so I am posting this ticket in hopes that a solution can be reached. Ideally, I'd like to see a solution that includes a time-sensitive link (similar to new account registrations) that would allow the owner of the admin to click through to the link, and agree to have the email address removed as the ""Administration Email Address""." andrewhoyer Yesterday 60801 New sessions are created when user authenticates but there already are active sessions Login and Registration 6.4.3 normal normal Awaiting Review defect (bug) new 2024-03-18T18:28:41Z 2024-03-18T21:07:37Z "**The problem:** When a user logs in to WordPress a new session is created. If the user opens a new browser tab and navigates to website/wp-admin, the user does not need to authenticate because of the session cookies are saved in the browser, which is the expected behaviour. The same happens even when the user closes the browser completely and reopens it within the duration of that session. However, if the user navigates to the URL *website/wp-login.php* on the website they are already logged in, the user is presented with a login page, and upon authenticating WordPress creates a new session and new cookies etc, instead of ""retrieving"" the existing logged-in session. **How to reproduce:** 1. Log in to a WordPress website 2. Open a new browser tab on the same browser (you can close the previous one) 3. Navigate to the login page of the same website you are already logged in to: *website/wp-login.php* 4. Log in At this point there are two different sessions for the same user in the database and in the browser the user has multiple sets of cookies for the different sessions. **The issues this causes:** 1. Excessive amount of unnecessary session data in the database. We've seen some large websites with tens of thousands of session entries in the database. 2. Site admins who try to control / limit / manage the number of simultaneous user sessions with third party plugins end up having a lot of problems, such as locking out legit users etc **Possible solution?:** There are a few possible solutions, however, the easiest one we can think of is to check for session cookies in the users' browsers whenever they access the *wp-login.php*, and if there are, retrieve that session." robert681 Yesterday 54628 Third-Party API Integrations General normal normal Awaiting Review feature request new 2021-12-15T00:25:28Z 2024-03-18T18:13:35Z "I have had to write many integrations with Third-Party APIs for WordPress. I would love to see WordPress introduce a more formal way to integrate with various APIs. Take for example Slack, many plugins and themes have written custom code to integrate Slack messages, but the end call to the api is typically the same using `wp_remote_post()`. Currently I have seen some sites with 5 different plugins all connecting to Slack's API. I would love to see the following: A page on WordPress.org (similar to plugins, blocks, etc) where I choose what app/services I want connected to my WordPress install. Theme/Plugin Authors could use these connections instead of writing their own. This can help with managing security and performance with Third-Party APIs. With multiple apps connected to my WordPress install, in the future we can have workflows, similar to Zapier, IFTTT, etc. Many of these integrations are for WordPress Plugins such as Gravity Forms or WooCommerce. If I want to create workflows with those tools and other services, it would be nice if it can be done all within WordPress. " bhubbard Yesterday 58986 TypeError: Unsupported operand types: string * int * Date/Time 6.2.2 normal normal Future Release defect (bug) reopened dev-feedback 2023-08-05T17:08:48Z 2024-03-18T17:57:31Z "Path: `/wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php` File: `class-wp-rest-posts-controller.php` Line: 1833 **Expression Error:** `get_option('gmt_offset') * HOUR_IN_SECONDS` **Rais Exception:** `TypeError: Unsupported operand types: string * int` Suggested Fix: `intval(get_option('gmt_offset')) * HOUR_IN_SECONDS` Thanks " nurielmeni Yesterday 60261 Fatal error with invalid charset specified in Trackback Pings/Trackbacks normal normal 6.6 defect (bug) new has-patch 2024-01-16T01:13:43Z 2024-03-18T17:48:33Z "wp-trackback.php accepts a `charset` parameter, but doesn't validate that the site supports it. Code is effectively this: https://core.trac.wordpress.org/browser/trunk/src/wp-trackback.php?marks=54-76#L53 {{{ $charset = isset( $_POST['charset'] ) ? $_POST['charset'] : ''; $title = isset( $_POST['title'] ) ? wp_unslash( $_POST['title'] ) : ''; $title = mb_convert_encoding( $title, get_option( 'blog_charset' ), $charset ); }}} `charset` ''should be'' a charset that's commonly accepted, such as `UTF-8`, but it could also be specified as `foobar`. This would cause a PHP Warning in PHP 7.4: > E_WARNING: mb_convert_encoding(): Illegal character encoding specified in wp-trackback.php:76 and in PHP 8.1: > Fatal error: Uncaught ValueError: mb_convert_encoding(): Argument #3 ($from_encoding) contains invalid encoding ""FOOBAR"" in wp-trackback.php on line 76 " dd32 Yesterday 60629 PHP Fatal error: Uncaught TypeError: gmdate(): Argument #2 ($timestamp) must be of type ?int, string given in wp-admin/includes/dashboard.php:1025 Date/Time 6.4.3 normal normal Awaiting Review defect (bug) new 2024-02-24T16:57:33Z 2024-03-18T17:00:40Z "== Bug Report === Description Describe the bug. === Environment - WordPress: 6.4.3 - PHP: 8.3.3-1+ubuntu22.04.1+deb.sury.org+1 - Server: Apache/2.4.52 (Ubuntu) - Database: mysqli (Server: 8.0.36-0ubuntu0.22.04.1 / Client: mysqlnd 8.3.3-1+ubuntu22.04.1+deb.sury.org+1) - Browser: Chrome 121.0.0.0 (Windows 10/11) - Theme: tfm4wp 23.05.1 - MU-Plugins: * wp-hide-loader.php - Plugins: * Advanced Cron Manager 2.5.2 * Cron Logger 1.2.1 * ct4gg 1.5.1 * Customer Tools For WordPress 1.1.0 * Cycles For WordPress 24.02.1 * Duplicator 1.5.8.1 * Loco Translate 2.6.6 * Query Monitor 3.15.0 * Solid Security Basique 9.3.1 * stats4wp 1.4.9 * Theme Check 20231220 * WordPress Beta Tester 3.5.5 * WP Hide & Security Enhancer 2.3.1 === Steps to Reproduce 1. Change Php 7.4 to php 8.3 2. login to admin dashboard x. 🐞 Bug occurs. At login to dashboard === Expected Results 1. ✅ What should happen. === Actual Results 1. ❌ What actually happened. [24-Feb-2024 15:34:00 UTC] PHP Fatal error: Uncaught TypeError: gmdate(): Argument #2 ($timestamp) must be of type ?int, string given in /var/www/vhost/dev-wordpress/wp-admin/includes/dashboard.php:1025 Stack trace: #0 /var/www/vhost/dev-wordpress/wp-admin/includes/dashboard.php(1025): gmdate() #1 /var/www/vhost/dev-wordpress/wp-admin/includes/dashboard.php(948): wp_dashboard_recent_posts() #2 /var/www/vhost/dev-wordpress/wp-admin/includes/template.php(1456): wp_dashboard_site_activity() #3 /var/www/vhost/dev-wordpress/wp-admin/includes/dashboard.php(271): do_meta_boxes() #4 /var/www/vhost/dev-wordpress/wp-admin/index.php(204): wp_dashboard() #5 {main} thrown in /var/www/vhost/dev-wordpress/wp-admin/includes/dashboard.php on line 1025" vanhoucke Yesterday 60700 Coding Standards fixes for WP 6.6 General normal normal 6.6 task (blessed) new has-patch 2024-03-06T05:03:13Z 2024-03-18T15:44:26Z "Previously: - #59650 (6.5) - #58831 (6.4) - #57839 (6.3) - #56791 (6.2) - #55647 (6.1) - #54728 (6.0) - #53359 (5.9) - #52627 (5.8) - #51799 (5.7) - #50767 (5.6) - #49542 (5.5) - #49222 (5.4) - #47632 (5.3) - #45934 (5.1)" mukesh27 Yesterday 60799 Change the Header Tag in Link Modal from

to

for Better Accessibility TinyMCE 6.4.3 normal normal Awaiting Review defect (bug) new 2024-03-18T15:38:57Z 2024-03-18T15:38:57Z "=== Problem: Currently, the WordPress link insertion modal in the text editor uses an

tag for its title (""Insert/edit link""). This can create accessibility issues, as multiple

tags on a single page can confuse screen readers and undermine the semantic structure of the content, potentially leading to a poor user experience for people with disabilities. === Proposed Solution: I suggest changing the

tag in the link insertion modal to a

tag, or alternatively to a tag if the heading level is not appropriate in the context of the modal's use. This change would improve the semantic HTML structure and enhance accessibility by maintaining a proper heading hierarchy. === Justification: According to the HTML5 specification and accessibility guidelines, a page should have a clear and logical heading hierarchy. The main content should start with an

tag, followed by

,

, and so on. The current use of an

tag in the link modal disrupts this hierarchy, especially since this modal can appear on any page regardless of the existing heading structure. Implementing this change will make WordPress more accessible and compliant with WCAG (Web Content Accessibility Guidelines) standards, which is crucial for users relying on screen readers and for SEO best practices. === Steps to Reproduce: 1. Go to the WordPress text editor. 2. Click on the 'Add link' button to open the link insertion modal. 3. Inspect the modal's title element, which is currently marked up as an

. === Possible Implementation: The change can be implemented by modifying the HTML structure in the core WordPress files where the link modal is defined. Additionally, testing should be conducted to ensure that this change does not affect the modal's functionality and that it enhances the accessibility as intended. I am looking forward to the community's input on this proposal and am happy to contribute to the implementation and testing phases. " lyonmuller Yesterday 60722 incorrect display of mail due to outdated version of PHP mailer Mail 6.4.3 normal normal Awaiting Review defect (bug) new reporter-feedback 2024-03-07T10:47:34Z 2024-03-18T14:59:57Z "Good morning, I am experiencing problems when displaying order confirmation emails and contact forms from multiple WordPress websites. This code is displayed first in the emails: Content-Type: text/html; charset=UTF-8 I've already been looking into what could be causing it. There it was indicated that it was due to the PHP Mailer version of WordPress. Could it be that the PHP Mailer update is not current with the new version (6.4.3) of WordPress? Yours sincerely, Diana" studiodv Yesterday 60754 Block Hooks: Incorrect context passed when setting ignored hooked blocks metadata General trunk normal normal 6.5 defect (bug) new has-patch 2024-03-12T11:17:36Z 2024-03-18T14:21:50Z "Since [57790], the `rest_pre_insert_wp_template` and `rest_pre_insert_wp_template_part` hooks in the Templates Controller are used to call `inject_ignored_hooked_blocks_metadata_attributes()`, which in turn sets the `ignoredHookedBlocks` metadata attribute on anchor blocks upon writing to the DB. The latter function applies the `hooked_block_types`, `hooked_block`, and `hooked_block_{$hooked_block_type}` filters, in order to inform which blocks should be hooked to a given anchor block. Each of these filters is given a `$context` argument, which in the case of templates (and template parts, respectively) is the containing `WP_Block_Template` object. Since the `rest_pre_insert_`-prefixed filters only pass a `stdClass` object for the relevant `$changes` that need to be made to the relevant template (or template part), `$context` is constructed by fetching the existing template (or part) via `get_block_template()` (using the template/part ID present in the network `$request`). This isn't quite how things should be: `hooked_block_types`, `hooked_block`, and `hooked_block_{$hooked_block_type}` should be given a `$context` object that reflects the template (part) that is about to be persisted to the database, ''not'' the one that's currently stored there. A filter might e.g. look for the presence of a certain block in the template's content; that block might not have been present in the previous version of a template (stored in the DB) but might've been added by the user in the editor (and will be part of the payload that's used to update the DB)." Bernhard Reiter Yesterday 60654 Install several formats of the same font one by one is not possible Editor trunk normal normal 6.6 enhancement new 2024-02-28T17:12:31Z 2024-03-18T11:52:17Z "== Bug Report === Description It's not possible to install multiple formats of the same font by installing one format at a time, but it works if you select different formats for the same upload. === Environment - WordPress: 6.5-beta3 - PHP: 8.1.15 - Server: Apache/2.4.54 (Win64) OpenSSL/1.1.1q mod_fcgid/2.3.10-dev - Database: mysqli (Server: 8.0.30 / Client: mysqlnd 8.1.15) - Browser: Chrome 122.0.0.0 (Windows 10/11) - Theme: Twenty Twenty-Four 1.0 - MU-Plugins: None activated - Plugins: * WordPress Beta Tester 3.5.5 * Debug Log Manager 2.3.1 === Steps to Reproduce 1. Go to Apparence > Editor > Styles. 2. Click on Edit styles button then Typography (in settings sidebar). 3. Click on Manage fonts button then Upload. 4. Click on Upload font and select the font on your computer. Choose a font for which several formats are available (ttf, woff, woff2) and select only one format, e.g. ttf. 5. The font is uploaded and installed. 6. Then click again on Upload font and select another format for the same font, e.g. woff. 7. 🐞 The following error message is displayed: ""No font faces were installed. Fetch error: A font face matching those settings already exists."" But if you upload several formats (ttf, woff and woff2) of the same font at once, then all 3 files are imported and the font is installed 3 times. === Expected Results 1. ✅ It should be possible to install different formats of the same font, at once or in several times. === Actual Results 1. ❌ When uploading different formats of the same font at once, all files are uploaded and installed, with no error message. But if you've already uploaded a format for a font (e.g. ttf), you can't upload the font in another format (such as woff or woff2), and an error message is displayed." jdy68 Yesterday 60798 Investigate potentially failing Imagick PDF alpha channel test Media normal normal Awaiting Review defect (bug) new dev-feedback 2024-03-18T11:30:17Z 2024-03-18T11:31:33Z "The test `\Tests_Image_Editor_Imagick::test_remove_pdf_alpha_channel_should_remove_the_alpha_channel_in_preview()` was introduced in #39216 / [56271]. On some hosting providers, this test appears to be failing with errors such as this: {{{ Tests_Image_Editor_Imagick::test_remove_pdf_alpha_channel_should_remove_the_alpha_channel_in_preview The intermediate size could not be retrieved. Failed asserting that false is of type ""array"". /tmp/wp-test-runner/tests/phpunit/tests/image/editorImagick.php:680 }}} Examples: https://make.wordpress.org/hosting/test-results/r57849/wpsabot-r57849/ https://make.wordpress.org/hosting/test-results/r57848/wetopibot-r57848/ We should investigate this failure to see whether it's an issue in core or with the hosting provider. The test mentions ""Ghostscript version >= 9.14"", so maybe it's just a matter of skipping the test if the installed Ghostscript version (`gs --version` I think) is older than that." swissspidy Yesterday 60780 Twenty Twenty :- Button block having issue with letter spacing Bundled Theme 6.4.3 normal normal Awaiting Review defect (bug) new has-patch 2024-03-15T09:34:25Z 2024-03-18T11:13:32Z "Steps to reproduce the issue :- 1. Activate Twenty Twenty theme. 2. Choose Button block. 3. Add text. 4. Now change the letter spacing. You can able to see there is no difference in letter spacing in editor and front side both. I have attached video for better understanding. Video URL :- https://share.cleanshot.com/mpT4l41VskS7J26DB23b" nidhidhandhukiya Yesterday 60784 Add __experimentalSkipSerialization support to shadow Editor normal normal Awaiting Review enhancement new has-patch 2024-03-15T16:00:00Z 2024-03-18T10:35:51Z "What? This is a backport of the merged Gutenberg PR https://github.com/WordPress/gutenberg/pull/59887 When a dynamic block defines experimentalSkipSerialization in its block.supports.shadow the styles continue to be printed to the block wrapper element. This PR corrects that behavior so that shadow behaves like border, color, and others. Why? This provides the expected behavior for dynamic blocks that need to opt out of having the shadow styles printed to the block wrapper. How? Added a check at the start of the render function to return an empty array of the block has set experimentalSkipSerialization (This is my first attempt at submitting a Gutenberg PR to be included back into WP Core so welcome any advice if I'm doing this wrong)" ColinD Yesterday 56455 Twenty Nineteen: Text Color issue in Pullquote Block Bundled Theme 6.0.1 normal normal Awaiting Review defect (bug) new has-patch 2022-08-29T07:16:04Z 2024-03-18T10:33:29Z "In Twenty Nineteen Theme, when we add Pullquote block in editor side, and choose text color, We can see that the text color is not reflected for ""Add citation"" text.But when we see the same Pullquote block at front side, text color for ""Add quote"" and ""Add citation"" is not reflected. Steps to replicate: 1: Activate the Twenty Nineteen Theme 2: Add Pullquote block 3: Enter some Text for ""Add quote"" 4: Enter some Text for ""Add citation"" 3: Choose Text color 4: Save Page/Post 5: View the page/post at front side For better understanding I provide video attachment link. Video URL : https://share.cleanshot.com/4DhJNFXRZcP8DJKYfZnp Thanks" kajalgohel Yesterday 60796 An error for page and post without revisions support Posts, Post Types 6.4 normal normal Awaiting Review defect (bug) new 2024-03-18T10:03:04Z 2024-03-18T10:03:04Z "Since **6.4.0** the `$revisions_enabled` argument was added to the arguments array of `register_meta()` function (https://developer.wordpress.org/reference/functions/register_meta/#changelog). For post and page with disabled revisions support there is an error: Error: Function register_meta was called incorrectly. Meta keys cannot enable revisions support unless the object subtype supports revisions. Please see Debugging in WordPress for more information. (This message was added in version 6.4.0.). In register_block_core_footnotes() function `revisions_enabled` argument is permanently set to true and it's makes this error." danielpietrasik Yesterday 57774 Add some initial PHPUnit tests for `WP_Filesystem_Direct` hellofromTonya Build/Test Tools 2.5 normal normal 6.5 task (blessed) reopened commit 2023-02-21T00:22:57Z 2024-03-18T09:26:06Z "This is a tests-only ticket. `WP_Filesystem_Direct` is, by far, the most used filesystem abstraction class. While some PHPUnit tests exist for a `WP_Filesystem_MockFS` class, this ticket aims to add PHPUnit tests for the `WP_Filesystem_Direct` class itself. The other filesystem abstraction classes, `WP_Filesystem_FTPext`, `WP_Filesystem_ftpsockets` and `WP_Filesystem_SSH2`, do not have PHPUnit test runner configurations. While in future, we may reuse many of the same tests across filesystem abstraction classes, this ticket specifically targets `WP_Filesystem_Direct`." costdev Yesterday 22369 get_transient() do not call delete_transient() when deleting one General 2.8 normal normal defect (bug) reopened close 2012-11-06T01:27:01Z 2024-03-18T09:11:56Z "Hello i was wondering why get_transient() is not calling delete_transient when deleting a timeouted transient. Piece of code from get_transient() {{{ $transient_option = '_transient_' . $transient; $transient_timeout = '_transient_timeout_' . $transient; if ( get_option( $transient_timeout ) < time() ) { delete_option( $transient_option ); delete_option( $transient_timeout ); return false; } }}} but i need to trigger the ""deleted_transient"" hook. Can we do that: {{{ $transient_option = '_transient_' . $transient; $transient_timeout = '_transient_timeout_' . $transient; if ( get_option( $transient_timeout ) < time() ) { delete_transient( $transient_option ); return false; } }}} " juliobox Yesterday 60783 plugins_api() and parameters audrasjb* 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 Yesterday 60793 wp_trigger error has a wrong wp_kses $allowed_html arguement. Formatting 6.4 normal normal Awaiting Review defect (bug) new has-patch 2024-03-18T02:04:16Z 2024-03-18T02:15:45Z "Elements and attributes need to be array keys, not values. Came with: https://core.trac.wordpress.org/changeset/56707 Fix: https://github.com/WordPress/wordpress-develop/pull/6285" nico23 2 Days Ago 60717 Font Library: Add an ability to replace font General trunk normal normal Awaiting Review enhancement new 2024-03-07T03:31:40Z 2024-03-17T18:54:01Z Instead of the error or notice that the font already exists, the font library should allow replacing the font. Sometimes a font can be corrupted for some reason, and you need to update it. So, the better flow should be to ask the users if they want to replace the font(s). oglekler 2 Days Ago 60716 "Font Library: Replace error message ""A font face matching those settings already exists"" with notice" General trunk normal normal Awaiting Review defect (bug) new 2024-03-07T03:25:56Z 2024-03-17T18:53:45Z If the font already exists, it is not an error, and should not scare the user. oglekler 2 Days Ago 60791 Pre-populate slug using URL parameters on new post edit screen. Posts, Post Types normal normal Awaiting Review enhancement new has-patch 2024-03-17T06:29:23Z 2024-03-17T15:28:10Z "get_default_post_to_edit() allows to pre-populate `post_title`, `content`, and `excerpt` from `$_REQUEST`. This URL will pre-populate the title and the content: /wp-admin/post-new.php?post_type=post&post_title=My+Title&content=aaaa I have an use case where I need to do the same for the `post_name`: https://wordpress.org/support/topic/set-title-and-slug-of-new-post-using-url-parameters/ I have a shortcode that allows me to load content from a custom post type, and it searches by slug (it needs to be this way for UX reasons). If the post with the provided slug doesn't exist, I register an admin notice alerting that the shortcode is trying to load an unexisting post, and offer a link to create the missing post with the specified slug. I need the slug to be pre-populated with the URL parameter, just as it is possible to do for title, content, and excerpt." gerardreches 2 Days Ago 59919 Twenty Sixteen : PullQuote block Typography option is not working properly Bundled Theme normal normal Future Release defect (bug) new has-patch 2023-11-17T05:18:57Z 2024-03-17T05:06:53Z "In Twenty Sixteen, The PullQuote block Typography option is not working properly. if we compare it with other themes when we change the typography size the whole content of the PullQuote Block changes. Here is the Video for proper understanding : https://drive.google.com/file/d/1oFolq5vcgiZVZlXfMV-k5Q34If3m6N61/view?usp=sharing " pranitdugad 2 Days Ago 29341 Raise default value for WP_MEMORY_LIMIT in wp-includes/default-constants.php Bootstrap/Load 4.0 normal normal Awaiting Review enhancement new dev-feedback 2014-08-23T19:45:21Z 2024-03-17T04:33:21Z "wp-includes/default-constants.php currently has a default value for WP_MEMORY_LIMIT of 40Mb (or 64Mb for multisite). The effect of this constant is that if the current value of ini_get( 'memory_limit' ) is less, then ini_set() is used to raise it to at least WP_MEMORY_LIMIT. This default is fine, if your site has few plugins. When the constant was brought in (looks like 3.0, from the comment in the code), sites tended to have fewer plugins, and need less memory. It is not clear exactly what the rationale behind the default choice for WP_MEMORY_LIMIT is, and what data it is based upon. Nevertheless, I get to read a lot of log files through support for one of my plugins, and it is not uncommon for me to see sites where PHP memory use has exceeded 40Mb. It is not uncommon for me to have to advise someone on how to raise their PHP memory limit, because they are trying to clone their site into something like MAMP, which apparently has a lower limit than this (can't verify: I have no Mac), and the WP default is too low to then load their site successfully. Based on my (admittedly anecdotal) experiences, I would recommend 64Mb or 80Mb as a much more suitable default in 2014 (and a corresponding increase for multisite), if the aim is for users to not be surprised by a lack of memory. I don't think that hosting companies will have a problem with this. I have extensive data on default settings of the PHP memory limit, and 99.8% of web hosting companies in that data have 64Mb or more. 99.5% have 96Mb or more." DavidAnderson 3 Days Ago 43305 Accessibility Issue in Arranging the Menu Items: I need a combobox for selecting the parent item and a combobox for selecting the item position rcreators Menus normal normal 6.6 defect (bug) assigned dev-feedback 2018-02-13T07:03:23Z 2024-03-16T14:06:20Z "Hello I shall firstly thank WordPress team for their utmost attention to accessibility standards, which makes WordPress unique among all CMSs. All WordPress core features are fairly Accessible for me as a blind person who uses screen reader (JAWS), but I always have problems with rearranging the menu items. Although the menu-items are also very accessible for a blind person and I can re-arrange them very well, this process is very time consuming for me, because; for example, if I want to send a menu-item from position 16 to position 11, I have to press “Move Up” 5 times. The problem is: I don’t have any combobox that assigns the mother-item and the item-position. Therefore, I have to adjust the positions by moving each item one by one, level by level. Suppose I have a menu with lots of sub-menus and sub-items. Now, I want to add 6 new sub-items to the different menus. Of course, when I add them to the menu, they are at the end of menu. If I want to bring each item to a certain position near the center of menu, I have to click “Move up” and “Move down” one by one for many many times over and over. It takes me about 2 hours to rearrange those menu items. I hope I could explain clearly. Solution: Beside each menu item, there is a link called “Edit Menu Item”. When I click on the link, a set of options open up: move up, move down, name, etc. I would like to have two other options as well: mother-item, and position. For example, I adjust the mother-item of “Audio Translation” as “Translation”, and I adjust its position to “2”, which means subitem number 2 under “Translation”. I hope I could explain clearly what I mean. If I can adjust the menu positions with comboboxes, I will not have to click “move up” and “move down” many many times. " javad2000 3 Days Ago 60790 Editor has encountered an unexpected error Editor trunk normal normal Awaiting Review defect (bug) new 2024-03-16T10:02:59Z 2024-03-16T10:02:59Z "During the customization of the Blog template, an unexpected error was encountered by the editor when changing the line height after uploading a custom font. " shilpamanoj 3 Days Ago 60786 [PHP 8.4] Fix implicit nullable parameter type depcation General trunk normal normal Awaiting Review defect (bug) new has-patch 2024-03-15T20:23:38Z 2024-03-16T03:35:34Z "In PHP 8.4, declaring function/method parameters with a default value of `null` is deprecated if the type is not nullable. [https://wiki.php.net/rfc/deprecate-implicitly-nullable-types RFC] and [https://php.watch/versions/8.4/implicitly-marking-parameter-type-nullable-deprecated PHP 8.4: Implicitly nullable parameter declarations deprecated] Out current minimum PHP requirement is PHP 7.0, but nullable types are only supported in PHP 7.1 and later. Submitting the PR with the fixes and to start a conversation, but merging these changes without bumping minimum PHP requirement to 7.1 will break things on PHP 7.0." ayeshrajans 3 Days Ago 60788 Content-Disposition support in download_url() seems broken HTTP API 6.4.3 normal normal Awaiting Review defect (bug) new 2024-03-16T01:12:30Z 2024-03-16T01:12:30Z " In https://core.trac.wordpress.org/changeset/51939 a change was made to resolve ticket https://core.trac.wordpress.org/ticket/38231 to make `download_url()` use the `Content-Disposition` header to specify the name of the downloaded file. I realize I'm a bit late to the party here since the ticket was opened more than 7 years ago and the change was made more than 2 years ago, but I think that this change was flawed and needs to be reconsidered (and possibly reverted entirely). The way it was implemented seems fundamentally broken and has the effect of making `download_url()` basically impossible to use reliably. Consider the following simple PHP script named `echo.php`: {{{#!php ""Add New Post"". I would love to have this new usability feature added in the core." klevismiho 4-7 Days Ago 60389 PHP unit test for links_add_base_url Build/Test Tools normal normal 6.6 defect (bug) new has-patch 2024-01-30T22:14:08Z 2024-03-14T04:26:47Z pbearne 4-7 Days Ago 49761 Twenty Fourteen: Add gradient background options that fit the theme color scheme Bundled Theme 6.4 normal normal Future Release enhancement new has-patch 2020-04-01T17:47:16Z 2024-03-13T22:40:24Z Now that we have the option for certain blocks to have gradient backgrounds, we need to add gradient background options to the theme that fit the themes color scheme. ianbelanger 4-7 Days Ago 60739 Wrong redirection when installing with URI rewrite Upgrade/Install 3.7 normal normal Future Release defect (bug) new 2024-03-10T22:54:12Z 2024-03-13T21:48:16Z "I have a server where the users can build their own WordPress installations. The URL of such installation is like: https://example.com/u/user/wpfolder/ The folder on disk is like: /srv/http/public_html_user/wpfolder But when the user tries to run the installation setup, an automatic redirection leeds to the following incorrect address: https://example.com/wpfolder/wp-admin/setup-config.php (notice that /u/user/ is missing) So: - REQUEST_URI is '/u/user/wpfolder' - My document root is '/srv/http/public_html_user/' - Therefore the document URI (relative to this document root) is '/wpfolder/index.php' - And the $_SERVER[PHP_SELF] value is '/wpfolder/index.php' I have found that the problem comes from the wp_guess_url function in wp-includes/functions.php file (line 6218): {{{#!php array($term0_id,$term1_id))); }}} affected code starts on line 724 of wp-includes/taxonomy.php Potential problems. 1. I simply added the temp table to the $join variable not knowing if this will cause problems on other queries 2. Clean up of the temporary tables may be needed after query is executed with a persistent connection but in my case they can be left there as mysql will garbage clean them after script disconnects. Attached is a patch to wp-includes/taxonomy.php " robertv123 4-7 Days Ago 60681 Elements: Fix application of element class name when attributes are filtered Editor trunk normal normal 6.6 defect (bug) new has-patch 2024-03-04T07:25:07Z 2024-03-13T19:12:19Z "This ticket tracks the backporting of PHP files for the following Gutenberg changes: - https://github.com/WordPress/gutenberg/pull/59535 These changes fix a bug where if the block data was filtered via `render_block_data` the elements CSS class wouldn't be consistently applied breaking the feature. The initial solution that was merged in Gutenberg via https://github.com/WordPress/gutenberg/pull/59533 caused a conflict in CSS classes that https://github.com/WordPress/gutenberg/pull/59535 addresses." aaronrobertshaw 4-7 Days Ago 60770 TimeZone select box compatibility with RTL directions Administration trunk normal normal Awaiting Review enhancement new has-patch 2024-03-13T15:35:10Z 2024-03-13T16:55:59Z "This patch fixes the time zone select box compatibility with RTL directions It sets auto direction which makes the options value compatible with both RTL and LTR directions " farhad0 4-7 Days Ago 59514 Add more context to split_the_query filter Query 3.4 normal normal 6.6 enhancement new has-patch 2023-10-02T11:41:06Z 2024-03-13T15:45:24Z "Current the split_the_query filter has the current WP_Query instance as context. However to calculate the value you need the value variables. - $old_request - $limits - $fields - $q ( query arguments ). It is worth noting that `$this->request` can be received by `WP_Query` instance and `$wpdb->posts` can be received from global $wpdb. With this extra context, will be make the filter much more useful. " spacedmonkey 4-7 Days Ago 55996 the get_the_block_template_html call all the same functions as the the_conent filter so they are run twice flixos90 Formatting normal normal Future Release defect (bug) assigned dev-feedback 2022-06-16T22:23:50Z 2024-03-13T15:42:08Z "In get_the_block_template_html we have this code {{{#!php run_shortcode( $_wp_current_template_content ); $content = $wp_embed->autoembed( $content ); $content = do_blocks( $content ); $content = wptexturize( $content ); $content = convert_smilies( $content ); $content = shortcode_unautop( $content ); $content = wp_filter_content_tags( $content ); $content = do_shortcode( $content ); $content = str_replace( ']]>', ']]>', $content ); }}} These are direct calls to the same functions as used by the filter the_content {{{#!php Editor** 2. Now, open a style 3. Click on **Browse Style** 4. Select **Maelstrom** style 5. Now, observe the shaking effect as shown in the screenshot. === Expected Results 1. If we select any other styles they don't behave strangely whereas here it seems like a bug. But not sure if such an effect is given purposely. === Actual Results 1. ❌ It should not shake like other styles. === Supplemental Artifacts Add as Attachments " krupajnanda Last Week 60082 """Copied"" tooltip should be hidden when another attachment URL is copied (in list mode)" Media 6.0 normal normal Awaiting Review defect (bug) new 2023-12-15T13:05:00Z 2024-03-12T15:39:27Z "In the media list view, clicking the ""Copy URL"" action link displays previously clicked ""Copy URL"". The previously clicked row showing ""Copied!"" when hover the media again. === Environment - WordPress: 6.4.2 - PHP: 8.2.0 - Server: Apache/2.4.54 (Unix) OpenSSL/1.0.2u PHP/8.2.0 mod_wsgi/3.5 Python/2.7.18 mod_fastcgi/mod_fastcgi-SNAP-0910052141 mod_perl/2.0.11 Perl/v5.30.1 - Database: mysqli (Server: 5.7.39 / Client: 8.2.0) - Browser: Firefox 119.0 (macOS) - Theme: Twenty Twenty-Four 1.0 - MU-Plugins: None activated - Plugins: * WordPress Beta Tester 3.5.5 === Steps to Reproduce 1. Go to media library 2. Click ""Copy URL"" of one of the media. 3. Click ""Copy URL"" of another media. 4. The previously clicked row showing ""Copied!"" when hover the media again. === Expected Results 1. The previously ""Copied!"" tooltip should be close after clicking the next one. === Actual Results 1. The previously clicked row showing ""Copied!"" when hover the media again." jayadevankbh Last Week 60062 Add required attribute to username and password field in wp_login_form function. rcreators Login and Registration 3.0 normal normal 6.6 defect (bug) assigned 2023-12-13T16:56:11Z 2024-03-12T15:39:03Z "Add required attribute to username and password field in wp_login_form function. " alesflex Last Week 60045 Change to add_new label displays wrong label for old post types joedolson* Administration 6.4 normal normal Future Release defect (bug) accepted 2023-12-11T02:32:49Z 2024-03-12T15:27:00Z "In #47125, the label for adding a new item in the menu changed its default value from Add New to Add New Post, with developers advised to change their code to match when creating custom content types. To me this was a mistake; an appropriate label already existed with that wording: the add_new_item label. If it was desired to change what displayed in the menu, the right fixing was to use display add_new_item, rather than changing the entire meaning of add_new. I have always registered custom post types by setting add_new_item to 'Add New MyPostType', and leaving add_new out of the array entirely, since there was never a need to override the wording of 'Add New'. Now, all of my post types for all clients over many years are displaying 'Add New Post'. Can this change please be reverted, and replaced by displaying add_new_item when you wanted to display the item name, as it was always intended to be used?" smerriman Last Week 60672 Improve menu toggle accessible name in admin menus joedolson Menus normal normal 6.6 defect (bug) assigned has-patch 2024-03-02T03:29:57Z 2024-03-12T15:08:54Z "Follow up from #32728 The Customizer accessible name format is ""Edit menu item: {item title} ({item type})"". The admin accessible name format is ""{item title} Menu item n of n"". It doesn't include the purpose of the control or the type, so the Customizer is providing better information; the admin menu needs to be updated. " joedolson Last Week 60303 About Page for 6.5 Release Help/About normal normal 6.5 task (blessed) new has-patch 2024-01-19T19:17:45Z 2024-03-12T15:00:41Z "This ticket will serve as a hub for the discussion, planning, design, and other related work for creating the WordPress 6.5 About page. Anyone involved in the release is invited to follow this ticket as part of their release-related duties and offer their input. " laurlittle Last Week 60756 Block Hooks: Toggle (re-)inserts hooked block in wrong position (if added by filter) General normal normal Awaiting Review defect (bug) new 2024-03-12T13:59:51Z 2024-03-12T14:48:27Z "As of [https://github.com/WordPress/gutenberg/pull/59396 this change], Block Hook toggles are displayed for hooked blocks that were added by a filter (rather than during block registration), ''if the containing template or template part has had user modifications''. (Displaying the toggle also for ''un''modified templates/parts is the subject of #59574, see especially https://core.trac.wordpress.org/ticket/59574#comment:13.) There is still one more problem with these toggles: If the user disables the toggle to remove the hooked block, and then re-enables it to re-insert the latter, it's not possible for the client to infer ''where'' to insert it. Instead, it simply defaults to (re-)inserting it ''after'' the anchor block. The reason is that once the hooked block is removed, no information about its position relative to its anchor block is available. The only available information is the `ignoredHookedBlocks` metadata attribute on the anchor block, which is an array of hooked block type names (e.g. `[""core/loginout"",""mycommerce/shopping-cart""]`). They do however not include the relative position of these hooked blocks. (This was considered in the original ticket #59646 for enabling Block Hooks in modified templates/parts, but ultimately dismissed.)" Bernhard Reiter Last Week 59574 Blocks: No toggle shown for hooked blocks added via filter General normal normal Awaiting Review defect (bug) new 2023-10-09T16:58:11Z 2024-03-12T13:35:59Z "Per #59313, one core tenet of Block Hooks is to give the user the ultimate say in persisting or removing a hooked block. This is done by showing hooked blocks in the editor, and making them customizable by the user. Additionally, in order to aid visibility, a panel is added to the anchor block's block inspector with a list of blocks hooked to it, and toggles to enable or disable each of them. However, that toggle is currently only shown if the hooked block was added unconditionally (i.e. via the `blockHooks` field in `block.json`, or `registerBlockType()`). Conversely, the toggle is ''not'' shown if the hooked block was added via the `hooked_block_types` filter (#59424)). This is due to the how the toggles are implemented: The editor evaluates the block types endpoint's `blockHooks` field for a given anchor block (which corresponds to the `block.json`/block registration setting), and if it finds a hooked block in the specified location, it will show the toggle as enabled (and as disabled otherwise, unless the block is present elsewhere in the template). By its nature, that endpoint is ""unconditional"", i.e. in cannot provide the information which hooked blocks are present based on what template (or pattern) is being edited. A fix will thus require a different mechanism." Bernhard Reiter Last Week 60582 Let WordPress multisite network setup be aware of Nginx Unit as a hosting environment Networks and Sites trunk normal normal Future Release feature request new needs-docs 2024-02-20T15:04:36Z 2024-03-12T12:45:58Z "Hi there, I work at F5 on the NGINX Unit team. I'd like to get WordPress to recognise when it's running behind a Unit environment, much like Apache, IIS, and Nginx proper, looking at the server header is sufficient for this. I already have a proof of concept locally with the required code changes. With that, I'd also like to help with adding configuration documentation to the handbook, and to help getting an official Unit-based docker container created as well. There are a few prerequisites that we still need to take care of on our (NGINX Unit) side, however here are all the references for work we already have: * PR to the WordPress docker library adding Unit: https://github.com/docker-library/wordpress/pull/875 * work to fix multisite handling within Unit: https://github.com/nginx/unit/issues/916 I'd like to start the conversation about adding a section to the handbook for Unit configurations like how NGINX has its own: https://developer.wordpress.org/advanced-administration/server/web-server/nginx/. I'd like help validating that Unit can handle all instances of multisite and single site functionality in a way that is expected. Let me know how else I can help. You can also find me in the WordPress Slack during normal working hours GMT. Thanks, Gabor" javorszky Last Week 47456 Improve the user interface to ensure correct usage of the image alt text joedolson* Media high normal Future Release defect (bug) accepted 2019-06-01T11:15:23Z 2024-03-12T11:15:33Z "Splitting this out from the [https://github.com/WordPress/gutenberg/issues/created_by/karlgroves WPCampus accessibility report issues on the Gutenberg GitHub], see https://github.com/WordPress/gutenberg/issues/15309 as part of the reported issue applies to the Media Views in core. Related: #41467 == Problem A common misconception is that the image alt text should always be a ""description of the image"". In most of the cases, this is misleading. Actually, the image alt text needs to describe the purpose of the image in its specific context. For more details, see the W3C Alt Text Decision Tree tutorial (https://www.w3.org/WAI/tutorials/images/decision-tree/). WordPress stores a ""default"" alt text in the media object. While storing a default value may help users when they build their content, it also promotes a misunderstanding of the purpose of the alt text. In the accessibility team, we think this is more an user interface problem rather than a data model problem. The user interface should ensure users clearly understand that alt attributes are context sensitive and that the ""default"" alt value needs to be changed (or even removed) based on the specific usage. == Data model problem: The alt text is not constant: it needs to describe the image purpose on a case by case basis. == User interface problem: The alt text from the media library is automatically assigned as the alt text within the post: this is not always correct. Actually, in most of the cases it produces wrong alt text. == Improvements to evaluate Credits: Some of the following points come from @carlseibert and @joedolson comments on #41467, and from the Gutenberg GitHub issue. 1. allow saving multiple alt attributes for a given media object: a default attribute and a set of alternates users can select from 2. have something in the editor UI that would let users know whether the alt text was filled, and what it says 3. modifications on the Media views side to differentiate between the alt text describing the image and the alt text for a specific usage, which might override the normal alt text without changing it 4. all linked images must have alternative text if the image is the sole content of the link, and the action should be blocked if this is not true 5. any guidance given should inform users that the text provided needs to inform the user of the link action 6. include a warning about linking directly to the image file: linking directly to images is inadvisable, because the resulting image view in the browser does not include alternate text 7. when the image is linked to the image file itself, the alt text can remain the normal alternative text for that image, with an appended indicator that the link is to view the image 8. worth considering plugins that add ""lightbox"" modals, sliders and the like often use the alt text value to add contextual text within their UI 9. images used to link to other resources should offer a field to add dedicated link text separate from the image's own description; in this case the alt text should be empty. Example markup (simplified):" afercia Last Week 60375 Site Transfer Protocol Import normal normal Awaiting Review enhancement new 2024-01-30T10:16:53Z 2024-03-12T10:41:23Z "Migrating WordPress sites involves custom, error-prone logic. There are no canonical tools and the guidelines seem lacking. Let's: 1. Formalize a list of steps involved in transferring a WordPress site between hosts 2. Build a canonical plugin that implements those steps and enables easy site migrations 3. Merge it into WordPress core once its stable This is relevant for: * Site migrations * Creating and restoring site backups * Staging and development environments * WordPress Playground imports and exports * Moving live sites into Playground and vice versa ... probably a lot more. == ZIP bundle as the export format The [https://github.com/WordPress/data-liberation/discussions/53 Data Liberation proposal] makes a great argument for a "".zip"" bundle as the export format. I would love to leverage it here. A wordpress.zip file with all the site files and the data in an .sqlite (or plaintext .sql) format sounds like the most natural and convenient way of moving WordPress sites around. Large sites may seem problematic at the first glance, as 300GB zip archives are difficult to manage. However, the ZIP format was built with streaming, compression, chunking, checksums, and seeking in mind. It is a good fit for handling imports that are many GBs large even on a host with 64 MB of ram allocated and not enough hard drive space to hold the import file itself. To support that last point – I’ve built a [https://github.com/WordPress/wordpress-playground/pull/880 streaming zip encoder and decoder in JavaScript] for Playground. It can cherry-pick a single file from https://downloads.wordpress.org/plugin/gutenberg.17.5.2.zip by transferring only a few kilobytes and without downloading the entire 10+MB archive. It works with zip files, and it would work with a Synchronization API endpoint where the zipped fragments are generated on demand. === Differences with WXR Unlike WXR imports this is looking to transfer a site in its entirely with the Transfer Protocol. The export bundle should include every database table, every installed plugin, every asset and file in the wp-content directory. It must also include meta information such as the domain from which the site is being exported and all custom wp-config.php settings. This will be necessary in order to automate the transfer. == Tasks involved in site transfer * Set IMPORTING constant so things shut down: * Stop sending emails * Database replication * Cleanup jobs/CRON jobs that might filter on post creation * Communicate source and destination site domains/base URLs * Rewrite URLs in the database to match new site URL * Rewrite URLs in all files including wp-config.php, wp-content, sunrise.php, mu-plugins, etc. * Communicate wp-config.php settings, including things like WP_SITEURL and plugins directory, theme directory, content directory, memory limits, and other settings. * Let the target site set the database credentials. * Copy all content from source to destination site, including users, site options, database * tables. * Bonus if there's no post-processing via tools like `wp search-replace`. The transferred data would rewritten as the transfer happens (e.g. to adjust the site URL). * Bonus if we can cryptographically secure the conduit through which the transfer takes place to prevent someone intercepting a transfer (e.g. create a private/public keypair, only allow a single transfer at a time, use that certificate to authenticate the transfer. * Bonus to track transfer state, communicate progress on it, and allow for pausing and resuming a transfer. * Bonus if we can start a database transaction log via $wpdb or similar system when starting a transfer so that the source site can continue to serve requests and ensure that the destination site gets a full concurrent update to its data. == Challenges * This assumes a blank slate on the target site otherwise we risk overwriting ids or mismatching ids. * The right design could become a foundation for live synchronization between WordPress sites. == Related efforts * https://github.com/WordPress/playground-tools/pull/124 * https://github.com/WordPress/data-liberation/discussions/53 * https://github.com/WordPress/wordpress-playground/pull/880 Co-authored with @dmsnell cc @dufresnesteven @berislavgrgicak @tellyworth @dd32 @barry @payton @peterwilsoncc @swissspidy @miyarakira @matt @youknowriad @mamaduka @aristath" zieladam Last Week 56595 Add a Site Health check for a non-virtual robots.txt file Site Health normal normal Awaiting Review enhancement new dev-feedback 2022-09-17T13:24:52Z 2024-03-12T10:11:37Z "At WordCamp Nederland 2022 @joostdevalk held a talk about unnecessary bot traffic and how to prevent it. One slide caught my interest: https://docs.google.com/presentation/d/13Ngq-T2Qdbz1b8apUiioTCBmcsB5s411xBKcklmKyNQ/edit#slide=id.g152f65bfa26_0_87 Blocking those unneeded bots is easy in theory (there is a filter available to change the virtual robots.txt file), but is not easy to build, because we need to look at many use cases and edge cases. For high traffic sites, it would be better to have a non-virtual robots.txt file, to prevent PHP/WordPress handling this. But if we create a robots.txt file it is easily missed that now WordPress is not handling it anymore. Therefore I suggest adding a check to Site Health if there is non-virtual robots.txt file in the root directory. Maybe we could also add the content of this file in the info area and/or in the tools section of the plugin. Happy to work on a patch if this idea gets confirmation." zodiac1978 Last Week 59816 Bump default theme versions for WordPress 6.5 Bundled Theme normal normal 6.5 task (blessed) new has-patch 2023-11-06T14:33:24Z 2024-03-12T05:39:55Z "All bundled themes from 2010 to 2024 will need a version bump for the 6.5 release. Previously: #58832 - 6.4 #57857 - 6.3 #57689 - 6.2 #56450 - 6.1 #55754 - 6.0 #54783 - 5.9 #53277 - 5.8 #52704 - 5.7 #51919 - 5.6 #50889 - 5.5 #49743 - 5.4" mukesh27 Last Week 29807 add support for picture element and srcset attribute on img in wp_kses Formatting normal normal Future Release defect (bug) new has-patch 2014-09-30T12:39:10Z 2024-03-11T21:03:26Z "Related to #28993 - ( srcset attribute is stripped when switching from text to visual tab in the editor) If support for srcset attribute and picture element (and source element) is to be added to tinyMCE, they should also be allowed in wp_kses. " mattheu Last Week 60750 Warning: these pages should not be the same as your Privacy Policy page! General 6.4.3 normal normal Awaiting Review defect (bug) new 2024-03-11T20:20:54Z 2024-03-11T20:20:54Z On Settings > Reading this message appears. The Privacy Page is NOT SELECTED. The homepage is another page and that is what is selected. There is nothing else in there. OctoTooT Last Week 60699 Docblock improvements for 6.6 General normal normal 6.6 task (blessed) new 2024-03-06T04:57:35Z 2024-03-11T14:06:52Z "Previously: - #59651 (6.5) - #58833 (6.4) - #57840 (6.3) - #56792 (6.2) - #55646 (6.1) - #54729 (6.0) - #53399 (5.9) - #52628 (5.8) - #51800 (5.7) - #50768 (5.6) - #49572 (5.5) - #48303 (5.4) - #47110 (5.3) - #46543 (5.2) - #42505 (5.1) - #41017 (4.9) - #39130 (4.8) - #37770 (4.7) - #32246 (4.6)" SergeyBiryukov Last Week 60748 auth_redirect() login check doesn't exist or doesn't work Login and Registration normal normal Awaiting Review defect (bug) new 2024-03-11T13:11:38Z 2024-03-11T13:33:04Z "The `auth_redirect()` documentation states: ""Checks if a user is logged in, if not it redirects them to the login page."" [https://developer.wordpress.org/reference/functions/auth_redirect/] However, unless a call to `auth_redirect()` is wrapped inside a `is_user_logged_in()` check, then it always sends people to the login page (even if a user is already logged in). I don't know if the documentation is incorrect or if there is a bug in the code. To reproduce, all you need to do is something like this: {{{#!php = 8.x. Steps to reproduce it: Add the following dummy plugin and enable it to a test WP {{{ alex@wayra time % cat time.php 'GET', 'callback' => 'my_awesome_func', ) ); } ); { ""plugins"": [ ""."" ] } alex@wayra time % cat .wp-env.json { ""plugins"": [ ""."" ] } alex@wayra time % wp-env start WordPress development site started at http://localhost:8888/ WordPress test site started at http://localhost:8889/ MySQL is listening on port 32768 MySQL for automated testing is listening on port 32769 ✔ Done! (in 77s 181ms) alex@wayra time % curl 'http://localhost:8888/?rest_route=/myplugin/v1/datetime' ""2024-02-22T09:38:36+00:00""% alex@wayra time % curl 'http://localhost:8888/?rest_route=/myplugin/v1/datetime&_fields=foo' Fatal error: Uncaught TypeError: array_intersect_key(): Argument #1 ($array) must be of type array, string given in /var/www/html/wp-includes/rest-api.php:869 Stack trace: #0 /var/www/html/wp-includes/rest-api.php(869): array_intersect_key('2024-02-22T09:3...', Array) #1 /var/www/html/wp-includes/rest-api.php(928): _rest_array_intersect_key_recursive('2024-02-22T09:3...', Array) #2 /var/www/html/wp-includes/class-wp-hook.php(324): rest_filter_response_fields(Object(WP_REST_Response), Object(WP_REST_Server), Object(WP_REST_Request)) #3 /var/www/html/wp-includes/plugin.php(205): WP_Hook->apply_filters(Object(WP_REST_Response), Array) #4 /var/www/html/wp-includes/rest-api/class-wp-rest-server.php(454): apply_filters('rest_post_dispa...', Object(WP_REST_Response), Object(WP_REST_Server), Object(WP_REST_Request)) #5 /var/www/html/wp-includes/rest-api.php(424): WP_REST_Server->serve_request('/myplugin/v1/da...') #6 /var/www/html/wp-includes/class-wp-hook.php(324): rest_api_loaded(Object(WP)) #7 /var/www/html/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters('', Array) #8 /var/www/html/wp-includes/plugin.php(565): WP_Hook->do_action(Array) #9 /var/www/html/wp-includes/class-wp.php(418): do_action_ref_array('parse_request', Array) #10 /var/www/html/wp-includes/class-wp.php(813): WP->parse_request('') #11 /var/www/html/wp-includes/functions.php(1336): WP->main('') #12 /var/www/html/wp-blog-header.php(16): wp() #13 /var/www/html/index.php(17): require('/var/www/html/w...') #14 {main} thrown in /var/www/html/wp-includes/rest-api.php on line 869 }}}" xknown Last Week 60745 WP_Query::parse_query() does not handle invalid query arg values Query normal normal Awaiting Review defect (bug) new has-patch 2024-03-11T11:29:09Z 2024-03-11T11:31:45Z "The code in `WP_Query::parse_query` assumes that most query arguments have the correct type. However, this doesn't seem to be the case for the following arguments: Things that expect arrays, but the code that call them pass (unintended) invalid data types {{{ 'author__in' => 'string', 'author__not_in' => 'string', 'category__and' => 'string', 'category__in' => 'string', 'category__not_in' => 'string', 'post__in' => 'string', 'post__not_in' => 'string', 'post_name__in' => 'string', 'post_parent__in' => 'string', 'post_parent__not_in' => 'string', 'tag__and' => 'string', 'tag__in' => 'string', 'tag__not_in' => 'string', 'tag_slug__and' => 'string', 'tag_slug__in' => 'string', }}} Using most of the above query args in a `WP_Query::get_posts()` call result in a PHP fatal. Things that expect scalars: {{{ 'attachment' => array(), 'author_name' => array(), 'feed' => array(), }}} Using any of the above query args result in a PHP fatal on a default WP installation: {{{ alex@wayra core % cat .wp-env.json { ""core"": null } }}} http://localhost:8888/?attachment[]=admin {{{ Fatal error: Uncaught TypeError: urlencode(): Argument #1 ($string) must be of type string, array given in /var/www/html/wp-includes/formatting.php:5683 Stack trace: #0 /var/www/html/wp-includes/formatting.php(5683): urlencode(Array) #1 /var/www/html/wp-includes/class-wp-query.php(2183): wp_basename(Array) #2 /var/www/html/wp-includes/class-wp-query.php(3824): WP_Query->get_posts() #3 /var/www/html/wp-includes/class-wp.php(696): WP_Query->query(Array) #4 /var/www/html/wp-includes/class-wp.php(816): WP->query_posts() #5 /var/www/html/wp-includes/functions.php(1336): WP->main('') #6 /var/www/html/wp-blog-header.php(16): wp() #7 /var/www/html/index.php(17): require('/var/www/html/w...') #8 {main} thrown in /var/www/html/wp-includes/formatting.php on line 5683 }}} http://localhost:8888/?author_name[]=admin {{{ Fatal error: Uncaught TypeError: str_contains(): Argument #1 ($haystack) must be of type string, array given in /var/www/html/wp-includes/class-wp-query.php:2358 Stack trace: #0 /var/www/html/wp-includes/class-wp-query.php(2358): str_contains(Array, '/') #1 /var/www/html/wp-includes/class-wp-query.php(3824): WP_Query->get_posts() #2 /var/www/html/wp-includes/class-wp.php(696): WP_Query->query(Array) #3 /var/www/html/wp-includes/class-wp.php(816): WP->query_posts() #4 /var/www/html/wp-includes/functions.php(1336): WP->main('') #5 /var/www/html/wp-blog-header.php(16): wp() #6 /var/www/html/index.php(17): require('/var/www/html/w...') #7 {main} thrown in /var/www/html/wp-includes/class-wp-query.php on line 2358 }}} http://localhost:8888/?feed[]=admin {{{ Fatal error: Uncaught TypeError: str_contains(): Argument #1 ($haystack) must be of type string, array given in /var/www/html/wp-includes/class-wp-query.php:1018 Stack trace: #0 /var/www/html/wp-includes/class-wp-query.php(1018): str_contains(Array, 'comments-') #1 /var/www/html/wp-includes/class-wp-query.php(1868): WP_Query->parse_query() #2 /var/www/html/wp-includes/class-wp-query.php(3824): WP_Query->get_posts() #3 /var/www/html/wp-includes/class-wp.php(696): WP_Query->query(Array) #4 /var/www/html/wp-includes/class-wp.php(816): WP->query_posts() #5 /var/www/html/wp-includes/functions.php(1336): WP->main('') #6 /var/www/html/wp-blog-header.php(16): wp() #7 /var/www/html/index.php(17): require('/var/www/html/w...') #8 {main} thrown in /var/www/html/wp-includes/class-wp-query.php on line 1018 }}}" xknown Last Week 60663 Plugin Cards: Links with `.button-disabled` are still clickable costdev Plugins normal normal 6.6 defect (bug) assigned has-patch 2024-03-01T03:04:20Z 2024-03-11T11:03:57Z "Props to @swissspidy for noticing this while testing Plugin Dependencies. Currently, links with a `href` attribute and the `.button-disabled` class are still clickable. We should prevent the default `click` handling for elements with the `.button-disabled` class. While this appears to have been the case in earlier WordPress versions, it may be more apparent in the increased AJAX-ified experience added by the Plugin Dependencies feature. **Milestoning for 6.5 for awareness, though I welcome thoughts on whether this is something that needs to be handled in 6.5, or should wait until 6.6.** == Testing Instructions These steps define how to reproduce the issue, and indicate the expected behavior. === Steps to Reproduce 1. Navigate to `Plugins > Add New Plugin`. 2. Click ""Install Now"". 3. Once installed, click ""Activate"". 4. 🐞 Once activated, click on the disabled ""Active"" button. === Expected Results When testing a patch to validate it works as expected: - ✅ The link does not work. When reproducing a bug: - ❌ The link still works despite the `.button-disabled` class being present." costdev Last Week 58874 Code Modernization: Consider using the null coalescing operator. costdev* General normal normal Future Release enhancement accepted dev-feedback 2023-07-22T05:41:48Z 2024-03-11T06:27:11Z "== Overview There are currently around 500 instances of `isset( $var ) ? $var : 'default'` in Core. In [https://make.wordpress.org/core/2020/03/20/updating-the-coding-standards-for-modern-php/ Updating the Coding Standards for modern PHP], the proposal states: > The spaceship `<=>`, null coalesce `??` and null coalesce equals `??=` operators can not be used in WordPress Core until the minimum PHP version has been raised to PHP 7.0 (spaceship and null coalesce) or PHP 7.4 (null coalesce equals). With [https://make.wordpress.org/core/2023/07/05/dropping-support-for-php-5/ the dropping of PHP 5 support in WordPress 6.3], we can now make use of the [https://www.php.net/manual/en/migration70.new-features.php#migration70.new-features.null-coalesce-op null coalescing operator]. > The null coalescing operator (`??`) has been added as syntactic sugar for the common case of needing to use a ternary in conjunction with `isset()`. It returns its first operand if it exists and is not `null`; otherwise it returns its second operand. > [https://www.php.net/manual/en/migration70.new-features.php#migration70.new-features.null-coalesce-op PHP.net] This allows changes from: {{{#!php prop ) ? $obj->prop : 'default'; }}} to: {{{#!php prop ?? 'default'; }}} == Proposal This ticket proposes that we update these as the above instances often result in very long lines or very cumbersome conditions. This follows on from similar changes to use `str_starts_with()`, `str_ends_with()` and `str_contains()`, helps usher in the bump to a PHP 7 minimum for WordPress in a safe way compared to other PHP 7+ features, and promotes increased contribution as prospective contributors see WordPress not just enforcing a minimum PHP version or using new features in ''new'' code, but modernising its ''existing'' codebase. As we're very early in 6.4-alpha, making this change now is as ""perfect"" as we could hope to be considering this will invalidate ''some'' patches. However, given the verbosity of `isset()` ternaries, these usually occur on their own line with very little extra code, so the number of invalidated patches should be ''relatively'' low. == Considerations 1. Backporting: This may add extra work if backports involve changing lines containing the affected `isset()` ternaries. This applies to security backports as well as WordPress 6.3 minor releases. However, our earlier changes to `str_starts_with()`, `str_ends_with()` and `str_contains()` had a greater risk of creating extra work. 2. Invalidated patches: Patches that change lines containing the affected `isset()` ternaries will need a refresh. This ''is'' a negative, but it's also likely to be relatively straightforward to resolve for each patch. Our earlier changes to `str_starts_with()`, `str_ends_with()` and `str_contains()` risked invalidating many more patches compared to this proposal. 3. Readability: While objectively this is a benefit for brevity, readability is subjective. 4. [https://make.wordpress.org/core/handbook/contribute/code-refactoring/ Code refactoring should not be done just because we can]: This page details several things needed for proposals such as this: - **Unit tests**, even if the code was not previously covered. We can’t afford regressions, and this will improve our test coverage. - The behaviour of the null coalescing operator is the same as `isset( $var ) ? $var : 'default'`. This proposal does not suggest changing any other instances at this time. - **Performance benchmarks**, before and after. We can’t afford regressions. - The behaviour and performance of the null coalescing operator is the same as `isset( $var ) ? $var : 'default'`. This proposal does not suggest changing any other instances at this time. - **Proper justification and clear rationale of changes are both necessary**. Too often it is impossible to determine the purpose, objective, or focus of these patches. Code should not be rewritten under the cloaks of readability, narrow personal opinion, or general subjectiveness. - Much like the changes to `str_starts_with()`, `str_ends_with()` and `str_contains()`, this provides brevity in the codebase, and per-instance has a much greater reduction in code. - It reduces our time reading and writing code - I appreciate there will be an adjustment period for some. - It provides a clear signal to prospective contributors and to extenders that WordPress is moving forward, encouraging participation and observation for future changes." costdev Last Week 58719 Bump the minimum PHP version to 7.2 johnbillion* General normal normal 6.6 enhancement accepted has-patch 2023-07-05T17:59:52Z 2024-03-11T04:40:57Z "Background: #51043, #57345 Per discussion in #51043 (and reaffirmed in #57345, specifically https://core.trac.wordpress.org/ticket/57345#comment:29 and https://core.trac.wordpress.org/ticket/57345#comment:83 ), for WordPress to consider dropping support for a PHP version, the versions need to get below 5% usage, regardless of the WordPress version used on those sites. As of 5 July 2023, [PHP usage for all WordPress sites](https://wordpress.org/about/stats/) - PHP 5.6 is at 3.93% - PHP 7.0 is at 2.05% - PHP 7.1 is at 1.38% #57345 is slated to drop support for 5.6, which means barring the unlikely event that migrating users choose PHP 7.0 or 7.1 instead of a later version, the collective usage of PHP 7.0+7.1 is <%5 and eligible to be dropped. That said (and as evidenced in the referenced tickets), dropping support for a PHP version is an orchestrated event that requires leadership approval, coordination with web hosts, and an announcement post that gives users ample time to prepare. In an effort to prevent some of the planning hiccups around previous version drops, and hopefully continuing to standardize the process, I propose we already begin planning the eventual removal of the next slated PHP version. Specifically, * We should choose a ""go/no-go"" date for when we should evaluate the stats and determine which versions (collectively) meet the <%5 threshold (my assumption is that we will want to pad #57345 to see where the migrations land). * We should determine the minimum ideal time before dropping support for an announcement post (several in #57345 suggested 2-3 months advanced notice) Previously: #57345 Bumping the minimum PHP version to 7.0 in WordPress 6.3 (targeted) #46594 Bumping the minimum PHP version to 5.6 in WordPress 5.2 #16917 Bumping the minimum PHP version to 5.2 in WordPress 3.2 " justlevine Last Week 59742 Media library should display the number of pages/posts/urls a particular media file is being used in. Media normal normal Awaiting Review defect (bug) new 2023-10-26T08:19:37Z 2024-03-10T12:50:48Z "For managing media files, WordPress requires you to navigate from the Media Library. However, selecting a file doesn't offer any information on the published pages/posts that are actively using the file. This information is necessary to effectively manage storage and replacing media without losing essential files or causing dependency issues. Selecting a file from the media library should ideally, at minimum show the number of published pages/posts it's in use. Best case would be to make the number a clickable item, that shows a list of all URLs using the file." rsiddiqe Last Week 60735 Problem: Updating failed. The response is not a valid JSON response General 6.4.3 normal normal Awaiting Review defect (bug) new reporter-feedback 2024-03-09T02:50:17Z 2024-03-09T12:20:40Z "I encountered an error message when publishing or updating. Due to a mistake in a wrong sentence, the error message appears. You will get the error message ""Updating failed. The response is not a valid JSON response"". Why did it happen? - WordPress 6.4.3 running theme GeneratePress. - .htaccess file according to wp settings - Permalinks postname settings - Already started with HTTPS - REST API no 404 error message" r3ndy Last Week 60734 Deregistering Open Sans Script Loader 6.4.3 normal normal Awaiting Review enhancement new 2024-03-09T02:15:43Z 2024-03-09T10:31:21Z "I have wasted an entire day trying to figure out why my Open Sans styles were not applying. This is counterproductive/suboptimal. As it turns out, Open Sans was packed in WP back in 2014, which is fine by me. More info: #28478 However it is **not** immediately **obvious** one needs to `wp_deregister_style('open-sans');` before he can register his own style. Please, consider making an exception and make `wp_register_style()` automatically `wp_deregister_style(X)` if X equals 'open-sans'. Otherwise consider other courses of action that may prevent others from incurring in the same problem I did. Thanks. " ecv80 Last Week 60733 GitHub Actions updates and improvements for 6.6 Build/Test Tools normal normal 6.6 task (blessed) new 2024-03-09T01:05:07Z 2024-03-09T01:07:53Z " This ticket is for various updates and improvements for Core's GitHub Actions workflows. Previously: - 6.5 (#59805) - 6.4 (#58867) - 6.3 (#57865) - 6.2 (#57572) " desrosj Last Week 56258 Add IPv6 availability check in Site Health Site Health normal normal Awaiting Review feature request new 2022-07-20T14:23:37Z 2024-03-08T09:34:05Z As IP4 should be replaced by IPv6, WordPress sites should also be available via IPv6. It would help if a check could be added to the Site Health section to check if the site can be reached over IPv6. If not, an instruction could be given to contact the webhost. josklever Last Week 60369 Shortcut for Select Button in Media Library antpb Media normal normal 6.6 enhancement assigned 2024-01-29T11:58:30Z 2024-03-07T19:34:39Z "Hi there, there should be a shortcut to confirm the selected image in Media Library? It is possible to choose an image with Return Shortcut but there is no combination (and documentation) to just confirm the selection with keypad and insert it to the page … Dealing with lots of images is currently really cucumbersome, as one has to click the button manually each time again and again. [https://pasteboard.co/sX5B35Ns3tM7.jpg]" hirschferkel Last Week 60726 The WordPress core password reset needs to pre-populate the username to meet WCAG 2.2 joedolson* Login and Registration normal normal 6.6 defect (bug) accepted 2024-03-07T17:09:25Z 2024-03-07T19:33:35Z "According to new WCAG 2.2 success criterion for [https://www.w3.org/TR/WCAG22/#dfn-processes 3.3.7 redundant entry]. The criterion establishes that information previously entered by or provided to the user that is required to be entered again the same process is either: * auto-populated, or * available for the user to select There are 3 exceptions: * re-entering the information is essential, * the information is required to ensure the security of the content, or * previously entered information is no longer valid. Once the user has performed the process of requesting a new password, the redirected form should have the username filled-in to pass. As of now, this is the form that the user is redirected to: " estelaris Last Week 60727 Allow fine-grained control of when to use oEmbed for providers outside the explicit list Embeds normal normal Awaiting Review enhancement new 2024-03-07T18:30:45Z 2024-03-07T18:30:45Z "WordPress maintains a list of appvoed oEmbed providers. Developers are able to add or remove providers from this list. WordPress also attempts to see if URLs, outside the provider list, support oEmbed - and if they do, it uses oEmbed for them. Unfortunately, this is currently an ""all or nothing"" appraoch. You can either agree to use all these random sites oEmbed, or none. I'd love to see a filter added to control whether or not a specific URL, outside the provider list, should use oEmbed. For reference, our specific use case is we want to continue supporting oEmbed for the vast majority of sites that support it - but we've identified some specific domains that do a poor job of oEmbed, and we'd like to only turn it off for those domains." MadtownLems Last Week 60229 HTML API: Introduce HTML Templating HTML API trunk normal normal enhancement new dev-feedback 2024-01-11T03:41:51Z 2024-03-07T17:03:47Z "WordPress relies on developers remembering to perform proper escaping when building HTML strings. There's no mechanism to ensure that output HTML is safe. This patch introduces `WP_HTML_Template::render( $template, $args )` to do just that. {{{#!php ""> ""> HTML, array( 'url' => 'https://s.wp.com/i/atat.png?w=640&h=480&alt=""atat>atst""' ), ); }}} outputs {{{ https://s.wp.com/i/atat.png?w=640&h=480&alt="atat>atst" }}} This proposed templating syntax uses closing tags containing invalid tag names, so-called ""funky comments,"" as placeholders, because they are converted to HTML comments in the DOM and because there is near universal existing support for them in all browsers, and because the syntax cannot be nested. The `%` at the front indicates that the value for the placeholder should come from the args array with a key named according to what follows the `%`. This proposal does not yet consider nested HTML, or ""raw"" HTML. It currently escapes all content. It would be great if the templating engine can properly and safely handle HTML passed into it without risking unintentional exposure, but there must also be some way to communicate that a value inside is already escaped //and that its safety is maintained//. By relying on the HTML API, this templating only supports replacement of values //inside// HTML attributes or in plaintext (`#text`) nodes. It's not possible to inject HTML tags (unless nested support can be safely added), comments, or other HTML syntax." dmsnell Last Week 60693 """Previously approved comment"" for logged out users bug" Comments 6.4.3 normal normal Awaiting Review defect (bug) new dev-feedback 2024-03-05T14:30:41Z 2024-03-07T17:00:03Z "When ""Comment author must have a previously approved comment"" is checked in the discussion settings, comments made by registered users who are logged out, go to moderation every time. The check comment function looks for previous comments under their user id but if they have only commented while logged out, no id is recorded. This bug has caused our users and our team major frustration. Can someone please address? Thanks!" jmorti Last Week 45197 Introduce `user_can_for_blog()` johnbillion Role/Capability normal normal 6.6 enhancement reviewing needs-unit-tests 2018-10-26T11:05:51Z 2024-03-07T16:46:56Z "The available user capability checking functions include: * `current_user_can()` * `user_can()` * `current_user_can_for_blog()` What's missing is `user_can_for_blog()` so that both a user ID and a site ID can be passed in order to check a given user's capabilities on a given site." johnbillion Last Week 54304 Expose menu data public in Menus REST API REST API 4.7 normal normal Future Release defect (bug) new has-patch 2021-10-21T19:45:22Z 2024-03-07T12:20:38Z "Menus endpoints will be added in #40878. However by default this data requires the user to be logged in with the correct capability to access this data. There should be a way to allow developers or users to expose menu / menu item / menu location publically in REST API. " spacedmonkey Last Week 60647 Script Modules: Allow modules to depend on existing WordPress scripts jonsurrell Script Loader trunk normal normal 6.6 feature request assigned 2024-02-27T15:40:59Z 2024-03-07T11:09:26Z "Script modules cannot depend on existing scripts such as `wp-url`, `wp-i18n`, or `wp-api-fetch`. Script modules should be able to leverage the functionality available in existing scripts." jonsurrell Last Week 57349 Page cache is not detected but the server response time is OK Site Health 6.0.1 normal normal Awaiting Review enhancement new reporter-feedback 2022-12-18T10:59:38Z 2024-03-07T10:19:01Z "New site health feature that reports on page cache says ""Page cache is not detected but the server response time is OK"" Later expresses that""Page cache is detected by looking for an active page cache plugin as well as making three requests to the homepage and looking for one or more of the following HTTP client caching response headers: cache-control, expires, age, last-modified, etag, x-cache-enabled, x-cache-disabled, x-srcache-store-status, x-srcache-fetch-status."" I do happen to have cache control expires age less modified and e-tags. But these are applied by nginx reverse proxy. Wondering why they're not detected.. When it checks the page is it running it by using localhost? Or does it try from the domain name? I think it should be set up to make a request to the actual domain name if it does not say that it would get a more accurate view of the headers." djav1985 Last Week 59486 Make test suite compatible with PHPUnit 10 / 11 Build/Test Tools 6.4 normal normal Future Release enhancement new 2023-09-28T08:58:42Z 2024-03-07T09:58:11Z "PHPUnit 10 was released back in February of 2023, and included [https://github.com/sebastianbergmann/phpunit/blob/10.0.0/ChangeLog-10.0.md#1000---2023-02-03 many breaking changes] - they completely rewrote the internal functionality of PHPUnit (mainly the event system for extending the test runner). Besides that, they upped the minimum PHP version to >=8.1, so for WordPress, it could only be used on PHP versions of >=8.1. While this is not a huge and critical update, since the tests are running fine on PHP versions all the way up to version 8.3, it would be a good idea to start preparing for PHPUnit 10 compatibility. Besides being up to date, it will allow external testing library maintainers (such as [https://github.com/lucatume/wp-browser wp-browser] or [https://github.com/dingo-d/wp-pest wp-pest]), to use the latest versions of both PHPUnit, or dependencies that are using PHPUnit 10 (such as PestPHP v2 which depends on PHPUnit 10). I understand that this is a huge undertaking, but it's okay to have a ticket open for this (I didn't find one opened while searching, could be wrong tho), so that we can keep track of changes, and maybe create a roadmap or a to-do list of what needs to be fixed in order to make WordPress test suite compatible with PHPUnit 10. " dingo_d Last Week 60718 Awareness of permission after updating cores, themes and plugins Upgrade/Install trunk normal normal Awaiting Review enhancement new 2024-03-07T04:41:04Z 2024-03-07T05:46:41Z "This is the major security concern now a day when people install/update plugins or themes on DEV/STAG/PROD after changing respective directory permission from **755** (7=rwx 5=r-x 5=r-x) to **777** (7=rwx 7=rwx 7=rwx) Once installation/updation is complete, people forget to restore directory permission, and due to this, hackers might inject scripts into those directories. To prevent this, we have to check directories and file permissions for it and give the notice on top of the admin section. It will help to reduce security threats. " Girishpanchal Last Week 30686 Twenty Fourteen/Thirteen/Twelve Navbar submenu behaviour Bundled Theme 4.0.1 normal normal Awaiting Review defect (bug) assigned 2014-12-12T08:11:58Z 2024-03-07T05:22:09Z "As you all may know, both 2014/13/12 themes require you to hover over a menu item in order to access the submenu item. This isn't a problem for desktops but for touchscreen devices this may pose a problem. I notice this problem has largely been addressed at least for the 2013 and 2012 themes for Android, iOS and Windows Phone devices (see https://core.trac.wordpress.org/ticket/24767#comment:35). However, on my Windows 8 tablet, it still registers the first tap as a click on both Internet Explorer 11 and Mozilla Firefox (Google Chrome works fine). I believe both browsers somehow do not declare whether the device is a touchscreen. In addition, for the 2014 theme, the (partial) fix isn't even implemented (I don't know how it got implemented for both 2013 and 2012 themes but was overlooked for 2014), therefore you will still find it hard to click on sub-menus if you're using an Android device. As for the 2013 and 2012 themes, I know that the Windows 8 tablet userbase is comparatively small, but I believe it will grow over the years. I'm not sure how this can be fixed in the mean time (since the hover/click behaviour seems to rely on a touchscreen detection), but I would like to suggest the following: - In the Twenty Fifteen theme, this issue seems to be fixed once and for all, as the dropbox arrow next to the menu item is a separate link. Clicking on the arrow itself will maximise/minimise the sub-menu, instead of linking you to the menu item itself. - However, the Twenty Fifteen theme's menu is only available at the side, instead of the top. - Thus, if the improvements made in the Twenty Fifteen theme could be backported to Fourteen, Thirteen and Twelve. It would be great! P.S. I'm not sure what to classify this ticket under, but I guess I will leave it as a 'bug' since the hover and click issues have not been completely addressed, especially on the Twenty Fourteen theme. The same behaviour occurs on WordPress 4.0.1 and 4.1 RC." trenzterra Last Week 30575 Twenty Fourteen: Submenu items on dropdown menus nearly impossible to select on some Android mobile tablets Bundled Theme 4.0.1 normal normal Awaiting Review defect (bug) assigned has-patch 2014-12-02T16:01:22Z 2024-03-07T05:01:38Z "On larger Android tablets, it's next to impossible select a submenu item from the dropdown menu, since it appears too quickly to be tapped. Replicated on [http://wp-themes.com/twentyfourteen/ Twenty Fourteen demo] site using: - Samsung Galaxy note 10.1 2014 edition, running Android 4.4.2, using the ""Browser"" app and Chrome. Tester noted that ""When I use my stylus, I am able to hover over the menus so I can choose the correct one."" - Nexus 7 in landscape mode, Android 4.4.2, Chrome Screencast: https://cloudup.com/imicb2EvVyc This does '''not''' seem to affect the mobile menu, which kicks in at smaller screen sizes, such as the Nexus 7 in portrait mode. It only affects screen sizes at which the regular dropdown menu is displayed. Reported in [http://en.forums.wordpress.com/topic/not-functional-drop-down-menus-on-20-14-theme-and-android-platform this forum thread] " zoonini Last Week 60052 Error when deleting media if default taxonomies have been removed General 6.4.2 normal normal Awaiting Review defect (bug) reopened dev-feedback 2023-12-12T07:44:20Z 2024-03-07T04:39:20Z "Hello, I recently had a problem with deleting media from the media library. I received the following error message: 2151#0: *203114 FastCGI sent in stderr: ""PHP message: UM_TEST_ERROR_LOG PHP message: 63870 PHP message: ""category"" PHP message: UM_TEST_ERROR_LOG PHP message: 63870 PHP message: ""post_tag"" PHP message: PHP Fatal error: Uncaught TypeError: array_map(): Argument #2 ($array) must be of type array, WP_Error given in /var/www/vhosts/fis-gmbh.de/stage.fis-gmbh.de/wp-includes/taxonomy.php:1964 Stack trace: #0 /var/www/vhosts/fis-gmbh.de/stage.fis-gmbh.de/wp-includes/taxonomy.php(1964): array_map() #1 /var/www/vhosts/fis-gmbh.de/stage.fis-gmbh.de/wp-includes/post.php(6304): wp_delete_object_term_relationships() #2 /var/www/vhosts/fis-gmbh.de/stage.fis-gmbh.de/wp-includes/post.php(3416): wp_delete_attachment() #3 /var/www/vhosts/fis-gmbh.de/stage.fis-gmbh.de/wp-admin/includes/ajax-actions.php(886): wp_delete_post() #4 /var/www/vhosts/fis-gmbh.de/stage.fis-gmbh.de/wp-includes/class-wp-hook.php(324): wp_ajax_delete_post() #5 /var/www/vhosts/fis-gmbh.de/stage.fis-gmbh.de/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters() #6 /var/www/vhosts/fis-gmbh.de/stage.fis-gmbh.de/wp-includes/plugin.php(517): WP_Hook->do_action() #7 /var/www/vhosts/fis-gmbh.de/stage.fis-gmbh.de/wp-admin/admin-ajax.php(1"" while reading response header from upstream This happened because we had used the following code elsewhere: add_action( 'init', 'deregister_tag' ); function deregister_tag() { global $wp_taxonomies; $tax = 'post_tag'; if ( taxonomy_exists( $tax ) ) { unset( $wp_taxonomies[ $tax ] ); } } This code ensures that the standard WordPress taxonomy 'post_tag' is no longer present (this was not necessary for this project). In wp-includes/post.php there is the following call: wp_delete_object_term_relationships( $post_id, array( 'category', 'post_tag' ) ); This call causes an error to occur if the taxonomy 'post_tag' is not present. I am of the opinion that this error should be caught in the WordPress core. This issue is also being discussed here at WPML: https://wpml.org/forums/topic/fatal-error-when-deleting-a-media/ Thank you." imatoni Last Week 60528 Font Library: first time install fails if /wp-content/fonts isn't created. Editor trunk normal normal 6.5 defect (bug) new 2024-02-13T16:39:35Z 2024-03-07T03:13:06Z "The first time the user want to install a font via the font library, it fails with this error message: {{{ Some font faces were installed. There were some errors. Fetch error: Unable to create directory wp-content/fonts. Is its parent directory writable by the server? }}} After the first attempt, the font installation process works as expected. This happens because the /wp-content/fonts is not created by the time of the first attempt, after the first one it is created and it works as expected. A fix for this probably consists of creating the folder before trying to write in it." mmaattiiaass Last Week 49869 Apply comment field filters to backend Comments normal normal Awaiting Review defect (bug) reopened has-patch 2020-04-10T16:21:27Z 2024-03-07T01:13:41Z "Recently, I had to work on an internally consuming WP project. I am a bit surprised how WP filters are mainly affecting only visual side, instead of applying to backend functions. so, for example: {{{ add_filter('comment_form_default_fields', 'website_remove'); function website_remove($fields) { if( isset($fields['url']) ) unset($fields['url']); return $fields; } }}} it only removes 'url' input field from output of comment form. So, what is the point of that, if it can be simply achieved by css `display:none`. ? the intention is clear, that it should REMOVE ""url"" parameter from comment system at all. However, at this moment, even if people use 'comment_form_default_fields' filter to remove `url`, it is almost meaningless - anyone in front-end form can just insert `url` field (i mainly say bots, but also typical user can just insert ""url"" parameter in browser ""inspect element"") and submit form and in backend, in `wp-includes/comment.php :: wp_handle_comment_submission` still accepts the `url` field. In parallel of the fact that WP advocates ""never trust user input"", the filters should be applied firstly and mostly to backend functions in my mind. I firmly reckon that the filters (in any other WP form too) should be applied in both front-end and back-end functions for same parameter. So in backend, the same filter should be applied to comment fields ( in `wp-includes/comment.php :: wp_handle_comment_submission`): {{{ $comment_data = apply_filters('comment_form_default_fields', $comment_data, true); }}} the third parameter is indication whether the filter is in BACK-END (true) or FRONT-END (false). So, in front-end output of comments (`wp-includes\comment-template.php`, function `comment_form`) the filter can now be: {{{#!php update()` fails This is a bit worrying but shouldn’t be the case as surely there should be an accompanying database error? I think we can rule out (1) seeing as the `$option` parameter is never empty. We can maybe rule out (2) because from the thread above, this happens on high traffic sites as well as low traffic sites and on sites using the default wp-cron firing as well as cron fired by the system … ? The leaves (3) being the most likely cause of the ""bug"". I have tried to assign to @audrasjb (I hope that's OK to do?) because they added the commit on the 20th September that started to highlight the issue https://github.com/WordPress/WordPress/commit/84d19848666a81584e0007a6ab7f7ad3c990d71a I realise that this is not going to be easy to diagnose until the issue can be manually replicated but I think it should be looked into. Oliver " domainsupport Last Week 60710 save_post_{$post->post_type} hook returns inconsistent $_POST['tax_input'] format Taxonomy 6.4.3 normal normal Awaiting Review defect (bug) new 2024-03-06T19:55:52Z 2024-03-06T19:55:52Z "In the save_post_{$post->post_type} hook: **Case 1**: If we do not make any changes to the taxonomy `$_POST['tax_input'][$term]` returns a comma delimited string WITH a space. Output Example: ''Maple, Spring, Summer, Winter'' **Case 2**: If we modify the taxonomy (adding or removing), it eliminates the space: Output Example: ''Spring,Summer,Winter'' Proposed solution, eliminate the space in the first case for consistency. " jenUnderscore_ Last Week 55603 PHP 8.2: address deprecation of the utf8_encode() and utf8_decode() functions hellofromTonya General 6.0 normal normal 6.6 task (blessed) assigned dev-feedback 2022-04-21T19:24:21Z 2024-03-06T17:40:19Z "== Context The [https://wiki.php.net/rfc/remove_utf8_decode_and_utf8_encode PHP RFC to remove the `utf8_encode()` and `utf8_decode()` functions] from PHP in PHP 9.0 has recently been accepted. This means in effect that as of PHP 8.2, those functions will be deprecated and a deprecation notice will be thrown whenever they are called. The reasoning behind the deprecation and removal is that these functions are confusing and rarely used correctly. See the [https://wiki.php.net/rfc/remove_utf8_decode_and_utf8_encode#usage Usage section] of the RFC for an analysis of the various (mostly incorrect) uses of the functions. == The Problem The [https://wiki.php.net/rfc/remove_utf8_decode_and_utf8_encode#alternatives_to_removed_functionality typical replacements for these functions] are using the [https://www.php.net/manual/en/book.mbstring.php MBString extension] and/or the [https://www.php.net/manual/en/book.iconv.php Iconv extension]. As these extensions are both ''optional'' extensions in PHP, they cannot be relied on to be available in an open source context. WordPress uses the `utf8_encode()` function a few times in the codebase: * 1 x `utf8_encode()` in `src/wp-admin/includes/export.php` * 2 x `utf8_encode()` in `src/wp-admin/includes/image.php` * 1 x `utf8_encode()` in `tests/phpunit/tests/kses/php` Aside from that the external dependency [https://github.com/JamesHeinrich/getID3 GetID3] also uses both these functions a number of times. A search of the plugin and theme directory shows more worrying results with a plenitude of matches: * [https://wpdirectory.net/search/01G16P0SWHB37G2965MP8R4ZYK 11247 matches in 3315 plugins], including 15 plugins with over a million installs. * [https://wpdirectory.net/search/01G16P2K39TQ538M9KRTVXT4CA 40 matches in 22 themes]. == Options So, what are the options we have ? In my opinion, especially seeing how these functions are used so often in plugins, there are only two realistic options: === 1. We could polyfill these functions. While some functions which may not be available are polyfilled by WP, this is generally only done to have access to ''new'' PHP functionality or to allow for using functions which require certain optional extensions to be enabled. As far as I know, no PHP native function has ever been polyfilled due to it being removed from PHP. **Pro**: Relatively simple solution and everything keeps working (deprecation notices will still show when running on PHP 8.x, though these could silenced). **Con**: As most uses of these functions are likely to be incorrect usage (especially in plugins), these ""bugs"" will remain and not be reviewed or addressed, undercutting the improvement PHP is trying to make. === 2. We could make the MbString (or the Iconv) extension a requirement At this moment, [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/class-wp-site-health.php#L876 both the MbString as well as the Iconv extension are recommended, but not required by WP]. A couple of MbString functions are also polyfilled in WP, so now might be a good time to make the MbString extension a requirement for WP. **Pro**: MbString being available will allow for fixing the deprecations in a forward-compatible manner. It will also allow for other code improvements to be made to improve WPs support for languages using non-latin based scripts. **Con**: A new requirement would be added to WP which should not be taken lightly. At the same time, it should be noted that MbString is generally enabled already anyway, so this will impact only a small percentage of users. ==== Why MbString instead of Iconv ? While both are included (though not enabled) by default with PHP, Iconv [https://www.php.net/manual/en/iconv.requirements.php requires the `libiconv` library], which may not be available, while MbString has [https://www.php.net/manual/en/mbstring.requirements.php no external dependencies]. MbString is [https://www.php.net/manual/en/mbstring.installation.php not enabled by default in PHP], but generally ''is'' enabled in practice. [https://www.php.net/manual/en/mbstring.installation.php Iconv is enabled by default] in PHP, but can be disabled. Having said that, MbString offers much more functionality than the limited functionality offered by Iconv and - as indicated by a number of functions being polyfilled - is already in use in WP. Still, it would be helpful if someone with access to the underlying statistics data collected by WP could add figures to this issue showing how often either extension is enabled on systems running WP. == Recommendation I'd strongly recommend option 2, but would like to hear the opinions of additional Core devs. == Action lists === General - [ ] Report the issue to GetID3 === Action list for option 1 - [ ] Polyfill the functions. - [ ] Review the uses of the functions in WP Core anyhow to see if those could/should be removed/the code using them should be refactored. - [ ] Add a note about the polyfills in a dev-note with a recommendation for plugin/theme authors to review their use of these functions anyhow. === Action list for option 2 - [ ] Make the MbString a requirement for installing WP/in the WP bootstrapping. - [ ] Change the MbString extension from optional to required in the Site Health component. - [ ] Remove the current MbString related polyfills from the `compat.php` file. - [ ] Review the uses of the functions in WP Core and replace with more appropriate alternatives. - [ ] Add a note about the deprecation in the PHP 8.2 dev-note with a recommendation for plugin/theme authors to review their use of these functions and noting that the MbString extension can be relied upon to be available (as of WP 6.1). " jrf Last Week 60499 Duplicate CSS in src/wp-includes/css/media-views.css afercia Media normal normal 6.6 enhancement assigned has-patch 2024-02-12T11:33:04Z 2024-03-06T17:00:44Z "There's about 60 lines (including empty lines) of duplicate CSS in `src/wp-includes/css/media-views.css` all related to the 'load more' button shown at the bottom of the media grid. Compare the CSS starting at line 1272: https://github.com/WordPress/wordpress-develop/blob/93ba10dae607581c00eac627e82dff61d3e5dca6/src/wp-includes/css/media-views.css#L1272 with the one starting at line 1317: https://github.com/WordPress/wordpress-develop/blob/93ba10dae607581c00eac627e82dff61d3e5dca6/src/wp-includes/css/media-views.css#L1317 While it doesn't harm anything, it's just redundant code that can be safely removed. Hint: use a tool of your choice to find all the duplicated CSS rulesets. There are a few online tools as well." afercia Last Week 60548 Image editor: improve the browsePopup function joedolson* Media 6.3 normal normal 6.6 defect (bug) accepted 2024-02-15T14:10:11Z 2024-03-06T16:59:58Z "While auditing all the remaining jQuery deprecations still to address in core, I noticed a couple things that offer room for improvements in the `browsePopup` function of the core image editor. 1. The `browsePopup` function uses the `window.event` property, which is deprecated and should not be used. This is the `global` event. Instead, the event should be passed as a function parameter. Aside: instead of using inline events, it could have been better to consider a more modern approach. 2. When using the keyboard to navigate the items in the 'Image rotation' dropdown menu, the page scrolls. See attached animated GIF. There's some code in place to prevent page scrolling you may need to reduce your viewport height. See [55919] / #50523 " afercia Last Week 60250 Feature Req – Media Library Grid-List Media normal normal Awaiting Review feature request new 2024-01-14T16:18:41Z 2024-03-06T16:57:57Z "Hello, i have site with lots of images so i have to check attachment details of images and upload new ones everyday. so in grid view of media library, the attachment details modal is really helpful and i have infinite scroll enabled. i have to check old images after uploading a new into media library but need to scroll a lot and it’s very annoying. on the other side in list view there is a pagination so i can remember page number everyday but there is No attachment modal thats why I have to open attachment page of every image and update info which takes lots of time. I really need pagination in grid view or attachment details modal in list view. kindly add an one feature in media library. it will save lots of time in future. Thank You 🙂 " smtkapps Last Week 60569 Generate UUID for media slugs if attachment pages are inactive. Media normal normal Awaiting Review enhancement new 2024-02-19T02:36:19Z 2024-03-06T16:55:03Z "For hierarchical post types, WordPress compares slugs with those used by attachments to avoid collisions. The effect of this is that a page can not have the same slug as an uploaded image. [https://core.trac.wordpress.org/browser/tags/6.4.3/src/wp-includes/post.php?marks=5100-5101#L5100 Source code.] This remains the case now that attachment pages have been disabled by default. As the attachment pages slugs are now largely meaningless on new WordPress installs, the media slugs should not reserve nice names and prevent pages from using them. For example, a media file with the name `about-us.png` should not prevent the page `about-us` from existing. Steps to reproduce above: 1. Install WordPress 6.4 or later 2. Go to Dashboard > Media > Add new media file 3. Upload the file `about-us.png` 4. Go to Dashboard > Pages > Add new page 5. Title the page `About Us` and publish 6. Observe the page's slug is `about-us-2` If the attachment pages are disabled, the URLs for the media pages (as opposed to the image) can use `wp_generate_uuid4()` for the slug to avoid reserving nice names and preventing their use on available permalinks." peterwilsoncc Last Week 60610 Consider fixing user mistakes and/or adding unit tests for $preferred_ext in wp_mime_type_icon() joedolson* Media trunk normal normal 6.6 enhancement accepted 2024-02-22T19:39:29Z 2024-03-06T16:48:20Z "Follow-up to ticket:31352#comment:54 The `$preferred_ext` value for `wp_mime_type_icon()` begins with a period, and developers might miss that. The function could check the first character and add the dot if it does not exist there. The function also could ensure that the letters are lowercase. For unit tests, the `test_wp_mime_type_icon_video` test in `post/attachments.php` checks the default `$preferred_ext` parameter value. Adding at least one more test with a specific `$preferred_ext` could help." sabernhardt Last Week 60666 Unwanted section appears as a sidebar in 'Create gallery' section joedolson* Media 5.0 normal normal 6.6 defect (bug) accepted 2024-03-01T09:04:35Z 2024-03-06T16:46:30Z "Unwanted section with 'Actions' and 'Create gallery' texts appear in the sidebar of Media Library and nothing happens on selection or click of the texts. To find the issue, please go through the below steps. 1.From the 'File' block add the block 'Gallery', then select Media Library. 2.Unwanted sidebar section with the specified texts appears." ukdrahul Last Week 9257 EXIF GPS data Media 2.7 normal normal Awaiting Review enhancement assigned dev-feedback 2009-03-01T19:30:17Z 2024-03-06T16:33:55Z "Attached patch adds GPS longitude and latitude to image meta data. Changed: wp_read_image_metadata function (file: wp-admin/includes/image.php). It complies with exif standard: [http://www.exif.org/Exif2-2.PDF] (page 46) Commented on wp-hackers list: [http://comox.textdrive.com/pipermail/wp-hackers/2009-March/025093.html]" B-Scan Last Week 58051 Attachment custom fields not rendered after upload antpb Media 6.2 normal normal 6.6 defect (bug) assigned 2023-04-02T02:23:40Z 2024-03-06T16:20:39Z "This is a follow-up to #40909. Attachment custom fields added via `attachment_fields_to_edit` are no longer rendered just after an image is uploaded. Clicking away and back will restore the custom field markup, but is quite inconvenient." trepmal Last Week 57469 retrieve_widgets(): fatal error when a sidebar's widgets set to null (array is expected) Widgets 4.9 normal normal defect (bug) reopened close 2023-01-15T21:02:11Z 2024-03-06T13:09:48Z "When changing from PHP 7.4 to PHP 8.0 it's not possible to activate our theme. {{{ Fatal error: Uncaught Error: array_merge(): Argument #3 must be of type array, null given in wp-includes/widgets.php on line 1342 }}} {{{ array_merge() wp-includes/widgets.php:1342 retrieve_widgets() wp-includes/widgets.php:1287 _wp_sidebars_changed() wp-includes/class-wp-hook.php:310 WP_Hook::apply_filters() wp-includes/class-wp-hook.php:332 WP_Hook::do_action() wp-includes/plugin.php:517 do_action() wp-includes/theme.php:3395 check_theme_switched() wp-includes/class-wp-hook.php:308 WP_Hook::apply_filters() wp-includes/class-wp-hook.php:332 WP_Hook::do_action() wp-includes/plugin.php:517 do_action() wp-settings.php:617 require_once() wp-config.php:103 require_once() wp-load.php:50 require_once() wp-admin/admin.php:34 require_once() wp-admin/plugins.php:10 }}} Line 1342: {{{#!php array ( ), 'sidebar-standard' => array ( ), 'sidebar-marken' => NULL, 'sidebar-typen' => NULL, 'sidebar-test' => NULL, 'sidebar-zubehoer' => NULL, 'sidebar-ratgeber' => NULL, ) }}} PHP 8.0+ throws a type error when a non-array value is given to array_merge. I guess NULL is not a valid value for the sidebar widgets. Maybe our theme wrote this weird state to the options field. Patch: https://github.com/WordPress/wordpress-develop/pull/3848" kesselb Last Week 60398 "WordPress 6.4.3 MacOS/Linux Compressed Zip plugin archives ""Incompatible Archive"" on upload" peterwilsoncc Upload 6.4.3 normal normal 6.4.4 defect (bug) reopened commit 2024-01-31T11:42:20Z 2024-03-06T08:44:43Z "If I zip a plugin folder using MacOS right-click Compress command in the contextual menu, those archives are no longer accepted when using upload plugin. It returns ""Incompatible Archive"". This has worked up until now. Probably related to recent security updates for the plugin and theme uploader. If I create a zip on the command line of the same folder that works correctly." Endymion00 Last Week 60290 Changeset #56635 breaks template loading in multisite network using switch_to_blog() joemcgill Themes 6.4.2 normal normal 6.4.4 defect (bug) reopened has-patch 2024-01-18T19:53:51Z 2024-03-06T08:27:49Z "The changes to the `locate_template()` function in https://core.trac.wordpress.org/changeset/56635 that replaced STYLESHEETPATH and TEMPLATEPATH constants with the relevant functions have broken the `get_template_part()` functionality in a multisite network that uses `switch_to_blog()`. Expected behavior: `get_template_part()` should only look in the active theme of the current site even after `switch_to_blog()` is used. In WP 6.4.2, if `switch_to_blog(1)` is used in site 2, then `get_template_part()` is called, only the active theme of site 1 is searched for the template part. `switch_to_blog()` should only affect database calls and should not allow theme developers to pull template parts from the theme of another site in a network. " metropolis_john Last Week 20140 Ask old password to change user password Security normal normal Future Release feature request reopened dev-feedback 2012-02-29T12:55:38Z 2024-03-06T07:00:58Z "I have experienced this in various sites and i think it adds extra security. We must ask for the old password when the user tries to change the password" nprasath002 Last Week 60705 Test tool and unit test improvements for 6.6 Build/Test Tools normal normal 6.6 task (blessed) new has-patch 2024-03-06T06:53:46Z 2024-03-06T06:58:16Z "Previously: * #59647 (6.5) * #58955 (6.4) * #57841 (6.3) * #56793 (6.2) * #55652 (6.1) * #54725 (6.0) * #53363 (5.9) * #52625 (5.8) * #51802 (5.7) * #51344 (5.6) This ticket is for various fixes and improvements in PHPUnit tests that don't have a more specific ticket, as well as general improvements to the GitHub Actions workflows that run automated testing." SergeyBiryukov Last Week 60706 Tests: Reduce usage of assertEquals for 6.6 Build/Test Tools normal normal 6.6 task (blessed) new has-patch 2024-03-06T06:55:52Z 2024-03-06T06:56:39Z "Follow-up to: * #59655 (6.5) * #58956 (6.4) * #57855 (6.3) * #56800 (6.2) * #55654 (6.1) * #54726 (6.0) * #53364 (5.9) * #52482 (5.8) * #38266 (5.7) The `assertEquals()` test method does not check that the types of the expected and actual values match. This can hide subtle bugs especially when the values are falsey. Tasks: * Switch to using `assertSame()` when the type of the value in the assertion is important * Replace overall usage of `assertEquals()` with type-strict assertion methods, with the aim of potentially removing its usage altogether To help ease the effort of merging tests, changes should also be made upstream in the Gutenberg repository." SergeyBiryukov Last Week 60227 HTML API: Add external test suite Build/Test Tools normal normal 6.6 task (blessed) new has-patch 2024-01-10T15:31:28Z 2024-03-06T06:54:42Z "Problem: The HTML API is a complex and important feature being implemented by a small group of developers. The implementation follows the HTML Standard https://html.spec.whatwg.org/. The tests and the implementation of the HTML API both depend on the interpretation of the standard by the same small group of developers. This means there is a risk of misinterpretation or overlooked edge cases. Needs: A suite of tests that can serve to test the HTML API that does not depend on our own interpretation of the HTML Standard and is implementation agnostic. Benefits: Many software projects such as browsers implement the HTML Standard. We should be able to use a third-party implementation-agnostic test suite to validate our implementation of the HTML API. This mitigates the risk where our implementation and tests all derive from the same interpretation of the specification." jonsurrell Last Week 60648 Update the `$_old_files` array for 6.5 swissspidy* General normal normal 6.5 task (blessed) accepted has-patch 2024-02-27T16:43:31Z 2024-03-06T06:54:12Z "Updating from 6.4 to 6.5 Beta 3 results in the following files being removed: {{{ File removed: wp-includes/ID3/license.commercial.txt File removed: wp-includes/blocks/query/style-rtl.min.css File removed: wp-includes/blocks/query/style.min.css File removed: wp-includes/blocks/query/style-rtl.css File removed: wp-includes/blocks/query/style.css File removed: wp-admin/images/about-header-privacy.svg File removed: wp-admin/images/about-header-about.svg File removed: wp-admin/images/about-header-credits.svg File removed: wp-admin/images/about-header-freedoms.svg File removed: wp-admin/images/about-header-contribute.svg File removed: wp-admin/images/about-header-background.svg }}} See also https://make.wordpress.org/core/handbook/about/release-cycle/releasing-major-versions/#dry-run While there is an initial patch already, please double check before committing." swissspidy Last Week 59416 Add a GitHub Action which alerts contributors to a WordPress Playground link to use for testing PRs Build/Test Tools normal normal 6.6 task (blessed) new has-patch 2023-09-20T20:53:28Z 2024-03-06T06:44:58Z "The following approach could help bring in many new folks to help with testing PRs as they no longer need to have a local set up and able to load patches/PRs locally and can quickly jump into a WordPress Playground environment to help test. ---- Gutenberg has a GitHub Action that builds a ZIP of the plugin ([https://github.com/WordPress/gutenberg/blob/trunk/.github/workflows/build-plugin-zip.yml workflow file], [https://github.com/WordPress/gutenberg/actions/runs/6250831688 example Gutenberg PR with built ZIP attached]) which then [https://developer.wordpress.org/playground/ WordPress Playground] makes use of in the [https://playground.wordpress.net/gutenberg.html Gutenberg PR Previewer]. Taking that above functionality a step further and integrating for Core: 1. Add a GitHub Action for [https://github.com/WordPress/wordpress-develop/ wordpress-develop] that builds a ZIP of core for a PR (similar to the Gutenberg action). 2. Have that same action also add a comment to the PR with a link to a WordPress Playground that's built using the ZIP from the PR. So a comment like: > Thanks <@PR-author>! Here's a link to a site created from this PR that can be used for testing: . In my quick review of the [https://wordpress.github.io/wordpress-playground/ WordPress Playground documentation] it does reference an ability to [https://wordpress.github.io/wordpress-playground/build-your-first-app/#preview-pull-requests-from-your-repositorypreview pull requests from your repository], but I think that's crafted more for plugin developers and not for WordPress core itself. I took a look at [https://wordpress.github.io/wordpress-playground/api/client/interface/ReplaceSiteStep/ ReplaceSiteStep], but I think that's just for loading in alternate content and not a full on separate WordPress ZIP. So, this functionality might require additional functionality within WordPress Playground but I'll try and chase down folks from that team to comment here on the topic. " JeffPaul Last Week 60701 Bump default theme versions for WordPress 6.6 Bundled Theme normal normal 6.6 task (blessed) new 2024-03-06T05:03:35Z 2024-03-06T05:03:35Z "All bundled themes from 2010 to 2024 will need a version bump for the 6.6 release. Previously: #59816 - 6.5 #58832 - 6.4 #57857 - 6.3 #57689 - 6.2 #56450 - 6.1 #55754 - 6.0 #54783 - 5.9 #53277 - 5.8 #52704 - 5.7 #51919 - 5.6 #50889 - 5.5 #49743 - 5.4" mukesh27 Last Week 60698 Add optimized set lookup class. General trunk normal normal Awaiting Review feature request new 2024-03-06T01:18:34Z 2024-03-06T01:18:34Z "In the course of exploratory development in the HTML API there have been a few times where I wanted to test if a given string is in a set of statically-known strings, and a few times where I wanted to check if the next span of text represents an item in the set. For the first case, `in_array()` is a suitable method, but isn't always ideal when the test set is large. {{{#!php contains( '¬in' ) ) { … } while ( true ) { $was_at = $at; $at = strpos( $text, '&', $at ); if ( false === $at ) { $output .= substr( $text, $was_at ) break; } $name = $named_character_reference->read_token( $text, $at ); if ( false !== $name ) { $output .= substr( $text, $was_at, $at - $was_at ); $output .= $named_character_replacements[ $name ]; $at += strlen( $name ); continue; } // No named character reference was found, continue searching. ++$at; } }}} ---- Further, because WordPress largely deals with large and relatively static token sets (named character references, allowable URL schemes, file types, loaded templates, etc…), it would be nice to be able to precompute the lookup tables if they are at all costly, as doing so on every PHP load is unnecessarily burdensome. A bonus feature would be a method to add and a method to remove terms. ---- In [https://github.com/WordPress/wordpress-develop/pull/5373 #5373] I have proposed such a `WP_Token_Set` and used it in [https://github.com/WordPress/wordpress-develop/pull/5337 #5337] to create a spec-compliant, low-memory-overhead, and efficient replacement for `esc_attr()`. The replacement `esc_attr()` is able to more reliably parse attribute values than the existing code and it does so more efficiently, avoiding numerous memory allocations and lookups." dmsnell Yesterday 60802 Enable debug mode / debug options in site health Site Health normal minor Awaiting Review feature request new close 2024-03-18T19:34:03Z 2024-03-18T21:31:48Z "Debugging is a necessity for any developer and for WordPress users in general. As it stands now debug mode and the related debug options can only be enabled through manually editing the wp-config file to add or adjust wp-config constants. This makes debugging harder to access for everyone, and even more difficult to access for users that are either not familiar with ftp/ssh or who only have wp-admin access and not access to the filesystem. Adding toggle options for debugging mode in the Site Health tools wp-admin page would make troubleshooting errors and issues easier and more accessible for all users with administrator access. As a bonus, this would also decrease the demand on web host technical support because users would be more equipt to identify plugin conflicts, php errors and other issues independently. Proposed Site Health Options: - 'Enable debugging on/off' -- WP_DEBUG true/false with false as default and subtext about only setting to true/on for troubleshooting bc of adverse performance effects. - 'Enable debug log on/off' -- WP_DEBUG_LOG true/false - set to true/on as default and - Site Health could and should have a tab to view contents of debug logs within wp-admin (maybe -tail 30 or the last 30-50 results, potentially could improve on this to hide duplicate entries, to hide warnings and notices and to grep/search for keywords) - 'Show errors on front end on/off' - WP_DEBUG_DISPLAY true/false with a default to false so as not to expose debugging to end users and this could also have a toggle option to display errors only in wp-admin pages and not on the front end - Debugging should be set to never display on the front end in the first place as a default (ever), that could probably be it's own ticket - This could be expanded on to include toggle settings for SCRIPT_DEBUG and SAVEQUERIES constants " amykamala Yesterday 56358 PHP8 TypeError on current_time( 'timestamp' ) if timezone is set to GMT / 0 Date/Time 6.0 normal minor defect (bug) reopened 2022-08-09T22:46:45Z 2024-03-18T17:58:01Z "Just a minor bug to report, seems that if you have your timezone set to GMT, current_time( 'timestamp' ) throws a fatal error on PHP8, I think because 0 is being sent as a string. I can fix by changing my timezone to anything else. PHP Fatal error: Uncaught TypeError: Unsupported operand types: string * int in /wp-includes/functions.php:75 Stack trace: #0 /RSSItemPull.php(286): current_time('timestamp')" toastercookie Yesterday 52551 Twenty Twenty-One: Search box alignment Bundled Theme 5.7 normal minor 6.6 enhancement new has-patch 2021-02-17T07:17:16Z 2024-03-18T10:28:19Z I was Customized theme twenty twenty-one search-box on tablet and smartphones view. here search-box text field and button are not in correct alignment. vinita29 4-7 Days Ago 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 dev-feedback 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 4-7 Days Ago 52696 Add a way to determine whether a translation exists I18N normal minor Future Release enhancement new 2021-03-02T20:34:53Z 2024-03-13T20:09:06Z "Currently `__()` wraps `pomo/translations.php::translate_entry()̀` in such a way: {{{#!php $singular, 'context' => $context, ) ); $translated = $this->translate_entry( $entry ); return ( $translated && ! empty( $translated->translations ) ) ? $translated->translations[0] : $singular; } }}} If no translation exist, the original is returned which is the more frequently desirable behavior. But in some cases, the user may want to know whether the string obtained from `__()` is actually the translation or the original. **Use-case**: I'm inserting programmatically taxonomy terms translated using a 3rd-party service. I'm iterating over `[__(""t1""), __(""t2""), ...]` and I would like to only insert those actually translated, ignoring the others. Currently, I've no way to discriminate between the original and the translation (which may or may not be identical btw). I'd like a function providing me this ability like. One such example `__i18n_exists($term, $context = null);`" drzraf Last Week 60653 Block-based Widgets Editor - Site Logo Block is not listed. Widgets 6.4 normal minor Awaiting Review feature request assigned dev-feedback 2024-02-28T15:47:51Z 2024-03-12T19:18:51Z "It would be interesting to activate the Site Logo Block to appear in the Block-based Widgets Editor. [[Image(https://i.ibb.co/BLRLFp5/Captura-de-tela-2024-02-28-124402.png)]]" williansantana Last Week 18836 ORDER BY RAND() is slow pbearne Query normal minor enhancement assigned has-patch 2011-10-01T16:59:04Z 2024-03-12T17:55:53Z "WP_Query currently accepts 'orderby' => 'rand' which translates to ORDER BY RAND(). This is very slow when you have many posts, since it effectively calls RAND() for each row. A faster way would be to call RAND() only once and put it in the LIMIT clause. The only thing is that we have to make sure that the generated number is smaller than (total number of posts - number of posts to fetch). So, this would require to do an extra query to calculate the total. It should still be faster than the current method. If we want to get more than one post, we can get them in any order and then call shuffle() on the resulting array." scribu Last Week 60732 Update old document URLs to new ones audrasjb* General normal minor 6.6 enhancement accepted commit 2024-03-08T15:53:24Z 2024-03-12T06:51:33Z "Some articles that was in https://wordpress.org/documentation/ was moved under https://developer.wordpress.org/advanced-administration/ and the old URLs has a redirect. However URLs in php files still refer to the old ones so I thought the URLs should be updated to avoid unnecessary redirects." mkismy Last Week 60099 Fix revisions system Revisions 6.4.2 normal minor Awaiting Review defect (bug) new reporter-feedback 2023-12-18T20:22:50Z 2024-03-11T12:49:30Z "After upgrading to 6.4, the added section of the last revision of every post is empty, instead of showing the latest changes. [[Image(revisions-issue.jpg)]]" aulivur Last Week 60737 invalid_email or user_email ? Login and Registration trunk normal minor Awaiting Review enhancement new dev-feedback 2024-03-10T21:40:10Z 2024-03-10T21:40:10Z "Hey there, I'm talking about login error keys. Here are the 3 things we can find in the WP Core: {{{#!php add( 'invalid_email', __( 'Error: There is no account with that username or email address.' ) ); $errors->add( 'invalid_email', __( 'Error: The email address is not correct.' ) ); $errors->add( 'user_email', __( 'Error: The email address is not correct.' ), array('form-field' => 'email', ) ); }}} The 1st is an error message when you try to login using an email address that is not used as a user in this site, the key is ""invalid_email"" The 2nd is an error message when you try to register a new user with an email address that is not correctly formatted, the key is ""invalid_email"" The 3rd is an error message when you try to update your personal profile with an email address that is not correctly formatted, the key is ""user_email"" So we have 2 keys and 2 messages (like ""A1 A2 B2"", should be ""A1 B2 B2"") but the message 2 is sharing both, we should clearly decide is ""invalid_email"" is when the email does not exists in our site OR when the email is not correctly formatted. I suggest that the 2nd message should share the ""user_email"" and let the ""invalid_*"" for the login stuff, like we already have ""invalidcombo"" or ""invalid_username"" that shares the same kind of issue. thanks for your reading time" juliobox Last Week 60729 YouTube embed start= Embeds 6.4.3 normal minor Awaiting Review defect (bug) new 2024-03-08T07:24:54Z 2024-03-08T07:24:54Z "Hi. I am experiencing an issue where I am seeing the video start time being either randomized or shifted for each load. Expected behavior: YouTube video embedded with a timestamp like {youtube_url}start=5064, video starts at 1:24:24 each time video is loaded on a blog post. Issue 1: if ""resize for smaller devices"" is active the start point is randomized before posting. E.g. at 5064 it start approximately 30 seconds before it should (say 5034). I shift the start time to 5094 to try and compensate, resulting in it starting earlier than previously (say 5004). I leave it at 5064 and publish the blog post, with the result of it starting at 0 seconds (incognito mode, fresh browser, logged in). Issue 2: Resize for smaller devices is turned off. Now the first time the video is loaded it starts where it is supposed to start at 5064 seconds (steps: start video -> refresh page -> start video -> refresh -> ...). But, for each time the blog post is loaded and the viewers presses play, the start time shifts back approximately 30 seconds. This does not happen in incognito mode, here it loads at the correct timestamp each time the page is reloaded and video started." chrdre Last Week 29999 update post overwrites slug if current_user is contributor Posts, Post Types 4.0 normal minor Awaiting Review defect (bug) new dev-feedback 2014-10-16T08:09:04Z 2024-03-07T21:30:46Z "The [http://codex.wordpress.org/Function_Reference/wp_update_post/ wp_update_post] function calls [http://codex.wordpress.org/Function_Reference/wp_insert_post/ wp_insert_post] which is located in [https://core.trac.wordpress.org/browser/tags/4.0/src/wp-includes/post.php#L3068/ wp-includes/post.php] in posts.php at lines 3168 - 3171 there is this code: {{{ // Don't allow contributors to set the post slug for pending review posts. if ( 'pending' == $post_status && !current_user_can( 'publish_posts' ) ) { $post_name = ''; } }}} this will remove post_name if the current user is a contributor without any message or notification. This creates an issue because scripts/plugins that uses wp_upadate_post usually don't handle this case (the documentation doesn't cover this also - I would update the documentation but I'm wondering if there's no other solution). I don't see the issues that a contributor changing the slug would create (a contributor vs an editor) anybody does?" jnhghy Last Week 57059 add complete phpinfo() to site health Site Health normal minor Awaiting Review enhancement new close 2022-11-10T13:23:26Z 2024-03-07T10:14:03Z "We regularely run into situations where we need detailed information from the `phpinfo()` page. Currently the site health page is pretty nice when trying to get a quick overview of what is working and what is missing. But it would be nice if there is a link inside the Site Health page to a complete render of the `phpinfo()` method (similar to other CMS like Drupal). This page/link/tab (e.g. https://mysite.at/wp-admin/phpinfo.php) or whatever should only be accessible to logged in WordPress admins so no potentially critical information is leaked for not logged in users." beardcat Last Week 60429 Deprecated: Implicit conversion from float to int loses precision I18N normal minor Awaiting Review defect (bug) new 2024-02-03T02:42:48Z 2024-03-07T09:10:41Z "**Describe the bug** Running WordPress 6.4.3 this PHP warning comes up: {{{ Deprecated: Implicit conversion from float 4294967295 to int loses precision in /var/www/html/wp-includes/pomo/mo.php on line 208 }}} **To Reproduce** 1. Run WordPress 6.4.3 2. Switch on WP_DEBUG and WP_DEBUG_DISPLAY 3. Load the site 4. See warning printed out See https://github.com/LeoColomb/pomo/issues/16 for a screenshot. " retrovertigo Last Week 60721 redirect_canonical suddenly causes issues with paramter values and CDN Canonical 6.4.3 normal minor Awaiting Review defect (bug) new 2024-03-07T07:31:07Z 2024-03-07T07:31:07Z "Hi there, I was just wondering if anything has changed regarding https://developer.wordpress.org/reference/functions/redirect_canonical/? `https://some-domain.tld/?my_param=a+a` triggers a 301 redirect to `https://some-domain.tld/?my_param=a a` Now our CDN is set to pass URLs with `my_param` straight on to WordPress. Since that response with a 301, that's what gets cached by the CDN and causes a redirect loop. Is that something new? I hadn't had that issue before, but also not 100% sure if I sent a value like ""a+a"" before. Trying to figure out why this redirect loop happens now after years. I'll leave that ticket to be a bug, but if nothing has changed in redirect_canonical() then I guess it can just be closed. Thanks for your help." retrovertigo Last Week 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 has-patch 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