From noreply at wordpress.org  Wed Apr  1 00:33:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 00:33:29 -0000
Subject: [wp-trac] [WordPress Trac] #64245: Update bundled root
 certificates for 7.0
In-Reply-To: <051.9329d945b761b17ec3cc2d8d8625c518@wordpress.org>
References: <051.9329d945b761b17ec3cc2d8d8625c518@wordpress.org>
Message-ID: <066.bdcff63ddc3ae25890c8f1330a642c03@wordpress.org>

#64245: Update bundled root certificates for 7.0
----------------------------+-----------------------
 Reporter:  desrosj         |       Owner:  desrosj
     Type:  task (blessed)  |      Status:  reopened
 Priority:  normal          |   Milestone:  7.0
Component:  Security        |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+-----------------------
Changes (by desrosj):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Reopening to consider including `1.5.11` in the `7.0` release.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64245#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 00:51:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 00:51:55 -0000
Subject: [wp-trac] [WordPress Trac] #64245: Update bundled root
 certificates for 7.0
In-Reply-To: <051.9329d945b761b17ec3cc2d8d8625c518@wordpress.org>
References: <051.9329d945b761b17ec3cc2d8d8625c518@wordpress.org>
Message-ID: <066.bb138302c47d5aa88838615271521a29@wordpress.org>

#64245: Update bundled root certificates for 7.0
----------------------------+-----------------------
 Reporter:  desrosj         |       Owner:  desrosj
     Type:  task (blessed)  |      Status:  reopened
 Priority:  normal          |   Milestone:  7.0
Component:  Security        |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+-----------------------

Comment (by peterwilsoncc):

 Replying to [comment:5 desrosj]:
 > Reopening to consider including `1.5.11` in the `7.0` release.

 I think it worth doing considering the delay, it's best to ship up to date
 certificates with the release.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64245#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 01:39:35 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 01:39:35 -0000
Subject: [wp-trac] [WordPress Trac] #64761: Admin Reskin: Change color
 picker height to 40px
In-Reply-To: <053.0662e8cd42d998e112a54bd506e405a8@wordpress.org>
References: <053.0662e8cd42d998e112a54bd506e405a8@wordpress.org>
Message-ID: <068.291912425a592dc65b447bfff6a17251@wordpress.org>

#64761: Admin Reskin: Change color picker height to 40px
-------------------------------------------------+-------------------------
 Reporter:  wildworks                            |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  reviewing
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch has-          |     Focuses:
  screenshots commit                             |
-------------------------------------------------+-------------------------

Comment (by wildworks):

 @audrasjb Does this mean committing https://github.com/WordPress
 /wordpress-develop/pull/11385?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64761#comment:25>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 01:43:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 01:43:33 -0000
Subject: [wp-trac] [WordPress Trac] #64744: [Admin reskin] Admin Help
 still uses old colors
In-Reply-To: <055.0c02e31a40f81c610f1a91fdecc82ef7@wordpress.org>
References: <055.0c02e31a40f81c610f1a91fdecc82ef7@wordpress.org>
Message-ID: <070.dc09070290a2e14b8751a36fb40b5104@wordpress.org>

#64744: [Admin reskin] Admin Help still uses old colors
-------------------------------------------------+-------------------------
 Reporter:  fabiankaegy                          |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch has-          |     Focuses:  ui, css
  screenshots dev-feedback                       |
-------------------------------------------------+-------------------------

Comment (by wildworks):

 > Reopening to consider backporting [62187] to 7.0.

 Approved

 > Replying to [comment:33 audrasjb]:
 > > Reopening to consider backporting [62187] to 7.0.

 > Should the code from comment:29 be added instead of the removed code?

 Since the code from comment:29 already exists, I think we can simply
 backport [62187] to 7.0.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64744#comment:35>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 01:53:58 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 01:53:58 -0000
Subject: [wp-trac] [WordPress Trac] #65006: `uglify:moment` task fails due
 to missing source file
Message-ID: <051.84601c4d043c890905c0ce65fe4c33fe@wordpress.org>

#65006: `uglify:moment` task fails due to missing source file
------------------------------+--------------------
 Reporter:  desrosj           |      Owner:  (none)
     Type:  defect (bug)      |     Status:  new
 Priority:  normal            |  Milestone:  7.0
Component:  Build/Test Tools  |    Version:
 Severity:  normal            |   Keywords:
  Focuses:                    |
------------------------------+--------------------
 Follow up to #64393.

 When running the `build` script, the following notice is output:

 {{{
 Running "uglify:moment" (uglify) task
 >> Destination src/wp-includes/js/dist/vendor/moment.min.js not written
 because src files were empty.
 >> No files created.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65006>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 02:01:42 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 02:01:42 -0000
Subject: [wp-trac] [WordPress Trac] #62864: Add padding and color
 changes to buttons and inputs
In-Reply-To: <054.a3c8f2ead86a6b48e5676a1f3b5c857a@wordpress.org>
References: <054.a3c8f2ead86a6b48e5676a1f3b5c857a@wordpress.org>
Message-ID: <069.9ff312096e95d7dca4450f9122ae913d@wordpress.org>

#62864: Add padding and color changes to buttons and inputs
-------------------------------------------------+-------------------------
 Reporter:  karmatosed                           |       Owner:
                                                 |  fabiankaegy
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Administration                       |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  needs-design-feedback has-patch      |     Focuses:  ui,
  early                                          |  accessibility, css
-------------------------------------------------+-------------------------

Comment (by wildworks):

 Although I'm seeing this ticket for the first time, I would like to
 understand precisely what negative impacts arise from removing the line-
 height from the input element.

 I have tried changing the zoom level in various browsers, but I haven't
 encountered any text overflow issues.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62864#comment:21>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 02:34:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 02:34:12 -0000
Subject: [wp-trac] [WordPress Trac] #64393: Change how we include
 Gutenberg in Core
In-Reply-To: <055.264b0dba638f7c3f5a9d3208ee755072@wordpress.org>
References: <055.264b0dba638f7c3f5a9d3208ee755072@wordpress.org>
Message-ID: <070.4b5646b83bd5477611c364fa073ec238@wordpress.org>

#64393: Change how we include Gutenberg in Core
------------------------------+--------------------------
 Reporter:  youknowriad       |       Owner:  youknowriad
     Type:  task (blessed)    |      Status:  closed
 Priority:  high              |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:
 Severity:  blocker           |  Resolution:  fixed
 Keywords:  has-patch         |     Focuses:
------------------------------+--------------------------

Comment (by peterwilsoncc):

 In [changeset:"62189" 62189]:
 {{{
 #!CommitTicketReference repository="" revision="62189"
 Build/Test Tools: Copy vendor scripts earlier in the build.

 Relocates the `copy-vendor-scripts` to run during the the `build:js`
 portion of the build script. This ensures the JavaScript files are in
 place before the `uglify:all` task is run.

 Follow up to r61438

 Props desrosj.
 Fixes #65006. See #64393.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64393#comment:253>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 02:34:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 02:34:12 -0000
Subject: [wp-trac] [WordPress Trac] #65006: `uglify:moment` task fails
 due to missing source file
In-Reply-To: <051.84601c4d043c890905c0ce65fe4c33fe@wordpress.org>
References: <051.84601c4d043c890905c0ce65fe4c33fe@wordpress.org>
Message-ID: <066.8b0d57480a018d69156be66762a1ab23@wordpress.org>

#65006: `uglify:moment` task fails due to missing source file
------------------------------+----------------------------
 Reporter:  desrosj           |       Owner:  peterwilsoncc
     Type:  defect (bug)      |      Status:  closed
 Priority:  normal            |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:
 Severity:  normal            |  Resolution:  fixed
 Keywords:  has-patch         |     Focuses:
------------------------------+----------------------------
Changes (by peterwilsoncc):

 * owner:  (none) => peterwilsoncc
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62189" 62189]:
 {{{
 #!CommitTicketReference repository="" revision="62189"
 Build/Test Tools: Copy vendor scripts earlier in the build.

 Relocates the `copy-vendor-scripts` to run during the the `build:js`
 portion of the build script. This ensures the JavaScript files are in
 place before the `uglify:all` task is run.

 Follow up to r61438

 Props desrosj.
 Fixes #65006. See #64393.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65006#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 02:36:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 02:36:55 -0000
Subject: [wp-trac] [WordPress Trac] #65006: `uglify:moment` task fails
 due to missing source file
In-Reply-To: <051.84601c4d043c890905c0ce65fe4c33fe@wordpress.org>
References: <051.84601c4d043c890905c0ce65fe4c33fe@wordpress.org>
Message-ID: <066.a83e82be5203f6e8cca19c22573e8eca@wordpress.org>

#65006: `uglify:moment` task fails due to missing source file
------------------------------+----------------------------
 Reporter:  desrosj           |       Owner:  peterwilsoncc
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+----------------------------
Changes (by peterwilsoncc):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Reopening for merge to the 7.0 branch following clarification of process
 in [https://wordpress.slack.com/archives/C18723MQ8/p1775010927839849 the
 #core-committers slack channel].

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65006#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 02:38:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 02:38:09 -0000
Subject: [wp-trac] [WordPress Trac] #64923: command palette input
 doesn't allow some keys
In-Reply-To: <053.747254a9dfeb40c7a22945bdf3952663@wordpress.org>
References: <053.747254a9dfeb40c7a22945bdf3952663@wordpress.org>
Message-ID: <068.ab438ad42ff27c782419caa898014841@wordpress.org>

#64923: command palette input doesn't allow some keys
--------------------------+--------------------------------
 Reporter:  Presskopp     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  close         |     Focuses:  ui, accessibility
--------------------------+--------------------------------
Changes (by wildworks):

 * keywords:   => close


Comment:

 Perhaps the best course of action would be to completely move away from
 cmdk. I propose closing this ticket and continuing the discussion in
 Gutenberg.

 https://github.com/WordPress/gutenberg/issues/76950

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64923#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 02:47:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 02:47:22 -0000
Subject: [wp-trac] [WordPress Trac] #65007: Contents of some `.min.js` files
 are no longer minified
Message-ID: <051.ca77996bd759b0598d7de612a42ec74d@wordpress.org>

#65007: Contents of some `.min.js` files are no longer minified
------------------------------+--------------------
 Reporter:  desrosj           |      Owner:  (none)
     Type:  defect (bug)      |     Status:  new
 Priority:  normal            |  Milestone:  7.0
Component:  Build/Test Tools  |    Version:
 Severity:  normal            |   Keywords:
  Focuses:                    |
------------------------------+--------------------
 The contents of 4 files are no longer minified despite that being the case
 in 6.9:
 - `wp-polyfill-node-contains.min.js`
 - `wp-polyfill-dom-rect.min.js`
 - `regenerator-runtime.min.js`
 - `wp-polyfill-fetch.min.js`

 Follow up to #64393.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65007>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 02:47:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 02:47:28 -0000
Subject: [wp-trac] [WordPress Trac] #65007: Contents of some `.min.js`
 files are no longer minified
In-Reply-To: <051.ca77996bd759b0598d7de612a42ec74d@wordpress.org>
References: <051.ca77996bd759b0598d7de612a42ec74d@wordpress.org>
Message-ID: <066.2c049c9559a0ec425cc20ea8e2a1a800@wordpress.org>

#65007: Contents of some `.min.js` files are no longer minified
------------------------------+---------------------
 Reporter:  desrosj           |       Owner:  (none)
     Type:  defect (bug)      |      Status:  new
 Priority:  normal            |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:                    |     Focuses:
------------------------------+---------------------
Changes (by desrosj):

 * version:   => trunk


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65007#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 02:47:42 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 02:47:42 -0000
Subject: [wp-trac] [WordPress Trac] #65006: `uglify:moment` task fails
 due to missing source file
In-Reply-To: <051.84601c4d043c890905c0ce65fe4c33fe@wordpress.org>
References: <051.84601c4d043c890905c0ce65fe4c33fe@wordpress.org>
Message-ID: <066.290640a120bd3710b844cecf8e05ade2@wordpress.org>

#65006: `uglify:moment` task fails due to missing source file
------------------------------+----------------------------
 Reporter:  desrosj           |       Owner:  peterwilsoncc
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+----------------------------
Changes (by desrosj):

 * version:   => trunk


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65006#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 03:57:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 03:57:05 -0000
Subject: [wp-trac] [WordPress Trac] #64950: wp_using_ext_object_cache
 can return null, causing type failures, potential fatals
In-Reply-To: <051.0ea02aed2495587dfabbac6c5957d746@wordpress.org>
References: <051.0ea02aed2495587dfabbac6c5957d746@wordpress.org>
Message-ID: <066.ea5ed03c40420f1dd43d19fd4be05f2d@wordpress.org>

#64950: wp_using_ext_object_cache can return null, causing type failures, potential
fatals
--------------------------+--------------------------
 Reporter:  ronalfy       |       Owner:  westonruter
     Type:  defect (bug)  |      Status:  reviewing
 Priority:  normal        |   Milestone:  7.1
Component:  Cache API     |     Version:  3.7
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+--------------------------

Comment (by liaison):

 Replying to [comment:4 westonruter]:
 > @liaison Inside `wp_using_ext_object_cache()`, wouldn't it be helpful if
 it emitted a `_doing_it_wrong()` if `$_wp_using_ext_object_cache` is
 `null`?
 >
 > I'm trying to reproduce the issue here. In the wordpress-develop
 environment with `LOCAL_PHP_MEMCACHED=true` added to `.env`, I'm seeing
 that `wp_using_ext_object_cache()` is returning `true` even when when an
 mu-plugin is added with:
 >
 > {{{#!php
 > <?php
 > var_dump( wp_using_ext_object_cache() );
 > }}}
 >
 >
 > However, I ''do'' see it output `NULL` if added to `db.php`. So it seems
 this is specifically an issue with `db.php`.
 >
 > Nevertheless, if I have `LOCAL_PHP_MEMCACHED=false` in my `.env`, then
 `wp_using_ext_object_cache()` is returning `NULL` even very late in the
 execution cycle.
 >
 > {{{#!php
 > <?php
 > add_action( 'template_redirect', function () {
 >       var_dump( wp_using_ext_object_cache() );
 > } );
 > }}}
 >
 > So it seems the function has always returned `null` if there is no
 `object-cache.php` drop-in? Apparently its return values are `null|true`?

 I've refined the PR with _doing_it_wrong() check specifically for the null
 state while maintaining type safety (returning false instead of null).
 Also to include a function_exists() check for _doing_it_wrong(). This
 ensures compatibility during the very early bootstrap stages (like db.php)
 where the function might not be defined yet. I've also ensured the return
 type is strictly boolean as discussed.

 {{{#!php
 <?php
 function wp_using_ext_object_cache( $using = null ) {
         global $_wp_using_ext_object_cache;

         // Save the current state to return later.
         $current_using = $_wp_using_ext_object_cache;

         if ( null !== $using ) {
                 $_wp_using_ext_object_cache = (bool) $using;
         }

         if ( null === $_wp_using_ext_object_cache ) {
                 if ( function_exists( '_doing_it_wrong' ) ) {
                         _doing_it_wrong(
                                 __FUNCTION__,
                                 __( 'This function should not be called
 before the object cache is initialized.' ),
                                 '7.1.0'
                         );
                 }

                 // If the global is uninitialized, the value would be
 null, which violates the type signature.
                 return false;
         }

         return (bool) $current_using;
 }
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64950#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 04:40:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 04:40:53 -0000
Subject: [wp-trac] [WordPress Trac] #64761: Admin Reskin: Change color
 picker height to 40px
In-Reply-To: <053.0662e8cd42d998e112a54bd506e405a8@wordpress.org>
References: <053.0662e8cd42d998e112a54bd506e405a8@wordpress.org>
Message-ID: <068.e5c534d838449fbb3459dc9fdc3ccab2@wordpress.org>

#64761: Admin Reskin: Change color picker height to 40px
-------------------------------------------------+-------------------------
 Reporter:  wildworks                            |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  reviewing
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch has-          |     Focuses:
  screenshots commit                             |
-------------------------------------------------+-------------------------

Comment (by audrasjb):

 @wildworks yes, 11385

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64761#comment:26>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 04:42:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 04:42:33 -0000
Subject: [wp-trac] [WordPress Trac] #64744: [Admin reskin] Admin Help
 still uses old colors
In-Reply-To: <055.0c02e31a40f81c610f1a91fdecc82ef7@wordpress.org>
References: <055.0c02e31a40f81c610f1a91fdecc82ef7@wordpress.org>
Message-ID: <070.434525fe2c9ce5c56e2dd4a9d6566956@wordpress.org>

#64744: [Admin reskin] Admin Help still uses old colors
-------------------------------------------------+-------------------------
 Reporter:  fabiankaegy                          |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch has-          |     Focuses:  ui, css
  screenshots dev-feedback                       |
-------------------------------------------------+-------------------------

Comment (by audrasjb):

 @SergeyBiryukov @wildworks yes, I think we can go with [62187]  as a
 follow-up to [62145].

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64744#comment:36>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 05:05:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 05:05:44 -0000
Subject: [wp-trac] [WordPress Trac] #65003: next/prev for enlarged image
 needs context
In-Reply-To: <052.b63525ba9b3238159791aa05ff965555@wordpress.org>
References: <052.b63525ba9b3238159791aa05ff965555@wordpress.org>
Message-ID: <067.4f47f8fd2d893ca04ebca95b0d84328e@wordpress.org>

#65003: next/prev for enlarged image needs context
--------------------------+---------------------
 Reporter:  timse201      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  I18N          |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+---------------------
Changes (by audrasjb):

 * keywords:  has-patch => needs-patch


Comment:

 Introduced in [62123]. This can't be fixed on Core side, we'll need to fix
 this on Gutenberg side before.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65003#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 05:07:25 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 05:07:25 -0000
Subject: [wp-trac] [WordPress Trac] #64976: Admin Style: Plugin links
 change styles on updates on 7.0
In-Reply-To: <052.33a9a520dd04c4f79918027e12c9cff4@wordpress.org>
References: <052.33a9a520dd04c4f79918027e12c9cff4@wordpress.org>
Message-ID: <067.da385cb337d59d2e8455b02b3589eb79@wordpress.org>

#64976: Admin Style: Plugin links change styles on updates on 7.0
-------------------------------------------------+-------------------------
 Reporter:  antonynz                             |       Owner:  joedolson
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  minor                                |  Resolution:
 Keywords:  admin-reskin has-patch has-          |     Focuses:
  screenshots commit                             |
-------------------------------------------------+-------------------------
Changes (by audrasjb):

 * keywords:  admin-reskin has-patch has-screenshots => admin-reskin has-
     patch has-screenshots commit


Comment:

 The PR looks good to me. Marking it as ready for commit.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64976#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 06:02:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 06:02:21 -0000
Subject: [wp-trac] [WordPress Trac] #64771: Existing block level custom
 CSS in a post breaks when the post is edited by user without
 unfiltered_html
In-Reply-To: <056.6cde4cb4d3674a3ab453a19d1888b21e@wordpress.org>
References: <056.6cde4cb4d3674a3ab453a19d1888b21e@wordpress.org>
Message-ID: <071.50a88a5d6fad1853425c22f18820f501@wordpress.org>

#64771: Existing block level custom CSS in a post breaks when the post is edited by
user without unfiltered_html
--------------------------------------------------+---------------------
 Reporter:  glendaviesnz                          |       Owner:  (none)
     Type:  defect (bug)                          |      Status:  new
 Priority:  high                                  |   Milestone:  7.0
Component:  Editor                                |     Version:  trunk
 Severity:  critical                              |  Resolution:
 Keywords:  has-patch has-unit-tests 2nd-opinion  |     Focuses:
--------------------------------------------------+---------------------

Comment (by ramonopoly):

 > 1. Revert the whole block level css feature and punt it to 7.1
 > 2. Find a solution for the issue on this feature during the small amount
 of time we have until 7.0 is released
 > 3. Show a simple warning notice and punt a more complete solution to 7.1


 From what I've read so far, `2` isn't feasible and the strip + warning was
 the compromise to all the suggestions offered so far.

 The strip + warning PR has been approved for the plugin, with a Core patch
 still to come I guess: https://github.com/WordPress/gutenberg/pull/76650

 So that implies `3` could be acceptable to folks?

 @glendaviesnz might be able to shed light on the implications of a full
 revert + punt.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64771#comment:48>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 06:54:43 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 06:54:43 -0000
Subject: [wp-trac] [WordPress Trac] #64298: Move the `failed-workflow`
 job logic into a reusable workflow
In-Reply-To: <051.02bd0a949a9deb60d0688818a1bb25df@wordpress.org>
References: <051.02bd0a949a9deb60d0688818a1bb25df@wordpress.org>
Message-ID: <066.2154bd2dbd89bb6b23abb3de48b3a801@wordpress.org>

#64298: Move the `failed-workflow` job logic into a reusable workflow
------------------------------+-----------------------------
 Reporter:  desrosj           |       Owner:  (none)
     Type:  enhancement       |      Status:  reopened
 Priority:  normal            |   Milestone:  Future Release
Component:  Build/Test Tools  |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  good-first-bug    |     Focuses:
------------------------------+-----------------------------

Comment (by moisesfonseca):

 Reviewed the ticket and patch.
 Moving the failed-workflow job to a reusable workflow makes sense given
 the duplication across workflows.
 This should improve maintainability across branches.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64298#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 07:13:00 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 07:13:00 -0000
Subject: [wp-trac] [WordPress Trac] #65002: Connectors: Replace
 plugin.slug with plugin.file and harden plugin data handling
In-Reply-To: <060.a8d38794450573f71fbec1ec7c7a0f56@wordpress.org>
References: <060.a8d38794450573f71fbec1ec7c7a0f56@wordpress.org>
Message-ID: <075.07dc5a3427eaf5f568c31efb95a32ca3@wordpress.org>

#65002: Connectors: Replace plugin.slug with plugin.file and harden plugin data
handling
---------------------------------------------------+---------------------
 Reporter:  jorgefilipecosta                       |       Owner:  (none)
     Type:  defect (bug)                           |      Status:  new
 Priority:  normal                                 |   Milestone:  7.0
Component:  General                                |     Version:  trunk
 Severity:  normal                                 |  Resolution:
 Keywords:  has-patch has-unit-tests dev-reviewed  |     Focuses:
---------------------------------------------------+---------------------
Changes (by gziolo):

 * keywords:  has-patch has-unit-tests => has-patch has-unit-tests dev-
     reviewed


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65002#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 07:33:50 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 07:33:50 -0000
Subject: [wp-trac] [WordPress Trac] #64744: [Admin reskin] Admin Help
 still uses old colors
In-Reply-To: <055.0c02e31a40f81c610f1a91fdecc82ef7@wordpress.org>
References: <055.0c02e31a40f81c610f1a91fdecc82ef7@wordpress.org>
Message-ID: <070.902d34eea88e781937bf06169e6fda11@wordpress.org>

#64744: [Admin reskin] Admin Help still uses old colors
-------------------------------------------------+-------------------------
 Reporter:  fabiankaegy                          |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  admin-reskin has-patch has-          |     Focuses:  ui, css
  screenshots dev-feedback                       |
-------------------------------------------------+-------------------------
Changes (by wildworks):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62190" 62190]:
 {{{
 #!CommitTicketReference repository="" revision="62190"
 Administration: Prevent horizontal scrollbar in contextual help panel.

 In [62145], an ::after CSS rule was added that caused an overflow,
 resulting in an unintended scrollbar always appearing on Windows OS for
 example. This changeset removes the related CSS rule which is unnecessary
 to fix the initial issue.

 Follow-up to [62145].

 Reviewed by wildworks, SergeyBiryukov.
 Merges [62187] to the 7.0 branch.

 Props wildworks, SergeyBiryukov, sabernhardt, audrasjb, huzaifaalmesbah,
 mehrazmorshed, mukesh27.
 Fixes #64744.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64744#comment:37>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 08:41:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 08:41:49 -0000
Subject: [wp-trac] [WordPress Trac] #65008: Block Hooks / RTC: Auto-inserted
 blocks duplicated on page refresh or collaborator join
Message-ID: <059.319ad79e4a20ae87460da2f729f62d48@wordpress.org>

#65008: Block Hooks / RTC: Auto-inserted blocks duplicated on page refresh or
collaborator join
-----------------------------+--------------------
 Reporter:  Bernhard Reiter  |      Owner:  (none)
     Type:  defect (bug)     |     Status:  new
 Priority:  normal           |  Milestone:  7.0
Component:  Editor           |    Version:  trunk
 Severity:  normal           |   Keywords:
  Focuses:                   |
-----------------------------+--------------------
 ''As reported [https://github.com/WordPress/gutenberg/issues/76176 here]
 by @ingeniumed, with some edits by myself''

 When real-time collaboration is activated, if a post contains blocks auto-
 inserted by the Block Hooks API, joining a real-time collaboration session
 (via page refresh or a second collaborator opening the post) causes the
 hooked blocks to be duplicated in the editor. The duplication compounds
 with each new session join, and each additional collaborator or refresh
 adds another copy of every hooked block.

 == Step-by-step reproduction instructions

 0. Enable real-time collaboration (in Settings > Writing).
 1. Create a new post and add a core/heading block and a core/paragraph
 block.
 2. Publish or save the post, then close it.
 3. Activate the
 [https://github.com/WordPress/gutenberg/blob/c21d3ce958e9c4c6f2f5053fa995a06d9740721a/packages
 /e2e-tests/plugins/block-hooks.php Gutenberg Block Hooks plugin from
 `packages/e2e-test/plugins`] (or any plugin that registers blocks via the
 Block Hooks API).
 4. Reopen the post. The Block Hooks API auto-inserts its blocks (in the
 after and last_child positions).
 5. Without saving, reload the post. Observe that the auto-inserted
 paragraph at the end of the post has been duplicated. Notice that every
 subsequent reload adds another copy.

 Alternative to item 5: Open the same post in a second browser window or
 tab to simulate a second collaborator joining the RTC session.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65008>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 08:41:58 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 08:41:58 -0000
Subject: [wp-trac] [WordPress Trac] #65008: Block Hooks / RTC:
 Auto-inserted blocks duplicated on page refresh or collaborator join
In-Reply-To: <059.319ad79e4a20ae87460da2f729f62d48@wordpress.org>
References: <059.319ad79e4a20ae87460da2f729f62d48@wordpress.org>
Message-ID: <074.fa43b117fa1afe93b581f994bc397007@wordpress.org>

#65008: Block Hooks / RTC: Auto-inserted blocks duplicated on page refresh or
collaborator join
-----------------------------+------------------------------
 Reporter:  Bernhard Reiter  |       Owner:  Bernhard Reiter
     Type:  defect (bug)     |      Status:  assigned
 Priority:  normal           |   Milestone:  7.0
Component:  Editor           |     Version:  trunk
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+------------------------------
Changes (by Bernhard Reiter):

 * owner:  (none) => Bernhard Reiter
 * status:  new => assigned


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65008#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 08:57:04 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 08:57:04 -0000
Subject: [wp-trac] [WordPress Trac] #64761: Admin Reskin: Change color
 picker height to 40px
In-Reply-To: <053.0662e8cd42d998e112a54bd506e405a8@wordpress.org>
References: <053.0662e8cd42d998e112a54bd506e405a8@wordpress.org>
Message-ID: <068.8dadba2e84045deac0c55a3fad0b3830@wordpress.org>

#64761: Admin Reskin: Change color picker height to 40px
-------------------------------------------------+-------------------------
 Reporter:  wildworks                            |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  reviewing
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch has-          |     Focuses:
  screenshots commit                             |
-------------------------------------------------+-------------------------

Comment (by wildworks):

 I see, I will commit https://github.com/WordPress/wordpress-
 develop/pull/11385.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64761#comment:27>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 09:18:58 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 09:18:58 -0000
Subject: [wp-trac] [WordPress Trac] #64761: Admin Reskin: Change color
 picker height to 40px
In-Reply-To: <053.0662e8cd42d998e112a54bd506e405a8@wordpress.org>
References: <053.0662e8cd42d998e112a54bd506e405a8@wordpress.org>
Message-ID: <068.51e83ece65dfbaa3ce9f01b6cfff15da@wordpress.org>

#64761: Admin Reskin: Change color picker height to 40px
-------------------------------------------------+-------------------------
 Reporter:  wildworks                            |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  admin-reskin has-patch has-          |     Focuses:
  screenshots commit                             |
-------------------------------------------------+-------------------------
Changes (by wildworks):

 * status:  reviewing => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62191" 62191]:
 {{{
 #!CommitTicketReference repository="" revision="62191"
 Admin Reskin: Change color picker height to match new design system.

 Update min-height from 30px to 32px for the color picker button and
 related elements to match new design system.

 Props audrasjb, hmbashar, huzaifaalmesbah, joedolson, juanmaguitar,
 mukesh27, noruzzaman, ozgursar, rahultank, rcorrales, sajib1223,
 tusharaddweb, vgnavada, wildworks.

 Fixes #64761.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64761#comment:28>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 09:20:15 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 09:20:15 -0000
Subject: [wp-trac] [WordPress Trac] #64761: Admin Reskin: Change color
 picker height to 40px
In-Reply-To: <053.0662e8cd42d998e112a54bd506e405a8@wordpress.org>
References: <053.0662e8cd42d998e112a54bd506e405a8@wordpress.org>
Message-ID: <068.d9fe4eef5b6900b242f1933eb0bee07c@wordpress.org>

#64761: Admin Reskin: Change color picker height to 40px
-------------------------------------------------+-------------------------
 Reporter:  wildworks                            |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch has-          |     Focuses:
  screenshots dev-feedback                       |
-------------------------------------------------+-------------------------
Changes (by wildworks):

 * keywords:  admin-reskin has-patch has-screenshots commit => admin-reskin
     has-patch has-screenshots dev-feedback
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Reopening #64761 to request backporting [62191] to 7.0 branch

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64761#comment:29>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 09:30:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 09:30:14 -0000
Subject: [wp-trac] [WordPress Trac] #64761: Admin Reskin: Change color
 picker height to 40px
In-Reply-To: <053.0662e8cd42d998e112a54bd506e405a8@wordpress.org>
References: <053.0662e8cd42d998e112a54bd506e405a8@wordpress.org>
Message-ID: <068.f9a1ef2072b7349f663a8e8aa5015928@wordpress.org>

#64761: Admin Reskin: Change color picker height to 40px
-------------------------------------------------+-------------------------
 Reporter:  wildworks                            |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch has-          |     Focuses:
  screenshots dev-feedback                       |
-------------------------------------------------+-------------------------

Comment (by shailu25):

 @wildworks I think you forgot to add me in the prop list.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64761#comment:30>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 09:34:20 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 09:34:20 -0000
Subject: [wp-trac] [WordPress Trac] #64761: Admin Reskin: Change color
 picker height to 40px
In-Reply-To: <053.0662e8cd42d998e112a54bd506e405a8@wordpress.org>
References: <053.0662e8cd42d998e112a54bd506e405a8@wordpress.org>
Message-ID: <068.2cd00977bb1e6593b7751daa55756004@wordpress.org>

#64761: Admin Reskin: Change color picker height to 40px
-------------------------------------------------+-------------------------
 Reporter:  wildworks                            |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch has-          |     Focuses:
  screenshots dev-feedback                       |
-------------------------------------------------+-------------------------

Comment (by wildworks):

 @shailu25 Sorry!

 @audrasjb, I believe I was able to update props on a certain website. Do
 you know about that?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64761#comment:31>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 09:46:51 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 09:46:51 -0000
Subject: [wp-trac] [WordPress Trac] #44524: Allow Users to View Custom
 Post Type Admin Page
In-Reply-To: <051.a67fad988942a90a0a40908c916c4ef5@wordpress.org>
References: <051.a67fad988942a90a0a40908c916c4ef5@wordpress.org>
Message-ID: <066.f40b118302f9efe2873f84e9e37e1b6d@wordpress.org>

#44524: Allow Users to View Custom Post Type Admin Page
-------------------------------------------------+-------------------------
 Reporter:  wpsmith                              |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Posts, Post Types                    |     Version:
 Severity:  normal                               |  Resolution:  duplicate
 Keywords:  has-patch dev-feedback needs-        |     Focuses:
  refresh                                        |  administration
-------------------------------------------------+-------------------------
Changes (by manfcarlo):

 * status:  new => closed
 * resolution:   => duplicate


Comment:

 Duplicate of #22895.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/44524#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 10:19:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 10:19:44 -0000
Subject: [wp-trac] =?utf-8?q?=5BWordPress_Trac=5D_=2365009=3A_Privacy=3A_?=
 =?utf-8?q?=E2=80=9DCopied!=E2=80=9D_text_is_misaligned?=
Message-ID: <053.5ad09e193f9b440670b51501b1539f2b@wordpress.org>

#65009: Privacy: ”Copied!” text is misaligned
--------------------------+--------------------------
 Reporter:  wildworks     |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  7.0
Component:  Privacy       |    Version:
 Severity:  normal        |   Keywords:  admin-reskin
  Focuses:                |
--------------------------+--------------------------
 When the "Copy suggested policy text to clipboardCopy suggested policy
 text from WordPress." button is clicked, the text "Copied" is displayed to
 the left of the button.

 The text and the button should be vertically aligned.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65009>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 10:19:54 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 10:19:54 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2365009=3A_Privacy=3A_?=
 =?utf-8?q?=E2=80=9DCopied!=E2=80=9D_text_is_misaligned?=
In-Reply-To: <053.5ad09e193f9b440670b51501b1539f2b@wordpress.org>
References: <053.5ad09e193f9b440670b51501b1539f2b@wordpress.org>
Message-ID: <068.91301fb00351796a3b56c28792e72abb@wordpress.org>

#65009: Privacy: ”Copied!” text is misaligned
--------------------------+---------------------
 Reporter:  wildworks     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  Privacy       |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  admin-reskin  |     Focuses:
--------------------------+---------------------
Changes (by wildworks):

 * Attachment "privacy-action-alignment.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65009>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 10:23:25 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 10:23:25 -0000
Subject: [wp-trac] [WordPress Trac] #64779: Notes can be edited and
 deleted by other users
In-Reply-To: <052.5551217cf4306aea1e0cf167b5c43983@wordpress.org>
References: <052.5551217cf4306aea1e0cf167b5c43983@wordpress.org>
Message-ID: <067.860cdb5962357e12452a6b50f6005636@wordpress.org>

#64779: Notes can be edited and deleted by other users
--------------------------------------+---------------------
 Reporter:  mindctrl                  |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  7.1
Component:  Comments                  |     Version:  6.9
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by manfcarlo):

 I think the pre-existing behaviour (any user able to delete any note) is
 correct. If someone leaves a note with profanity or personal attacks, or a
 typo, it should be easy for others to delete/correct without having to
 contact someone with higher privileges. If someone is maliciously deleting
 or changing other users' notes, they would be better off having their
 editing access to the whole post revoked.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64779#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 10:25:02 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 10:25:02 -0000
Subject: [wp-trac] [WordPress Trac] #65010: Media: The progress bar color is
 outdated
Message-ID: <053.19c481fcfd177ed15cdcc3946b04094c@wordpress.org>

#65010: Media: The progress bar color is outdated
--------------------------+--------------------------
 Reporter:  wildworks     |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  7.0
Component:  Media         |    Version:
 Severity:  normal        |   Keywords:  admin-reskin
  Focuses:                |
--------------------------+--------------------------
 The progress bar color when uploading media is outdated.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65010>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 10:25:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 10:25:13 -0000
Subject: [wp-trac] [WordPress Trac] #65010: Media: The progress bar
 color is outdated
In-Reply-To: <053.19c481fcfd177ed15cdcc3946b04094c@wordpress.org>
References: <053.19c481fcfd177ed15cdcc3946b04094c@wordpress.org>
Message-ID: <068.339e1b129149f350204bf0d21917c739@wordpress.org>

#65010: Media: The progress bar color is outdated
--------------------------+---------------------
 Reporter:  wildworks     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  Media         |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  admin-reskin  |     Focuses:
--------------------------+---------------------
Changes (by wildworks):

 * Attachment "progress-bar-color.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65010>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 10:30:45 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 10:30:45 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2365009=3A_Privacy=3A_?=
 =?utf-8?q?=E2=80=9DCopied!=E2=80=9D_text_is_misaligned?=
In-Reply-To: <053.5ad09e193f9b440670b51501b1539f2b@wordpress.org>
References: <053.5ad09e193f9b440670b51501b1539f2b@wordpress.org>
Message-ID: <068.326aa70e1691825d9eb062baacf3174c@wordpress.org>

#65009: Privacy: ”Copied!” text is misaligned
--------------------------+---------------------
 Reporter:  wildworks     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  Privacy       |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  admin-reskin  |     Focuses:
--------------------------+---------------------

Comment (by anupkankale):

 I'm working on a bug for this. Will submit a PR shortly.

 #65009 new defect (bug)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65009#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 10:35:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 10:35:13 -0000
Subject: [wp-trac] [WordPress Trac] #64926: REST API: GET requests fail
 object/array schema validation when params are JSON-serialized strings
In-Reply-To: <048.09e4f6945084c0394353ff269647c101@wordpress.org>
References: <048.09e4f6945084c0394353ff269647c101@wordpress.org>
Message-ID: <063.1fe179dc6d1c67beef328530a2efcead@wordpress.org>

#64926: REST API: GET requests fail object/array schema validation when params are
JSON-serialized strings
-------------------------+-------------------------------------------------
 Reporter:  dsmy         |       Owner:  (none)
     Type:  defect       |      Status:  new
  (bug)                  |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  REST API     |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  javascript, rest-api, php-
                         |  compatibility
-------------------------+-------------------------------------------------

Comment (by abcd95):

 IMO, placing the decode at the top of the function misses `anyOf/oneOf`
 schemas with no top-level type, and the $type resolves to `''` and the
 block is skipped on the initial call. It only works because recursive
 calls from rest_find_any_matching_schema() re-enter with the sub-schema's
 type set.

 Moving the decode inside the switch (validation) and before
 rest_sanitize_array()/rest_sanitize_object() (sanitization) ensures it
 fires after type resolution, regardless of schema.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64926#comment:21>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 11:03:08 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 11:03:08 -0000
Subject: [wp-trac] [WordPress Trac] #12801: Add Info link to plugins
 management screen
In-Reply-To: <048.8b9d62354ca1495ed0c82cb910d05114@wordpress.org>
References: <048.8b9d62354ca1495ed0c82cb910d05114@wordpress.org>
Message-ID: <063.08b6c90a3c2980a0fbca50008a30f64f@wordpress.org>

#12801: Add Info link to plugins management screen
-------------------------------------------+-------------------------------
 Reporter:  jane                           |       Owner:  chriscct7
     Type:  feature request                |      Status:  reviewing
 Priority:  normal                         |   Milestone:
Component:  Plugins                        |     Version:  3.0
 Severity:  minor                          |  Resolution:
 Keywords:  has-patch needs-refresh close  |     Focuses:  ui,
                                           |  administration
-------------------------------------------+-------------------------------
Changes (by abcd95):

 * keywords:  has-patch needs-refresh => has-patch needs-refresh close


Comment:

 It looks like this feature has already been addressed in core. The plugins
 list screen now shows a "View details" link for plugins available on
 WordPress.org, which opens the same tabbed info modal that was originally
 requested. Specifically, WP_Plugins_List_Table::single_row() renders this
 link in the plugin meta row (next to "Version | By Author") for any plugin
 with a known slug via the update_plugins transient.

 The link appears in the description area rather than in the action links
 row, and is labeled "View details" instead of "Info," but it serves the
 same purpose.

 I'd suggest closing this as fixed. If there's interest in also adding it
 as an action link alongside Activate/Deactivate/Delete, happy to prepare a
 patch.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/12801#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 11:05:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 11:05:29 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2365009=3A_Privacy=3A_?=
 =?utf-8?q?=E2=80=9DCopied!=E2=80=9D_text_is_misaligned?=
In-Reply-To: <053.5ad09e193f9b440670b51501b1539f2b@wordpress.org>
References: <053.5ad09e193f9b440670b51501b1539f2b@wordpress.org>
Message-ID: <068.a6b41df92a80665ab00a23785f68d104@wordpress.org>

#65009: Privacy: ”Copied!” text is misaligned
-------------------------------------------------+-------------------------
 Reporter:  wildworks                            |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  7.0
Component:  Privacy                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch changes-      |     Focuses:
  requested                                      |
-------------------------------------------------+-------------------------
Changes (by mukesh27):

 * keywords:  admin-reskin has-patch => admin-reskin has-patch changes-
     requested


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65009#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 11:17:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 11:17:17 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2365009=3A_Privacy=3A_?=
 =?utf-8?q?=E2=80=9DCopied!=E2=80=9D_text_is_misaligned?=
In-Reply-To: <053.5ad09e193f9b440670b51501b1539f2b@wordpress.org>
References: <053.5ad09e193f9b440670b51501b1539f2b@wordpress.org>
Message-ID: <068.9b77d3301fceb95042ec554177986c08@wordpress.org>

#65009: Privacy: ”Copied!” text is misaligned
------------------------------------+-----------------------
 Reporter:  wildworks               |       Owner:  mukesh27
     Type:  defect (bug)            |      Status:  assigned
 Priority:  normal                  |   Milestone:  7.0
Component:  Privacy                 |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  admin-reskin has-patch  |     Focuses:
------------------------------------+-----------------------
Changes (by mukesh27):

 * keywords:  admin-reskin has-patch changes-requested => admin-reskin has-
     patch
 * owner:  (none) => mukesh27
 * status:  new => assigned


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65009#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 11:59:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 11:59:05 -0000
Subject: [wp-trac] [WordPress Trac] #64171: Cache failed requests to
 WordPress.org API endpoints
In-Reply-To: <057.dc6a212d33bbae1b1fae2d00d8e5ac87@wordpress.org>
References: <057.dc6a212d33bbae1b1fae2d00d8e5ac87@wordpress.org>
Message-ID: <072.2eddbc4707f99b782bc0dcd21ed6bbaf@wordpress.org>

#64171: Cache failed requests to WordPress.org API endpoints
---------------------------+------------------------------
 Reporter:  peterwilsoncc  |       Owner:  (none)
     Type:  defect (bug)   |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  General        |     Version:
 Severity:  normal         |  Resolution:
 Keywords:                 |     Focuses:  performance
---------------------------+------------------------------

Comment (by jdeep):

 Hi, I checked this in my local setup by following the steps mentioned but
 I didn't notice any delays and was not able to reproduce this. My
 configuration (through LocalWP):

 WordPress: 6.9.4
 PHP: 8.2.30
 Database: MySQL 8.0.35

 I will investigate a bit more on it and update here.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64171#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 12:14:38 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 12:14:38 -0000
Subject: [wp-trac] [WordPress Trac] #54016: Media Library: Bulk delete
 elements in grid view takes very long
In-Reply-To: <053.163729d7b8e833e3128db8a5d8edb4b2@wordpress.org>
References: <053.163729d7b8e833e3128db8a5d8edb4b2@wordpress.org>
Message-ID: <068.69146baf75a23c933868f3297138ae62@wordpress.org>

#54016: Media Library: Bulk delete elements in grid view takes very long
-------------------------+------------------------------
 Reporter:  Presskopp    |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Media        |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:  performance
-------------------------+------------------------------

Comment (by jdeep):

 I would like to spent some time looking for a good approach for this. I
 checked this and can argue that sending an ajax request for every image is
 not performant.

 A simple solution would be to gather the selected attachment IDs from the
 Backbone selection collection on the frontend and send them to a new bulk
 delete AJAX endpoint. To prevent server timeouts on large deletions, we
 could chunk the requests in reasonable sizes. This approach should reduce
 the network overhead. We can always optimise how the backend deletes the
 data (through cron jobs or immediate deletes).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/54016#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 12:26:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 12:26:21 -0000
Subject: [wp-trac] [WordPress Trac] #62622: Bump minimum PHP version to
 7.4
In-Reply-To: <054.0e8fc3c3ef21a16174aab98b36d22a1d@wordpress.org>
References: <054.0e8fc3c3ef21a16174aab98b36d22a1d@wordpress.org>
Message-ID: <069.e5b570e2f04ae1d8f9ef2bf089fa3cb2@wordpress.org>

#62622: Bump minimum PHP version to 7.4
-------------------------------------------------+-------------------------
 Reporter:  justlevine                           |       Owner:
                                                 |  johnbillion
     Type:  enhancement                          |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  General                              |     Version:
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests add-to-     |     Focuses:
  field-guide                                    |
-------------------------------------------------+-------------------------

Comment (by samiamnot):

 Updated for early April 2026 based on [https://wordpress.org/about/stats/
 WordPress stats]. This will hopefully be the last post on this ticket,
 with next month's stats posted to #64494.

 7.2 + 7.3 that are slated to be the next PHP versions no longer supported
 by WordPress, continued dropping and reached 3.51%, a reduction of 0.12%
 since last month. It is interesting that the drop in sites on 7.2+7.3
 macthed the drop in older versions back to PHP 5.2, indicating an overall
 slowdown in updates of all older versions.

 The percentage of total sites on unsupported PHP versions (PHP 5.2 - 7.3)
 stands at 6.94% of sites, the first time that they were under 7%. Many are
 old abandoned sites that are unlikely to be updated.

 ||='''Month/Year'''=||='''PHP 7.2'''=||='''PHP 7.3'''=||='''PHP 7.2 +
 7.3'''=||
 ||Jul 2023|| 6.48|| 8.16|| '''14.64%'''||
 ||Aug 2023|| 5.64|| 7.62|| '''13.26%'''||
 ||Sep 2023|| 5.55|| 7.18|| '''12.73%'''||
 ||Oct 2023|| 5.31|| 6.87|| '''12.18%'''||
 ||Nov 2023|| 5.20|| 6.51|| '''11.71%'''||
 ||Dec 2023|| 5.08|| 6.17|| '''11.25%'''||
 ||Jan 2024|| 4.79|| 5.90|| '''10.69%'''||
 ||Feb 2024|| 4.67|| 5.54|| '''10.21%'''||
 ||Mar 2024|| 4.30|| 5.11|| '''9.41%'''||
 ||Apr 2024|| 3.80|| 4.79|| '''8.59%'''||
 ||May 2024|| 3.63|| 4.52|| '''8.15%'''||
 ||Jun 2024|| 3.46|| 4.30|| '''7.76%'''||
 ||Jul 2024|| 3.33|| 4.10|| '''7.43%'''||
 ||Aug 2024|| 3.18|| 3.90|| '''7.08%'''||
 ||Sep 2024|| 3.05|| 3.73|| '''6.78%'''||
 ||Oct 2024|| 2.93|| 3.56|| '''6.49%'''||
 ||Nov 2024|| 2.83|| 3.40|| '''6.23%'''||
 ||Dec 2024|| 2.76|| 3.26|| '''6.02%'''||
 ||Jan 2025|| 2.68|| 3.14|| '''5.82%'''||
 ||Feb 2025|| 2.63|| 3.04|| '''5.67%'''||
 ||Mar 2025|| 2.50|| 2.93|| '''5.43%'''||
 ||Apr 2025|| 2.39|| 2.77|| '''5.16%'''||
 ||May 2025|| 2.30|| 2.67|| '''4.97%'''||
 ||Jun 2025|| 2.22|| 2.56|| '''4.78%'''||
 ||Jul 2025|| 2.16|| 2.47|| '''4.63%'''||
 ||Aug 2025|| 2.11|| 2.42|| '''4.53%'''||
 ||Sep 2025|| 2.05|| 2.34|| '''4.39%'''||
 ||Oct 2025|| 1.99|| 2.26|| '''4.25%'''||
 ||Nov 2025|| 1.93|| 2.19|| '''4.12%'''||
 ||Dec 2025|| 1.87|| 2.11|| '''3.98%'''||
 ||Jan 2026|| 1.82|| 2.05|| '''3.87%'''||
 ||Feb 2026|| 1.77|| 1.99|| '''3.76%'''||
 ||Mar 2026|| 1.72|| 1.91|| '''3.63%'''||
 ||Apr 2026|| 1.68|| 1.83|| '''3.51%'''||


 For historical reasons, here are the stats for no longer supported
 versions (support removed in WP 6.6). This is not changing much and many
 are likely "abandoned" sites that are on old versions of WP. As it stands
 now, 3.43% of sites are on unsupported PHP versions, something that
 dropped 0.12% in the past month.

 ||='''Month/Year'''=||='''PHP 5.2'''=||='''PHP 5.3'''=||='''PHP
 5.4'''=||='''PHP 5.5'''=||='''PHP 5.6'''=||='''PHP 7.0'''=||='''PHP
 7.1'''=||='''Total'''=||
 ||Jan 2024|| 0.21|| 0.50|| 0.44|| 0.35|| 3.21|| 1.67|| 1.08||
 '''7.46%'''||
 ||Feb 2024|| 0.21|| 0.49|| 0.42|| 0.35|| 3.12|| 1.62|| 1.04||
 '''7.25%'''||
 ||Mar 2024|| 0.21|| 0.48|| 0.39|| 0.34|| 3.02|| 1.55|| 0.99||
 '''6.98%'''||
 ||Apr 2024|| 0.20|| 0.47|| 0.38|| 0.33|| 2.93|| 1.50|| 0.95||
 '''6.76%'''||
 ||May 2024|| 0.20|| 0.46|| 0.37|| 0.32|| 2.84|| 1.45|| 0.92||
 '''6.56%'''||
 ||Jun 2024|| 0.20|| 0.45|| 0.36|| 0.31|| 2.76|| 1.41|| 0.89||
 '''6.38%'''||
 ||Jul 2024|| 0.19|| 0.44|| 0.35|| 0.30|| 2.63|| 1.36|| 0.86||
 '''6.13%'''||
 ||Aug 2024|| 0.19|| 0.43|| 0.34|| 0.29|| 2.53|| 1.31|| 0.82||
 '''5.91%'''||
 ||Sep 2024|| 0.19|| 0.41|| 0.33|| 0.28|| 2.45|| 1.25|| 0.79||
 '''5.70%'''||
 ||Oct 2024|| 0.18|| 0.40|| 0.32|| 0.27|| 2.38|| 1.20|| 0.76||
 '''5.51%'''||
 ||Nov 2024|| 0.18|| 0.39|| 0.31|| 0.26|| 2.32|| 1.15|| 0.72||
 '''5.33%'''||
 ||Dec 2024|| 0.17|| 0.39|| 0.31|| 0.26|| 2.27|| 1.11|| 0.69||
 '''5.20%'''||
 ||Jan 2025|| 0.17|| 0.38|| 0.31|| 0.25|| 2.21|| 1.07|| 0.67||
 '''5.06%'''||
 ||Feb 2025|| 0.17|| 0.38|| 0.30|| 0.25|| 2.16|| 1.04|| 0.66||
 '''4.96%'''||
 ||Mar 2025|| 0.16|| 0.37|| 0.29|| 0.24|| 2.13|| 1.02|| 0.64||
 '''4.85%'''||
 ||Apr 2025|| 0.16|| 0.36|| 0.28|| 0.23|| 2.04|| 0.98|| 0.62||
 '''4.67%'''||
 ||May 2025|| 0.16|| 0.35|| 0.27|| 0.22|| 1.99|| 0.94|| 0.60||
 '''4.53%'''||
 ||Jun 2025|| 0.15|| 0.34|| 0.26|| 0.22|| 1.93|| 0.91|| 0.57||
 '''4.38%'''||
 ||Jul 2025|| 0.15|| 0.34|| 0.26|| 0.21|| 1.87|| 0.88|| 0.56||
 '''4.26%'''||
 ||Aug 2025|| 0.15|| 0.33|| 0.25|| 0.21|| 1.85|| 0.86|| 0.55||
 '''4.20%'''||
 ||Sep 2025|| 0.15|| 0.33|| 0.25|| 0.20|| 1.80|| 0.84|| 0.53||
 '''4.10%'''||
 ||Oct 2025|| 0.14|| 0.32|| 0.24|| 0.20|| 1.76|| 0.81|| 0.51||
 '''3.98%'''||
 ||Nov 2025|| 0.14|| 0.32|| 0.24|| 0.19|| 1.72|| 0.79|| 0.50||
 '''3.90%'''||
 ||Dec 2025|| 0.14|| 0.31|| 0.23|| 0.19|| 1.68|| 0.77|| 0.48||
 '''3.80%'''||
 ||Jan 2026|| 0.14|| 0.31|| 0.23|| 0.19|| 1.65|| 0.75|| 0.47||
 '''3.74%'''||
 ||Feb 2026|| 0.14|| 0.30|| 0.22|| 0.18|| 1.61|| 0.73|| 0.45||
 '''3.63%'''||
 ||Mar 2026|| 0.14|| 0.30|| 0.22|| 0.18|| 1.56|| 0.71|| 0.44||
 '''3.55%'''||
 ||Apr 2026|| 0.13|| 0.29|| 0.21|| 0.17|| 1.52|| 0.69|| 0.42||
 '''3.43%'''||

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62622#comment:52>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 12:30:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 12:30:28 -0000
Subject: [wp-trac] [WordPress Trac] #64298: Move the `failed-workflow`
 job logic into a reusable workflow
In-Reply-To: <051.02bd0a949a9deb60d0688818a1bb25df@wordpress.org>
References: <051.02bd0a949a9deb60d0688818a1bb25df@wordpress.org>
Message-ID: <066.e12c4e1cd8bb286af18a48cce03559bc@wordpress.org>

#64298: Move the `failed-workflow` job logic into a reusable workflow
--------------------------------------+-----------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  enhancement               |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.1
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  good-first-bug has-patch  |     Focuses:
--------------------------------------+-----------------------
Changes (by desrosj):

 * keywords:  good-first-bug => good-first-bug has-patch
 * milestone:  Future Release => 7.1


Comment:

 Hi @bsetiawan88,

 Could you please open a pull request against WordPress/wordpress-develop
 on GitHub? That will help validate that the workflow files are valid after
 applying the patch on this ticket. You'll find some
 [https://make.wordpress.org/core/handbook/contribute/git/github-pull-
 requests-for-code-review/ guidance around how to contribute using GitHub
 in the Core Gandbook].

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64298#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 14:37:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 14:37:07 -0000
Subject: [wp-trac] [WordPress Trac] #65011: Deleting an administrator -
 reassign content function
Message-ID: <056.b85a7632102cc144f289c1ddf3342e95@wordpress.org>

#65011: Deleting an administrator - reassign content function
--------------------------------+-----------------------------
 Reporter:  witchblade32        |      Owner:  (none)
     Type:  feature request     |     Status:  new
 Priority:  normal              |  Milestone:  Awaiting Review
Component:  Users               |    Version:
 Severity:  minor               |   Keywords:
  Focuses:  ui, administration  |
--------------------------------+-----------------------------
 When deleting an administrator, the user is promoted to assign all posts
 to another user. on membership and ecommerce sites, the number of users
 can be high, and the select box slow to load.

 it would be ideal if there was either a search capability to find and
 select the user, or the list did not include roles that are ready only
 (subscribers, customers, custom member roles).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65011>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 14:45:47 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 14:45:47 -0000
Subject: [wp-trac] [WordPress Trac] #64930: "Restore This Autosave"
 button misalignment
In-Reply-To: <053.4471d05b604b27273f0e1a80ece43ace@wordpress.org>
References: <053.4471d05b604b27273f0e1a80ece43ace@wordpress.org>
Message-ID: <068.dff112424b15530bd2c130c07f250c96@wordpress.org>

#64930: "Restore This Autosave" button misalignment
--------------------------+------------------------------
 Reporter:  Presskopp     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  ui
--------------------------+------------------------------
Changes (by kapilpaul):

 * keywords:  has-patch =>


Comment:

 I can reproduce the issue and have added a fix for that. below is a
 screenshot of fixed issue

 [[Image(https://i.ibb.co/d0zTp07W/Screenshot-2026-04-01-at-3-44-39-PM.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64930#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 14:54:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 14:54:57 -0000
Subject: [wp-trac] [WordPress Trac] #65011: Deleting an administrator -
 reassign content function
In-Reply-To: <056.b85a7632102cc144f289c1ddf3342e95@wordpress.org>
References: <056.b85a7632102cc144f289c1ddf3342e95@wordpress.org>
Message-ID: <071.cd140d4a1f082f7aaa53abf900a06742@wordpress.org>

#65011: Deleting an administrator - reassign content function
-----------------------------+---------------------------------
 Reporter:  witchblade32     |       Owner:  (none)
     Type:  feature request  |      Status:  closed
 Priority:  normal           |   Milestone:
Component:  Users            |     Version:
 Severity:  minor            |  Resolution:  duplicate
 Keywords:                   |     Focuses:  ui, administration
-----------------------------+---------------------------------
Changes (by swissspidy):

 * status:  new => closed
 * resolution:   => duplicate
 * milestone:  Awaiting Review =>


Comment:

 Hi there and welcome to Trac!

 We're already tracking this in #19867

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65011#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 14:57:04 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 14:57:04 -0000
Subject: [wp-trac] [WordPress Trac] #65002: Connectors: Replace
 plugin.slug with plugin.file and harden plugin data handling
In-Reply-To: <060.a8d38794450573f71fbec1ec7c7a0f56@wordpress.org>
References: <060.a8d38794450573f71fbec1ec7c7a0f56@wordpress.org>
Message-ID: <075.ec0f159ce105399368431f9f619c732f@wordpress.org>

#65002: Connectors: Replace plugin.slug with plugin.file and harden plugin data
handling
-------------------------------------------------+-------------------------
 Reporter:  jorgefilipecosta                     |       Owner:
                                                 |  jorgefilipecosta
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  General                              |     Version:  trunk
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests dev-        |     Focuses:
  reviewed                                       |
-------------------------------------------------+-------------------------
Changes (by jorgefilipecosta):

 * owner:  (none) => jorgefilipecosta
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62192" 62192]:
 {{{
 #!CommitTicketReference repository="" revision="62192"
 Connectors: Replace `plugin.slug` with `plugin.file` in connector
 registration.

 Use the plugin's main file path relative to the plugins directory
 (e.g. `akismet/akismet.php` or `hello.php`) instead of the WordPress.org
 slug
 to identify a connector's associated plugin.
 This lets `_wp_connectors_get_connector_script_module_data()` check plugin
 status with `file_exists()` and `is_plugin_active()` directly, removing
 the
 `get_plugins()` slug-to-file mapping that was previously needed.

 Props jorgefilipecosta, mukesh27, gziolo.
 Fixes #65002.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65002#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 15:17:27 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 15:17:27 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet Anti-Spam
 as a connector
Message-ID: <060.46689c302968272609f7f5709dd06b43@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-----------------------------------
 Reporter:  jorgefilipecosta  |      Owner:  (none)
     Type:  defect (bug)      |     Status:  new
 Priority:  normal            |  Milestone:  Awaiting Review
Component:  General           |    Version:  trunk
 Severity:  normal            |   Keywords:  has-patch 2nd-opinion
  Focuses:                    |
------------------------------+-----------------------------------
 Akismet comes with core but the connectors screen was not showing akismet
 even if akismet was on the file system. This PR fixes the issue.
 Registers Akismet Anti-Spam as a built-in non-AI connector with
 `spam_filtering` type on the Connectors screen.


 Core PR: [https://github.com/WordPress/wordpress-develop/pull/11399
 #11399].

 == What This Changes ==

 Registers Akismet Anti-Spam as a default connector in
 `_wp_connectors_register_defaults()`:

 {{{#!php
 $registry->register(
     'akismet',
     array(
         'name'           => __( 'Akismet Anti-spam' ),
         'description'    => __( 'Protect your site from spam.' ),
         'type'           => 'spam_filtering',
         'plugin'         => array(
             'file' => 'akismet/akismet.php',
         ),
         'authentication' => array(
             'method'          => 'api_key',
             'credentials_url' => 'https://akismet.com/get/',
             'setting_name'    => 'wordpress_api_key',
             'constant_name'   => 'WPCOM_API_KEY',
         ),
     )
 );
 }}}

 Key details:

  * Uses the existing `wordpress_api_key` WordPress option for API key
 storage (shared with Akismet's own settings).
  * Checks the `WPCOM_API_KEY` PHP constant for sites that define the key
 in `wp-config.php`.
  * Introduces the `spam_filtering` connector type alongside the existing
 `ai_provider` type.
  * References the plugin file as `akismet/akismet.php` for activate flows.


 == Testing Instructions ==

  1. Visit Settings → Connectors and verify the Akismet card appears when
 akismet is on the file system.
  2. Test the default activation flow.
  3. Set an Akismet key and verify it shows as connected on both the
 Connectors screen and the Akismet settings page.
  4. Set a key on the Akismet settings page and verify it is reflected on
 the Connectors screen.
  5. Set a key using `wp-config.php` via `define( 'WPCOM_API_KEY', 'your-
 key' );` and verify the Connectors screen reflects the key was set via
 constant.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 15:21:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 15:21:26 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.67ac028a81947554ee4c79528dfbe1fe@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
-----------------------------------+---------------------
 Reporter:  jorgefilipecosta       |       Owner:  (none)
     Type:  defect (bug)           |      Status:  new
 Priority:  normal                 |   Milestone:  7.0
Component:  General                |     Version:  trunk
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |     Focuses:
-----------------------------------+---------------------
Changes (by westonruter):

 * milestone:  Awaiting Review => 7.0


Comment:

 Guessing that this is supposed to ship with 7.0

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 15:24:40 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 15:24:40 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.c535c36cd01dd7f3e91cedf3b6b4865d@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------------+------------------------------
 Reporter:  jorgefilipecosta        |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  General                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-reviewed  |     Focuses:
------------------------------------+------------------------------
Changes (by gziolo):

 * keywords:  has-patch 2nd-opinion => has-patch dev-reviewed
 * milestone:  7.0 => Awaiting Review


Comment:

 I reviewed the changes.

 @matveb, this will show the Akimset card on the Connectors screen on every
 WP instance for now. However, we will follow up with the removing in the
 UI the card when the WP instance doesn't have the Akimset plugin bundled,
 or the user decides to remove it. In effect, when someone downloads a new
 WP instance, they will see the Akismet card with the activation button.

 @westonruter, based on the earlier 7.0 planning, it should ship with the
 current release.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 15:26:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 15:26:29 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.c09a32552a4f93f8ca9006f3fdbe8104@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------------+---------------------
 Reporter:  jorgefilipecosta        |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-reviewed  |     Focuses:
------------------------------------+---------------------
Changes (by gziolo):

 * milestone:  Awaiting Review => 7.0


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 15:34:59 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 15:34:59 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.1eff8961f91c636d1900ca38e38361e2@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------------+---------------------
 Reporter:  jorgefilipecosta        |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-reviewed  |     Focuses:
------------------------------------+---------------------

Comment (by jorbin):

 > I reviewed the changes.

 What changes? There is no PR attached to this ticket.


 > Checks the WPCOM_API_KEY PHP constant for sites that define the key in
 wp-config.php.

 As this is wordpress**.org**, I'm a bit concerned about introducing a
 `WPCOM` prefixed constant.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 15:53:32 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 15:53:32 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.8a25588fef21d5f2f2fdf8d42f36fa48@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
-------------------------------------------------+-------------------------
 Reporter:  jorgefilipecosta                     |       Owner:
                                                 |  jorgefilipecosta
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  General                              |     Version:  trunk
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch dev-reviewed has-unit-     |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------
Changes (by jorgefilipecosta):

 * owner:  (none) => jorgefilipecosta
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62193" 62193]:
 {{{
 #!CommitTicketReference repository="" revision="62193"
 Fix: Register Akismet Anti-Spam as a connector.

 Akismet comes with core but the connectors screen was not showing akismet
 even if akismet was on the file system. This commit fixes the issue.

 Props jorgefilipecosta, bluefuton, gziolo.
 Fixes #65012.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 15:56:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 15:56:17 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.a6f539aef7041375184e3104f2e75c9c@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
-------------------------------------------------+-------------------------
 Reporter:  jorgefilipecosta                     |       Owner:
                                                 |  jorgefilipecosta
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  General                              |     Version:  trunk
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch dev-reviewed has-unit-     |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------

Comment (by jorgefilipecosta):

 > I reviewed the changes.

 > What changes? There is no PR attached to this ticket.

 The PR in question was https://github.com/WordPress/wordpress-
 develop/pull/11399, it was being referenced on the description.

 > Checks the WPCOM_API_KEY PHP constant for sites that define the key in
 wp-config.php.

 > As this is wordpress.org, I'm a bit concerned about introducing a WPCOM
 prefixed constant.

 The plugin was already using WPCOM_API_KEY as the constant it is not
 different that the fact that you can use define( 'ANTHROPIC_API_KEY',
 '...' ) to define ANTHROPIC key, or define( 'GOOGLE_API_KEY', '...' ) to
 define a key for google.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 16:00:58 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 16:00:58 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.9c27877415a071c440ae974bf55da895@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
-------------------------------------------------+-------------------------
 Reporter:  jorgefilipecosta                     |       Owner:
                                                 |  jorgefilipecosta
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  General                              |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch dev-reviewed has-unit-     |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------
Changes (by westonruter):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 @jorgefilipecosta For the `setting_name`, it doesn't seem
 `'wordpress_api_key'` is correct. Shouldn't it be `'akismet_api_key'`? Or
 at least, `'wpcom_api_key'`/`'wordpresscom_api_key'`?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 16:02:00 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 16:02:00 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.631e2978220cda7646b8a43e345b8baa@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
-------------------------------------------------+-------------------------
 Reporter:  jorgefilipecosta                     |       Owner:
                                                 |  jorgefilipecosta
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  General                              |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch dev-reviewed has-unit-     |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------

Comment (by jorgefilipecosta):

 Replying to [comment:8 westonruter]:
 > @jorgefilipecosta For the `setting_name`, it doesn't seem
 `'wordpress_api_key'` is correct. Shouldn't it be `'akismet_api_key'`? Or
 at least, `'wpcom_api_key'`/`'wordpresscom_api_key'`?

 It is wordpress_api_key, it was what akismet also uses to store the key as
 the option name.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 16:03:32 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 16:03:32 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.76c0c2fb36b247cb8371fa0bafbf0290@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
-------------------------------------------------+-------------------------
 Reporter:  jorgefilipecosta                     |       Owner:
                                                 |  jorgefilipecosta
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  General                              |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch dev-reviewed has-unit-     |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------

Comment (by westonruter):

 That's unfortunate naming.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 16:07:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 16:07:03 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.30e7ad731292388ce662eee992e2bee8@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
-------------------------------------------------+-------------------------
 Reporter:  jorgefilipecosta                     |       Owner:
                                                 |  jorgefilipecosta
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  General                              |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch dev-reviewed has-unit-     |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------

Comment (by gziolo):

 https://github.com/WordPress/gutenberg/pull/76962 – related changes to
 hide the Akismet card when the plugin is not present in the plugins
 directory (not bundled / removed case).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 16:38:04 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 16:38:04 -0000
Subject: [wp-trac] [WordPress Trac] #64957: Connectors:
 `WP_Connector_Registry::register()` ignores custom `setting_name`
In-Reply-To: <060.efba94ef2ed1670ece3ced63ea3ce35e@wordpress.org>
References: <060.efba94ef2ed1670ece3ced63ea3ce35e@wordpress.org>
Message-ID: <075.db521509cbe5bd3a700338404d724a0a@wordpress.org>

#64957: Connectors: `WP_Connector_Registry::register()` ignores custom
`setting_name`
-------------------------------------------------+-------------------------
 Reporter:  jorgefilipecosta                     |       Owner:
                                                 |  jorgefilipecosta
     Type:  defect (bug)                         |      Status:  closed
 Priority:  high                                 |   Milestone:  7.0
Component:  General                              |     Version:  trunk
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch dev-reviewed has-unit-     |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------
Changes (by jorgefilipecosta):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62194" 62194]:
 {{{
 #!CommitTicketReference repository="" revision="62194"
 Connectors: Fix and generalize the API for custom connector types.

 Validate `setting_name`, `constant_name`, and `env_var_name` in connector
 registration — reject invalid values with `_doing_it_wrong()` instead of
 silently falling back.
 Change the auto-generated `setting_name` pattern from
 `connectors_ai_{$id}_api_key` to `connectors_{$type}_{$id}_api_key` so it
 works for any connector type. Built-in AI providers infer their names
 using
 the existing `connectors_ai_{$id}_api_key` convention, preserving backward
 compatibility.
 Add `constant_name` and `env_var_name` as optional authentication fields,
 allowing connectors to declare explicit PHP constant and environment
 variable names for API key lookup. AI providers auto-generate these using
 the `{CONSTANT_CASE_ID}_API_KEY` convention.
 Refactor `_wp_connectors_get_api_key_source()` to accept explicit
 `env_var_name` and `constant_name` parameters instead of deriving them
 from
 the provider ID. Environment variable and constant checks are skipped when
 not provided.
 Generalize REST dispatch, settings registration, and script module data to
 work with all connector types, not just `ai_provider`. Settings
 registration skips already-registered settings. Non-AI connectors
 determine
 `isConnected` based on key source.
 Replace `isInstalled` with `pluginFile` in script module data output to
 fix
 plugin entity ID resolution on the frontend.
 Update PHPDoc to reflect current behavior — widen `type` from literal
 `'ai_provider'` to `non-empty-string`, document new authentication fields,
 and use Anthropic examples throughout.

 Props gziolo, jorgefilipecosta.
 Fixes #64957.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64957#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 16:41:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 16:41:56 -0000
Subject: [wp-trac] [WordPress Trac] #65002: Connectors: Replace
 plugin.slug with plugin.file and harden plugin data handling
In-Reply-To: <060.a8d38794450573f71fbec1ec7c7a0f56@wordpress.org>
References: <060.a8d38794450573f71fbec1ec7c7a0f56@wordpress.org>
Message-ID: <075.87464aa695b8c7ca904e299cfcf6c21f@wordpress.org>

#65002: Connectors: Replace plugin.slug with plugin.file and harden plugin data
handling
-------------------------------------------------+-------------------------
 Reporter:  jorgefilipecosta                     |       Owner:
                                                 |  jorgefilipecosta
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  General                              |     Version:  trunk
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests dev-        |     Focuses:
  reviewed                                       |
-------------------------------------------------+-------------------------

Comment (by jorgefilipecosta):

 In [changeset:"62195" 62195]:
 {{{
 #!CommitTicketReference repository="" revision="62195"
 Connectors: Replace plugin.slug with plugin.file in connector
 registration.

 Use the plugin's main file path relative to the plugins directory
 (e.g. `akismet/akismet.php` or `hello.php`) instead of the WordPress.org
 slug
 to identify a connector's associated plugin.
 This lets `_wp_connectors_get_connector_script_module_data()` check plugin
 status with `file_exists()` and `is_plugin_active()` directly, removing
 the
 `get_plugins()` slug-to-file mapping that was previously needed.

 Props jorgefilipecosta, mukesh27, gziolo.
 Fixes #65002.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65002#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 18:07:10 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 18:07:10 -0000
Subject: [wp-trac] [WordPress Trac] #65003: next/prev for enlarged image
 needs context
In-Reply-To: <052.b63525ba9b3238159791aa05ff965555@wordpress.org>
References: <052.b63525ba9b3238159791aa05ff965555@wordpress.org>
Message-ID: <067.cc1195a8f6130cc90a857c09cb61fcc6@wordpress.org>

#65003: next/prev for enlarged image needs context
--------------------------+---------------------
 Reporter:  timse201      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  I18N          |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+---------------------

Comment (by shailu25):

 Created PR in Gutenberg [https://github.com/WordPress/gutenberg/pull/76967
 #76967]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65003#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 19:39:11 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 19:39:11 -0000
Subject: [wp-trac] [WordPress Trac] #64696: Real time collboration
 effectively disables persistent post caches while anyone edits a post
In-Reply-To: <057.05b7879d9d7300bfeccbd48dcfe7237b@wordpress.org>
References: <057.05b7879d9d7300bfeccbd48dcfe7237b@wordpress.org>
Message-ID: <072.023690c2e67d7e8ec2efebbfa0ebbb33@wordpress.org>

#64696: Real time collboration effectively disables persistent post caches while
anyone edits a post
--------------------------------------+--------------------------
 Reporter:  peterwilsoncc             |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Posts, Post Types         |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+--------------------------

Comment (by spacedmonkey):

 Sorry if I’m a bit late to this discussion. Since I worked on the WP_Query
 caching, I wanted to add a thought.

 If the concern is post meta invalidating caches, I think there’s a more
 targeted approach we could take.

 At the moment, we invalidate the entire post cache group whenever post
 meta is updated, which has always felt quite wasteful. In practice, post
 meta changes only matter for queries that actually join against the post
 meta table.

 Instead, we could introduce a separate “last changed” value specifically
 for post meta (and potentially other meta types in future). We would then
 only include this in the cache key when the query performs a join on the
 post meta table. For all other queries, the existing post “last changed”
 value should remain sufficient.

 I put together POC PR of this idea [https://github.com/WordPress
 /wordpress-develop/pull/11427 here].

 Would be interested to hear your thoughts on this.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64696#comment:141>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 20:59:27 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 20:59:27 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.5d10c0129a72b3db66f495b8ec7b1eaf@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
-------------------------------------------------+-------------------------
 Reporter:  jorgefilipecosta                     |       Owner:
                                                 |  jorgefilipecosta
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  General                              |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch dev-reviewed has-unit-     |     Focuses:
  tests close                                    |
-------------------------------------------------+-------------------------
Changes (by peterwilsoncc):

 * keywords:  has-patch dev-reviewed has-unit-tests => has-patch dev-
     reviewed has-unit-tests close


Comment:

 I think Akismet API registration belongs in the plugin, per
 [https://make.wordpress.org/core/2026/02/03/proposal-for-merging-wp-ai-
 client-into-wordpress-7-0/#comment-48384 Matt's comment on the AI client
 merbe proposal]:

 > Akismet (and other plugins) should register their keys to be on this
 page, so instead of users having to go around a bunch of different menu
 areas there is one place for all of this. A single page where you can see
 all the things your WordPress is connected to. Premium plugins could also
 register on this screen.

 Akismet can easily be removed from an install and replaced by another
 anti-spam solution. Some of which also require an API key.

 If the requirement is for other plugins to register their own key, the
 same should apply for Akismet.

 r62193 should be reverted asap.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 21:41:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 21:41:22 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.0de6734389588ba9b6bba7c2a1954682@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  General           |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+-------------------------------
Changes (by peterwilsoncc):

 * keywords:  has-patch dev-reviewed has-unit-tests close => has-patch


Comment:

 Removing keywords, including the one I accidentally added myself.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 21:51:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 21:51:39 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.dcac56e6c7bd52385ac2f8b31f1aed7f@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  General           |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+-------------------------------

Comment (by jorbin):

 I agree with reverting though I think it might only need to be temporary.
 Before any additional connectors are added, I think there is a need to
 have some guidelines that are agreed up and published on make/core for
 what connectors need in order to ship with core.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 22:02:27 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 22:02:27 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2365009=3A_Privacy=3A_?=
 =?utf-8?q?=E2=80=9DCopied!=E2=80=9D_text_is_misaligned?=
In-Reply-To: <053.5ad09e193f9b440670b51501b1539f2b@wordpress.org>
References: <053.5ad09e193f9b440670b51501b1539f2b@wordpress.org>
Message-ID: <068.894f1113f56c18d290ac684d4e2bfbfd@wordpress.org>

#65009: Privacy: ”Copied!” text is misaligned
------------------------------------+-----------------------
 Reporter:  wildworks               |       Owner:  mukesh27
     Type:  defect (bug)            |      Status:  closed
 Priority:  normal                  |   Milestone:  7.0
Component:  Privacy                 |     Version:
 Severity:  normal                  |  Resolution:  fixed
 Keywords:  admin-reskin has-patch  |     Focuses:
------------------------------------+-----------------------
Changes (by SergeyBiryukov):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62196" 62196]:
 {{{
 #!CommitTicketReference repository="" revision="62196"
 Admin Reskin: Correct ”Copied!” text alignment on Privacy Policy Guide
 screen.

 Follow-up to [61645].

 Props mukesh27, wildworks, audrasjb, shailu25, anupkankale, kapilpaul,
 SergeyBiryukov.
 Fixes #65009.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65009#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 22:03:02 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 22:03:02 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2365009=3A_Privacy=3A_?=
 =?utf-8?q?=E2=80=9DCopied!=E2=80=9D_text_is_misaligned?=
In-Reply-To: <053.5ad09e193f9b440670b51501b1539f2b@wordpress.org>
References: <053.5ad09e193f9b440670b51501b1539f2b@wordpress.org>
Message-ID: <068.45855b5a5dfe92d90579c67ef95c23be@wordpress.org>

#65009: Privacy: ”Copied!” text is misaligned
------------------------------------+-----------------------
 Reporter:  wildworks               |       Owner:  mukesh27
     Type:  defect (bug)            |      Status:  reopened
 Priority:  normal                  |   Milestone:  7.0
Component:  Privacy                 |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  admin-reskin has-patch  |     Focuses:
------------------------------------+-----------------------
Changes (by SergeyBiryukov):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Reopening for 7.0 consideration.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65009#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 22:03:37 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 22:03:37 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2365009=3A_Privacy=3A_?=
 =?utf-8?q?=E2=80=9DCopied!=E2=80=9D_text_is_misaligned?=
In-Reply-To: <053.5ad09e193f9b440670b51501b1539f2b@wordpress.org>
References: <053.5ad09e193f9b440670b51501b1539f2b@wordpress.org>
Message-ID: <068.49e13e492c61e6ae7d44dc0be18e479a@wordpress.org>

#65009: Privacy: ”Copied!” text is misaligned
-------------------------------------------------+-------------------------
 Reporter:  wildworks                            |       Owner:  mukesh27
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Privacy                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch commit dev-   |     Focuses:
  feedback                                       |
-------------------------------------------------+-------------------------
Changes (by SergeyBiryukov):

 * keywords:  admin-reskin has-patch => admin-reskin has-patch commit dev-
     feedback


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65009#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 22:08:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 22:08:53 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.559013f7dc1944b8eb7ddc566ad70442@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  General           |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+-------------------------------

Comment (by davidbaumwald):

 Agree that this should be reverted.  Akismet should register its connector
 via `wp_connectors_init`.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:17>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 22:14:42 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 22:14:42 -0000
Subject: [wp-trac] [WordPress Trac] #64975: Admin reskin: Vertical
 alignment of list pagination is off
In-Reply-To: <052.e06d36d29201146d7b9d2ef4dabf6a60@wordpress.org>
References: <052.e06d36d29201146d7b9d2ef4dabf6a60@wordpress.org>
Message-ID: <067.dc9c94909a88ff1d0ba43927070c672d@wordpress.org>

#64975: Admin reskin: Vertical alignment of list pagination is off
-------------------------------------------------+-------------------------
 Reporter:  TobiasBg                             |       Owner:
                                                 |  SergeyBiryukov
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  admin-reskin has-patch commit dev-   |     Focuses:
  reviewed                                       |
-------------------------------------------------+-------------------------
Changes (by SergeyBiryukov):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62197" 62197]:
 {{{
 #!CommitTicketReference repository="" revision="62197"
 Admin Reskin: Correct vertical alignment of pagination elements in list
 tables.

 Follow-up to [61645].

 Reviewed by audrasjb, SergeyBiryukov.
 Merges [62182] to the 7.0 branch.

 Props TobiasBg, rcorrales, opurockey, rahultank, SergeyBiryukov.
 Fixes #64975.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64975#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 22:41:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 22:41:29 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.76049160bee650342467ae3132150b99@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  General           |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+-------------------------------

Comment (by jorgefilipecosta):

 For now, Akismet cannot register its own connector that appears on the
 connectors screen before the plugin is activated. This commit includes the
 required metadata so the connector appears before activation, just like
 OpenAI, Anthropic, and Google. For OpenAI, Anthropic, and Google they even
 appear before installation which is not the case for akismet. This change
 was discussed with the release lead @matveb.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:18>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 22:50:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 22:50:44 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.6de057eed1a7944e0dbdb2753b72ebb9@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  General           |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+-------------------------------

Comment (by jorgefilipecosta):

 The long-term ideal solution is making sure all plugins in the filesystem
 that have connectors appear on the connectors screen even when not active
 and allow their activation from there, but that is something that needs
 additional thought and will require bigger changes. Meanwhile, this
 solution works and it is not different from what we do for the AI
 providers.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:19>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  1 22:59:40 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 01 Apr 2026 22:59:40 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.3520fed0972f9823b1ad9e5e7ee234d1@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  General           |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+-------------------------------

Comment (by peterwilsoncc):

 Replying to [comment:18 jorgefilipecosta]:
 > For now, Akismet cannot register its own connector that appears on the
 connectors screen before the plugin is activated. This commit includes the
 required metadata so the connector appears before activation, just like
 OpenAI, Anthropic, and Google.For OpenAI, Anthropic, and Google they even
 appear before installation which is not the case for Akismet.

 That's my point, without the plugin being active the Akismet plugin does
 not serve a purpose. As the AI connectors are designed to be shared
 between various plugins. The Akismet API key serves a purpose exclusively
 for a single plugin.



 The [https://wordpress.org/plugins/opengraph-xyz/ OpenGraph.xyz],
 [https://wordpress.org/plugins/magic-api-email/ Magic API Email] and
 [https://wordpress.org/plugins/transleti-connector/ TransLeti Connector]
 plugins all require API keys, are there plans to go through the plugin
 directory and add connectors for all plugins that require a key?

 > This change was discussed with the release lead @matveb.

 Where was this discussed? Like the AI client connectors, the wider
 contributor group should have had a chance to discuss this.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:20>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 00:01:50 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 00:01:50 -0000
Subject: [wp-trac] [WordPress Trac] #64298: Move the `failed-workflow`
 job logic into a reusable workflow
In-Reply-To: <051.02bd0a949a9deb60d0688818a1bb25df@wordpress.org>
References: <051.02bd0a949a9deb60d0688818a1bb25df@wordpress.org>
Message-ID: <066.114474297053d8dbe4fc604a81a83a8a@wordpress.org>

#64298: Move the `failed-workflow` job logic into a reusable workflow
--------------------------------------+-----------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  enhancement               |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.1
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  good-first-bug has-patch  |     Focuses:
--------------------------------------+-----------------------

Comment (by johnbillion):

 Alternate approach: https://github.com/WordPress/wordpress-
 develop/pull/11349. Needs testing on a separate repo because it only fires
 when the workflow is present in the default branch.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64298#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 00:20:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 00:20:22 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.b88ac698c5fa742078730a3f8c4f4e60@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  General           |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+-------------------------------

Comment (by desrosj):

 I commented on the PR already because I saw that discussion first. But
 just to respond to a few points I did not see specifically called out on
 the PR's discussion.

 Replying to [comment:19 jorgefilipecosta]:
 > The long-term ideal solution is making sure all plugins in the
 filesystem that have connectors appear on the connectors screen even when
 not active and allow their activation from there, but that is something
 that needs additional thought and will require bigger changes.

 I strongly disagree that this is the ideal solution here. This will be not
 only be abused by plugins rendering the Connectors page essentially
 useless (all you need is to be installed, and you can bug the site owner
 to reactivate and renew forever on this page). It will most certainly also
 be a vulnerability gold mine.

 > Meanwhile, this solution works and it is not different from what we do
 for the AI providers.

 I am of the opinion that it ''should'' be different. The AI connectors
 have a specific purpose that the project is trying to champion by
 empowering users with the tools they need to be successful in an
 increasingly AI world. If it were up to me, the two groups would be `AI
 connectors`, and `API Keys` or `Everything Else`.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:22>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 00:41:25 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 00:41:25 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.77bf0c6178d59ca6f9244c35e90e7908@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  General           |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+-------------------------------
Changes (by peterwilsoncc):

 * Attachment "Screenshot 2026-04-02 at 11.41.02 am.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 00:44:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 00:44:12 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.339b68544fbc1f1ed8e855822179e190@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  General           |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+-------------------------------

Comment (by peterwilsoncc):

 Looking in to this further, I've noticed that the
 [https://plugins.trac.wordpress.org/browser/akismet/trunk plugin's
 development version] already includes a connector, as
 [https://wordpress.slack.com/archives/C08TJ8BPULS/p1772731407708539 posted
 in Slack last month], so this definitely needs to be reverted in order
 that WordPress users don't end up with two Akismet connectors in the
 settings.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:23>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 01:24:02 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 01:24:02 -0000
Subject: [wp-trac] [WordPress Trac] #64890: Harden
 `WP_HTTP_Polling_Sync_Server` endpoint
In-Reply-To: <051.0abc1ef2f98aca960470eea117eafa49@wordpress.org>
References: <051.0abc1ef2f98aca960470eea117eafa49@wordpress.org>
Message-ID: <066.655a0702391fa97aa53162a41dc7ce27@wordpress.org>

#64890: Harden `WP_HTTP_Polling_Sync_Server` endpoint
--------------------------+----------------------------
 Reporter:  czarate       |       Owner:  peterwilsoncc
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:  7.0
Component:  REST API      |     Version:  trunk
 Severity:  normal        |  Resolution:  fixed
 Keywords:  has-patch     |     Focuses:
--------------------------+----------------------------
Changes (by peterwilsoncc):

 * owner:  (none) => peterwilsoncc
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62198" 62198]:
 {{{
 #!CommitTicketReference repository="" revision="62198"
 REST API: Harden Real Time Collaboration endpoint.

 Adds additional validation and permission checks the the Real Time
 Collaboration endpoint to ensure only input in the expected format is
 supported.

 Props czarate, westonruter, joefusco.
 Fixes #64890.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64890#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 01:25:04 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 01:25:04 -0000
Subject: [wp-trac] [WordPress Trac] #64890: Harden
 `WP_HTTP_Polling_Sync_Server` endpoint
In-Reply-To: <051.0abc1ef2f98aca960470eea117eafa49@wordpress.org>
References: <051.0abc1ef2f98aca960470eea117eafa49@wordpress.org>
Message-ID: <066.8fd531122ee943fc20dcaab8547b30e9@wordpress.org>

#64890: Harden `WP_HTTP_Polling_Sync_Server` endpoint
------------------------------------+----------------------------
 Reporter:  czarate                 |       Owner:  peterwilsoncc
     Type:  defect (bug)            |      Status:  reopened
 Priority:  normal                  |   Milestone:  7.0
Component:  REST API                |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:
------------------------------------+----------------------------
Changes (by peterwilsoncc):

 * keywords:  has-patch => has-patch dev-feedback
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Reopening for merge consideration to the 7.0 branch pending another
 committers sign off.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64890#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 04:48:46 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 04:48:46 -0000
Subject: [wp-trac] [WordPress Trac] #64926: REST API: GET requests fail
 object/array schema validation when params are JSON-serialized strings
In-Reply-To: <048.09e4f6945084c0394353ff269647c101@wordpress.org>
References: <048.09e4f6945084c0394353ff269647c101@wordpress.org>
Message-ID: <063.9369be733174cc714f491fd49925d682@wordpress.org>

#64926: REST API: GET requests fail object/array schema validation when params are
JSON-serialized strings
-------------------------+-------------------------------------------------
 Reporter:  dsmy         |       Owner:  (none)
     Type:  defect       |      Status:  new
  (bug)                  |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  REST API     |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  javascript, rest-api, php-
                         |  compatibility
-------------------------+-------------------------------------------------

Comment (by liaison):

 Replying to [comment:21 abcd95]:
 > IMO, placing the decode at the top of the function misses `anyOf/oneOf`
 schemas with no top-level type, and the $type resolves to `''` and the
 block is skipped on the initial call. It only works because recursive
 calls from rest_find_any_matching_schema() re-enter with the sub-schema's
 type set.
 >
 > Moving the decode inside the switch (validation) and before
 rest_sanitize_array()/rest_sanitize_object() (sanitization) ensures it
 fires after type resolution, regardless of schema.

 Thanks @abcd95. The assessment is correct. Moving the decoding logic after
 the type resolution ensures full compatibility with schemas that rely
 solely on anyOf or oneOf without a top-level type declaration.
 {{{#!php
 <?php
 function rest_sanitize_value_from_schema( $value, $args, $param = '' ) {
 ...
    if ( 'array' === $args['type'] ) {
         if ( is_string( $value ) ) {
             $trimmed_value = trim( $value );
             if ( str_starts_with( $trimmed_value, '[' ) ) {
                 $decoded = json_decode( $value, true );
                 if ( json_last_error() === JSON_ERROR_NONE ) {
                     $value = $decoded;
                 }
             }
         }

         $value = rest_sanitize_array( $value );

     ...
     }

     if ( 'object' === $args['type'] ) {
         if ( is_string( $value ) ) {
             $trimmed_value = trim( $value );
             if ( str_starts_with( $trimmed_value, '{' ) ) {
                 $decoded = json_decode( $value, true );
                 if ( json_last_error() === JSON_ERROR_NONE ) {
                     $value = $decoded;
                 }
             }
         }

         $value = rest_sanitize_object( $value );
         ....
     }
 ...
 }

 function rest_validate_value_from_schema( $value, $args, $param = '' ) {
 ...
                 case 'object':
                         if ( is_string( $value ) ) {
                                 $trimmed_value = trim( $value );
                                 if ( str_starts_with( $trimmed_value, '{'
 ) ) {
                                         $decoded = json_decode( $value,
 true );
                                         if ( json_last_error() ===
 JSON_ERROR_NONE ) {
                                                 $value = $decoded;
                                         }
                                 }
                         }
                         $is_valid =
 rest_validate_object_value_from_schema( $value, $args, $param );
                         break;
                 case 'array':
                         if ( is_string( $value ) ) {
                                 $trimmed_value = trim( $value );
                                 if ( str_starts_with( $trimmed_value, '['
 ) ) {
                                         $decoded = json_decode( $value,
 true );
                                         if ( json_last_error() ===
 JSON_ERROR_NONE ) {
                                                 $value = $decoded;
                                         }
                                 }
                         }
                         $is_valid = rest_validate_array_value_from_schema(
 $value, $args, $param );
                         break;
 ...
 }

 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64926#comment:22>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 06:15:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 06:15:28 -0000
Subject: [wp-trac] [WordPress Trac] #64956: Unnecessary horizontal
 scrollbar on theme-editor.php in WordPress 7.0 RC1
In-Reply-To: <054.5eefe006b265ff88e64c3a86674d6e92@wordpress.org>
References: <054.5eefe006b265ff88e64c3a86674d6e92@wordpress.org>
Message-ID: <069.175905863dc1a43b3692bf8f00ca5ad4@wordpress.org>

#64956: Unnecessary horizontal scrollbar on theme-editor.php in WordPress 7.0 RC1
-------------------------------------+-------------------------------------
 Reporter:  hardik2812               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  General                  |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-test-info needs-     |     Focuses:  ui, css,
  patch                              |  administration
-------------------------------------+-------------------------------------
Changes (by torontodigits):

 * keywords:  needs-testing => has-test-info needs-patch


Comment:

 Got a chance to test this via PlayGround by installing frresh WordPress
 RC2 & can see this issue on mobile & can replicate it on very large
 screens by Zooming it to 200%.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64956#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 06:21:19 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 06:21:19 -0000
Subject: [wp-trac] [WordPress Trac] #64956: Unnecessary horizontal
 scrollbar on theme-editor.php in WordPress 7.0 RC1
In-Reply-To: <054.5eefe006b265ff88e64c3a86674d6e92@wordpress.org>
References: <054.5eefe006b265ff88e64c3a86674d6e92@wordpress.org>
Message-ID: <069.2b5f1e19737e4eec91c389e4df73f31a@wordpress.org>

#64956: Unnecessary horizontal scrollbar on theme-editor.php in WordPress 7.0 RC1
-------------------------------------+-------------------------------------
 Reporter:  hardik2812               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  General                  |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-test-info needs-     |     Focuses:  ui, css,
  patch                              |  administration
-------------------------------------+-------------------------------------
Changes (by torontodigits):

 * Attachment "Reproduceable Issue on mobile - Ticket #64956.mp4" added.

 Reproduceable Issue on mobile - Ticket #64956

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64956>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 06:21:46 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 06:21:46 -0000
Subject: [wp-trac] [WordPress Trac] #64956: Unnecessary horizontal
 scrollbar on theme-editor.php in WordPress 7.0 RC1
In-Reply-To: <054.5eefe006b265ff88e64c3a86674d6e92@wordpress.org>
References: <054.5eefe006b265ff88e64c3a86674d6e92@wordpress.org>
Message-ID: <069.f485262e8b70a53cee9cd7cddafc3836@wordpress.org>

#64956: Unnecessary horizontal scrollbar on theme-editor.php in WordPress 7.0 RC1
-------------------------------------+-------------------------------------
 Reporter:  hardik2812               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  General                  |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-test-info needs-     |     Focuses:  ui, css,
  patch                              |  administration
-------------------------------------+-------------------------------------
Changes (by torontodigits):

 * Attachment "Reproduceable Issue - Ticket #64956.png" added.

 Reproduceable Issue on large screens - Ticket #64956

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64956>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 07:59:37 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 07:59:37 -0000
Subject: [wp-trac] [WordPress Trac] #64983: Scale needs gettext
In-Reply-To: <052.e53f02387eb408cdbc6651e425f128e1@wordpress.org>
References: <052.e53f02387eb408cdbc6651e425f128e1@wordpress.org>
Message-ID: <067.1b031130cb96cc234cacf21500db8f54@wordpress.org>

#64983: Scale needs gettext
-----------------------------------------+-----------------------
 Reporter:  timse201                     |       Owner:  audrasjb
     Type:  defect (bug)                 |      Status:  accepted
 Priority:  normal                       |   Milestone:  7.0
Component:  I18N                         |     Version:  trunk
 Severity:  normal                       |  Resolution:
 Keywords:  changes-requested has-patch  |     Focuses:
-----------------------------------------+-----------------------

Comment (by timse201):

 Too many requests. I will Look into it later.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64983#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 08:16:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 08:16:30 -0000
Subject: [wp-trac] [WordPress Trac] #65001: Hover on Upload files media
 Library tabs and drop to upload file overlay color has still old color
In-Reply-To: <053.1e9023874452fde73c1121655252bc0d@wordpress.org>
References: <053.1e9023874452fde73c1121655252bc0d@wordpress.org>
Message-ID: <068.9db3585e2c19cd23eda999aa7f40448b@wordpress.org>

#65001: Hover on Upload files media Library tabs and drop to upload file overlay
color has still old color
-----------------------------------------+----------------------------
 Reporter:  opurockey                    |       Owner:  joedolson
     Type:  defect (bug)                 |      Status:  accepted
 Priority:  normal                       |   Milestone:  7.0
Component:  Upload                       |     Version:  trunk
 Severity:  normal                       |  Resolution:
 Keywords:  has-patch changes-requested  |     Focuses:  accessibility
-----------------------------------------+----------------------------

Comment (by manhar):

 As I see and confirm, This is still use old color on hover.

 Refer the below image :

 https://postimg.cc/jLmGRgY0

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65001#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 09:12:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 09:12:48 -0000
Subject: [wp-trac] [WordPress Trac] #50486: Improve the admin notices
 accessibility
In-Reply-To: <051.24f50c50f88adad76984afde3cabc979@wordpress.org>
References: <051.24f50c50f88adad76984afde3cabc979@wordpress.org>
Message-ID: <066.9ffe9a0ccc0a8e1408a86ffb5c697cd7@wordpress.org>

#50486: Improve the admin notices accessibility
----------------------------+--------------------------------
 Reporter:  afercia         |       Owner:  joedolson
     Type:  defect (bug)    |      Status:  accepted
 Priority:  normal          |   Milestone:  7.1
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  needs-patch     |     Focuses:  ui, accessibility
----------------------------+--------------------------------

Comment (by sanket.parmar):

 Thank you for the feedback and for milestoning this for 7.1, @joedolson —
 great to have a concrete target!

 === On `<aside>` vs `<div role="complementary">` ===

 Completely agree — native HTML5 semantics are always preferable over ARIA
 role overrides. An `<aside>` with an `aria-label` gives the same landmark
 without depending on ARIA alone, and is more robust across different AT
 implementations. Happy to use that in the patch.

 === On the existing PR ===

 I had a look at [https://github.com/WordPress/wordpress-develop/pull/5225
 PR #5225] — the branch was deleted when it was closed in March 2024, so
 there's nothing to rebase from directly. That said, the PR diff is still
 visible and gives a clear picture of the direction and scope of the
 changes. My suggestion would be to start a fresh PR using the closed PR as
 a reference for which notices were covered and how they were approached,
 rather than trying to recover the old code.

  * Would you be taking the lead on that, or would it help if I put
 together a fresh PR based on what was in that old PR?
  * Are there any notices from that PR that you'd want to handle
 differently now, given the two years since it was closed?

 Happy to take on whichever part is most useful.

 === On inline / dynamic notices as a separate class ===

 This distinction makes a lot of sense. The way I read it, there would be
 two separate categories going forward:

  * '''Page-load notices''' — PHP-generated, rendered once after page load,
 covered by the landmark + skip link + title prefix approach
  * '''Dynamic/inline notices''' — JS-injected or triggered by user actions
 mid-page, each needing individual assessment, and delivering a spoken
 notification via `role="alert"` or `role="status"` depending on urgency

 The second category being treated individually is the right call given how
 varied the usages are across core. It also means the two tracks can
 progress independently without blocking each other.

 Would it make sense to open a child ticket specifically for the dynamic
 notices audit, so the two tracks can be tracked and reviewed separately?
 That would help keep this ticket focused on the page-load side and avoid
 it ballooning in scope again.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/50486#comment:46>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 09:24:37 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 09:24:37 -0000
Subject: [wp-trac] [WordPress Trac] #65001: Hover on Upload files media
 Library tabs and drop to upload file overlay color has still old color
In-Reply-To: <053.1e9023874452fde73c1121655252bc0d@wordpress.org>
References: <053.1e9023874452fde73c1121655252bc0d@wordpress.org>
Message-ID: <068.9fc973c7ed8f56d286f28bb74143c626@wordpress.org>

#65001: Hover on Upload files media Library tabs and drop to upload file overlay
color has still old color
-----------------------------------------+----------------------------
 Reporter:  opurockey                    |       Owner:  joedolson
     Type:  defect (bug)                 |      Status:  accepted
 Priority:  normal                       |   Milestone:  7.0
Component:  Upload                       |     Version:  trunk
 Severity:  normal                       |  Resolution:
 Keywords:  has-patch changes-requested  |     Focuses:  accessibility
-----------------------------------------+----------------------------

Comment (by opurockey):

 Replying to [comment:7 manhar]:
 > As I see and confirm, This is still use old color on hover.
 >
 > Refer the below image :
 >
 > https://postimg.cc/jLmGRgY0

 @manhar, Could you please pull and check that again after clearing the
 browser cache? Thanks.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65001#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 09:44:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 09:44:05 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2365009=3A_Privacy=3A_?=
 =?utf-8?q?=E2=80=9DCopied!=E2=80=9D_text_is_misaligned?=
In-Reply-To: <053.5ad09e193f9b440670b51501b1539f2b@wordpress.org>
References: <053.5ad09e193f9b440670b51501b1539f2b@wordpress.org>
Message-ID: <068.4fb91261b552c4184877a4e33ca1e524@wordpress.org>

#65009: Privacy: ”Copied!” text is misaligned
-------------------------------------------------+-------------------------
 Reporter:  wildworks                            |       Owner:  mukesh27
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Privacy                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch commit dev-   |     Focuses:
  feedback                                       |
-------------------------------------------------+-------------------------

Comment (by wildworks):

 > Reopening for 7.0 consideration.

 Approved

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65009#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 09:44:15 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 09:44:15 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2365009=3A_Privacy=3A_?=
 =?utf-8?q?=E2=80=9DCopied!=E2=80=9D_text_is_misaligned?=
In-Reply-To: <053.5ad09e193f9b440670b51501b1539f2b@wordpress.org>
References: <053.5ad09e193f9b440670b51501b1539f2b@wordpress.org>
Message-ID: <068.19b1903b1168b34d0b27bbc79ad58911@wordpress.org>

#65009: Privacy: ”Copied!” text is misaligned
-------------------------------------------------+-----------------------
 Reporter:  wildworks                            |       Owner:  mukesh27
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Privacy                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch dev-reviewed  |     Focuses:
-------------------------------------------------+-----------------------
Changes (by wildworks):

 * keywords:  admin-reskin has-patch commit dev-feedback => admin-reskin
     has-patch dev-reviewed


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65009#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 10:13:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 10:13:18 -0000
Subject: [wp-trac] [WordPress Trac] #65010: Media: The progress bar
 color is outdated
In-Reply-To: <053.19c481fcfd177ed15cdcc3946b04094c@wordpress.org>
References: <053.19c481fcfd177ed15cdcc3946b04094c@wordpress.org>
Message-ID: <068.6ce44b7a5925155e845326c7bceb13bb@wordpress.org>

#65010: Media: The progress bar color is outdated
------------------------------------+------------------------
 Reporter:  wildworks               |       Owner:  (none)
     Type:  defect (bug)            |      Status:  closed
 Priority:  normal                  |   Milestone:
Component:  Media                   |     Version:
 Severity:  normal                  |  Resolution:  duplicate
 Keywords:  admin-reskin has-patch  |     Focuses:
------------------------------------+------------------------
Changes (by wildworks):

 * status:  new => closed
 * resolution:   => duplicate
 * milestone:  7.0 =>


Comment:

 Duplicate of #65001.

 I realized that the same fix is already in progress in another ticket.

 - Tikcet: https://core.trac.wordpress.org/ticket/65001
 - PR: https://github.com/WordPress/wordpress-develop/pull/11409/changes
 #diff-
 c657d8edf83f580c59e61e205f967175fbf6e687c188e87e98221b47286c7074R1412

 I would like to close this ticket. My apologies for any confusion.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65010#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 10:13:32 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 10:13:32 -0000
Subject: [wp-trac] [WordPress Trac] #65010: Media: The progress bar
 color is outdated
In-Reply-To: <053.19c481fcfd177ed15cdcc3946b04094c@wordpress.org>
References: <053.19c481fcfd177ed15cdcc3946b04094c@wordpress.org>
Message-ID: <068.f6ab896f5aa5cb2757b47e24e2d85ffb@wordpress.org>

#65010: Media: The progress bar color is outdated
------------------------------------+------------------------
 Reporter:  wildworks               |       Owner:  (none)
     Type:  defect (bug)            |      Status:  closed
 Priority:  normal                  |   Milestone:  7.0
Component:  Media                   |     Version:
 Severity:  normal                  |  Resolution:  duplicate
 Keywords:  admin-reskin has-patch  |     Focuses:
------------------------------------+------------------------
Changes (by wildworks):

 * milestone:   => 7.0


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65010#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 10:35:11 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 10:35:11 -0000
Subject: [wp-trac] [WordPress Trac] #7965: Database upgrade complete
 message should be an admin notice
In-Reply-To: <049.fd6a94b589f8000eec76faf471b3870d@wordpress.org>
References: <049.fd6a94b589f8000eec76faf471b3870d@wordpress.org>
Message-ID: <064.a4194432318a39c960c5802e44cd2e3b@wordpress.org>

#7965: Database upgrade complete message should be an admin notice
-------------------------------------+---------------------------------
 Reporter:  westi                    |       Owner:  (none)
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Future Release
Component:  Upgrade/Install          |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-refresh  |     Focuses:  ui, administration
-------------------------------------+---------------------------------
Changes (by makdiahussain):

 * Attachment "7965.2.diff" added.

 Refreshed patch for #7965. On single-site, runs wp_upgrade() inline in
 admin.php instead of redirecting to upgrade.php. The user stays on their
 intended admin page and sees a dismissible success admin notice: "Your
 WordPress database has been successfully updated!" Multisite upgrade flow
 remains unchanged.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/7965>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 10:42:54 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 10:42:54 -0000
Subject: [wp-trac] [WordPress Trac] #7965: Database upgrade complete
 message should be an admin notice
In-Reply-To: <049.fd6a94b589f8000eec76faf471b3870d@wordpress.org>
References: <049.fd6a94b589f8000eec76faf471b3870d@wordpress.org>
Message-ID: <064.d1b09e2d21cbc0c6a52b098319b2a244@wordpress.org>

#7965: Database upgrade complete message should be an admin notice
-------------------------------------+---------------------------------
 Reporter:  westi                    |       Owner:  (none)
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Future Release
Component:  Upgrade/Install          |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  ui, administration
-------------------------------------+---------------------------------
Changes (by makdiahussain):

 * keywords:  has-patch needs-refresh => has-patch needs-testing


Comment:

 Refreshed patch based on nacin's original approach. For single-site
 installs, wp_upgrade() now runs inline in admin.php instead of redirecting
 to upgrade.php. Users land directly on their intended page with a
 dismissible success admin notice. Multisite flow is unchanged.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/7965#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 10:53:27 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 10:53:27 -0000
Subject: [wp-trac] [WordPress Trac] #64918: WP 7.0 Connectors: No models
 found that support image_generation
In-Reply-To: <051.08852fed50832f10b7d24dae2fa700ca@wordpress.org>
References: <051.08852fed50832f10b7d24dae2fa700ca@wordpress.org>
Message-ID: <066.f45dbbd9043398e1bd4840329671478b@wordpress.org>

#64918: WP 7.0 Connectors: No models found that support image_generation
--------------------------+---------------------
 Reporter:  ecairol       |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0.1
Component:  AI            |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  ai-client     |     Focuses:
--------------------------+---------------------

Comment (by iamadisingh):

 After investigating, I think this is more likely a plugin
 capability/declaration issue. With Gemini image refinement works fine.
 With OpenAI, the error shown is "No models found that support
 image_generation for this prompt," that suggests this is likely a plugin
 capability-mapping issue. The current error, “No models found that support
 image_generation for this prompt,” is probably happening because OpenAI
 provider still advertises GPT image models with text-only input.

 I opened a related issue in the AI plugin repo here:
 https://github.com/WordPress/ai/issues/363 to track improving the error
 message and clarifying provider/model capability support.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64918#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 11:11:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 11:11:12 -0000
Subject: [wp-trac] [WordPress Trac] #48656: Views details blocked by
 SAMEORIGIN
In-Reply-To: <058.72c597a7f04c1b2c4a0314e811705714@wordpress.org>
References: <058.72c597a7f04c1b2c4a0314e811705714@wordpress.org>
Message-ID: <073.1c7cfad4365563af1a6b5bb945d3bb01@wordpress.org>

#48656: Views details blocked by SAMEORIGIN
----------------------------+------------------------------
 Reporter:  sebastienserre  |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Plugins         |     Version:  5.3
 Severity:  major           |  Resolution:
 Keywords:  needs-patch     |     Focuses:  multisite
----------------------------+------------------------------
Changes (by makdiahussain):

 * Attachment "48656.diff" added.

 Skip the network admin redirect in plugin-install.php when handling an
 IFRAME_REQUEST (plugin information modal). This prevents the cross-origin
 X-Frame-Options SAMEORIGIN block that occurs on multisite subsites when
 clicking "View Details" on a plugin.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/48656>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 11:13:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 11:13:39 -0000
Subject: [wp-trac] [WordPress Trac] #48656: Views details blocked by
 SAMEORIGIN
In-Reply-To: <058.72c597a7f04c1b2c4a0314e811705714@wordpress.org>
References: <058.72c597a7f04c1b2c4a0314e811705714@wordpress.org>
Message-ID: <073.39d7a0599739c51fd67acc2795368de2@wordpress.org>

#48656: Views details blocked by SAMEORIGIN
----------------------------+------------------------------
 Reporter:  sebastienserre  |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Plugins         |     Version:  5.3
 Severity:  major           |  Resolution:
 Keywords:  has-patch       |     Focuses:  multisite
----------------------------+------------------------------
Changes (by makdiahussain):

 * keywords:  needs-patch => has-patch


Comment:

 The issue is in plugin-install.php. On multisite subsites, the redirect to
 network_admin_url() on line 22 fires even for IFRAME_REQUEST (the "View
 Details" thickbox modal). This causes a cross-origin redirect, which the
 browser blocks due to X-Frame-Options: SAMEORIGIN.

 The patch skips the network admin redirect when IFRAME_REQUEST is defined,
 so the plugin information modal loads directly on the subsite without a
 cross-origin issue. IFRAME_REQUEST is already set on line 9 when tab
 =plugin-information.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/48656#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 11:52:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 11:52:07 -0000
Subject: [wp-trac] [WordPress Trac] #64926: REST API: GET requests fail
 object/array schema validation when params are JSON-serialized strings
In-Reply-To: <048.09e4f6945084c0394353ff269647c101@wordpress.org>
References: <048.09e4f6945084c0394353ff269647c101@wordpress.org>
Message-ID: <063.92eba4846798a17b2b6818b1ec7e39f1@wordpress.org>

#64926: REST API: GET requests fail object/array schema validation when params are
JSON-serialized strings
-------------------------+-------------------------------------------------
 Reporter:  dsmy         |       Owner:  (none)
     Type:  defect       |      Status:  new
  (bug)                  |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  REST API     |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  javascript, rest-api, php-
                         |  compatibility
-------------------------+-------------------------------------------------

Comment (by abcd95):

 This is what I came up wtih -
 {{{
 diff --git a/src/wp-includes/rest-api.php b/src/wp-includes/rest-api.php
 index c524f9e22a..e62c1f2586 100644
 --- a/src/wp-includes/rest-api.php
 +++ b/src/wp-includes/rest-api.php
 @@ -2243,9 +2243,32 @@ function rest_validate_value_from_schema( $value,
 $args, $param = '' ) {
                         $is_valid =
 rest_validate_boolean_value_from_schema( $value, $param );
                         break;
                 case 'object':
 +                       /*
 +                        * A JSON-encoded string (e.g. from a GET query
 parameter) should be
 +                        * decoded before validation, mirroring what
 parse_json_params() does
 +                        * for application/json request bodies.
 +                        */
 +                       if ( is_string( $value ) ) {
 +                               $decoded = json_decode( $value, true );
 +                               if ( null !== $decoded && JSON_ERROR_NONE
 === json_last_error() ) {
 +                                       $value = $decoded;
 +                               }
 +                       }
                         $is_valid =
 rest_validate_object_value_from_schema( $value, $args, $param );
                         break;
                 case 'array':
 +                       /*
 +                        * A JSON-encoded string (e.g. ?ids=[1,2,3])
 should be decoded before
 +                        * validation. This takes priority over the comma-
 separated-value
 +                        * fallback in rest_is_array() / wp_parse_list(),
 which cannot
 +                        * preserve value types.
 +                        */
 +                       if ( is_string( $value ) && str_starts_with(
 ltrim( $value ), '[' ) ) {
 +                               $decoded = json_decode( $value, true );
 +                               if ( is_array( $decoded ) &&
 JSON_ERROR_NONE === json_last_error() ) {
 +                                       $value = $decoded;
 +                               }
 +                       }
                         $is_valid = rest_validate_array_value_from_schema(
 $value, $args, $param );
                         break;
                 case 'number':
 @@ -2833,6 +2856,19 @@ function rest_sanitize_value_from_schema( $value,
 $args, $param = '' ) {
         }

         if ( 'array' === $args['type'] ) {
 +               /*
 +                * A JSON-encoded string (e.g. ?ids=[1,2,3]) should be
 decoded before
 +                * sanitization. This takes priority over the comma-
 separated-value
 +                * fallback in rest_sanitize_array() / wp_parse_list(),
 which cannot
 +                * preserve value types.
 +                */
 +               if ( is_string( $value ) && str_starts_with( ltrim( $value
 ), '[' ) ) {
 +                       $decoded = json_decode( $value, true );
 +                       if ( is_array( $decoded ) && JSON_ERROR_NONE ===
 json_last_error() ) {
 +                               $value = $decoded;
 +                       }
 +               }
 +
                 $value = rest_sanitize_array( $value );

                 if ( ! empty( $args['items'] ) ) {
 @@ -2850,6 +2886,18 @@ function rest_sanitize_value_from_schema( $value,
 $args, $param = '' ) {
         }

         if ( 'object' === $args['type'] ) {
 +               /*
 +                * A JSON-encoded string (e.g. from a GET query parameter)
 should be
 +                * decoded before sanitization, mirroring what
 parse_json_params() does
 +                * for application/json request bodies.
 +                */
 +               if ( is_string( $value ) ) {
 +                       $decoded = json_decode( $value, true );
 +                       if ( null !== $decoded && JSON_ERROR_NONE ===
 json_last_error() ) {
 +                               $value = $decoded;
 +                       }
 +               }
 +
                 $value = rest_sanitize_object( $value );

                 foreach ( $value as $property => $v ) {
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64926#comment:23>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 12:04:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 12:04:30 -0000
Subject: [wp-trac] [WordPress Trac] #64930: "Restore This Autosave"
 button misalignment
In-Reply-To: <053.4471d05b604b27273f0e1a80ece43ace@wordpress.org>
References: <053.4471d05b604b27273f0e1a80ece43ace@wordpress.org>
Message-ID: <068.e9d975dea0228dd7b0d07e02a9e504f1@wordpress.org>

#64930: "Restore This Autosave" button misalignment
--------------------------+------------------------------
 Reporter:  Presskopp     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  ui
--------------------------+------------------------------
Changes (by mukesh27):

 * keywords:   => has-patch


Comment:

 First, can we confirm whether this issue also occurs in previous versions?
 Also, do we know if it was introduced as part of the admin reskin project
 changes?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64930#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 12:32:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 12:32:05 -0000
Subject: [wp-trac] [WordPress Trac] #12084: allow preserving HTML in
 the_excerpt (specify allowed tags for strip_tags in wp_trim_excerpt)
In-Reply-To: <053.59f2074e34c8115a47d5f8916b095de4@wordpress.org>
References: <053.59f2074e34c8115a47d5f8916b095de4@wordpress.org>
Message-ID: <068.a64b52693fe3dc3f5691a692f5b7b0e4@wordpress.org>

#12084: allow preserving HTML in the_excerpt (specify allowed tags for strip_tags
in wp_trim_excerpt)
-------------------------------------+---------------------
 Reporter:  sillybean                |       Owner:  (none)
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:
Component:  Formatting               |     Version:  3.0
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-refresh  |     Focuses:
-------------------------------------+---------------------

Comment (by abcd95):

 I think we should have a single excerpt_allowed_tags filter inside
 wp_trim_excerpt(), defaulting to `''` (strip everything — identical to
 current behaviour). When non-empty, bypass wp_trim_words(), strip only
 disallowed tags, find the word-boundary cut point on a plain-text copy,
 then run force_balance_tags() before appending the more string.

 I am working on this fix and testing some changes; the PR should be up
 shortly.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/12084#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 12:33:19 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 12:33:19 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.f46f5e105d6fcb921813ceb33d50257b@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  General           |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+-------------------------------

Comment (by manhar):

 Post locking helps prevent simultaneous edits, but it doesn’t handle
 conflicts when updates come from multiple sources like the editor, APIs,
 or background processes.

 In such cases, content can still be overwritten without clear feedback. It
 would be useful to explore better conflict detection or merging strategies
 to improve the editing experience.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:24>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 12:40:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 12:40:26 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.204c7457d0a80df4978217701086e26a@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  General           |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+-------------------------------

Comment (by jorgefilipecosta):

 Replying to [comment:20 peterwilsoncc]:
 > That's my point, without the plugin being active the Akismet key does
 not serve a purpose. As the AI connectors are designed to be shared
 between various plugins. The Akismet API key serves a purpose exclusively
 for a single plugin.

 That's a good point that is worth addressing. The UI doesn't actually
 allow setting a key without activating the plugin first. What it does is
 let users activate the plugin directly from the connectors screen, without
 needing to navigate to the plugins screen, and then provide the key right
 away without any page reloads. So by the time the key is set, the plugin
 is already active.
 The connectors screen serves as a place to configure connections to third
 parties that enhance the WordPress experience. Showing Akismet there
 provides an easy and intuitive way to activate the plugin, and it also
 reinforces the idea that the connectors screen is not exclusively for AI
 providers. And, though connectors really shine when they can be shared
 between plugins, connectors with a tighter relationship with a single
 plugin still have a place in this new central screen.

 > Where was this discussed? Like the AI client connectors, the wider
 contributor group should have had a chance to discuss this.

 We are discussing this publicly here both on Trac and GitHub and @gziolo
 also raised awareness for this discussion on the release leads slack
 channel. Everyone is welcome to share their thoughts and feedback. And I'm
 open to other alternatives/possibilities that achieve the goal of showing
 Akismet on the connectors screen before activation and that are feasible
 during the 7.0 release cycle.

 > Looking in to this further, I've noticed that the plugin's development
 version already includes a connector, as posted in Slack last month, so
 this definitely needs to be reverted in order that WordPress users don't
 end up with two Akismet connectors in the settings.

 It is fine and expected that plugins can define their register connectors.
 For instance, AI providers can overwrite the core UI to include token
 information; or akismet can overwrite the UI to show plan information. The
 connector will not appear two times. The same connector does not appear
 multiple times when registered, provided the IDs used are the same. I'm in
 touch with Akismet developers so that we're in sync. For example,
 @bluefuton had a look into related changes in the Gutenberg repo and left
 some comments; if there is any plugin incompatibility it will be addressed
 in Akismet before the 7.0 release.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:25>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 13:15:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 13:15:17 -0000
Subject: [wp-trac] [WordPress Trac] #65001: Hover on Upload files media
 Library tabs and drop to upload file overlay color has still old color
In-Reply-To: <053.1e9023874452fde73c1121655252bc0d@wordpress.org>
References: <053.1e9023874452fde73c1121655252bc0d@wordpress.org>
Message-ID: <068.def68846214259388a31364a3bf78ee6@wordpress.org>

#65001: Hover on Upload files media Library tabs and drop to upload file overlay
color has still old color
-----------------------------------------+----------------------------
 Reporter:  opurockey                    |       Owner:  joedolson
     Type:  defect (bug)                 |      Status:  accepted
 Priority:  normal                       |   Milestone:  7.0
Component:  Upload                       |     Version:  trunk
 Severity:  normal                       |  Resolution:
 Keywords:  has-patch changes-requested  |     Focuses:  accessibility
-----------------------------------------+----------------------------

Comment (by manhar):

 Replying to [comment:10 opurockey]:
 > Replying to [comment:7 manhar]:
 > > As I see and confirm, This is still use old color on hover.
 > >
 > > Refer the below image :
 > >
 > > https://postimg.cc/jLmGRgY0
 >
 > @manhar, Could you please pull and check that again after clearing the
 browser cache? Thanks.

 @opurockey Yes, it is working properly .

 Thanks for Information.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65001#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 13:39:08 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 13:39:08 -0000
Subject: [wp-trac] =?utf-8?q?=5BWordPress_Trac=5D_=2365013=3A_make=2Ewordp?=
 =?utf-8?q?ress=2Eorg/core_=E2=80=93_Site_title_=22=3C_=3E_Make_WordPress_?=
 =?utf-8?q?Core=22_only_visible_on_hover_and_incorrect_text_color?=
Message-ID: <059.1536e5e1bbb71cfcd1623a9e8ad75a2f@wordpress.org>

#65013: make.wordpress.org/core – Site title "< > Make WordPress Core" only visible
on hover and incorrect text color
--------------------------------+-----------------------------
 Reporter:  hiabhaykulkarni     |      Owner:  (none)
     Type:  defect (bug)        |     Status:  new
 Priority:  normal              |  Milestone:  Awaiting Review
Component:  WordPress.org Site  |    Version:
 Severity:  minor               |   Keywords:
  Focuses:                      |
--------------------------------+-----------------------------
 Steps to Reproduce:
 1. Visit https://make.wordpress.org/core/
 2. Observe the site title/logo area in the top-left header
 3. Note that the text "< > Make WordPress Core" is invisible by default
 4. Hover over the header area

 Expected Result:
 - The site title "< > Make WordPress Core" should be permanently visible
 in white text, consistent with the dark header background.
 Actual Result:
 - The site title text is hidden by default and only appears on hover. The
 text color also appears incorrect - it should be white to contrast with
 the dark header.

 Environment:
 URL: https://make.wordpress.org/core/
 Type: UI / CSS defect
 OS & Browser: macOS 26.3, Chrome Version 146.0.7680.165 (Official Build)
 (arm64)

 Additional Notes:
 This appears to be a CSS visibility or color issue affecting the site
 header. No plugins or themes are involved as this is a WordPress.org
 network site.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65013>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 14:07:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 14:07:56 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2365013=3A_make=2Eword?=
 =?utf-8?q?press=2Eorg/core_=E2=80=93_Site_title_=22=3C_=3E_Make_WordPress?=
 =?utf-8?q?_Core=22_only_visible_on_hover_and_incorrect_text_color?=
In-Reply-To: <059.1536e5e1bbb71cfcd1623a9e8ad75a2f@wordpress.org>
References: <059.1536e5e1bbb71cfcd1623a9e8ad75a2f@wordpress.org>
Message-ID: <074.3b02e4d6dbf531cd7c16f26c6b13e14e@wordpress.org>

#65013: make.wordpress.org/core – Site title "< > Make WordPress Core" only visible
on hover and incorrect text color
--------------------------------+------------------------------
 Reporter:  hiabhaykulkarni     |       Owner:  (none)
     Type:  defect (bug)        |      Status:  new
 Priority:  normal              |   Milestone:  Awaiting Review
Component:  WordPress.org Site  |     Version:
 Severity:  minor               |  Resolution:
 Keywords:                      |     Focuses:
--------------------------------+------------------------------

Comment (by SergeyBiryukov):

 Hi there, welcome to WordPress Trac! Thanks for the report.

 Looks like these inline styles have been recently removed from the page,
 causing the issue:
 {{{
 .wp-elements-1b51aea1fd24d0aef3e0b3e7d65bcfef a:where(:not(.wp-element-
 button)) {
   color:var(--wp--preset--color--white);
 }
 .wp-elements-1b51aea1fd24d0aef3e0b3e7d65bcfef a:where(:not(.wp-element-
 button)):hover {
   color:var(--wp--preset--color--white);
 }
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65013#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 14:24:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 14:24:21 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2365013=3A_make=2Eword?=
 =?utf-8?q?press=2Eorg/core_=E2=80=93_Site_title_=22=3C_=3E_Make_WordPress?=
 =?utf-8?q?_Core=22_only_visible_on_hover_and_incorrect_text_color?=
In-Reply-To: <059.1536e5e1bbb71cfcd1623a9e8ad75a2f@wordpress.org>
References: <059.1536e5e1bbb71cfcd1623a9e8ad75a2f@wordpress.org>
Message-ID: <074.231b8ab50502a8f9b07bc4bb77048378@wordpress.org>

#65013: make.wordpress.org/core – Site title "< > Make WordPress Core" only visible
on hover and incorrect text color
--------------------------------+----------------------
 Reporter:  hiabhaykulkarni     |       Owner:  (none)
     Type:  defect (bug)        |      Status:  closed
 Priority:  normal              |   Milestone:
Component:  WordPress.org Site  |     Version:
 Severity:  minor               |  Resolution:  invalid
 Keywords:                      |     Focuses:
--------------------------------+----------------------
Changes (by wildworks):

 * status:  new => closed
 * resolution:   => invalid
 * milestone:  Awaiting Review =>


Comment:

 Closing as a duplicate of https://meta.trac.wordpress.org/ticket/8211

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65013#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 14:25:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 14:25:17 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.ad999564048497aadd67356c9acdad7e@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  General           |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+-------------------------------

Comment (by jorgefilipecosta):

 Replying to [comment:22 desrosj]:
 > I commented on the PR already because I saw that discussion first. But
 just to respond to a few points I did not see specifically called out on
 the PR's discussion.
 >
 > Replying to [comment:19 jorgefilipecosta]:
 > > The long-term ideal solution is making sure all plugins in the
 filesystem that have connectors appear on the connectors screen even when
 not active and allow their activation from there, but that is something
 that needs additional thought and will require bigger changes.
 >
 > I strongly disagree that this is the ideal solution here. This will be
 not only be abused by plugins rendering the Connectors page essentially
 useless (all you need is to be installed, and you can bug the site owner
 to reactivate and renew forever on this page). It will most certainly also
 be a vulnerability gold mine.


 That's a fair concern, but it's not quite what I had in mind. Inactive
 plugins wouldn't be able to execute arbitrary code to register a
 connector. We're considering a few options, for example a special syntax
 in the plugin definition header or a dedicated connectors.json file.
 Either approach would also allow the WP.org API to expose connectors that
 core can use to render the default connectors list, removing the need for
 any hardcoding. That said, I think we need more time to land on the right
 path forward here, and I appreciate the thoughtfulness around security.



 > I am of the opinion that it ''should'' be different. The AI connectors
 have a specific purpose that the project is trying to champion by
 empowering users with the tools they need to be successful in an
 increasingly AI world. If it were up to me, the two groups would be `AI
 connectors`, and `API Keys` or `Everything Else`.


 I hear you, and I agree that the AI connectors serve an important purpose
 in empowering users. At the same time, Akismet also play a meaningful role
 in helping users succeed, in this case by saving them from spending
 significant time dealing with spam. Given the existing decision to include
 Akismet with core, I think it's natural for its connector to appear on the
 Connectors screen before activation, with an easy path to activate it from
 there. If we're already showing connectors for AI services whose files
 aren't even included in the installation, it seems reasonable to do the
 same for something that's already bundled.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:27>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 14:26:46 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 14:26:46 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.d44d452424163ab02faba119750cd593@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  General           |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+-------------------------------

Comment (by jorgefilipecosta):

 Thank you @jorbin, @westonruter, @peterwilsoncc, @davidbaumwald, and
 @gziolo for the thoughts and insights shared on this issue. The need for a
 decision has been raised in the release leads Core Slack channel, and I'll
 be waiting on public direction from the release/product leadership
 regarding next steps.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:28>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 14:26:50 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 14:26:50 -0000
Subject: [wp-trac] [WordPress Trac] #10931: Verify Comment Email
 Addresses of Registered Users
In-Reply-To: <054.355234388c96928dd0b426899fbdca8c@wordpress.org>
References: <054.355234388c96928dd0b426899fbdca8c@wordpress.org>
Message-ID: <069.05c9040178c6d3594167971a906f869e@wordpress.org>

#10931: Verify Comment Email Addresses of Registered Users
-------------------------------------------------+-------------------------
 Reporter:  mtdewvirus                           |       Owner:
                                                 |  adamsilverstein
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  7.1
Component:  Comments                             |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  needs-docs early has-patch has-      |     Focuses:
  unit-tests                                     |
-------------------------------------------------+-------------------------

Comment (by ankitkumarshah):

 Hi @adamsilverstein, @oglekler, @mindctrl, @wildworks

 Thank you all for the valuable feedback and for guiding the direction of
 this ticket. I have updated the PR to align with the consensus.

 Here is the PR link for reference: https://github.com/WordPress/wordpress-
 develop/pull/8443

 Could you please take a look and let me know if any further changes are
 required?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/10931#comment:85>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 14:38:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 14:38:44 -0000
Subject: [wp-trac] [WordPress Trac] #64494: Bump minimum PHP version to
 8.*
In-Reply-To: <055.4df567ed50664c15ffe5a6ec97d7b63d@wordpress.org>
References: <055.4df567ed50664c15ffe5a6ec97d7b63d@wordpress.org>
Message-ID: <070.5a4db66b0ab21970a2ff21a873ba46fa@wordpress.org>

#64494: Bump minimum PHP version to 8.*
-------------------------+--------------------------------
 Reporter:  masteradhoc  |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  php-compatibility
-------------------------+--------------------------------

Comment (by ZanderZ):

 Replying to [comment:2 samiamnot]:
 > What I find interesting is that PHP 8.0 usage is low (5.82%) and
 dropping. It will be below 5% in the next 2 or 3 months at the current
 rate.

 As expected, PHP 8.0 reached 4.9% today for the first time!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64494#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 15:16:47 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 15:16:47 -0000
Subject: [wp-trac] [WordPress Trac] #64494: Bump minimum PHP version to
 8.*
In-Reply-To: <055.4df567ed50664c15ffe5a6ec97d7b63d@wordpress.org>
References: <055.4df567ed50664c15ffe5a6ec97d7b63d@wordpress.org>
Message-ID: <070.d53cf9e8ddf1061886786aea362d7646@wordpress.org>

#64494: Bump minimum PHP version to 8.*
-------------------------+--------------------------------
 Reporter:  masteradhoc  |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  php-compatibility
-------------------------+--------------------------------

Comment (by masteradhoc):

 That's great to hear! Currently we're sitting at 20.48% for PHP 7.4, so
 that will take some time — the threshold needs to drop below 5%. The
 chances are high that we'll be able to move directly to something higher
 than 8.0. I lean toward @samiamnot's opinion that we'll be able to push to
 8.2 by the time PHP 7.4 gets below 5%.

 @samiamnot will continue the analytics after the WP 7.0 release on this
 ticket so we'll get regular updates and track how fast we can do this
 change.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64494#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 17:18:04 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 17:18:04 -0000
Subject: [wp-trac] [WordPress Trac] #65014: Site Health: Error icon missing
 due to missing dashicons class
Message-ID: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>

#65014: Site Health: Error icon missing due to missing dashicons class
-----------------------------------+---------------------------------------
 Reporter:  valani9099             |      Owner:  (none)
     Type:  defect (bug)           |     Status:  new
 Priority:  normal                 |  Milestone:  Awaiting Review
Component:  Administration         |    Version:  trunk
 Severity:  normal                 |   Keywords:  has-screenshots has-patch
  Focuses:  ui, css,               |
  administration                   |
-----------------------------------+---------------------------------------
 Tested on WordPress 7.0-RC2, the error icon is not displayed in:

 Tools → Site Health → Status

 ### Issue
 The error indicator span is missing the required `dashicons` class.

 Current markup:
 <span class="error"></span>

 Expected markup:
 <span class="error dashicons"></span>

 Because of the missing `dashicons` class, the icon is not rendered.

 ### Steps to Reproduce
 1. Install WordPress 7.0-RC2
 2. Go to Tools → Site Health → Status
 3. Trigger an error (e.g., block external requests or simulate failure)
 4. Observe missing icon next to the error message

 ### Expected Behavior
 The error icon (dashicon) should be visible.

 ### Actual Behavior
 No icon is displayed.

 ### Proposed Fix
 Add the `dashicons` class to the error span element.

 ### Additional Notes
 I have verified that adding the `dashicons` class fixes the issue.

 Screenshots attached:
 - Before fix (icon missing)
 - After fix (icon visible)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65014>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 17:22:27 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 17:22:27 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings are
 not translated (missing gettext)
Message-ID: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>

#65015: Connectors: Several strings are not translated (missing gettext)
--------------------------+-----------------------------
 Reporter:  369work       |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  I18N          |    Version:
 Severity:  normal        |   Keywords:  needs-patch
  Focuses:                |
--------------------------+-----------------------------
 In the Connectors section of the WordPress admin panel, several strings
 remain in English regardless of the site language setting.
 Steps to reproduce:

 Install WordPress 7.0 RC2
 Navigate to the Connectors section in the admin panel
 Switch the site language to any non-English language

 Strings that are not translated:

 "Text and image generation with Gemini and Imagen."
 "If the connector you need is not listed"
 "All of your API keys and credentials are stored here and shared across
 plugins. Configure once and use everywhere."
 "Set up" (button)

 Expected behavior:
 All of the above strings should be translatable, as the "Install" and
 "Cancel" buttons already are.
 Actual behavior:
 The strings listed above are not translated and remain in English
 regardless of the site language setting.
 WordPress version: 7.0 RC2

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 17:23:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 17:23:18 -0000
Subject: [wp-trac] [WordPress Trac] #65014: Site Health: Error icon
 missing due to missing dashicons class
In-Reply-To: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
References: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
Message-ID: <069.699efb6fbcc2678a6ff9b82c0d07d0fa@wordpress.org>

#65014: Site Health: Error icon missing due to missing dashicons class
-------------------------------------+-------------------------------------
 Reporter:  valani9099               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-screenshots has-     |     Focuses:  ui, css,
  patch                              |  administration
-------------------------------------+-------------------------------------
Changes (by valani9099):

 * Attachment "before-fix.png" added.

 Before fix – Site Health error icon missing in WordPress 7.0-RC2 admin
 panel

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65014>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 17:23:19 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 17:23:19 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated (missing gettext)
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.599c53689bfbae2f81ce1f6c7b4e8495@wordpress.org>

#65015: Connectors: Several strings are not translated (missing gettext)
--------------------------+------------------------------
 Reporter:  369work       |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  I18N          |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+------------------------------
Changes (by 369work):

 * Attachment "スクリーンショット 2026-04-03 020420.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 17:23:54 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 17:23:54 -0000
Subject: [wp-trac] [WordPress Trac] #65014: Site Health: Error icon
 missing due to missing dashicons class
In-Reply-To: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
References: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
Message-ID: <069.036b228e85e41da7bef684b4a9697dec@wordpress.org>

#65014: Site Health: Error icon missing due to missing dashicons class
-------------------------------------+-------------------------------------
 Reporter:  valani9099               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-screenshots has-     |     Focuses:  ui, css,
  patch                              |  administration
-------------------------------------+-------------------------------------
Changes (by valani9099):

 * Attachment "after-fix.png" added.

 After fix – Site Health error icon visible after adding dashicons class

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65014>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 17:40:43 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 17:40:43 -0000
Subject: [wp-trac] [WordPress Trac] #64494: Bump minimum PHP version to
 8.*
In-Reply-To: <055.4df567ed50664c15ffe5a6ec97d7b63d@wordpress.org>
References: <055.4df567ed50664c15ffe5a6ec97d7b63d@wordpress.org>
Message-ID: <070.ac30f13aac8098ca8d460456302881c8@wordpress.org>

#64494: Bump minimum PHP version to 8.*
-------------------------+--------------------------------
 Reporter:  masteradhoc  |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  php-compatibility
-------------------------+--------------------------------

Comment (by johnbillion):

 8.0, 8.1, and 8.2 have all peaked. It'll be interesting to see how their
 usage drops compared to that of 7.4.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64494#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 20:04:25 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 20:04:25 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.efd9273d952e9f7f627f6500044bf02e@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  General           |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+-------------------------------

Comment (by eclev91):

 Replying to [comment:27 jorgefilipecosta]:
 > Given the existing decision to include Akismet with core

 > The need for a decision has been raised in the release leads Core Slack
 channel, and I'll be waiting on public direction from the release/product
 leadership regarding next steps.

 I'm concerned about the ability for the public to weigh in on a broader
 discussion about preferential treatment for specific plugins without
 derailing this ticket.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:30>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 20:19:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 20:19:23 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.e41eedd6b75833e08f6b6dc23cc15ae4@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  General           |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch commit  |     Focuses:
------------------------------+-------------------------------
Changes (by jorbin):

 * keywords:  has-patch => has-patch commit


Comment:

 @matveb
 [https://wordpress.slack.com/archives/C0A803Z8MA5/p1775140428971829?thread_ts=1775057127.773399&cid=C0A803Z8MA5
 weighed in on slack]:

 > So i think Akismet should show up if it’s installed.

 As the code currently does the opposite, I think we are good to go with
 the revert.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:31>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 21:06:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 21:06:03 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.0ca7fac0e9838793bfd18243efb1cd6e@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  General           |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch commit  |     Focuses:
------------------------------+-------------------------------

Comment (by jorgefilipecosta):

 Replying to [comment:31 jorbin]:
 > @matveb
 [https://wordpress.slack.com/archives/C0A803Z8MA5/p1775140428971829?thread_ts=1775057127.773399&cid=C0A803Z8MA5
 weighed in on slack]:
 >
 > > So i think Akismet should show up if it’s installed.
 >
 > As the code currently does the opposite, I think we are good to go with
 the revert.


 Hi @jorbin the code does not makes the opposite, the connector only appear
 on the UI if Akismet is installed.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:32>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 21:11:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 21:11:53 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.8484433768aa674b273a0314b6b295df@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  General           |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch commit  |     Focuses:
------------------------------+-------------------------------

Comment (by jorgefilipecosta):

 To properly test this patch, the Gutenberg ref needs to be updated to the
 latest one (for now, cd9192803f5b1262cc2f9beefc52bc500545813f). Normally,
 the ref is only updated before releases. Once Akismet is deleted from the
 file system, it no longer shows up in the UI, which matches exactly what
 was shared in the Release Leads Slack channel

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:33>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 21:22:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 21:22:17 -0000
Subject: [wp-trac] [WordPress Trac] #64538: memoize wp_normalize_path
In-Reply-To: <055.d0a68ae7d0a278908d25712bd31f710d@wordpress.org>
References: <055.d0a68ae7d0a278908d25712bd31f710d@wordpress.org>
Message-ID: <070.5a47aaf41ca259a94016fb172c2d1f4f@wordpress.org>

#64538: memoize wp_normalize_path
--------------------------------------+--------------------------
 Reporter:  josephscott               |       Owner:  dmsnell
     Type:  defect (bug)              |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.0
Component:  General                   |     Version:  3.9
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+--------------------------

Comment (by josephscott):

 I had Claude code go through the PHP source changes to see if something
 could be found to explain why this only failed on those two versions of
 PHP ( 8.1 and 8.2 ).  It looks like the way this test works was
 particularly unlucky.

 {{{
 PHP 8.1/8.2 Bug: ReflectionFunction::getStaticVariables() Returns Stale
 Values
   When OPcache Is Enabled

   ReflectionFunction::getStaticVariables() returns compile-time default
 values
   instead of current runtime values on PHP 8.1 and 8.2 when OPcache is
 enabled.

   Affected versions: PHP 8.1.0–8.1.x, 8.2.0–8.2.x (with OPcache enabled)
   Not affected: PHP 7.4, 8.0, 8.3+

   Cause

   Two changes combined to create this bug:

   1. PHP 8.1 changed how static variable pointers are stored. In PHP 8.0
 and
   earlier, the internal static_variables_ptr pointed directly at the
 function's
   own static_variables field, so reflection always read the live data. PHP
 8.1
   switched to a separate storage slot initialized to NULL, relying on the
   ZEND_BIND_STATIC opcode to populate it at runtime.
   2. OPcache's Dead Code Elimination (DCE) incorrectly treats
 ZEND_BIND_STATIC as
   side-effect-free for static variables with simple initializers (like
 static
   $cache = array()). This allows the optimizer to eliminate or weaken the
 opcode,
   so the storage slot is never populated. getStaticVariables() then falls
 back to
   returning the compile-time defaults.

   PHP 8.0 was unaffected because the self-referencing pointer masked the
   optimizer's behavior. PHP 8.3 fixed the issue via the
   https://wiki.php.net/rfc/arbitrary_static_variable_initializers
   (https://github.com/php/php-src/pull/9301), which introduced a new
   ZEND_BIND_INIT_STATIC_OR_JMP opcode that DCE always treats as side-
 effectful,
   and updated DCE to recognize that reference bindings with initializers
 are
   observable through reflection.

   Reproduction

   <?php
   // Run with: php -d opcache.enable_cli=1 repro.php

   function demo() {
       static $cache = array();
       if ( isset( $cache['key'] ) ) {
           return $cache['key'];
       }
       $cache['key'] = 'value';
       return $cache['key'];
   }

   demo();

   $statics = ( new ReflectionFunction( 'demo' ) )->getStaticVariables();

   // PHP 8.1/8.2 with OPcache: array() (empty — bug)
   // All other versions:        array( 'key' => 'value' )
   var_dump( $statics['cache'] );

   References

   - https://wiki.php.net/rfc/arbitrary_static_variable_initializers — the
 PHP 8.3
   RFC whose implementation fixed this as a side effect
   - https://github.com/php/php-src/pull/9301 — the implementation,
 including the
   DCE fix and the regression test optimize_static_002.phpt ("Keep
 BIND_STATIC when
    static variable has an initializer")
   - https://github.com/php/php-src/issues/9177 — related issue about
 static
   variables and reflection
   - https://www.npopov.com/2021/10/13/How-opcache-works.html — background
 on
   ZEND_MAP_PTR and immutable functions
 }}}

 I don't have a lot of experience with PHP internals, and given that this
 is already fixed I think it is more helpful to focus addressing the
 testing code.  What if we split this test into two -
 https://gist.github.com/josephscott/e1265dc63d878a53947ec6c4cc555390 - one
 for each group of PHP versions ( with and without this bug ).

 For `wp_normlize_path()` itself, I haven't found anything that needs to be
 addressed.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64538#comment:29>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 21:23:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 21:23:57 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.4502c63937a78f88a176bb289fbdce0d@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  General           |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch commit  |     Focuses:
------------------------------+-------------------------------

Comment (by peterwilsoncc):

 I think the fundamental question is still to be answered.

 How does it benefit users to add an Akismet key to WordPress without
 Akismet being active?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:34>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 21:28:38 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 21:28:38 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.a3e601d806ea12b7e725ceb54269854a@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  defect (bug)      |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  General           |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch commit  |     Focuses:
------------------------------+-------------------------------

Comment (by jorgefilipecosta):

 Replying to [comment:34 peterwilsoncc]:
 > I think the fundamental question is still to be answered.
 >
 > How does it benefit users to add an Akismet key to WordPress without
 Akismet being active?

 Hi @peterwilsoncc, I believe I addressed this earlier at
 https://core.trac.wordpress.org/ticket/65012?replyto=34#comment:25, but it
 may have gotten lost in the conversation:

 > That's a good point that is worth addressing. The UI doesn't actually
 allow setting a key without activating the plugin first. What it does is
 let users activate the plugin directly from the connectors screen, without
 needing to navigate to the plugins screen, and then provide the key right
 away without any page reloads. So by the time the key is set, the plugin
 is already active.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:35>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 22:06:37 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 22:06:37 -0000
Subject: [wp-trac] [WordPress Trac] #64696: Real time collboration
 effectively disables persistent post caches while anyone edits a post
In-Reply-To: <057.05b7879d9d7300bfeccbd48dcfe7237b@wordpress.org>
References: <057.05b7879d9d7300bfeccbd48dcfe7237b@wordpress.org>
Message-ID: <072.6e749e466edac239c418713ef1937a90@wordpress.org>

#64696: Real time collboration effectively disables persistent post caches while
anyone edits a post
--------------------------------------+--------------------------
 Reporter:  peterwilsoncc             |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Posts, Post Types         |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+--------------------------

Comment (by spacedmonkey):

 Sorry for the ping, but I would like eyes on my
 [https://github.com/WordPress/wordpress-develop/pull/11427 PR].
 @davidbaumwald @peterwilsoncc @westonruter @zieladam

 TDLR of the PR, it keep the last changed group changing on clean post
 cache / update / add delete post meta, to maintain backwards compatiblity
 with third parties code that is use this cache key for invalidation /
 salts. But with the core base use two new last changed caches, one for
 post-queries and one for post meta.

 So to be clear.
 - Post - last changed is updated when both posts and meta are updated.
 - Post-queries - last changed is updated when posts are updated.
 - Post-meta - last changed is updated when meta is updated.

 If this change works for posts, we should roll this out to other query
 classes.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64696#comment:144>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 22:13:32 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 22:13:32 -0000
Subject: [wp-trac] [WordPress Trac] #64696: Real time collboration
 effectively disables persistent post caches while anyone edits a post
In-Reply-To: <057.05b7879d9d7300bfeccbd48dcfe7237b@wordpress.org>
References: <057.05b7879d9d7300bfeccbd48dcfe7237b@wordpress.org>
Message-ID: <072.99ea5eae82a985accde8f9eb2b0930da@wordpress.org>

#64696: Real time collboration effectively disables persistent post caches while
anyone edits a post
--------------------------------------+--------------------------
 Reporter:  peterwilsoncc             |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Posts, Post Types         |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+--------------------------

Comment (by peterwilsoncc):

 @spacedmonkey The 7.0 delay is to allow time for a custom table to be used
 so we won't need to make any immediate and last minute changes to the
 Query or Meta APIs.

 FWIW, I've been silently pondering x_meta last changed values as something
 to consider in a future release, are you able to open a ticket?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64696#comment:145>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 22:36:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 22:36:23 -0000
Subject: [wp-trac] [WordPress Trac] #64538: memoize wp_normalize_path
In-Reply-To: <055.d0a68ae7d0a278908d25712bd31f710d@wordpress.org>
References: <055.d0a68ae7d0a278908d25712bd31f710d@wordpress.org>
Message-ID: <070.0d083d0d1751fbfca25df037acb741ae@wordpress.org>

#64538: memoize wp_normalize_path
--------------------------------------+--------------------------
 Reporter:  josephscott               |       Owner:  dmsnell
     Type:  defect (bug)              |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.0
Component:  General                   |     Version:  3.9
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+--------------------------

Comment (by dmsnell):

 @josephscott wild.

 this appears then to be another case of //tests failing//.

 perhaps instead of splitting the tests, which seems a bit awkward, can we
 think of a way to assert the end behavior rather than the the method by
 which the function accomplishes it?

 ----

 As an aside, when I follow the reproduction steps with PHP 8.1.33 and also
 with PHP 8.2.29 it works appropriately, so it probably doesn’t affect all
 of the PHP 8.1 and 8.2 lines. Maybe some hosts haven’t updated to the
 latest minor releases.


 {{{
 array(1) {
   ["key"]=>
   string(5) "value"
 }
 }}}


 Were you successful in reproducing this with the proposed snippet?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64538#comment:30>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 22:46:01 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 22:46:01 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.2b8a63166be7663689ae24e8f8f67589@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  feature request   |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  Plugins           |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  has-patch revert  |     Focuses:
------------------------------+-------------------------------
Changes (by johnbillion):

 * keywords:  has-patch commit => has-patch revert
 * type:  defect (bug) => feature request
 * version:  trunk =>
 * component:  General => Plugins


Comment:

 Replying to [comment:25 jorgefilipecosta]:

 > We are discussing this publicly here both on Trac and GitHub and @gziolo
 also raised awareness for this discussion on the release leads slack
 channel.

 - The Slack thread that you didn't reference was started after the commit
 was made:
 https://wordpress.slack.com/archives/C0A803Z8MA5/p1775057127773399.
 - There is no public discussion of this change outside of this Trac
 ticket. Discussion on the PR was technical feedback.
 - Nobody approved your PR.
 - The change was committed 36 minutes after opening the ticket.

 Sorry @jorgefilipecosta but it is inappropriate to make this sort of
 change during RC, especially within such a short period of time and with
 no public discussion.

 If you want to facilitate plugins registering an entry on the Connectors
 screen when they're installed but not activate, then make a proper
 proposal and discussion instead of privately deciding that it's ok for
 Akismet to be inserted there. Please go ahead and revert [62193] pending
 further discussion. Thank you.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:36>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 23:05:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 23:05:28 -0000
Subject: [wp-trac] [WordPress Trac] #65001: Hover on Upload files media
 Library tabs and drop to upload file overlay color has still old color
In-Reply-To: <053.1e9023874452fde73c1121655252bc0d@wordpress.org>
References: <053.1e9023874452fde73c1121655252bc0d@wordpress.org>
Message-ID: <068.eb95c144a40e15867c4b2f8eeabc3d2f@wordpress.org>

#65001: Hover on Upload files media Library tabs and drop to upload file overlay
color has still old color
------------------------------+----------------------------
 Reporter:  opurockey         |       Owner:  joedolson
     Type:  defect (bug)      |      Status:  accepted
 Priority:  normal            |   Milestone:  7.0
Component:  Upload            |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch commit  |     Focuses:  accessibility
------------------------------+----------------------------
Changes (by joedolson):

 * keywords:  has-patch changes-requested => has-patch commit


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65001#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 23:09:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 23:09:23 -0000
Subject: [wp-trac] [WordPress Trac] #65001: Hover on Upload files media
 Library tabs and drop to upload file overlay color has still old color
In-Reply-To: <053.1e9023874452fde73c1121655252bc0d@wordpress.org>
References: <053.1e9023874452fde73c1121655252bc0d@wordpress.org>
Message-ID: <068.9c7fdcc6c2fb73cb70f7bd4c39b24077@wordpress.org>

#65001: Hover on Upload files media Library tabs and drop to upload file overlay
color has still old color
------------------------------+----------------------------
 Reporter:  opurockey         |       Owner:  joedolson
     Type:  defect (bug)      |      Status:  closed
 Priority:  normal            |   Milestone:  7.0
Component:  Upload            |     Version:  trunk
 Severity:  normal            |  Resolution:  fixed
 Keywords:  has-patch commit  |     Focuses:  accessibility
------------------------------+----------------------------
Changes (by joedolson):

 * status:  accepted => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62199" 62199]:
 {{{
 #!CommitTicketReference repository="" revision="62199"
 Media: Update upload file overlay colors.

 Update the colors used for the file upload overlay mask to use the new
 admin theme colors.

 Props opurockey, huzaifaalmesbah, wildworks, audrasjb, manhar, joedolson.
 Fixes #65001.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65001#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 23:10:08 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 23:10:08 -0000
Subject: [wp-trac] [WordPress Trac] #65016: Auto-approve self pingbacks
Message-ID: <052.2f05be43d6f406fcfda761b36981a246@wordpress.org>

#65016: Auto-approve self pingbacks
------------------------------+-----------------------------
 Reporter:  annezazu          |      Owner:  (none)
     Type:  enhancement       |     Status:  new
 Priority:  normal            |  Milestone:  Awaiting Review
Component:  Pings/Trackbacks  |    Version:
 Severity:  normal            |   Keywords:
  Focuses:  administration    |
------------------------------+-----------------------------
 This came up from @matt: self-pingbacks should auto-approve. Unclear
 whether this should be a setting or something that automatically happens
 as I'm not sure of the broader use cases where folks might not want this.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65016>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 23:10:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 23:10:18 -0000
Subject: [wp-trac] [WordPress Trac] #65001: Hover on Upload files media
 Library tabs and drop to upload file overlay color has still old color
In-Reply-To: <053.1e9023874452fde73c1121655252bc0d@wordpress.org>
References: <053.1e9023874452fde73c1121655252bc0d@wordpress.org>
Message-ID: <068.fcb0d77855721adffccbd63faa951d01@wordpress.org>

#65001: Hover on Upload files media Library tabs and drop to upload file overlay
color has still old color
-------------------------------------------+----------------------------
 Reporter:  opurockey                      |       Owner:  joedolson
     Type:  defect (bug)                   |      Status:  reopened
 Priority:  normal                         |   Milestone:  7.0
Component:  Media                          |     Version:  trunk
 Severity:  normal                         |  Resolution:
 Keywords:  has-patch commit dev-feedback  |     Focuses:  accessibility
-------------------------------------------+----------------------------
Changes (by joedolson):

 * keywords:  has-patch commit => has-patch commit dev-feedback
 * resolution:  fixed =>
 * status:  closed => reopened
 * component:  Upload => Media


Comment:

 Re-opening for review to merge to the 7.0 branch.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65001#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 23:20:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 23:20:12 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.40da70f2db076b97d0edb6e3f30ed174@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  feature request   |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  Plugins           |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  has-patch revert  |     Focuses:
------------------------------+-------------------------------

Comment (by jorgefilipecosta):

 Replying to [comment:36 johnbillion]:
 > Replying to [comment:25 jorgefilipecosta]:
 >
 > > We are discussing this publicly here both on Trac and GitHub and
 @gziolo also raised awareness for this discussion on the release leads
 slack channel.
 >
 > - The Slack thread that you didn't reference was started after the
 commit was made:
 https://wordpress.slack.com/archives/C0A803Z8MA5/p1775057127773399.
 > - There is no public discussion of this change outside of this Trac
 ticket. Discussion on the PR was technical feedback.
 > - Nobody approved your PR.
 > - The change was committed 36 minutes after opening the ticket.
 >
 > Sorry @jorgefilipecosta but it is inappropriate to make this sort of
 change during RC, especially within such a short period of time and with
 no public discussion.
 >
 > If you want to facilitate plugins registering an entry on the Connectors
 screen when they're installed but not activate, then make a proper
 proposal and discussion instead of privately deciding that it's ok for
 Akismet to be inserted there. Please go ahead and revert [62193] pending
 further discussion. Thank you.

 Hi @johnbillion,
 Thank you for raising your concerns. This ticket was approved by @gziolo
 (another committer)
 https://core.trac.wordpress.org/ticket/65012#comment:2, following the
 normal double sign-off process before committing. It was only committed to
 trunk and has not been backported into the 7.0 release branch as of now.

 > If you want to facilitate plugins registering an entry on the Connectors
 screen when they're installed but not activate, then make a proper
 proposal and discussion instead of privately deciding that it's ok for
 Akismet to be inserted there.

 It's worth noting that the approach used to add Akismet is the same as the
 one used for the other three connectors we already had, using what is
 currently possible. And in the future, we could iterate on both Akismet
 and the other connectors.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:37>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 23:26:25 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 23:26:25 -0000
Subject: [wp-trac] [WordPress Trac] #24241: Whitelist
 trackbacks/pingbacks from own site
In-Reply-To: <051.106bf3626fb84ef91e7ff6677e87ea80@wordpress.org>
References: <051.106bf3626fb84ef91e7ff6677e87ea80@wordpress.org>
Message-ID: <066.70340404b977be7019f2df35c6782e18@wordpress.org>

#24241: Whitelist trackbacks/pingbacks from own site
-------------------------------------------------+-------------------------
 Reporter:  eurello                              |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Pings/Trackbacks                     |     Version:  3.5.1
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing has-unit-    |     Focuses:
  tests needs-refresh                            |
-------------------------------------------------+-------------------------

Comment (by desrosj):

 Related: #65016

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/24241#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 23:26:52 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 23:26:52 -0000
Subject: [wp-trac] [WordPress Trac] #65016: Auto-approve self pingbacks
In-Reply-To: <052.2f05be43d6f406fcfda761b36981a246@wordpress.org>
References: <052.2f05be43d6f406fcfda761b36981a246@wordpress.org>
Message-ID: <067.5ea7e3a6f31e3ea7d2bd4ec339ed53df@wordpress.org>

#65016: Auto-approve self pingbacks
------------------------------+------------------------------
 Reporter:  annezazu          |       Owner:  (none)
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  Awaiting Review
Component:  Pings/Trackbacks  |     Version:
 Severity:  normal            |  Resolution:
 Keywords:                    |     Focuses:  administration
------------------------------+------------------------------

Comment (by desrosj):

 Related: #24241.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65016#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 23:34:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 23:34:07 -0000
Subject: [wp-trac] [WordPress Trac] #64976: Admin Style: Plugin links
 change styles on updates on 7.0
In-Reply-To: <052.33a9a520dd04c4f79918027e12c9cff4@wordpress.org>
References: <052.33a9a520dd04c4f79918027e12c9cff4@wordpress.org>
Message-ID: <067.3af005836d5ab22fc4dffdfc1842b173@wordpress.org>

#64976: Admin Style: Plugin links change styles on updates on 7.0
-------------------------------------------------+-------------------------
 Reporter:  antonynz                             |       Owner:  joedolson
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  minor                                |  Resolution:  fixed
 Keywords:  admin-reskin has-patch has-          |     Focuses:
  screenshots commit                             |
-------------------------------------------------+-------------------------
Changes (by joedolson):

 * status:  accepted => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62200" 62200]:
 {{{
 #!CommitTicketReference repository="" revision="62200"
 Admin: Limit scope of admin notice link design.

 The design changes to admin notices links in the admin refresh were
 applied broadly to `.notice, .error, and .updated` classes, but these
 classes are sometimes used outside the context of an admin notice.

 Change selectors from `.notice a, .error a, .updated a` to `div.notice a,
 div.error a, div.updated a`.

 Props opurockey, audrasjb, vgnavada, gaisma22, shailu25, rbcorrales,
 joedolson.
 Fixes #64976.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64976#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 23:34:37 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 23:34:37 -0000
Subject: [wp-trac] [WordPress Trac] #64976: Admin Style: Plugin links
 change styles on updates on 7.0
In-Reply-To: <052.33a9a520dd04c4f79918027e12c9cff4@wordpress.org>
References: <052.33a9a520dd04c4f79918027e12c9cff4@wordpress.org>
Message-ID: <067.cf07908232138277eca1b2ace60c36bd@wordpress.org>

#64976: Admin Style: Plugin links change styles on updates on 7.0
-------------------------------------------------+-------------------------
 Reporter:  antonynz                             |       Owner:  joedolson
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  minor                                |  Resolution:
 Keywords:  admin-reskin has-patch has-          |     Focuses:
  screenshots dev-feedback                       |
-------------------------------------------------+-------------------------
Changes (by joedolson):

 * keywords:  admin-reskin has-patch has-screenshots commit => admin-reskin
     has-patch has-screenshots dev-feedback
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Re-opening for review to merge to the 7.0 branch.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64976#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 23:37:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 23:37:26 -0000
Subject: [wp-trac] [WordPress Trac] #64761: Admin Reskin: Change color
 picker height to 40px
In-Reply-To: <053.0662e8cd42d998e112a54bd506e405a8@wordpress.org>
References: <053.0662e8cd42d998e112a54bd506e405a8@wordpress.org>
Message-ID: <068.2410b8e70cd3bddd6097388a244ce789@wordpress.org>

#64761: Admin Reskin: Change color picker height to 40px
-------------------------------------------------+-------------------------
 Reporter:  wildworks                            |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch has-          |     Focuses:
  screenshots dev-reviewed                       |
-------------------------------------------------+-------------------------
Changes (by joedolson):

 * keywords:  admin-reskin has-patch has-screenshots dev-feedback => admin-
     reskin has-patch has-screenshots dev-reviewed


Comment:

 @wildworks You can update props in the admin at make.wordpress.org/core,
 using the 'Core Props' tool.

 Reviewed and approved for 7.0.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64761#comment:32>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 23:39:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 23:39:44 -0000
Subject: [wp-trac] [WordPress Trac] #24241: Whitelist
 trackbacks/pingbacks from own site
In-Reply-To: <051.106bf3626fb84ef91e7ff6677e87ea80@wordpress.org>
References: <051.106bf3626fb84ef91e7ff6677e87ea80@wordpress.org>
Message-ID: <066.f313416ff8cca09202dde37c696724c3@wordpress.org>

#24241: Whitelist trackbacks/pingbacks from own site
-------------------------------------------------+-------------------------
 Reporter:  eurello                              |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Pings/Trackbacks                     |     Version:  3.5.1
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing has-unit-    |     Focuses:
  tests needs-refresh                            |
-------------------------------------------------+-------------------------

Comment (by dshanske):

 I withdrew as Pingback maintainer years ago, as I switched to a successor
 protocol, webmention, but as similar, still think about this. For
 webmentions, we did add an option to allow self pings or discard them.
 That might work here, even if it is a filter not a setting that controls
 it.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/24241#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  2 23:48:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 02 Apr 2026 23:48:22 -0000
Subject: [wp-trac] [WordPress Trac] #64898: PHPStan code quality
 improvements for 7.1
In-Reply-To: <051.14621a206a2a689950362f87fda1495c@wordpress.org>
References: <051.14621a206a2a689950362f87fda1495c@wordpress.org>
Message-ID: <066.b61370286c82119b9f1617bc3cdbaabc@wordpress.org>

#64898: PHPStan code quality improvements for 7.1
----------------------------+-------------------------------
 Reporter:  desrosj         |       Owner:  (none)
     Type:  task (blessed)  |      Status:  new
 Priority:  normal          |   Milestone:  7.1
Component:  General         |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:  coding-standards
----------------------------+-------------------------------

Comment (by SergeyBiryukov):

 In [changeset:"62201" 62201]:
 {{{
 #!CommitTicketReference repository="" revision="62201"
 Code Quality: Remove unused variable in `WP_Block_Patterns_Registry`.

 Follow-up to [56805], [59101].

 Props Soean, mukesh27.
 See #64898.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64898#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 01:28:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 01:28:14 -0000
Subject: [wp-trac] [WordPress Trac] #64761: Admin Reskin: Change color
 picker height to 40px
In-Reply-To: <053.0662e8cd42d998e112a54bd506e405a8@wordpress.org>
References: <053.0662e8cd42d998e112a54bd506e405a8@wordpress.org>
Message-ID: <068.506ef6b3ea07d5d429cbfbe5ae7ec1b5@wordpress.org>

#64761: Admin Reskin: Change color picker height to 40px
-------------------------------------------------+-------------------------
 Reporter:  wildworks                            |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch has-          |     Focuses:
  screenshots dev-reviewed                       |
-------------------------------------------------+-------------------------

Comment (by wildworks):

 > Reviewed and approved for 7.0.

 Approved

 > You can update props in the admin at make.wordpress.org/core, using the
 'Core Props' tool.

 Thanks you, updated.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64761#comment:33>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 01:33:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 01:33:48 -0000
Subject: [wp-trac] [WordPress Trac] #64761: Admin Reskin: Change color
 picker height to 40px
In-Reply-To: <053.0662e8cd42d998e112a54bd506e405a8@wordpress.org>
References: <053.0662e8cd42d998e112a54bd506e405a8@wordpress.org>
Message-ID: <068.82de32e868afa0b4b585912e8aaf9a04@wordpress.org>

#64761: Admin Reskin: Change color picker height to 40px
-------------------------------------------------+-------------------------
 Reporter:  wildworks                            |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  admin-reskin has-patch has-          |     Focuses:
  screenshots dev-reviewed                       |
-------------------------------------------------+-------------------------
Changes (by wildworks):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62202" 62202]:
 {{{
 #!CommitTicketReference repository="" revision="62202"
 Admin Reskin: Change color picker height to match new design system.

 Update min-height from 30px to 32px for the color picker button and
 related elements to match new design system.

 Reviewed by joedolson, wildworks.
 Merges [62191] to the 7.0 branch.

 Props audrasjb, hmbashar, huzaifaalmesbah, joedolson, juanmaguitar,
 mukesh27, noruzzaman, ozgursar, rahultank, rcorrales, sajib1223, shailu25,
 tusharaddweb, vgnavada, wildworks.

 Fixes #64761.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64761#comment:34>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 01:37:20 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 01:37:20 -0000
Subject: [wp-trac] [WordPress Trac] #65001: Hover on Upload files media
 Library tabs and drop to upload file overlay color has still old color
In-Reply-To: <053.1e9023874452fde73c1121655252bc0d@wordpress.org>
References: <053.1e9023874452fde73c1121655252bc0d@wordpress.org>
Message-ID: <068.24bc384a6fac70b305513d05b3e4d1c9@wordpress.org>

#65001: Hover on Upload files media Library tabs and drop to upload file overlay
color has still old color
-------------------------------------------+----------------------------
 Reporter:  opurockey                      |       Owner:  joedolson
     Type:  defect (bug)                   |      Status:  reopened
 Priority:  normal                         |   Milestone:  7.0
Component:  Media                          |     Version:  trunk
 Severity:  normal                         |  Resolution:
 Keywords:  has-patch commit dev-reviewed  |     Focuses:  accessibility
-------------------------------------------+----------------------------
Changes (by wildworks):

 * keywords:  has-patch commit dev-feedback => has-patch commit dev-reviewed


Comment:

 Reviewed and approved for 7.0.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65001#comment:17>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 02:03:32 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 02:03:32 -0000
Subject: [wp-trac] [WordPress Trac] #65014: Site Health: Error icon
 missing due to missing dashicons class
In-Reply-To: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
References: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
Message-ID: <069.7cb7e8f3ed85ce23c7529d1822f01de5@wordpress.org>

#65014: Site Health: Error icon missing due to missing dashicons class
-------------------------------------+-------------------------------------
 Reporter:  valani9099               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-screenshots has-     |     Focuses:  ui, css,
  patch                              |  administration
-------------------------------------+-------------------------------------

Comment (by wildworks):

 Thanks for the report.

 Please note that this issue did not newly arise in 7.0.

 Also, if someone wishes to test this problem, you can intentionally cause
 an error with code like the following:

 {{{
 add_filter( 'pre_http_request', function( $response, $parsed_args, $url )
 {
         if ( false !== strpos( $url, 'api.wordpress.org' ) ) {
                 return new WP_Error( 'http_request_failed', 'Intentional
 failure for testing.' );
         }
         return $response;
 }, 10, 3 );
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65014#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 03:07:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 03:07:16 -0000
Subject: [wp-trac] [WordPress Trac] #64538: memoize wp_normalize_path
In-Reply-To: <055.d0a68ae7d0a278908d25712bd31f710d@wordpress.org>
References: <055.d0a68ae7d0a278908d25712bd31f710d@wordpress.org>
Message-ID: <070.46b41887c96f923a454898bcb56a4c30@wordpress.org>

#64538: memoize wp_normalize_path
--------------------------------------+--------------------------
 Reporter:  josephscott               |       Owner:  dmsnell
     Type:  defect (bug)              |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.0
Component:  General                   |     Version:  3.9
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+--------------------------

Comment (by josephscott):

 I didn't run the repo code - I guess it included it in an effort to be
 "helpful".  I took a quick run at it and I'm not seeing the failure.
 Either the repo example is useless ( entirely possible ) or there is
 another variable at play that I haven't matched yet.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64538#comment:31>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 06:39:36 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 06:39:36 -0000
Subject: [wp-trac] [WordPress Trac] #63532: Unit Testing: Checking if
 images already exists before starting tests
In-Reply-To: <052.4a4062885ce6917a72a5153a72ac1b10@wordpress.org>
References: <052.4a4062885ce6917a72a5153a72ac1b10@wordpress.org>
Message-ID: <067.721f1df98db27e38219ddb35f809482a@wordpress.org>

#63532: Unit Testing: Checking if images already exists before starting tests
-------------------------------------------------+-------------------------
 Reporter:  SirLouen                             |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Media                                |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-unit-tests has-test-info needs-  |     Focuses:  tests
  patch                                          |
-------------------------------------------------+-------------------------

Comment (by sukhendu2002):

 I tested the UPLOADS constant approach in bootstrap.php, and it does solve
 the collision by isolating test uploads in a disposable directory.

 The main thing I found is that this change affects more of the test suite
 than it first appears, because it changes the base URL returned by
 wp_upload_dir() globally. As a result, several media tests with hardcoded
 wp-content/uploads URLs start failing and need to be updated to use
 dynamic upload URLs instead.

 So the approach looks valid, but the patch likely needs broader test
 updates alongside it. Discussion and alternative ideas are welcome.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63532#comment:22>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 09:35:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 09:35:17 -0000
Subject: [wp-trac] [WordPress Trac] #65017: Dashboard widgets border bottom
 issue when it is closed in version 7.0 RC2
Message-ID: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>

#65017: Dashboard widgets border bottom issue when it is closed in version 7.0 RC2
----------------------------+-------------------------------------------
 Reporter:  Pratik Jain     |      Owner:  (none)
     Type:  defect (bug)    |     Status:  assigned
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Administration  |    Version:
 Severity:  normal          |   Keywords:  has-screenshots needs-testing
  Focuses:  ui, css         |
----------------------------+-------------------------------------------
 In WordPress 7.0 RC2 version,
 When dashboard widgets are closed then we can see a straight border bottom
 without round.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65017>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 09:37:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 09:37:22 -0000
Subject: [wp-trac] [WordPress Trac] #65017: Dashboard widgets border
 bottom issue when it is closed in version 7.0 RC2
In-Reply-To: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
References: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
Message-ID: <070.9f628aa7d08e1f565e7e8caed313567f@wordpress.org>

#65017: Dashboard widgets border bottom issue when it is closed in version 7.0 RC2
-------------------------------------------+------------------------------
 Reporter:  Pratik Jain                    |       Owner:  (none)
     Type:  defect (bug)                   |      Status:  assigned
 Priority:  normal                         |   Milestone:  Awaiting Review
Component:  Administration                 |     Version:
 Severity:  normal                         |  Resolution:
 Keywords:  has-screenshots needs-testing  |     Focuses:  ui, css
-------------------------------------------+------------------------------
Changes (by Pratik Jain):

 * Attachment "WordPress-7.png" added.

 Dashboard Widget Border Bottom Issue

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65017>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 09:45:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 09:45:09 -0000
Subject: [wp-trac] [WordPress Trac] #65017: Dashboard widgets border
 bottom issue when it is closed in version 7.0 RC2
In-Reply-To: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
References: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
Message-ID: <070.e0b59816770d9c32a604b5289bbd67e9@wordpress.org>

#65017: Dashboard widgets border bottom issue when it is closed in version 7.0 RC2
-------------------------------------------+------------------------------
 Reporter:  Pratik Jain                    |       Owner:  (none)
     Type:  defect (bug)                   |      Status:  assigned
 Priority:  normal                         |   Milestone:  Awaiting Review
Component:  Administration                 |     Version:
 Severity:  normal                         |  Resolution:
 Keywords:  has-screenshots needs-testing  |     Focuses:  ui, css
-------------------------------------------+------------------------------

Comment (by Pratik Jain):

 Confirmed the bug persists in both Firefox and Chrome. Applying the CSS
 snippet below will standardize the behavior across both browsers,

 We need to remove this CSS

 {{{
 .postbox.closed {border-bottom: 0;}
 }}}


 We need to add this CSS

 {{{
 .postbox.closed .postbox-header{border-bottom: 0;}
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65017#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 09:51:34 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 09:51:34 -0000
Subject: [wp-trac] [WordPress Trac] #65017: Dashboard widgets border
 bottom issue when it is closed in version 7.0 RC2
In-Reply-To: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
References: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
Message-ID: <070.0722b72904322949f1189cc14bbc46fd@wordpress.org>

#65017: Dashboard widgets border bottom issue when it is closed in version 7.0 RC2
-----------------------------------------+-----------------------
 Reporter:  Pratik Jain                  |       Owner:  (none)
     Type:  defect (bug)                 |      Status:  assigned
 Priority:  normal                       |   Milestone:  7.0
Component:  Administration               |     Version:  trunk
 Severity:  normal                       |  Resolution:
 Keywords:  has-screenshots needs-patch  |     Focuses:  ui, css
-----------------------------------------+-----------------------
Changes (by audrasjb):

 * keywords:  has-screenshots needs-testing => has-screenshots needs-patch
 * version:   => trunk
 * milestone:  Awaiting Review => 7.0


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65017#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 10:28:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 10:28:21 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2364967=3A_Bug_report_?=
 =?utf-8?q?=E2=80=93_Whitespace_/_non-breaking_spaces_removed_after_save_i?=
 =?utf-8?q?n_Gutenberg?=
In-Reply-To: <052.3c2e3cbdf85fb7e2fb39e221e5a6c84b@wordpress.org>
References: <052.3c2e3cbdf85fb7e2fb39e221e5a6c84b@wordpress.org>
Message-ID: <067.cdb1c404e6310071e3c1a1bb5448fd6d@wordpress.org>

#64967: Bug report – Whitespace / non-breaking spaces removed after save in
Gutenberg
--------------------------+------------------------------
 Reporter:  testwp75      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by devasheeshkaul):

 == Reproduction Report
 === Description
 ❌ This report can't validate whether the issue can be reproduced.


 === Environment
 - WordPress: 7.1-alpha-62161-src
 - PHP: 8.3.30
 - Server: nginx/1.29.7
 - Database: mysqli (Server: 8.4.8 / Client: mysqlnd 8.3.30)
 - Browser: Chrome 146.0.0.0
 - OS: macOS
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None activated
 - Plugins:
   * Test Reports 1.2.1

 === Steps Performed
 1. Copied content from Google Docs/Microsoft Word
 2. Added a new Paragraph block and pasted the copied content
 3. Saved the changes
 4. Verified that no spaces were missing between words

 === Actual Results
 1.  ❌ Error condition couldn't be reproduced.

 === Additional Notes
 - Tested using both Google Docs and Microsoft Word, but the issue could
 not be reproduced in either case
 - Tried making multiple edits before and after pasting, as well as testing
 without any additional changes after pasting but no missing spaces were
 observed
 - Restored an autosave version of the newly pasted content, but the issue
 still could not be reproduced
 - Checked both in the editor and on the frontend; the text was copied and
 displayed correctly

 === Supplemental Artifacts
 Editor:
 [[Image(https://i.ibb.co/8LKYgZqb/Screenshot-2026-04-03-at-3-49-53-PM.png)]]

 Frontend:
 [[Image(https://i.ibb.co/mrvPD5Rj/Screenshot-2026-04-03-at-3-50-03-PM.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64967#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 10:34:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 10:34:57 -0000
Subject: [wp-trac] [WordPress Trac] #65018: WordPress Post Edit Screen
 Content Overflow Issue in version 7.0 RC2
Message-ID: <055.e55fb8bae717ff9f69325eb98e7f0c10@wordpress.org>

#65018: WordPress Post Edit Screen Content Overflow Issue in version 7.0 RC2
----------------------------+-----------------------------
 Reporter:  Pratik Jain     |      Owner:  (none)
     Type:  defect (bug)    |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Administration  |    Version:  trunk
 Severity:  normal          |   Keywords:  needs-patch
  Focuses:  ui, css         |
----------------------------+-----------------------------
 In WordPress 7.0 RC2 version,
 At Post Add / Edit Scrren (Wheather It is Built-in Post Type or Custom
 Post Type) the content after the page heading is coming out of wrapping
 container.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65018>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 10:37:54 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 10:37:54 -0000
Subject: [wp-trac] [WordPress Trac] #65018: WordPress Post Edit Screen
 Content Overflow Issue in version 7.0 RC2
In-Reply-To: <055.e55fb8bae717ff9f69325eb98e7f0c10@wordpress.org>
References: <055.e55fb8bae717ff9f69325eb98e7f0c10@wordpress.org>
Message-ID: <070.4f0501aae6fd03172369c1fe05e4acd5@wordpress.org>

#65018: WordPress Post Edit Screen Content Overflow Issue in version 7.0 RC2
----------------------------+------------------------------
 Reporter:  Pratik Jain     |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  needs-patch     |     Focuses:  ui, css
----------------------------+------------------------------
Changes (by Pratik Jain):

 * Attachment "WordPress-7-1.png" added.

 Normal Scrren

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65018>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 10:38:19 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 10:38:19 -0000
Subject: [wp-trac] [WordPress Trac] #65018: WordPress Post Edit Screen
 Content Overflow Issue in version 7.0 RC2
In-Reply-To: <055.e55fb8bae717ff9f69325eb98e7f0c10@wordpress.org>
References: <055.e55fb8bae717ff9f69325eb98e7f0c10@wordpress.org>
Message-ID: <070.c636747d31ab91ea246feb62d552c078@wordpress.org>

#65018: WordPress Post Edit Screen Content Overflow Issue in version 7.0 RC2
----------------------------+------------------------------
 Reporter:  Pratik Jain     |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  needs-patch     |     Focuses:  ui, css
----------------------------+------------------------------
Changes (by Pratik Jain):

 * Attachment "WordPress-7-2.png" added.

 Overflow when we closly examine it

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65018>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 10:39:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 10:39:18 -0000
Subject: [wp-trac] [WordPress Trac] #64946: Command Palette returns
 inaccurate results when searching for tags
In-Reply-To: <054.8e7b6dabce5080a83107de260f84284b@wordpress.org>
References: <054.8e7b6dabce5080a83107de260f84284b@wordpress.org>
Message-ID: <069.7fdfd3cf9d95527d75db15153a57836d@wordpress.org>

#64946: Command Palette returns inaccurate results when searching for tags
----------------------------+------------------------------
 Reporter:  khushi1501      |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:  6.9
 Severity:  normal          |  Resolution:
 Keywords:  needs-patch     |     Focuses:
----------------------------+------------------------------

Comment (by lakshyajeet):

 This issue is originating within the Command Palette component in the
 Gutenberg plugin. I have opened a tracking issue in the Gutenberg
 repository.

 You can follow the progress here:
 https://github.com/WordPress/gutenberg/issues/77021

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64946#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 10:40:32 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 10:40:32 -0000
Subject: [wp-trac] [WordPress Trac] #65018: WordPress Post Edit Screen
 Content Overflow Issue in version 7.0 RC2
In-Reply-To: <055.e55fb8bae717ff9f69325eb98e7f0c10@wordpress.org>
References: <055.e55fb8bae717ff9f69325eb98e7f0c10@wordpress.org>
Message-ID: <070.0738ed7bc522675d53543277bb2dbdf5@wordpress.org>

#65018: WordPress Post Edit Screen Content Overflow Issue in version 7.0 RC2
----------------------------+------------------------------
 Reporter:  Pratik Jain     |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  needs-patch     |     Focuses:  ui, css
----------------------------+------------------------------

Comment (by Pratik Jain):

 I checked it and I can see below CSS is causing it,


 {{{
 #poststuff #post-body {
   padding: 0;
   margin: 0 -4px;
 }
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65018#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 11:11:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 11:11:06 -0000
Subject: [wp-trac] [WordPress Trac] #64952: Dashboard Quick Draft allows
 creating an empty draft without title or content
In-Reply-To: <054.413d80367fe58cfbdc89759451f05f63@wordpress.org>
References: <054.413d80367fe58cfbdc89759451f05f63@wordpress.org>
Message-ID: <069.dd58d587d0e5b07bf2138d3a2eb14834@wordpress.org>

#64952: Dashboard Quick Draft allows creating an empty draft without title or
content
-------------------------------------+-------------------------------------
 Reporter:  sumitsingh               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  7.1
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-screenshots has-     |     Focuses:  accessibility,
  patch needs-dev-note               |  javascript, administration, coding-
                                     |  standards
-------------------------------------+-------------------------------------
Changes (by torontodigits):

 * keywords:  has-screenshots has-patch => has-screenshots has-patch needs-
     dev-note


Comment:

 @westonruter we've tested alert box in mobile & it looks a bit large as it
 has same font size that is for desktop & in our opnion font size should be
 less as compared to desktop by following UX rules.

 What's your take on mobile version of alert box font size?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64952#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 11:11:47 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 11:11:47 -0000
Subject: [wp-trac] [WordPress Trac] #64952: Dashboard Quick Draft allows
 creating an empty draft without title or content
In-Reply-To: <054.413d80367fe58cfbdc89759451f05f63@wordpress.org>
References: <054.413d80367fe58cfbdc89759451f05f63@wordpress.org>
Message-ID: <069.71cfa225a255c214c8fe104e309a6567@wordpress.org>

#64952: Dashboard Quick Draft allows creating an empty draft without title or
content
-------------------------------------+-------------------------------------
 Reporter:  sumitsingh               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  7.1
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-screenshots has-     |     Focuses:  accessibility,
  patch needs-dev-note               |  javascript, administration, coding-
                                     |  standards
-------------------------------------+-------------------------------------
Changes (by torontodigits):

 * Attachment "Quick Draft Alert Box for mobile version - 64952.png" added.

 Quick Draft Alert Box for mobile version

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64952>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 11:56:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 11:56:21 -0000
Subject: [wp-trac] [WordPress Trac] #64946: Command Palette returns
 inaccurate results when searching for tags
In-Reply-To: <054.8e7b6dabce5080a83107de260f84284b@wordpress.org>
References: <054.8e7b6dabce5080a83107de260f84284b@wordpress.org>
Message-ID: <069.c689b3a980654d2b9c8c7b26f3cd9366@wordpress.org>

#64946: Command Palette returns inaccurate results when searching for tags
----------------------------+--------------------------------
 Reporter:  khushi1501      |       Owner:  (none)
     Type:  defect (bug)    |      Status:  closed
 Priority:  normal          |   Milestone:
Component:  Administration  |     Version:  6.9
 Severity:  normal          |  Resolution:  reported-upstream
 Keywords:  needs-patch     |     Focuses:
----------------------------+--------------------------------
Changes (by wildworks):

 * status:  new => closed
 * resolution:   => reported-upstream
 * milestone:  Awaiting Review =>


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64946#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 12:52:15 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 12:52:15 -0000
Subject: [wp-trac] [WordPress Trac] #65019: Double or single quotation marks
 in tags
Message-ID: <054.ddfa409871730593b02cb81092d72d84@wordpress.org>

#65019: Double or single quotation marks in tags
--------------------------+-----------------------------
 Reporter:  andronasis    |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  General       |    Version:  6.9.4
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65019>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 12:55:25 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 12:55:25 -0000
Subject: [wp-trac] [WordPress Trac] #65019: Double or single quotation
 marks in tags
In-Reply-To: <054.ddfa409871730593b02cb81092d72d84@wordpress.org>
References: <054.ddfa409871730593b02cb81092d72d84@wordpress.org>
Message-ID: <069.09e170bfe25213a52510d37432fc5f47@wordpress.org>

#65019: Double or single quotation marks in tags
--------------------------+------------------------------
 Reporter:  andronasis    |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:  6.9.4
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by andronasis):

 Hello! I noticed that the page code now has single or double quotation
 marks in the tags. I changed the theme to the standard one, disabled
 plugins, everything remains as it was. Example meta name=’robots’ and meta
 name=”robots” and so it is on all pages, that is, double quotes, and
 somewhere single quotes. I want to lead to double quotes. I am attaching a
 screenshot https://disk.yandex.ru/i/eYmRY-TBYI0whg Help please!

 please make double quotes throughout wordpress - this is a good tone for
 developers.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65019#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 13:32:50 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 13:32:50 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2365009=3A_Privacy=3A_?=
 =?utf-8?q?=E2=80=9DCopied!=E2=80=9D_text_is_misaligned?=
In-Reply-To: <053.5ad09e193f9b440670b51501b1539f2b@wordpress.org>
References: <053.5ad09e193f9b440670b51501b1539f2b@wordpress.org>
Message-ID: <068.361b67afcd2f9bb9f26958aba768b9c7@wordpress.org>

#65009: Privacy: ”Copied!” text is misaligned
-------------------------------------------------+-----------------------
 Reporter:  wildworks                            |       Owner:  mukesh27
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  Privacy                              |     Version:
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  admin-reskin has-patch dev-reviewed  |     Focuses:
-------------------------------------------------+-----------------------
Changes (by SergeyBiryukov):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62203" 62203]:
 {{{
 #!CommitTicketReference repository="" revision="62203"
 Admin Reskin: Correct ”Copied!” text alignment on Privacy Policy Guide
 screen.

 Follow-up to [61645].

 Reviewed by wildworks, SergeyBiryukov.
 Merges [62196] to the 7.0 branch.

 Props mukesh27, wildworks, audrasjb, shailu25, anupkankale, kapilpaul,
 SergeyBiryukov.
 Fixes #65009.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65009#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 13:38:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 13:38:21 -0000
Subject: [wp-trac] [WordPress Trac] #64538: memoize wp_normalize_path
In-Reply-To: <055.d0a68ae7d0a278908d25712bd31f710d@wordpress.org>
References: <055.d0a68ae7d0a278908d25712bd31f710d@wordpress.org>
Message-ID: <070.62cc31a33b01580bf7c2613dbda51daf@wordpress.org>

#64538: memoize wp_normalize_path
--------------------------------------+--------------------------
 Reporter:  josephscott               |       Owner:  dmsnell
     Type:  defect (bug)              |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.0
Component:  General                   |     Version:  3.9
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+--------------------------

Comment (by josephscott):

 I have been going through variations of PHP versions and haven't been able
 to reproduce this.  Is it possible that this is something specific to the
 configuration of the host?  Do they have a custom build of PHP?  At this
 point I think we need more data.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64538#comment:32>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 13:54:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 13:54:28 -0000
Subject: [wp-trac] [WordPress Trac] #64950: wp_using_ext_object_cache
 can return null, causing type failures, potential fatals
In-Reply-To: <051.0ea02aed2495587dfabbac6c5957d746@wordpress.org>
References: <051.0ea02aed2495587dfabbac6c5957d746@wordpress.org>
Message-ID: <066.252589f0c07f89883fa1e27068dc7e1d@wordpress.org>

#64950: wp_using_ext_object_cache can return null, causing type failures, potential
fatals
--------------------------+--------------------------
 Reporter:  ronalfy       |       Owner:  westonruter
     Type:  defect (bug)  |      Status:  reviewing
 Priority:  normal        |   Milestone:  7.1
Component:  Cache API     |     Version:  3.7
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+--------------------------

Comment (by ronalfy):

 @westonruter I'm not using a standard WP docker setup, but I can confirm
 our code is running in an activated plugin's constructor. As you
 mentioned, the result is `null`, which is the confusing part of this.

 If the function has returned `bool|null` all along, intentionally or not,
 then for backwards compatibility, I recommend updating the diff to remove
 the casting (essentially leave the function as-is) and update the return
 type to bool|null so a user consuming it can expect both types. We'll also
 want to update the docs because expecting a boolean and then checking that
 var will trigger a fatal.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64950#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 13:58:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 13:58:17 -0000
Subject: [wp-trac] [WordPress Trac] #65020: Connectors: Support custom
 plugin is_active callback in connector registry and plugin status output
Message-ID: <055.d405075069acea8d9ef2197fb71ff599@wordpress.org>

#65020: Connectors: Support custom plugin is_active callback in connector registry
and plugin status output
--------------------------+-------------------------------------
 Reporter:  iamadisingh   |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  AI            |    Version:  trunk
 Severity:  normal        |   Keywords:  needs-testing has-patch
  Focuses:                |
--------------------------+-------------------------------------
 This changeset backports connector improvements from Gutenberg to Core:
 - Extend connector plugin metadata to support optional `plugin.is_active`
 callback.
 - Validate `plugin.is_active` as callable during
 `WP_Connector_Registry::register()`.
 - Use `plugin.is_active` callback when building connector script-module
 data, with fallback to file_exists + is_plugin_active.
 - Update default Akismet connector to use a robust activity check:
 `defined( AKISMET_VERSION ) && class_exists( Akismet, false )`.

 Some plugins (especially MU-loaded or non-standard load paths) cannot be
 reliably detected via is_plugin_active(file) alone. Allowing an explicit
 activity callback provides accurate activation state in connectors UI.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65020>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 14:15:52 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 14:15:52 -0000
Subject: [wp-trac] [WordPress Trac] #65021: Fatal error in
 _wp_get_iframed_editor_assets(): wp_print_media_templates not found
Message-ID: <054.ea0d932820907a7f93a4c539f1b738bd@wordpress.org>

#65021: Fatal error in _wp_get_iframed_editor_assets(): wp_print_media_templates
not found
--------------------------+-----------------------------
 Reporter:  manuelurak    |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Customize     |    Version:  6.9.4
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 When opening the Customizer, a fatal error occurs:

 Fatal error: call_user_func_array(): Argument #1 ($callback) must be
 a valid callback, function "wp_print_media_templates" not found

 The function _wp_get_iframed_editor_assets() in block-editor.php
 creates an isolated script context and calls wp_print_footer_scripts(),
 which fires the print_media_templates action. However, media-template.php
 is not loaded in this isolated context, so wp_print_media_templates()
 is undefined.

 Fix: Add a require_once for media-template.php before
 wp_print_footer_scripts()
 inside _wp_get_iframed_editor_assets().

 Here is my temporary fix for the function:

 {{{#!php
 <?php
 function _wp_get_iframed_editor_assets() {
         global $wp_styles, $wp_scripts;

         // Keep track of the styles and scripts instance to restore later.
         $current_wp_styles  = $wp_styles;
         $current_wp_scripts = $wp_scripts;

         // Create new instances to collect the assets.
         $wp_styles  = new WP_Styles();
         $wp_scripts = new WP_Scripts();

         /*
          * Register all currently registered styles and scripts. The
 actions that
          * follow enqueue assets, but don't necessarily register them.
          */
         $wp_styles->registered  = $current_wp_styles->registered;
         $wp_scripts->registered = $current_wp_scripts->registered;

         /*
          * We generally do not need reset styles for the iframed editor.
          * However, if it's a classic theme, margins will be added to
 every block,
          * which is reset specifically for list items, so classic themes
 rely on
          * these reset styles.
          */
         $wp_styles->done =
                 wp_theme_has_theme_json() ? array( 'wp-reset-editor-
 styles' ) : array();

         wp_enqueue_script( 'wp-polyfill' );
         // Enqueue the `editorStyle` handles for all core block, and
 dependencies.
         wp_enqueue_style( 'wp-edit-blocks' );

         if ( current_theme_supports( 'wp-block-styles' ) ) {
                 wp_enqueue_style( 'wp-block-library-theme' );
         }

         /*
          * We don't want to load EDITOR scripts in the iframe, only
 enqueue
          * front-end assets for the content.
          */
         add_filter( 'should_load_block_editor_scripts_and_styles',
 '__return_false' );
         do_action( 'enqueue_block_assets' );
         remove_filter( 'should_load_block_editor_scripts_and_styles',
 '__return_false' );

         $block_registry = WP_Block_Type_Registry::get_instance();

         /*
          * Additionally, do enqueue `editorStyle` assets for all blocks,
 which
          * contains editor-only styling for blocks (editor content).
          */
         foreach ( $block_registry->get_all_registered() as $block_type ) {
                 if ( isset( $block_type->editor_style_handles ) &&
 is_array( $block_type->editor_style_handles ) ) {
                         foreach ( $block_type->editor_style_handles as
 $style_handle ) {
                                 wp_enqueue_style( $style_handle );
                         }
                 }
         }

         /**
          * Remove the deprecated `print_emoji_styles` handler.
          * It avoids breaking style generation with a deprecation message.
          */
         $has_emoji_styles = has_action( 'wp_print_styles',
 'print_emoji_styles' );
         if ( $has_emoji_styles ) {
                 remove_action( 'wp_print_styles', 'print_emoji_styles' );
         }

         ob_start();
         wp_print_styles();
         wp_print_font_faces();
         wp_print_font_faces_from_style_variations();
         $styles = ob_get_clean();

         if ( $has_emoji_styles ) {
                 add_action( 'wp_print_styles', 'print_emoji_styles' );
         }

         ob_start();
         wp_print_head_scripts();
         if ( ! function_exists( 'wp_print_media_templates' ) ) {
                 require_once ABSPATH . WPINC . '/media-template.php';
         }
         wp_print_footer_scripts();
         $scripts = ob_get_clean();

         // Restore the original instances.
         $wp_styles  = $current_wp_styles;
         $wp_scripts = $current_wp_scripts;

         return array(
                 'styles'  => $styles,
                 'scripts' => $scripts,
         );
 }
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65021>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 15:15:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 15:15:22 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2364967=3A_Bug_report_?=
 =?utf-8?q?=E2=80=93_Whitespace_/_non-breaking_spaces_removed_after_save_i?=
 =?utf-8?q?n_Gutenberg?=
In-Reply-To: <052.3c2e3cbdf85fb7e2fb39e221e5a6c84b@wordpress.org>
References: <052.3c2e3cbdf85fb7e2fb39e221e5a6c84b@wordpress.org>
Message-ID: <067.7a4edc371ba77e047467efc0928ad1f4@wordpress.org>

#64967: Bug report – Whitespace / non-breaking spaces removed after save in
Gutenberg
--------------------------+------------------------------
 Reporter:  testwp75      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by testwp75):

 Hello @devasheeshkaul thanks for trying to help ! We are continuing to try
 to find a simple way to reproduce the problem. However, in your test, this
 could not work because the problem only occurs **between bold letters or
 between bold and regular letters**.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64967#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 15:31:43 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 15:31:43 -0000
Subject: [wp-trac] [WordPress Trac] #65017: Dashboard widgets border
 bottom issue when it is closed in version 7.0 RC2
In-Reply-To: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
References: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
Message-ID: <070.7c0ad35ffb60c7b1ab2e3899b41fda6f@wordpress.org>

#65017: Dashboard widgets border bottom issue when it is closed in version 7.0 RC2
-----------------------------------------+-----------------------
 Reporter:  Pratik Jain                  |       Owner:  (none)
     Type:  defect (bug)                 |      Status:  assigned
 Priority:  normal                       |   Milestone:  7.0
Component:  Administration               |     Version:  trunk
 Severity:  normal                       |  Resolution:
 Keywords:  has-screenshots needs-patch  |     Focuses:  ui, css
-----------------------------------------+-----------------------
Changes (by ankitkumarshah):

 * Attachment "65017.diff" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65017>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 15:38:41 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 15:38:41 -0000
Subject: [wp-trac] [WordPress Trac] #65017: Dashboard widgets border
 bottom issue when it is closed in version 7.0 RC2
In-Reply-To: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
References: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
Message-ID: <070.69d649881a4bfc363e7b8bd55adaed57@wordpress.org>

#65017: Dashboard widgets border bottom issue when it is closed in version 7.0 RC2
-----------------------------------------+-----------------------
 Reporter:  Pratik Jain                  |       Owner:  (none)
     Type:  defect (bug)                 |      Status:  assigned
 Priority:  normal                       |   Milestone:  7.0
Component:  Administration               |     Version:  trunk
 Severity:  normal                       |  Resolution:
 Keywords:  has-screenshots needs-patch  |     Focuses:  ui, css
-----------------------------------------+-----------------------
Changes (by ankitkumarshah):

 * Attachment "65017.2.diff" added.

 Fix linting issue

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65017>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 15:39:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 15:39:06 -0000
Subject: [wp-trac] [WordPress Trac] #65017: Dashboard widgets border
 bottom issue when it is closed in version 7.0 RC2
In-Reply-To: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
References: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
Message-ID: <070.1bda62133cf7ad7687ddae48e3e452a3@wordpress.org>

#65017: Dashboard widgets border bottom issue when it is closed in version 7.0 RC2
---------------------------------------+-----------------------
 Reporter:  Pratik Jain                |       Owner:  (none)
     Type:  defect (bug)               |      Status:  assigned
 Priority:  normal                     |   Milestone:  7.0
Component:  Administration             |     Version:  trunk
 Severity:  normal                     |  Resolution:
 Keywords:  has-screenshots has-patch  |     Focuses:  ui, css
---------------------------------------+-----------------------
Changes (by ankitkumarshah):

 * keywords:  has-screenshots needs-patch => has-screenshots has-patch


Comment:

 == Before
 [[Image(https://i.postimg.cc/9QFFVHxg/Screenshot-2026-04-03-at-9-06-00-PM.png)]]

 == After
 [[Image(https://i.postimg.cc/Sx7NbN7p/Screenshot-2026-04-03-at-9-02-15-PM.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65017#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 15:49:32 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 15:49:32 -0000
Subject: [wp-trac] [WordPress Trac] #65019: Double or single quotation
 marks in tags
In-Reply-To: <054.ddfa409871730593b02cb81092d72d84@wordpress.org>
References: <054.ddfa409871730593b02cb81092d72d84@wordpress.org>
Message-ID: <069.e84e5d7a4bc16e987665c0430d930fb1@wordpress.org>

#65019: Double or single quotation marks in tags
--------------------------+------------------------------
 Reporter:  andronasis    |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  close         |     Focuses:
--------------------------+------------------------------
Changes (by westonruter):

 * keywords:   => close
 * version:  6.9.4 =>


Comment:

 Thanks for opening the ticket.

 However, using single quotes or double quotes for HTML attributes makes no
 difference. They are equivalent. In some cases, the quotes can be omitted
 entirely.

 I don't think consistency in quote style matters to the vast majority of
 developers, so it's not going to be a priority to fix.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65019#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 15:54:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 15:54:22 -0000
Subject: [wp-trac] [WordPress Trac] #65021: Fatal error in
 _wp_get_iframed_editor_assets(): wp_print_media_templates not found
In-Reply-To: <054.ea0d932820907a7f93a4c539f1b738bd@wordpress.org>
References: <054.ea0d932820907a7f93a4c539f1b738bd@wordpress.org>
Message-ID: <069.32a19840fb82fc96a49af7beb92d0f5b@wordpress.org>

#65021: Fatal error in _wp_get_iframed_editor_assets(): wp_print_media_templates
not found
-------------------------------+------------------------------
 Reporter:  manuelurak         |       Owner:  (none)
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Customize          |     Version:
 Severity:  normal             |  Resolution:
 Keywords:  reporter-feedback  |     Focuses:
-------------------------------+------------------------------
Changes (by westonruter):

 * keywords:   => reporter-feedback
 * version:  6.9.4 =>


Comment:

 I'm not able to reproduce a fatal error in the Customizer.

 I just tested in both the Twenty Twenty-Five and Twenty Twenty core
 themes.

 Please provide the minimal steps to reproduce this issue from a fresh
 installation of WordPress.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65021#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 15:57:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 15:57:05 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2364967=3A_Bug_report_?=
 =?utf-8?q?=E2=80=93_Whitespace_/_non-breaking_spaces_removed_after_save_i?=
 =?utf-8?q?n_Gutenberg?=
In-Reply-To: <052.3c2e3cbdf85fb7e2fb39e221e5a6c84b@wordpress.org>
References: <052.3c2e3cbdf85fb7e2fb39e221e5a6c84b@wordpress.org>
Message-ID: <067.9deba411d3cb0ecd6191276c01cad49a@wordpress.org>

#64967: Bug report – Whitespace / non-breaking spaces removed after save in
Gutenberg
--------------------------+------------------------------
 Reporter:  testwp75      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by jorbin):

 @testwp75 Can you confirm if you are seeing this with all plugins
 deactivated while using a default theme? Additionally, since you mentioned
 this is after copying fromm google docs and word, can you share some
 example documents that demonstrate this for you.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64967#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 16:03:59 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 16:03:59 -0000
Subject: [wp-trac] [WordPress Trac] #65014: Site Health: Error icon
 missing due to missing dashicons class
In-Reply-To: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
References: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
Message-ID: <069.095b4f10be029572215f8434aabb559a@wordpress.org>

#65014: Site Health: Error icon missing due to missing dashicons class
-------------------------------------+-------------------------------------
 Reporter:  valani9099               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  7.1
Component:  Site Health              |     Version:  5.3
 Severity:  normal                   |  Resolution:
 Keywords:  has-screenshots needs-   |     Focuses:  ui, css,
  patch                              |  administration
-------------------------------------+-------------------------------------
Changes (by sabernhardt):

 * keywords:  has-screenshots has-patch => has-screenshots needs-patch
 * version:  trunk => 5.3
 * component:  Administration => Site Health
 * milestone:  Awaiting Review => 7.1


Old description:

> Tested on WordPress 7.0-RC2, the error icon is not displayed in:
>
> Tools → Site Health → Status
>
> ### Issue
> The error indicator span is missing the required `dashicons` class.
>
> Current markup:
> <span class="error"></span>
>
> Expected markup:
> <span class="error dashicons"></span>
>
> Because of the missing `dashicons` class, the icon is not rendered.
>
> ### Steps to Reproduce
> 1. Install WordPress 7.0-RC2
> 2. Go to Tools → Site Health → Status
> 3. Trigger an error (e.g., block external requests or simulate failure)
> 4. Observe missing icon next to the error message
>
> ### Expected Behavior
> The error icon (dashicon) should be visible.
>
> ### Actual Behavior
> No icon is displayed.
>
> ### Proposed Fix
> Add the `dashicons` class to the error span element.
>
> ### Additional Notes
> I have verified that adding the `dashicons` class fixes the issue.
>
> Screenshots attached:
> - Before fix (icon missing)
> - After fix (icon visible)

New description:

 Tested on WordPress 7.0-RC2, the error icon is not displayed in:

 Tools → Site Health → Status

 ==== Issue
 The error indicator span is missing the required `dashicons` class.

 Current markup:
 `<span class="error"></span>`

 Expected markup:
 `<span class="error dashicons"></span>`

 Because of the missing `dashicons` class, the icon is not rendered.

 ==== Steps to Reproduce
 1. Install WordPress 7.0-RC2
 2. Go to Tools → Site Health → Status
 3. Trigger an error (e.g., block external requests or simulate failure)
 4. Observe missing icon next to the error message

 ==== Expected Behavior
 The error icon (dashicon) should be visible.

 ==== Actual Behavior
 No icon is displayed.

 ==== Proposed Fix
 Add the `dashicons` class to the error span element.

 ==== Additional Notes
 I have verified that adding the `dashicons` class fixes the issue.

 Screenshots attached:
 - Before fix (icon missing)
 - After fix (icon visible)

--

Comment:

 [45309] removed lines of CSS in favor of adding the `dashicons` class, and
 it missed at least this one message.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65014#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 16:42:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 16:42:48 -0000
Subject: [wp-trac] [WordPress Trac] #64536: About Page - 7.0
In-Reply-To: <051.70759fa0a8836490f78fb36a7530ec61@wordpress.org>
References: <051.70759fa0a8836490f78fb36a7530ec61@wordpress.org>
Message-ID: <066.215e3dfda8a865536176d37585f6f1ca@wordpress.org>

#64536: About Page - 7.0
----------------------------+---------------------
 Reporter:  desrosj         |       Owner:  (none)
     Type:  task (blessed)  |      Status:  new
 Priority:  normal          |   Milestone:  7.0
Component:  Help/About      |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  needs-design    |     Focuses:
----------------------------+---------------------

Comment (by Benjamin_Zekavica):

 @parinpanjari That looks amazing :) Good job! I think the orange
 background is a bit too intense here. Maybe a lighter shade would work
 better.

 See: https://www.directupload.eu/file/d/9243/j24ow9kg_png.htm

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64536#comment:25>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 17:59:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 17:59:29 -0000
Subject: [wp-trac] [WordPress Trac] #65022: Posts list: replace (no title)
 filler when a title isn't site with something more useful.
Message-ID: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>

#65022: Posts list: replace (no title) filler when a title isn't site with
something more useful.
-------------------------------+-----------------------------
 Reporter:  annezazu           |      Owner:  (none)
     Type:  enhancement        |     Status:  new
 Priority:  normal             |  Milestone:  Awaiting Review
Component:  Posts, Post Types  |    Version:
 Severity:  normal             |   Keywords:
  Focuses:  administration     |
-------------------------------+-----------------------------
 Pulled from here after @matt shared it as an area to improve:
 http://scripting.com/2026/04/03.html#a140913

 While we could show first N characters of a post when title is empty,
 there are also other ideas to consider to both still reflect a post title
 is missing but to make it easier for the person skimming to know what the
 post is likely about. Speaking personally, I like to see (no title) or
 some indication a title is missing so I can fill in.

 Let's discuss ideas and implement a solution based on the discussion.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65022>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 18:02:24 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 18:02:24 -0000
Subject: [wp-trac] [WordPress Trac] #63085: "Login details" spam sent by
 from the account registration page
In-Reply-To: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
References: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
Message-ID: <066.dcd970dd34143f25530125a5cded23bd@wordpress.org>

#63085: "Login details" spam sent by from the account registration page
------------------------------------+------------------------------
 Reporter:  cweiske                 |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Login and Registration  |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:                          |     Focuses:
------------------------------------+------------------------------
Changes (by cweiske):

 * Attachment "63085-registration-spam.diff" added.

 Patch

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63085>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 18:04:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 18:04:05 -0000
Subject: [wp-trac] [WordPress Trac] #63085: "Login details" spam sent by
 from the account registration page
In-Reply-To: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
References: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
Message-ID: <066.9041c395267eedab37a3c6984c888db1@wordpress.org>

#63085: "Login details" spam sent by from the account registration page
------------------------------------+------------------------------
 Reporter:  cweiske                 |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Login and Registration  |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch               |     Focuses:
------------------------------------+------------------------------
Changes (by cweiske):

 * keywords:   => has-patch


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63085#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 18:29:51 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 18:29:51 -0000
Subject: [wp-trac] [WordPress Trac] #65014: Site Health: Error icon
 missing due to missing dashicons class
In-Reply-To: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
References: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
Message-ID: <069.60c7a70703f9e3a86b0296aa6ac95cff@wordpress.org>

#65014: Site Health: Error icon missing due to missing dashicons class
-------------------------------------+-------------------------------------
 Reporter:  valani9099               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  7.1
Component:  Site Health              |     Version:  5.3
 Severity:  normal                   |  Resolution:
 Keywords:  has-screenshots needs-   |     Focuses:  ui, css,
  patch                              |  administration
-------------------------------------+-------------------------------------
Changes (by valani9099):

 * Attachment "65014.diff" added.

 Attaching patch for missing dashicons class on error span  in Site Health
 status screen. Verified fix manually. Consistent with changes from #45309.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65014>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 18:47:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 18:47:28 -0000
Subject: [wp-trac] [WordPress Trac] #65014: Site Health: Error icon
 missing due to missing dashicons class
In-Reply-To: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
References: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
Message-ID: <069.ba5a3f93c2c3150508c36734c95e14f8@wordpress.org>

#65014: Site Health: Error icon missing due to missing dashicons class
-------------------------------------+-------------------------------------
 Reporter:  valani9099               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  7.1
Component:  Site Health              |     Version:  5.3
 Severity:  normal                   |  Resolution:
 Keywords:  has-screenshots has-     |     Focuses:  ui, css,
  patch                              |  administration
-------------------------------------+-------------------------------------

Comment (by valani9099):

 https://github.com/WordPress/wordpress-develop/pull/11440

 Patch attached and PR created for review.

 This restores the missing `dashicons` class for the error icon in the Site
 Health screen.

 As noted in changeset [45309], CSS was removed in favor of dashicons, but
 this instance was missed.

 Tested using the `pre_http_request` filter method to simulate failure, and
 confirmed the icon now displays correctly.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65014#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 19:15:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 19:15:26 -0000
Subject: [wp-trac] [WordPress Trac] #65023: Don't use (no title) in place of
 text from body of post in Posts list
Message-ID: <053.0429a4c35d1df1f6ec0a0783e9df8ce7@wordpress.org>

#65023: Don't use (no title) in place of text from body of post in Posts list
-------------------------------+------------------------------------------
 Reporter:  davewiner          |      Owner:  (none)
     Type:  enhancement        |     Status:  new
 Priority:  normal             |  Milestone:  Awaiting Review
Component:  Posts, Post Types  |    Version:  6.9.4
 Severity:  normal             |   Keywords:  needs-design has-screenshots
  Focuses:                     |
-------------------------------+------------------------------------------
 In the Posts list, if an item doesn't have a title, (no title) in place of
 the title isn't helpful, and makes it difficult when a page has lots of
 singular posts.

 Suggested solution: Grab the first N chars of the body, or first sentence
 (easy with regex) or add a tool tip with the same text.

 I write a lot of "singular" posts, ie posts without titles.

 Happy to share JS code that works.

 [[Image(https://imgs.scripting.com/2026/04/03/noTitlePosts.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65023>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 19:16:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 19:16:18 -0000
Subject: [wp-trac] [WordPress Trac] #65023: Don't use (no title) in
 place of text from body of post in Posts list
In-Reply-To: <053.0429a4c35d1df1f6ec0a0783e9df8ce7@wordpress.org>
References: <053.0429a4c35d1df1f6ec0a0783e9df8ce7@wordpress.org>
Message-ID: <068.d606aa556bb2116bda31960064068988@wordpress.org>

#65023: Don't use (no title) in place of text from body of post in Posts list
------------------------------------------+------------------------------
 Reporter:  davewiner                     |       Owner:  (none)
     Type:  enhancement                   |      Status:  new
 Priority:  normal                        |   Milestone:  Awaiting Review
Component:  Posts, Post Types             |     Version:  6.9.4
 Severity:  normal                        |  Resolution:
 Keywords:  needs-design has-screenshots  |     Focuses:
------------------------------------------+------------------------------
Changes (by davewiner):

 * Attachment "image (2).png" added.

 Screen shot of Posts page with lots of (no title) entries.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65023>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 20:23:00 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 20:23:00 -0000
Subject: [wp-trac] [WordPress Trac] #65001: Hover on Upload files media
 Library tabs and drop to upload file overlay color has still old color
In-Reply-To: <053.1e9023874452fde73c1121655252bc0d@wordpress.org>
References: <053.1e9023874452fde73c1121655252bc0d@wordpress.org>
Message-ID: <068.73349745cc3aeb257f86f6da95a0c6d1@wordpress.org>

#65001: Hover on Upload files media Library tabs and drop to upload file overlay
color has still old color
-------------------------------------------+----------------------------
 Reporter:  opurockey                      |       Owner:  joedolson
     Type:  defect (bug)                   |      Status:  closed
 Priority:  normal                         |   Milestone:  7.0
Component:  Media                          |     Version:  trunk
 Severity:  normal                         |  Resolution:  fixed
 Keywords:  has-patch commit dev-reviewed  |     Focuses:  accessibility
-------------------------------------------+----------------------------
Changes (by joedolson):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62204" 62204]:
 {{{
 #!CommitTicketReference repository="" revision="62204"
 Media: Update upload file overlay colors.

 Update the colors used for the file upload overlay mask to use the new
 admin theme colors.

 Reviewed by wildworks.
 Merges 62199 to the 7.0 branch.

 Props opurockey, huzaifaalmesbah, wildworks, audrasjb, manhar, joedolson.
 Fixes #65001.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65001#comment:18>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr  3 21:58:51 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 03 Apr 2026 21:58:51 -0000
Subject: [wp-trac] [WordPress Trac] #64225: Test tool and unit test
 improvements for 7.0
In-Reply-To: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
References: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
Message-ID: <066.d30112bf9dfb80b0d0d3795ad6143d4a@wordpress.org>

#64225: Test tool and unit test improvements for 7.0
--------------------------------------+---------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  task (blessed)            |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by SergeyBiryukov):

 In [changeset:"62205" 62205]:
 {{{
 #!CommitTicketReference repository="" revision="62205"
 Tests: Move data providers and helpers in `Tests_REST_Server` for
 consistency.

 This ensures that data providers or helper functions used by a single test
 are located next to the test, for consistency with the rest of the test
 suite.

 Follow-up to [37905], [37943], [45809], [47239], [47260], [47351],
 [48947], [49252], [49257], [51960], [53110], [56096], [59032].

 See #64225.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64225#comment:52>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 03:45:42 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 03:45:42 -0000
Subject: [wp-trac] [WordPress Trac] #65014: Site Health: Error icon
 missing due to missing dashicons class
In-Reply-To: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
References: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
Message-ID: <069.8533c3c7793a291a105e859a20f97133@wordpress.org>

#65014: Site Health: Error icon missing due to missing dashicons class
-------------------------------------+-------------------------------------
 Reporter:  valani9099               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  7.1
Component:  Site Health              |     Version:  5.3
 Severity:  normal                   |  Resolution:
 Keywords:  has-screenshots has-     |     Focuses:  ui, css,
  patch                              |  administration
-------------------------------------+-------------------------------------

Comment (by wildworks):

 https://github.com/WordPress/wordpress-develop/pull/11440 looks good to
 me.

 However, due to the coordination with the 7.0 release, it would be best
 not to commit to trunk yet.

 https://make.wordpress.org/core/2026/04/02/the-path-forward-for-
 wordpress-7-0/#:~:text=trunk%20is%20closed%20to%20commits%20for%20the%207.1%20release%20until%20further%20notice.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65014#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 05:43:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 05:43:17 -0000
Subject: [wp-trac] [WordPress Trac] #65017: Dashboard widgets border
 bottom issue when it is closed in version 7.0 RC2
In-Reply-To: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
References: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
Message-ID: <070.e8b7df35a742d560573c07bc84820d60@wordpress.org>

#65017: Dashboard widgets border bottom issue when it is closed in version 7.0 RC2
---------------------------------------+-----------------------
 Reporter:  Pratik Jain                |       Owner:  audrasjb
     Type:  defect (bug)               |      Status:  accepted
 Priority:  normal                     |   Milestone:  7.0
Component:  Administration             |     Version:  trunk
 Severity:  normal                     |  Resolution:
 Keywords:  has-screenshots has-patch  |     Focuses:  ui, css
---------------------------------------+-----------------------
Changes (by audrasjb):

 * owner:  (none) => audrasjb
 * status:  assigned => accepted


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65017#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 05:56:10 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 05:56:10 -0000
Subject: [wp-trac] [WordPress Trac] #65017: Dashboard widgets border
 bottom issue when it is closed in version 7.0 RC2
In-Reply-To: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
References: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
Message-ID: <070.85383bf0c78daff03432ba57d4a76086@wordpress.org>

#65017: Dashboard widgets border bottom issue when it is closed in version 7.0 RC2
----------------------------------------------+-----------------------
 Reporter:  Pratik Jain                       |       Owner:  audrasjb
     Type:  defect (bug)                      |      Status:  accepted
 Priority:  normal                            |   Milestone:  7.0
Component:  Administration                    |     Version:  trunk
 Severity:  normal                            |  Resolution:
 Keywords:  has-screenshots has-patch commit  |     Focuses:  ui, css
----------------------------------------------+-----------------------
Changes (by audrasjb):

 * keywords:  has-screenshots has-patch => has-screenshots has-patch commit


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65017#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 05:59:25 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 05:59:25 -0000
Subject: [wp-trac] [WordPress Trac] #65023: Don't use (no title) in
 place of text from body of post in Posts list
In-Reply-To: <053.0429a4c35d1df1f6ec0a0783e9df8ce7@wordpress.org>
References: <053.0429a4c35d1df1f6ec0a0783e9df8ce7@wordpress.org>
Message-ID: <068.4242e10c84b96f2f0cbaf5f9dbc4fc06@wordpress.org>

#65023: Don't use (no title) in place of text from body of post in Posts list
-------------------------------+------------------------
 Reporter:  davewiner          |       Owner:  (none)
     Type:  enhancement        |      Status:  closed
 Priority:  normal             |   Milestone:
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:  duplicate
 Keywords:  has-screenshots    |     Focuses:
-------------------------------+------------------------
Changes (by sabernhardt):

 * keywords:  needs-design has-screenshots => has-screenshots
 * status:  new => closed
 * version:  6.9.4 =>
 * resolution:   => duplicate
 * milestone:  Awaiting Review =>


Comment:

 Duplicate of #65022.

 I'm closing this to keep the discussion on one ticket.

 For now, you could show any excerpt—manual or automated—for all posts in
 the list:
 1. Go to Screen Options.
 2. Select the Extended view.
 3. Apply changes.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65023#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 06:00:52 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 06:00:52 -0000
Subject: [wp-trac] [WordPress Trac] #65023: Don't use (no title) in
 place of text from body of post in Posts list
In-Reply-To: <053.0429a4c35d1df1f6ec0a0783e9df8ce7@wordpress.org>
References: <053.0429a4c35d1df1f6ec0a0783e9df8ce7@wordpress.org>
Message-ID: <068.35ade4d1bafc3e1ba02b039d6ada9baf@wordpress.org>

#65023: Don't use (no title) in place of text from body of post in Posts list
-------------------------------+------------------------
 Reporter:  davewiner          |       Owner:  (none)
     Type:  enhancement        |      Status:  closed
 Priority:  normal             |   Milestone:
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:  duplicate
 Keywords:  has-screenshots    |     Focuses:
-------------------------------+------------------------
Changes (by sabernhardt):

 * Attachment "posts-list-extended-view.png" added.

 Extended view shows excerpts for posts (the last post does not have an
 automated excerpt because it only has a Search block, no text)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65023>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 06:01:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 06:01:18 -0000
Subject: [wp-trac] [WordPress Trac] #65022: Posts list: replace (no
 title) filler when a title isn't set with something more useful. (was:
 Posts list: replace (no title) filler when a title isn't site with
 something more useful.)
In-Reply-To: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
References: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
Message-ID: <067.c1d5fd95e9708b05686b29aa544a5ddb@wordpress.org>

#65022: Posts list: replace (no title) filler when a title isn't set with something
more useful.
-------------------------------+-----------------------------
 Reporter:  annezazu           |       Owner:  (none)
     Type:  enhancement        |      Status:  new
 Priority:  normal             |   Milestone:  Future Release
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:  administration
-------------------------------+-----------------------------
Changes (by sabernhardt):

 * milestone:  Awaiting Review => Future Release


Old description:

> Pulled from here after @matt shared it as an area to improve:
> http://scripting.com/2026/04/03.html#a140913
>
> While we could show first N characters of a post when title is empty,
> there are also other ideas to consider to both still reflect a post title
> is missing but to make it easier for the person skimming to know what the
> post is likely about. Speaking personally, I like to see (no title) or
> some indication a title is missing so I can fill in.
>
> Let's discuss ideas and implement a solution based on the discussion.

New description:

 Pulled from here after @matt shared it as an area to improve:
 [http://scripting.com/2026/04/03.html#a140913]

 While we could show first N characters of a post when title is empty,
 there are also other ideas to consider to both still reflect a post title
 is missing but to make it easier for the person skimming to know what the
 post is likely about. Speaking personally, I like to see (no title) or
 some indication a title is missing so I can fill in.

 Let's discuss ideas and implement a solution based on the discussion.

--

Comment:

 @davewiner shared this on #65023:

 > In the Posts list, if an item doesn't have a title, (no title) in place
 of the title isn't helpful, and makes it difficult when a page has lots of
 singular posts.
 >
 > Suggested solution: Grab the first N chars of the body, or first
 sentence (easy with regex) or add a tool tip with the same text.
 >
 > I write a lot of "singular" posts, ie posts without titles.

 [[Image(https://core.trac.wordpress.org/raw-
 attachment/ticket/65023/image%20(2).png, alt="Posts list in Compact view",
 title="")]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65022#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 06:02:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 06:02:17 -0000
Subject: [wp-trac] [WordPress Trac] #65022: Posts list: replace (no
 title) filler when a title isn't set with something more useful.
In-Reply-To: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
References: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
Message-ID: <067.675196a2dc6895f6e768342f877bd763@wordpress.org>

#65022: Posts list: replace (no title) filler when a title isn't set with something
more useful.
-------------------------------+-----------------------------
 Reporter:  annezazu           |       Owner:  (none)
     Type:  enhancement        |      Status:  new
 Priority:  normal             |   Milestone:  Future Release
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:  administration
-------------------------------+-----------------------------
Changes (by sabernhardt):

 * Attachment "65022.diff" added.

 proof of concept for showing excerpts in the Compact view when the post
 has no title

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65022>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 06:04:43 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 06:04:43 -0000
Subject: [wp-trac] [WordPress Trac] #65022: Posts list: replace (no
 title) filler when a title isn't set with something more useful.
In-Reply-To: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
References: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
Message-ID: <067.ed908bf547efb5d71c0928b4ebc87dd1@wordpress.org>

#65022: Posts list: replace (no title) filler when a title isn't set with something
more useful.
-------------------------------+-----------------------------
 Reporter:  annezazu           |       Owner:  (none)
     Type:  enhancement        |      Status:  new
 Priority:  normal             |   Milestone:  Future Release
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:  administration
-------------------------------+-----------------------------
Changes (by sabernhardt):

 * Attachment "show-excerpt-in-compact-view.png" added.

 proof of concept: excerpt showing for post without a title in Compact view

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65022>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 06:09:24 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 06:09:24 -0000
Subject: [wp-trac] [WordPress Trac] #65022: Posts list: replace (no
 title) filler when a title isn't set with something more useful.
In-Reply-To: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
References: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
Message-ID: <067.92cb3e8c47e35e106ecb8e2992b92a91@wordpress.org>

#65022: Posts list: replace (no title) filler when a title isn't set with something
more useful.
-------------------------------+-----------------------------
 Reporter:  annezazu           |       Owner:  (none)
     Type:  enhancement        |      Status:  new
 Priority:  normal             |   Milestone:  Future Release
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:  administration
-------------------------------+-----------------------------

Comment (by sabernhardt):

 Extended view (excerpt mode) already can show standard post excerpts in
 the posts list. With a small edit to the conditions, the Compact view
 could show excerpts for any posts that lack a title.
 - That still notifies people who need titles for every post when the title
 is missing.
 - In a way, it ignores the user's view preference, because more
 information //should// help in this situation.

 The image includes three posts:
 1. Post without a title but with content, which shows the excerpt.
 2. Post with a title and with content, which shows the title without
 adding the excerpt.
 3. Post without a title or an excerpt because the post content has no text
 (only a Search block).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65022#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 06:17:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 06:17:07 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated (missing gettext)
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.e490986a0c194a5f567a41bc1ced9911@wordpress.org>

#65015: Connectors: Several strings are not translated (missing gettext)
--------------------------+------------------------------
 Reporter:  369work       |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  I18N          |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+------------------------------
Changes (by sabernhardt):

 * Attachment "Connectors-screen-Japanese.png" added.

 Connectors screen in Japanese

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 06:35:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 06:35:17 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated (was: Connectors: Several strings are not translated
 (missing gettext))
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.fc5039f072439018af1be69252f1c72a@wordpress.org>

#65015: Connectors: Several strings are not translated
--------------------------+---------------------
 Reporter:  369work       |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  I18N          |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+---------------------
Changes (by sabernhardt):

 * keywords:  needs-patch =>
 * milestone:  Awaiting Review => 7.0


Old description:

> In the Connectors section of the WordPress admin panel, several strings
> remain in English regardless of the site language setting.
> Steps to reproduce:
>
> Install WordPress 7.0 RC2
> Navigate to the Connectors section in the admin panel
> Switch the site language to any non-English language
>
> Strings that are not translated:
>
> "Text and image generation with Gemini and Imagen."
> "If the connector you need is not listed"
> "All of your API keys and credentials are stored here and shared across
> plugins. Configure once and use everywhere."
> "Set up" (button)
>
> Expected behavior:
> All of the above strings should be translatable, as the "Install" and
> "Cancel" buttons already are.
> Actual behavior:
> The strings listed above are not translated and remain in English
> regardless of the site language setting.
> WordPress version: 7.0 RC2

New description:

 In the Connectors section of the WordPress admin panel, several strings
 remain in English regardless of the site language setting.

 ==== Steps to reproduce:

 - Install WordPress 7.0 RC2
 - Switch the site language to any non-English language
 - Navigate to the Connectors section in the admin panel

 Strings that are not translated:

 - "Text and image generation with Gemini and Imagen."
 - "If the connector you need is not listed"
 - "All of your API keys and credentials are stored here and shared across
 plugins. Configure once and use everywhere."
 - "Set up" (button)

 ==== Expected behavior:

 All of the above strings should be translatable, as the "Install" and
 "Cancel" buttons already are.

 ==== Actual behavior:

 The strings listed above are not translated and remain in English
 regardless of the site language setting.

 WordPress version: 7.0 RC2

--

Comment:

 I have the translation for the Gemini and Imagen string now because that
 is in the `connectors.php` file, but the JSON translations are not used
 yet.

 All Japanese string translations for WordPress 7.0 have been completed,
 including those related to
 [https://translate.wordpress.org/projects/wp/dev/ja/default/?filters%5Bterm%5D=connector
 connectors].

 The
 [https://github.com/WordPress/gutenberg/blob/6dab881281120bc406a9621d0344e212441a92c2/routes
 /connectors-home/stage.tsx#L55 strings] have the `__()` function, and the
 script requests the `i18n` package.

 The script module includes some translations:
 {{{
 <script id="wp-script-module-data-options-connectors-wp-admin"
 type="application/json">
 {"connectors":{"anthropic":{"name":"Anthropic","description":"Claude を使
 用したテキスト生成。
 ","logoUrl":null,"type":"ai_provider","authentication":{"method":"api_key","settingName":"connectors_ai_anthropic_api_key","credentialsUrl":"https://platform.claude.com/settings/keys","keySource":"none","isConnected":false},"plugin":{"file
 ":"ai-provider-for-
 anthropic/plugin.php","isInstalled":false,"isActivated":false}},"google":{"name":"Google","description":"Gemini
 と Imagen による、テキストおよび画像の生成。
 ","logoUrl":null,"type":"ai_provider","authentication":{"method":"api_key","settingName":"connectors_ai_google_api_key","credentialsUrl":"https://aistudio.google.com
 /api-keys","keySource":"none","isConnected":false},"plugin":{"file":"ai-
 provider-for-
 google/plugin.php","isInstalled":false,"isActivated":false}},"openai":{"name":"OpenAI","description":"GPT
 と Dall-E による、テキストおよび画像の生成。
 ","logoUrl":null,"type":"ai_provider","authentication":{"method":"api_key","settingName":"connectors_ai_openai_api_key","credentialsUrl":"https://platform.openai.com
 /api-keys","keySource":"none","isConnected":false},"plugin":{"file":"ai-
 provider-for-
 openai/plugin.php","isInstalled":false,"isActivated":false}}}}
 </script>
 }}}

 I remember having a similar issue earlier with strings in JavaScript when
 using trunk or beta/RC, and I think it resolved itself in the general
 release. However, this might need to assign the translations for the
 script module.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 06:38:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 06:38:07 -0000
Subject: [wp-trac] [WordPress Trac] #65017: Dashboard widgets border
 bottom issue when it is closed in version 7.0 RC2
In-Reply-To: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
References: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
Message-ID: <070.f60ea8d95ac827645bd4b46d9acf989a@wordpress.org>

#65017: Dashboard widgets border bottom issue when it is closed in version 7.0 RC2
----------------------------------------------+-----------------------
 Reporter:  Pratik Jain                       |       Owner:  audrasjb
     Type:  defect (bug)                      |      Status:  closed
 Priority:  normal                            |   Milestone:  7.0
Component:  Administration                    |     Version:  trunk
 Severity:  normal                            |  Resolution:  fixed
 Keywords:  has-screenshots has-patch commit  |     Focuses:  ui, css
----------------------------------------------+-----------------------
Changes (by audrasjb):

 * status:  accepted => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62206" 62206]:
 {{{
 #!CommitTicketReference repository="" revision="62206"
 Administration: Improve dashboard widgets border styles.

 This changeset fixes a CSS glitch on dashboard widgets bottom border when
 they are collapsed.

 Follow-up to [61646].

 Props pratik-jain, audrasjb, ankitkumarshah.
 Fixes #65017.
 See #64549.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65017#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 06:38:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 06:38:07 -0000
Subject: [wp-trac] [WordPress Trac] #64549: Admin Reskin: Update card
 and metabox styling to align with WordPress Design System
In-Reply-To: <055.2b95acb44717d717d3e8d12a7e1a4a5f@wordpress.org>
References: <055.2b95acb44717d717d3e8d12a7e1a4a5f@wordpress.org>
Message-ID: <070.82b5f445a71a870e889636bf011be048@wordpress.org>

#64549: Admin Reskin: Update card and metabox styling to align with WordPress
Design System
----------------------------+-------------------------------------
 Reporter:  fabiankaegy     |       Owner:  joedolson
     Type:  enhancement     |      Status:  closed
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:  fixed
 Keywords:  has-patch       |     Focuses:  ui, accessibility, css
----------------------------+-------------------------------------

Comment (by audrasjb):

 In [changeset:"62206" 62206]:
 {{{
 #!CommitTicketReference repository="" revision="62206"
 Administration: Improve dashboard widgets border styles.

 This changeset fixes a CSS glitch on dashboard widgets bottom border when
 they are collapsed.

 Follow-up to [61646].

 Props pratik-jain, audrasjb, ankitkumarshah.
 Fixes #65017.
 See #64549.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64549#comment:18>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 06:38:46 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 06:38:46 -0000
Subject: [wp-trac] [WordPress Trac] #65017: Dashboard widgets border
 bottom issue when it is closed in version 7.0 RC2
In-Reply-To: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
References: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
Message-ID: <070.4a4825601bbd794e28ea8493870d9136@wordpress.org>

#65017: Dashboard widgets border bottom issue when it is closed in version 7.0 RC2
-------------------------------------------------+-------------------------
 Reporter:  Pratik Jain                          |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-screenshots has-patch dev-       |     Focuses:  ui, css
  feedback                                       |
-------------------------------------------------+-------------------------
Changes (by audrasjb):

 * keywords:  has-screenshots has-patch commit => has-screenshots has-patch
     dev-feedback


Comment:

 Reopening for 7.0 backport.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65017#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 06:44:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 06:44:12 -0000
Subject: [wp-trac] [WordPress Trac] #63909: Automatic excerpts: support
 lists in addition to columns and groups
In-Reply-To: <051.082bb765fdfdf1bd63d2da2e3006ba4a@wordpress.org>
References: <051.082bb765fdfdf1bd63d2da2e3006ba4a@wordpress.org>
Message-ID: <066.6407848823f472234aa2e2511ce51da5@wordpress.org>

#63909: Automatic excerpts: support lists in addition to columns and groups
----------------------------------------------------+---------------------
 Reporter:  jeherve                                 |       Owner:  (none)
     Type:  defect (bug)                            |      Status:  new
 Priority:  normal                                  |   Milestone:  7.1
Component:  Editor                                  |     Version:  5.8
 Severity:  normal                                  |  Resolution:
 Keywords:  has-patch has-unit-tests needs-testing  |     Focuses:
----------------------------------------------------+---------------------
Changes (by audrasjb):

 * keywords:  has-patch has-unit-tests => has-patch has-unit-tests needs-
     testing
 * milestone:  Awaiting Review => 7.1


Comment:

 Good point. The propose PR looks good to me, milestoning it to 7.1.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63909#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 06:45:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 06:45:29 -0000
Subject: [wp-trac] [WordPress Trac] #64944: Generated Excerpts - Missing
 white space when stripping <br>s generated in paragraph block, verse block,
 etc.
In-Reply-To: <055.8505625efe4ec85c57d03df6fb669dac@wordpress.org>
References: <055.8505625efe4ec85c57d03df6fb669dac@wordpress.org>
Message-ID: <070.d8bb541e92acbe7c81287decbbc8bf63@wordpress.org>

#64944: Generated Excerpts - Missing white space when stripping <br>s generated in
paragraph block, verse block, etc.
----------------------------------------------------+---------------------
 Reporter:  addiestavlo                             |       Owner:  (none)
     Type:  defect (bug)                            |      Status:  new
 Priority:  normal                                  |   Milestone:  7.1
Component:  Formatting                              |     Version:  5.0
 Severity:  normal                                  |  Resolution:
 Keywords:  has-patch has-unit-tests needs-testing  |     Focuses:
----------------------------------------------------+---------------------
Changes (by audrasjb):

 * keywords:  has-patch has-unit-tests => has-patch has-unit-tests needs-
     testing
 * version:   => 5.0
 * milestone:  Awaiting Review => 7.1


Comment:

 Moving to 7.1 as we have a patch ready to be tested.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64944#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 06:46:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 06:46:09 -0000
Subject: [wp-trac] [WordPress Trac] #63909: Automatic excerpts: support
 lists in addition to columns and groups
In-Reply-To: <051.082bb765fdfdf1bd63d2da2e3006ba4a@wordpress.org>
References: <051.082bb765fdfdf1bd63d2da2e3006ba4a@wordpress.org>
Message-ID: <066.ea8b6c317100f1c34d5b3933a9296a21@wordpress.org>

#63909: Automatic excerpts: support lists in addition to columns and groups
-------------------------------------------------+-------------------------
 Reporter:  jeherve                              |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  7.1
Component:  Editor                               |     Version:  5.8
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests needs-      |     Focuses:
  testing                                        |
-------------------------------------------------+-------------------------
Changes (by audrasjb):

 * owner:  (none) => audrasjb
 * status:  new => accepted


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63909#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 06:46:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 06:46:26 -0000
Subject: [wp-trac] [WordPress Trac] #64944: Generated Excerpts - Missing
 white space when stripping <br>s generated in paragraph block, verse block,
 etc.
In-Reply-To: <055.8505625efe4ec85c57d03df6fb669dac@wordpress.org>
References: <055.8505625efe4ec85c57d03df6fb669dac@wordpress.org>
Message-ID: <070.4671c56255a1b09d6c6518cb06c967a6@wordpress.org>

#64944: Generated Excerpts - Missing white space when stripping <br>s generated in
paragraph block, verse block, etc.
-------------------------------------------------+-------------------------
 Reporter:  addiestavlo                          |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  7.1
Component:  Formatting                           |     Version:  5.0
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests needs-      |     Focuses:
  testing                                        |
-------------------------------------------------+-------------------------
Changes (by audrasjb):

 * owner:  (none) => audrasjb
 * status:  new => accepted


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64944#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 06:48:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 06:48:13 -0000
Subject: [wp-trac] [WordPress Trac] #64976: Admin Style: Plugin links
 change styles on updates on 7.0
In-Reply-To: <052.33a9a520dd04c4f79918027e12c9cff4@wordpress.org>
References: <052.33a9a520dd04c4f79918027e12c9cff4@wordpress.org>
Message-ID: <067.e914384599cccead41a5c6010aa6794e@wordpress.org>

#64976: Admin Style: Plugin links change styles on updates on 7.0
-------------------------------------------------+-------------------------
 Reporter:  antonynz                             |       Owner:  joedolson
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  minor                                |  Resolution:
 Keywords:  admin-reskin has-patch has-          |     Focuses:
  screenshots dev-reviewed                       |
-------------------------------------------------+-------------------------
Changes (by audrasjb):

 * keywords:  admin-reskin has-patch has-screenshots dev-feedback => admin-
     reskin has-patch has-screenshots dev-reviewed


Comment:

 The changeset looks good to me. Let's backport this to branch 7.0.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64976#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 06:49:08 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 06:49:08 -0000
Subject: [wp-trac] [WordPress Trac] #64980: Notes needs gettext
In-Reply-To: <052.bebd4bef753cdda60cb3e99a230ce2bc@wordpress.org>
References: <052.bebd4bef753cdda60cb3e99a230ce2bc@wordpress.org>
Message-ID: <067.2b458b90c9243ccaab172a7c0a54c690@wordpress.org>

#64980: Notes needs gettext
------------------------------------------------+-----------------------
 Reporter:  timse201                            |       Owner:  audrasjb
     Type:  defect (bug)                        |      Status:  reopened
 Priority:  normal                              |   Milestone:  7.0
Component:  I18N                                |     Version:  trunk
 Severity:  normal                              |  Resolution:
 Keywords:  has-patch dev-feedback i18n-change  |     Focuses:
------------------------------------------------+-----------------------
Changes (by audrasjb):

 * keywords:  has-patch dev-feedback => has-patch dev-feedback i18n-change


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64980#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 06:49:19 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 06:49:19 -0000
Subject: [wp-trac] [WordPress Trac] #63085: "Login details" spam sent by
 from the account registration page
In-Reply-To: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
References: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
Message-ID: <066.015fe10e5d35d0a5d75fee16c9760176@wordpress.org>

#63085: "Login details" spam sent by from the account registration page
------------------------------------+------------------------------
 Reporter:  cweiske                 |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Login and Registration  |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch               |     Focuses:
------------------------------------+------------------------------
Changes (by cweiske):

 * Attachment "63085-registration-spam.2.diff" added.

 updated patch

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63085>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 06:49:59 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 06:49:59 -0000
Subject: [wp-trac] [WordPress Trac] #65005: Next/Previous for datepicker
 needs context
In-Reply-To: <052.e7c5ffd7379c8e33f54d240e729da31e@wordpress.org>
References: <052.e7c5ffd7379c8e33f54d240e729da31e@wordpress.org>
Message-ID: <067.052b9e4b895ace84d33856432ebb1771@wordpress.org>

#65005: Next/Previous for datepicker needs context
-------------------------------------------------+-------------------------
 Reporter:  timse201                             |       Owner:
                                                 |  SergeyBiryukov
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  I18N                                 |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch commit dev-reviewed i18n-  |     Focuses:
  change                                         |
-------------------------------------------------+-------------------------
Changes (by audrasjb):

 * keywords:  has-patch commit dev-feedback => has-patch commit dev-reviewed
     i18n-change


Comment:

 The change looks good to me. Adding `dev-reviewed` and `i18n-change`
 workflow keywords.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65005#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 06:57:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 06:57:33 -0000
Subject: [wp-trac] [WordPress Trac] #64994: Add context to the "Bulk
 edit" string in `get_bulk_actions()`
In-Reply-To: <052.a01757996873f8b092dbc098d7f5bc61@wordpress.org>
References: <052.a01757996873f8b092dbc098d7f5bc61@wordpress.org>
Message-ID: <067.2b0ebda5314c33f80e3174342bb955bd@wordpress.org>

#64994: Add context to the "Bulk edit" string in `get_bulk_actions()`
------------------------------------------------+-----------------------
 Reporter:  audrasjb                            |       Owner:  audrasjb
     Type:  defect (bug)                        |      Status:  reopened
 Priority:  normal                              |   Milestone:  7.0
Component:  I18N                                |     Version:  trunk
 Severity:  normal                              |  Resolution:
 Keywords:  has-patch dev-feedback i18n-change  |     Focuses:
------------------------------------------------+-----------------------
Changes (by audrasjb):

 * keywords:  has-patch dev-feedback => has-patch dev-feedback i18n-change


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64994#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 07:42:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 07:42:23 -0000
Subject: [wp-trac] [WordPress Trac] #64995: Publish Button returns Code
 View and NOT Visual View?
In-Reply-To: <051.9d661596ebbd346329c94fded8a15b01@wordpress.org>
References: <051.9d661596ebbd346329c94fded8a15b01@wordpress.org>
Message-ID: <066.c533408c64a3b02a977f3b2fc773a007@wordpress.org>

#64995: Publish Button returns Code View and NOT Visual View?
-------------------------------+------------------------------
 Reporter:  pdliles            |       Owner:  (none)
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Editor             |     Version:  6.9.4
 Severity:  normal             |  Resolution:
 Keywords:  reporter-feedback  |     Focuses:
-------------------------------+------------------------------
Changes (by sabernhardt):

 * keywords:   => reporter-feedback
 * component:  General => Editor


Comment:

 Hi and welcome to WordPress Core Trac!

 This might fit better in the [https://wordpress.org/support/forum/how-to-
 and-troubleshooting/ forums].

 More details could help:
 1. Do you use [https://wordpress.org/plugins/classic-editor/ Classic
 Editor] or a similar plugin? (That refreshes the page when you publish or
 update a post.)
 2. An archive of your site says you had WordPress 6.8.3 before 6.9.4. Did
 you update from a different version?
 3. What browser and operating system do you use? I had the Code view when
 I published a post within Firefox's Responsive Design Mode, but then I did
 not have the buttons to switch between Visual and Code views until after I
 left the responsive mode and refreshed the page.
 4. Does the editor show
    - the Visual view every time you open a new post or edit an existing
 post?
    - the Code view every time you publish or update a post?
    - the Code view when you refresh the page without updating the post?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64995#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 07:44:50 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 07:44:50 -0000
Subject: [wp-trac] [WordPress Trac] #65018: WordPress Post Edit Screen
 Content Overflow Issue in version 7.0 RC2
In-Reply-To: <055.e55fb8bae717ff9f69325eb98e7f0c10@wordpress.org>
References: <055.e55fb8bae717ff9f69325eb98e7f0c10@wordpress.org>
Message-ID: <070.7581898a3707c18dc4817210fd309540@wordpress.org>

#65018: WordPress Post Edit Screen Content Overflow Issue in version 7.0 RC2
-------------------------------------+------------------------------
 Reporter:  Pratik Jain              |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch has-test-info  |     Focuses:  ui, css
-------------------------------------+------------------------------
Changes (by abcd95):

 * keywords:  has-patch => has-patch has-test-info


Comment:

 == Test Report

 === Description
 This report validates that the proposed patch resolves the content
 overflow issue observed on the Post Add/Edit screen.

 Patch tested: https://patch-diff.githubusercontent.com/raw/WordPress
 /wordpress-develop/pull/11437.diff

 === Environment

 WordPress: 7.1-alpha-62161-src
 PHP: 8.3.30
 Server: nginx/1.29.5
 Database: mysqli (Server: 8.4.8 / Client: mysqlnd 8.3.30)
 Browser: Chrome 146.0.0.0
 OS: macOS
 Theme: Twenty Twenty-Five 1.4
 Plugins:
 Test Reports 1.2.0

 === Steps to Reproduce

 Navigate to Media → edit.
 Observe layout behavior below the page heading.
 Apply the patch.
 Reload the Post Add/Edit screen.

 === Actual Results

 Before patch: Content overflows outside the wrapping container below the
 page heading.
 After patch: Content is properly contained within the layout boundaries.
 ✅ Issue resolved with the patch.

 === Additional Notes

 The fix correctly restores layout containment without introducing any
 visible UI regressions.
 Verified across both default and custom post types.

 === Supplemental Artifacts

 Screenshot of the fixed contained layout -

 [[Image(https://i.ibb.co/wF8K836L/Screenshot-2026-04-04-at-13-13-30.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65018#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 08:06:46 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 08:06:46 -0000
Subject: [wp-trac] [WordPress Trac] #65014: Site Health: Error icon
 missing due to missing dashicons class
In-Reply-To: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
References: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
Message-ID: <069.a3bd0f87dbcd4d0412d67cd208cfaf7d@wordpress.org>

#65014: Site Health: Error icon missing due to missing dashicons class
-------------------------------------+-------------------------------------
 Reporter:  valani9099               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  7.1
Component:  Site Health              |     Version:  5.3
 Severity:  normal                   |  Resolution:
 Keywords:  has-screenshots has-     |     Focuses:  ui, css,
  patch                              |  administration
-------------------------------------+-------------------------------------

Comment (by valani9099):

 Thank you @wildworks for reviewing!
 I understand the timing with the 7.0 release coordination. I'll wait for
 trunk to reopen and am happy to assist with any further testing needed.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65014#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 08:22:46 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 08:22:46 -0000
Subject: [wp-trac] [WordPress Trac] #65014: Site Health: Error icon
 missing due to missing dashicons class
In-Reply-To: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
References: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
Message-ID: <069.89b00d485d529e309391873366b1d8ba@wordpress.org>

#65014: Site Health: Error icon missing due to missing dashicons class
-------------------------------------+-------------------------------------
 Reporter:  valani9099               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  7.1
Component:  Site Health              |     Version:  5.3
 Severity:  normal                   |  Resolution:
 Keywords:  has-screenshots has-     |     Focuses:  ui, css,
  patch                              |  administration
-------------------------------------+-------------------------------------
Changes (by valani9099):

 * Attachment "65014-v2.diff" added.

 Updated patch v2 — moved dashicons class before error  class for
 consistency per @sabernhardt suggestion.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65014>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 16:17:54 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 16:17:54 -0000
Subject: [wp-trac] [WordPress Trac] #65024: Not possible to modify the
 "Draft saved" message
Message-ID: <055.016483a0a4b9c0ce303a7dde8c97ad24@wordpress.org>

#65024: Not possible to modify the "Draft saved" message
--------------------------+-----------------------------
 Reporter:  stevejburge   |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Editor        |    Version:
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 It's currently not possible to modify the "Draft saved" message that
 appears when saving a post in Draft status.

 https://imgur.com/a/XC3j2Bk

 As far as we can see, that string is not exposed to any plugin-accessible
 filter.

 https://build.trac.wordpress.org/export/61376/trunk/wp-
 includes/js/dist/editor.js

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65024>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 16:18:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 16:18:07 -0000
Subject: [wp-trac] [WordPress Trac] #65024: Not possible to modify the
 "Draft saved" message
In-Reply-To: <055.016483a0a4b9c0ce303a7dde8c97ad24@wordpress.org>
References: <055.016483a0a4b9c0ce303a7dde8c97ad24@wordpress.org>
Message-ID: <070.4bbfdaa5c09775946c727e43cadbfc38@wordpress.org>

#65024: Not possible to modify the "Draft saved" message
--------------------------+------------------------------
 Reporter:  stevejburge   |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Changes (by stevejburge):

 * Attachment "573240234-5231abdb-3b5f-47cd-aa3e-f53e3cf1cbe2.png" added.

 Saving in draft status

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65024>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 16:19:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 16:19:39 -0000
Subject: [wp-trac] [WordPress Trac] #65024: Not possible to modify the
 "Draft saved" message
In-Reply-To: <055.016483a0a4b9c0ce303a7dde8c97ad24@wordpress.org>
References: <055.016483a0a4b9c0ce303a7dde8c97ad24@wordpress.org>
Message-ID: <070.95cff6b5111b63734b0023a7b4f4c975@wordpress.org>

#65024: Not possible to modify the "Draft saved" message
--------------------------+------------------------------
 Reporter:  stevejburge   |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by stevejburge):

 Possible solution here:
 https://github.com/WordPress/gutenberg/issues/77014#issuecomment-4182426163

 "This would require a Trac ticket for a new item_drafted label or a
 similar label. Then the resolution could be the same as
 https://github.com/WordPress/gutenberg/pull/55155"

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65024#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 17:20:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 17:20:49 -0000
Subject: [wp-trac] [WordPress Trac] #63085: "Login details" spam sent by
 from the account registration page
In-Reply-To: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
References: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
Message-ID: <066.c65621ee6e86ba8275f55a1bc304210c@wordpress.org>

#63085: "Login details" spam sent by from the account registration page
------------------------------------+------------------------------
 Reporter:  cweiske                 |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Login and Registration  |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch               |     Focuses:
------------------------------------+------------------------------
Changes (by cweiske):

 * Attachment "63085-registration-spam.3.diff" added.

 patch #3 with unit test

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63085>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 17:21:27 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 17:21:27 -0000
Subject: [wp-trac] [WordPress Trac] #63085: "Login details" spam sent by
 from the account registration page
In-Reply-To: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
References: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
Message-ID: <066.a946b36b7e326a17f0d830fc82c0581d@wordpress.org>

#63085: "Login details" spam sent by from the account registration page
--------------------------------------+------------------------------
 Reporter:  cweiske                   |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  Login and Registration    |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+------------------------------
Changes (by cweiske):

 * keywords:  has-patch => has-patch has-unit-tests


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63085#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 22:29:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 22:29:12 -0000
Subject: [wp-trac] [WordPress Trac] #65022: Posts list: replace (no
 title) filler when a title isn't set with something more useful.
In-Reply-To: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
References: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
Message-ID: <067.35ef9ecf36c09e5d184584b622bbf86c@wordpress.org>

#65022: Posts list: replace (no title) filler when a title isn't set with something
more useful.
-------------------------------+-----------------------------
 Reporter:  annezazu           |       Owner:  SergeyBiryukov
     Type:  enhancement        |      Status:  accepted
 Priority:  normal             |   Milestone:  7.1
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:  administration
-------------------------------+-----------------------------
Changes (by SergeyBiryukov):

 * owner:  (none) => SergeyBiryukov
 * status:  new => accepted
 * milestone:  Future Release => 7.1


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65022#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr  4 23:17:59 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 04 Apr 2026 23:17:59 -0000
Subject: [wp-trac] [WordPress Trac] #64225: Test tool and unit test
 improvements for 7.0
In-Reply-To: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
References: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
Message-ID: <066.2e2a253c39cc7d871871d3847adef86e@wordpress.org>

#64225: Test tool and unit test improvements for 7.0
--------------------------------------+---------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  task (blessed)            |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by SergeyBiryukov):

 In [changeset:"62207" 62207]:
 {{{
 #!CommitTicketReference repository="" revision="62207"
 Tests: Adjust Unicode tests for consistency.

 Includes:
 * Adding missing `@covers` tags.
 * Correcting test class names as per the naming conventions.
 * Moving `wp_check_invalid_utf8()` tests to their own file, separate from
 `wp_scrub_utf8()`.

 Follow-up to [60630], [60793], [61000].

 See #64225.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64225#comment:53>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr  5 00:03:41 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 05 Apr 2026 00:03:41 -0000
Subject: [wp-trac] [WordPress Trac] #65025: Privacy Shield is declared
 invalid
Message-ID: <052.e19a7c96a9d266e3ed2f7acba308d54e@wordpress.org>

#65025: Privacy Shield is declared invalid
-------------------------+-----------------------------
 Reporter:  timse201     |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  Privacy      |    Version:  trunk
 Severity:  normal       |   Keywords:
  Focuses:  privacy      |
-------------------------+-----------------------------
 This string is outdated:
 https://build.trac.wordpress.org/browser/trunk/wp-admin/includes/class-wp-
 privacy-policy-content.php?marks=604#L604

 The EU-U.S. Privacy Shield was declared invalid by the European Court of
 Justice years ago. The current agreement is the Data Privacy Framework
 (DPF).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65025>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr  5 06:01:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 05 Apr 2026 06:01:53 -0000
Subject: [wp-trac] [WordPress Trac] #65025: Privacy Shield is declared
 invalid
In-Reply-To: <052.e19a7c96a9d266e3ed2f7acba308d54e@wordpress.org>
References: <052.e19a7c96a9d266e3ed2f7acba308d54e@wordpress.org>
Message-ID: <067.f9dcf969ff3df543c54a0556851b4848@wordpress.org>

#65025: Privacy Shield is declared invalid
-------------------------------------------------+-------------------------
 Reporter:  timse201                             |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Privacy                              |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-privacy-review       |     Focuses:  privacy
  needs-testing                                  |
-------------------------------------------------+-------------------------
Changes (by masteradhoc):

 * keywords:  has-patch => has-patch needs-privacy-review needs-testing


Comment:

 Hey @timse201
 Good catch! This definately needs some update.

 The EU-U.S. Privacy Shield was invalidated by the CJEU in July 2020
 (Schrems II, Case C-311/18) and is no longer a valid data transfer
 mechanism. The current replacement is the EU-U.S. Data Privacy Framework
 (DPF), adopted by the European Commission on 10 July 2023.

 Proposed change:

 Before:
 ''...whether that is through an agreement such as Privacy Shield, model
 clauses in your contracts, or binding corporate rules.''

 After:
 ''...whether that is through an agreement such as the EU-U.S. Data Privacy
 Framework (DPF), Standard Contractual Clauses (SCCs), or binding corporate
 rules.''


 References:
 - FTC on DPF replacing Privacy Shield: https://www.ftc.gov/business-
 guidance/privacy-security/data-privacy-framework
 - European Commission DPF Q&A:
 https://ec.europa.eu/commission/presscorner/detail/en/qanda_23_3752
 - DPF programme website: https://www.dataprivacyframework.gov
 - NOYB reaction to General Court ruling (Sept 2025): https://noyb.eu/en
 /eu-us-data-transfers-first-reaction-latombe-case

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65025#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr  5 06:59:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 05 Apr 2026 06:59:23 -0000
Subject: [wp-trac] [WordPress Trac] #65025: Privacy Shield is declared
 invalid
In-Reply-To: <052.e19a7c96a9d266e3ed2f7acba308d54e@wordpress.org>
References: <052.e19a7c96a9d266e3ed2f7acba308d54e@wordpress.org>
Message-ID: <067.dc7e03a2764a186059d0b1ac207d84ab@wordpress.org>

#65025: Privacy Shield is declared invalid
-------------------------------------------------+-------------------------
 Reporter:  timse201                             |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Privacy                              |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-privacy-review       |     Focuses:  privacy
  needs-testing                                  |
-------------------------------------------------+-------------------------

Comment (by masteradhoc):

 Based on the feedback of @vikingtechguy I adjusted the string further to
 also clarify which persons are protected under the transfer rules. The
 original "European residents" wording is legally imprecise — GDPR Article
 3 is based on being in the EU/EEA at the time of data collection, not
 residency or citizenship. The updated text reflects this correctly and
 also adds EEA alongside EU.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65025#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr  5 07:46:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 05 Apr 2026 07:46:09 -0000
Subject: [wp-trac] [WordPress Trac] #65025: Privacy Shield is declared
 invalid
In-Reply-To: <052.e19a7c96a9d266e3ed2f7acba308d54e@wordpress.org>
References: <052.e19a7c96a9d266e3ed2f7acba308d54e@wordpress.org>
Message-ID: <067.aaa41c290e38a910a65d33ab16d46a66@wordpress.org>

#65025: Privacy Shield is declared invalid
-------------------------------------+------------------------------
 Reporter:  timse201                 |       Owner:  (none)
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Privacy                  |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  privacy
-------------------------------------+------------------------------
Changes (by masteradhoc):

 * keywords:  has-patch needs-privacy-review needs-testing => has-patch
     needs-testing


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65025#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr  5 14:33:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 05 Apr 2026 14:33:44 -0000
Subject: [wp-trac] [WordPress Trac] #65024: Not possible to modify the
 "Draft saved" message
In-Reply-To: <055.016483a0a4b9c0ce303a7dde8c97ad24@wordpress.org>
References: <055.016483a0a4b9c0ce303a7dde8c97ad24@wordpress.org>
Message-ID: <070.8b2d56174d7a58d0356206bd28a11fe0@wordpress.org>

#65024: Not possible to modify the "Draft saved" message
-------------------------------+-----------------------------
 Reporter:  stevejburge        |       Owner:  (none)
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  7.1
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:  has-patch          |     Focuses:  administration
-------------------------------+-----------------------------
Changes (by Mamaduka):

 * keywords:   => has-patch
 * focuses:   => administration
 * component:  Editor => Posts, Post Types
 * milestone:  Awaiting Review => 7.1


Comment:

 This is similar to #51387.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65024#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr  5 16:10:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 05 Apr 2026 16:10:55 -0000
Subject: [wp-trac] [WordPress Trac] #65024: Not possible to modify the
 "Draft saved" message
In-Reply-To: <055.016483a0a4b9c0ce303a7dde8c97ad24@wordpress.org>
References: <055.016483a0a4b9c0ce303a7dde8c97ad24@wordpress.org>
Message-ID: <070.d1e476af3457807b544da26288ca2947@wordpress.org>

#65024: Not possible to modify the "Draft saved" message
-------------------------------+-----------------------------
 Reporter:  stevejburge        |       Owner:  (none)
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  7.1
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:  needs-patch        |     Focuses:  administration
-------------------------------+-----------------------------
Changes (by Mamaduka):

 * keywords:  has-patch => needs-patch


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65024#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr  5 19:37:24 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 05 Apr 2026 19:37:24 -0000
Subject: [wp-trac] [WordPress Trac] #56694: Uncached database read for
 logged in users when Privacy Policy Page is deleted
In-Reply-To: <059.106d6b1a41744ecc5ef86c9648259268@wordpress.org>
References: <059.106d6b1a41744ecc5ef86c9648259268@wordpress.org>
Message-ID: <074.6c56d310fd79239cd0aee94f31078d17@wordpress.org>

#56694: Uncached database read for logged in users when Privacy Policy Page is
deleted
-------------------------------------+-------------------------------------
 Reporter:  johnjamesjacoby          |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Privacy                  |     Version:  5.7
 Severity:  normal                   |  Resolution:
 Keywords:  needs-unit-tests has-    |     Focuses:  administration,
  patch                              |  performance, privacy
-------------------------------------+-------------------------------------
Changes (by masteradhoc):

 * focuses:  administration, performance => administration, performance,
     privacy


Comment:

 Hey @johnjamesjacoby
 i just prepared a PullRequest over at https://github.com/WordPress
 /wordpress-develop/pull/11443
 Could you give it a test as well? i followed your suggested pattern.

 **These are the tests i performed locally:**
 ''Test A — Trash resets the option''
 Set a page as the Privacy Policy page, trashed it via the Pages list, then
 ran wp option get wp_page_for_privacy_policy. Result: 0. ✅

 ''Test B — Permanent delete resets the option''
 Same setup, then permanently deleted the page from Trash. Result: 0. ✅

 ''Test C — Self-healing in notice()''
 Manually set the option to a non-existent ID (wp option update
 wp_page_for_privacy_policy 99999), visited a page edit screen (/wp-
 admin/post.php?post=1&action=edit), then checked the option. Result: 0. ✅

 ''Test D — Trash notice removed from Settings → Privacy''
 With the option set to a non-existent ID, visited Settings → Privacy.
 Confirmed the old "page is in the Trash / restore" message no longer
 appears. The "page does not exist" fallback still shows correctly. ✅


 Could you give it a test as well? Appreciate your feedback.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/56694#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr  5 21:17:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 05 Apr 2026 21:17:26 -0000
Subject: [wp-trac] [WordPress Trac] #64376: redirect_canonical() causes
 unnecessary 301 redirects for query string encoding variants (+ vs %20)
In-Reply-To: <058.c816cc44ffb5ab003c62f5ea5231d1fb@wordpress.org>
References: <058.c816cc44ffb5ab003c62f5ea5231d1fb@wordpress.org>
Message-ID: <073.e83fececb86de3f0275340960f435d93@wordpress.org>

#64376: redirect_canonical() causes unnecessary 301 redirects for query string
encoding variants (+ vs %20)
-------------------------------------------------+-------------------------
 Reporter:  robbertvancaem                       |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Canonical                            |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests needs-      |     Focuses:
  testing                                        |  performance
-------------------------------------------------+-------------------------

Comment (by jbiggs):

 Just wanted to add my 2c here. I struggled with this for the whole of
 Easter weekend until I figured out what was happening. Upon fixing the
 issue I discovered this thread.

 I can see how this could potentially be used to create a denial-of-service
 condition on a site.

 For example, if a host like Kinsta is ignoring UTM parameters for cache
 variation (which it does), and repeated requests are sent just as the
 homepage cache is about to expire using a URL such as
 https://site.com/?utm_content=test:123, it could cause the homepage to
 cache a 301 redirect loop. Once that redirect response is cached, all
 users could be served the loop until the cache expires.

 That is effectively what I was seeing happen to my site, although it
 wasn't malicious, we were just getting that much Google Ads traffic that
 occasionally it was happening by chance.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64376#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr  5 21:30:54 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 05 Apr 2026 21:30:54 -0000
Subject: [wp-trac] [WordPress Trac] #44498: Make
 `_wp_personal_data_cleanup_requests()` run on cron
In-Reply-To: <051.0a5bc17024630cc1beae5dca0b2ebd29@wordpress.org>
References: <051.0a5bc17024630cc1beae5dca0b2ebd29@wordpress.org>
Message-ID: <066.89df895547e3773c3d81808b11983281@wordpress.org>

#44498: Make `_wp_personal_data_cleanup_requests()` run on cron
-------------------------+------------------------------
 Reporter:  desrosj      |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Privacy      |     Version:  4.9.6
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |     Focuses:
-------------------------+------------------------------

Comment (by masteradhoc):

 Hey @desrosj

 Thanks for the clear report — I’ve opened a Pull Request for review.

 Additionally, I identified and fixed a timezone issue in
 `_wp_personal_data_cleanup_requests()` (wp-admin/includes/privacy-
 tools.php).

 The query used `'column' => 'post_modified_gmt'`, while
 `WP_Date_Query::build_mysql_datetime()` generates timestamps in the site’s
 local timezone. This led to mismatched comparisons (local time vs UTC):

 * Positive UTC offsets: expiry threshold shifts into the future → requests
 expire immediately
 * Negative offsets: requests live longer than intended

 This is subtle with a 24h window but becomes obvious with short
 expirations (e.g. 120 seconds used for my tests), where requests can fail
 instantly.

 Thank you very much for your feedback.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/44498#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr  5 21:33:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 05 Apr 2026 21:33:18 -0000
Subject: [wp-trac] [WordPress Trac] #44498: Make
 `_wp_personal_data_cleanup_requests()` run on cron
In-Reply-To: <051.0a5bc17024630cc1beae5dca0b2ebd29@wordpress.org>
References: <051.0a5bc17024630cc1beae5dca0b2ebd29@wordpress.org>
Message-ID: <066.22a7d9efc87c4b7be5203323b8e4a935@wordpress.org>

#44498: Make `_wp_personal_data_cleanup_requests()` run on cron
----------------------------------------+------------------------------
 Reporter:  desrosj                     |       Owner:  (none)
     Type:  enhancement                 |      Status:  new
 Priority:  normal                      |   Milestone:  Awaiting Review
Component:  Privacy                     |     Version:  4.9.6
 Severity:  normal                      |  Resolution:
 Keywords:  has-patch needs-unit-tests  |     Focuses:
----------------------------------------+------------------------------
Changes (by masteradhoc):

 * keywords:  needs-patch => has-patch needs-unit-tests


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/44498#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr  5 23:14:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 05 Apr 2026 23:14:09 -0000
Subject: [wp-trac] [WordPress Trac] #64225: Test tool and unit test
 improvements for 7.0
In-Reply-To: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
References: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
Message-ID: <066.408048364a9b439140f7b3d9d13caac1@wordpress.org>

#64225: Test tool and unit test improvements for 7.0
--------------------------------------+---------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  task (blessed)            |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by SergeyBiryukov):

 In [changeset:"62208" 62208]:
 {{{
 #!CommitTicketReference repository="" revision="62208"
 Tests: Move `wp_dropdown_languages()` tests to their own file.

 This aims to make the tests more discoverable and easier to expand.

 Follow-up to [36631], [39169], [43359], [44514].

 See #64225.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64225#comment:54>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 06:52:27 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 06:52:27 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2364962=3A_Install_scr?=
 =?utf-8?b?ZWVuczog4oCcTG9nIElu4oCdIGFuZCAiU3VwcG9ydCBsaW5rIiB1c2Ugb2xk?=
 =?utf-8?q?_color?=
In-Reply-To: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
References: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
Message-ID: <074.8260def7f4ec562f5a1220ca70af2f60@wordpress.org>

#64962: Install screens: “Log In” and "Support link" use old color
-------------------------------------------------+-------------------------
 Reporter:  huzaifaalmesbah                      |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch has-          |     Focuses:  ui, css
  screenshots changes-requested                  |
-------------------------------------------------+-------------------------

Comment (by dhrumilk):

 The updated color looks consistent with the new admin design system and
 aligns well with the intended UI refresh. I reviewed the changes locally
 using the provided updated code, and the links such as “Log In” and the
 support article now appear visually consistent with other admin links.

 This improvement enhances clarity and maintains design consistency across
 the experience. From a UI perspective, this update looks good to me.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64962#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 07:20:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 07:20:39 -0000
Subject: [wp-trac] [WordPress Trac] #64168: Inaccurate JSON schema for
 template-parts endpoint
In-Reply-To: <055.7ddf1779cd570990c9e729ca93d75a06@wordpress.org>
References: <055.7ddf1779cd570990c9e729ca93d75a06@wordpress.org>
Message-ID: <070.41475f449f6bdbccafea242cf3c18c01@wordpress.org>

#64168: Inaccurate JSON schema for template-parts endpoint
-------------------------------------------------+-------------------------
 Reporter:  johnbillion                          |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  REST API                             |     Version:  5.8
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-patch has-unit-   |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------
Changes (by motylanogha):

 * Attachment "64168.diff" added.

 Refreshed patch for current trunk (r609f25f). Schema fix for    origin
 (string|null) and modified (oneOf string|false) with 3 unit tests. All 51
 template        controller tests pass.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64168>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 07:28:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 07:28:17 -0000
Subject: [wp-trac] [WordPress Trac] #39473: get_routes() called multiple
 times within single REST request causing the rest_endpoints() filter to
 also fire more than once
In-Reply-To: <053.77887102c1a884ba82848b7fd355727f@wordpress.org>
References: <053.77887102c1a884ba82848b7fd355727f@wordpress.org>
Message-ID: <068.6d4af2195ce7cddb6e6f2575384a326a@wordpress.org>

#39473: get_routes() called multiple times within single REST request causing the
rest_endpoints() filter to also fire more than once
-------------------------------------------------+-------------------------
 Reporter:  ruud@…                               |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  REST API                             |     Version:  4.4
 Severity:  normal                               |  Resolution:
 Keywords:  needs-unit-tests good-first-bug      |     Focuses:
  dev-feedback                                   |
-------------------------------------------------+-------------------------
Changes (by motylanogha):

 * Attachment "39473.diff" added.

 Refreshed patch for current trunk with route map caching and 4 unit tests.
 Cache is invalidated on register_route(). All 1052 REST API tests pass

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/39473>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 07:41:41 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 07:41:41 -0000
Subject: [wp-trac] [WordPress Trac] #43502:
 `WP_REST_Posts_Controller::prepare_item_for_response()` doesn't reset
 postdata after calling setup_postdata()
In-Reply-To: <057.83d91ea915ff38acf2097fa68d250dca@wordpress.org>
References: <057.83d91ea915ff38acf2097fa68d250dca@wordpress.org>
Message-ID: <072.797baae0ba9ff85836cfaa51d4d9f868@wordpress.org>

#43502: `WP_REST_Posts_Controller::prepare_item_for_response()` doesn't reset
postdata after calling setup_postdata()
-------------------------------------------------+-------------------------
 Reporter:  gerbenvandijk                        |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  REST API                             |     Version:  4.9.4
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-patch needs-      |     Focuses:  rest-api
  unit-tests                                     |
-------------------------------------------------+-------------------------
Changes (by motylanogha):

 * Attachment "43502.6.diff" added.

 Refreshed patch for current trunk. Saves and restores $GLOBALS['post'] in
 prepare_item_for_response(), including the HEAD early return path.
 Includes 2 unit tests. All 283 posts controller tests pass.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/43502>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 07:46:35 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 07:46:35 -0000
Subject: [wp-trac] [WordPress Trac] #65022: Posts list: replace (no
 title) filler when a title isn't set with something more useful.
In-Reply-To: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
References: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
Message-ID: <067.cb32a94f952a2cf3cdde28caf10766c3@wordpress.org>

#65022: Posts list: replace (no title) filler when a title isn't set with something
more useful.
-------------------------------+-----------------------------
 Reporter:  annezazu           |       Owner:  SergeyBiryukov
     Type:  enhancement        |      Status:  accepted
 Priority:  normal             |   Milestone:  7.1
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:  administration
-------------------------------+-----------------------------
Changes (by Joen):

 * Attachment "before.png" added.

 Present state, for comparison

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65022>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 07:47:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 07:47:48 -0000
Subject: [wp-trac] [WordPress Trac] #65022: Posts list: replace (no
 title) filler when a title isn't set with something more useful.
In-Reply-To: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
References: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
Message-ID: <067.9e1208b5d5ec62e62cad915f496fb460@wordpress.org>

#65022: Posts list: replace (no title) filler when a title isn't set with something
more useful.
-------------------------------+-----------------------------
 Reporter:  annezazu           |       Owner:  SergeyBiryukov
     Type:  enhancement        |      Status:  accepted
 Priority:  normal             |   Milestone:  7.1
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:  administration
-------------------------------+-----------------------------
Changes (by Joen):

 * Attachment "after-proposal.png" added.

 A proposal for an implementation

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65022>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 07:49:38 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 07:49:38 -0000
Subject: [wp-trac] [WordPress Trac] #65022: Posts list: replace (no
 title) filler when a title isn't set with something more useful.
In-Reply-To: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
References: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
Message-ID: <067.1b2815b4d78f1ed8adb11d05f0bffc1e@wordpress.org>

#65022: Posts list: replace (no title) filler when a title isn't set with something
more useful.
-------------------------------+-----------------------------
 Reporter:  annezazu           |       Owner:  SergeyBiryukov
     Type:  enhancement        |      Status:  accepted
 Priority:  normal             |   Milestone:  7.1
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:  administration
-------------------------------+-----------------------------

Comment (by Joen):

 I agree with this issue, and would love to see small improvements land in
 7.1. The use case feels clear, and the path forward seems relatively
 straight too; there's even precedence in P2.

 A question to be mindful of, however: does the auto-generated title
 actually get saved as title metadata to the post? If yes, does it change
 the slug from what would've otherwise simply been an incrementing post-ID?

 The alternative would be to make this a Posts-list screen visual change
 only: if no title is set, use the first n words from the post and end with
 an ellipsis, but otherwise keep the title metadata empty, the cpt slug
 unchanged.

 Attached two draft sketches of a before and after, for consideration.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65022#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 07:51:25 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 07:51:25 -0000
Subject: [wp-trac] [WordPress Trac] #43502:
 `WP_REST_Posts_Controller::prepare_item_for_response()` doesn't reset
 postdata after calling setup_postdata()
In-Reply-To: <057.83d91ea915ff38acf2097fa68d250dca@wordpress.org>
References: <057.83d91ea915ff38acf2097fa68d250dca@wordpress.org>
Message-ID: <072.29ec7633b31016077392eb4b5158bd3c@wordpress.org>

#43502: `WP_REST_Posts_Controller::prepare_item_for_response()` doesn't reset
postdata after calling setup_postdata()
-------------------------------------------------+-------------------------
 Reporter:  gerbenvandijk                        |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  REST API                             |     Version:  4.9.4
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-patch has-unit-   |     Focuses:  rest-api
  tests                                          |
-------------------------------------------------+-------------------------
Changes (by motylanogha):

 * keywords:  good-first-bug has-patch needs-unit-tests => good-first-bug
     has-patch has-unit-tests


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/43502#comment:26>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 07:52:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 07:52:09 -0000
Subject: [wp-trac] [WordPress Trac] #39473: get_routes() called multiple
 times within single REST request causing the rest_endpoints() filter to
 also fire more than once
In-Reply-To: <053.77887102c1a884ba82848b7fd355727f@wordpress.org>
References: <053.77887102c1a884ba82848b7fd355727f@wordpress.org>
Message-ID: <068.ed2a98b76ffd40cc627afb1442b42c66@wordpress.org>

#39473: get_routes() called multiple times within single REST request causing the
rest_endpoints() filter to also fire more than once
-------------------------------------------------+-------------------------
 Reporter:  ruud@…                               |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  REST API                             |     Version:  4.4
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-patch has-unit-   |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------
Changes (by motylanogha):

 * keywords:  needs-unit-tests good-first-bug dev-feedback => good-first-bug
     has-patch has-unit-tests


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/39473#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 07:59:40 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 07:59:40 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2364967=3A_Bug_report_?=
 =?utf-8?q?=E2=80=93_Whitespace_/_non-breaking_spaces_removed_after_save_i?=
 =?utf-8?q?n_Gutenberg?=
In-Reply-To: <052.3c2e3cbdf85fb7e2fb39e221e5a6c84b@wordpress.org>
References: <052.3c2e3cbdf85fb7e2fb39e221e5a6c84b@wordpress.org>
Message-ID: <067.19835c5af3ec78696a1bbc3af06a0b40@wordpress.org>

#64967: Bug report – Whitespace / non-breaking spaces removed after save in
Gutenberg
--------------------------+------------------------------
 Reporter:  testwp75      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by devasheeshkaul):

 Hey @testwp75, thanks for the additional information! I tried again by
 testing multiple bold text scenarios (both consecutive bold letters and
 bold text mixed with regular text), but I still wasn’t able to reproduce
 the issue. In all the cases, the content was pasted with the properly
 bolded text without any missing spacing, both in the editor and on the
 frontend.

 As @jorbin mentioned, if you could share the example document, it would
 really help in testing this further in case we’re missing any crucial
 detail from the doc itself.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64967#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 08:01:25 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 08:01:25 -0000
Subject: [wp-trac] [WordPress Trac] #51811: Query inconsistency between
 WP_Query and WP_Term_Query
In-Reply-To: <054.9b076db509a0f3f242b9378404382a74@wordpress.org>
References: <054.9b076db509a0f3f242b9378404382a74@wordpress.org>
Message-ID: <069.9c30755cf32b7ba9e5e72480b21afc9e@wordpress.org>

#51811: Query inconsistency between WP_Query and WP_Term_Query
-------------------------------------------------+-------------------------
 Reporter:  tonydjukic                           |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Query                                |     Version:  4.6
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-patch has-unit-   |     Focuses:  coding-
  tests                                          |  standards
-------------------------------------------------+-------------------------
Changes (by motylanogha):

 * Attachment "51811.diff" added.

 Refreshed patch for current trunk. Adds 's' as alias for 'search' in
 WP_Term_Query for consistency with WP_Query. 'search' takes precedence
 when both are provided. 3 unit tests, all 45 term query tests pass.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/51811>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 08:07:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 08:07:21 -0000
Subject: [wp-trac] [WordPress Trac] #64986: preview needs gettext
In-Reply-To: <052.86455e444a3819f06c00aef779dc6226@wordpress.org>
References: <052.86455e444a3819f06c00aef779dc6226@wordpress.org>
Message-ID: <067.2434cb636ff3238b85aac0c44f38608c@wordpress.org>

#64986: preview needs gettext
--------------------------------------+----------------------------
 Reporter:  timse201                  |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  I18N                      |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  good-first-bug has-patch  |     Focuses:  accessibility
--------------------------------------+----------------------------
Changes (by motylanogha):

 * Attachment "64986.diff" added.

 Refreshed patch for current trunk. Adds translator context to all 4
 instances of  __( 'Preview' ) using _x() with descriptive context strings.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64986>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 08:13:27 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 08:13:27 -0000
Subject: [wp-trac] [WordPress Trac] #59354: Unnecessary queries
 performed when updating a post without providing categories or tags
In-Reply-To: <055.f56eb67c6a6dfc122b9277f7d7b85b7f@wordpress.org>
References: <055.f56eb67c6a6dfc122b9277f7d7b85b7f@wordpress.org>
Message-ID: <070.70a250038c5b95260e04c11117a552f7@wordpress.org>

#59354: Unnecessary queries performed when updating a post without providing
categories or tags
--------------------------------------+------------------------------
 Reporter:  johnbillion               |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  Posts, Post Types         |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+------------------------------
Changes (by motylanogha):

 * Attachment "59354.diff" added.

 Patch for current trunk. Skips wp_set_post_categories() on update when
 post_category is not in $postarr, matching the existing tags_input guard.
 Includes unit test verifying fewer queries. All 62 wp_insert_post tests
 pass.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59354>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 08:22:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 08:22:57 -0000
Subject: [wp-trac] [WordPress Trac] #52976: user emails comparison
 should be case insensitive
In-Reply-To: <050.7727b644129a97f4082fdf76cb8aa740@wordpress.org>
References: <050.7727b644129a97f4082fdf76cb8aa740@wordpress.org>
Message-ID: <065.79b67294bef4e6f67b68c8d58304c81d@wordpress.org>

#52976: user emails comparison should be case insensitive
-------------------------------------------------+-------------------------
 Reporter:  asaifm                               |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Users                                |     Version:  4.3
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-patch has-        |     Focuses:
  screenshots reporter-feedback                  |
-------------------------------------------------+-------------------------
Changes (by motylanogha):

 * Attachment "52976.2.diff" added.

 Refreshed patch for current trunk. Uses strcasecmp() for case-insensitive
 email comparison in both the activation key reset (line 2550) and email
 change notification (line 2766). 2 unit tests. All 124 user tests pass.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/52976>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 08:23:19 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 08:23:19 -0000
Subject: [wp-trac] [WordPress Trac] #52976: user emails comparison
 should be case insensitive
In-Reply-To: <050.7727b644129a97f4082fdf76cb8aa740@wordpress.org>
References: <050.7727b644129a97f4082fdf76cb8aa740@wordpress.org>
Message-ID: <065.bef5fafe9c7ebc50bf61fd74c2b62071@wordpress.org>

#52976: user emails comparison should be case insensitive
-------------------------------------------------+-------------------------
 Reporter:  asaifm                               |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Users                                |     Version:  4.3
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-patch has-        |     Focuses:
  screenshots reporter-feedback has-unit-tests   |
-------------------------------------------------+-------------------------
Changes (by motylanogha):

 * keywords:  good-first-bug has-patch has-screenshots reporter-feedback =>
     good-first-bug has-patch has-screenshots reporter-feedback has-unit-
     tests


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/52976#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 08:56:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 08:56:53 -0000
Subject: [wp-trac] [WordPress Trac] #52976: user emails comparison
 should be case insensitive
In-Reply-To: <050.7727b644129a97f4082fdf76cb8aa740@wordpress.org>
References: <050.7727b644129a97f4082fdf76cb8aa740@wordpress.org>
Message-ID: <065.21dd9b39391307d96302ea4a094b9557@wordpress.org>

#52976: user emails comparison should be case insensitive
-------------------------------------------------+-------------------------
 Reporter:  asaifm                               |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Users                                |     Version:  4.3
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-patch has-        |     Focuses:
  screenshots reporter-feedback has-unit-tests   |
-------------------------------------------------+-------------------------

Comment (by ozgursar):

 Hi @motylanogha, I tried to reproduce the bug against the `trunk` again,
 but similarly to my previous bug reproduction test, changing lowercase to
 uppercase email did not trigger the notification. Am I missing something?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/52976#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 09:16:10 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 09:16:10 -0000
Subject: [wp-trac] [WordPress Trac] #52976: user emails comparison
 should be case insensitive
In-Reply-To: <050.7727b644129a97f4082fdf76cb8aa740@wordpress.org>
References: <050.7727b644129a97f4082fdf76cb8aa740@wordpress.org>
Message-ID: <065.065a69d293e46e153f8b377066eebd0a@wordpress.org>

#52976: user emails comparison should be case insensitive
-------------------------------------------------+-------------------------
 Reporter:  asaifm                               |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Users                                |     Version:  4.3
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-patch has-        |     Focuses:
  screenshots reporter-feedback has-unit-tests   |
-------------------------------------------------+-------------------------

Comment (by motylanogha):

 Hi @ozgursar,

 What you observed is the expected, buggy behaviour on the current trunk —
 that's exactly the issue this ticket aims to fix.

 Right now on trunk, the comparison at line 2766 uses strict !==, which
 does see admin at example.com and ADMIN at example.com as different strings.
 However, the way the code flows works, the email gets silently updated
 without properly triggering the confirmation/notification email. So the
 user ends up with a changed email, and no confirmation was ever sent —
 which is a problem.

 The patch in 52976.2.diff fixes this by using strcasecmp() so that case-
 only differences are treated as "same email" — no update, no notification
 needed. This is the correct behaviour since email addresses are case-
 insensitive per RFC 5321, and virtually all mail servers treat them that
 way.

 To verify the fix works, you'd need to apply the patch to your local trunk
 checkout and then confirm that:
 1. Changing admin at example.com -> ADMIN at example.com is treated as no change
 (no notification, no update).
 2. Changing admin at example.com -> different at example.com still properly
 triggers the confirmation email.

 The 2 unit tests included in the patch cover both scenarios.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/52976#comment:17>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 09:53:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 09:53:28 -0000
Subject: [wp-trac] [WordPress Trac] #65022: Posts list: replace (no
 title) filler when a title isn't set with something more useful.
In-Reply-To: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
References: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
Message-ID: <067.342007251e0130891b0bba379203985b@wordpress.org>

#65022: Posts list: replace (no title) filler when a title isn't set with something
more useful.
-------------------------------+-----------------------------
 Reporter:  annezazu           |       Owner:  SergeyBiryukov
     Type:  enhancement        |      Status:  accepted
 Priority:  normal             |   Milestone:  7.1
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:  administration
-------------------------------+-----------------------------

Comment (by mcsf):

 Replying to [comment:5 Joen]:
 > The alternative would be to make this a Posts-list screen visual change
 only: if no title is set, use the first n words from the post and end with
 an ellipsis, but otherwise keep the title metadata empty, the cpt slug
 unchanged.

 From what I understood of Matt's and Anne's report, it's more of a visual
 change, not an attempt to auto-generate titles. The consequences of that
 (IMO) are that **it should remain clear that the post lacks a title**, and
 that the excerpt/preview of the content is just that: a preview, or a
 placeholder.

 I'm not a designer, but I think the solution ought to look a bit more like
 [https://core.trac.wordpress.org/attachment/ticket/65022/show-excerpt-in-
 compact-view.png Stephen's concept], but on a single line (to honour
 Compact View). It could be a string of text that tries to fill the
 available space in the row's cell but gets clipped so as not to interfere
 with the other fields (Author, etc.).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65022#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 10:01:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 10:01:29 -0000
Subject: [wp-trac] [WordPress Trac] #65022: Posts list: replace (no
 title) filler when a title isn't set with something more useful.
In-Reply-To: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
References: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
Message-ID: <067.161311c4d589b3b6fa9fc8b649c0fe15@wordpress.org>

#65022: Posts list: replace (no title) filler when a title isn't set with something
more useful.
-------------------------------+-----------------------------
 Reporter:  annezazu           |       Owner:  SergeyBiryukov
     Type:  enhancement        |      Status:  accepted
 Priority:  normal             |   Milestone:  7.1
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:  administration
-------------------------------+-----------------------------

Comment (by Joen):

 I should've added that my (semi-strong) preference was also to keep the
 post title-less, and the slug unmodified.

 I'm not sure that showing an excerpt in absence of a title is going to be
 a good solution, though; it will create a different rhythm in the list
 with visual rivers. And from Dave's post, it simply mentions the title. I
 think the expectation from web-apps of today (think Docs, etc) is that
 items have titles that you can customise if you want to. In that sense,
 I'd think whatever we show should use the same visual area of the list.
 Your point about making it clear it's a title-less post is well made,
 though. Let me attach some experiments.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65022#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 10:02:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 10:02:05 -0000
Subject: [wp-trac] [WordPress Trac] #65022: Posts list: replace (no
 title) filler when a title isn't set with something more useful.
In-Reply-To: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
References: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
Message-ID: <067.4e393874ceea688436113369c46ae4f7@wordpress.org>

#65022: Posts list: replace (no title) filler when a title isn't set with something
more useful.
-------------------------------+-----------------------------
 Reporter:  annezazu           |       Owner:  SergeyBiryukov
     Type:  enhancement        |      Status:  accepted
 Priority:  normal             |   Milestone:  7.1
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:  administration
-------------------------------+-----------------------------
Changes (by Joen):

 * Attachment "italic.png" added.

 Italic excerpt-based placeholder title

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65022>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 10:02:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 10:02:22 -0000
Subject: [wp-trac] [WordPress Trac] #65022: Posts list: replace (no
 title) filler when a title isn't set with something more useful.
In-Reply-To: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
References: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
Message-ID: <067.f5b43b3d7dde61bdfe4d3949d5adfa1f@wordpress.org>

#65022: Posts list: replace (no title) filler when a title isn't set with something
more useful.
-------------------------------+-----------------------------
 Reporter:  annezazu           |       Owner:  SergeyBiryukov
     Type:  enhancement        |      Status:  accepted
 Priority:  normal             |   Milestone:  7.1
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:  administration
-------------------------------+-----------------------------
Changes (by Joen):

 * Attachment "italic-no-title.png" added.

 Italic excerpt-based placeholder title, and "(no title)"

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65022>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 10:22:34 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 10:22:34 -0000
Subject: [wp-trac] [WordPress Trac] #52976: user emails comparison
 should be case insensitive
In-Reply-To: <050.7727b644129a97f4082fdf76cb8aa740@wordpress.org>
References: <050.7727b644129a97f4082fdf76cb8aa740@wordpress.org>
Message-ID: <065.3d5f0a0c0b02071d79e7fdbd762e18f7@wordpress.org>

#52976: user emails comparison should be case insensitive
-------------------------------------------------+-------------------------
 Reporter:  asaifm                               |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Users                                |     Version:  4.3
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-patch has-        |     Focuses:
  screenshots has-unit-tests                     |
-------------------------------------------------+-------------------------
Changes (by ozgursar):

 * keywords:
     good-first-bug has-patch has-screenshots reporter-feedback has-unit-
     tests
     => good-first-bug has-patch has-screenshots has-unit-tests


Comment:

 Thanks for the clarification @motylanogha . I'll do the patch testing
 accordingly.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/52976#comment:18>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 10:23:58 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 10:23:58 -0000
Subject: [wp-trac] [WordPress Trac] #65026: Hide plugin search form on
 Favorites tab
Message-ID: <048.5df104f8236536e341a0c31918d9a06c@wordpress.org>

#65026: Hide plugin search form on Favorites tab
--------------------------+-----------------------------
 Reporter:  bor0          |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Plugins       |    Version:
 Severity:  normal        |   Keywords:  has-patch
  Focuses:  ui            |
--------------------------+-----------------------------
 The plugin search form is currently displayed on the Favorites tab, where
 it is not applicable.

 This patch prevents the search form from rendering when tab=favorites,
 aligning the UI with expected behavior and reducing confusion.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65026>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 10:24:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 10:24:12 -0000
Subject: [wp-trac] [WordPress Trac] #65026: Hide plugin search form on
 Favorites tab
In-Reply-To: <048.5df104f8236536e341a0c31918d9a06c@wordpress.org>
References: <048.5df104f8236536e341a0c31918d9a06c@wordpress.org>
Message-ID: <063.925218200b740d9e846425d72a6f66a3@wordpress.org>

#65026: Hide plugin search form on Favorites tab
--------------------------+------------------------------
 Reporter:  bor0          |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Plugins       |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  ui
--------------------------+------------------------------
Changes (by bor0):

 * Attachment "65026.patch" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65026>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 10:24:27 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 10:24:27 -0000
Subject: [wp-trac] [WordPress Trac] #65026: Hide plugin search form on
 Favorites tab
In-Reply-To: <048.5df104f8236536e341a0c31918d9a06c@wordpress.org>
References: <048.5df104f8236536e341a0c31918d9a06c@wordpress.org>
Message-ID: <063.42c4a12b19bbf94b2e4e60c4f0465dad@wordpress.org>

#65026: Hide plugin search form on Favorites tab
--------------------------+------------------------------
 Reporter:  bor0          |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Plugins       |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  ui
--------------------------+------------------------------

Comment (by bor0):

 cc @dd32, would be great to get your thoughts on this one as well

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65026#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 11:02:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 11:02:03 -0000
Subject: [wp-trac] [WordPress Trac] #65022: Posts list: replace (no
 title) filler when a title isn't set with something more useful.
In-Reply-To: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
References: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
Message-ID: <067.d4455a35954e4e57e72aa5196f88d80a@wordpress.org>

#65022: Posts list: replace (no title) filler when a title isn't set with something
more useful.
-------------------------------+-----------------------------
 Reporter:  annezazu           |       Owner:  SergeyBiryukov
     Type:  enhancement        |      Status:  accepted
 Priority:  normal             |   Milestone:  7.1
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:  administration
-------------------------------+-----------------------------

Comment (by mcsf):

 Replying to [comment:7 Joen]:
 > Your point about making it clear it's a title-less post is well made,
 though. Let me attach some experiments.

 Thanks for them. AFAIC they could be something to try, but I'd love to get
 other people's feedback.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65022#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 14:38:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 14:38:13 -0000
Subject: [wp-trac] [WordPress Trac] #65017: Dashboard widgets border
 bottom issue when it is closed in version 7.0 RC2
In-Reply-To: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
References: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
Message-ID: <070.ef1d1e9de171eaf1348494b77bd13e1e@wordpress.org>

#65017: Dashboard widgets border bottom issue when it is closed in version 7.0 RC2
-------------------------------------------------+-------------------------
 Reporter:  Pratik Jain                          |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-screenshots has-patch dev-       |     Focuses:  ui, css
  reviewed commit                                |
-------------------------------------------------+-------------------------
Changes (by westonruter):

 * keywords:  has-screenshots has-patch dev-feedback => has-screenshots has-
     patch dev-reviewed commit
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 @audrasjb This fixes the issue for me. Approved.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65017#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 14:41:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 14:41:31 -0000
Subject: [wp-trac] [WordPress Trac] #64994: Add context to the "Bulk
 edit" string in `get_bulk_actions()`
In-Reply-To: <052.a01757996873f8b092dbc098d7f5bc61@wordpress.org>
References: <052.a01757996873f8b092dbc098d7f5bc61@wordpress.org>
Message-ID: <067.09320f4f960bbc830fc7ff92c35ba3b4@wordpress.org>

#64994: Add context to the "Bulk edit" string in `get_bulk_actions()`
-------------------------------------------------+-------------------------
 Reporter:  audrasjb                             |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  I18N                                 |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch i18n-change dev-reviewed   |     Focuses:
  commit                                         |
-------------------------------------------------+-------------------------
Changes (by westonruter):

 * keywords:  has-patch dev-feedback i18n-change => has-patch i18n-change
     dev-reviewed commit


Comment:

 Looks good.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64994#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 14:42:00 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 14:42:00 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.9106af13d2ccd10a201d0d3394603d3c@wordpress.org>

#65015: Connectors: Several strings are not translated
--------------------------+---------------------
 Reporter:  369work       |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  I18N          |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+---------------------

Comment (by jorgefilipecosta):

 Hi @369work, @sabernhardt. Thank you for reporting these issues, we are
 using the i18n functions on these strings so it may be temporary until the
 final release properly connects these strings Gutenberg side
 implementation is using. Is this issue only happening on the connectors
 screen or it also happens on some strings in Appearance -> Fonts, or the
 editor and site editor?

 Than k you in advance for any additional insights.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 15:06:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 15:06:57 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.e58a4e10665fc9b573577f8f534045f2@wordpress.org>

#65015: Connectors: Several strings are not translated
--------------------------+---------------------
 Reporter:  369work       |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  I18N          |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+---------------------
Changes (by nilambar):

 * Attachment "Screenshot 2026-04-06 at 8.51.16 PM.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 15:07:47 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 15:07:47 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.2740be7534b1c16dbff8190ceb9f5812@wordpress.org>

#65015: Connectors: Several strings are not translated
--------------------------+---------------------
 Reporter:  369work       |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  I18N          |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+---------------------

Comment (by nilambar):

 Some strings in Fonts page are also not translated.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 15:15:59 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 15:15:59 -0000
Subject: [wp-trac] [WordPress Trac] #65027: Add ID do Section titles
 generated by Settings API
Message-ID: <049.5cca681fb1dec77bdd5b65aa7d19357d@wordpress.org>

#65027: Add ID do Section titles generated by Settings API
-----------------------------------------------+---------------------------
 Reporter:  wetah                              |      Owner:  (none)
     Type:  enhancement                        |     Status:  new
 Priority:  normal                             |  Milestone:  Awaiting
                                               |  Review
Component:  Administration                     |    Version:
 Severity:  trivial                            |   Keywords:
  Focuses:  ui, accessibility, administration  |
-----------------------------------------------+---------------------------
 I see that there's a lot of debate around improvements to the Forms
 generated by
 [https://developer.wordpress.org/reference/functions/do_settings_sections/
 do_settings_sections].

 - https://core.trac.wordpress.org/ticket/51086
 - https://core.trac.wordpress.org/ticket/43303
 - https://core.trac.wordpress.org/ticket/39441

 I know more radical changes won't move up easily so I would like to
 suggest a simple one: having the section ID in the section title. For
 instance this:

 {{{#!php
 <?php
      if ( $section['title'] ) {
         echo "<h2>{$section['title']}</h2>\n";
      }
 }}}

 To become something like this:

 {{{#!php
 <?php
      if ( $section['title'] ) {
         echo '<h2 id="' . $section['id'] . '">' . $section['title'] .
 '</h2>\n';
      }
 }}}

 For consistency, I would add the IDs also to the Core forms that have
 sections not generated by ''do_settings_sections'', such as ''options-
 media.php'', ''options-reading.php'', etc. They already do something
 different which is to add a 'title' class to all their section titles.
 This makes me think that maybe we should have a filter to change that
 title markup in the end... but that can be for another topic.

 The main motivation for doing that is to allow hash navigation via URL. We
 could easily in the documentation have links such as ''wp-admin/options-
 discussion.php#avatars'', which I think it is a huge benefit if we're
 talking long forms. I know it wouldn't solve more complex issues but can
 be beneficial even for Accessibility and for those who want to customize
 their forms via CSS, as discussed in the other linked tickets.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65027>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 15:54:00 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 15:54:00 -0000
Subject: [wp-trac] [WordPress Trac] #60420: Default wordpress@site.com
 sender address can be problematic
In-Reply-To: <054.d3bd9eee2d6f2124576c55af40233ad9@wordpress.org>
References: <054.d3bd9eee2d6f2124576c55af40233ad9@wordpress.org>
Message-ID: <069.28bbce0357c91cc478934d88ba10eda5@wordpress.org>

#60420: Default wordpress at site.com sender address can be problematic
-----------------------------+------------------------------
 Reporter:  thinlinecz       |       Owner:  (none)
     Type:  feature request  |      Status:  reopened
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Mail             |     Version:  1.5.1.2
 Severity:  normal           |  Resolution:
 Keywords:  close            |     Focuses:
-----------------------------+------------------------------

Comment (by dmsnell):

 > The problem is that the bureaucrats of these Core sections, have the
 power to hinder these proposals, but they can't hinder other areas like AI
 because those guys have much more power in this project than them, so they
 have to bow their heads and accept the new changes with unease. It's like
 a game of thrones. ;)

 > there's a new group of 19-year-olds in charge who think that everything
 learned before 2025 could not possibly still have relevance…undo these
 asinine decisions

 let’s perhaps take a moment to breathe and recognize that behind every
 username here is a human trying to find ways to improve WordPress. let’s
 also take a moment to realize that, despite the confidence and fervor of
 the proponents of this ticket, //following that confidence// led to
 breakages across different platforms.

 so I don’t know which asinine decisions we’re referring to, but when the
 failures started, a number of us tried to assess the impact and whether
 fixes or reverts would be more appropriate. when we asked, we were unable
 to find people who were willing or able to provide empirical data showing
 the scope of the breakages, and there was already a workaround for the
 sender address issue.

 therefore we reverted. some of the requested fixes were also incomplete
 and would have led to the same kind of breakage if deployed.

 personally, I went out of my way to try and help the efforts pushed here,
 seeing that there was no Core committer championing the work. every week I
 have a thousand different projects, groups of people, and tasks that I
 can’t hope to adequately attend to, but I chose to try and move this one
 forward where I could. I spent that precious time reviewing this work,
 getting second-opinions from people with more experience in email
 delivery, writing a Make post and putting my name on it //to draw public
 flak and reaction to me and not onto others//, and accepting the liability
 for any problems that happened post merge — and guess what, there was a
 huge liability post merge.

 there was a time I was 19, but it’s not now. email systems behave
 differently since the last time this fundamental change was attempted, so
 we gave it another try, and you know what? it //mostly// worked! to the
 best of our collected knowledge, this affected a very specific subset of
 the deployed WordPress ecosystem. we never found the data we were asking
 for though — only received a declaration that because the problem appeared
 “more than 0%” //by a few reported systems//, despite fixing other
 systems, that things were “unambiguous.”

 the decision to revert also broke email delivery for those for whom the
 original patch fixed it.

 if you feel like people like me, and those who took part in helping to try
 and make this thing work, are obstacles with the goal of hindering your
 plans…I don’t know, consider what would have happened if this had gone
 smoothly? would I still be an asinine 19-year-old bureaucrat if email
 //only// got better with this merge rather than //got better more many and
 worse for some//? throwing insults isn’t likely going to help whatever
 your own agendas are or gather cooperation in the community.

 ----

 we should be clear here: AI had nothing to do with hindering this
 proposal. the only thing //hindering// this proposal is the impact that
 the proposed fixes had when they broke real systems for real people. and
 because of that, now, any attempt to redo the change is obviously going to
 be much slower a more effort is being put in place to ensure due-diligence
 before unnecessarily and negatively impacting people again.

 there are open tickets for different parts of the broader issue at play
 here surrounding the sender address. I understand that it can be
 frustrating when things move slower than one wants when a solution seems
 so simple from a given perspective.

 for my part I regret merging this late in the release cycle. I wish I had
 outright said “no” when considering the merge before 6.9, but I wanted to
 help what appeared to be effortful work that was stuck. I have learned my
 lesson and have tried to more carefully push caution in unrelated work so
 that it lands at the start of a release cycle instead of the end. I hope
 that because of that I don’t convince someone else to call me an asinine
 19 year old bureaucrat 🙃

 ----

 > All of these problems boil down to one thing: the lack of a text box to
 type in a usable address in a manner that is consistent with the design of
 WP, the internet, and hosting environments.

 This sounds like a good thing to add in a plugin as
 [https://core.trac.wordpress.org/ticket/60420#comment:16 @desrosj]
 suggested eight months ago. It’s far easier to discuss something that
 exists and is in use than a confusing back-and-forth of hypotheticals.
 Hosts can install the plugin and test it and provide feedback. Anyone with
 email troubles can install it.

 As has been brought up by others in this ticket, even adding the text box
 presents coordination problems when hosts and site admins have different
 understandings of what //should// be set as the sender address.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60420#comment:63>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 15:59:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 15:59:07 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.c04acea8a9d8f375ab8987fa5346c31e@wordpress.org>

#65015: Connectors: Several strings are not translated
--------------------------+---------------------
 Reporter:  369work       |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  I18N          |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+---------------------

Comment (by 369work):

 Hi, at jorgefilipecosta.

 Thank you.
 Currently, as far as I've checked,
 1. The part me pointed out in Connector
 2. The Library and Upload tabs in Appearance > Fonts

 These two are untranslated.
 The Site Editor seems fine in the parts I've looked at.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 16:07:43 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 16:07:43 -0000
Subject: [wp-trac] [WordPress Trac] #20044: Enable search for pages by
 slug
In-Reply-To: <052.b5c8b29675796ae358c80f6b8a682a41@wordpress.org>
References: <052.b5c8b29675796ae358c80f6b8a682a41@wordpress.org>
Message-ID: <067.d1842d31fa62f343b1b266a45c142bca@wordpress.org>

#20044: Enable search for pages by slug
-------------------------+---------------------
 Reporter:  ekitomat     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:
Component:  Query        |     Version:  3.7
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |     Focuses:
-------------------------+---------------------
Changes (by kush123):

 * Attachment "Screenshot 2026-04-06 at 9.37.12 PM.png" added.

 search-slug-test

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/20044>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 16:12:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 16:12:44 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.41c4564b2edc407d87209c822c387968@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  feature request   |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  Plugins           |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  has-patch revert  |     Focuses:
------------------------------+-------------------------------

Comment (by jorbin):

 Replying to [comment:32 jorgefilipecosta]:

 > the connector only appear on the UI if Akismet is installed.

 The current code shows the akismet connector for all users, not just those
 that have Akismet installed. Seeing that there are now six committers
 (seven based off of @matveb's comments) that are supporting the revert,
 that seems like the best immediate path.

 I stand by my original recommendation that no additional connectors should
 be added until some guidelines are agreed up and published on make/core
 for what connectors need in order to ship with core. I can absolutely see
 a possible result of that is shipping a connector for Akismet (or
 something similar), but for the time being, it's clear this code is not
 ready for WordPress.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:38>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 16:15:58 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 16:15:58 -0000
Subject: [wp-trac] [WordPress Trac] #52976: user emails comparison
 should be case insensitive
In-Reply-To: <050.7727b644129a97f4082fdf76cb8aa740@wordpress.org>
References: <050.7727b644129a97f4082fdf76cb8aa740@wordpress.org>
Message-ID: <065.26b1012ede6f8520d565cd43a4f73395@wordpress.org>

#52976: user emails comparison should be case insensitive
-------------------------------------------------+-------------------------
 Reporter:  asaifm                               |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Users                                |     Version:  4.3
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-patch has-        |     Focuses:
  screenshots has-unit-tests                     |
-------------------------------------------------+-------------------------

Comment (by ozgursar):

 == Patch Testing Report

 Patch Tested:
 https://core.trac.wordpress.org/attachment/ticket/52976/52976.2.diff

 === Environment
 - WordPress: 7.1-alpha-20260406.185701
 - PHP: 8.3.30
 - Server: PHP.wasm
 - Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
 - Browser: Chrome 146.0.0.0
 - OS: macOS
 - Theme: Twenty Fourteen 4.4
 - MU Plugins: None activated
 - Plugins:
   * Email Logger
   * Test Reports 1.2.1

 === Steps taken
 Install Email Logger plugin from
 https://make.wordpress.org/test/files/2026/02/wp-email-logger.zip

 Method1 - Manually
 1. Change your user's email from admin at localhost.com to
 ADMIN at localhost.com
 2. Observe email notification that contains the email change
 3. Apply patch and repeat the steps 1-2
 4. Observe email notification is not triggered
 5. ✅ Patch is solving the problem

 Method2 - Programmatically
 1. Install any classic theme
 2. Add the following code to your active theme's `functions.php`


 {{{
 $user_id = 1; // ID of the user you are testing
 $user = get_userdata($user_id);
 $original_email = $user->user_email; // e.g., "admin at localhost.com"
 $result = wp_update_user([
     'ID' => $user_id,
     'user_email' => strtoupper($original_email) // "ADMIN at LOCALHOST.COM"
 ]);
 }}}

 3. Visit Users page and observe the user's email
 4. Check email logs and observe the email change notification sent
 5. Apply patch and repeat the steps with a new user
 6. Observe that no notification email sent even though email changes.
 7. ✅ Patch is solving the problem

 In both Method 1 and Method 2, changing the email in any way other than
 capitalization successfully triggers the email change notification.

 === Expected result
 - We expect no notifications to be triggered if only the letter case
 changes.

 === Additional Notes
 - Other locations that use `!==` and `===` for emails comparisons should
 also be checked.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/52976#comment:19>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 16:17:08 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 16:17:08 -0000
Subject: [wp-trac] [WordPress Trac] #20044: Enable search for pages by
 slug
In-Reply-To: <052.b5c8b29675796ae358c80f6b8a682a41@wordpress.org>
References: <052.b5c8b29675796ae358c80f6b8a682a41@wordpress.org>
Message-ID: <067.d6a807ecc075bd0c4771bfd55064dcd0@wordpress.org>

#20044: Enable search for pages by slug
-------------------------+---------------------
 Reporter:  ekitomat     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:
Component:  Query        |     Version:  3.7
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |     Focuses:
-------------------------+---------------------

Comment (by kush123):

 == Test Report
 === Description
 ❌ No working patch available as existing patches (20044.diff →
 20044.5.diff are outdated)

 === Environment
 - WordPress: 7.1-alpha-62161-src
 - PHP: 8.2.28
 - Server: nginx/1.27.5
 - Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.28)
 - Browser: Chrome 144.0.0.0
 - OS: macOS
 - Theme: Twenty Twenty 3.0
 - MU Plugins: None activated
 - Plugins:
   * Test Reports 1.2.0

 === Actual Results
 1.  ❌ Issue not resolved with the patch, and the issue is still present.

 === Steps to Reproduce
 - Navigate to Pages → Add New and create a page with the title "Slug
 Search Test" and the slug slug-search-test.
 - Publish the page.
 - Go to Pages → All Pages and enter slug-search-test into the search box.
 - Navigate to the site frontend and use the search widget to search for
 the same slug: slug-search-test.
 - 🐞 Bug occurs.

 === Supplemental Artifacts
 [[Image(https://core.trac.wordpress.org/raw-
 attachment/ticket/20044/Screenshot%202026-04-06%20at%209.37.12%E2%80%AFPM.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/20044#comment:18>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 16:35:01 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 16:35:01 -0000
Subject: [wp-trac] [WordPress Trac] #58288: No support for JPG with HDR
 gain maps
In-Reply-To: <052.4ee318d9656f525cea014289978fb735@wordpress.org>
References: <052.4ee318d9656f525cea014289978fb735@wordpress.org>
Message-ID: <067.b6372901e069df89e36ac6593a03be26@wordpress.org>

#58288: No support for JPG with HDR gain maps
--------------------------+------------------------------
 Reporter:  gregbenz      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Media         |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by gregbenz):

 This issue is scheduled to be addressed with client-side transcoding in
 WordPress v7.1. The wasm-vips library properly supports JPG gain maps.
 https://github.com/WordPress/gutenberg/issues/76756

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/58288#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 16:40:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 16:40:05 -0000
Subject: [wp-trac] [WordPress Trac] #59508: Cannot bypass image
 reprocessing for specific images => media library breaks HDR JPGs
In-Reply-To: <052.b8aefefc6f3a7ef475a10eea0bbecab1@wordpress.org>
References: <052.b8aefefc6f3a7ef475a10eea0bbecab1@wordpress.org>
Message-ID: <067.45b2d6fd15cb49b37fcee9f03e67259f@wordpress.org>

#59508: Cannot bypass image reprocessing for specific images => media library
breaks HDR JPGs
--------------------------+----------------------
 Reporter:  gregbenz      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  General       |     Version:
 Severity:  normal        |  Resolution:  invalid
 Keywords:                |     Focuses:
--------------------------+----------------------

Comment (by gregbenz):

 This issue is scheduled to be addressed in WordPress v7.1
 (https://github.com/WordPress/gutenberg/issues/76756) with use of wasm-
 vips for client-side transcoding during upload. I have validated that
 wasm-vips properly transcodes these images, so the core library appears to
 be in good shape (built on libultrahdr, which also implies support for
 AVIF gain maps should also be feasible when the roadmap for that library
 is completed).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59508#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 17:32:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 17:32:29 -0000
Subject: [wp-trac] [WordPress Trac] #64595: Update Gutenberg ref in
 package.json
In-Reply-To: <052.77ee8574fdbbcf6ccf6ecf00bf3f7a14@wordpress.org>
References: <052.77ee8574fdbbcf6ccf6ecf00bf3f7a14@wordpress.org>
Message-ID: <067.d0f3b785485b06118e4a796a44ec86ee@wordpress.org>

#64595: Update Gutenberg ref in package.json
----------------------------+---------------------
 Reporter:  ellatrix        |       Owner:  (none)
     Type:  task (blessed)  |      Status:  new
 Priority:  normal          |   Milestone:  7.0
Component:  General         |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+---------------------

Comment (by jorgefilipecosta):

 In [changeset:"62209" 62209]:
 {{{
 #!CommitTicketReference repository="" revision="62209"
 Editor: Bump pinned hash for the Gutenberg repository.

 This updates the pinned hash from the `gutenberg` from
 `0d133bf7e7437d65d68a06551f3d613a7d8e4361` to
 `e2970ba736edb99e08fb369d4fb0c378189468ee`.
 The following changes are included:

 - https://github.com/WordPress/gutenberg/pull/76478 Boot: Fix black area
 below content when sidebar is taller than page c…
 (https://github.com/WordPress/gutenberg/pull/76764)
 - Style Book: Fix missing styles for classic themes in stylebook route
 (https://github.com/WordPress/gutenberg/pull/76843)
 - RTC: Fix stuck "Join" link in post list when lock expires
 (https://github.com/WordPress/gutenberg/pull/76795)
 - Icon: Fix center alignment in the editor for classic themes
 (https://github.com/WordPress/gutenberg/pull/76878)
 - RTC: Fix notes not syncing between collaborative editors
 (https://github.com/WordPress/gutenberg/pull/76873)
 - Latest Comments: Fix v1 deprecated block missing supports
 (https://github.com/WordPress/gutenberg/pull/76877)
 - Connectors: Add Akismet as a default connector
 (https://github.com/WordPress/gutenberg/pull/76828)
 - Restore with compaction update
 (https://github.com/WordPress/gutenberg/pull/76872)
 - Improve JSDoc for abilities API
 (https://github.com/WordPress/gutenberg/pull/76824)
 - Connectors: Replace plugin.slug with plugin.file
 (https://github.com/WordPress/gutenberg/pull/76909)
 - Block visibility badge: use canvas iframe for viewport detection
 (https://github.com/WordPress/gutenberg/pull/76889)
 - Connectors: Update help text from 'reset' to 'manage'
 (https://github.com/WordPress/gutenberg/pull/76963)
 - Connectors: Hide Akismet unless already installed
 (https://github.com/WordPress/gutenberg/pull/76962)
 - Wrap sync update processing in try/catch
 (https://github.com/WordPress/gutenberg/pull/76968)
 - Backport: Improve validation and permission checks for
 `WP_HTTP_Polling_Sync_Server`
 (https://github.com/WordPress/gutenberg/pull/76987)
 - Connectors: account for mu-plugins when resolving plugin.file status
 (https://github.com/WordPress/gutenberg/pull/76994)


 A full list of changes can be found on GitHub:
 https://github.com/WordPress/gutenberg/compare/0d133bf7e7437d65d68a06551f3d613a7d8e4361…e2970ba736edb99e08fb369d4fb0c378189468ee.

 Log created with:

 git log --reverse --format="- %s"
 0d133bf7e7437d65d68a06551f3d613a7d8e4361..e2970ba736edb99e08fb369d4fb0c378189468ee
 | sed
 's|#\([0-9][0-9]*\)|https://github.com/WordPress/gutenberg/pull/\1|g;
 /github\.com\/WordPress\/gutenberg\/pull/!d' | pbcopy

 See #64595.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64595#comment:50>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 18:00:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 18:00:13 -0000
Subject: [wp-trac] [WordPress Trac] #64656: Fatal error on new font
 library admin page
In-Reply-To: <051.452a77fdc7ce1f6e32036f66207914fe@wordpress.org>
References: <051.452a77fdc7ce1f6e32036f66207914fe@wordpress.org>
Message-ID: <066.f2f2e766cb1102355b6e19357a7493ee@wordpress.org>

#64656: Fatal error on new font library admin page
----------------------------+--------------------------
 Reporter:  desrosj         |       Owner:  youknowriad
     Type:  defect (bug)    |      Status:  reopened
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+--------------------------
Changes (by pbearne):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 I am seeing this issue
 I am loading the trunk as of 04-06, and my constats.php is


 {{{#!php
 <?php

 /**
  * Plugin constants - Auto-generated by build process.
  * Do not edit this file manually.
  *
  * Returns an array of constants for use in other templates.
  *
  * @package wp
  */

 return array(
         'version' => '22.6.0-rc.1',
         'build_url' => includes_url(,
 );
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64656#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 19:22:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 19:22:44 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.f0c09033608420b150af238327a33aae@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  feature request   |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  Plugins           |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  has-patch revert  |     Focuses:
------------------------------+-------------------------------

Comment (by jorbin):

 In [changeset:"62210" 62210]:
 {{{
 #!CommitTicketReference repository="" revision="62210"
 Revert Register Akismet Anti-Spam as a connector.

 This reverts [62193]. The connector for Akismet shouldn't show up when
 akismet is not installed. The plugin itself can register the connecter
 when it is activated.

 Follow-up to [62193].

 See #65012.
 Props peterwilsoncc, jorgefilipecosta, johnbillion, eclev91, desrosj,
 davidbaumwald, jorbin.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:39>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 19:23:32 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 19:23:32 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.bdc655d8a2b48ec84fb11917cc39dba6@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  feature request   |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  Plugins           |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+-------------------------------
Changes (by jorbin):

 * keywords:  has-patch revert => has-patch


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:40>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 19:34:38 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 19:34:38 -0000
Subject: [wp-trac] [WordPress Trac] #65028: no error message when installing
 connector if File system read only
Message-ID: <051.dba1e5b249ba8e02e154d12428f5633b@wordpress.org>

#65028: no error message when installing connector if File system read only
--------------------------+-------------------------
 Reporter:  pbearne       |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  7.0
Component:  AI            |    Version:  trunk
 Severity:  normal        |   Keywords:  needs-patch
  Focuses:                |
--------------------------+-------------------------
 When I click the install button, I see this error in the inspector, but
 getting any feedback on the page


 {{{
 {
     "code": "fs_unavailable",
     "message": "The filesystem is currently unavailable for managing
 plugins.",
     "data": {
         "status": 500
     }
 }
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65028>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 20:03:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 20:03:07 -0000
Subject: [wp-trac] [WordPress Trac] #64976: Admin Style: Plugin links
 change styles on updates on 7.0
In-Reply-To: <052.33a9a520dd04c4f79918027e12c9cff4@wordpress.org>
References: <052.33a9a520dd04c4f79918027e12c9cff4@wordpress.org>
Message-ID: <067.0fb3089c0f39a6be822e4649ecedc7aa@wordpress.org>

#64976: Admin Style: Plugin links change styles on updates on 7.0
-------------------------------------------------+-------------------------
 Reporter:  antonynz                             |       Owner:  joedolson
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  minor                                |  Resolution:  fixed
 Keywords:  admin-reskin has-patch has-          |     Focuses:
  screenshots dev-reviewed                       |
-------------------------------------------------+-------------------------
Changes (by joedolson):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62211" 62211]:
 {{{
 #!CommitTicketReference repository="" revision="62211"
 Admin: Limit scope of admin notice link design.

 The design changes to admin notices links in the admin refresh were
 applied broadly to .notice, .error, and .updated classes, but these
 classes are sometimes used outside the context of an admin notice.

 Change selectors from .notice a, .error a, .updated a to div.notice a,
 div.error a, div.updated a.

 Reviewed by audrasjb.
 Merges [62200] to the 7.0 branch.

 Props opurockey, audrasjb, vgnavada, gaisma22, shailu25, rbcorrales,
 joedolson.
 Fixes #64976.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64976#comment:17>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 20:07:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 20:07:22 -0000
Subject: [wp-trac] [WordPress Trac] #54016: Media Library: Bulk delete
 elements in grid view takes very long
In-Reply-To: <053.163729d7b8e833e3128db8a5d8edb4b2@wordpress.org>
References: <053.163729d7b8e833e3128db8a5d8edb4b2@wordpress.org>
Message-ID: <068.1842d79fc9a59e57e3d5f14841b76ff6@wordpress.org>

#54016: Media Library: Bulk delete elements in grid view takes very long
-------------------------------------------------+-------------------------
 Reporter:  Presskopp                            |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Media                                |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch 2nd-opinion needs-testing  |     Focuses:
                                                 |  performance
-------------------------------------------------+-------------------------
Changes (by jdeep):

 * keywords:  has-patch => has-patch 2nd-opinion needs-testing


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/54016#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 21:46:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 21:46:12 -0000
Subject: [wp-trac] [WordPress Trac] #64595: Update Gutenberg ref in
 package.json
In-Reply-To: <052.77ee8574fdbbcf6ccf6ecf00bf3f7a14@wordpress.org>
References: <052.77ee8574fdbbcf6ccf6ecf00bf3f7a14@wordpress.org>
Message-ID: <067.99b7a77b9b656cfc48ab633b0834d678@wordpress.org>

#64595: Update Gutenberg ref in package.json
----------------------------+---------------------
 Reporter:  ellatrix        |       Owner:  (none)
     Type:  task (blessed)  |      Status:  new
 Priority:  normal          |   Milestone:  7.0
Component:  General         |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+---------------------

Comment (by jorgefilipecosta):

 In [changeset:"62212" 62212]:
 {{{
 #!CommitTicketReference repository="" revision="62212"
 Editor: Bump pinned hash for the Gutenberg repository.

 This updates the pinned hash from the `gutenberg` from
 `0d133bf7e7437d65d68a06551f3d613a7d8e4361` to
 `e2970ba736edb99e08fb369d4fb0c378189468ee`.
 The following changes are included:

 - WordPress/gutenberg#76478 Boot: Fix black area below content when
 sidebar is taller than page c… (WordPress/gutenberg#76764)
 - Style Book: Fix missing styles for classic themes in stylebook route
 (WordPress/gutenberg#76843)
 - RTC: Fix stuck "Join" link in post list when lock expires
 (WordPress/gutenberg#76795)
 - Icon: Fix center alignment in the editor for classic themes
 (WordPress/gutenberg#76878)
 - RTC: Fix notes not syncing between collaborative editors
 (WordPress/gutenberg#76873)
 - Latest Comments: Fix v1 deprecated block missing supports
 (WordPress/gutenberg#76877)
 - Connectors: Add Akismet as a default connector
 (WordPress/gutenberg#76828)
 - Restore with compaction update (WordPress/gutenberg#76872)
 - Improve JSDoc for abilities API (WordPress/gutenberg#76824)
 - Connectors: Replace plugin.slug with plugin.file
 (WordPress/gutenberg#76909)
 - Block visibility badge: use canvas iframe for viewport detection
 (WordPress/gutenberg#76889)
 - Connectors: Update help text from 'reset' to 'manage'
 (WordPress/gutenberg#76963)
 - Connectors: Hide Akismet unless already installed
 (WordPress/gutenberg#76962)
 - Wrap sync update processing in try/catch (WordPress/gutenberg#76968)
 - Backport: Improve validation and permission checks for
 `WP_HTTP_Polling_Sync_Server` (WordPress/gutenberg#76987)
 - Connectors: account for mu-plugins when resolving plugin.file status
 (WordPress/gutenberg#76994)


 A full list of changes can be found on GitHub:
 https://github.com/WordPress/gutenberg/compare/0d133bf7e7437d65d68a06551f3d613a7d8e4361…e2970ba736edb99e08fb369d4fb0c378189468ee.

 Log created with:

 git log --reverse --format="- %s"
 0d133bf7e7437d65d68a06551f3d613a7d8e4361..e2970ba736edb99e08fb369d4fb0c378189468ee
 | sed
 's|#\([0-9][0-9]*\)|https://github.com/WordPress/gutenberg/pull/\1|g;
 /github\.com\/WordPress\/gutenberg\/pull/!d' | pbcopy

 See #64595.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64595#comment:51>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr  6 23:51:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 06 Apr 2026 23:51:57 -0000
Subject: [wp-trac] [WordPress Trac] #64225: Test tool and unit test
 improvements for 7.0
In-Reply-To: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
References: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
Message-ID: <066.b1e65b125e99a31febe34389065397b9@wordpress.org>

#64225: Test tool and unit test improvements for 7.0
--------------------------------------+---------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  task (blessed)            |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by SergeyBiryukov):

 In [changeset:"62213" 62213]:
 {{{
 #!CommitTicketReference repository="" revision="62213"
 Tests: Add missing `@covers` tags for some multisite tests.

 See #64225.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64225#comment:55>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 00:23:24 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 00:23:24 -0000
Subject: [wp-trac] [WordPress Trac] #56878: Remove Desktopserver
 references from the docs
In-Reply-To: <055.2ae5a1b5f47f7178487c157e3829f2fa@wordpress.org>
References: <055.2ae5a1b5f47f7178487c157e3829f2fa@wordpress.org>
Message-ID: <070.3e24641828ce0c352958aa6619cae5b8@wordpress.org>

#56878: Remove Desktopserver references from the docs
--------------------------+----------------------------
 Reporter:  mayankgupta   |       Owner:  (none)
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:  WordPress.org
Component:  General       |     Version:
 Severity:  normal        |  Resolution:  fixed
 Keywords:                |     Focuses:  docs
--------------------------+----------------------------
Changes (by sabernhardt):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 As noted in [https://github.com/WordPress/Documentation-Issue-
 Tracker/issues/400 issue 400], "this has been resolved in the core
 handbook"

 (The "Installing DesktopServer" page was removed without a redirect, which
 simply gives the `404` error.)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/56878#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 00:43:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 00:43:18 -0000
Subject: [wp-trac] [WordPress Trac] #65022: Posts list: replace (no
 title) filler when a title isn't set with something more useful.
In-Reply-To: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
References: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
Message-ID: <067.3874431c28a188c7c4a3836d258148a4@wordpress.org>

#65022: Posts list: replace (no title) filler when a title isn't set with something
more useful.
-------------------------------+-----------------------------
 Reporter:  annezazu           |       Owner:  SergeyBiryukov
     Type:  enhancement        |      Status:  accepted
 Priority:  normal             |   Milestone:  7.1
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:  administration
-------------------------------+-----------------------------
Changes (by annezazu):

 * Attachment "no title first in italics.png" added.

 No title listed first before excerpt in italics

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65022>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 00:43:50 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 00:43:50 -0000
Subject: [wp-trac] [WordPress Trac] #65022: Posts list: replace (no
 title) filler when a title isn't set with something more useful.
In-Reply-To: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
References: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
Message-ID: <067.fdfc0a54eb1562d8faedd9e989d2c56d@wordpress.org>

#65022: Posts list: replace (no title) filler when a title isn't set with something
more useful.
-------------------------------+-----------------------------
 Reporter:  annezazu           |       Owner:  SergeyBiryukov
     Type:  enhancement        |      Status:  accepted
 Priority:  normal             |   Milestone:  7.1
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:  administration
-------------------------------+-----------------------------

Comment (by annezazu):

 I'd prefer the (no title) first then the first sentence as shown above. To
 me, without it, it becomes harder to skim which posts don't have titles.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65022#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 01:09:36 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 01:09:36 -0000
Subject: [wp-trac] [WordPress Trac] #60420: Default wordpress@site.com
 sender address can be problematic
In-Reply-To: <054.d3bd9eee2d6f2124576c55af40233ad9@wordpress.org>
References: <054.d3bd9eee2d6f2124576c55af40233ad9@wordpress.org>
Message-ID: <069.04b6fdf2651ece72cd9f4865df58f995@wordpress.org>

#60420: Default wordpress at site.com sender address can be problematic
-----------------------------+------------------------------
 Reporter:  thinlinecz       |       Owner:  (none)
     Type:  feature request  |      Status:  reopened
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Mail             |     Version:  1.5.1.2
 Severity:  normal           |  Resolution:
 Keywords:  close            |     Focuses:
-----------------------------+------------------------------

Comment (by michael.orlitzky):

 Replying to [comment:63 dmsnell]:
 >
 > > All of these problems boil down to one thing: the lack of a text box
 to type in a usable address in a manner that is consistent with the design
 of WP, the internet, and hosting environments.
 >
 > This sounds like a good thing to add in a plugin as
 [https://core.trac.wordpress.org/ticket/60420#comment:16 @desrosj]
 suggested eight months ago. It’s far easier to discuss something that
 exists and is in use than a confusing back-and-forth of hypotheticals.
 Hosts can install the plugin and test it and provide feedback. Anyone with
 email troubles can install it.

 You are suggesting that we leave the core WP functionality broken, and
 provide a way for administrators to work around it once they discover the
 breakage. But that's the situation everyone is already complaining about.
 Users/admins should not have to lose important emails or deal with
 customer complaints as step zero towards solving this problem.

 The broken functionality is in WP core, and it is broken because of a line
 of code in WP core. It should be fixed in WP core, and the solution is
 trivial.

 > As has been brought up by others in this ticket, even adding the text
 box presents coordination problems when hosts and site admins have
 different understandings of what //should// be set as the sender address.

 "What if someone types the wrong thing in the box???" is not a serious
 criticism of an option that is currently hard-coded to the wrong value.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60420#comment:64>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 05:25:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 05:25:05 -0000
Subject: [wp-trac] [WordPress Trac] #43502:
 `WP_REST_Posts_Controller::prepare_item_for_response()` doesn't reset
 postdata after calling setup_postdata()
In-Reply-To: <057.83d91ea915ff38acf2097fa68d250dca@wordpress.org>
References: <057.83d91ea915ff38acf2097fa68d250dca@wordpress.org>
Message-ID: <072.4fe3311fa62759f1ad56c7e2ffb02abb@wordpress.org>

#43502: `WP_REST_Posts_Controller::prepare_item_for_response()` doesn't reset
postdata after calling setup_postdata()
-------------------------------------------------+-------------------------
 Reporter:  gerbenvandijk                        |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  REST API                             |     Version:  4.9.4
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-patch has-unit-   |     Focuses:  rest-api
  tests                                          |
-------------------------------------------------+-------------------------
Changes (by liaison):

 * Attachment "ticket-43502.png" added.

 github CI actions 238 check pass.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/43502>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 05:31:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 05:31:49 -0000
Subject: [wp-trac] [WordPress Trac] #43502:
 `WP_REST_Posts_Controller::prepare_item_for_response()` doesn't reset
 postdata after calling setup_postdata()
In-Reply-To: <057.83d91ea915ff38acf2097fa68d250dca@wordpress.org>
References: <057.83d91ea915ff38acf2097fa68d250dca@wordpress.org>
Message-ID: <072.f75e090dcce9888218212bda131b6364@wordpress.org>

#43502: `WP_REST_Posts_Controller::prepare_item_for_response()` doesn't reset
postdata after calling setup_postdata()
-------------------------------------------------+-------------------------
 Reporter:  gerbenvandijk                        |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  REST API                             |     Version:  4.9.4
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-patch has-unit-   |     Focuses:  rest-api
  tests                                          |
-------------------------------------------------+-------------------------

Comment (by liaison):

 I've refreshed the patch and opened PR #11455.

 Tests conducted:
 * Verified all 238 CI checks passed (PHP 7.2 - 8.4).
 * Included 2 new unit tests specifically for global $post restoration (one
 for existing post, one for null).
 * Confirmed fix for 'pollution' during internal REST API calls.

 [[Image(ticket-43502.png, 600px)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/43502#comment:28>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 05:31:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 05:31:53 -0000
Subject: [wp-trac] [WordPress Trac] #65017: Dashboard widgets border
 bottom issue when it is closed in version 7.0 RC2
In-Reply-To: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
References: <055.3f9b68260d228fbdd2f93d8b1c45eca5@wordpress.org>
Message-ID: <070.b5a66467952b3832400e75f3e9d0abbe@wordpress.org>

#65017: Dashboard widgets border bottom issue when it is closed in version 7.0 RC2
-------------------------------------------------+-------------------------
 Reporter:  Pratik Jain                          |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-screenshots has-patch dev-       |     Focuses:  ui, css
  reviewed commit                                |
-------------------------------------------------+-------------------------
Changes (by audrasjb):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62214" 62214]:
 {{{
 #!CommitTicketReference repository="" revision="62214"
 Administration: Improve dashboard widgets border styles.

 This changeset fixes a CSS glitch on dashboard widgets bottom border when
 they are collapsed.

 Follow-up to [61646].

 Reviewed by westonruter.
 Merges [62206] to the 7.0 branch.

 Props pratik-jain, audrasjb, ankitkumarshah.
 Fixes #65017.
 See #64549.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65017#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 05:31:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 05:31:53 -0000
Subject: [wp-trac] [WordPress Trac] #64549: Admin Reskin: Update card
 and metabox styling to align with WordPress Design System
In-Reply-To: <055.2b95acb44717d717d3e8d12a7e1a4a5f@wordpress.org>
References: <055.2b95acb44717d717d3e8d12a7e1a4a5f@wordpress.org>
Message-ID: <070.4f134e82b8a9614c4cccb864df0e4650@wordpress.org>

#64549: Admin Reskin: Update card and metabox styling to align with WordPress
Design System
----------------------------+-------------------------------------
 Reporter:  fabiankaegy     |       Owner:  joedolson
     Type:  enhancement     |      Status:  closed
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:  fixed
 Keywords:  has-patch       |     Focuses:  ui, accessibility, css
----------------------------+-------------------------------------

Comment (by audrasjb):

 In [changeset:"62214" 62214]:
 {{{
 #!CommitTicketReference repository="" revision="62214"
 Administration: Improve dashboard widgets border styles.

 This changeset fixes a CSS glitch on dashboard widgets bottom border when
 they are collapsed.

 Follow-up to [61646].

 Reviewed by westonruter.
 Merges [62206] to the 7.0 branch.

 Props pratik-jain, audrasjb, ankitkumarshah.
 Fixes #65017.
 See #64549.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64549#comment:19>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 05:35:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 05:35:03 -0000
Subject: [wp-trac] [WordPress Trac] #64994: Add context to the "Bulk
 edit" string in `get_bulk_actions()`
In-Reply-To: <052.a01757996873f8b092dbc098d7f5bc61@wordpress.org>
References: <052.a01757996873f8b092dbc098d7f5bc61@wordpress.org>
Message-ID: <067.64152918aa70ea67c1dab42f4b606494@wordpress.org>

#64994: Add context to the "Bulk edit" string in `get_bulk_actions()`
-------------------------------------------------+-------------------------
 Reporter:  audrasjb                             |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  I18N                                 |     Version:  trunk
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch i18n-change dev-reviewed   |     Focuses:
  commit                                         |
-------------------------------------------------+-------------------------
Changes (by audrasjb):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62215" 62215]:
 {{{
 #!CommitTicketReference repository="" revision="62215"
 I18N: Provide gettext context to disambiguate translation strings for
 "Bulk Edit".

 The "Bulk Edit" translation string is used for both verbs and nouns, and
 may have different translations in some Locales. This changeset helps
 disambuguating these different contexts.

 Follow-up to [61255].

 Reviewed by westonruter.
 Merges [62186] to the 7.0 branch.

 Props audrasjb, shailu25.
 Fixes #64994.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64994#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 06:25:20 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 06:25:20 -0000
Subject: [wp-trac] [WordPress Trac] #56254: PHP Warning: Undefined array
 key 1 wp-admin\menu-header.php on line 202
In-Reply-To: <053.65f01ced154e72c6304dda58f63ec838@wordpress.org>
References: <053.65f01ced154e72c6304dda58f63ec838@wordpress.org>
Message-ID: <068.a570f75770a682bb1303809f19a8275f@wordpress.org>

#56254: PHP Warning:  Undefined array key 1 wp-admin\menu-header.php on line 202
----------------------------------------------+----------------------------
 Reporter:  pras.88in                         |       Owner:  (none)
     Type:  defect (bug)                      |      Status:  new
 Priority:  normal                            |   Milestone:  Awaiting
                                              |  Review
Component:  Administration                    |     Version:
 Severity:  normal                            |  Resolution:
 Keywords:  php81 has-patch needs-unit-tests  |     Focuses:
----------------------------------------------+----------------------------

Comment (by lakshyajeet):

 == Reproduction Report

 === Description
 This report validates whether the issue described in Trac #56254 can be
 reproduced.

 === Environment
 - WordPress: 7.1-alpha-62161-src
 - PHP: 8.3.30
 - Server: nginx/1.29.7
 - Database: mysqli (Server: 8.4.8 / Client: mysqlnd 8.3.30)
 - Browser: Chrome 146.0.0.0
 - OS: macOS
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None activated
 - Plugins: None activated

 === Steps to Reproduce
 1. Install and activate the plugin below.
 2. Log in as an administrator and navigate to any wp-admin page.
 3. Observe the PHP warning in the debug log or on screen.

 === Minimal Reproduction Code

 {{{#!php
 <?php
 /**
  * Plugin Name: Reproduce Trac #56254
  */

 add_action( 'admin_menu', 'r56254_register_menus' );

 function r56254_register_menus(): void {
     add_menu_page(
         'Reproduce #56254',          // page title
         'Reproduce #56254',          // menu title
         'manage_options',            // capability
         'reproduce-56254',           // menu slug
         'r56254_page_callback',      // callback
         'dashicons-warning',         // icon
         80                           // position
     );

     add_submenu_page(
         'reproduce-56254',
         'Good Submenu',
         'Good Submenu',
         'manage_options',            // capability present
         'reproduce-56254-good',
         'r56254_page_callback'
     );

     // Malformed submenu - missing capability
     global $submenu;

     // The array structure core expects: [title, capability, slug,
 page_title]
     // We deliberately omit index 1 (capability) to trigger the warning.
     $submenu['reproduce-56254'][] = [
         0 => 'Broken Submenu',   // menu title
         // 1 => capability       - INTENTIONALLY MISSING (triggers the
 bug)
         2 => 'reproduce-56254-broken',  // slug
         3 => 'Broken Submenu',          // page title
     ];
 }

 function r56254_page_callback(): void {
     echo '<div class="wrap"><h1>Reproduce Trac #56254</h1></div>';
 }

 }}}

 === Actual Results
 1.  ✅ Error condition occurs (reproduced).

 === Additional Notes
 - The warning is reproducible, but this may be expected behavior on the
 core side. `add_submenu_page()` enforces a non-empty capability as a
 required parameter, meaning the `$sub_item[1]` slot is always populated
 under normal usage. The missing key only appears when a plugin or theme
 bypasses the API and writes directly into the global `$submenu` array with
 a malformed entry. This suggests the root cause likely lives in a third-
 party plugin rather than in WordPress core. The defensive guard proposed
 in PR would still be a reasonable hardening measure, but the underlying
 fault is arguably the misbehaving plugin.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/56254#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 06:56:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 06:56:09 -0000
Subject: [wp-trac] [WordPress Trac] #47359: Unable to distinguish post
 formats when viewing list tables on mobile
In-Reply-To: <053.e918317cf894ffaed4656b8fe275881a@wordpress.org>
References: <053.e918317cf894ffaed4656b8fe275881a@wordpress.org>
Message-ID: <068.cd27c517a55debcc31ef8e11e9ada1d7@wordpress.org>

#47359: Unable to distinguish post formats when viewing list tables on mobile
-------------------------------------------------+-------------------------
 Reporter:  ajfleming                            |       Owner:  joedolson
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Post Formats                         |     Version:  5.2.1
 Severity:  normal                               |  Resolution:
 Keywords:  needs-design has-screenshots needs-  |     Focuses:  ui,
  patch                                          |  accessibility
-------------------------------------------------+-------------------------

Comment (by sanket.parmar):

 Building on comment:2 and comment:16, here are two narrower tracks that
 could produce a reviewable patch independently of the broader disclosure-
 panel restructuring.

 '''Track A — Filterability: CSS selector precision (no PHP change)'''

 The ≤782px breakpoint hides filter controls via an overly broad selector
 in
 `src/wp-admin/css/list-tables.css`:

 {{{
 .tablenav.top .actions,    /* hides .bulkactions AND the filter controls
 div */
 .tablenav .view-switch {
     display: none;
 }
 }}}

 The bulk actions `<div>` already carries `.bulkactions` alongside
 `.actions`.
 The filter controls `<div>` does not. So a one-line selector change would
 expose
 all filter dropdowns (date, categories, post format, and plugin-added
 filters) on
 mobile:

 {{{
 .tablenav.top .bulkactions,
 .tablenav .view-switch {
     display: none;
 }
 }}}

 Bulk actions remain available in the bottom tablenav. Note this would
 affect
 all list tables on mobile, not just posts — which is consistent with the
 broader
 concern in comment:2, but worth flagging in case it's considered too broad
 a change.
 It would also need supplemental layout CSS for the stacked view at narrow
 widths,
 and a design mockup per the `needs-design` keyword.

 '''Track B — Visibility: inline format label in the primary column (PHP +
 CSS)'''

 For the original use case — identifying a post's format at a glance
 without
 needing to filter — a text label in `column_title()` following the
 existing
 `_post_states()` pattern would work:

 {{{
 #!php
 // After _post_states( $post ), inside column_title():
 $format = get_post_format( $post->ID );
 if ( $format && 'standard' !== $format
     && is_object_in_taxonomy( $post->post_type, 'post_format' )
 ) {
     echo ' &mdash; <span class="post-format-state">'
         . esc_html( get_post_format_string( $format ) )
         . '</span>';
 }
 }}}

 Restricted to mobile only, and intentionally avoiding the icon approach
 removed
 in [changeset:45136] per #46591:

 {{{
 #!css
 .post-format-state { display: none; }

 @media screen and (max-width: 782px) {
     .post-format-state { display: inline; }
 }
 }}}

 Note that Track B addresses only visibility (identifying a post's format
 in the
 list), not filterability. The two tracks are independent of each other.
 Happy to
 put together a formal patch for either if the direction aligns.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47359#comment:20>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 07:04:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 07:04:21 -0000
Subject: [wp-trac] [WordPress Trac] #65029: Trac Ticket: Keyboard Shortcut
 to Toggle Toolbar on Frontend
Message-ID: <050.6dc60cf2bb50968de73232ec75bf728d@wordpress.org>

#65029: Trac Ticket: Keyboard Shortcut to Toggle Toolbar on Frontend
-------------------------+-----------------------------
 Reporter:  apermo       |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  Toolbar      |    Version:
 Severity:  normal       |   Keywords:
  Focuses:               |
-------------------------+-----------------------------
 Add a keyboard shortcut (access+w) to temporarily hide and show the
 toolbar on the frontend. This gives logged-in users a quick way to preview
 their site without the toolbar, without navigating to Profile settings or
 logging out.

 Description

 When working on a site's frontend, the toolbar covers the top 32px (46px
 on mobile) of the page. Designers, content editors, and developers
 frequently need to see the page without it — for screenshots, visual
 testing, or checking how fixed headers behave. Today the only options are:

 1. Uncheck "Show Toolbar when viewing site" in the user profile (requires
 a page reload)
 2. Use show_admin_bar( false ) in code (requires a code change and reload)
 3. Use browser DevTools to hide the element manually
 4. Install a plugin (e.g. https://wordpress.org/plugins/apermo-adminbar-
 toggle/)

 None of these are fast or convenient for a quick toggle.

 Proposed Solution

 A keyboard shortcut using the WordPress access modifier pattern:

 - Windows/Linux: Alt+Shift+W
 - Mac: Ctrl+Option+W

 The "W" key is mnemonic for "WordPress toolbar." This follows the same
 modifier pattern used by all existing WordPress keyboard shortcuts (e.g.
 access+h for help, access+d for strikethrough), ensuring consistency.

 Behavior

 - Toggle only: The shortcut hides the toolbar; pressing it again brings it
 back.
 - No persistence: The state resets on page navigation. This is intentional
 — the feature is for quick previews, not a permanent setting.
 - Frontend only: The shortcut does not work in wp-admin, where the toolbar
 is part of the fixed layout and is not optional by design (see #19685).
 - Smooth animation: The toolbar slides up/down with a 200ms CSS
 transition.
 - Page spacing adjusts: The --wp-admin--admin-bar--height custom property
 is set to 0px when hidden, so scroll-padding-top and the bump margin-top
 adjust automatically. No content jump.
 - Accessible: An aria-live region announces "Toolbar hidden." / "Toolbar
 visible." for screen reader users. The toolbar element gets aria-
 hidden="true" when hidden.

 Shortcut Conflict Analysis

 The access+w shortcut was chosen after an audit of all existing shortcuts:

 WordPress: The letter w is completely free in both the classic editor and
 block editor access modifier space. No WordPress core shortcut uses
 access+w.

 Browsers: Alt+Shift+W / Ctrl+Option+W has no known conflicts in Chrome,
 Firefox, Safari, or Edge on any platform. (By contrast, access+b — "B for
 Bar" — conflicts with Chrome/Edge's "focus bookmarks bar" on
 Windows/Linux.)

 Historical note: WordPress previously used Alt+Shift+W for "Distraction
 Free Writing" mode, which was removed years ago. The association with
 "toggling a UI element for focus" is fitting.

 Prior Art

 - In 2016 I released a plugin, that never good notable attention with the
 feature https://wordpress.org/plugins/apermo-adminbar/ and
 https://wordpress.org/plugins/apermo-adminbar-toggle/
 - #53184 discusses auto-hiding the toolbar but does not propose a keyboard
 shortcut.
 - No existing Trac ticket specifically requests a keyboard shortcut to
 toggle the toolbar.

 Implementation

 The patch modifies three files:

 1. src/js/_enqueues/lib/admin-bar.js — Adds a keydown listener for
 access+w (frontend only), a toggleToolbar() function that toggles the wp-
 toolbar-hidden class on <html>, and screen reader announcements via a live
 region.
 2. src/wp-includes/css/admin-bar.css — Adds the html.wp-toolbar-hidden
 rules: sets --wp-admin--admin-bar--height: 0px, overrides the bump margin-
 top, and uses transform: translateY(-100%) with visibility: hidden to
 slide the bar out.
 3. src/wp-includes/class-wp-admin-bar.php — Adds wp_localize_script for
 the two screen reader strings (toolbarHidden, toolbarVisible).

 Theme Compatibility

 Themes that use var(--wp-admin--admin-bar--height) for their toolbar
 offset will adjust automatically. Themes that hardcode a 32px top offset
 based on the .admin-bar body class will not adjust, but this is the same
 limitation that exists when users disable the toolbar via Profile settings
 today.

 Themes can also use the html.wp-toolbar-hidden selector to apply custom
 styles when the toolbar is hidden.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65029>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 07:07:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 07:07:48 -0000
Subject: [wp-trac] [WordPress Trac] #65018: WordPress Post Edit Screen
 Content Overflow Issue in version 7.0 RC2
In-Reply-To: <055.e55fb8bae717ff9f69325eb98e7f0c10@wordpress.org>
References: <055.e55fb8bae717ff9f69325eb98e7f0c10@wordpress.org>
Message-ID: <070.dd9ccb2a80261a9e4b96240e65ce2dd9@wordpress.org>

#65018: WordPress Post Edit Screen Content Overflow Issue in version 7.0 RC2
-------------------------------------+------------------------------
 Reporter:  Pratik Jain              |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch has-test-info  |     Focuses:  ui, css
-------------------------------------+------------------------------

Comment (by rshultz1):

 Tested the attached patch on a LocalWP environment on Windows.

 Environment:

 WordPress 7.0 RC2
 LocalWP on Windows 11
 PHP 8.2.x
 Browser: Chrome 135
 Theme: Twenty Twenty-Five
 Screen size: 1366×768

 Steps to reproduce:
 1.      Open the post edit screen (/wp-admin/post.php).
 2.      Drag metaboxes such as Categories or Tags.
 3.      Observe horizontal overflow and layout shifting during drag.

 Results before patch:
         Horizontal overflow occurs.
         Layout shifts while dragging metaboxes.

 Results after applying patch:
         Overflow issue is resolved.
         No horizontal scrolling during drag.
         Layout remains stable while moving metaboxes.

 Patch applies and fixes the issue as expected in this Windows LocalWP test
 environment.

 Patch tested:[https://patch-diff.githubusercontent.com/raw/WordPress
 /wordpress-develop/pull/11437.diff]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65018#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 07:42:11 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 07:42:11 -0000
Subject: [wp-trac] [WordPress Trac] #65030: Customize: `isLinkPreviewable()`
 regex overrides `customize_allowed_urls` filter for sites with
 `/wp-content/` in home URL
Message-ID: <052.c9ae259fa333dbfc488d81cc1aa9e24e@wordpress.org>

#65030: Customize: `isLinkPreviewable()` regex overrides `customize_allowed_urls`
filter for sites with `/wp-content/` in home URL
--------------------------+-----------------------------
 Reporter:  abhi3315      |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Customize     |    Version:  6.9.4
 Severity:  normal        |   Keywords:
  Focuses:  javascript    |
--------------------------+-----------------------------
 == Summary

 The `customize_allowed_urls` PHP filter allows plugins and themes to
 register additional previewable URLs for the Customizer. However, the
 hardcoded regex in `isLinkPreviewable()` in `customize-preview.js`
 overrides this filter for any URL whose pathname contains `/wp-content/` —
 making the filter incomplete.

 When a URL passes the `settings.url.allowed` check (populated by
 `customize_allowed_urls`), it should be considered previewable. Instead,
 the regex silently rejects it, and there is no JS-side filter or hook to
 override this behavior.

 == Steps to reproduce

 1. Install WordPress in a subdirectory under `wp-content/` (e.g.,
 `example.com/wp-content/subsite/`)
 2. Confirm `home_url('/')` returns the `wp-content` based URL
 3. Log in and open Appearance → Customize
 4. The preview iframe fails to load

 Note: `get_allowed_urls()` includes `home_url('/')` by default, so the
 site's own URL is in the allowed list — yet the Customizer still rejects
 it.

 == Root cause

 In `src/js/_enqueues/wp/customize/preview.js`, the `isLinkPreviewable()`
 function runs two checks in sequence:

 {{{#!js
 // Check 1: URL matches an explicitly allowed URL — PASSES
 matchesAllowedUrl = ! _.isUndefined( _.find( api.settings.url.allowed,
 function( allowedUrl ) {
     parsedAllowedUrl.href = allowedUrl;
     return parsedAllowedUrl.protocol === element.protocol
         && parsedAllowedUrl.host === element.host
         && 0 === element.pathname.indexOf( parsedAllowedUrl.pathname );
 } ) );
 if ( ! matchesAllowedUrl ) {
     return false;
 }

 // Check 2: Hardcoded regex — overrides check 1 for URLs containing /wp-
 content/
 if ( /\/wp-(admin|includes|content)(\/|$)/.test( element.pathname ) ) {
     return false;
 }
 }}}

 Check 2 does not consider whether the URL was already approved by check 1.
 A URL can be explicitly allowed via the PHP filter and still be blocked by
 the JS regex.

 The same issue exists in the `previewUrl` setter in `customize-
 controls.js`.

 == Expected behavior

 URLs that match an entry in `settings.url.allowed` (populated via the
 `customize_allowed_urls` PHP filter) should not be overridden by the
 hardcoded regex. The regex should only apply to URLs that did **not**
 match the allowed list.

 == Proposed fix

 {{{#!js
 // Only apply the regex block for URLs that were NOT explicitly allowed
 if ( ! matchesAllowedUrl && /\/wp-(admin|includes|content)(\/|$)/.test(
 element.pathname ) ) {
     return false;
 }
 }}}

 This is backward-compatible. If no allowed URL contains `/wp-content/`,
 behavior is identical to today. It only changes behavior when the PHP
 filter has explicitly approved a URL that happens to contain `/wp-
 content/` in its path.

 == Related tickets

 - #38409 — Hardened URL matching in `isLinkPreviewable`
 - #31517 — Added non-previewable link notice in Customizer
 - #30937 — Customize changesets, introduced `isLinkPreviewable`

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65030>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 08:01:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 08:01:05 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
Message-ID: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
-------------------------------------+-----------------------------
 Reporter:  piyushpatel123           |      Owner:  (none)
     Type:  defect (bug)             |     Status:  new
 Priority:  normal                   |  Milestone:  Awaiting Review
Component:  Administration           |    Version:  trunk
 Severity:  normal                   |   Keywords:
  Focuses:  ui, css, administration  |
-------------------------------------+-----------------------------
 An alignment issue has been identified with the password dashicon on the
 user edit screen in WordPress 7.0-RC2.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 08:02:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 08:02:23 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.128d316bb7cd39c7b2c253b9018d710f@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
----------------------------+--------------------------------------
 Reporter:  piyushpatel123  |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:  ui, css, administration
----------------------------+--------------------------------------
Changes (by piyushpatel123):

 * Attachment "Screenshot_4.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 08:04:36 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 08:04:36 -0000
Subject: [wp-trac] [WordPress Trac] #64656: Fatal error on new font
 library admin page
In-Reply-To: <051.452a77fdc7ce1f6e32036f66207914fe@wordpress.org>
References: <051.452a77fdc7ce1f6e32036f66207914fe@wordpress.org>
Message-ID: <066.5c6b6216d8d5a48450f9997e9f6b8c2b@wordpress.org>

#64656: Fatal error on new font library admin page
----------------------------+--------------------------
 Reporter:  desrosj         |       Owner:  youknowriad
     Type:  defect (bug)    |      Status:  reopened
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+--------------------------

Comment (by desrosj):

 @pbearne I'm not seeing the issue in my efforts to reproduce. Could you
 check a few things to try and narrow this down:
 - Which commit is your local checkout at?
 - What is the contents of the `gutenberg/.gutenberg-hash` file?
 - In `gutenberg/build/`, does the contents of the `constants.php` file the
 same as what you've shared above?
 - Are you running from `src` or `build`? Can you re-run `npm run
 build:dev` or `npm run build` respectively?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64656#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 08:07:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 08:07:57 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.8a1f8cb00c27040ece717f47c167a080@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
----------------------------+--------------------------------------
 Reporter:  piyushpatel123  |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:  ui, css, administration
----------------------------+--------------------------------------

Comment (by piyushpatel123):

 I was able to identify the issue and found a solution. Removing or
 adjusting the following two CSS lines resolves the problem.

 {{{
 .wp-core-ui .button.wp-hide-pw > .dashicons{
 line-height: 1;
 vertical-align: middle;
 }
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 08:27:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 08:27:53 -0000
Subject: [wp-trac] [WordPress Trac] #65029: Trac Ticket: Keyboard
 Shortcut to Toggle Toolbar on Frontend
In-Reply-To: <050.6dc60cf2bb50968de73232ec75bf728d@wordpress.org>
References: <050.6dc60cf2bb50968de73232ec75bf728d@wordpress.org>
Message-ID: <065.a37d7e55130fac1d96012dd21182b367@wordpress.org>

#65029: Trac Ticket: Keyboard Shortcut to Toggle Toolbar on Frontend
-------------------------+------------------------------
 Reporter:  apermo       |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Toolbar      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:
-------------------------+------------------------------

Comment (by apermo):

 Update: Shortcut changed from access+w to Ctrl+Shift+F

 After further analysis, the initially proposed access+w shortcut
 (Ctrl+Option+W on Mac / Alt+Shift+W on Windows) has been replaced with
 Ctrl+Shift+F — unified across all platforms.

 TL;DR of dead ends:

 - access+w (Ctrl+Option / Alt+Shift): Ctrl+Option on macOS is the default
 modifier for the temporary accessibility Display zoom feature. Which is as
 inconvenience, as there are Developers using the feature to temporarily
 magnify their work. I do, and it's a gem I regularly share.
 - Ctrl+Shift+H ("H for Hide"): Firefox uses Ctrl+Shift+H for the History
 sidebar.
 - primaryShift+\ (reuse Gutenberg's distraction-free shortcut): \ is not
 directly accessible on non-US keyboard layouts — e.g. on German keyboards
 it requires Alt+Shift+7 on Mac or AltGr+ß on Windows, making the combo
 effectively unusable.

 Why Ctrl+Shift+F:

 - Free across all major browsers (Chrome, Firefox, Safari, Edge) on all
 platforms
 - Works on every keyboard layout (letter key, no special characters)
 - Follows the ctrlShift modifier pattern already established in WordPress
 for region navigation (`Ctrl+Shift+``)
 - Same physical keys on Mac, Windows, and Linux — no per-platform
 branching
 - "F" for "Frontend view" as mnemonic
 - Ergonomic single hand use for quick access

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65029#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 08:32:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 08:32:56 -0000
Subject: [wp-trac] [WordPress Trac] #65028: no error message when
 installing connector if File system read only
In-Reply-To: <051.dba1e5b249ba8e02e154d12428f5633b@wordpress.org>
References: <051.dba1e5b249ba8e02e154d12428f5633b@wordpress.org>
Message-ID: <066.fd097a90c385d7634cfcf56db047485f@wordpress.org>

#65028: no error message when installing connector if File system read only
--------------------------+--------------------------------
 Reporter:  pbearne       |       Owner:  (none)
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  AI            |     Version:  trunk
 Severity:  normal        |  Resolution:  reported-upstream
 Keywords:  needs-patch   |     Focuses:
--------------------------+--------------------------------
Changes (by wildworks):

 * status:  new => closed
 * resolution:   => reported-upstream
 * milestone:  7.0 =>


Comment:

 Thanks for the report. I think this problem should be fixed on the client-
 side.

 Let's close this ticket in favor of
 https://github.com/WordPress/gutenberg/issues/77089.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65028#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 08:37:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 08:37:09 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.fb07e4bbd61011e41507297cdcdc848b@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
----------------------------+--------------------------------------
 Reporter:  piyushpatel123  |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:  ui, css, administration
----------------------------+--------------------------------------
Changes (by rajdiptank111):

 * Attachment "65031.patch" added.

 Upload patch

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 08:51:47 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 08:51:47 -0000
Subject: [wp-trac] [WordPress Trac] #65014: Site Health: Error icon
 missing due to missing dashicons class
In-Reply-To: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
References: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
Message-ID: <069.b1edfffb4da3bb852134484b1dbf3ed4@wordpress.org>

#65014: Site Health: Error icon missing due to missing dashicons class
-------------------------------------+-------------------------------------
 Reporter:  valani9099               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  7.1
Component:  Site Health              |     Version:  5.3
 Severity:  normal                   |  Resolution:
 Keywords:  has-screenshots has-     |     Focuses:  ui, css,
  patch                              |  administration
-------------------------------------+-------------------------------------

Comment (by wildworks):

 @valani9099 Thanks for the update.

 P.S. If you have already submitted a pull request, you do not need to
 submit a separate patch.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65014#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 09:15:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 09:15:48 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.bfe1038a01ac1ebcbc0809f7cd600768@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
------------------------------+-------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  jorgefilipecosta
     Type:  feature request   |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  Plugins           |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+-------------------------------

Comment (by matveb):

 I'm a bit confused about the outcome. I agree, at this late stage, the
 connector should not show up when the plugin is not present in the WP
 install, but it should be displayed when it is, even if it's not
 activated.

 It’s important to position connectors as not being exclusively for AI.
 Looking beyond, the connectors UI should show available connectors from
 any installed plugin, regardless of whether they are activated. Given
 Akismet is bundled by default, it should show up if the file is present
 for 7.0. It'd be odd to have the plugin present in plugins but not in
 connectors. For the next cycle, this should be formalized in plugin
 headers or some other broader mechanism.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:41>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 09:44:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 09:44:55 -0000
Subject: [wp-trac] [WordPress Trac] #50699: Fix and improve arranging
 metaboxes
In-Reply-To: <050.688ed7764ed7452dc1ee2d128b41a286@wordpress.org>
References: <050.688ed7764ed7452dc1ee2d128b41a286@wordpress.org>
Message-ID: <065.a8b474783f3d334c79776ff773fd2a1d@wordpress.org>

#50699: Fix and improve arranging metaboxes
--------------------------------------+--------------------------------
 Reporter:  azaozz                    |       Owner:  joedolson
     Type:  enhancement               |      Status:  accepted
 Priority:  normal                    |   Milestone:  Future Release
Component:  Administration            |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  needs-design needs-patch  |     Focuses:  ui, accessibility
--------------------------------------+--------------------------------

Comment (by sanket.parmar):

 After going through the full thread, the direction that azaozz and
 joedolson landed on in the Jan 2021 discussion still seems right: a Screen
 Options toggle to enable/disable drag-and-drop reordering, defaulting to
 enabled so existing workflows aren't disrupted.

 The sticking point since then has been `needs-design`. From what I can
 tell, the open questions are:

  1. '''Checkbox label wording.''' "Enable drag-and-drop reordering" is
 explicit. "Allow reordering of boxes" would echo the existing "Enable
 accessibility mode" phrasing already in Screen Options — which might feel
 more consistent.
  2. '''Placement in the Screen Options panel.''' It would sit naturally
 alongside the column count and accessibility mode fields.
  3. '''Touch device default.''' Should the toggle default to off on
 touch/mobile? This was raised but never settled.

 On the implementation side, the scope is fairly contained: gate the
 `.sortable()` initialization in `postbox.js` on a setting passed from PHP,
 store the preference as a user option per screen (same pattern as
 `screen_layout_{page}`), and render the new checkbox in
 `render_screen_options()` in `class-wp-screen.php`. The keyboard up/down
 buttons would stay unaffected regardless of the toggle state.

 If there's some agreement on the design questions, I'd be happy to put
 together a patch. Happy to hear thoughts before going further.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/50699#comment:66>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 09:45:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 09:45:33 -0000
Subject: [wp-trac] [WordPress Trac] #64771: Existing block level custom
 CSS in a post breaks when the post is edited by user without
 unfiltered_html
In-Reply-To: <056.6cde4cb4d3674a3ab453a19d1888b21e@wordpress.org>
References: <056.6cde4cb4d3674a3ab453a19d1888b21e@wordpress.org>
Message-ID: <071.26ad53ba59533e56d03f932f8aec2b86@wordpress.org>

#64771: Existing block level custom CSS in a post breaks when the post is edited by
user without unfiltered_html
--------------------------------------------------+---------------------
 Reporter:  glendaviesnz                          |       Owner:  (none)
     Type:  defect (bug)                          |      Status:  new
 Priority:  high                                  |   Milestone:  7.0
Component:  Editor                                |     Version:  trunk
 Severity:  critical                              |  Resolution:
 Keywords:  has-patch has-unit-tests 2nd-opinion  |     Focuses:
--------------------------------------------------+---------------------

Comment (by jonsurrell):

 The [#comment:47 recent] [#comment:48 assessments] seem correct to me.

 > 1. Revert the whole block level css feature and punt it to 7.1
 > 2. Find a solution for the issue on this feature during the small amount
 of time we have until 7.0 is released
 > 3. Show a simple warning notice and punt a more complete solution to 7.1

 [https://core.trac.wordpress.org/ticket/64771#comment:42 I advocate 3.]

 2 seems too complex and risky for this point in the in the release cycle.
 I discourage it.

 If folks are not happy with the proposed compromise (option 3), I
 recommend a the revert (option 1).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64771#comment:49>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 10:04:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 10:04:44 -0000
Subject: [wp-trac] [WordPress Trac] #65026: Hide plugin search form on
 Favorites tab
In-Reply-To: <048.5df104f8236536e341a0c31918d9a06c@wordpress.org>
References: <048.5df104f8236536e341a0c31918d9a06c@wordpress.org>
Message-ID: <063.6eb26061d7fcbeb41f9849dd3d3e4c0f@wordpress.org>

#65026: Hide plugin search form on Favorites tab
--------------------------+------------------------------
 Reporter:  bor0          |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Plugins       |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  ui
--------------------------+------------------------------

Comment (by bor0):

 cc @SergeyBiryukov would also be great to get your opinion on it

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65026#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 10:09:36 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 10:09:36 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.309dc85874609ed21369fe067517f79d@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
--------------------------------------+-------------------------------
 Reporter:  jorgefilipecosta          |       Owner:  jorgefilipecosta
     Type:  feature request           |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.0
Component:  Plugins                   |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------------

Comment (by desrosj):

 Historically, plugins have largely referred to these "connection details"
 as "API keys".

 One thing I am still not clear on is what the benefit is of renaming this
 to "connectors" when a plugin requires a simple set of API credentials or
 a key.

 Using connectors for AI-related tools makes sense because it is a new
 concept. But there is a long-standing word association that users will
 have to be retrained on by renaming this.

 @matveb past listing AI connectors and plugin API keys in one location
 (which I fully agree with), are you able to help clarify what the benefits
 are of calling the same thing instead of having two types?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:43>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 10:14:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 10:14:09 -0000
Subject: [wp-trac] [WordPress Trac] #65030: Customize:
 `isLinkPreviewable()` regex overrides `customize_allowed_urls` filter for
 sites with `/wp-content/` in home URL
In-Reply-To: <052.c9ae259fa333dbfc488d81cc1aa9e24e@wordpress.org>
References: <052.c9ae259fa333dbfc488d81cc1aa9e24e@wordpress.org>
Message-ID: <067.a6e95f06ac542c90177f9ce972bb9ea2@wordpress.org>

#65030: Customize: `isLinkPreviewable()` regex overrides `customize_allowed_urls`
filter for sites with `/wp-content/` in home URL
--------------------------+------------------------------
 Reporter:  abhi3315      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Customize     |     Version:  6.9.4
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  javascript
--------------------------+------------------------------

Comment (by abhi3315):

 Updated the proposed fix. The original `! matchesAllowedUrl` approach
 wouldn't work because `matchesAllowedUrl` is always true at that point.
 The correct fix captures the matched allowed URL's path prefix and applies
 the regex only to the remainder. See PR: https://github.com/WordPress
 /wordpress-develop/pull/11459

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65030#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 11:28:37 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 11:28:37 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.fa805e9b089cb3f15bf376b33626b774@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
--------------------------------------+-------------------------------
 Reporter:  jorgefilipecosta          |       Owner:  jorgefilipecosta
     Type:  feature request           |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.0
Component:  Plugins                   |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------------

Comment (by jorgefilipecosta):

 Hi @jorbin, thanks for following up on this!

 Replying to [comment:38 jorbin]:
 > Replying to [comment:32 jorgefilipecosta]:
 >
 > > the connector only appear on the UI if Akismet is installed.
 >
 > The current code shows the akismet connector for all users, not just
 those that have Akismet installed. Seeing that there are now six
 committers (seven based off of @matveb's comments) that are supporting the
 revert, that seems like the best immediate path.

 I think there might be a small misunderstanding. As I mentioned in
 https://core.trac.wordpress.org/ticket/65012#comment:32, the connector
 only appears when Akismet is installed. If it helps, you can see this in
 action using [https://playground.wordpress.net/wordpress.html?pr=11460
 Playground] (PR [https://github.com/WordPress/wordpress-develop/pull/11460
 wordpress-develop#11460] is just there to support this Playground demo).

 I also recorded a quick video walking through the behavior:
 [https://make.wordpress.org/core/files/2026/04/Akismet-connector.mov
 Akismet-connector.mov]. You can see the connector appearing when Akismet
 is installed and disappearing once it's deleted.

 That said, if you've run into a case where the connector showed up without
 Akismet being installed, that would be really useful to know about. It
 could point to a bug that might also affect third-party connectors, so any
 details about the setup where you saw this would be a big help in tracking
 it down.

 > Seeing that there are now six committers (seven based off of @matveb's
 comments) that are supporting the revert, that seems like the best
 immediate path.

 I interpreted @matveb's comments a bit differently. I took him to be
 saying that Akismet should be shown even when not installed, which is what
 the original commit was doing, in line with what the infrastructure
 supported at the time, rather than supporting a revert.

 Whatever direction we land on next, working through the Akismet
 integration has been a great opportunity to stress-test the connectors
 infrastructure and ship some improvements along the way, like fixes for
 assumptions about constants and settings sharing the same naming, and the
 bug @peterwilsoncc reported at
 [https://github.com/WordPress/gutenberg/issues/76984 gutenberg#76984].
 Really appreciate the suggestions and issues reported.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:44>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 11:43:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 11:43:05 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.4093aa8fb9d9f26ddbae1971c04285e4@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
-------------------------------------+-------------------------------------
 Reporter:  piyushpatel123           |       Owner:  audrasjb
     Type:  defect (bug)             |      Status:  accepted
 Priority:  normal                   |   Milestone:  7.0
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  needs-testing has-patch  |     Focuses:  ui, css,
  admin-reskin                       |  administration
-------------------------------------+-------------------------------------
Changes (by audrasjb):

 * keywords:   => needs-testing has-patch admin-reskin
 * owner:  (none) => audrasjb
 * status:  new => accepted
 * milestone:  Awaiting Review => 7.0


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 11:55:24 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 11:55:24 -0000
Subject: [wp-trac] [WordPress Trac] #65022: Posts list: replace (no
 title) filler when a title isn't set with something more useful.
In-Reply-To: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
References: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
Message-ID: <067.ada21c9486776dee7742cad158bbbb9d@wordpress.org>

#65022: Posts list: replace (no title) filler when a title isn't set with something
more useful.
-------------------------------+-----------------------------
 Reporter:  annezazu           |       Owner:  SergeyBiryukov
     Type:  enhancement        |      Status:  accepted
 Priority:  normal             |   Milestone:  7.1
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:  administration
-------------------------------+-----------------------------

Comment (by Joen):

 > I'd prefer the (no title) first then the first sentence as shown above.
 To me, without it, it becomes harder to skim which posts don't have
 titles.

 That works for me, and then we wouldn't need any italicising.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65022#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 12:00:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 12:00:07 -0000
Subject: [wp-trac] [WordPress Trac] #65032: View transition admin bar quirks
Message-ID: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>

#65032: View transition admin bar quirks
-------------------------------+-----------------------------
 Reporter:  zieladam           |      Owner:  (none)
     Type:  defect (bug)       |     Status:  new
 Priority:  normal             |  Milestone:  Awaiting Review
Component:  Administration     |    Version:
 Severity:  normal             |   Keywords:
  Focuses:  ui, accessibility  |
-------------------------------+-----------------------------
 Since 7.0 enabled view transitions in wp-admin (#64470, [10699]),
 navigating between admin screens crossfades the entire admin sidebar
 into itself, even when its markup is identical between the two pages.

 `src/wp-admin/css/view-transitions.css` gives each top-level menu item
 a stable `view-transition-name`, but `#adminmenu` itself does not — so
 the whole sidebar falls into the default root snapshot and crossfades
 on every navigation.

 Screencast: https://github.com/user-attachments/assets/7a48ae52-70d7-47ee-
 95e0-aec80463dcde

 == Steps to reproduce ==

 1. Run trunk in Chrome.
 2. Log in to wp-admin.
 3. Click between two screens whose sidebars are nearly identical (e.g.
 Dashboard → Posts → Pages).

 == Expected ==

 Sidebar stays visually stable across the navigation — nothing in it has
 changed.

 == Actual ==

 The whole sidebar crossfades between two identical snapshots.

 == Notes ==

 Claude claims a likely fix is to give `#adminmenu` (and possibly
 `#adminmenuwrap`)
 its own `view-transition-name` so it's treated as a single persistent
 element
 across navigations rather than part of the default root snapshot. To be
 verified.

 cc @westonruter @annezazu

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65032>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 12:00:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 12:00:49 -0000
Subject: [wp-trac] [WordPress Trac] #65032: View transition admin bar
 quirks
In-Reply-To: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
References: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
Message-ID: <067.cb8ebcfbf671aafad202fc01084aa591@wordpress.org>

#65032: View transition admin bar quirks
----------------------------+--------------------------------
 Reporter:  zieladam        |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:  ui, accessibility
----------------------------+--------------------------------
Description changed by zieladam:

Old description:

> Since 7.0 enabled view transitions in wp-admin (#64470, [10699]),
> navigating between admin screens crossfades the entire admin sidebar
> into itself, even when its markup is identical between the two pages.
>
> `src/wp-admin/css/view-transitions.css` gives each top-level menu item
> a stable `view-transition-name`, but `#adminmenu` itself does not — so
> the whole sidebar falls into the default root snapshot and crossfades
> on every navigation.
>
> Screencast: https://github.com/user-attachments/assets/7a48ae52-70d7
> -47ee-95e0-aec80463dcde
>
> == Steps to reproduce ==
>
> 1. Run trunk in Chrome.
> 2. Log in to wp-admin.
> 3. Click between two screens whose sidebars are nearly identical (e.g.
> Dashboard → Posts → Pages).
>
> == Expected ==
>
> Sidebar stays visually stable across the navigation — nothing in it has
> changed.
>
> == Actual ==
>
> The whole sidebar crossfades between two identical snapshots.
>
> == Notes ==
>
> Claude claims a likely fix is to give `#adminmenu` (and possibly
> `#adminmenuwrap`)
> its own `view-transition-name` so it's treated as a single persistent
> element
> across navigations rather than part of the default root snapshot. To be
> verified.
>
> cc @westonruter @annezazu

New description:

 Since 7.0 enabled view transitions in wp-admin (#64470, [10699]),
 navigating between admin screens crossfades the entire admin sidebar into
 itself, even when its markup is identical between the two pages.

 `src/wp-admin/css/view-transitions.css` gives each top-level menu item a
 stable `view-transition-name`, but `#adminmenu` itself does not — so the
 whole sidebar falls into the default root snapshot and crossfades on every
 navigation.

 Screencast: https://github.com/user-attachments/assets/7a48ae52-70d7-47ee-
 95e0-aec80463dcde

 **Steps to reproduce**

 1. Run trunk in Chrome.
 2. Log in to wp-admin.
 3. Click between two screens whose sidebars are nearly identical (e.g.
 Dashboard → Posts → Pages).

 **Expected**

 Sidebar stays visually stable across the navigation — nothing in it has
 changed.

 **Actual**

 The whole sidebar crossfades between two identical snapshots.

 == Notes ==

 Claude claims a likely fix is to give `#adminmenu` (and possibly
 `#adminmenuwrap`)
 its own `view-transition-name` so it's treated as a single persistent
 element
 across navigations rather than part of the default root snapshot. To be
 verified.

 cc @westonruter @annezazu

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65032#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 12:01:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 12:01:28 -0000
Subject: [wp-trac] [WordPress Trac] #65032: View transition admin bar
 quirks
In-Reply-To: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
References: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
Message-ID: <067.149ceceecfb7169c17bf6c941544fcef@wordpress.org>

#65032: View transition admin bar quirks
----------------------------+--------------------------------
 Reporter:  zieladam        |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:  ui, accessibility
----------------------------+--------------------------------
Description changed by zieladam:

Old description:

> Since 7.0 enabled view transitions in wp-admin (#64470, [10699]),
> navigating between admin screens crossfades the entire admin sidebar into
> itself, even when its markup is identical between the two pages.
>
> `src/wp-admin/css/view-transitions.css` gives each top-level menu item a
> stable `view-transition-name`, but `#adminmenu` itself does not — so the
> whole sidebar falls into the default root snapshot and crossfades on
> every navigation.
>
> Screencast: https://github.com/user-attachments/assets/7a48ae52-70d7
> -47ee-95e0-aec80463dcde
>
> **Steps to reproduce**
>
> 1. Run trunk in Chrome.
> 2. Log in to wp-admin.
> 3. Click between two screens whose sidebars are nearly identical (e.g.
> Dashboard → Posts → Pages).
>
> **Expected**
>
> Sidebar stays visually stable across the navigation — nothing in it has
> changed.
>
> **Actual**
>
> The whole sidebar crossfades between two identical snapshots.
>
> == Notes ==
>
> Claude claims a likely fix is to give `#adminmenu` (and possibly
> `#adminmenuwrap`)
> its own `view-transition-name` so it's treated as a single persistent
> element
> across navigations rather than part of the default root snapshot. To be
> verified.
>
> cc @westonruter @annezazu

New description:

 Since 7.0 enabled view transitions in wp-admin (#64470, [10699]),
 navigating between admin screens crossfades the entire admin sidebar into
 itself, even when its markup is nearly identical between the two pages.

 Screencast: https://github.com/user-attachments/assets/7a48ae52-70d7-47ee-
 95e0-aec80463dcde

 **Steps to reproduce**

 1. Run trunk in Chrome.
 2. Log in to wp-admin.
 3. Click between two screens whose sidebars are nearly identical (e.g.
 Dashboard → Posts → Pages).

 **Expected**

 Sidebar stays visually stable across the navigation — nothing in it has
 changed.

 **Actual**

 The whole sidebar crossfades between two identical snapshots.

 == Notes ==

 Claude claims, to be verified:

 * `src/wp-admin/css/view-transitions.css` gives each top-level menu item a
 stable `view-transition-name`, but `#adminmenu` itself does not — so the
 whole sidebar falls into the default root snapshot and crossfades on every
 navigation.
 * a likely fix is to give `#adminmenu` (and possibly `#adminmenuwrap`)
 its own `view-transition-name` so it's treated as a single persistent
 element
 across navigations rather than part of the default root snapshot.

 cc @westonruter @annezazu

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65032#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 12:31:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 12:31:31 -0000
Subject: [wp-trac] [WordPress Trac] #64926: REST API: GET requests fail
 object/array schema validation when params are JSON-serialized strings
In-Reply-To: <048.09e4f6945084c0394353ff269647c101@wordpress.org>
References: <048.09e4f6945084c0394353ff269647c101@wordpress.org>
Message-ID: <063.14e924ba134d5c5ac7e82a5eed7248a7@wordpress.org>

#64926: REST API: GET requests fail object/array schema validation when params are
JSON-serialized strings
-------------------------+-------------------------------------------------
 Reporter:  dsmy         |       Owner:  (none)
     Type:  defect       |      Status:  new
  (bug)                  |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  REST API     |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  javascript, rest-api, php-
                         |  compatibility
-------------------------+-------------------------------------------------

Comment (by westonruter):

 Something that just came to mind: the abilities in the Abilities API can
 be exposed in the REST API. When an ability is read-only, then a `GET`
 request is made. Nevertheless, the `input_schema` may involve an object of
 properties.

 Consider this Abilities API code:

 {{{#!php
 <?php
 add_action(
         'wp_abilities_api_init',
         static function () {
                 wp_register_ability(
                         'abilities-experiment/get-post',
                         array(
                                 'label'               => __( 'Get Post',
 'abilities-experiment' ),
                                 'description'         => __( 'Gets fields
 for a post', 'abilities-experiment' ),
                                 'category'            => 'site',
                                 'input_schema'        => array(
                                         'type'                 =>
 'object',
                                         'required'             => array(
 'post' ),
                                         'properties'           => array(
                                                 'post' => array(
                                                         'type' =>
 'object',
                                                         'required' =>
 array( 'id' ),
                                                         'properties' =>
 array(
                                                                 'id' =>
 array(
 'type'        => 'integer',
 'description' => __( 'The ID of the post to get.', 'abilities-experiment'
 ),
 'minimum'     => 1,
                                                                 ),
                                                         )
                                                 ),
                                                 'fields' => array(
                                                         'type' => 'array',
                                                         'items' => array(
                                                                 'type' =>
 'string',
                                                         ),
                                                 )
                                         ),
                                 ),
                                 'output_schema'       => array(
                                         'type'                 =>
 'object',
                                 ),
                                 'execute_callback'    => static function (
 array $input ): array|WP_Error {
                                         $post = get_post(
 $input['post']['id'] );
                                         if ( ! $post ) {
                                                 return new WP_Error(
 'post_not_found', __( 'Post not found.', 'abilities-experiment' ), array(
 'status' => 404 ) );
                                         }
                                         $data = $post->to_array();
                                         if ( $input['fields'] ) {
                                                 $data =
 wp_array_slice_assoc( $data, $input['fields'] );
                                         }
                                         return $data;
                                 },
                                 'permission_callback' => static function (
 array $input ): bool {
                                         return current_user_can(
 'edit_posts', $input['post']['id'] );
                                 },
                                 'meta'                => array(
                                         'annotations'  => array(
                                                 'readonly'    => true,
                                                 'destructive' => false,
                                                 'idempotent'  => false,
                                         ),
                                         'show_in_rest' => true,
                                 ),
                         )
                 );
         }
 );
 }}}

 Using the Abilities API client module as follows:

 {{{#!js
 (await import("@wordpress/abilities")).executeAbility(
   "abilities-experiment/get-post",
   { post: { id: 1 }, fields: ["post_content", "post_author"] },
 );
 }}}

 This results in an HTTP request being made to the REST API as follows:

 `/wp-json/wp-abilities/v1/abilities/abilities-experiment/get-
 post/run?input%5Bpost%5D%5Bid%5D=1&input%5Bfields%5D%5B0%5D=post_content&input%5Bfields%5D%5B1%5D=post_author&_locale=user`

 With the brackets decoded:

 `/wp-json/wp-abilities/v1/abilities/abilities-experiment/get-
 post/run?input[post][id]=1&input[fields][0]=post_content&input[fields][1]=post_author&_locale=user`

 So, note that `@wordpress/abilities` (er, `@wordpress/core-abilities`) is
 already handling this correctly, converting a nested object into a list of
 URL query params.

 See
 [https://github.com/WordPress/gutenberg/blob/6ea168835304764d253d169906148cf5fe6269d9/packages
 /core-abilities/src/index.ts#L27-L71 logic] in `createServerCallback()`:

 {{{
 // For GET and DELETE requests, pass the input as query parameters.
 path = addQueryArgs( path, { input } );
 }}}

 This `addQueryArgs()` function is part of the `@wordpress/url` package:
 https://developer.wordpress.org/block-editor/reference-guides/packages
 /packages-url/#addqueryargs

 So you can use that instead of the `qs` package.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64926#comment:25>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 12:50:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 12:50:14 -0000
Subject: [wp-trac] [WordPress Trac] #65033: Suggestion for commenting the
 format of DB_HOST in wp-config-sample.php
Message-ID: <052.9ae18080fb29b8e7d5d99df8ab0c3f15@wordpress.org>

#65033: Suggestion for commenting the format of DB_HOST in wp-config-sample.php
-------------------------+-----------------------------
 Reporter:  ralatalo     |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  General      |    Version:  6.9.4
 Severity:  normal       |   Keywords:
  Focuses:               |
-------------------------+-----------------------------
 in wp-config-sample.php the entry for DB_HOST is simply:

 /** Database hostname */
 define( ‘DB_HOST’, ‘localhost’ );

 I would suggest adding something similar to the following comment:
 /** the format for DB_HOST can also contain either a port or socket or
 both **/
 /** the format for both is: ‘{hostname}:{port}:/path/to/socket’ **/

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65033>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 12:52:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 12:52:31 -0000
Subject: [wp-trac] [WordPress Trac] #65033: Suggestion for commenting
 the format of DB_HOST in wp-config-sample.php
In-Reply-To: <052.9ae18080fb29b8e7d5d99df8ab0c3f15@wordpress.org>
References: <052.9ae18080fb29b8e7d5d99df8ab0c3f15@wordpress.org>
Message-ID: <067.06c644ba9dafdca19db6c379a6cec9ce@wordpress.org>

#65033: Suggestion for commenting the format of DB_HOST in wp-config-sample.php
-------------------------+------------------------------
 Reporter:  ralatalo     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:  6.9.4
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+------------------------------

Comment (by ralatalo):

 This could help save time for the next person, I hacked though the source
 code (not hard with php) to see how it was being processed since all I
 found were references on other sites that you could use port or socket
 (nothing else mentioned both)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65033#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 13:03:43 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 13:03:43 -0000
Subject: [wp-trac] [WordPress Trac] #65032: View transition admin bar
 quirks
In-Reply-To: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
References: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
Message-ID: <067.f073283e9eea575d7ef943b86cb21547@wordpress.org>

#65032: View transition admin bar quirks
----------------------------+--------------------------------
 Reporter:  zieladam        |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:  ui, accessibility
----------------------------+--------------------------------

Comment (by mukesh27):

 > Screencast: https://github.com/user-attachments/assets/7a48ae52-70d7
 -47ee-95e0-aec80463dcde

 Not working. Update the URL please

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65032#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 13:07:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 13:07:49 -0000
Subject: [wp-trac] [WordPress Trac] #65032: View transition admin bar
 quirks
In-Reply-To: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
References: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
Message-ID: <067.af17963761921df7ae75e6045d1b6316@wordpress.org>

#65032: View transition admin bar quirks
----------------------------+--------------------------------
 Reporter:  zieladam        |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:  ui, accessibility
----------------------------+--------------------------------
Changes (by audrasjb):

 * version:   => trunk
 * milestone:  Awaiting Review => 7.0


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65032#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 13:11:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 13:11:05 -0000
Subject: [wp-trac] [WordPress Trac] #64656: Fatal error on new font
 library admin page
In-Reply-To: <051.452a77fdc7ce1f6e32036f66207914fe@wordpress.org>
References: <051.452a77fdc7ce1f6e32036f66207914fe@wordpress.org>
Message-ID: <066.583df9cef777ff149022a9a6c19845e2@wordpress.org>

#64656: Fatal error on new font library admin page
----------------------------+--------------------------
 Reporter:  desrosj         |       Owner:  youknowriad
     Type:  defect (bug)    |      Status:  reopened
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+--------------------------

Comment (by pbearne):

 Refreshed yesterday to Revision:b8729ff6 sha-
 b8729ff639a4b49ec4b6fd4b16700cd25ef95f1e
 I don't have a hash file (see image)
 [[Image(https://drive.google.com/file/d/1X9wd7mJc5F7DnR425LVmlOXgeGxgKU8b/view?usp=sharing)]]
 yes see Image
 I'm running src

 I am using the WP Docker as per the readme.md

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64656#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 13:19:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 13:19:16 -0000
Subject: [wp-trac] [WordPress Trac] #65034: More help for trouble shooting
 initial Database problems
Message-ID: <052.fd5374c925a8fa0b4c57feefe9c3e3fb@wordpress.org>

#65034: More help for trouble shooting initial Database problems
-------------------------+-----------------------------
 Reporter:  ralatalo     |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  General      |    Version:  6.9.4
 Severity:  normal       |   Keywords:
  Focuses:               |
-------------------------+-----------------------------
 Once you have enabled debugging in wp-config.php you get more information
 about database connection failure but maybe I missed a toggle because I
 didn't get a 'good' error message till I though together my own small PHP
 script which included:
 if (mysqli_connect_errno()) {
     printf("Connect failed: %s\n", mysqli_connect_error());
     exit();
 }

 Where I finally got: mysqli_real_connect(): (HY000/2002): Permission
 denied

 My Suggestion would be to Increase the diagnostic output once debugging is
 enabled, in particularly, to include something like:

 The connection request below processed your configuration data as follows:
 mysqli_real_connect( {DBhandle} , host, dbuser, dbpassword, database,
 port, socket, client_flags );
 as host=’xxx’, dbuser=’xxxx’, dbpassword=’xxxxx’, database=’xxxxx’ ,
 port=’xxxx’ , socket=’xxxxx’

 And something showing the reported error:
 Currently you show something like:

 This either means that the username and password information in your %1$s
 file is incorrect or that contact with the database server at %2$s could
 not be established. This could mean your host&#8217;s database server is
 down.'

 Then ask them if they are sure that they have the correct username and
 password, and correct hostname and if the database is running.  Which I
 honestly found a little frustrating as I was alternating between hacking
 class-wpdb.php to figure out how you processed my entries and logging into
 mariadb directly using those same options.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65034>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 13:19:58 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 13:19:58 -0000
Subject: [wp-trac] [WordPress Trac] #65032: View transition admin bar
 quirks
In-Reply-To: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
References: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
Message-ID: <067.606ce4bbdd6ef4ba77a04e6366c2ebdd@wordpress.org>

#65032: View transition admin bar quirks
----------------------------+--------------------------------
 Reporter:  zieladam        |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:  ui, accessibility
----------------------------+--------------------------------

Comment (by westonruter):

 Replying to [ticket:65032 zieladam]:
 > Screencast: https://github.com/user-attachments/assets/7a48ae52-70d7
 -47ee-95e0-aec80463dcde

 This is a 404. Can you upload here?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65032#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 13:22:52 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 13:22:52 -0000
Subject: [wp-trac] [WordPress Trac] #65035: Abilities: Strip internal schema
 keywords from abilities REST responses
Message-ID: <060.11365645bf003f62fe2c244d23d3172e@wordpress.org>

#65035: Abilities: Strip internal schema keywords from abilities REST responses
------------------------------+--------------------------------------
 Reporter:  jorgefilipecosta  |      Owner:  (none)
     Type:  defect (bug)      |     Status:  new
 Priority:  normal            |  Milestone:  7.0
Component:  AI                |    Version:
 Severity:  normal            |   Keywords:  has-patch has-unit-tests
  Focuses:                    |
------------------------------+--------------------------------------
 The Abilities REST API endpoint ({{{/wp/v2/abilities}}}) returns
 {{{input_schema}}} and {{{output_schema}}} that may contain WordPress-
 internal properties like {{{sanitize_callback}}}, {{{validate_callback}}},
 and {{{arg_options}}}. These are not valid JSON Schema keywords and cause
 client-side JSON Schema validators to reject the schemas.

 For example, a plugin registering an ability with {{{register_ability()}}}
 that includes {{{sanitize_callback}}} or {{{arg_options}}} in its schema
 arguments will surface those internal keywords in the REST response.
 Clients consuming the API (such as Gutenberg's AI tools integration)
 cannot validate these schemas without error.

 == Proposed Fix ==

 Add a recursive {{{strip_internal_schema_keywords()}}} method to
 {{{WP_REST_Abilities_V1_List_Controller}}} that removes the three internal
 keywords from schemas before they appear in REST responses.

 The method uses a '''denylist''' approach ({{{array_diff_key()}}} against
 a class constant {{{INTERNAL_SCHEMA_KEYWORDS}}}) rather than the
 '''allowlist''' approach ({{{rest_get_allowed_schema_keywords()}}} +
 {{{array_intersect_key()}}}) used in
 {{{WP_REST_Server::get_data_for_route()}}}. The denylist is the correct
 choice here because {{{rest_get_allowed_schema_keywords()}}} is missing
 valid JSON Schema keywords ({{{allOf}}}, {{{not}}}, {{{definitions}}},
 {{{dependencies}}}, {{{additionalItems}}}) that would be silently stripped
 with the allowlist approach.

 The recursive method traverses all JSON Schema sub-schema locations:
  * {{{properties}}}, {{{patternProperties}}}, {{{definitions}}},
 {{{dependencies}}} (map-of-schemas)
  * {{{not}}}, {{{additionalProperties}}}, {{{additionalItems}}} (single
 sub-schema)
  * {{{items}}} (single schema or tuple array)
  * {{{anyOf}}}, {{{oneOf}}}, {{{allOf}}} (array-of-schemas)

 Property-dependency arrays (numeric arrays in {{{dependencies}}}) are
 correctly skipped.

 The stripping is applied to both {{{input_schema}}} and
 {{{output_schema}}} in {{{prepare_item_for_response()}}}.

 == Test Coverage ==

  * Verifies internal keywords are stripped from top-level and nested
 properties in both {{{input_schema}}} and {{{output_schema}}}
  * Verifies internal keywords are stripped from all sub-schema locations
 ({{{anyOf}}}, {{{oneOf}}}, {{{allOf}}}, {{{not}}},
 {{{patternProperties}}}, {{{definitions}}}, {{{dependencies}}},
 {{{additionalProperties}}}, {{{additionalItems}}}, tuple-style
 {{{items}}})
  * Verifies valid JSON Schema keywords are preserved
  * Verifies property-dependency arrays pass through unchanged

 == Related ==

  * PR: [https://github.com/WordPress/wordpress-develop/pull/11451
 wordpress-develop#11451]
  * Broader schema compilation tracking: #64955

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65035>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 13:28:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 13:28:21 -0000
Subject: [wp-trac] [WordPress Trac] #65034: More help for trouble
 shooting initial Database problems
In-Reply-To: <052.fd5374c925a8fa0b4c57feefe9c3e3fb@wordpress.org>
References: <052.fd5374c925a8fa0b4c57feefe9c3e3fb@wordpress.org>
Message-ID: <067.4414867151d722ac28e4bcb42e70039b@wordpress.org>

#65034: More help for trouble shooting initial Database problems
-------------------------+------------------------------
 Reporter:  ralatalo     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:  6.9.4
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+------------------------------

Comment (by ralatalo):

 Note 1): I also filed Enhancement Request #65033 for adding a comment to
 wp-config-sample.php
 for the format for DB_HOST which is what lead me to suspect I might have
 had some incorrect comment.
 Note 2) Once I got my error message I was able too
 find:https://wordpress.org/support/topic/first-time-install-issue-error-
 hy000-2002/   which let me to SELinux Policies and a solution.

 This Enhancement request is to assist in reducing the time others spend
 troubleshooting a similar issue.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65034#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 13:36:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 13:36:48 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.a18d2efd7a2be7f0470db7b2924f01b4@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
-------------------------------------+-------------------------------------
 Reporter:  piyushpatel123           |       Owner:  audrasjb
     Type:  defect (bug)             |      Status:  accepted
 Priority:  normal                   |   Milestone:  7.0
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  needs-testing has-patch  |     Focuses:  ui, css,
  admin-reskin                       |  administration
-------------------------------------+-------------------------------------

Comment (by ankitkumarshah):

 Hi @rajdiptank111,

 I tried applying your patch, but unfortunately ran into an error while
 doing so (screenshot attached):
 [[Image(https://i.postimg.cc/4dFk3k0N/Screenshot-2026-04-07-at-6-59-10-PM.png)]]

 I also attempted to apply the changes manually, but noticed a
 regression—specifically, the patch seems to introduce a layout issue on
 `/wp-admin/options-writing.php` (screenshot attached for reference):

 [[Image(https://i.postimg.cc/8zH1V3Ny/Screenshot-2026-04-07-at-6-39-04-PM.png)]]

 To address this, I’ve created a PR with a fix:
 https://github.com/WordPress/wordpress-develop/pull/11463

 Could you please test it when you get a chance and let me know if this
 works for you?

 Thank you!

 cc: @audrasjb

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 13:37:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 13:37:22 -0000
Subject: [wp-trac] [WordPress Trac] #65022: Posts list: replace (no
 title) filler when a title isn't set with something more useful.
In-Reply-To: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
References: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
Message-ID: <067.092e2626837561f00ff0ea8b64458627@wordpress.org>

#65022: Posts list: replace (no title) filler when a title isn't set with something
more useful.
-------------------------------+-----------------------------
 Reporter:  annezazu           |       Owner:  SergeyBiryukov
     Type:  enhancement        |      Status:  accepted
 Priority:  normal             |   Milestone:  7.1
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:  administration
-------------------------------+-----------------------------

Comment (by mindctrl):

 Related to previous ticket regarding titles:
 https://core.trac.wordpress.org/ticket/45516

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65022#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 13:39:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 13:39:23 -0000
Subject: [wp-trac] [WordPress Trac] #65036: List more helpful suggestions
 than check username and password for database issues
Message-ID: <052.760af5d53bfcccb3cdda842a90001391@wordpress.org>

#65036: List more helpful suggestions than check username and password for database
issues
-------------------------+-----------------------------
 Reporter:  ralatalo     |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  General      |    Version:  6.9.4
 Severity:  normal       |   Keywords:
  Focuses:               |
-------------------------+-----------------------------
 During initial setup, if wordpress can't connect to the database it only
 suggests checking username, password and host and checking if your
 database is running.  I have already filed enhancement request #65034 to
 increase the diagnostics but this request is to add additional
 suggestions:
 Currently you suggest:
 'Are you sure you have the correct username and password?'
 'Are you sure you have typed the correct hostname?'
 'Are you sure the database server is running?'
 I would suggest adding:
 'You may also need to check for possible Firewalls'
 'You may also need to check for possible security restrictions such as
 SELinux'

 Possible a link to a dedicated external page (which can have a more
 detailed check list?)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65036>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 13:39:25 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 13:39:25 -0000
Subject: [wp-trac] [WordPress Trac] #65035: Abilities: Strip internal
 schema keywords from abilities REST responses
In-Reply-To: <060.11365645bf003f62fe2c244d23d3172e@wordpress.org>
References: <060.11365645bf003f62fe2c244d23d3172e@wordpress.org>
Message-ID: <075.193977923743e5e70bee59f3df32efd3@wordpress.org>

#65035: Abilities: Strip internal schema keywords from abilities REST responses
--------------------------------------+---------------------
 Reporter:  jorgefilipecosta          |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  AI                        |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by gziolo):

 Reported by @ocean90 on the dev note:
 https://make.wordpress.org/core/2026/03/24/client-side-abilities-api-in-
 wordpress-7-0/#comment-48604
 Tracked originally in Gutenberg:
 https://github.com/WordPress/ai/issues/346

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65035#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 13:43:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 13:43:53 -0000
Subject: [wp-trac] [WordPress Trac] #65034: More help for trouble
 shooting initial Database problems
In-Reply-To: <052.fd5374c925a8fa0b4c57feefe9c3e3fb@wordpress.org>
References: <052.fd5374c925a8fa0b4c57feefe9c3e3fb@wordpress.org>
Message-ID: <067.daa4f5dd89a539020b7cf6b6fb84a4ee@wordpress.org>

#65034: More help for trouble shooting initial Database problems
-------------------------+------------------------------
 Reporter:  ralatalo     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:  6.9.4
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+------------------------------

Comment (by mindctrl):

 Somewhat related to https://core.trac.wordpress.org/ticket/63678 in that
 it involves improving database error messaging.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65034#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 15:05:25 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 15:05:25 -0000
Subject: [wp-trac] [WordPress Trac] #65029: Add Keyboard Shortcut to
 Hide and Show Toolbar on Frontend (was: Trac Ticket: Keyboard Shortcut to
 Toggle Toolbar on Frontend)
In-Reply-To: <050.6dc60cf2bb50968de73232ec75bf728d@wordpress.org>
References: <050.6dc60cf2bb50968de73232ec75bf728d@wordpress.org>
Message-ID: <065.7cbe909f96b76682d6f2c6682c6073ac@wordpress.org>

#65029: Add Keyboard Shortcut to Hide and Show Toolbar on Frontend
-------------------------+------------------------------
 Reporter:  apermo       |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Toolbar      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  accessibility
-------------------------+------------------------------
Changes (by sabernhardt):

 * focuses:   => accessibility


Old description:

> Add a keyboard shortcut (access+w) to temporarily hide and show the
> toolbar on the frontend. This gives logged-in users a quick way to
> preview their site without the toolbar, without navigating to Profile
> settings or logging out.
>
> Description
>
> When working on a site's frontend, the toolbar covers the top 32px (46px
> on mobile) of the page. Designers, content editors, and developers
> frequently need to see the page without it — for screenshots, visual
> testing, or checking how fixed headers behave. Today the only options
> are:
>
> 1. Uncheck "Show Toolbar when viewing site" in the user profile (requires
> a page reload)
> 2. Use show_admin_bar( false ) in code (requires a code change and
> reload)
> 3. Use browser DevTools to hide the element manually
> 4. Install a plugin (e.g. https://wordpress.org/plugins/apermo-adminbar-
> toggle/)
>
> None of these are fast or convenient for a quick toggle.
>
> Proposed Solution
>
> A keyboard shortcut using the WordPress access modifier pattern:
>
> - Windows/Linux: Alt+Shift+W
> - Mac: Ctrl+Option+W
>
> The "W" key is mnemonic for "WordPress toolbar." This follows the same
> modifier pattern used by all existing WordPress keyboard shortcuts (e.g.
> access+h for help, access+d for strikethrough), ensuring consistency.
>
> Behavior
>
> - Toggle only: The shortcut hides the toolbar; pressing it again brings
> it back.
> - No persistence: The state resets on page navigation. This is
> intentional — the feature is for quick previews, not a permanent setting.
> - Frontend only: The shortcut does not work in wp-admin, where the
> toolbar is part of the fixed layout and is not optional by design (see
> #19685).
> - Smooth animation: The toolbar slides up/down with a 200ms CSS
> transition.
> - Page spacing adjusts: The --wp-admin--admin-bar--height custom property
> is set to 0px when hidden, so scroll-padding-top and the bump margin-top
> adjust automatically. No content jump.
> - Accessible: An aria-live region announces "Toolbar hidden." / "Toolbar
> visible." for screen reader users. The toolbar element gets aria-
> hidden="true" when hidden.
>
> Shortcut Conflict Analysis
>
> The access+w shortcut was chosen after an audit of all existing
> shortcuts:
>
> WordPress: The letter w is completely free in both the classic editor and
> block editor access modifier space. No WordPress core shortcut uses
> access+w.
>
> Browsers: Alt+Shift+W / Ctrl+Option+W has no known conflicts in Chrome,
> Firefox, Safari, or Edge on any platform. (By contrast, access+b — "B for
> Bar" — conflicts with Chrome/Edge's "focus bookmarks bar" on
> Windows/Linux.)
>
> Historical note: WordPress previously used Alt+Shift+W for "Distraction
> Free Writing" mode, which was removed years ago. The association with
> "toggling a UI element for focus" is fitting.
>
> Prior Art
>
> - In 2016 I released a plugin, that never good notable attention with the
> feature https://wordpress.org/plugins/apermo-adminbar/ and
> https://wordpress.org/plugins/apermo-adminbar-toggle/
> - #53184 discusses auto-hiding the toolbar but does not propose a
> keyboard shortcut.
> - No existing Trac ticket specifically requests a keyboard shortcut to
> toggle the toolbar.
>
> Implementation
>
> The patch modifies three files:
>
> 1. src/js/_enqueues/lib/admin-bar.js — Adds a keydown listener for
> access+w (frontend only), a toggleToolbar() function that toggles the wp-
> toolbar-hidden class on <html>, and screen reader announcements via a
> live region.
> 2. src/wp-includes/css/admin-bar.css — Adds the html.wp-toolbar-hidden
> rules: sets --wp-admin--admin-bar--height: 0px, overrides the bump
> margin-top, and uses transform: translateY(-100%) with visibility: hidden
> to slide the bar out.
> 3. src/wp-includes/class-wp-admin-bar.php — Adds wp_localize_script for
> the two screen reader strings (toolbarHidden, toolbarVisible).
>
> Theme Compatibility
>
> Themes that use var(--wp-admin--admin-bar--height) for their toolbar
> offset will adjust automatically. Themes that hardcode a 32px top offset
> based on the .admin-bar body class will not adjust, but this is the same
> limitation that exists when users disable the toolbar via Profile
> settings today.
>
> Themes can also use the html.wp-toolbar-hidden selector to apply custom
> styles when the toolbar is hidden.

New description:

 Add a keyboard shortcut (`access+w`) to temporarily hide and show the
 toolbar on the frontend. This gives logged-in users a quick way to preview
 their site without the toolbar, without navigating to Profile settings or
 logging out.

 ==== Description

 When working on a site's frontend, the toolbar covers the top 32px (46px
 on mobile) of the page. Designers, content editors, and developers
 frequently need to see the page without it — for screenshots, visual
 testing, or checking how fixed headers behave. Today the only options are:

 1. Uncheck "Show Toolbar when viewing site" in the user profile (requires
 a page reload)
 2. Use `show_admin_bar( false )` in code (requires a code change and
 reload)
 3. Use browser DevTools to hide the element manually
 4. Install a plugin (e.g. https://wordpress.org/plugins/apermo-adminbar-
 toggle/)

 None of these are fast or convenient for a quick toggle.

 ==== Proposed Solution

 A keyboard shortcut using the WordPress access modifier pattern:

 - Windows/Linux: `Alt+Shift+W`
 - Mac: `Ctrl+Option+W`

 The "W" key is mnemonic for "WordPress toolbar." This follows the same
 modifier pattern used by all existing WordPress keyboard shortcuts (e.g.
 `access+h` for help, `access+d` for strikethrough), ensuring consistency.

 ===== Behavior

 - Toggle only: The shortcut hides the toolbar; pressing it again brings it
 back.
 - No persistence: The state resets on page navigation. This is intentional
 — the feature is for quick previews, not a permanent setting.
 - Frontend only: The shortcut does not work in `wp-admin`, where the
 toolbar is part of the fixed layout and is not optional by design (see
 #19685).
 - Smooth animation: The toolbar slides up/down with a 200ms CSS
 transition.
 - Page spacing adjusts: The `--wp-admin--admin-bar--height` custom
 property is set to `0px` when hidden, so `scroll-padding-top` and the bump
 `margin-top` adjust automatically. No content jump.
 - Accessible: An `aria-live` region announces "Toolbar hidden." / "Toolbar
 visible." for screen reader users. The toolbar element gets `aria-
 hidden="true"` when hidden.

 ==== Shortcut Conflict Analysis

 The `access+w` shortcut was chosen after an audit of all existing
 shortcuts:

 WordPress: The letter w is completely free in both the classic editor and
 block editor access modifier space. No WordPress core shortcut uses
 `access+w`.

 Browsers: `Alt+Shift+W `/ `Ctrl+Option+W` has no known conflicts in
 Chrome, Firefox, Safari, or Edge on any platform. (By contrast, `access+b`
 — "B for Bar" — conflicts with Chrome/Edge's "focus bookmarks bar" on
 Windows/Linux.)

 Historical note: WordPress previously used `Alt+Shift+W` for "Distraction
 Free Writing" mode, which was removed years ago. The association with
 "toggling a UI element for focus" is fitting.

 ==== Prior Art

 - In 2016 I released a plugin, that never got notable attention with the
 feature https://wordpress.org/plugins/apermo-adminbar/ and
 https://wordpress.org/plugins/apermo-adminbar-toggle/
 - #53184 discusses auto-hiding the toolbar but does not propose a keyboard
 shortcut.
 - No existing Trac ticket specifically requests a keyboard shortcut to
 toggle the toolbar.

 ==== Implementation

 The patch modifies three files:

 1. `src/js/_enqueues/lib/admin-bar.js` — Adds a `keydown` listener for
 `access+w` (frontend only), a `toggleToolbar()` function that toggles the
 `wp-toolbar-hidden` class on `<html>`, and screen reader announcements via
 a live region.
 2. `src/wp-includes/css/admin-bar.css` — Adds the `html.wp-toolbar-hidden`
 rules: sets `--wp-admin--admin-bar--height: 0px`, overrides the bump
 `margin-top`, and uses `transform: translateY(-100%)` with `visibility:
 hidden` to slide the bar out.
 3. `src/wp-includes/class-wp-admin-bar.php` — Adds `wp_localize_script`
 for the two screen reader strings (`toolbarHidden`, `toolbarVisible`).

 ==== Theme Compatibility

 Themes that use `var(--wp-admin--admin-bar--height)` for their toolbar
 offset will adjust automatically. Themes that hardcode a `32px` top offset
 based on the `.admin-bar` body class will not adjust, but this is the same
 limitation that exists when users disable the toolbar via Profile settings
 today.

 Themes can also use the `html.wp-toolbar-hidden` selector to apply custom
 styles when the toolbar is hidden.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65029#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 15:26:08 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 15:26:08 -0000
Subject: [wp-trac] [WordPress Trac] #65007: Contents of some `.min.js`
 files are no longer minified
In-Reply-To: <051.ca77996bd759b0598d7de612a42ec74d@wordpress.org>
References: <051.ca77996bd759b0598d7de612a42ec74d@wordpress.org>
Message-ID: <066.4b410c8bb4f6dd0d9ae3a19b87ea877b@wordpress.org>

#65007: Contents of some `.min.js` files are no longer minified
------------------------------+---------------------
 Reporter:  desrosj           |       Owner:  (none)
     Type:  defect (bug)      |      Status:  new
 Priority:  normal            |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+---------------------
Changes (by ozgursar):

 * Attachment "65007-before.png" added.

 Before applying patch 11418

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65007>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 15:26:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 15:26:23 -0000
Subject: [wp-trac] [WordPress Trac] #65007: Contents of some `.min.js`
 files are no longer minified
In-Reply-To: <051.ca77996bd759b0598d7de612a42ec74d@wordpress.org>
References: <051.ca77996bd759b0598d7de612a42ec74d@wordpress.org>
Message-ID: <066.68e45f537f38e530459a81f21d3b4183@wordpress.org>

#65007: Contents of some `.min.js` files are no longer minified
------------------------------+---------------------
 Reporter:  desrosj           |       Owner:  (none)
     Type:  defect (bug)      |      Status:  new
 Priority:  normal            |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+---------------------
Changes (by ozgursar):

 * Attachment "65007-after.png" added.

 After applying patch 11418

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65007>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 15:36:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 15:36:30 -0000
Subject: [wp-trac] [WordPress Trac] #65007: Contents of some `.min.js`
 files are no longer minified
In-Reply-To: <051.ca77996bd759b0598d7de612a42ec74d@wordpress.org>
References: <051.ca77996bd759b0598d7de612a42ec74d@wordpress.org>
Message-ID: <066.5bffb968910bf572ee4087760e5ce357@wordpress.org>

#65007: Contents of some `.min.js` files are no longer minified
------------------------------+---------------------
 Reporter:  desrosj           |       Owner:  (none)
     Type:  defect (bug)      |      Status:  new
 Priority:  normal            |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+---------------------

Comment (by ozgursar):

 == Patch Testing Report

 Patch Tested: https://github.com/WordPress/wordpress-develop/pull/11418

 === Environment
 - WordPress: 7.1-alpha-20260407.182057
 - PHP: 8.3.30
 - Server: PHP.wasm
 - Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
 - Browser: Opera
 - OS: macOS
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None activated
 - Plugins:
   * Test Reports 1.2.1

 === Steps taken
 1. Run `npm run build` in your WordPress Develop folder cloned from the
 GitHub repo [https://github.com/WordPress/wordpress-develop].
 2. Observe the following files in `wp-includes/js/dist/vendor/` that they
 are not minified.

 - `wp-polyfill-node-contains.min.js`
 - `wp-polyfill-dom-rect.min.js`
 - `regenerator-runtime.min.js`
 - `wp-polyfill-fetch.min.js`

 3. Apply the patch.
 4. Rerun `npm run build`.
 5. Observe the files again and confirm that they are the minified
 versions.
 6. ✅ Patch is solving the problem.

 === Expected result
 - We expect to see the minified versions of the `.min.js` files in the
 `wp-includes/js/dist/vendor/` folder.

 === Screenshots/Screencast with results
 Before
 [[Image(https://core.trac.wordpress.org/raw-
 attachment/ticket/65007/65007-before.png)]]

 After
 [[Image(https://core.trac.wordpress.org/raw-
 attachment/ticket/65007/65007-after.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65007#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 15:45:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 15:45:55 -0000
Subject: [wp-trac] [WordPress Trac] #64762: Frontend admin toolbar not
 using updated admin color scheme
In-Reply-To: <059.0e31afc455ee11847f5a061f732569ee@wordpress.org>
References: <059.0e31afc455ee11847f5a061f732569ee@wordpress.org>
Message-ID: <074.f87c61820e74f2e1d93338ca53bc4eb7@wordpress.org>

#64762: Frontend admin toolbar not using updated admin color scheme
-------------------------------------------------+-------------------------
 Reporter:  huzaifaalmesbah                      |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Toolbar                              |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-screenshots admin-reskin has-    |     Focuses:  ui, css
  patch has-unit-tests                           |
-------------------------------------------------+-------------------------

Comment (by gaisma22):

 == Patch Testing Report
 Patch Tested: https://github.com/WordPress/wordpress-develop/pull/11354

 === Environment
 - WordPress: 7.0-beta6-62085-src
 - PHP: 8.3.30
 - Server: nginx/1.29.7
 - Database: MySQL 8.4.8
 - Browser: Brave
 - OS: Ubuntu 24.04
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None
 - Plugins: None

 === Steps Taken
 1. Went to Users > Profile and set color scheme to Sunrise.
 2. Visited the frontend at localhost.
    **Before patch:** Admin toolbar showed default black colors despite
    Sunrise being selected.
 3. Applied PR #11354 and hard refreshed the frontend.
    **After patch:** Admin toolbar correctly showed Sunrise colors.
 4. Switched color scheme to Ectoplasm and hard refreshed.
    **After patch:** Admin toolbar correctly showed Ectoplasm colors.

 ✅ Patch is solving the problem

 === Expected Result
 The frontend admin toolbar should match the admin color scheme
 selected in the user profile.

 === Additional Notes
 1. Bug confirmed on WordPress 7.0-beta6 - frontend toolbar displayed
    default black colors regardless of the selected admin color scheme.
 2. After applying the patch, the toolbar correctly reflects the
    selected color scheme on the frontend across multiple schemes
    tested (Sunrise and Ectoplasm).

 === Screenshots/Screencast with results
 **Before Patch:**
 [[Image(https://i.ibb.co/wZFyN4ww/before-sunrise.png)]]

 **After Patch:**
 [[Image(https://i.ibb.co/6cDTdJ2X/after-sunrise.png)]]

 [[Image(https://i.ibb.co/C5vKwszr/after-ectoplasm.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64762#comment:43>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 16:00:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 16:00:14 -0000
Subject: [wp-trac] [WordPress Trac] #65005: Next/Previous for datepicker
 needs context
In-Reply-To: <052.e7c5ffd7379c8e33f54d240e729da31e@wordpress.org>
References: <052.e7c5ffd7379c8e33f54d240e729da31e@wordpress.org>
Message-ID: <067.37c9fccb9b87e5365431db8f55da6659@wordpress.org>

#65005: Next/Previous for datepicker needs context
-------------------------------------------------+-------------------------
 Reporter:  timse201                             |       Owner:
                                                 |  SergeyBiryukov
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  I18N                                 |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch commit dev-reviewed i18n-  |     Focuses:
  change                                         |
-------------------------------------------------+-------------------------

Comment (by gaisma22):

 == Patch Testing Report
 Patch Tested: https://github.com/WordPress/wordpress-develop/pull/11412

 === Environment
 - WordPress: 7.0-beta6-62085-src
 - PHP: 8.3.30
 - Server: nginx/1.29.7
 - Database: MySQL 8.4.8
 - Browser: Brave
 - OS: Ubuntu 24.04
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None
 - Plugins: None

 === Steps Taken
 1. Applied PR #11412.
 2. Opened Posts > Add New and clicked the publish date field
    to open the datepicker.
 3. Clicked Next and Previous buttons to navigate between months.
    Both buttons worked correctly.

 ✅ Patch is solving the problem

 === Expected Result
 The datepicker Next and Previous buttons should function correctly
 after the i18n context strings are added.

 === Additional Notes
 1. This is a pure i18n change. No visual difference is expected.
    The strings `Next` and `Previous` now use `_x()` with translator
    context instead of `__()`, helping translators in languages where
    context determines the correct word.
 2. Datepicker navigation confirmed working on WordPress 7.0-beta6.

 === Screenshots
 [[Image(https://i.ibb.co/jvXTKGkr/datepicker-working.png)]]

 [[Image(https://i.ibb.co/ks6xV3ZW/after-datepicker.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65005#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 16:02:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 16:02:17 -0000
Subject: [wp-trac] [WordPress Trac] #65014: Site Health: Error icon
 missing due to missing dashicons class
In-Reply-To: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
References: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
Message-ID: <069.e62232087c670eb9bdcdb51d540737d2@wordpress.org>

#65014: Site Health: Error icon missing due to missing dashicons class
-------------------------------------+-------------------------------------
 Reporter:  valani9099               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  7.1
Component:  Site Health              |     Version:  5.3
 Severity:  normal                   |  Resolution:
 Keywords:  has-screenshots has-     |     Focuses:  ui, css,
  patch                              |  administration
-------------------------------------+-------------------------------------

Comment (by valani9099):

 Thank you for the clarification @wildworks! Sorry for the extra patch — I
 wasn't aware the PR was sufficient on its own. I've re-requested reviews
 on the PR from @sabernhardt and @t-hamano. I'll keep this in mind for
 future contributions and rely only on the PR going forward!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65014#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 17:31:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 17:31:23 -0000
Subject: [wp-trac] [WordPress Trac] #64926: REST API: GET requests fail
 object/array schema validation when params are JSON-serialized strings
In-Reply-To: <048.09e4f6945084c0394353ff269647c101@wordpress.org>
References: <048.09e4f6945084c0394353ff269647c101@wordpress.org>
Message-ID: <063.c53178b02ff4019fc319ae70cc40fc18@wordpress.org>

#64926: REST API: GET requests fail object/array schema validation when params are
JSON-serialized strings
-------------------------+-------------------------------------------------
 Reporter:  dsmy         |       Owner:  (none)
     Type:  defect       |      Status:  new
  (bug)                  |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  REST API     |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  javascript, rest-api, php-
                         |  compatibility
-------------------------+-------------------------------------------------

Comment (by dsmy):

 @westonruter I tested both encoding paths against two schema shapes on
 WordPress trunk (unpatched):

 **Schema A —** fully-typed properties (your example shape):
 addQueryArgs() bracket notation, booleans preserved.
 rest_sanitize_value_from_schema() coerces correctly when property types
 are declared. You're right that this works today.

 JSON.stringify gives 400 rest_invalid_type (the bug, unpatched).

 **Schema B —** additionalProperties: true, no declared property types (our
 use case):
 addQueryArgs() bracket notation are accepted, but types collapse: { lock:
 { move: false, remove: true }, dropCap: false } arrives as { lock: { move:
 "false", remove: "true" }, dropCap: "false" }. No schema type hints no
 coercion.

 JSON.stringify gives 400 rest_invalid_type (same bug).

 So addQueryArgs() solves the problem for endpoints where every nested
 property is typed in the schema. For additionalProperties schemas and for
 block attribute filters where you can't pre-declare every possible key
 bracket notation is lossy and JSON.stringify is the only lossless encoding
 path.

 This confirms the patch is still needed. It closes the gap for both schema
 shapes, consistent with how parse_json_params() already handles POST
 bodies.

 Replying to [comment:25 westonruter]:
 > Something that just came to mind: the abilities in the Abilities API can
 be exposed in the REST API. When an ability is read-only, then a `GET`
 request is made. Nevertheless, the `input_schema` may involve an object of
 properties.
 >
 > Consider this Abilities API code:
 >
 > {{{#!php
 > <?php
 > add_action(
 >       'wp_abilities_api_init',
 >       static function () {
 >               wp_register_ability(
 >                       'abilities-experiment/get-post',
 >                       array(
 >                               'label'               => __( 'Get Post',
 'abilities-experiment' ),
 >                               'description'         => __( 'Gets fields
 for a post', 'abilities-experiment' ),
 >                               'category'            => 'site',
 >                               'input_schema'        => array(
 >                                       'type'                 =>
 'object',
 >                                       'required'             => array(
 'post' ),
 >                                       'properties'           => array(
 >                                               'post' => array(
 >                                                       'type' =>
 'object',
 >                                                       'required' =>
 array( 'id' ),
 >                                                       'properties' =>
 array(
 >                                                               'id' =>
 array(
 >
 'type'        => 'integer',
 >
 'description' => __( 'The ID of the post to get.', 'abilities-experiment'
 ),
 >
 'minimum'     => 1,
 >                                                               ),
 >                                                       )
 >                                               ),
 >                                               'fields' => array(
 >                                                       'type' => 'array',
 >                                                       'items' => array(
 >                                                               'type' =>
 'string',
 >                                                       ),
 >                                               )
 >                                       ),
 >                               ),
 >                               'output_schema'       => array(
 >                                       'type'                 =>
 'object',
 >                               ),
 >                               'execute_callback'    => static function (
 array $input ): array|WP_Error {
 >                                       $post = get_post(
 $input['post']['id'] );
 >                                       if ( ! $post ) {
 >                                               return new WP_Error(
 'post_not_found', __( 'Post not found.', 'abilities-experiment' ), array(
 'status' => 404 ) );
 >                                       }
 >                                       $data = $post->to_array();
 >                                       if ( $input['fields'] ) {
 >                                               $data =
 wp_array_slice_assoc( $data, $input['fields'] );
 >                                       }
 >                                       return $data;
 >                               },
 >                               'permission_callback' => static function (
 array $input ): bool {
 >                                       return current_user_can(
 'edit_posts', $input['post']['id'] );
 >                               },
 >                               'meta'                => array(
 >                                       'annotations'  => array(
 >                                               'readonly'    => true,
 >                                               'destructive' => false,
 >                                               'idempotent'  => false,
 >                                       ),
 >                                       'show_in_rest' => true,
 >                               ),
 >                       )
 >               );
 >       }
 > );
 > }}}
 >
 > Using the Abilities API client module as follows:
 >
 > {{{#!js
 > (await import("@wordpress/abilities")).executeAbility(
 >   "abilities-experiment/get-post",
 >   { post: { id: 1 }, fields: ["post_content", "post_author"] },
 > );
 > }}}
 >
 > This results in an HTTP request being made to the REST API as follows:
 >
 > `/wp-json/wp-abilities/v1/abilities/abilities-experiment/get-
 post/run?input%5Bpost%5D%5Bid%5D=1&input%5Bfields%5D%5B0%5D=post_content&input%5Bfields%5D%5B1%5D=post_author&_locale=user`
 >
 > With the brackets decoded:
 >
 > `/wp-json/wp-abilities/v1/abilities/abilities-experiment/get-
 post/run?input[post][id]=1&input[fields][0]=post_content&input[fields][1]=post_author&_locale=user`
 >
 > So, note that `@wordpress/abilities` (er, `@wordpress/core-abilities`)
 is already handling this correctly, converting a nested object into a list
 of URL query params.
 >
 > See
 [https://github.com/WordPress/gutenberg/blob/6ea168835304764d253d169906148cf5fe6269d9/packages
 /core-abilities/src/index.ts#L27-L71 logic] in `createServerCallback()`:
 >
 > {{{
 > // For GET and DELETE requests, pass the input as query parameters.
 > path = addQueryArgs( path, { input } );
 > }}}
 >
 > This `addQueryArgs()` function is part of the `@wordpress/url` package:
 https://developer.wordpress.org/block-editor/reference-guides/packages
 /packages-url/#addqueryargs
 >
 > So you can use that instead of the `qs` package.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64926#comment:26>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 18:38:10 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 18:38:10 -0000
Subject: [wp-trac] [WordPress Trac] #64225: Test tool and unit test
 improvements for 7.0
In-Reply-To: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
References: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
Message-ID: <066.6b61456b73ae500d5220a0a9890198fd@wordpress.org>

#64225: Test tool and unit test improvements for 7.0
--------------------------------------+---------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  task (blessed)            |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by SergeyBiryukov):

 In [changeset:"62218" 62218]:
 {{{
 #!CommitTicketReference repository="" revision="62218"
 Tests: Add missing `@covers` tags for some multisite tests.

 Follow-up to [62213].

 See #64225.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64225#comment:56>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 19:26:00 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 19:26:00 -0000
Subject: [wp-trac] [WordPress Trac] #63085: "Login details" spam sent by
 from the account registration page
In-Reply-To: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
References: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
Message-ID: <066.ca59cf2db0b0e424d6d5abdbf714de02@wordpress.org>

#63085: "Login details" spam sent by from the account registration page
-------------------------------------------------+-------------------------
 Reporter:  cweiske                              |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Login and Registration               |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests has-test-   |     Focuses:
  info                                           |
-------------------------------------------------+-------------------------
Changes (by cweiske):

 * keywords:  has-patch has-unit-tests => has-patch has-unit-tests has-test-
     info


Comment:

 == How to test

 1. Enable registration: General Settings > Membership > Anyone can
 register
 2. Log out, open the login form and click "register"
 3. Enter "www.spammer.com 123 BTC" as username, and a dummy e-mail
 address.
 4. Submit the registration form. The username will be rejected.
 5. Try to register again, this time as username "123 Bitcoin
 www.spammer.com"
 6. Submit the registration form. The username will be rejected.
 7. Try to register again with a username that does not begin with "www."
 and does not contain "<space>www.". This username will not be rejected.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63085#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 21:28:24 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 21:28:24 -0000
Subject: [wp-trac] [WordPress Trac] #64656: Fatal error on new font
 library admin page
In-Reply-To: <051.452a77fdc7ce1f6e32036f66207914fe@wordpress.org>
References: <051.452a77fdc7ce1f6e32036f66207914fe@wordpress.org>
Message-ID: <066.8f85ecd8f6d8a601ffa1309db61bd4d4@wordpress.org>

#64656: Fatal error on new font library admin page
----------------------------+--------------------------
 Reporter:  desrosj         |       Owner:  youknowriad
     Type:  defect (bug)    |      Status:  closed
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:  fixed
 Keywords:  has-patch       |     Focuses:
----------------------------+--------------------------
Changes (by pbearne):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 Updated the trunk again, and it is fixed :-)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64656#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr  7 22:33:02 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 07 Apr 2026 22:33:02 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.e4a114dc2a86a14f8d396d4b9a4868f1@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
--------------------------------------+-------------------------------
 Reporter:  jorgefilipecosta          |       Owner:  jorgefilipecosta
     Type:  feature request           |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.0
Component:  Plugins                   |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------------

Comment (by peterwilsoncc):

 Replying to [comment:41 matveb]:
 > I'm a bit confused about the outcome. I agree, at this late stage, the
 connector should not show up when the plugin is not present in the WP
 install, but it should be displayed when it is, even if it's not
 activated.
 >
 > It’s important to position connectors as not being exclusively for AI.
 Looking beyond, the connectors UI should show available connectors from
 any installed plugin, regardless of whether they are activated. Given
 Akismet is bundled by default, it should show up if the file is present
 for 7.0. It'd be odd to have the plugin present in plugins but not in
 connectors. For the next cycle, this should be formalized in plugin
 headers or some other broader mechanism.


 Mobile, jetlgged, flight delays. Excuse typos


 The Akismet team have added a connector to their plugin for the next
 release (mentioned in core-ai channel)

 An akismet API entry field will show up once the plugin is active and
 needed. I’m not sure what happened when both the plugin and core were
 registered the connectors

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:45>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 02:45:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 02:45:12 -0000
Subject: [wp-trac] [WordPress Trac] #62996: register_new_user()
 unintentionally triggering 'profile_update' hook
In-Reply-To: <059.992a6d75ece41ad901164a6253efa607@wordpress.org>
References: <059.992a6d75ece41ad901164a6253efa607@wordpress.org>
Message-ID: <074.4df5f6f0091e318b31ea2c82dfc22a13@wordpress.org>

#62996: register_new_user() unintentionally triggering 'profile_update' hook
-------------------------------------+------------------------------
 Reporter:  johnjamesjacoby          |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Login and Registration   |     Version:  5.3
 Severity:  normal                   |  Resolution:
 Keywords:  2nd-opinion needs-patch  |     Focuses:
-------------------------------------+------------------------------

Comment (by johnjamesjacoby):

 This is also happening when submitting a password reset via `wp-
 login.php?action=lostpassword`.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62996#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 04:40:19 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 04:40:19 -0000
Subject: [wp-trac] [WordPress Trac] #65037: Block Supports: Add min width
 block support to dimensions
Message-ID: <059.0aad98f413f2ed1b493e244489334918@wordpress.org>

#65037: Block Supports: Add min width block support to dimensions
-----------------------------+-----------------------------
 Reporter:  aaronrobertshaw  |      Owner:  (none)
     Type:  defect (bug)     |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  Editor           |    Version:  trunk
 Severity:  normal           |   Keywords:  gutenberg-merge
  Focuses:                   |
-----------------------------+-----------------------------
 This ticket tracks the backport of PHP files for the following Gutenberg
 update:

 https://github.com/WordPress/gutenberg/pull/76949

 Adds `dimensions.minWidth` as a new block support, enabling blocks to
 define a minimum width value. This mirrors the existing
 `dimensions.minHeight` support and allows themes and users to set `min-
 width` CSS properties on supported blocks via theme.json or block styles.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65037>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 07:18:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 07:18:06 -0000
Subject: [wp-trac] [WordPress Trac] #64536: About Page - 7.0
In-Reply-To: <051.70759fa0a8836490f78fb36a7530ec61@wordpress.org>
References: <051.70759fa0a8836490f78fb36a7530ec61@wordpress.org>
Message-ID: <066.dc200106fef6dac46609a625ec0145e0@wordpress.org>

#64536: About Page - 7.0
----------------------------+---------------------
 Reporter:  desrosj         |       Owner:  (none)
     Type:  task (blessed)  |      Status:  new
 Priority:  normal          |   Milestone:  7.0
Component:  Help/About      |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:
----------------------------+---------------------
Changes (by parinpanjari):

 * keywords:  needs-design =>


Comment:

 @fcoveram @desrosj

 Just checking if the updated design with the neutral background has been
 applied.

 Since I don’t have edit access for that change, please let me know if
 anything is needed from my side to help move this forward.

 Happy to assist with finalizing if required.

 Thanks!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64536#comment:26>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 08:35:32 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 08:35:32 -0000
Subject: [wp-trac] [WordPress Trac] #55344: Resources for hidden widgets
 are loaded on WP dashboard
In-Reply-To: <053.4ed27fa406a39cbf13813ae1048c8a9f@wordpress.org>
References: <053.4ed27fa406a39cbf13813ae1048c8a9f@wordpress.org>
Message-ID: <068.55a540ef41feda47af8f8a730b1fb3ed@wordpress.org>

#55344: Resources for hidden widgets are loaded on WP dashboard
-----------------------------+-----------------------------
 Reporter:  josklever        |       Owner:  (none)
     Type:  feature request  |      Status:  assigned
 Priority:  normal           |   Milestone:  Future Release
Component:  Administration   |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  needs-patch      |     Focuses:  javascript
-----------------------------+-----------------------------

Comment (by sanket.parmar):

 Thanks for the report and to everyone who weighed in. The problem is real
 and fixable without a major architectural change. This comment proposes a
 concrete approach.

 ----

 == How the current system works ==

 The Screen Options toggle is fully client-side: `postbox.js` calls
 `$postbox.hide()` or `$postbox.show()`, then persists the new visibility
 state via an AJAX call to `wp-ajax.php?action=closed-postboxes`. The
 server stores the hidden widget IDs in `metaboxhidden_dashboard` user meta
 — ''without'' a page reload.

 On the next full page load, `get_hidden_meta_boxes( $screen )` reads that
 user meta and returns the list of hidden widget IDs. This list is already
 used server-side (e.g. to render the Screen Options checkboxes), but is
 '''never consulted before plugins enqueue their assets'''.

 The typical plugin pattern looks like this:

 {{{#!php
 function my_plugin_dashboard_setup() {
     wp_enqueue_script( 'my-plugin-dashboard' );  // ← always runs, hidden
 or not
     wp_add_dashboard_widget( 'my_plugin_widget', 'My Widget',
 'my_plugin_widget_render' );
 }
 add_action( 'wp_dashboard_setup', 'my_plugin_dashboard_setup' );
 }}}

 There is no supported way for a plugin to say "only enqueue this if my
 widget is visible." The bug exists in core itself too — the Site Health
 widget is the only core widget that explicitly enqueues separate assets,
 and it does so unconditionally — but the primary audience for a fix is
 plugin authors.

 ----

 == UX constraint ==

 If we skip enqueueing scripts for a hidden widget, and the user then un-
 hides it via Screen Options ''without a page reload'', the widget's JS
 will be absent until the next full load.

 This is the same trade-off that applies to all other meta-box screens in
 WordPress. A user toggling Screen Options on any post edit screen faces
 the same behaviour today. [comment:7 Comment #7] on this ticket already
 acknowledges this, and it is the accepted outcome — '''no additional UX
 change or page-reload prompt is needed'''.

 ----

 == Distinguishing hidden vs. closed ==

 Two separate user-meta keys exist:

  * `metaboxhidden_dashboard` — widget unchecked in Screen Options →
 removed from the DOM entirely
  * `closedpostboxes_dashboard` — widget collapsed (title bar only, content
 still in DOM)

 The fix should apply '''only''' to hidden widgets. Collapsed widgets are
 still present in the DOM and their scripts may be needed when the user
 expands them without a page reload. `get_hidden_meta_boxes()` returns
 exactly the hidden list.

 ----

 == Proposed approaches ==

 === Approach A — New `$enqueue_callback` parameter on
 `wp_add_dashboard_widget()` (recommended) ===

 Add an optional 8th parameter. The function checks the hidden list once
 and only invokes the callback when the widget is visible. All callers —
 core and plugins — can opt in with a single-line change.

 {{{#!php
 /**
  * @since X.X.0
  *
  * @param callable|null $enqueue_callback Optional. Callback that enqueues
  *     scripts/styles for this widget. Only called when the widget is not
  *     hidden via Screen Options. Default null.
  */
 function wp_add_dashboard_widget(
     $widget_id,
     $widget_name,
     $callback,
     $control_callback = null,
     $callback_args    = null,
     $context          = 'normal',
     $priority         = 'core',
     $enqueue_callback = null    // ← new, backward-compatible
 ) {
     global $wp_dashboard_control_callbacks;
     $screen = get_current_screen();

     if ( is_callable( $enqueue_callback ) ) {
         $hidden = get_hidden_meta_boxes( $screen );
         if ( ! in_array( $widget_id, $hidden, true ) ) {
             call_user_func( $enqueue_callback );
         }
     }

     // ... rest of existing function unchanged ...
 }
 }}}

 Plugin migration is minimal:

 {{{#!php
 // Before:
 function my_plugin_dashboard_setup() {
     wp_enqueue_script( 'my-plugin-dashboard' );
     wp_add_dashboard_widget( 'my_plugin_widget', 'My Widget',
 'my_plugin_widget_render' );
 }

 // After:
 function my_plugin_dashboard_setup() {
     wp_add_dashboard_widget(
         'my_plugin_widget',
         'My Widget',
         'my_plugin_widget_render',
         null, null, 'normal', 'core',
         function() {
             wp_enqueue_script( 'my-plugin-dashboard' );
         }
     );
 }
 }}}

 '''Pros:''' Centralised, consistent, documented, backward-compatible
 (default `null` means existing calls are untouched).[[BR]]
 '''Cons:''' Requires plugin authors to update their code to benefit; does
 not automatically fix existing plugins.

 ----

 === Approach B — Dynamic action hook ===

 Instead of a new parameter, fire a targeted action inside
 `wp_add_dashboard_widget()` only when the widget is visible:

 {{{#!php
 if ( ! in_array( $widget_id, get_hidden_meta_boxes( $screen ), true ) ) {
     /**
      * Fires when a dashboard widget's resources should be enqueued.
      * Only fires if the widget is not hidden via Screen Options.
      *
      * @since X.X.0
      *
      * @param string $widget_id The widget ID.
      */
     do_action( "wp_dashboard_widget_enqueue_{$widget_id}", $widget_id );
 }
 }}}

 Plugin usage:

 {{{#!php
 add_action( 'wp_dashboard_widget_enqueue_my_plugin_widget', function() {
     wp_enqueue_script( 'my-plugin-dashboard' );
 } );
 }}}

 '''Pros:''' Hook-based; no new function signature; trivial for plugins to
 adopt.[[BR]]
 '''Cons:''' Dynamic hook name is harder to discover and grep for; does not
 help if enqueue calls happen before `wp_add_dashboard_widget()` is called.

 ----

 == What must not break ==

 ||= Area =||= Concern =||= Safe? =||
 || First visit (no user pref set) || `get_hidden_meta_boxes()` returns
 `[]` by default for the dashboard screen → all resources enqueued as today
 || ✓ ||
 || Toggle hide → show without reload || Scripts absent until next full
 load — same as all other meta-box screens || ✓ (accepted) ||
 || Collapsed (closed) widgets || `closedpostboxes_dashboard` ≠
 `metaboxhidden_dashboard`; collapsed widget scripts correctly loaded || ✓
 ||
 || Existing 7-argument callers of `wp_add_dashboard_widget()` || New 8th
 param defaults to `null`; all existing calls unchanged || ✓ ||
 || `wp_dashboard_setup` action callbacks that enqueue before calling
 `wp_add_dashboard_widget()` || Not automatically fixed; plugin authors
 need to move enqueue into the callback || ✗ (known limitation, same for
 Approach B) ||
 || Multisite per-user prefs || `metaboxhidden_dashboard` is per-user-per-
 blog; `get_hidden_meta_boxes()` already handles this || ✓ ||
 || Widget ordering / drag-drop || Sortable postboxes do not affect the
 hidden meta || ✓ ||

 ----

 == Tests needed ==

 File: `tests/phpunit/tests/admin/includesTemplate.php` (alongside the
 existing `test_wp_add_dashboard_widget`)

  1.
 `test_wp_add_dashboard_widget_enqueue_callback_called_when_visible`[[BR]]Widget
 ID not in `metaboxhidden_dashboard`. Assert the enqueue callback is
 invoked.

  2.
 `test_wp_add_dashboard_widget_enqueue_callback_not_called_when_hidden`[[BR]]Add
 the widget ID to `metaboxhidden_dashboard` user meta. Assert the enqueue
 callback is '''not''' invoked.

  3.
 `test_wp_add_dashboard_widget_enqueue_callback_not_called_when_closed_but_not_hidden`[[BR]]Add
 the widget ID to `closedpostboxes_dashboard` but '''not'''
 `metaboxhidden_dashboard`. Assert the callback IS invoked (collapsed ≠
 hidden).

  4.
 `test_wp_add_dashboard_widget_null_enqueue_callback_no_error`[[BR]]Call
 with default `null` callback; assert no error is produced (backward-
 compatibility regression test).

  5.
 `test_wp_add_dashboard_widget_enqueue_callback_called_when_no_user_pref`[[BR]]Delete
 `metaboxhidden_dashboard` user option entirely (first-visit scenario).
 Assert callback IS invoked.

 ----

 == Recommendation ==

 '''Approach A''' (`$enqueue_callback` parameter) is the better long-term
 API — it keeps the enqueue logic co-located with the widget registration,
 is self-documenting, and is easy to validate in tests. Approach B is
 simpler to adopt but less discoverable.

 Happy to put together a patch for either approach.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/55344#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 08:58:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 08:58:56 -0000
Subject: [wp-trac] [WordPress Trac] #65035: Abilities: Strip internal
 schema keywords from abilities REST responses
In-Reply-To: <060.11365645bf003f62fe2c244d23d3172e@wordpress.org>
References: <060.11365645bf003f62fe2c244d23d3172e@wordpress.org>
Message-ID: <075.600bf95041215f4808942c22df11cd5d@wordpress.org>

#65035: Abilities: Strip internal schema keywords from abilities REST responses
---------------------------------------------------+---------------------
 Reporter:  jorgefilipecosta                       |       Owner:  (none)
     Type:  defect (bug)                           |      Status:  new
 Priority:  normal                                 |   Milestone:  7.0
Component:  AI                                     |     Version:
 Severity:  normal                                 |  Resolution:
 Keywords:  has-patch has-unit-tests dev-reviewed  |     Focuses:
---------------------------------------------------+---------------------
Changes (by gziolo):

 * keywords:  has-patch has-unit-tests => has-patch has-unit-tests dev-
     reviewed


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65035#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 09:56:46 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 09:56:46 -0000
Subject: [wp-trac] [WordPress Trac] #64955: Abilities API: Add schema
 compiler for AI tool calling compatibility
In-Reply-To: <050.19503ad4acb7bc26296393882efd78fe@wordpress.org>
References: <050.19503ad4acb7bc26296393882efd78fe@wordpress.org>
Message-ID: <065.d3c79c3fc5a78c3f0890c36e9e571d8b@wordpress.org>

#64955: Abilities API: Add schema compiler for AI tool calling compatibility
---------------------------------------------+-----------------------------
 Reporter:  gziolo                           |       Owner:  gziolo
     Type:  enhancement                      |      Status:  assigned
 Priority:  normal                           |   Milestone:  Future Release
Component:  AI                               |     Version:  6.9
 Severity:  normal                           |  Resolution:
 Keywords:  abilities ai-client 2nd-opinion  |     Focuses:  rest-api
---------------------------------------------+-----------------------------

Comment (by gziolo):

 #65035 fixes the Abilities REST API (`/wp/v2/abilities`) leaking
 WordPress-internal schema keywords (`sanitize_callback`,
 `validate_callback`, `arg_options`) into `input_schema` and
 `output_schema` responses. These keywords aren't valid JSON Schema and
 break client-side validators — notably Gutenberg's AI tools integration.

 This is a targeted fix for item 5 in this ticket's description (WordPress-
 only keywords) at the REST output boundary. The broader schema compiler
 proposed here would address the remaining structural incompatibilities
 (items 1–4 and 6) at the AI-facing boundary.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64955#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 10:50:40 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 10:50:40 -0000
Subject: [wp-trac] [WordPress Trac] #57979: Can't upload images to
 WordPress Comments
In-Reply-To: <047.a82cb166cec25ad36f1f38efdeccbe9f@wordpress.org>
References: <047.a82cb166cec25ad36f1f38efdeccbe9f@wordpress.org>
Message-ID: <062.dc9301b2623135a66dd394dfa867a858@wordpress.org>

#57979: Can't upload images to WordPress Comments
-------------------------------------------------+-------------------------
 Reporter:  sbb                                  |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Comments                             |     Version:  6.0.3
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch 2nd-opinion dev-feedback   |     Focuses:
  early has-unit-tests                           |  administration
-------------------------------------------------+-------------------------
Changes (by sukhendu2002):

 * keywords:
     has-patch 2nd-opinion dev-feedback changes-requested early has-unit-
     tests
     => has-patch 2nd-opinion dev-feedback early has-unit-tests


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/57979#comment:30>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 10:57:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 10:57:39 -0000
Subject: [wp-trac] [WordPress Trac] #65038: Shortcode block adds empty <p>
 tags around block output in widget/footer areas
Message-ID: <052.bfb40169a8ed2a0ceb94e4a0c088e9f5@wordpress.org>

#65038: Shortcode block adds empty <p> tags around block output in widget/footer
areas
--------------------------+-----------------------------
 Reporter:  frauinga      |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  General       |    Version:  6.9.4
 Severity:  normal        |   Keywords:  has-screenshots
  Focuses:                |
--------------------------+-----------------------------
 In WordPress 6.9.4, using a Blocksy child theme, I’m seeing empty <p> tags
 around the output of shortcodes when they are placed in a Shortcode block
 or widget block inside the footer.

 The shortcode returns valid block‑level HTML (e.g. <ul class="widget-
 terminliste"> ... </ul>), but in the frontend it is rendered as:

 <div class="widget_block">
     <p><ul class="widget-name"> ... </ul></p>
 </div>

 This results in invalid HTML, since a <ul> must not be a direct child of
 <p>. The browser repairs this by creating an empty <p> element, which
 shows up in the DOM inspector as <p></p> and causes unnecessary vertical
 spacing, especially in the footer where layout is tight.

 **Steps to reproduce**

 1. WordPress 6.9.4 with the Blocksy theme and a child theme based on it.
 2. Add a Shortcode block (or “Shortcode” widget) in the footer widget area
 (or any footer block region).
 3. Insert a shortcode that returns block‑level HTML, e.g. <ul>, <div>, or
 similar.
 4. View the page in the browser and inspect the HTML.
     You will see something like <p><ul> ... </ul></p> and, in the DOM
 tree, an empty <p>.

 **Expected behavior**

 - The shortcode output should be rendered without extra <p> tags around
 it.
 - The HTML should be valid (e.g. <ul> not inside <p>).
 - No empty <p> elements should appear in the DOM.

 **Actual behavior**
 - WordPress wraps the shortcode output in a <p> in the widget/footer
 context.
 - This leads to invalid HTML and an empty <p> in the DOM, causing layout
 issues.

 **Environment**

 - WordPress version: 6.9.4
 - Theme: Blocksy
 - Child theme: yes
 - Context: footer widget / shortcode block

 **Notes**

 - The same behavior occurs with different shortcodes, including Blocksy’s
 own example shortcodes, so it does not seem to be related to a specific
 theme function.
 - A CSS workaround (hiding p:empty or p containing .widget-terminliste) is
 possible, but the root cause lies in shortcode/block rendering in
 widget/footer contexts and should be handled in core or Gutenberg.
 - The site is still under construction

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65038>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 10:58:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 10:58:57 -0000
Subject: [wp-trac] [WordPress Trac] #65038: Shortcode block adds empty
 <p> tags around block output in widget/footer areas
In-Reply-To: <052.bfb40169a8ed2a0ceb94e4a0c088e9f5@wordpress.org>
References: <052.bfb40169a8ed2a0ceb94e4a0c088e9f5@wordpress.org>
Message-ID: <067.a943c062791eebe58a330163dda79cb6@wordpress.org>

#65038: Shortcode block adds empty <p> tags around block output in widget/footer
areas
-----------------------------+------------------------------
 Reporter:  frauinga         |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  General          |     Version:  6.9.4
 Severity:  normal           |  Resolution:
 Keywords:  has-screenshots  |     Focuses:
-----------------------------+------------------------------
Changes (by frauinga):

 * Attachment "Screenshot 2026-04-08 125438.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65038>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 10:59:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 10:59:16 -0000
Subject: [wp-trac] [WordPress Trac] #65038: Shortcode block adds empty
 <p> tags around block output in widget/footer areas
In-Reply-To: <052.bfb40169a8ed2a0ceb94e4a0c088e9f5@wordpress.org>
References: <052.bfb40169a8ed2a0ceb94e4a0c088e9f5@wordpress.org>
Message-ID: <067.b17353957a3030fd6942453f44de4eb3@wordpress.org>

#65038: Shortcode block adds empty <p> tags around block output in widget/footer
areas
-----------------------------+------------------------------
 Reporter:  frauinga         |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  General          |     Version:  6.9.4
 Severity:  normal           |  Resolution:
 Keywords:  has-screenshots  |     Focuses:
-----------------------------+------------------------------
Changes (by frauinga):

 * Attachment "Screenshot 2026-04-08 125605.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65038>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 11:15:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 11:15:07 -0000
Subject: [wp-trac] [WordPress Trac] #64536: About Page - 7.0
In-Reply-To: <051.70759fa0a8836490f78fb36a7530ec61@wordpress.org>
References: <051.70759fa0a8836490f78fb36a7530ec61@wordpress.org>
Message-ID: <066.3289b43ea262994d12980fd430f42f8e@wordpress.org>

#64536: About Page - 7.0
----------------------------+---------------------
 Reporter:  desrosj         |       Owner:  (none)
     Type:  task (blessed)  |      Status:  new
 Priority:  normal          |   Milestone:  7.0
Component:  Help/About      |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:
----------------------------+---------------------

Comment (by peterwilsoncc):

 Moving the header to use rounded corners will need updated designs for the
 hover elements in the "About, Credits .... Get Involved" menu, could they
 be added to the Figma file?

 In the WordPress 6.9 about page update, the rounded corners were reverted
 as it made the hover effects look odd at either end of the menu, see this
 [https://github.com/WordPress/wordpress-
 develop/pull/10500#pullrequestreview-3445703617 comment on the 6.9 PR] for
 a gif showing the issue.

 My apologies if this is covered in the Figma file and my ignorance of the
 ways of Figma means I am missing something obvious.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64536#comment:27>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 11:33:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 11:33:53 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.485d15e2f339adf23c43f74d22734f8e@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
-------------------------------------+-------------------------------------
 Reporter:  piyushpatel123           |       Owner:  audrasjb
     Type:  defect (bug)             |      Status:  accepted
 Priority:  normal                   |   Milestone:  7.0
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  needs-testing has-patch  |     Focuses:  ui, css,
  admin-reskin                       |  administration
-------------------------------------+-------------------------------------

Comment (by jdahir0789):

 I have tested in playground issue is not resolve.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 11:36:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 11:36:29 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.ae3d54bcbccafcded918b08f11b33504@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
-------------------------------------+-------------------------------------
 Reporter:  piyushpatel123           |       Owner:  audrasjb
     Type:  defect (bug)             |      Status:  accepted
 Priority:  normal                   |   Milestone:  7.0
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  needs-testing has-patch  |     Focuses:  ui, css,
  admin-reskin                       |  administration
-------------------------------------+-------------------------------------
Changes (by jdahir0789):

 * Attachment "04-08-2026_05_03_PM.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 11:36:40 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 11:36:40 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.c181756cb9dc2a4dacfc95f039ce68f1@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
-------------------------------------+-------------------------------------
 Reporter:  piyushpatel123           |       Owner:  audrasjb
     Type:  defect (bug)             |      Status:  accepted
 Priority:  normal                   |   Milestone:  7.0
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  needs-testing has-patch  |     Focuses:  ui, css,
  admin-reskin                       |  administration
-------------------------------------+-------------------------------------
Changes (by jdahir0789):

 * Attachment "04-08-2026_05_04_PM.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 12:25:01 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 12:25:01 -0000
Subject: [wp-trac] [WordPress Trac] #65008: Block Hooks / RTC:
 Auto-inserted blocks duplicated on page refresh or collaborator join
In-Reply-To: <059.319ad79e4a20ae87460da2f729f62d48@wordpress.org>
References: <059.319ad79e4a20ae87460da2f729f62d48@wordpress.org>
Message-ID: <074.657fda4aa306116f8f84026ef1ecdd6c@wordpress.org>

#65008: Block Hooks / RTC: Auto-inserted blocks duplicated on page refresh or
collaborator join
-----------------------------+------------------------------
 Reporter:  Bernhard Reiter  |       Owner:  Bernhard Reiter
     Type:  defect (bug)     |      Status:  closed
 Priority:  normal           |   Milestone:  7.0
Component:  Editor           |     Version:  trunk
 Severity:  normal           |  Resolution:  fixed
 Keywords:  has-patch        |     Focuses:
-----------------------------+------------------------------
Changes (by jonsurrell):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62219" 62219]:
 {{{
 #!CommitTicketReference repository="" revision="62219"
 Block Hooks: Set ignored blocks meta in REST API response.

 Set `_wp_ignored_hooked_blocks` post meta in the REST API response sent
 from post-like endpoints that support Block Hooks (see
 `rest_block_hooks_post_types` filter).

 Previously, it was enough to set that post meta on write (i.e. save to
 DB). However, due to the way real-time collaboration syncs posts and
 reconciles them with content received from the server side, this
 information is now vital on the client side to ensure hooked blocks aren't
 duplicated.

 Developed in https://github.com/WordPress/wordpress-develop/pull/11410.

 Props bernhard-reiter, czarate, ingeniumed.
 Fixes #65008.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65008#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 12:28:27 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 12:28:27 -0000
Subject: [wp-trac] [WordPress Trac] #65008: Block Hooks / RTC:
 Auto-inserted blocks duplicated on page refresh or collaborator join
In-Reply-To: <059.319ad79e4a20ae87460da2f729f62d48@wordpress.org>
References: <059.319ad79e4a20ae87460da2f729f62d48@wordpress.org>
Message-ID: <074.b2b255ea12896a371a9a5623d89bf155@wordpress.org>

#65008: Block Hooks / RTC: Auto-inserted blocks duplicated on page refresh or
collaborator join
------------------------------------+------------------------------
 Reporter:  Bernhard Reiter         |       Owner:  Bernhard Reiter
     Type:  defect (bug)            |      Status:  reopened
 Priority:  normal                  |   Milestone:  7.0
Component:  Editor                  |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:
------------------------------------+------------------------------
Changes (by Bernhard Reiter):

 * keywords:  has-patch => has-patch dev-feedback
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Reopening for the backport to 7.0.
 (It meets the criteria: Fixes a bug that was introduced during the 7.0
 cycle.)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65008#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 12:34:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 12:34:21 -0000
Subject: [wp-trac] [WordPress Trac] #65008: Block Hooks / RTC:
 Auto-inserted blocks duplicated on page refresh or collaborator join
In-Reply-To: <059.319ad79e4a20ae87460da2f729f62d48@wordpress.org>
References: <059.319ad79e4a20ae87460da2f729f62d48@wordpress.org>
Message-ID: <074.ea3b32e075be34d0454947f969c26df1@wordpress.org>

#65008: Block Hooks / RTC: Auto-inserted blocks duplicated on page refresh or
collaborator join
------------------------------------+------------------------------
 Reporter:  Bernhard Reiter         |       Owner:  Bernhard Reiter
     Type:  defect (bug)            |      Status:  reopened
 Priority:  normal                  |   Milestone:  7.0
Component:  Editor                  |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-reviewed  |     Focuses:
------------------------------------+------------------------------
Changes (by jonsurrell):

 * keywords:  has-patch dev-feedback => has-patch dev-reviewed


Comment:

 Approving [62219] for 7.0 backport. It's a 7.0 bugfix for RTC and
 satisfies the requirements.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65008#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 12:42:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 12:42:18 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2364962=3A_Install_scr?=
 =?utf-8?b?ZWVuczog4oCcTG9nIElu4oCdIGFuZCAiU3VwcG9ydCBsaW5rIiB1c2Ugb2xk?=
 =?utf-8?q?_color?=
In-Reply-To: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
References: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
Message-ID: <074.2c64c42f5a11a599fc095b36ea0a610f@wordpress.org>

#64962: Install screens: “Log In” and "Support link" use old color
-------------------------------------------------+-------------------------
 Reporter:  huzaifaalmesbah                      |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch has-          |     Focuses:  ui, css
  screenshots changes-requested                  |
-------------------------------------------------+-------------------------

Comment (by darshitrajyaguru97):

 tested the changes locally with the updated code, and the link colors are
 now consistent with the revised admin design system. The “Log In” and
 support article links align well with other admin link styles, improving
 overall visual consistency.
 From my review, the color values look accurate, and the update meets the
 intended UI expectations.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64962#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 12:43:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 12:43:05 -0000
Subject: [wp-trac] [WordPress Trac] #65008: Block Hooks / RTC:
 Auto-inserted blocks duplicated on page refresh or collaborator join
In-Reply-To: <059.319ad79e4a20ae87460da2f729f62d48@wordpress.org>
References: <059.319ad79e4a20ae87460da2f729f62d48@wordpress.org>
Message-ID: <074.1408e461f0095447fb5c51838f4ba3e4@wordpress.org>

#65008: Block Hooks / RTC: Auto-inserted blocks duplicated on page refresh or
collaborator join
------------------------------------+------------------------------
 Reporter:  Bernhard Reiter         |       Owner:  Bernhard Reiter
     Type:  defect (bug)            |      Status:  closed
 Priority:  normal                  |   Milestone:  7.0
Component:  Editor                  |     Version:  trunk
 Severity:  normal                  |  Resolution:  fixed
 Keywords:  has-patch dev-reviewed  |     Focuses:
------------------------------------+------------------------------
Changes (by jonsurrell):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62220" 62220]:
 {{{
 #!CommitTicketReference repository="" revision="62220"
 Block Hooks: Set ignored blocks meta in REST API response.

 Set `_wp_ignored_hooked_blocks` post meta in the REST API response sent
 from post-like endpoints that support Block Hooks (see
 `rest_block_hooks_post_types` filter).

 Previously, it was enough to set that post meta on write (i.e. save to
 DB). However, due to the way real-time collaboration syncs posts and
 reconciles them with content received from the server side, this
 information is now vital on the client side to ensure hooked blocks aren't
 duplicated.

 Developed in https://github.com/WordPress/wordpress-develop/pull/11410.

 Reviewed by jonsurrell.
 Merges [62219] to the 7.0 branch.

 Props bernhard-reiter, czarate, ingeniumed.
 Fixes #65008.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65008#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 13:34:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 13:34:44 -0000
Subject: [wp-trac] [WordPress Trac] #57420: Add filter for
 wp_theme_get_element_class_name
In-Reply-To: <056.8e793be96f60abf5c9806cc67eab5028@wordpress.org>
References: <056.8e793be96f60abf5c9806cc67eab5028@wordpress.org>
Message-ID: <071.b441426b414dab880d864a431a8917d4@wordpress.org>

#57420: Add filter for wp_theme_get_element_class_name
--------------------------+------------------------------
 Reporter:  benjgrolleau  |       Owner:  (none)
     Type:  enhancement   |      Status:  closed
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:
 Severity:  minor         |  Resolution:  wontfix
 Keywords:  has-patch     |     Focuses:
--------------------------+------------------------------
Changes (by benjgrolleau):

 * status:  new => closed
 * resolution:   => wontfix


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/57420#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 14:21:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 14:21:56 -0000
Subject: [wp-trac] [WordPress Trac] #65039: _doing_it_wrong messages in
 WP_Block_Type_Registry::register() lack context
Message-ID: <056.8be73966739af74d828552979ecac5c8@wordpress.org>

#65039: _doing_it_wrong messages in WP_Block_Type_Registry::register() lack context
--------------------------+-----------------------------
 Reporter:  benjgrolleau  |      Owner:  (none)
     Type:  enhancement   |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Editor        |    Version:  trunk
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 WP_Block_Type_Registry::register() has four _doing_it_wrong() calls for
 invalid block names. Three of them don't say which name caused the error.

 Example: you get "Block type names must not contain uppercase characters."
 with no way to tell which block it's about.

 The fourth message ("Block type "%s" is already registered.") already
 includes the name. The other three should do the same to improve
 developper experience.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65039>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 15:08:38 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 15:08:38 -0000
Subject: [wp-trac] [WordPress Trac] #65040: WordPress Paragraph block
 throwing "Block contains unexpected or invalid content" error
 inconsistently on brand new blocks in WordPress 6.9.4
Message-ID: <054.a07bca5b15b45cc713e61bece909c015@wordpress.org>

#65040: WordPress Paragraph block throwing "Block contains unexpected or invalid
content" error inconsistently on brand new blocks in WordPress 6.9.4
--------------------------+-----------------------------
 Reporter:  playagroup    |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  General       |    Version:  6.9.4
 Severity:  major         |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 I am experiencing a consistent but inconsistently triggered validation
 error on WordPress Paragraph blocks in WordPress 6.9.4 with automatic
 updates enabled.


 Brand new WordPress Paragraph blocks are triggering "Block contains
 unexpected or invalid content" errors under WordPress 6.9.4.  The build
 structure is a container block housing a GenerateBlocks image block with a
 separate container block directly underneath containing the Paragraph
 block used as a caption text centered in bold text and this Paragraph
 block is where the validator error is occurring unevenly applied meaning
 it’s not rejecting every single container block within the new build area
 in this years old post I’m re-building.

 The critical diagnostic detail: the error fires randomly across newly
 created blocks only not the original block farther down the page.  Every
 single item is built inside the identical block structure I detailed
 above.  I’m rebuilding this post taking it from one rather GIANT/TALL
 container block housing the content into a series of multiple container
 blocks so the underlying page structure is leaner and will render even
 faster for website visitors.  So, there’s the old (original content) below
 in that older very tall container block and brand new container blocks at
 the top of the post.  Each new container block up above is from scratch
 nothing is copied from down below. Same block type and build structure,
 identical formatting, same build process every time — yet the validator
 accepts some and rejects others inconsistently. A plugin conflict would
 produce consistent errors. This does not.

 Clicking "Attempt Recovery" is destructive — it strips all formatting and
 content below the first line of my caption. It is not a viable solution
 and the other two options take me from bad to worse territory so all three
 in this instance are dead on arrival.

 This is not a GeneratePress Premium theme or GenerateBlocks Pro issue. The
 error is on the WordPress core Paragraph block.

 What I’m running building on:  WordPress version 6.9.4, GeneratePress
 Premium theme version 2.5.5, GenerateBlocks Pro version 2.5.0.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65040>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 15:44:25 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 15:44:25 -0000
Subject: [wp-trac] [WordPress Trac] #64771: Existing block level custom
 CSS in a post breaks when the post is edited by user without
 unfiltered_html
In-Reply-To: <056.6cde4cb4d3674a3ab453a19d1888b21e@wordpress.org>
References: <056.6cde4cb4d3674a3ab453a19d1888b21e@wordpress.org>
Message-ID: <071.56402279b913b3323525f2f6f9593cb4@wordpress.org>

#64771: Existing block level custom CSS in a post breaks when the post is edited by
user without unfiltered_html
--------------------------------------------------+---------------------
 Reporter:  glendaviesnz                          |       Owner:  (none)
     Type:  defect (bug)                          |      Status:  new
 Priority:  high                                  |   Milestone:  7.0
Component:  Editor                                |     Version:  trunk
 Severity:  critical                              |  Resolution:
 Keywords:  has-patch has-unit-tests 2nd-opinion  |     Focuses:
--------------------------------------------------+---------------------

Comment (by apeatling):

 Adding a concrete data point in support of keeping this feature in 7.0.

 I'm building Miles (bymiles.ai), an AI site builder for WordPress with
 paying customers. This approach works well. Per-block custom CSS is
 exactly the primitive Miles needs. It's the natural output target for
 section-level styling that doesn't belong in theme.json globals.

 A full revert (option 1) would be a real setback given how much of the
 block editor's recent direction this unlocks.

 For what it's worth, the data-URI / base64 approach from @dmsnell and
 @sirreal looks like the right long-term answer to me. It keeps KSES doing
 its one job and moves the encoding responsibility to the system that owns
 the data. Happy to help test whatever lands.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64771#comment:50>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 15:47:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 15:47:39 -0000
Subject: [wp-trac] [WordPress Trac] #65035: Abilities: Strip internal
 schema keywords from abilities REST responses
In-Reply-To: <060.11365645bf003f62fe2c244d23d3172e@wordpress.org>
References: <060.11365645bf003f62fe2c244d23d3172e@wordpress.org>
Message-ID: <075.39fc7a74c95a0de9b931ed7e9ff53b3b@wordpress.org>

#65035: Abilities: Strip internal schema keywords from abilities REST responses
-------------------------------------------------+-------------------------
 Reporter:  jorgefilipecosta                     |       Owner:
                                                 |  jorgefilipecosta
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  AI                                   |     Version:
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests dev-        |     Focuses:
  reviewed                                       |
-------------------------------------------------+-------------------------
Changes (by jorgefilipecosta):

 * owner:  (none) => jorgefilipecosta
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62221" 62221]:
 {{{
 #!CommitTicketReference repository="" revision="62221"
 Abilities: Strip internal schema keywords from abilities REST responses.

 Remove WordPress-internal properties (`sanitize_callback`,
 `validate_callback`, `arg_options`) from ability `input_schema` and
 `output_schema` fields in REST responses. These properties are used
 server-side but are not valid JSON Schema keywords and cause client-side
 validators to fail.

 Props jorgefilipecosta, ocean90, gziolo.
 Fixes #65035.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65035#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 15:58:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 15:58:09 -0000
Subject: [wp-trac] [WordPress Trac] #65041: Implement Priority+ pattern for
 WordPress adminbar
Message-ID: <056.8691352382afa15de7f9c21e9388d411@wordpress.org>

#65041: Implement Priority+ pattern for WordPress adminbar
----------------------------+-----------------------------
 Reporter:  mrleblanc101    |      Owner:  (none)
     Type:  enhancement     |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Administration  |    Version:
 Severity:  normal          |   Keywords:
  Focuses:  ui              |
----------------------------+-----------------------------
 When plugin add new menu items to the wordpress admin bar, it breaks the
 adminbar when resizing the window bellow a certain threshold.
 It would be nice to implement the priority+ pattern (See
 https://github.com/jayfreestone/priority-plus) where elements that would
 wrap or overflow are collapsed into a separate submenu instead of breaking
 the adminbar.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65041>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 15:59:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 15:59:06 -0000
Subject: [wp-trac] [WordPress Trac] #65041: Implement Priority+ pattern
 for WordPress adminbar
In-Reply-To: <056.8691352382afa15de7f9c21e9388d411@wordpress.org>
References: <056.8691352382afa15de7f9c21e9388d411@wordpress.org>
Message-ID: <071.da7f6dd12365c07816fa6824c39e4bda@wordpress.org>

#65041: Implement Priority+ pattern for WordPress adminbar
----------------------------+------------------------------
 Reporter:  mrleblanc101    |       Owner:  (none)
     Type:  enhancement     |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:  ui
----------------------------+------------------------------
Changes (by mrleblanc101):

 * Attachment "2026-04-08 11.53.02.gif" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65041>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 16:04:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 16:04:16 -0000
Subject: [wp-trac] [WordPress Trac] #65041: Implement Priority+ pattern
 for WordPress adminbar
In-Reply-To: <056.8691352382afa15de7f9c21e9388d411@wordpress.org>
References: <056.8691352382afa15de7f9c21e9388d411@wordpress.org>
Message-ID: <071.75606c20c3d894a10c42280e068278aa@wordpress.org>

#65041: Implement Priority+ pattern for WordPress adminbar
----------------------------+------------------------------
 Reporter:  mrleblanc101    |       Owner:  (none)
     Type:  enhancement     |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:  ui
----------------------------+------------------------------
Changes (by mrleblanc101):

 * Attachment "nav-demo.gif" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65041>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 16:15:20 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 16:15:20 -0000
Subject: [wp-trac] [WordPress Trac] #64771: Existing block level custom
 CSS in a post breaks when the post is edited by user without
 unfiltered_html
In-Reply-To: <056.6cde4cb4d3674a3ab453a19d1888b21e@wordpress.org>
References: <056.6cde4cb4d3674a3ab453a19d1888b21e@wordpress.org>
Message-ID: <071.2da1cee50ca0cf1c53ca53b78680df1d@wordpress.org>

#64771: Existing block level custom CSS in a post breaks when the post is edited by
user without unfiltered_html
--------------------------------------------------+---------------------
 Reporter:  glendaviesnz                          |       Owner:  (none)
     Type:  defect (bug)                          |      Status:  new
 Priority:  high                                  |   Milestone:  7.0
Component:  Editor                                |     Version:  trunk
 Severity:  critical                              |  Resolution:
 Keywords:  has-patch has-unit-tests 2nd-opinion  |     Focuses:
--------------------------------------------------+---------------------

Comment (by apeatling):

 Will `edit_css` be a standalone capability, or does it resolve to
 `unfiltered_html` via `map_meta_cap`? This materially affects whether
 trusted tools and AI agents can operate on hardened hosts without
 implementing questionable workarounds.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64771#comment:51>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 17:22:58 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 17:22:58 -0000
Subject: [wp-trac] [WordPress Trac] #45907: Twenty Nineteen:
 Right-aligned,
 uncaptioned images inserted via the Classic Editor do not extend beyond the
 text column
In-Reply-To: <050.c1989ede0c64f21325e00693fd80e3ee@wordpress.org>
References: <050.c1989ede0c64f21325e00693fd80e3ee@wordpress.org>
Message-ID: <065.aa2c9eac14c3af460d534bd4b3447f78@wordpress.org>

#45907: Twenty Nineteen: Right-aligned, uncaptioned images inserted via the Classic
Editor do not extend beyond the text column
-----------------------------+-----------------------------
 Reporter:  kjellr           |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Future Release
Component:  Bundled Theme    |     Version:  5.0
 Severity:  normal           |  Resolution:
 Keywords:  has-patch close  |     Focuses:  css
-----------------------------+-----------------------------
Changes (by sabernhardt):

 * keywords:  good-first-bug has-patch needs-refresh changes-requested =>
     has-patch close


Comment:

 People who have added captionless images in the Classic Editor with
 alignment to the right or left probably should expect them to continue
 displaying the same way they have been for the past 7 years. I recommend
 ignoring the discrepancy.

 On the
 [https://github.com/WordPress/twentynineteen/issues/688#issuecomment-443336721
 GitHub issue], @joyously wanted to fix the discrepancy the other way:
 > Having them stick out might be the design, but it looks odd. It looks
 like they are the problem, not the ones that are in line with the text
 being the problem.

 Also, the patches do not consider right-to-left languages. The `style-
 rtl.css` stylesheet would add rules for the `alignleft` class instead of
 `alignright`. And Twenty Nineteen stylesheets need be compiled from SCSS,
 which complicates setting rules for two different classes.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/45907#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 17:54:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 17:54:39 -0000
Subject: [wp-trac] [WordPress Trac] #64536: About Page - 7.0
In-Reply-To: <051.70759fa0a8836490f78fb36a7530ec61@wordpress.org>
References: <051.70759fa0a8836490f78fb36a7530ec61@wordpress.org>
Message-ID: <066.87003ec725328f3fb8969137d3ecb58e@wordpress.org>

#64536: About Page - 7.0
----------------------------+---------------------
 Reporter:  desrosj         |       Owner:  (none)
     Type:  task (blessed)  |      Status:  new
 Priority:  normal          |   Milestone:  7.0
Component:  Help/About      |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:
----------------------------+---------------------
Changes (by markoserb):

 * Attachment "About _ cover.png" added.

 about_cover-rounded-edges

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64536>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 17:55:02 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 17:55:02 -0000
Subject: [wp-trac] [WordPress Trac] #64536: About Page - 7.0
In-Reply-To: <051.70759fa0a8836490f78fb36a7530ec61@wordpress.org>
References: <051.70759fa0a8836490f78fb36a7530ec61@wordpress.org>
Message-ID: <066.057327cad1f410cf99ea9dd0e8dfc8c3@wordpress.org>

#64536: About Page - 7.0
----------------------------+---------------------
 Reporter:  desrosj         |       Owner:  (none)
     Type:  task (blessed)  |      Status:  new
 Priority:  normal          |   Milestone:  7.0
Component:  Help/About      |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:
----------------------------+---------------------

Comment (by markoserb):

 It's either we update the buttons to have the same radius value (image
 above), or keep the sharp approach for covers. Ideally we do round these,
 as lower sections are also rounded. However, if timing is not good we can
 leave it for the next release and simply go sharp edges. @fcoveram what do
 you think?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64536#comment:28>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 18:41:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 18:41:29 -0000
Subject: [wp-trac] [WordPress Trac] #64225: Test tool and unit test
 improvements for 7.0
In-Reply-To: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
References: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
Message-ID: <066.6ff21d6c6ef4708206094d919a29b7c9@wordpress.org>

#64225: Test tool and unit test improvements for 7.0
--------------------------------------+---------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  task (blessed)            |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by SergeyBiryukov):

 In [changeset:"62222" 62222]:
 {{{
 #!CommitTicketReference repository="" revision="62222"
 Tests: Add missing `@covers` tags for some multisite tests.

 Follow-up to [62213], [62218].

 See #64225.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64225#comment:57>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 18:42:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 18:42:30 -0000
Subject: [wp-trac] [WordPress Trac] #62864: Add padding and color
 changes to buttons and inputs
In-Reply-To: <054.a3c8f2ead86a6b48e5676a1f3b5c857a@wordpress.org>
References: <054.a3c8f2ead86a6b48e5676a1f3b5c857a@wordpress.org>
Message-ID: <069.236c935d50a05afee9db10629e8de9b0@wordpress.org>

#62864: Add padding and color changes to buttons and inputs
-------------------------------------------------+-------------------------
 Reporter:  karmatosed                           |       Owner:
                                                 |  fabiankaegy
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Administration                       |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  needs-design-feedback has-patch      |     Focuses:  ui,
  early                                          |  accessibility, css
-------------------------------------------------+-------------------------

Comment (by joedolson):

 I haven't encountered them either; and this seemed related specifically to
 fixed-height elements. I'm thinking that it's not a relevant issue here.

 In that case, I'm thinking that this can be closed, as this specific path
 for an admin redesign isn't being taken, and the other path is largely
 finished.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62864#comment:22>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 18:57:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 18:57:28 -0000
Subject: [wp-trac] [WordPress Trac] #42061: Add new utility function for
 checking if the current request is a REST API request.
In-Reply-To: <055.bea450dae3f9b358bd493a1db818a9d6@wordpress.org>
References: <055.bea450dae3f9b358bd493a1db818a9d6@wordpress.org>
Message-ID: <070.4db4311e411e416b7c34f28dab20a5c0@wordpress.org>

#42061: Add new utility function for checking if the current request is a REST API
request.
-------------------------------------------------+-------------------------
 Reporter:  lots.0.logs                          |       Owner:
                                                 |  TimothyBlynJacobs
     Type:  enhancement                          |      Status:  closed
 Priority:  normal                               |   Milestone:  6.5
Component:  Bootstrap/Load                       |     Version:  4.9
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch dev-feedback commit has-   |     Focuses:  rest-api,
  unit-tests add-to-field-guide                  |  performance
-------------------------------------------------+-------------------------

Comment (by johnjamesjacoby):

 Just found this!

 From a code-completion standpoint and the benefit of hindsight,
 `wp_is_serving_rest_request()` should have been `wp_doing_rest()` because
 that's the established pattern even if it isn't perfect for its context.
 The convenience of typing or searching for `wp_doing_` and your IDE
 showing all of the similar constant wrappers is hard to beat, plus we all
 know what those functions are intending to do.

 `_serving_` is a brand new unique verb without a need for any other
 `wp_is_serving_` functions. It's longer for no benefit, doesn't pair
 nicely with `wp_is_rest_endpoint()`, and introduces doubt as to what is
 going on internally in both functions.

 I'd still like to see `wp_doing_rest()` happen, along with
 `wp_doing_cli()` in a new ticket.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/42061#comment:44>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 18:58:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 18:58:23 -0000
Subject: [wp-trac] [WordPress Trac] #65042: Alter Attachment page slug
 behaviour
Message-ID: <058.fd3e142d1fd8c40b2e51ab15f9ac6119@wordpress.org>

#65042: Alter Attachment page slug behaviour
-------------------------------+-----------------------------
 Reporter:  namith.jawahar     |      Owner:  (none)
     Type:  enhancement        |     Status:  new
 Priority:  normal             |  Milestone:  Awaiting Review
Component:  Posts, Post Types  |    Version:
 Severity:  minor              |   Keywords:
  Focuses:                     |
-------------------------------+-----------------------------
 Since files in the media library are stored as post types, each media file
 uploaded takes a unique slug with it matching its file name which is then
 used to create the attachment page url.

 The problem is that this seldom used page hogs slugs which can’t be used
 in other post types like pages, posts, public custom post types etc.

 Eg : If I upload an image named “Planet X” I cannot have a page /planet-x
 page anymore as that slug is taken by the image page (which is again
 rarely used)

 There is no straight forward way to recover this slug back too as media
 library is not represented as a post type in the admin UI.

 I propose that media slugs be appended by an alphanumeric string on file
 upload to avoid hogging valuable slugs from other public post types.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65042>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 19:04:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 19:04:33 -0000
Subject: [wp-trac] [WordPress Trac] #64536: About Page - 7.0
In-Reply-To: <051.70759fa0a8836490f78fb36a7530ec61@wordpress.org>
References: <051.70759fa0a8836490f78fb36a7530ec61@wordpress.org>
Message-ID: <066.690eaaa2bece04c7128f9b2076d0aea2@wordpress.org>

#64536: About Page - 7.0
----------------------------+---------------------
 Reporter:  desrosj         |       Owner:  (none)
     Type:  task (blessed)  |      Status:  new
 Priority:  normal          |   Milestone:  7.0
Component:  Help/About      |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:
----------------------------+---------------------

Comment (by Benjamin_Zekavica):

 I wouldn’t round the buttons and would keep them without border radius.
 For the header, keep the top corners rounded and the bottom corners
 square.

 Example (Quick-CSS): https://cleanshot.com/share/ckl76CDh

 I wouldn’t change much overall.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64536#comment:29>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 19:12:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 19:12:55 -0000
Subject: [wp-trac] [WordPress Trac] #65042: Alter Attachment page slug
 behaviour
In-Reply-To: <058.fd3e142d1fd8c40b2e51ab15f9ac6119@wordpress.org>
References: <058.fd3e142d1fd8c40b2e51ab15f9ac6119@wordpress.org>
Message-ID: <073.6fadcc573cb561236968e0f42a5b8de4@wordpress.org>

#65042: Alter Attachment page slug behaviour
-------------------------------+------------------------------
 Reporter:  namith.jawahar     |       Owner:  (none)
     Type:  enhancement        |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Posts, Post Types  |     Version:
 Severity:  minor              |  Resolution:
 Keywords:                     |     Focuses:
-------------------------------+------------------------------

Comment (by siliconforks):

 Replying to [ticket:65042 namith.jawahar]:
 > There is no straight forward way to recover this slug back too as media
 library is not represented as a post type in the admin UI.

 There is a way to do it although it is not very obvious - you have to edit
 an attachment, then click "Screen Options" and check the "Slug" checkbox.

 > I propose that media slugs be appended by an alphanumeric string on file
 upload to avoid hogging valuable slugs from other public post types.

 There are plugins which do this already - for example:

 https://wordpress.org/plugins/disable-media-pages/

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65042#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 19:18:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 19:18:31 -0000
Subject: [wp-trac] [WordPress Trac] #65043: Consider adding wp_doing_cli()
 to wrap WP_CLI constant checks
Message-ID: <059.d826a9251a69742df119d4b424865c97@wordpress.org>

#65043: Consider adding wp_doing_cli() to wrap WP_CLI constant checks
-----------------------------+-----------------------------
 Reporter:  johnjamesjacoby  |      Owner:  (none)
     Type:  feature request  |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  Bootstrap/Load   |    Version:
 Severity:  normal           |   Keywords:  2nd-opinion
  Focuses:                   |
-----------------------------+-----------------------------
 See #42061.

 I think WordPress core should come with a `wp_doing_cli()` function to
 provide a centrally supported, familiar, and filterable way for plugins
 and tools to check whether or not the `WP_CLI` constant is set.

 While the WP-CLI project is an external library, it is obviously part of
 the WordPress Foundation, so it is the canonical command line interface
 for WordPress itself.

 Mostly, honestly, I get annoyed seeing `defined( 'WP_CLI' ) && WP_CLI`
 everywhere. 😇

 {{{
 /**
  * Determines whether the current request is a WordPress CLI request.
  *
  * @since 7.1.0
  *
  * @return bool True if it's a WordPress CLI request, false otherwise.
  */
 function wp_doing_cli() {
         /**
          * Filters whether the current request is a WordPress CLI request.
          *
          * @since 7.1.0
          *
          * @param bool $wp_doing_cli Whether the current request is a
 WordPress CLI request.
          */
         return apply_filters( 'wp_doing_cli', defined( 'WP_CLI' ) &&
 WP_CLI );
 }
 }}}

 (I set the Component to Bootstrap/Load because that's where this function
 would likely end up.)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65043>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 19:47:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 19:47:26 -0000
Subject: [wp-trac] [WordPress Trac] #65042: Alter Attachment page slug
 behaviour
In-Reply-To: <058.fd3e142d1fd8c40b2e51ab15f9ac6119@wordpress.org>
References: <058.fd3e142d1fd8c40b2e51ab15f9ac6119@wordpress.org>
Message-ID: <073.0a7c5adf9886db533e61855b71c0e75f@wordpress.org>

#65042: Alter Attachment page slug behaviour
-------------------------------+------------------------------
 Reporter:  namith.jawahar     |       Owner:  (none)
     Type:  enhancement        |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Posts, Post Types  |     Version:
 Severity:  minor              |  Resolution:
 Keywords:                     |     Focuses:
-------------------------------+------------------------------

Comment (by joedolson):

 See also #61824, #60816

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65042#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 21:02:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 21:02:48 -0000
Subject: [wp-trac] [WordPress Trac] #65032: View transition admin bar
 quirks
In-Reply-To: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
References: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
Message-ID: <067.8db73865cdd1b00c49327de3eb520ac5@wordpress.org>

#65032: View transition admin bar quirks
-------------------------------+--------------------------------
 Reporter:  zieladam           |       Owner:  (none)
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  7.0
Component:  Administration     |     Version:  trunk
 Severity:  normal             |  Resolution:
 Keywords:  reporter-feedback  |     Focuses:  ui, accessibility
-------------------------------+--------------------------------
Changes (by sabernhardt):

 * keywords:   => reporter-feedback


Old description:

> Since 7.0 enabled view transitions in wp-admin (#64470, [10699]),
> navigating between admin screens crossfades the entire admin sidebar into
> itself, even when its markup is nearly identical between the two pages.
>
> Screencast: https://github.com/user-attachments/assets/7a48ae52-70d7
> -47ee-95e0-aec80463dcde
>
> **Steps to reproduce**
>
> 1. Run trunk in Chrome.
> 2. Log in to wp-admin.
> 3. Click between two screens whose sidebars are nearly identical (e.g.
> Dashboard → Posts → Pages).
>
> **Expected**
>
> Sidebar stays visually stable across the navigation — nothing in it has
> changed.
>
> **Actual**
>
> The whole sidebar crossfades between two identical snapshots.
>
> == Notes ==
>
> Claude claims, to be verified:
>
> * `src/wp-admin/css/view-transitions.css` gives each top-level menu item
> a stable `view-transition-name`, but `#adminmenu` itself does not — so
> the whole sidebar falls into the default root snapshot and crossfades on
> every navigation.
> * a likely fix is to give `#adminmenu` (and possibly `#adminmenuwrap`)
> its own `view-transition-name` so it's treated as a single persistent
> element
> across navigations rather than part of the default root snapshot.
>
> cc @westonruter @annezazu

New description:

 Since 7.0 enabled view transitions in wp-admin (#64470,
 [https://github.com/WordPress/wordpress-develop/pull/10699 PR 10699]),
 navigating between admin screens crossfades the entire admin sidebar into
 itself, even when its markup is nearly identical between the two pages.

 Screencast: https://github.com/user-attachments/assets/7a48ae52-70d7-47ee-
 95e0-aec80463dcde

 **Steps to reproduce**

 1. Run trunk in Chrome.
 2. Log in to wp-admin.
 3. Click between two screens whose sidebars are nearly identical (e.g.
 Dashboard → Posts → Pages).

 **Expected**

 Sidebar stays visually stable across the navigation — nothing in it has
 changed.

 **Actual**

 The whole sidebar crossfades between two identical snapshots.

 == Notes ==

 Claude claims, to be verified:

 * `src/wp-admin/css/view-transitions.css` gives each top-level menu item a
 stable `view-transition-name`, but `#adminmenu` itself does not — so the
 whole sidebar falls into the default root snapshot and crossfades on every
 navigation.
 * a likely fix is to give `#adminmenu` (and possibly `#adminmenuwrap`) its
 own `view-transition-name` so it's treated as a single persistent element
 across navigations rather than part of the default root snapshot.

 cc @westonruter @annezazu

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65032#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 21:53:40 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 21:53:40 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.19ee6cb0cce6440887117159b8cae595@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
--------------------------------------+-------------------------------
 Reporter:  jorgefilipecosta          |       Owner:  jorgefilipecosta
     Type:  feature request           |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.0
Component:  Plugins                   |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------------

Comment (by jorbin):

 Replying to [comment:41 matveb]:

 > It’s important to position connectors as not being exclusively for AI.

 I agree. Do you want to open a ticket to discuss how best to do that or do
 you think this might be better as a make/core discussion?

 > Given Akismet is bundled by default, it should show up if the file is
 present for 7.0.

 How does that help users? If anything it's going to create confusion since
 they may think that by having entered the key on the connectors screen
 they have activated akismet. Aditionally, the connectors screen should be
 about reusable connections. Besides akismet, which plugins currently make
 use of this key? Installation and activation are different intents and
 should be treated differently.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:46>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr  8 21:57:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 08 Apr 2026 21:57:30 -0000
Subject: [wp-trac] [WordPress Trac] #57858: If permalink structure is
 set to /%category%/%postname% ,
 WordPress will match a /0/ path as a category archive
In-Reply-To: <051.249b4eee57497f64fc23af338fe61154@wordpress.org>
References: <051.249b4eee57497f64fc23af338fe61154@wordpress.org>
Message-ID: <066.5898494081fec17ab16b35844d21d393@wordpress.org>

#57858: If permalink structure is set to /%category%/%postname% , WordPress will
match a /0/ path as a category archive
-------------------------------------------------+-------------------------
 Reporter:  krdevio                              |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Rewrite Rules                        |     Version:  6.1.1
 Severity:  normal                               |  Resolution:
 Keywords:  has-test-info needs-testing needs-   |     Focuses:
  patch                                          |
-------------------------------------------------+-------------------------

Comment (by codente):

 Is there any update on this issue? I just ran into it.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/57858#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 00:01:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 00:01:26 -0000
Subject: [wp-trac] [WordPress Trac] #64683: _print_scripts should use
 the wp_inline_script_attributes filter
In-Reply-To: <051.b101eb3cd239e67d8a67df5ddf22e3ba@wordpress.org>
References: <051.b101eb3cd239e67d8a67df5ddf22e3ba@wordpress.org>
Message-ID: <066.dd6cfe05dc75749d8690e00603fe079b@wordpress.org>

#64683: _print_scripts should use the wp_inline_script_attributes filter
---------------------------+------------------------------
 Reporter:  galaxor        |       Owner:  (none)
     Type:  enhancement    |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  Script Loader  |     Version:  6.9.1
 Severity:  normal         |  Resolution:
 Keywords:                 |     Focuses:
---------------------------+------------------------------
Changes (by sabernhardt):

 * component:  General => Script Loader


Old description:

> On my site, we want to use a content-security-policy:
> https://infosec.mozilla.org/guidelines/web_security#content-security-
> policy. And in this policy, we would like to not include support for
> 'unsafe-inline' scripts.
>
> We can include inline scripts, as long as they have a nonce in them. That
> is, instead of just a <script> tag, if they included a <script
> nonce="xxxxxxx">, where the nonce is generated on every page load, and if
> our Content-Security-Policy contains script-src 'nonce-xxxxxxxx'.
>
> Some of the scripts generated by WordPress core -- and, indeed, by
> plugins -- print themselves out using the wp_get_inline_script_tag
> function. When a script does that, then our theme can add a filter on the
> wp_inline_script_attributes hook, which adds the nonce according to our
> own logic.
>
> However, there are some inline scripts printed by WordPress core that do
> not use wp_get_inline_script_tag, and with these scripts, there is no way
> to for our theme to add a nonce to the script tag, and therefore no way
> to allow these scripts to run in the context of a Content-Security-Policy
> that does not allow 'unsafe-inline' scripts.
>
> The scripts added by WordPress core are at least those that are added by
> wp_default_scripts.   Ultimately, these are printed out using the
> function _print_scripts, in wp-includes/script-loader.php.  It prints the
> script tag using
>
> {{{
> echo "\n<script{$type_attr}>\n";
> }}}
>

> where $type_attr is either the empty string or "type='text/javascript'".
>
> I propose that _print_scripts be changed so that instead of echoing the
> script directly, it constructs the code it wants to output, and prints it
> onto the page using wp_get_inline_script_tag, so that themes or plugins
> can add filters on the wp_inline_script_attributes hook to add a nonce
> (or do anything else).
>
> Is that a good approach?  If so, I can submit a pull request.
>
> If there's another approach that would be better, I could do that.
> Perhaps we want to have a different hook here for some reason.

New description:

 On my site, we want to use a
 [https://infosec.mozilla.org/guidelines/web_security#content-security-
 policy content-security-policy]. And in this policy, we would like to not
 include support for 'unsafe-inline' scripts.

 We can include inline scripts, as long as they have a nonce in them. That
 is, instead of just a `<script>` tag, if they included a `<script
 nonce="xxxxxxx">`, where the nonce is generated on every page load, and if
 our Content-Security-Policy contains `script-src 'nonce-xxxxxxxx'`.

 Some of the scripts generated by WordPress core—and, indeed, by
 plugins—print themselves out using the `wp_get_inline_script_tag`
 function. When a script does that, then our theme can add a filter on the
 `wp_inline_script_attributes` hook, which adds the nonce according to our
 own logic.

 However, there are some inline scripts printed by WordPress core that do
 not use `wp_get_inline_script_tag`, and with these scripts, there is no
 way to for our theme to add a nonce to the script tag, and therefore no
 way to allow these scripts to run in the context of a Content-Security-
 Policy that does not allow 'unsafe-inline' scripts.

 The scripts added by WordPress core are at least those that are added by
 `wp_default_scripts`.   Ultimately, these are printed out using the
 function `_print_scripts`, in `wp-includes/script-loader.php`.  It prints
 the script tag using

 {{{
 echo "\n<script{$type_attr}>\n";
 }}}


 where `$type_attr` is either the empty string or
 `"type='text/javascript'"`.

 I propose that `_print_scripts` be changed so that instead of echoing the
 script directly, it constructs the code it wants to output, and prints it
 onto the page using `wp_get_inline_script_tag`, so that themes or plugins
 can add filters on the `wp_inline_script_attributes` hook to add a nonce
 (or do anything else).

 Is that a good approach?  If so, I can submit a pull request.

 If there's another approach that would be better, I could do that.
 Perhaps we want to have a different hook here for some reason.

--

Comment:

 Related: #58664

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64683#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 01:42:10 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 01:42:10 -0000
Subject: [wp-trac] [WordPress Trac] #62864: Add padding and color
 changes to buttons and inputs
In-Reply-To: <054.a3c8f2ead86a6b48e5676a1f3b5c857a@wordpress.org>
References: <054.a3c8f2ead86a6b48e5676a1f3b5c857a@wordpress.org>
Message-ID: <069.9a310e4a448b3ba5eb0a040af7556408@wordpress.org>

#62864: Add padding and color changes to buttons and inputs
-------------------------------------------------+-------------------------
 Reporter:  karmatosed                           |       Owner:
                                                 |  fabiankaegy
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Administration                       |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  needs-design-feedback has-patch      |     Focuses:  ui,
  early                                          |  accessibility, css
-------------------------------------------------+-------------------------

Comment (by wildworks):

 @karmatosed @fabiankaegy

 I have towo questions:

 - Why is `line-height` necessary in addition to `min-height` for element
 height, and what issues arise if `line-height` is removed?
 - Are there any other tsks that should be addressed in this ticket?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62864#comment:23>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 02:56:59 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 02:56:59 -0000
Subject: [wp-trac] [WordPress Trac] #65038: Shortcode block adds empty
 <p> tags around block output in widget/footer areas
In-Reply-To: <052.bfb40169a8ed2a0ceb94e4a0c088e9f5@wordpress.org>
References: <052.bfb40169a8ed2a0ceb94e4a0c088e9f5@wordpress.org>
Message-ID: <067.9c6a2947e1262997d863ee62ebb934ed@wordpress.org>

#65038: Shortcode block adds empty <p> tags around block output in widget/footer
areas
-----------------------------+------------------------------
 Reporter:  frauinga         |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  General          |     Version:  6.9.4
 Severity:  normal           |  Resolution:
 Keywords:  has-screenshots  |     Focuses:
-----------------------------+------------------------------
Description changed by sabernhardt:

Old description:

> In WordPress 6.9.4, using a Blocksy child theme, I’m seeing empty <p>
> tags around the output of shortcodes when they are placed in a Shortcode
> block or widget block inside the footer.
>
> The shortcode returns valid block‑level HTML (e.g. <ul class="widget-
> terminliste"> ... </ul>), but in the frontend it is rendered as:
>
> <div class="widget_block">
>     <p><ul class="widget-name"> ... </ul></p>
> </div>
>
> This results in invalid HTML, since a <ul> must not be a direct child of
> <p>. The browser repairs this by creating an empty <p> element, which
> shows up in the DOM inspector as <p></p> and causes unnecessary vertical
> spacing, especially in the footer where layout is tight.
>
> **Steps to reproduce**
>
> 1. WordPress 6.9.4 with the Blocksy theme and a child theme based on it.
> 2. Add a Shortcode block (or “Shortcode” widget) in the footer widget
> area (or any footer block region).
> 3. Insert a shortcode that returns block‑level HTML, e.g. <ul>, <div>, or
> similar.
> 4. View the page in the browser and inspect the HTML.
>     You will see something like <p><ul> ... </ul></p> and, in the DOM
> tree, an empty <p>.
>
> **Expected behavior**
>
> - The shortcode output should be rendered without extra <p> tags around
> it.
> - The HTML should be valid (e.g. <ul> not inside <p>).
> - No empty <p> elements should appear in the DOM.
>
> **Actual behavior**
> - WordPress wraps the shortcode output in a <p> in the widget/footer
> context.
> - This leads to invalid HTML and an empty <p> in the DOM, causing layout
> issues.
>
> **Environment**
>
> - WordPress version: 6.9.4
> - Theme: Blocksy
> - Child theme: yes
> - Context: footer widget / shortcode block
>
> **Notes**
>
> - The same behavior occurs with different shortcodes, including Blocksy’s
> own example shortcodes, so it does not seem to be related to a specific
> theme function.
> - A CSS workaround (hiding p:empty or p containing .widget-terminliste)
> is possible, but the root cause lies in shortcode/block rendering in
> widget/footer contexts and should be handled in core or Gutenberg.
> - The site is still under construction

New description:

 In WordPress 6.9.4, using a Blocksy child theme, I’m seeing empty `<p>`
 tags around the output of shortcodes when they are placed in a Shortcode
 block or widget block inside the footer.

 The shortcode returns valid block‑level HTML (e.g. `<ul class="widget-
 terminliste"> ... </ul>`), but in the frontend it is rendered as:
 {{{
 <div class="widget_block">
     <p><ul class="widget-name"> ... </ul></p>
 </div>
 }}}

 This results in invalid HTML, since a `<ul>` must not be a direct child of
 <p>. The browser repairs this by creating an empty `<p>` element, which
 shows up in the DOM inspector as `<p></p>` and causes unnecessary vertical
 spacing, especially in the footer where layout is tight.

 **Steps to reproduce**

 1. WordPress 6.9.4 with the Blocksy theme and a child theme based on it.
 2. Add a Shortcode block (or “Shortcode” widget) in the footer widget area
 (or any footer block region).
 3. Insert a shortcode that returns block‑level HTML, e.g. `<ul>`, `<div>`,
 or similar.
 4. View the page in the browser and inspect the HTML. \\
    You will see something like `<p><ul> ... </ul></p>` and, in the DOM
 tree, an empty `<p>`.

 **Expected behavior**

 - The shortcode output should be rendered without extra `<p>` tags around
 it.
 - The HTML should be valid (e.g. `<ul>` not inside `<p>`).
 - No empty `<p>` elements should appear in the DOM.

 **Actual behavior**
 - WordPress wraps the shortcode output in a `<p>` in the widget/footer
 context.
 - This leads to invalid HTML and an empty `<p>` in the DOM, causing layout
 issues.

 **Environment**

 - WordPress version: 6.9.4
 - Theme: Blocksy
 - Child theme: yes
 - Context: footer widget / shortcode block

 **Notes**

 - The same behavior occurs with different shortcodes, including Blocksy’s
 own example shortcodes, so it does not seem to be related to a specific
 theme function.
 - A CSS workaround (hiding `p:empty` or `p` containing `.widget-
 terminliste`) is possible, but the root cause lies in shortcode/block
 rendering in widget/footer contexts and should be handled in core or
 Gutenberg.
 - The site is still under construction

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65038#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 03:07:43 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 03:07:43 -0000
Subject: [wp-trac] [WordPress Trac] #64926: REST API: GET requests fail
 object/array schema validation when params are JSON-serialized strings
In-Reply-To: <048.09e4f6945084c0394353ff269647c101@wordpress.org>
References: <048.09e4f6945084c0394353ff269647c101@wordpress.org>
Message-ID: <063.d932939603a54e299b6954a2ddf36c24@wordpress.org>

#64926: REST API: GET requests fail object/array schema validation when params are
JSON-serialized strings
-------------------------+-------------------------------------------------
 Reporter:  dsmy         |       Owner:  (none)
     Type:  defect       |      Status:  new
  (bug)                  |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  REST API     |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  javascript, rest-api, php-
                         |  compatibility
-------------------------+-------------------------------------------------

Comment (by liaison):

 @westonruter, @dsmy Thanks for sharing the context about the Abilities
 API.

 The Abilities API and @wordpress/abilities provide a structured interface
 for the WordPress ecosystem (like Gutenberg). By using the package,
 developers benefit from API encapsulation and schema-driven validation, as
 well as:

 Security: Execution via this package respects WordPress's built-in
 permission callbacks.

 State Management: Deep integration with Data Store and Caching for the
 Gutenberg Editor.

 Context Awareness: Improved handling for Multisite environments and
 metadata annotations.

 Implementing json_decode directly in rest-api.php provides a more
 "universal" approach. This keeps the REST API decoupled from any specific
 client-side library, which is essential for:

 Diverse Clients: AI agents (via MCP), standalone scripts, or headless SPAs
 that may not load the @wordpress/abilities package but still need to pass
 complex data via GET requests.

 Infrastructure Robustness: It ensures JSON-encoded strings are correctly
 parsed into types that match the input_schema, preventing validation
 errors during the raw REST path.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64926#comment:27>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 04:41:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 04:41:16 -0000
Subject: [wp-trac] [WordPress Trac] #53348: No form to log in when
 visiting wp-login.php with a given query string
In-Reply-To: <056.35d4161c0e6e0d6c95b0806d663da34b@wordpress.org>
References: <056.35d4161c0e6e0d6c95b0806d663da34b@wordpress.org>
Message-ID: <071.7b86e93a24aba629371a90ac0b0916fe@wordpress.org>

#53348: No form to log in when visiting wp-login.php with a given query string
------------------------------------------------+--------------------------
 Reporter:  henry.wright                        |       Owner:
                                                |  SergeyBiryukov
     Type:  defect (bug)                        |      Status:  reviewing
 Priority:  normal                              |   Milestone:  Future
                                                |  Release
Component:  Login and Registration              |     Version:
 Severity:  normal                              |  Resolution:
 Keywords:  needs-unit-tests early needs-patch  |     Focuses:
------------------------------------------------+--------------------------
Changes (by sheldorofazeroth):

 * keywords:  has-patch needs-unit-tests early => needs-unit-tests early
     needs-patch


Comment:

 The existing PR is 4 years old. Therefore, raising a new PR which covers
 some additional cases.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/53348#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 04:45:51 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 04:45:51 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.83e8719cf64d561b80c299a93fb8c4c9@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
-------------------------------------+-------------------------------------
 Reporter:  piyushpatel123           |       Owner:  audrasjb
     Type:  defect (bug)             |      Status:  accepted
 Priority:  normal                   |   Milestone:  7.0
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  needs-testing has-patch  |     Focuses:  ui, css,
  admin-reskin                       |  administration
-------------------------------------+-------------------------------------

Comment (by gautammkgarg):

 Tested patch: https://github.com/WordPress/wordpress-develop/pull/11463

 Environment

 WordPress: 7.1-alpha-20260407.134046
 PHP: 7.4.33
 Server: Playground
 Database: WP_SQLite_Driver 8.0.38
 Browser: Firefox 148
 OS: Android
 Theme: Twenty Twenty-Five 1.4

 I think alignment is better after patch is applied but I think it is still
 not exactly center aligned.
 [[Image(https://prnt.sc/aIGLnK85BqUU)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 04:50:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 04:50:13 -0000
Subject: [wp-trac] [WordPress Trac] #64944: Generated Excerpts - Missing
 white space when stripping <br>s generated in paragraph block, verse block,
 etc.
In-Reply-To: <055.8505625efe4ec85c57d03df6fb669dac@wordpress.org>
References: <055.8505625efe4ec85c57d03df6fb669dac@wordpress.org>
Message-ID: <070.285c028a420ec9d3f26115298f881f18@wordpress.org>

#64944: Generated Excerpts - Missing white space when stripping <br>s generated in
paragraph block, verse block, etc.
-------------------------------------------------+-------------------------
 Reporter:  addiestavlo                          |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  7.1
Component:  Formatting                           |     Version:  5.0
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests needs-      |     Focuses:
  testing                                        |
-------------------------------------------------+-------------------------

Comment (by yashyadav247):

 == Reproduction Report and Patch Testing
 === Description
 This report validates whether the issue related to missing white space
 when stripping <br>s generated in paragraph block, verse block, etc.
 can be reproduced.

 === Environment
 - WordPress: 7.1-alpha-62161-src
 - PHP: 8.2.28
 - Server: nginx/1.29.0
 - Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.28)
 - Browser: Chrome 145.0.0.0
 - OS: Windows 10/11
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None activated
 - Plugins:
   * Test Reports 1.2.1

 === Actual Results

 Created a new post using Verse block, and published the post. Ran
 get_the_excerpt for the post.
 No spaces between the last words of one line and first words of the next.
 ✅

 === Supplemental Artifacts

 **BEFORE**

 Created verse block

 [[Image(https://i.postimg.cc/fb3zr2w9/image.png)]]


 Calling get_the_excerpt for the post shows no spaces in between.

 [[Image(https://i.postimg.cc/XJCvp2mv/bug-reproduction.png)]]

 **AFTER Patch**:

 Spaces visible between the last words of one line and first words of the
 next ✅

 [[Image(https://i.postimg.cc/ZY36Bjz1/image.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64944#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 04:53:08 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 04:53:08 -0000
Subject: [wp-trac] [WordPress Trac] #65042: Alter Attachment page slug
 behaviour
In-Reply-To: <058.fd3e142d1fd8c40b2e51ab15f9ac6119@wordpress.org>
References: <058.fd3e142d1fd8c40b2e51ab15f9ac6119@wordpress.org>
Message-ID: <073.291cbf586e7c6ac3202bf15b50476622@wordpress.org>

#65042: Alter Attachment page slug behaviour
-------------------------------+------------------------------
 Reporter:  namith.jawahar     |       Owner:  (none)
     Type:  enhancement        |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Posts, Post Types  |     Version:
 Severity:  trivial            |  Resolution:
 Keywords:                     |     Focuses:
-------------------------------+------------------------------
Changes (by rakeshfalke):

 * severity:  minor => trivial


Comment:

 Replying to [ticket:65042 namith.jawahar]:

 Changing slug generation (random suffixes) would likely hurt SEO more than
 it helps:

 Breaks clean, readable URLs and can impact image/content sitemap structure
 Reduces keyword relevance in image filenames
 Can make debugging, CDN usage, and asset tracking harder


 I think this can be handled during site building:

 If a page is important → reserve that slug
 Use slightly adjusted image names (e.g., planet-x-image.jpg)

 I think best addressed through content planning and Information
 Architecture (IA), rather than modifying slug generation logic.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65042#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 04:55:04 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 04:55:04 -0000
Subject: [wp-trac] [WordPress Trac] #55563: The function
 get_allowed_mime_types should check wp_get_current_user
In-Reply-To: <049.ef77ab37b6df3e3dcc41a51596801c65@wordpress.org>
References: <049.ef77ab37b6df3e3dcc41a51596801c65@wordpress.org>
Message-ID: <064.f55a0f558e7c004eaaac37d56aa49ed2@wordpress.org>

#55563: The function get_allowed_mime_types should check wp_get_current_user
------------------------------------+------------------------------
 Reporter:  giuse                   |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Formatting              |     Version:  5.9.3
 Severity:  normal                  |  Resolution:
 Keywords:  dev-feedback has-patch  |     Focuses:
------------------------------------+------------------------------
Changes (by bruheshwarinikhil):

 * Attachment "55563.2.diff" added.

 Updated patch adding function_exists('wp_get_current_user') check and unit
 tests

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/55563>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 05:07:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 05:07:49 -0000
Subject: [wp-trac] [WordPress Trac] #55563: The function
 get_allowed_mime_types should check wp_get_current_user
In-Reply-To: <049.ef77ab37b6df3e3dcc41a51596801c65@wordpress.org>
References: <049.ef77ab37b6df3e3dcc41a51596801c65@wordpress.org>
Message-ID: <064.2ef4d1fd7712302f98c3702898c5f2c1@wordpress.org>

#55563: The function get_allowed_mime_types should check wp_get_current_user
------------------------------------+------------------------------
 Reporter:  giuse                   |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Formatting              |     Version:  5.9.3
 Severity:  normal                  |  Resolution:
 Keywords:  dev-feedback has-patch  |     Focuses:
------------------------------------+------------------------------
Changes (by bruheshwarinikhil):

 * keywords:  dev-feedback has-patch has-unit-tests => dev-feedback has-
               patch


Comment:

 Fixes a fatal error when get_allowed_mime_types() is called before
 wp_get_current_user() is defined (e.g. in a mu-plugin or before the
 plugin_loaded action). Fixes #55563.

 Adds function_exists( 'wp_get_current_user' ) check alongside the existing
 current_user_can check so the function degrades safely when the user
 system isn't loaded yet.

 **PR Link => https://github.com/WordPress/wordpress-develop/pull/11482**

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/55563#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 05:16:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 05:16:33 -0000
Subject: [wp-trac] [WordPress Trac] #65024: Not possible to modify the
 "Draft saved" message
In-Reply-To: <055.016483a0a4b9c0ce303a7dde8c97ad24@wordpress.org>
References: <055.016483a0a4b9c0ce303a7dde8c97ad24@wordpress.org>
Message-ID: <070.985cd4e5880c85b8911520c3cd82cff3@wordpress.org>

#65024: Not possible to modify the "Draft saved" message
-------------------------------+-----------------------------
 Reporter:  stevejburge        |       Owner:  (none)
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  7.1
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:  has-patch          |     Focuses:  administration
-------------------------------+-----------------------------

Comment (by sheldorofazeroth):

 I've submitted a patch that handles the PHP side of this fix.

 What the patch does:

 Adds a new item_draft_saved label to WP_Post_Type::get_default_labels() in
 class-wp-post-type.php with a default value of 'Draft saved.' for both
 hierarchical and non-hierarchical post types.
 Adds a contextual 'Pattern draft saved.' label for the wp_block post type
 in post.php, consistent with how it already defines its own
 item_published, item_updated, etc.
 Updates the get_post_type_labels() docblock to document the new label.
 Since the REST API post types controller already exposes the full
 $post_type->labels object, the new label flows to the JavaScript side
 automatically with no REST API changes needed.

 What still needs to happen (Gutenberg side):

 The wp-includes/js/dist/editor.js file is a compiled build artifact synced
 from the Gutenberg monorepo and should not be edited directly. The
 corresponding JS change — replacing the hardcoded __( 'Draft saved.' )
 with postType2.labels.item_draft_saved inside
 getNotificationArgumentsForSaveSuccess() in
 packages/editor/src/store/utils/notice-builder.js — needs to be submitted
 as a separate PR to the Gutenberg repository.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65024#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 05:25:04 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 05:25:04 -0000
Subject: [wp-trac] [WordPress Trac] #58824: Add a filter to change the
 classes in posts list table in admin
In-Reply-To: <052.52d3815d86e5ea6524314f24b9017c2c@wordpress.org>
References: <052.52d3815d86e5ea6524314f24b9017c2c@wordpress.org>
Message-ID: <067.e9c4b9b802226f147ae942cea2bfe21b@wordpress.org>

#58824: Add a filter to change the classes in posts list table in admin
-------------------------------------+-------------------------------------
 Reporter:  zahardoc                 |       Owner:  (none)
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  General                  |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  good-first-bug has-      |     Focuses:  ui, css,
  patch has-unit-tests               |  administration
-------------------------------------+-------------------------------------
Changes (by bruheshwarinikhil):

 * Attachment "58824.diff" added.

 Adds post_list_table_classes filter to
 WP_Posts_List_Table::get_table_classes() with unit tests.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/58824>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 05:30:04 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 05:30:04 -0000
Subject: [wp-trac] [WordPress Trac] #55563: The function
 get_allowed_mime_types should check wp_get_current_user
In-Reply-To: <049.ef77ab37b6df3e3dcc41a51596801c65@wordpress.org>
References: <049.ef77ab37b6df3e3dcc41a51596801c65@wordpress.org>
Message-ID: <064.9eb86cc0e9f87bdee8540c99ced21eac@wordpress.org>

#55563: The function get_allowed_mime_types should check wp_get_current_user
------------------------------------+------------------------------
 Reporter:  giuse                   |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Formatting              |     Version:  5.9.3
 Severity:  normal                  |  Resolution:
 Keywords:  dev-feedback has-patch  |     Focuses:
------------------------------------+------------------------------
Changes (by bruheshwarinikhil):

 * Attachment "55563.3.diff" added.

 Updated patch adding function_exists('wp_get_current_user') check and unit
 tests

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/55563>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 05:43:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 05:43:56 -0000
Subject: [wp-trac] [WordPress Trac] #65044: get_post_custom_values() missing
 array check, inconsistent with get_post_custom_keys()
Message-ID: <057.4a59bcc730ee55ef2108915dd95410cb@wordpress.org>

#65044: get_post_custom_values() missing array check, inconsistent with
get_post_custom_keys()
-------------------------------+-----------------------------
 Reporter:  saratheonline      |      Owner:  saratheonline
     Type:  defect (bug)       |     Status:  assigned
 Priority:  normal             |  Milestone:  Awaiting Review
Component:  Posts, Post Types  |    Version:  trunk
 Severity:  normal             |   Keywords:
  Focuses:                     |
-------------------------------+-----------------------------
 Explain that get_post_custom() can return false or "", and that the
 sibling function
   get_post_custom_keys() guards against this but get_post_custom_values()
 does not, causing a PHP 8+ warning.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65044>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 05:46:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 05:46:14 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.e9cfe82f400040533e92ab5f3d38eb8c@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
-------------------------------------+-------------------------------------
 Reporter:  piyushpatel123           |       Owner:  audrasjb
     Type:  defect (bug)             |      Status:  accepted
 Priority:  normal                   |   Milestone:  7.0
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  needs-testing has-patch  |     Focuses:  ui, css,
  admin-reskin                       |  administration
-------------------------------------+-------------------------------------

Comment (by gaurangsondagar):

 https://core.trac.wordpress.org/ticket/65031

 Tested the latest patch and it appears to be working as expected in Chrome
 and Firefox browsers.

 Steps:
 - Applied the patch
 - Navigated to the user edit screen
 - Checked password field alignment

 Result:
 The dashicon alignment looks correct and consistent. I did not notice any
 visual issues in my testing.

 Environment:
 - WordPress: 7.1-alpha-62161-src
 - PHP: 8.3.30
 - Browser: Chrome, Firefox
 - Database: MySQL 8.4.8
 - OS: Ubuntu

 The patch appears to work as expected. Screenshots for reference:

 Chrome:
 - https://kommodo.ai/i/Mrhi5OujbQsxTaij03xR
 - https://kommodo.ai/i/RWgMAZeNvv5sdODnZsCL

 Firefox:
 - https://kommodo.ai/i/lwFlv8ObJmXgNitBDZfY
 - https://kommodo.ai/i/REvixbQXniYMW4H54c55
 -

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 05:46:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 05:46:44 -0000
Subject: [wp-trac] [WordPress Trac] #65044: get_post_custom_values()
 missing array check, inconsistent with get_post_custom_keys()
In-Reply-To: <057.4a59bcc730ee55ef2108915dd95410cb@wordpress.org>
References: <057.4a59bcc730ee55ef2108915dd95410cb@wordpress.org>
Message-ID: <072.67f84cdc1fc6e3b2e90aeca907b793d0@wordpress.org>

#65044: get_post_custom_values() missing array check, inconsistent with
get_post_custom_keys()
-------------------------------------+------------------------------
 Reporter:  saratheonline            |       Owner:  saratheonline
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Posts, Post Types        |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+------------------------------
Changes (by saratheonline):

 * keywords:   => has-patch needs-testing


Comment:

 Pull request: https://github.com/saratheonline/wordpress-develop/pull/1

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65044#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 05:48:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 05:48:22 -0000
Subject: [wp-trac] [WordPress Trac] #57858: If permalink structure is
 set to /%category%/%postname% ,
 WordPress will match a /0/ path as a category archive
In-Reply-To: <051.249b4eee57497f64fc23af338fe61154@wordpress.org>
References: <051.249b4eee57497f64fc23af338fe61154@wordpress.org>
Message-ID: <066.9764bb3551311ffd2a913dd6ddddc9bd@wordpress.org>

#57858: If permalink structure is set to /%category%/%postname% , WordPress will
match a /0/ path as a category archive
-------------------------------------------------+-------------------------
 Reporter:  krdevio                              |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Rewrite Rules                        |     Version:  6.1.1
 Severity:  normal                               |  Resolution:
 Keywords:  has-test-info needs-testing needs-   |     Focuses:
  patch                                          |
-------------------------------------------------+-------------------------

Comment (by kalpeshh):

 I verified testcases below. And everything seems to be working as
 expected.


 **Permalink**: `/%category%/%postname%.html`

 **Test case 1:**
 `http://localhost:8889/uncategorized/hello-world.html`

 ✅ Working as expected and not giving 404

 **Test case 2:**
 `http://localhost:8889/0/hello-world.html`

 ✅ Working as expected and not giving 404 (as category index exist)


 **Test case 3:**
 `http://localhost:8889/0/

 ❌ Working but should have given 404


 **Test case 4:**
 `http://localhost:8889/1/

 ✅ Working as expected and giving 404

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/57858#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 05:51:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 05:51:44 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.ff9a6184a593bb9c63fe9d6ce2541734@wordpress.org>

#65015: Connectors: Several strings are not translated
--------------------------+----------------------
 Reporter:  369work       |       Owner:  (none)
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:  7.0
Component:  I18N          |     Version:
 Severity:  normal        |  Resolution:  wontfix
 Keywords:  close         |     Focuses:
--------------------------+----------------------
Changes (by malayladu):

 * keywords:   => close
 * status:  new => closed
 * resolution:   => wontfix


Comment:

 I've found that `Library` and `Upload` strings are coming from the
 Gutenberg build file. It should be part of the Gutenberg repo.

 Findings - `gutenberg/build/routes/font-list/content.js`

 This is already fixed in the Gutenberg repo. So, it seems a syncing issue
 of Gutenberg to the core. This should be synced in upcoming release.

 https://github.com/WordPress/gutenberg/blob/a473a4cbb07a650238d5ec11a0f9538db814ab30/routes
 /font-list/stage.tsx#L53-L60

 I worked on this issue on contributer's day and reviewed by cordinator.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 05:54:01 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 05:54:01 -0000
Subject: [wp-trac] [WordPress Trac] #64917: WP 7.0 Connectors: unclear
 error message
In-Reply-To: <051.50e3faafb74ba8eaaede21fb888645f0@wordpress.org>
References: <051.50e3faafb74ba8eaaede21fb888645f0@wordpress.org>
Message-ID: <066.47ba8ab3e1491c8b33725224b50078f3@wordpress.org>

#64917: WP 7.0 Connectors: unclear error message
---------------------------------+----------------------
 Reporter:  ecairol              |       Owner:  (none)
     Type:  defect (bug)         |      Status:  new
 Priority:  normal               |   Milestone:  7.0.1
Component:  AI                   |     Version:  trunk
 Severity:  normal               |  Resolution:
 Keywords:  ai-client has-patch  |     Focuses:  ui-copy
---------------------------------+----------------------

Comment (by dhruvang21):

 @JeffPaul The proposed message is definitely an improvement, but it may
 still be unclear for end users since <capability-name> exposes internal
 terminology and “none are active” can represent multiple states (no
 providers configured, providers disabled, or no providers supporting the
 capability).

 It might be better to:

 Use user-friendly capability labels (e.g., “image generation” instead of
 image_generation)

 For example:

 “No AI providers are configured. Please add one in Settings → Connectors.”
 “Your active AI providers do not support image generation. Please enable a
 compatible provider.”

 This would provide clearer, more actionable guidance and align with
 WordPress’ general approach to user-facing error messages.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64917#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 06:06:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 06:06:31 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.7fafd2e5e978df52b6b216c7eb8d0ff7@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
------------------------------------+--------------------------------------
 Reporter:  piyushpatel123          |       Owner:  audrasjb
     Type:  defect (bug)            |      Status:  accepted
 Priority:  normal                  |   Milestone:  7.0
Component:  Administration          |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch admin-reskin  |     Focuses:  ui, css, administration
------------------------------------+--------------------------------------
Changes (by gaisma22):

 * keywords:  needs-testing has-patch admin-reskin => has-patch admin-reskin


Comment:

 == Patch Testing Report
 Patch Tested: https://github.com/WordPress/wordpress-develop/pull/11463

 === Environment
 - WordPress: 7.0-beta6-62085-src
 - PHP: 8.3.30
 - Server: nginx/1.29.7
 - Database: MySQL 8.4.8
 - Browser: Brave
 - OS: Ubuntu 24.04
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None
 - Plugins: None

 === Steps Taken
 1. Went to Users > Edit User and clicked Set New Password.
    **Before patch:** Eye icon sits lower than the Hide text.
 2. Applied PR #11463 and hard refreshed.
    **After patch:** Eye icon aligned with Hide text.

 ✅ Patch is solving the problem

 === Expected Result
 The password toggle button eye icon should sit at the same vertical level
 as the Hide text on the user edit screen.

 === Additional Notes
 1. Bug confirmed on WordPress 7.0-beta6. The dashicon eye icon
    on the password toggle button on **`user-edit.php`** sits lower
    than the Hide text before the patch.
 2. After the patch the alignment is correct.
 3. Removing **`needs-testing`** as patch resolves the issue on
    WordPress 7.0-beta6-62085-src.

 === Screenshots/Screencast with results
 **Before Patch:**
 [[Image(https://i.ibb.co/Y4Zv164X/before-user-edit.png)]]

 **After Patch:**
 [[Image(https://i.ibb.co/zCcyqNB/after-user-edit.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 06:12:58 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 06:12:58 -0000
Subject: [wp-trac] [WordPress Trac] #65005: Next/Previous for datepicker
 needs context
In-Reply-To: <052.e7c5ffd7379c8e33f54d240e729da31e@wordpress.org>
References: <052.e7c5ffd7379c8e33f54d240e729da31e@wordpress.org>
Message-ID: <067.93929e35c14e27325807c265c79bc0c6@wordpress.org>

#65005: Next/Previous for datepicker needs context
-------------------------------------------------+-------------------------
 Reporter:  timse201                             |       Owner:
                                                 |  SergeyBiryukov
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  I18N                                 |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch commit dev-reviewed i18n-  |     Focuses:
  change                                         |
-------------------------------------------------+-------------------------
Changes (by mdhori15):

 * Attachment "65005.diff" added.

 The 7.0 branch still uses __( 'Next' ) and __( 'Previous' ) in
 wp_localize_jquery_ui_datepicker(). Attaching a patch to backport the _x()
 fix from trunk with proper context strings so translators can pick the
 correct grammatical form.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65005>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 06:13:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 06:13:28 -0000
Subject: [wp-trac] [WordPress Trac] #65039: _doing_it_wrong messages in
 WP_Block_Type_Registry::register() lack context
In-Reply-To: <056.8be73966739af74d828552979ecac5c8@wordpress.org>
References: <056.8be73966739af74d828552979ecac5c8@wordpress.org>
Message-ID: <071.22c0101db34aa088a067c7a5d1d80876@wordpress.org>

#65039: _doing_it_wrong messages in WP_Block_Type_Registry::register() lack context
--------------------------+--------------------------
 Reporter:  benjgrolleau  |       Owner:  westonruter
     Type:  enhancement   |      Status:  reviewing
 Priority:  normal        |   Milestone:  7.1
Component:  Editor        |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+--------------------------
Changes (by westonruter):

 * owner:  (none) => westonruter
 * status:  new => reviewing
 * milestone:  Awaiting Review => 7.1


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65039#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 06:14:40 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 06:14:40 -0000
Subject: [wp-trac] [WordPress Trac] #64619: wp.updates.l10n.updating is
 deprecated notice
In-Reply-To: <053.43a7a9a454abeb3b68ee4e5b92ba70cf@wordpress.org>
References: <053.43a7a9a454abeb3b68ee4e5b92ba70cf@wordpress.org>
Message-ID: <068.324a5d2bd94269d070f6b5279187177a@wordpress.org>

#64619: wp.updates.l10n.updating is deprecated notice
--------------------------+-----------------------------
 Reporter:  Presskopp     |       Owner:  westonruter
     Type:  defect (bug)  |      Status:  reviewing
 Priority:  normal        |   Milestone:  7.1
Component:  I18N          |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  administration
--------------------------+-----------------------------
Changes (by westonruter):

 * owner:  (none) => westonruter
 * status:  new => reviewing


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64619#comment:29>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 06:25:11 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 06:25:11 -0000
Subject: [wp-trac] [WordPress Trac] #65026: Hide plugin search form on
 Favorites tab
In-Reply-To: <048.5df104f8236536e341a0c31918d9a06c@wordpress.org>
References: <048.5df104f8236536e341a0c31918d9a06c@wordpress.org>
Message-ID: <063.02532619c2c64d2bd4bbb1896bd96233@wordpress.org>

#65026: Hide plugin search form on Favorites tab
--------------------------+--------------------------
 Reporter:  bor0          |       Owner:  westonruter
     Type:  defect (bug)  |      Status:  reviewing
 Priority:  normal        |   Milestone:  7.1
Component:  Plugins       |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  ui
--------------------------+--------------------------
Changes (by westonruter):

 * owner:  (none) => westonruter
 * status:  new => reviewing
 * milestone:  Awaiting Review => 7.1


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65026#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 06:25:52 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 06:25:52 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.3305dcd66152605656915bd6b85e99db@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
-------------------------------------+-------------------------------------
 Reporter:  piyushpatel123           |       Owner:  audrasjb
     Type:  defect (bug)             |      Status:  accepted
 Priority:  normal                   |   Milestone:  7.0
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  needs-testing has-patch  |     Focuses:  ui, css,
  admin-reskin                       |  administration
-------------------------------------+-------------------------------------
Changes (by ugyensupport):

 * keywords:  has-patch admin-reskin => needs-testing has-patch admin-reskin


Comment:

 == User Edit Screen Displays Misaligned Password Dashicon in WordPress
 7.0-RC2
 === Description
 An alignment issue has been identified with the password dashicon on the
 user edit screen in WordPress 7.0-RC2.

 Patch tested: REPLACE_WITH_PATCH_URL

 === Environment
 - WordPress: 7.0-RC2
 - PHP: 8.2.28
 - Server: nginx/1.21.4
 - Database: mysqli (Server: 5.7.44-log / Client: mysqlnd 8.2.28)
 - Browser: Chrome 146.0.0.0
 - OS: macOS
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None activated
 - Plugins:
   * Gutenberg 22.9.0
   * Test Reports 1.2.1
   * WordPress Beta Tester 4.0.0
   * wpDataTables 7.3.4
   * WP File Manager 8.0.3

 === Actual Results
 1.  ✅ Issue resolved with patch https://github.com/WordPress/wordpress-
 develop/pull/11463/changes


 === Supplemental Artifacts
 Before: [[Image(https://i.postimg.cc/s2kr05DG/Before.jpg)]]
 After: [[Image(https://jumpshare.com/s/U0FG0DUD39v3kTyLSuRx)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 06:42:08 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 06:42:08 -0000
Subject: [wp-trac] [WordPress Trac] #59588: False returned instead of
 default value on get_option with failure of unserializing data.
In-Reply-To: <052.191e4045ab80c485c18bb44c11b94417@wordpress.org>
References: <052.191e4045ab80c485c18bb44c11b94417@wordpress.org>
Message-ID: <067.12c8d3444a53d6c8f618addfc9f6ec2f@wordpress.org>

#59588: False returned instead of default value on get_option with failure of
unserializing data.
--------------------------------------+------------------------------
 Reporter:  cweberDC                  |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  Widgets                   |     Version:  6.3.2
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+------------------------------

Comment (by kalpeshh):

 I've created a patch for this issue.

 The fix saves the raw DB value before calling `maybe_unserialize()`, then
 checks if unserialization failed (result is `false`, value was serialized,
 and value is not `b:0;` — the valid serialization of boolean `false`). In
 that case, `$default_value` is returned instead.

 Two tests are included: one for corrupted serialized data returning the
 default, and one confirming a legitimately stored `false` still returns
 `false`.

 PR: https://github.com/WordPress/wordpress-develop/pull/11500

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59588#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 06:42:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 06:42:13 -0000
Subject: [wp-trac] [WordPress Trac] #65030: Customize:
 `isLinkPreviewable()` regex overrides `customize_allowed_urls` filter for
 sites with `/wp-content/` in home URL
In-Reply-To: <052.c9ae259fa333dbfc488d81cc1aa9e24e@wordpress.org>
References: <052.c9ae259fa333dbfc488d81cc1aa9e24e@wordpress.org>
Message-ID: <067.e4d62543814d4e5aa0fdc13267fd2e53@wordpress.org>

#65030: Customize: `isLinkPreviewable()` regex overrides `customize_allowed_urls`
filter for sites with `/wp-content/` in home URL
-----------------------------------------+--------------------------
 Reporter:  abhi3315                     |       Owner:  westonruter
     Type:  defect (bug)                 |      Status:  accepted
 Priority:  normal                       |   Milestone:  7.1
Component:  Customize                    |     Version:
 Severity:  normal                       |  Resolution:
 Keywords:  has-patch changes-requested  |     Focuses:  javascript
-----------------------------------------+--------------------------
Changes (by westonruter):

 * keywords:  has-patch => has-patch changes-requested
 * owner:  (none) => westonruter
 * version:  6.9.4 =>
 * status:  new => accepted
 * milestone:  Awaiting Review => 7.1


Comment:

 I can see this would be a problem, although it seems very uncommon.

 Really, the approach was wrong to begin with in how the `wp-admin`, `wp-
 includes`, and `wp-content` paths are hard-coded. Really, these should be
 exported from PHP to JS, using an approach similar to what can be seen in
 the Speculative Loading functionality. See
 `\WP_URL_Pattern_Prefixer::get_default_contexts()`. So we should be
 obtaining the paths from `admin_url()`, `plugins_url()`, and
 `content_url()`, for example. This would be a more robust way to prevent
 navigations to URLs that aren't served by WP.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65030#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 06:45:54 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 06:45:54 -0000
Subject: [wp-trac] [WordPress Trac] #64944: Generated Excerpts - Missing
 white space when stripping <br>s generated in paragraph block, verse block,
 etc.
In-Reply-To: <055.8505625efe4ec85c57d03df6fb669dac@wordpress.org>
References: <055.8505625efe4ec85c57d03df6fb669dac@wordpress.org>
Message-ID: <070.413b5e38e8fcd67b56cba20a880b5ba6@wordpress.org>

#64944: Generated Excerpts - Missing white space when stripping <br>s generated in
paragraph block, verse block, etc.
--------------------------------------+-----------------------
 Reporter:  addiestavlo               |       Owner:  audrasjb
     Type:  defect (bug)              |      Status:  accepted
 Priority:  normal                    |   Milestone:  7.1
Component:  Formatting                |     Version:  5.0
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-----------------------
Changes (by gaisma22):

 * keywords:  has-patch has-unit-tests needs-testing => has-patch has-unit-
     tests


Comment:

 == Patch Testing Report
 Patch Tested: https://github.com/WordPress/wordpress-develop/pull/11352

 === Environment
 - WordPress: 7.0-beta6-62085-src
 - PHP: 8.3.30
 - Server: nginx/1.29.7
 - Database: MySQL 8.4.8
 - Browser: Brave
 - OS: Ubuntu 24.04
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None
 - Plugins: None

 === Steps Taken
 1. Created a new post using a Verse block with three lines
    separated by Enter.
 2. Published without a custom excerpt.
 3. Checked the generated excerpt via the REST API at
    `/wp-json/wp/v2/posts/6`.
    **Before patch:** Words from adjacent lines were stuck together
    with no spaces. e.g. "this is line onethis is line two"
 4. Created a new post with the same steps after applying PR #11352.
    Checked `/wp-json/wp/v2/posts/9`.
    **After patch:** Words are correctly separated by spaces.
    e.g. "this is line one this is line two this is line three"

 ✅ Patch is solving the problem

 === Expected Result
 When WordPress generates an automatic excerpt from a post using a Verse
 block or Paragraph block with shift+enter line breaks, words from adjacent
 lines should be separated by spaces.

 === Additional Notes
 1. Bug confirmed on WordPress 7.0-beta6. The br tags in Verse
    block content were stripped without preserving word boundaries,
    causing words from adjacent lines to concatenate in the
    generated excerpt.
 2. Removing **`needs-testing`** as patch resolves the issue on
    WordPress 7.0-beta6-62085-src.

 === Screenshots/Screencast with results
 **Before Patch:**
 [[Image(https://i.ibb.co/60Q5zz13/before-excerpt.png)]]

 **After Patch:**
 [[Image(https://i.ibb.co/j9jNbKWZ/after-excerpt.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64944#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 06:54:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 06:54:14 -0000
Subject: [wp-trac] [WordPress Trac] #65045: Duplicate 'Comment' entry in
 trashableTypes array in wp/api.js
Message-ID: <062.6a6382486f0ae31cacfe346576196e85@wordpress.org>

#65045: Duplicate 'Comment' entry in trashableTypes array in wp/api.js
-------------------------------------------------+-------------------------
 Reporter:  baikare.sandeep007                   |      Owner:  (none)
     Type:  defect (bug)                         |     Status:  new
 Priority:  normal                               |  Milestone:  Awaiting
                                                 |  Review
Component:  REST API                             |    Version:  trunk
 Severity:  normal                               |   Keywords:  has-patch
  Focuses:  javascript, rest-api, coding-        |
  standards                                      |
-------------------------------------------------+-------------------------
 While reviewing the file `src/js/_enqueues/wp/api.js`, I noticed that the
 `trashableTypes` array contains a duplicate entry for 'Comment'.

 Current code:
 trashableTypes = [ 'Comment', 'Media', 'Post', 'Page', 'Status',
 'Taxonomy', 'Type' ];

 The presence of duplicate values in this array is unnecessary and may lead
 to redundant checks or confusion during maintenance.

 Proposed fix:
 Remove the duplicate 'Comment' entry to ensure the array contains only
 unique values.

 This change improves code clarity and avoids potential redundancy in logic
 that relies on this array.


 == Steps to reproduce

 1. Navigate to src/js/_enqueues/wp/api.js
 2. Locate the trashableTypes array
 3. Observe duplicate 'Comment' entry

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65045>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 06:56:35 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 06:56:35 -0000
Subject: [wp-trac] [WordPress Trac] #65045: Duplicate 'Comment' entry in
 trashableTypes array in wp/api.js
In-Reply-To: <062.6a6382486f0ae31cacfe346576196e85@wordpress.org>
References: <062.6a6382486f0ae31cacfe346576196e85@wordpress.org>
Message-ID: <077.a27dd864f07abb0ff07a2f30c6e20fad@wordpress.org>

#65045: Duplicate 'Comment' entry in trashableTypes array in wp/api.js
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  (none)
  baikare.sandeep007     |
     Type:  defect       |      Status:  new
  (bug)                  |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  REST API     |     Version:  trunk
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  javascript, rest-api, coding-
                         |  standards
-------------------------+-------------------------------------------------
Changes (by baikare.sandeep007):

 * Attachment "trashable-types-fix.patch" added.

 A patch will be attached to remove the duplicate entry.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65045>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 06:57:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 06:57:07 -0000
Subject: [wp-trac] [WordPress Trac] #65045: Duplicate 'Comment' entry in
 trashableTypes array in wp/api.js
In-Reply-To: <062.6a6382486f0ae31cacfe346576196e85@wordpress.org>
References: <062.6a6382486f0ae31cacfe346576196e85@wordpress.org>
Message-ID: <077.e2ce508ccaa87fe83d79d51dfc58cab3@wordpress.org>

#65045: Duplicate 'Comment' entry in trashableTypes array in wp/api.js
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  (none)
  baikare.sandeep007     |
     Type:  defect       |      Status:  new
  (bug)                  |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  REST API     |     Version:  trunk
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  javascript, rest-api, coding-
                         |  standards
-------------------------+-------------------------------------------------
Changes (by baikare.sandeep007):

 * Attachment "trashable-types-fix.2.patch" added.

 A patch will be attached to remove the duplicate entry.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65045>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 07:10:38 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 07:10:38 -0000
Subject: [wp-trac] [WordPress Trac] #65046: get_weekstartend() has swapped
 variable names and comments for month and day
Message-ID: <057.a04ab5ef592944628bef1cd9cd93c2e5@wordpress.org>

#65046: get_weekstartend() has swapped variable names and comments for month and
day
---------------------------+-------------------------------------
 Reporter:  saratheonline  |      Owner:  saratheonline
     Type:  defect (bug)   |     Status:  assigned
 Priority:  normal         |  Milestone:  Awaiting Review
Component:  Date/Time      |    Version:  trunk
 Severity:  normal         |   Keywords:  has-patch needs-testing
  Focuses:                 |
---------------------------+-------------------------------------
 In `get_weekstartend()` (src/wp-includes/functions.php), the variable
 names
   and comments for month and day are swapped, making the code misleading
 and
   a maintenance risk.

   For a MySQL date string like "2024-12-15":
   - Position 5-6 = "12" (month)
   - Position 8-9 = "15" (day)

   But the current code does the opposite:

       // MySQL string month.
       $mm = substr( $mysqlstring, 8, 2 ); // actually extracts the day

       // MySQL string day.
       $md = substr( $mysqlstring, 5, 2 ); // actually extracts the month

   The result of mktime() is accidentally correct because the two errors
 cancel
   each other out, but anyone reading or maintaining this code would be
 confused
   — or worse, "fix" the variable names without updating mktime() and
 introduce
   a real bug.

   == Proposed Fix ==

       // MySQL string month.
       $mm = substr( $mysqlstring, 5, 2 );

       // MySQL string day.
       $md = substr( $mysqlstring, 8, 2 );

       // The timestamp for MySQL string day.
       $day = mktime( 0, 0, 0, $mm, $md, $my );

   This makes the variable names, comments, substr positions, and mktime()
   argument order all consistent. The output is identical.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65046>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 07:20:32 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 07:20:32 -0000
Subject: [wp-trac] [WordPress Trac] #63909: Automatic excerpts: support
 lists in addition to columns and groups
In-Reply-To: <051.082bb765fdfdf1bd63d2da2e3006ba4a@wordpress.org>
References: <051.082bb765fdfdf1bd63d2da2e3006ba4a@wordpress.org>
Message-ID: <066.c58c30bf0ff18d0d47d139df3ebfeaf2@wordpress.org>

#63909: Automatic excerpts: support lists in addition to columns and groups
--------------------------------------+-----------------------
 Reporter:  jeherve                   |       Owner:  audrasjb
     Type:  defect (bug)              |      Status:  accepted
 Priority:  normal                    |   Milestone:  7.1
Component:  Editor                    |     Version:  5.8
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-----------------------
Changes (by gaisma22):

 * keywords:  has-patch has-unit-tests needs-testing => has-patch has-unit-
     tests


Comment:

 == Patch Testing Report
 Patch Tested: https://github.com/WordPress/wordpress-develop/pull/9704

 === Environment
 - WordPress: 7.0-beta6-62085-src
 - PHP: 8.3.30
 - Server: nginx/1.29.7
 - Database: MySQL 8.4.8
 - Browser: Brave
 - OS: Ubuntu 24.04
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None
 - Plugins: None

 === Steps Taken
 1. Created a new post using a List block with three items.
 2. Published without a custom excerpt.
 3. Checked the generated excerpt via the REST API at
    /wp-json/wp/v2/posts/13.
    **Before patch:** excerpt.rendered was completely empty.
    List content was not pulled into the excerpt at all.
 4. Applied PR #9704 and created a new post with the same steps.
    Checked /wp-json/wp/v2/posts/15.
    **After patch:** List items appear correctly in the excerpt.

 ✅ Patch is solving the problem

 === Expected Result
 When WordPress generates an automatic excerpt from a post using a List
 block, the list item content should be included in the generated excerpt.

 === Additional Notes
 1. Bug confirmed on WordPress 7.0-beta6. List block content was
    completely ignored when generating automatic excerpts.
 2. After the patch, list content is correctly extracted and
    included in the excerpt.
 3. Removing **`needs-testing`** as patch resolves the issue on
    WordPress 7.0-beta6-62085-src.

 === Screenshots/Screencast with results
 **Before Patch:**
 [[Image(https://i.ibb.co/P7tcttk/before-excerpt.png)]]

 **After Patch:**
 [[Image(https://i.ibb.co/LXRLsr17/after-excerpt.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63909#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 07:20:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 07:20:44 -0000
Subject: [wp-trac] [WordPress Trac] #64999: Admin reskin: Form elements
 are not standardized in the mobile viewport.
In-Reply-To: <053.6afa9d79ed563c578a97c68f2ee8cfe3@wordpress.org>
References: <053.6afa9d79ed563c578a97c68f2ee8cfe3@wordpress.org>
Message-ID: <068.162a5348d60afb574989641e860a09e1@wordpress.org>

#64999: Admin reskin: Form elements are not standardized in the mobile viewport.
------------------------------------+------------------------------
 Reporter:  wildworks               |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  General                 |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  admin-reskin has-patch  |     Focuses:
------------------------------------+------------------------------

Comment (by abcd95):

 https://core.trac.wordpress.org/browser/trunk/src/wp-admin/css/customize-
 widgets.css#L572

 This element has `height: 39px,` but it lives inside `@media screen and
 (max-height: 700px)` and `(min-width: 981px)` so that's most probably a
 compact mode for small-screen desktops/laptops, not the mobile breakpoint.
 So just wante to confirm if its intentional compact sizing and out of
 scope for this ticket or not.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64999#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 07:22:11 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 07:22:11 -0000
Subject: [wp-trac] [WordPress Trac] #65046: get_weekstartend() has
 swapped variable names and comments for month and day
In-Reply-To: <057.a04ab5ef592944628bef1cd9cd93c2e5@wordpress.org>
References: <057.a04ab5ef592944628bef1cd9cd93c2e5@wordpress.org>
Message-ID: <072.186f41bc0dc748e6ed0108aed17feca7@wordpress.org>

#65046: get_weekstartend() has swapped variable names and comments for month and
day
-------------------------------------+------------------------------
 Reporter:  saratheonline            |       Owner:  saratheonline
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Date/Time                |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+------------------------------

Comment (by saratheonline):

 Pull request: https://github.com/WordPress/wordpress-develop/pull/11504

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65046#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 07:36:36 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 07:36:36 -0000
Subject: [wp-trac] [WordPress Trac] #52976: user emails comparison
 should be case insensitive
In-Reply-To: <050.7727b644129a97f4082fdf76cb8aa740@wordpress.org>
References: <050.7727b644129a97f4082fdf76cb8aa740@wordpress.org>
Message-ID: <065.5b842c9c2a849510d9301d42d18a19c1@wordpress.org>

#52976: user emails comparison should be case insensitive
-------------------------------------+-------------------------------------
 Reporter:  asaifm                   |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Users                    |     Version:  4.3
 Severity:  normal                   |  Resolution:
 Keywords:  good-first-bug has-      |     Focuses:  administration,
  patch has-screenshots has-unit-    |  coding-standards
  tests                              |
-------------------------------------+-------------------------------------
Changes (by gaurangsondagar):

 * focuses:   => administration, coding-standards


Comment:

 Tested the patch:
 https://core.trac.wordpress.org/attachment/ticket/52976/52976.2.diff

 Environment:
 - WordPress: 7.0-RC2
 - PHP: 8.3.30
 - Browser: Chrome
 - Database: MySQL 8.4.8
 - OS: Ubuntu

 Testing Method:
 - Update the user's email from user at example.com to different case
 variations such as:
   - USER at example.com
   - User at example.com
   - User at example.com
 - Check if an email notification is triggered for this change
 - Apply the patch
 - Repeat the same steps with the above variations
 - Verify that no email notification is triggered after applying the patch

 Also tested programmatically using the wp_update_user() function, and it
 behaves as expected.

 Result:
 This confirms that the patch resolves the issue. If the update only
 modifies the letter case, it should not trigger any notification.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/52976#comment:20>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 07:45:19 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 07:45:19 -0000
Subject: [wp-trac] [WordPress Trac] #65020: Connectors: Support custom
 plugin is_active callback in connector registry and plugin status output
In-Reply-To: <055.d405075069acea8d9ef2197fb71ff599@wordpress.org>
References: <055.d405075069acea8d9ef2197fb71ff599@wordpress.org>
Message-ID: <070.569d22e4a730bbfb68b5c4a686782fd4@wordpress.org>

#65020: Connectors: Support custom plugin is_active callback in connector registry
and plugin status output
--------------------------+------------------------------
 Reporter:  iamadisingh   |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  AI            |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  dev-feedback  |     Focuses:
--------------------------+------------------------------
Changes (by gaisma22):

 * keywords:  needs-testing has-patch => dev-feedback


Comment:

 No patch file or PR is attached to this ticket. The description contains
 code snippets but nothing that can be applied or tested. Removing **`has-
 patch`** and **`needs-testing`**. Adding **`dev-feedback`** as the changes
 need review from a developer with commit access first.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65020#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 08:10:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 08:10:57 -0000
Subject: [wp-trac] [WordPress Trac] #65045: Duplicate 'Comment' entry in
 trashableTypes array in wp/api.js
In-Reply-To: <062.6a6382486f0ae31cacfe346576196e85@wordpress.org>
References: <062.6a6382486f0ae31cacfe346576196e85@wordpress.org>
Message-ID: <077.3c48b404973a2ce0a9cac1d624ed4a7c@wordpress.org>

#65045: Duplicate 'Comment' entry in trashableTypes array in wp/api.js
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  (none)
  baikare.sandeep007     |
     Type:  defect       |      Status:  new
  (bug)                  |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  REST API     |     Version:  trunk
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  javascript, rest-api, coding-
                         |  standards
-------------------------+-------------------------------------------------

Comment (by gaurangsondagar):

 Tested patch: https://core.trac.wordpress.org/attachment/ticket/65045
 /trashable-types-fix.patch

 Steps I followed:
 - Located the 'trashableTypes' array in 'wp/api.js' and confirmed the
 duplicate 'Comment' entry.
 - Applied the patch and verified the duplicate entry has been removed.
 - Tested comment trash, restore, and delete actions from the admin panel.
 - Confirmed no JavaScript errors and no regressions in functionality.

 Environment:
 - WordPress: 7.1-alpha-62161-src
 - PHP: 8.3.30
 - Browser: Chrome
 - Database: MySQL 8.4.8
 - OS: Ubuntu

 As this is a minor code duplication issue with no visible UI impact, the
 fix improves code clarity without affecting behavior.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65045#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 08:23:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 08:23:33 -0000
Subject: [wp-trac] [WordPress Trac] #65038: Shortcode block adds empty
 <p> tags around block output in widget/footer areas
In-Reply-To: <052.bfb40169a8ed2a0ceb94e4a0c088e9f5@wordpress.org>
References: <052.bfb40169a8ed2a0ceb94e4a0c088e9f5@wordpress.org>
Message-ID: <067.2054f827a5c52bfff942fbbd4e9c9928@wordpress.org>

#65038: Shortcode block adds empty <p> tags around block output in widget/footer
areas
-----------------------------+------------------------------
 Reporter:  frauinga         |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  General          |     Version:  6.9.4
 Severity:  normal           |  Resolution:
 Keywords:  has-screenshots  |     Focuses:
-----------------------------+------------------------------

Comment (by wildworks):

 Thanks for the report. I think the fundamental issue is that the HTML
 output by shortcodes is always wrapped in a `P` element, which I believe
 is the same problem reported in #62694.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65038#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 08:25:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 08:25:26 -0000
Subject: [wp-trac] [WordPress Trac] #65018: WordPress Post Edit Screen
 Content Overflow Issue in version 7.0 RC2
In-Reply-To: <055.e55fb8bae717ff9f69325eb98e7f0c10@wordpress.org>
References: <055.e55fb8bae717ff9f69325eb98e7f0c10@wordpress.org>
Message-ID: <070.7052c3f768aa4a7a9d3c73f4532962fa@wordpress.org>

#65018: WordPress Post Edit Screen Content Overflow Issue in version 7.0 RC2
-------------------------------------+------------------------------
 Reporter:  Pratik Jain              |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch has-test-info  |     Focuses:  ui, css
-------------------------------------+------------------------------

Comment (by gaisma22):

 == Patch Testing Report
 Patch Tested: https://github.com/WordPress/wordpress-develop/pull/11437

 === Environment
 - WordPress: 7.0-beta6-62085-src
 - PHP: 8.3.30
 - Server: nginx/1.29.7
 - Database: MySQL 8.4.8
 - Browser: Brave
 - OS: Ubuntu 24.04
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None
 - Plugins: Classic Editor 1.6.7

 === Steps Taken
 1. Went to Posts > Add New on the classic editor screen.
 2. Observed the layout below the page heading.
    **Before patch:** Content area overflows its container,
    visible as a red line on the left edge.
 3. Applied PR #11437 and hard refreshed.
    **After patch:** Red line gone. Layout looks correct.

 ✅ Patch is solving the problem

 === Expected Result
 The post edit screen content area should sit within its container with no
 horizontal overflow.

 === Additional Notes
 1. Bug confirmed on WordPress 7.0-beta6 on the classic
    post edit screen.
 2. Classic Editor plugin was required to reproduce the issue
    since the block editor does not show the same layout.


 === Screenshots/Screencast with results
 **Before Patch:**
 [[Image(https://i.ibb.co/x0Lp3Hw/before-overflow.png)]]

 **After Patch:**
 [[Image(https://i.ibb.co/tw1hvPJG/after-overflow.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65018#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 08:37:40 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 08:37:40 -0000
Subject: [wp-trac] [WordPress Trac] #45354: Adding index for meta_key
 and post_id in postmeta
In-Reply-To: <056.ed0283820e92025f40a31fbe52b0dd88@wordpress.org>
References: <056.ed0283820e92025f40a31fbe52b0dd88@wordpress.org>
Message-ID: <071.4d3e49bfe6cbfa426381f4d0d4ed43e8@wordpress.org>

#45354: Adding index for meta_key and post_id in postmeta
-------------------------------------------------+-------------------------
 Reporter:  DuckDagobert                         |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  7.1
Component:  Database                             |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  needs-testing dev-feedback has-      |     Focuses:
  patch has-unit-tests                           |  performance
-------------------------------------------------+-------------------------
Changes (by westonruter):

 * milestone:  Awaiting Review => 7.1


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/45354#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 08:51:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 08:51:29 -0000
Subject: [wp-trac] [WordPress Trac] #65038: Shortcode block adds empty
 <p> tags around block output in widget/footer areas
In-Reply-To: <052.bfb40169a8ed2a0ceb94e4a0c088e9f5@wordpress.org>
References: <052.bfb40169a8ed2a0ceb94e4a0c088e9f5@wordpress.org>
Message-ID: <067.37766857c3f00317e972b7dcaaeec9b3@wordpress.org>

#65038: Shortcode block adds empty <p> tags around block output in widget/footer
areas
-----------------------------+------------------------
 Reporter:  frauinga         |       Owner:  (none)
     Type:  defect (bug)     |      Status:  closed
 Priority:  normal           |   Milestone:
Component:  General          |     Version:  6.9.4
 Severity:  normal           |  Resolution:  duplicate
 Keywords:  has-screenshots  |     Focuses:
-----------------------------+------------------------
Changes (by wildworks):

 * status:  new => closed
 * resolution:   => duplicate
 * milestone:  Awaiting Review =>


Comment:

 Duplicate of #62694.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65038#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 10:05:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 10:05:09 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2364962=3A_Install_scr?=
 =?utf-8?b?ZWVuczog4oCcTG9nIElu4oCdIGFuZCAiU3VwcG9ydCBsaW5rIiB1c2Ugb2xk?=
 =?utf-8?q?_color?=
In-Reply-To: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
References: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
Message-ID: <074.1382e23435356f86821b8fb9940342ae@wordpress.org>

#64962: Install screens: “Log In” and "Support link" use old color
-------------------------------------------------+-------------------------
 Reporter:  huzaifaalmesbah                      |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch has-          |     Focuses:  ui, css
  screenshots changes-requested                  |
-------------------------------------------------+-------------------------

Comment (by ismail0071):

 Tested locally — link colors now match the new admin design system. “Log
 In” and support links are consistent with other admin styles. Overall,
 looks good.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64962#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 10:08:52 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 10:08:52 -0000
Subject: [wp-trac] [WordPress Trac] #65047: Missing escaping for XML error
 message
Message-ID: <055.114e593d87c6f2e3617a84cdf8f35483@wordpress.org>

#65047: Missing escaping for XML error message
------------------------------+-----------------------------
 Reporter:  maheshpatel       |      Owner:  (none)
     Type:  defect (bug)      |     Status:  new
 Priority:  normal            |  Milestone:  Awaiting Review
Component:  Pings/Trackbacks  |    Version:  trunk
 Severity:  normal            |   Keywords:
  Focuses:                    |
------------------------------+-----------------------------
 **File:** [src/wp-trackback.php](src/wp-trackback.php#L37)
 - **Line:** 37
 - **Problem:** `$error_message` output in XML without escaping
 - **Severity:** XML parsing vulnerability
 - **Current Code:**


   if ( $error ) {
       echo '<?xml version="1.0" encoding="utf-8"?' . ">\n";
       echo "<response>\n";
       echo "<error>1</error>\n";
       echo "<message>$error_message</message>\n";
       echo '</response>';
   }


 - **Fix:**


   if ( $error ) {
       echo '<?xml version="1.0" encoding="utf-8"?' . ">\n";
       echo "<response>\n";
       echo "<error>1</error>\n";
       echo "<message>" . esc_html ( $error_message ) . "</message>\n";
       echo '</response>';
   }


 - **Why It Matters:**
   - XML special characters (`&`, `<`, `>`) can break XML parsing
   - Error messages come from user actions or system states

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65047>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 10:09:59 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 10:09:59 -0000
Subject: [wp-trac] [WordPress Trac] #65048: wp_ajax_fetch_list(): Sanitize
 $_GET input before nonce construction
Message-ID: <052.ec9b36b226893b34c604b6419cd46f00@wordpress.org>

#65048: wp_ajax_fetch_list(): Sanitize $_GET input before nonce construction
----------------------------+-------------------------------------
 Reporter:  rajeshcp        |      Owner:  rajeshcp
     Type:  defect (bug)    |     Status:  assigned
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Administration  |    Version:  trunk
 Severity:  critical        |   Keywords:  has-patch needs-testing
  Focuses:                  |
----------------------------+-------------------------------------
 In wp_ajax_fetch_list() (wp-admin/includes/ajax-actions.php), raw $_GET
 data is read without an existence check or sanitization before being used
 to construct the nonce action string and passed to _get_list_table().

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65048>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 10:10:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 10:10:57 -0000
Subject: [wp-trac] [WordPress Trac] #65005: Next/Previous for datepicker
 needs context
In-Reply-To: <052.e7c5ffd7379c8e33f54d240e729da31e@wordpress.org>
References: <052.e7c5ffd7379c8e33f54d240e729da31e@wordpress.org>
Message-ID: <067.1b427beb99bde265420bea79b8a7b3cd@wordpress.org>

#65005: Next/Previous for datepicker needs context
-------------------------------------------------+-------------------------
 Reporter:  timse201                             |       Owner:
                                                 |  SergeyBiryukov
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  I18N                                 |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch commit dev-reviewed i18n-  |     Focuses:
  change                                         |
-------------------------------------------------+-------------------------

Comment (by audrasjb):

 Hello and thank you @mdhori15 but this is already fixed in trunk by this
 changeset: [62188].
 Now we only need to backport this changeset to branch 7.0 and this doesn't
 require a new patch :)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65005#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 10:12:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 10:12:56 -0000
Subject: [wp-trac] [WordPress Trac] #65049: Templates: Add date field
Message-ID: <054.45728328379eda370a00123ba3914847@wordpress.org>

#65049: Templates: Add date field
-------------------------+-----------------------
 Reporter:  ntsekouras   |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  7.1
Component:  REST API     |    Version:
 Severity:  normal       |   Keywords:  has-patch
  Focuses:               |
-------------------------+-----------------------
 Backports: https://github.com/WordPress/gutenberg/pull/77134


 This PR adds the `date` field in templates and template parts. This will
 help with the simplification of revisions handling for these post types,
 as there is a lot of scattered code around that working around the fact
 that they expose only the `modified` date.

 ## Testing Instructions
 1. `date` field should be returned through REST API
 2. everything should work exactly as before - especially the
 templates/template parts flows since the change affects only them.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65049>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 10:12:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 10:12:56 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.2fc378f8d9b7e6e0b3183a33216d0f16@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
-------------------------------------+-------------------------------------
 Reporter:  piyushpatel123           |       Owner:  audrasjb
     Type:  defect (bug)             |      Status:  accepted
 Priority:  normal                   |   Milestone:  7.0
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  needs-testing has-patch  |     Focuses:  ui, css,
  admin-reskin                       |  administration
-------------------------------------+-------------------------------------

Comment (by abduremon):

 Tested the patch in the mentioned environment. Alignment has improved and
 spacing looks better, but it’s still slightly off-center. A small
 adjustment is needed to achieve perfect centering.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 10:13:24 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 10:13:24 -0000
Subject: [wp-trac] [WordPress Trac] #65047: Missing escaping for XML
 error message
In-Reply-To: <055.114e593d87c6f2e3617a84cdf8f35483@wordpress.org>
References: <055.114e593d87c6f2e3617a84cdf8f35483@wordpress.org>
Message-ID: <070.5c8aaf82cd40da127804e0fbb3c8ac68@wordpress.org>

#65047: Missing escaping for XML error message
------------------------------+------------------------------
 Reporter:  maheshpatel       |       Owner:  (none)
     Type:  defect (bug)      |      Status:  new
 Priority:  normal            |   Milestone:  Awaiting Review
Component:  Pings/Trackbacks  |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+------------------------------

Comment (by maheshpatel):

 This issue has been resolved and generated PR
 PR - https://github.com/WordPress/wordpress-develop/pull/11527

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65047#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 10:18:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 10:18:03 -0000
Subject: [wp-trac] [WordPress Trac] #65050: REST API: Comments controller
 returns 403 instead of 404 for invalid post ID in update_item()
Message-ID: <057.d01cd307fcdefb847d0c0d7b8f496018@wordpress.org>

#65050: REST API: Comments controller returns 403 instead of 404 for invalid post
ID in update_item()
---------------------------+-------------------------------------
 Reporter:  saratheonline  |      Owner:  saratheonline
     Type:  defect (bug)   |     Status:  assigned
 Priority:  normal         |  Milestone:  Awaiting Review
Component:  REST API       |    Version:  trunk
 Severity:  normal         |   Keywords:  has-patch needs-testing
  Focuses:                 |
---------------------------+-------------------------------------
 In `WP_REST_Comments_Controller`, the `update_item()` method returns HTTP
   403 (Forbidden) when an invalid post ID is provided, but the correct
 status
   code is 404 (Not Found).

   The same file returns 404 for the identical scenario in `get_item()`
   (line 418), making this inconsistent within the same controller.

   403 implies the client lacks permission. 404 is correct here because
   the post does not exist — it is a missing resource, not an authorization
   failure.

   == Affected code (class-wp-rest-comments-controller.php) ==

 {{{
 if ( empty( $post ) ) {
     return new WP_Error(
         'rest_comment_invalid_post_id',
         __( 'Invalid post ID.' ),
         array( 'status' => 403 )  // incorrect
     );
 }
 }}}


   == Proposed Fix ==

 {{{
 array( 'status' => 404 )
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65050>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 10:23:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 10:23:44 -0000
Subject: [wp-trac] [WordPress Trac] #64853: Inconsistent Post Count in
 Category Taxonomy
In-Reply-To: <053.ece87b24efa5a106a4b3afbe8c18db50@wordpress.org>
References: <053.ece87b24efa5a106a4b3afbe8c18db50@wordpress.org>
Message-ID: <068.7150f9c5c12846f98290d1da55d1f9ab@wordpress.org>

#64853: Inconsistent Post Count in Category Taxonomy
------------------------------------+---------------------------------
 Reporter:  phunsanit               |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  General                 |     Version:  6.9.4
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:  ui, administration
------------------------------------+---------------------------------
Changes (by pratikmandaliya):

 * keywords:  has-patch needs-testing => has-patch dev-feedback


Comment:

 == Reproduction Report
 === Description
 ✅ This report validates the issue reproduced.

 === Environment
 - WordPress: 6.9.4
 - PHP: 8.3.30
 - Server: PHP.wasm
 - Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
 - Browser: Chrome 147.0.0.0
 - OS: Windows 10/11
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None activated
 - Plugins:
   * Test Reports 1.2.1

 === Step Follows
 1. Created a new category named “History”.
 2. Created one post, assigned it to the History category, and published
 it.
 3. Created another post, assigned it to the History category, and set its
 status to Scheduled (Future).
 4. Navigated to Posts > Categories and observed the post count column for
 the “History” category. The count displayed is 1. However, when clicking
 on the count, the post list shows 2 posts (1 Published + 1 Scheduled).


 === Actual Results
 1.  ✅ Error condition occurs (reproduced).

 === Additional Notes
 - Any additional details worth mentioning.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64853#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 10:25:20 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 10:25:20 -0000
Subject: [wp-trac] [WordPress Trac] #64853: Inconsistent Post Count in
 Category Taxonomy
In-Reply-To: <053.ece87b24efa5a106a4b3afbe8c18db50@wordpress.org>
References: <053.ece87b24efa5a106a4b3afbe8c18db50@wordpress.org>
Message-ID: <068.aa475353717dba85c884ae78efe4d519@wordpress.org>

#64853: Inconsistent Post Count in Category Taxonomy
------------------------------------+---------------------------------
 Reporter:  phunsanit               |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  General                 |     Version:  6.9.4
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:  ui, administration
------------------------------------+---------------------------------
Changes (by pratikmandaliya):

 * Attachment "Before.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64853>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 10:25:32 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 10:25:32 -0000
Subject: [wp-trac] [WordPress Trac] #64853: Inconsistent Post Count in
 Category Taxonomy
In-Reply-To: <053.ece87b24efa5a106a4b3afbe8c18db50@wordpress.org>
References: <053.ece87b24efa5a106a4b3afbe8c18db50@wordpress.org>
Message-ID: <068.4664c6f435ef2065cff5a3d7030a6e93@wordpress.org>

#64853: Inconsistent Post Count in Category Taxonomy
------------------------------------+---------------------------------
 Reporter:  phunsanit               |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  General                 |     Version:  6.9.4
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:  ui, administration
------------------------------------+---------------------------------
Changes (by pratikmandaliya):

 * Attachment "After.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64853>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 10:29:51 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 10:29:51 -0000
Subject: [wp-trac] [WordPress Trac] #65051: $_REQUEST['term'] used
 unsanitized in user search query
Message-ID: <052.48e93b7172e09acbd378dc6d127d732f@wordpress.org>

#65051: $_REQUEST['term'] used unsanitized in user search query
--------------------------+-------------------------------------
 Reporter:  rajeshcp      |      Owner:  rajeshcp
     Type:  defect (bug)  |     Status:  assigned
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  General       |    Version:  trunk
 Severity:  major         |   Keywords:  has-patch needs-testing
  Focuses:                |
--------------------------+-------------------------------------
 User-supplied search term is concatenated directly into the get_users()
 search argument without
   sanitize_text_field() or wp_unslash().

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65051>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 10:34:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 10:34:26 -0000
Subject: [wp-trac] [WordPress Trac] #65050: REST API: Comments
 controller returns 403 instead of 404 for invalid post ID in update_item()
In-Reply-To: <057.d01cd307fcdefb847d0c0d7b8f496018@wordpress.org>
References: <057.d01cd307fcdefb847d0c0d7b8f496018@wordpress.org>
Message-ID: <072.efb22bc23d87aa0f4cb37fccf8fda2ca@wordpress.org>

#65050: REST API: Comments controller returns 403 instead of 404 for invalid post
ID in update_item()
-------------------------------------+-------------------------------
 Reporter:  saratheonline            |       Owner:  saratheonline
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  REST API                 |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  coding-standards
-------------------------------------+-------------------------------
Changes (by gaurangsondagar):

 * focuses:   => coding-standards


Comment:

 Tested patch: https://github.com/WordPress/wordpress-develop/pull/11529

 Environment:
 - WordPress: 7.1-alpha-62161-src
 - PHP: 8.3.30
 - Browser: Chrome
 - Database: MySQL 8.4.8
 - OS: Ubuntu

 Steps I followed:
 - Confirmed that 'update_item()' in 'WP_REST_Comments_Controller' returns
 a 403 status when an invalid post ID is provided.
 - Verified that the same scenario in `get_item()` correctly returns a 404
 status.
 - This creates inconsistency within the same controller.

 Agree that 404 is the correct response here, as the post does not exist
 and this is not a permission issue.

 Tested the proposed fix and it resolves the issue as expected without
 introducing any regressions.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65050#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 10:51:27 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 10:51:27 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2364962=3A_Install_scr?=
 =?utf-8?b?ZWVuczog4oCcTG9nIElu4oCdIGFuZCAiU3VwcG9ydCBsaW5rIiB1c2Ugb2xk?=
 =?utf-8?q?_color?=
In-Reply-To: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
References: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
Message-ID: <074.4a42486cb04c0161e60123a5bcfcda4e@wordpress.org>

#64962: Install screens: “Log In” and "Support link" use old color
-------------------------------------------------+-------------------------
 Reporter:  huzaifaalmesbah                      |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch has-          |     Focuses:  ui, css
  screenshots changes-requested                  |
-------------------------------------------------+-------------------------

Comment (by vishitshah):

 Verified the updates in a local environment, and the revised link colors
 integrate well with the refreshed admin UI. The “Log In” and support links
 now follow a consistent styling pattern, enhancing visual clarity across
 the interface.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64962#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 10:54:51 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 10:54:51 -0000
Subject: [wp-trac] [WordPress Trac] #32507: Admin notices remove styling
 of lists
In-Reply-To: <056.670b8dae2adcf945919c73764f1bc013@wordpress.org>
References: <056.670b8dae2adcf945919c73764f1bc013@wordpress.org>
Message-ID: <071.dc54b0ffbaa9632e9fbc60206e0cfa90@wordpress.org>

#32507: Admin notices remove styling of lists
----------------------------+---------------------------------
 Reporter:  sciamannikoo    |       Owner:  (none)
     Type:  enhancement     |      Status:  new
 Priority:  normal          |   Milestone:
Component:  Administration  |     Version:  4.2.2
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:  ui, administration
----------------------------+---------------------------------
Changes (by atharvaa2001):

 * Attachment "trac-32507.patch" added.

 Restores list-style and margin-left for ul, ol, and li elements nested
 inside admin notices (.notice, div.updated, div.error). Fixes the issue
 where lists inside notices displayed without bullets or numbers due to the
 global ul { list-style: none } reset.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/32507>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 10:54:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 10:54:56 -0000
Subject: [wp-trac] [WordPress Trac] #65051: $_REQUEST['term'] used
 unsanitized in user search query
In-Reply-To: <052.48e93b7172e09acbd378dc6d127d732f@wordpress.org>
References: <052.48e93b7172e09acbd378dc6d127d732f@wordpress.org>
Message-ID: <067.a269ffe8d69447ee4898b909c39cd2af@wordpress.org>

#65051: $_REQUEST['term'] used unsanitized in user search query
-------------------------------------+-------------------------------
 Reporter:  rajeshcp                 |       Owner:  rajeshcp
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  General                  |     Version:  trunk
 Severity:  major                    |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  coding-standards
-------------------------------------+-------------------------------
Changes (by gaurangsondagar):

 * focuses:   => coding-standards


Comment:

 Tested the patch and confirmed the issue: https://github.com/WordPress
 /wordpress-
 develop/pull/11530/commits/5eed1c8ea50eb3dfda7605749f267bf9e3234dc3

 Environment:
 - WordPress: 7.1-alpha-62161-src
 - PHP: 8.3.30
 - Browser: Chrome
 - Database: MySQL 8.4.8
 - OS: Ubuntu


 1) The current implementation uses `$_REQUEST[term]` directly without
 sanitization.
 2) The patch correctly applies 'wp_unslash()' and 'sanitize_text_field()',
 which aligns with WordPress data handling standards.
 3) Verified that the user search functionality continues to work as
 expected after the change.

 This is a valid security improvement and works as expected

 Screenshot for reference: https://kommodo.ai/i/s2Bol19v4cwB50UNttQp

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65051#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 11:04:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 11:04:17 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2364962=3A_Install_scr?=
 =?utf-8?b?ZWVuczog4oCcTG9nIElu4oCdIGFuZCAiU3VwcG9ydCBsaW5rIiB1c2Ugb2xk?=
 =?utf-8?q?_color?=
In-Reply-To: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
References: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
Message-ID: <074.ce694a172b78b7fa5c98b449f6d50016@wordpress.org>

#64962: Install screens: “Log In” and "Support link" use old color
-------------------------------------------------+-------------------------
 Reporter:  huzaifaalmesbah                      |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch has-          |     Focuses:  ui, css
  screenshots changes-requested                  |
-------------------------------------------------+-------------------------

Comment (by mikinc860):

 The updates were successfully validated in a local environment, with the
 revised link colors aligning seamlessly with the refreshed admin UI. The
 **Log In** and support links now adhere to a consistent styling pattern,
 improving visual coherence and enhancing overall interface clarity.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64962#comment:17>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 11:04:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 11:04:22 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.a9d10e8df9d7b55c6e8264da4574c14f@wordpress.org>

#65015: Connectors: Several strings are not translated
--------------------------+----------------------
 Reporter:  369work       |       Owner:  (none)
     Type:  defect (bug)  |      Status:  closed
 Priority:  high          |   Milestone:  7.0
Component:  I18N          |     Version:
 Severity:  normal        |  Resolution:  wontfix
 Keywords:  needs-patch   |     Focuses:
--------------------------+----------------------
Changes (by desrosj):

 * keywords:  close has-patch => needs-patch
 * priority:  normal => high


Comment:

 I've been working with @manishxdp today at WordCamp Asia Contributor Day,
 and based on what we found this seems like a legitimate issue that needs
 to be addressed.

 As far as I can tell based on our investigation today, the normal practice
 for registering translations for a specific script is to call
 `wp_set_script_translations()` after the script is registered. This prints
 an inline, localized script with the translated strings so that `wp-i18n`
 can properly localize them.

 However, there does not appear to be an equivalent function for script
 ''modules''. I'm not clear on the history there and whether this is
 intentional or what the functional differences are between scripts and
 script modules, but it seems that a `set_translations()` method likely
 needs to be added to `WP_Script_Modules` so that strings within modules
 are properly localized and translated for the user.

 That change belongs here in `wordpress-develop` with the
 `wp_set_script_module_translations()` wrapper (see
 `wp_set_script_translations()`). However, a polyfill will need to be added
 to `gutenberg` to ensure it works in the plugin for users running
 `WP<7.0`. Then the template files in the `wp-build` package will need to
 be updated to call `wp_set_script_module_translations()`

 In talking with @westonruter, it seems this will be quite complicated
 because of how modules include files (directly and not typically
 registered as a script through WordPress). The strings for every
 dependency file needs to also be localized respecting the textdomain for
 each.

 I'm unclear how this is different than the previous issues reported above,
 but I don't believe that this will resolve itself in the same way.

 The surface area for this bug will be any registered script module that
 contains strings. For 7.0, this is primarily affecting the new admin pages
 registered through routes.

 I have changed this to a high priority issue because it seems that these
 strings will not be localized in WordPress 7.0 without resolving this gap.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 11:04:41 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 11:04:41 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.da781dff40482a6587400e6b00cfbdea@wordpress.org>

#65015: Connectors: Several strings are not translated
--------------------------+-----------------------
 Reporter:  369work       |       Owner:  (none)
     Type:  defect (bug)  |      Status:  reopened
 Priority:  high          |   Milestone:  7.0
Component:  I18N          |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+-----------------------
Changes (by desrosj):

 * status:  closed => reopened
 * resolution:  wontfix =>


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 11:24:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 11:24:39 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.224ef78cc4afe10c4a1aca516600f67a@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
--------------------------------------+-------------------------------
 Reporter:  jorgefilipecosta          |       Owner:  jorgefilipecosta
     Type:  feature request           |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.0
Component:  Plugins                   |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------------

Comment (by jorgefilipecosta):

 Replying to [comment:45 peterwilsoncc]:

 > Replying to [comment:41 matveb]:

 > > I'm a bit confused about the outcome. I agree, at this late stage, the
 connector should not show up when the plugin is not present in the WP
 install, but it should be displayed when it is, even if it's not
 activated.

 > >

 > > It's important to position connectors as not being exclusively for AI.
 Looking beyond, the connectors UI should show available connectors from
 any installed plugin, regardless of whether they are activated. Given
 Akismet is bundled by default, it should show up if the file is present
 for 7.0. It'd be odd to have the plugin present in plugins but not in
 connectors. For the next cycle, this should be formalized in plugin
 headers or some other broader mechanism.

 >

 >

 > Mobile, jetlgged, flight delays. Excuse typos

 >

 >

 > The Akismet team have added a connector to their plugin for the next
 release (mentioned in core-ai channel)

 >

 > An akismet API entry field will show up once the plugin is active and
 needed. I'm not sure what happened when both the plugin and core were
 registered the connectors

 >

 Hi @peterwilsoncc, I tried to address this point earlier in [comment:25].
 What we had works well with the latest released version of Akismet on the
 wp.org repo. The Akismet developers are aware of what is happening in core
 and will make sure things continue to work well together in future
 releases, independently of what is on the development branch now. It is
 totally fine for plugins to remove core registration and enhance it at the
 plugin level; AI providers can also do the same if, for example, they want
 to include credit information, etc.

 Hi @jorbin,

 > How does that help users? If anything it's going to create confusion
 since they may think that by having entered the key on the connectors
 screen they have activated akismet.

 I tried to address this point earlier in [comment:25]:

 > That's a good point that is worth addressing. The UI doesn't actually
 allow setting a key without activating the plugin first. What it does is
 let users activate the plugin directly from the connectors screen, without
 needing to navigate to the plugins screen, and then provide the key right
 away without any page reloads. So by the time the key is set, the plugin
 is already active.

 So this shouldn't create confusion. The user can activate the plugin and
 provide a key directly from the connectors screen, without any page
 reloads or needing to visit a separate settings page. If users think
 they've activated Akismet, they're correct: everything is ready to use,
 and the UI accurately reflects that.

 It's possible to test this flow on Playground:
 https://playground.wordpress.net/wordpress.html?pr=11460 (note: Akismet
 needs to be installed first in the Playground PR reviewer, as it does not
 bundle Akismet the way normal core does). I also recorded a
 [https://make.wordpress.org/core/files/2026/04/akismet-full-flow.mov video
 with the full flow].

 > Aditionally, the connectors screen should be about reusable connections.
 Besides akismet, which plugins currently make use of this key?

 My understanding is that the connectors screen is not exclusively about
 reusable connections. It is a central place that supports a set of common
 patterns for connecting to third-party services, even if a connection is
 only used by a single plugin. That said, in the specific case of Akismet,
 the key could actually be used by many third-party plugins, such as
 [https://lifterlms.com/blog/block-spam-increase-security/ LifterLMS],
 [https://wpmanageninja.com/docs/fluent-form/integrations-available-in-wp-
 fluent-form/wp-fluent-forms-akismet-integration/ Fluent Forms],
 [https://help.formassembly.com/help/464341-akismet-spam-filter Form
 Assembly], [https://formidableforms.com/knowledgebase/add-spam-protection
 /#kb-akismet Formidable Forms],
 [https://givewp.com/documentation/core/settings/advanced/akismet-spam-
 protection GiveWP], and some other services.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:47>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 12:49:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 12:49:29 -0000
Subject: [wp-trac] [WordPress Trac] #65051: $_REQUEST['term'] used
 unsanitized in user search query
In-Reply-To: <052.48e93b7172e09acbd378dc6d127d732f@wordpress.org>
References: <052.48e93b7172e09acbd378dc6d127d732f@wordpress.org>
Message-ID: <067.68c2e7d269ddf6e1ba9aa8692c8ebba8@wordpress.org>

#65051: $_REQUEST['term'] used unsanitized in user search query
--------------------------------+------------------------------------------
 Reporter:  rajeshcp            |       Owner:  rajeshcp
     Type:  defect (bug)        |      Status:  assigned
 Priority:  normal              |   Milestone:  7.1
Component:  Networks and Sites  |     Version:
 Severity:  normal              |  Resolution:
 Keywords:  has-patch needs-    |     Focuses:  multisite, coding-standards
  testing                       |
--------------------------------+------------------------------------------
Changes (by audrasjb):

 * focuses:  coding-standards => multisite, coding-standards
 * component:  General => Networks and Sites
 * severity:  major => normal
 * version:  trunk =>
 * milestone:  Awaiting Review => 7.1


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65051#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 13:06:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 13:06:03 -0000
Subject: [wp-trac] [WordPress Trac] #65052: Nonce check order flaw in
 post-quickdraft-save
Message-ID: <052.5cb71bdc8207e81444fff364e3bc4f57@wordpress.org>

#65052: Nonce check order flaw in post-quickdraft-save
--------------------------+-------------------------------------
 Reporter:  rajeshcp      |      Owner:  rajeshcp
     Type:  defect (bug)  |     Status:  assigned
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Security      |    Version:  trunk
 Severity:  major         |   Keywords:  has-patch needs-testing
  Focuses:                |
--------------------------+-------------------------------------
 $_REQUEST['post_ID'] is used to load a post object before the referer is
 actually checked on line 93. A
   crafted request can cause a database lookup on an arbitrary post_ID
 before authorization. $_REQUEST['_wpnonce'] is
   also accessed without checking key existence.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65052>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 13:12:38 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 13:12:38 -0000
Subject: [wp-trac] [WordPress Trac] #65028: no error message when
 installing connector if File system read only
In-Reply-To: <051.dba1e5b249ba8e02e154d12428f5633b@wordpress.org>
References: <051.dba1e5b249ba8e02e154d12428f5633b@wordpress.org>
Message-ID: <066.cd1eed9f6bdae98536ecbdecb9ba77ea@wordpress.org>

#65028: no error message when installing connector if File system read only
------------------------------------+--------------------------------
 Reporter:  pbearne                 |       Owner:  (none)
     Type:  defect (bug)            |      Status:  closed
 Priority:  normal                  |   Milestone:
Component:  AI                      |     Version:  trunk
 Severity:  normal                  |  Resolution:  reported-upstream
 Keywords:  connectors needs-patch  |     Focuses:
------------------------------------+--------------------------------
Changes (by JeffPaul):

 * keywords:  needs-patch => connectors needs-patch


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65028#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 13:13:36 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 13:13:36 -0000
Subject: [wp-trac] [WordPress Trac] #64960: Connectors: Allow custom env
 var and constant names for API key source detection
In-Reply-To: <060.b88a9f4b06cf0eb59248afb9feb72ee5@wordpress.org>
References: <060.b88a9f4b06cf0eb59248afb9feb72ee5@wordpress.org>
Message-ID: <075.1b36214313757a193d07f085793cd0e4@wordpress.org>

#64960: Connectors: Allow custom env var and constant names for API key source
detection
----------------------------------+---------------------
 Reporter:  jorgefilipecosta      |       Owner:  (none)
     Type:  task (blessed)        |      Status:  new
 Priority:  high                  |   Milestone:  7.0
Component:  AI                    |     Version:
 Severity:  normal                |  Resolution:
 Keywords:  connectors has-patch  |     Focuses:
----------------------------------+---------------------
Changes (by JeffPaul):

 * keywords:  has-patch => connectors has-patch


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64960#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 13:13:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 13:13:56 -0000
Subject: [wp-trac] [WordPress Trac] #64706: A single config option to
 disable all LLM related features
In-Reply-To: <057.5a6fad87789be36a76653e559056b566@wordpress.org>
References: <057.5a6fad87789be36a76653e559056b566@wordpress.org>
Message-ID: <072.e68c447f2915ccc97b6a0340adda60d9@wordpress.org>

#64706: A single config option to disable all LLM related features
------------------------------------------------+-------------------------
 Reporter:  romainmrhenry                       |       Owner:  justlevine
     Type:  defect (bug)                        |      Status:  assigned
 Priority:  normal                              |   Milestone:  7.0
Component:  AI                                  |     Version:  trunk
 Severity:  normal                              |  Resolution:
 Keywords:  ai-client has-patch has-unit-tests  |     Focuses:
------------------------------------------------+-------------------------
Changes (by JeffPaul):

 * keywords:  has-patch has-unit-tests => ai-client has-patch has-unit-tests


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64706#comment:33>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 13:14:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 13:14:39 -0000
Subject: [wp-trac] [WordPress Trac] #64977: The `core/get-site-info`
 ability returns wrong locale code in the admin
In-Reply-To: <051.fa74e7932cff36205e00e2d2015b7211@wordpress.org>
References: <051.fa74e7932cff36205e00e2d2015b7211@wordpress.org>
Message-ID: <066.0ef856f81b9c235fe3425c7f45776688@wordpress.org>

#64977: The `core/get-site-info` ability returns wrong locale code in the admin
---------------------------------+---------------------
 Reporter:  afercia              |       Owner:  (none)
     Type:  defect (bug)         |      Status:  new
 Priority:  normal               |   Milestone:  7.1
Component:  AI                   |     Version:  6.9
 Severity:  normal               |  Resolution:
 Keywords:  abilities has-patch  |     Focuses:
---------------------------------+---------------------
Changes (by JeffPaul):

 * keywords:  has-patch => abilities has-patch


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64977#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 13:14:50 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 13:14:50 -0000
Subject: [wp-trac] [WordPress Trac] #65020: Connectors: Support custom
 plugin is_active callback in connector registry and plugin status output
In-Reply-To: <055.d405075069acea8d9ef2197fb71ff599@wordpress.org>
References: <055.d405075069acea8d9ef2197fb71ff599@wordpress.org>
Message-ID: <070.cdb37d51ec1c809a01c185a723188f04@wordpress.org>

#65020: Connectors: Support custom plugin is_active callback in connector registry
and plugin status output
-------------------------------------+------------------------------
 Reporter:  iamadisingh              |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  AI                       |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  connectors dev-feedback  |     Focuses:
-------------------------------------+------------------------------
Changes (by JeffPaul):

 * keywords:  dev-feedback => connectors dev-feedback


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65020#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 13:22:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 13:22:26 -0000
Subject: [wp-trac] [WordPress Trac] #64917: WP 7.0 Connectors: unclear
 error message
In-Reply-To: <051.50e3faafb74ba8eaaede21fb888645f0@wordpress.org>
References: <051.50e3faafb74ba8eaaede21fb888645f0@wordpress.org>
Message-ID: <066.72d53b05b3a82afe9207d5417d3183e3@wordpress.org>

#64917: WP 7.0 Connectors: unclear error message
---------------------------------+----------------------
 Reporter:  ecairol              |       Owner:  (none)
     Type:  defect (bug)         |      Status:  new
 Priority:  normal               |   Milestone:  7.0.1
Component:  AI                   |     Version:  trunk
 Severity:  normal               |  Resolution:
 Keywords:  ai-client has-patch  |     Focuses:  ui-copy
---------------------------------+----------------------

Comment (by JeffPaul):

 Yeah, user-friendly names would definitely be preferred @dhruvang21 if
 that's feasible to maintain.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64917#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 13:29:10 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 13:29:10 -0000
Subject: [wp-trac] [WordPress Trac] #65047: Missing escaping for XML
 error message
In-Reply-To: <055.114e593d87c6f2e3617a84cdf8f35483@wordpress.org>
References: <055.114e593d87c6f2e3617a84cdf8f35483@wordpress.org>
Message-ID: <070.c6214ab8729cfb6ca5410c9568d2e2dd@wordpress.org>

#65047: Missing escaping for XML error message
------------------------------+------------------------------
 Reporter:  maheshpatel       |       Owner:  (none)
     Type:  defect (bug)      |      Status:  new
 Priority:  normal            |   Milestone:  Awaiting Review
Component:  Pings/Trackbacks  |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+------------------------------
Changes (by sabernhardt):

 * version:  trunk =>


Old description:

> **File:** [src/wp-trackback.php](src/wp-trackback.php#L37)
> - **Line:** 37
> - **Problem:** `$error_message` output in XML without escaping
> - **Severity:** XML parsing vulnerability
> - **Current Code:**
>

>   if ( $error ) {
>       echo '<?xml version="1.0" encoding="utf-8"?' . ">\n";
>       echo "<response>\n";
>       echo "<error>1</error>\n";
>       echo "<message>$error_message</message>\n";
>       echo '</response>';
>   }
>

> - **Fix:**
>

>   if ( $error ) {
>       echo '<?xml version="1.0" encoding="utf-8"?' . ">\n";
>       echo "<response>\n";
>       echo "<error>1</error>\n";
>       echo "<message>" . esc_html ( $error_message ) . "</message>\n";
>       echo '</response>';
>   }
>

> - **Why It Matters:**
>   - XML special characters (`&`, `<`, `>`) can break XML parsing
>   - Error messages come from user actions or system states

New description:

 - **File:** [https://github.com/WordPress/wordpress-
 develop/blob/e12ddb3c76e73ef32510e5464472e04f0cd1483a/src/wp-
 trackback.php#L37 src/wp-trackback.php]
 - **Line:** 37
 - **Problem:** `$error_message` output in XML without escaping

 **Current Code:**

 {{{
   if ( $error ) {
       echo '<?xml version="1.0" encoding="utf-8"?' . ">\n";
       echo "<response>\n";
       echo "<error>1</error>\n";
       echo "<message>$error_message</message>\n";
       echo '</response>';
   }
 }}}

 **Fix:**

 {{{
   if ( $error ) {
       echo '<?xml version="1.0" encoding="utf-8"?' . ">\n";
       echo "<response>\n";
       echo "<error>1</error>\n";
       echo "<message>" . esc_html ( $error_message ) . "</message>\n";
       echo '</response>';
   }
 }}}

 **Why It Matters:**
   - XML special characters (`&`, `<`, `>`) can break XML parsing
   - Error messages come from user actions or system states

--

Comment:

 The `trackback_response()` function has been available since
 [https://core.trac.wordpress.org/browser/trunk/b2-include/b2functions.php?rev=8&marks=809#L803
 changeset 8], and the escaping functions were added later.

 Would `esc_xml()` be a better choice?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65047#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 13:31:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 13:31:31 -0000
Subject: [wp-trac] [WordPress Trac] #64924: Add a `has_ai_credentials()`
 function to WordPress core that plugins can use to check if AI credentials
 are available.
In-Reply-To: <055.27be0ae421a3dd47e68ac187c824a251@wordpress.org>
References: <055.27be0ae421a3dd47e68ac187c824a251@wordpress.org>
Message-ID: <070.3ecf3e7d060341cb42343f0df8e3f201@wordpress.org>

#64924: Add a `has_ai_credentials()` function to WordPress core that plugins can
use to check if AI credentials are available.
----------------------------------------------+----------------------------
 Reporter:  raftaar1191                       |       Owner:  (none)
     Type:  enhancement                       |      Status:  new
 Priority:  normal                            |   Milestone:  Awaiting
                                              |  Review
Component:  AI                                |     Version:  trunk
 Severity:  normal                            |  Resolution:
 Keywords:  connectors ai-client 2nd-opinion  |     Focuses:
                                              |  sustainability
----------------------------------------------+----------------------------
Changes (by JeffPaul):

 * keywords:  2nd-opinion => connectors ai-client 2nd-opinion


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64924#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 13:35:27 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 13:35:27 -0000
Subject: [wp-trac] [WordPress Trac] #57858: If permalink structure is
 set to /%category%/%postname% ,
 WordPress will match a /0/ path as a category archive
In-Reply-To: <051.249b4eee57497f64fc23af338fe61154@wordpress.org>
References: <051.249b4eee57497f64fc23af338fe61154@wordpress.org>
Message-ID: <066.bc9f13fca71204c8ea11210e5d76abc4@wordpress.org>

#57858: If permalink structure is set to /%category%/%postname% , WordPress will
match a /0/ path as a category archive
-------------------------------------------------+-------------------------
 Reporter:  krdevio                              |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Rewrite Rules                        |     Version:  6.1.1
 Severity:  normal                               |  Resolution:
 Keywords:  has-test-info needs-testing needs-   |     Focuses:
  patch                                          |
-------------------------------------------------+-------------------------

Comment (by codente):

 It is not working as expected but maybe what I'm seeing isn't this exact
 issue? I'm not sure.

 When the post permalink structure (Settings > Permalinks > Permalink
 Structure > Custom Structure ) is set to /%category%/%postname% , the
 category slug without /%category%/ will match as the category archive but
 won't work as expected - pagination doesn't work for example.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/57858#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 14:19:47 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 14:19:47 -0000
Subject: [wp-trac] [WordPress Trac] #64960: Connectors: Allow custom env
 var and constant names for API key source detection
In-Reply-To: <060.b88a9f4b06cf0eb59248afb9feb72ee5@wordpress.org>
References: <060.b88a9f4b06cf0eb59248afb9feb72ee5@wordpress.org>
Message-ID: <075.83f76675b8bf5957d483844b4eeb9b9c@wordpress.org>

#64960: Connectors: Allow custom env var and constant names for API key source
detection
----------------------------------+---------------------
 Reporter:  jorgefilipecosta      |       Owner:  (none)
     Type:  task (blessed)        |      Status:  closed
 Priority:  high                  |   Milestone:  7.0
Component:  AI                    |     Version:
 Severity:  normal                |  Resolution:  fixed
 Keywords:  connectors has-patch  |     Focuses:
----------------------------------+---------------------
Changes (by jorgefilipecosta):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 Closing this issue as we followed a better implementation proposed by
 @gziolo.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64960#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 14:47:20 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 14:47:20 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.715681182da13172903e5ed6d61fafc7@wordpress.org>

#65015: Connectors: Several strings are not translated
--------------------------+-----------------------
 Reporter:  369work       |       Owner:  (none)
     Type:  defect (bug)  |      Status:  reopened
 Priority:  high          |   Milestone:  7.0
Component:  I18N          |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+-----------------------

Comment (by 369work):

 Thanks for the thorough investigation.
 I'll keep watching this ticket and happy to help with testing when a patch
 is available.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 15:07:59 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 15:07:59 -0000
Subject: [wp-trac] =?utf-8?q?=5BWordPress_Trac=5D_=2365053=3A_Bu_blog_ta_g?=
 =?utf-8?b?ZXLDp2VrIGhhYmVybGVyaSBidWxhY2Frc8SxbsSxeiBhbWFxY8SxbSDDtnpn?=
 =?utf-8?q?=C3=BCr_gazetecilik?=
Message-ID: <053.f152c653748dc1666a3f52230551518e@wordpress.org>

#65053: Bu blog ta gerçek haberleri bulacaksınız amaqcım özgür gazetecilik
-------------------------------------------------+-------------------------
 Reporter:  demirzcan                            |      Owner:  (none)
     Type:  defect (bug)                         |     Status:  new
 Priority:  normal                               |  Milestone:  Awaiting
                                                 |  Review
Component:  General                              |    Version:
 Severity:  normal                               |   Keywords:
  Focuses:  ui, accessibility, javascript,       |
  docs, administration, multisite, performance,  |
  privacy, sustainability, ui-copy               |
-------------------------------------------------+-------------------------
 Değerli Dostlarım Haberlerimi Worldpres Dünya Türk haqber/world Turkısh
 news ıfj-ınternatıonal federatıon of journalist bloglarımdan yayınlıyorum
 Blogger de Eydünya insaları    hepiniz Türksünüz blogum var buralardan
 haber yazıyorum ERTUĞRUL DEMİRÖZCAN[[Image([[Image()]])]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65053>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 15:18:11 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 15:18:11 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2365053=3A_Bu_blog_ta_?=
 =?utf-8?b?Z2Vyw6dlayBoYWJlcmxlcmkgYnVsYWNha3PEsW7EsXogYW1hcWPEsW0gw7Z6?=
 =?utf-8?q?g=C3=BCr_gazetecilik?=
In-Reply-To: <053.f152c653748dc1666a3f52230551518e@wordpress.org>
References: <053.f152c653748dc1666a3f52230551518e@wordpress.org>
Message-ID: <068.c3684966a3eba0fe40338f92ec9190b7@wordpress.org>

#65053: Bu blog ta gerçek haberleri bulacaksınız amaqcım özgür gazetecilik
-------------------------+-------------------------------------------------
 Reporter:  demirzcan    |       Owner:  (none)
     Type:  defect       |      Status:  closed
  (bug)                  |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:
 Severity:  normal       |  Resolution:  invalid
 Keywords:  close        |     Focuses:  ui, accessibility, javascript,
                         |  docs, administration, multisite, performance,
                         |  privacy, sustainability, ui-copy
-------------------------+-------------------------------------------------
Changes (by ozgursar):

 * keywords:   => close
 * status:  new => closed
 * resolution:   => invalid


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65053#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 16:27:15 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 16:27:15 -0000
Subject: [wp-trac] [WordPress Trac] #65053: Media upload from the post edit
 screen shows an inaccurate number when uploading multiple media files
Message-ID: <053.9dbb6fc319de35dce28f39fb3ef8f2fb@wordpress.org>

#65053: Media upload from the post edit screen shows an inaccurate number when
uploading multiple media files
----------------------------+-----------------------------
 Reporter:  Dharm1025       |      Owner:  (none)
     Type:  defect (bug)    |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Upload          |    Version:  trunk
 Severity:  normal          |   Keywords:
  Focuses:  ui, javascript  |
----------------------------+-----------------------------
 When uploading multiple media files from the Edit Post screen via “Set
 featured image”, it displays incorrect numbers.

 **Steps to reproduce:**

 1. Create a new post.
 2. Click on “Set featured image.”
 3. Go to “Upload files” and upload multiple files.
 4. Notice that the numbers are inaccurate (you may need to repeat step 3
 multiple times to reproduce the issue).

 [[Image(https://cldup.com/YXkXrw9K0z.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65053>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 16:27:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 16:27:39 -0000
Subject: [wp-trac] [WordPress Trac] #65053: Media upload from the post
 edit screen shows an inaccurate number when uploading multiple media files
In-Reply-To: <053.9dbb6fc319de35dce28f39fb3ef8f2fb@wordpress.org>
References: <053.9dbb6fc319de35dce28f39fb3ef8f2fb@wordpress.org>
Message-ID: <068.71d281f9258fed120f187b088641a7e4@wordpress.org>

#65053: Media upload from the post edit screen shows an inaccurate number when
uploading multiple media files
--------------------------+------------------------------
 Reporter:  Dharm1025     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Upload        |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  ui, javascript
--------------------------+------------------------------
Changes (by Dharm1025):

 * Attachment "Screenshot 2026-04-09 at 3.52.52 PM.png" added.

 Screenshot

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65053>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 16:30:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 16:30:23 -0000
Subject: [wp-trac] [WordPress Trac] #62819: Twenty Fourteen: Latest
 Comments block font-size does not change with user settings
In-Reply-To: <060.7d514c752ccbbc429a7452cb86525dfe@wordpress.org>
References: <060.7d514c752ccbbc429a7452cb86525dfe@wordpress.org>
Message-ID: <075.4e902fad6edab43f54e7e4352ddb9a3f@wordpress.org>

#62819: Twenty Fourteen: Latest Comments block font-size does not change with user
settings
--------------------------------------------------+---------------------
 Reporter:  nidhidhandhukiya                      |       Owner:  (none)
     Type:  defect (bug)                          |      Status:  new
 Priority:  normal                                |   Milestone:  7.1
Component:  Bundled Theme                         |     Version:
 Severity:  normal                                |  Resolution:
 Keywords:  has-patch dev-feedback needs-testing  |     Focuses:  css
--------------------------------------------------+---------------------
Changes (by sabernhardt):

 * milestone:  Awaiting Review => 7.1


Comment:

 The block updates sizes in the editor, without refreshing, now without the
 Gutenberg plugin activated.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62819#comment:20>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 16:50:52 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 16:50:52 -0000
Subject: [wp-trac] [WordPress Trac] #65054: $_GET['pagenow'] and
 $_GET['widget'] unsanitized in dashboard AJAX handler
Message-ID: <052.a75882c45098b4077208ace43f305612@wordpress.org>

#65054: $_GET['pagenow'] and $_GET['widget'] unsanitized in dashboard AJAX handler
--------------------------+-------------------------------------
 Reporter:  rajeshcp      |      Owner:  rajeshcp
     Type:  defect (bug)  |     Status:  assigned
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Security      |    Version:  trunk
 Severity:  major         |   Keywords:  has-patch needs-testing
  Focuses:                |
--------------------------+-------------------------------------
 $_GET['pagenow'] and $_GET['widget'] unsanitized in dashboard AJAX handler
 Both values are read directly without sanitize_key(). While the
 switch/comparison limits damage, unsanitized
   superglobal access violates WordPress coding standards unconditionally.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65054>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 17:39:02 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 17:39:02 -0000
Subject: [wp-trac] [WordPress Trac] #65055: _pad_term_counts() uses
 string-concatenated SQL without prepared statement
Message-ID: <052.bca20aa704264c411e9a5a70bff738ad@wordpress.org>

#65055: _pad_term_counts() uses string-concatenated SQL without prepared statement
--------------------------+-------------------------------------
 Reporter:  rajeshcp      |      Owner:  rajeshcp
     Type:  defect (bug)  |     Status:  assigned
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Database      |    Version:  trunk
 Severity:  major         |   Keywords:  has-patch needs-testing
  Focuses:                |
--------------------------+-------------------------------------
 $object_types values are not individually escaped via $wpdb->prepare().
 They use esc_sql() only at the
   get_taxonomy() call, but imploded directly into the query string. The
 array keys are integer IDs but are not cast.
   This should use prepare() with placeholders.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65055>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 17:50:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 17:50:57 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2364962=3A_Install_scr?=
 =?utf-8?b?ZWVuczog4oCcTG9nIElu4oCdIGFuZCAiU3VwcG9ydCBsaW5rIiB1c2Ugb2xk?=
 =?utf-8?q?_color?=
In-Reply-To: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
References: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
Message-ID: <074.8bd82b13690e6b26845d3daeebfde8ff@wordpress.org>

#64962: Install screens: “Log In” and "Support link" use old color
-------------------------------------------------+-------------------------
 Reporter:  huzaifaalmesbah                      |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch has-          |     Focuses:  ui, css
  screenshots changes-requested                  |
-------------------------------------------------+-------------------------

Comment (by Pooja N):

 Tested the changes locally and confirmed that the updated link colors
 align with the revised admin design system.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64962#comment:18>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 18:25:46 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 18:25:46 -0000
Subject: [wp-trac] [WordPress Trac] #65042: Alter Attachment page slug
 behaviour
In-Reply-To: <058.fd3e142d1fd8c40b2e51ab15f9ac6119@wordpress.org>
References: <058.fd3e142d1fd8c40b2e51ab15f9ac6119@wordpress.org>
Message-ID: <073.a8c01f9e6d37b8c3a89d23cc0619fd71@wordpress.org>

#65042: Alter Attachment page slug behaviour
-------------------------------+------------------------------
 Reporter:  namith.jawahar     |       Owner:  (none)
     Type:  enhancement        |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Posts, Post Types  |     Version:
 Severity:  trivial            |  Resolution:
 Keywords:                     |     Focuses:
-------------------------------+------------------------------

Comment (by namith.jawahar):

 The attachment pages are not used by most of WordPress users for sure and
 most don't even know its there and only serving as SEO spam.  I didn't
 suggest a toggle to disable it completely thinking about backward
 compatibility.  while solvable via plugins, the SEO spam this creates is
 real and not really desirable in a modern CMS.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65042#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 19:51:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 19:51:26 -0000
Subject: [wp-trac] [WordPress Trac] #64706: A single config option to
 disable all LLM related features
In-Reply-To: <057.5a6fad87789be36a76653e559056b566@wordpress.org>
References: <057.5a6fad87789be36a76653e559056b566@wordpress.org>
Message-ID: <072.709dbf550d014a5f69655c2986b54c4e@wordpress.org>

#64706: A single config option to disable all LLM related features
------------------------------------------------+-------------------------
 Reporter:  romainmrhenry                       |       Owner:  justlevine
     Type:  defect (bug)                        |      Status:  assigned
 Priority:  normal                              |   Milestone:  7.0
Component:  AI                                  |     Version:  trunk
 Severity:  normal                              |  Resolution:
 Keywords:  ai-client has-patch has-unit-tests  |     Focuses:
------------------------------------------------+-------------------------

Comment (by justlevine):

 FWIW the semantics behind `wp_supports_ai()` is to check whether the
 current **WordPress** environment **supports** AI** functionality.

 I'm happy to change it to any short and self-documenting name. It only
 entered core in beta so it's not like it's a big deal to change. I thought
 about `wp_allows_ai()` for a bit, but the semantics didn't feel as good to
 me. 🤷

 Would recommend we avoid scope creeping into a broad `wp_supports( $thing
 )` or `current_site_can( $thing )` or other patterns. This is scoped for a
 specific and important need, and shouldn't block (or be blocked by)
 progress on defining what sort of `$things` should theoretically qualify
 for this new registry.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64706#comment:34>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 20:07:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 20:07:49 -0000
Subject: [wp-trac] [WordPress Trac] #64225: Test tool and unit test
 improvements for 7.0
In-Reply-To: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
References: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
Message-ID: <066.56ab3eda4e82e50cf300a3a491bddaea@wordpress.org>

#64225: Test tool and unit test improvements for 7.0
--------------------------------------+---------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  task (blessed)            |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by SergeyBiryukov):

 In [changeset:"62223" 62223]:
 {{{
 #!CommitTicketReference repository="" revision="62223"
 Tests: Add missing `@covers` tags for some oEmbed tests.

 Props sagardeshmukh.
 See #64225.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64225#comment:60>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 20:23:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 20:23:23 -0000
Subject: [wp-trac] [WordPress Trac] #65056: The first letter of the labels
 is always capitalized instead of being written as it is
Message-ID: <050.a021bcd8fd08a29a3d1198b1d949ca5a@wordpress.org>

#65056: The first letter of the labels is always capitalized instead of being
written as it is
--------------------------+-----------------------------
 Reporter:  devede        |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Widgets       |    Version:  6.9.4
 Severity:  minor         |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 In the widget, the first letter of the labels is always capitalized,
 instead of being written as is.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65056>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 20:24:15 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 20:24:15 -0000
Subject: [wp-trac] [WordPress Trac] #65056: The first letter of the
 labels is always capitalized instead of being written as it is
In-Reply-To: <050.a021bcd8fd08a29a3d1198b1d949ca5a@wordpress.org>
References: <050.a021bcd8fd08a29a3d1198b1d949ca5a@wordpress.org>
Message-ID: <065.92c0960a4d94c2d23d61e1fa4050ed57@wordpress.org>

#65056: The first letter of the labels is always capitalized instead of being
written as it is
--------------------------+------------------------------
 Reporter:  devede        |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Widgets       |     Version:  6.9.4
 Severity:  minor         |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Changes (by devede):

 * Attachment "Capture d’écran du 2026-04-02 09-44-46.png" added.

 Labels in widget

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65056>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 20:26:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 20:26:30 -0000
Subject: [wp-trac] [WordPress Trac] #65056: The first letter of the
 labels is always capitalized instead of being written as it is
In-Reply-To: <050.a021bcd8fd08a29a3d1198b1d949ca5a@wordpress.org>
References: <050.a021bcd8fd08a29a3d1198b1d949ca5a@wordpress.org>
Message-ID: <065.6e899075e60a87103b933c24c9c01fec@wordpress.org>

#65056: The first letter of the labels is always capitalized instead of being
written as it is
--------------------------+------------------------------
 Reporter:  devede        |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Widgets       |     Version:  6.9.4
 Severity:  minor         |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Changes (by devede):

 * Attachment "Capture d’écran du 2026-04-02 09-44-29.png" added.

 labels in bottom of articles

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65056>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 20:28:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 20:28:31 -0000
Subject: [wp-trac] [WordPress Trac] #65056: The first letter of the
 labels is always capitalized instead of being written as it is
In-Reply-To: <050.a021bcd8fd08a29a3d1198b1d949ca5a@wordpress.org>
References: <050.a021bcd8fd08a29a3d1198b1d949ca5a@wordpress.org>
Message-ID: <065.51ccbe892c70782555a159e384d99ecd@wordpress.org>

#65056: The first letter of the labels is always capitalized instead of being
written as it is
--------------------------+------------------------------
 Reporter:  devede        |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Widgets       |     Version:  6.9.4
 Severity:  minor         |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by devede):

 Sorry, the text of my bugreport is wrong.
 In the widget, the first letter of the labels is being written as is but
 at the bottom of each article, the first letter of the labels is always
 capitalized, instead of being written as is.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65056#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 22:22:34 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 22:22:34 -0000
Subject: [wp-trac] [WordPress Trac] #65053: Media upload from the post
 edit screen shows an inaccurate number when uploading multiple media files
In-Reply-To: <053.9dbb6fc319de35dce28f39fb3ef8f2fb@wordpress.org>
References: <053.9dbb6fc319de35dce28f39fb3ef8f2fb@wordpress.org>
Message-ID: <068.5e49a7c5b60c2e19d18ec8dda00dbbeb@wordpress.org>

#65053: Media upload from the post edit screen shows an inaccurate number when
uploading multiple media files
--------------------------+------------------------------
 Reporter:  Dharm1025     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Upload        |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  ui, javascript
--------------------------+------------------------------
Changes (by adamsilverstein):

 * Attachment "uploading.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65053>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 22:28:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 22:28:06 -0000
Subject: [wp-trac] [WordPress Trac] #65053: Media upload from the post
 edit screen shows an inaccurate number when uploading multiple media files
In-Reply-To: <053.9dbb6fc319de35dce28f39fb3ef8f2fb@wordpress.org>
References: <053.9dbb6fc319de35dce28f39fb3ef8f2fb@wordpress.org>
Message-ID: <068.994e36f78212f7178ab844d7e63b2efc@wordpress.org>

#65053: Media upload from the post edit screen shows an inaccurate number when
uploading multiple media files
--------------------------+------------------------------
 Reporter:  Dharm1025     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Upload        |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  ui, javascript
--------------------------+------------------------------

Comment (by adamsilverstein):

 Thanks for the bug report @Dharm1025 - I was able to reproduce this
 immediately in the editor. I cleared my media library, then dragging 10
 files onto the editor the display read "Showing 10 of 11".

 I was not able to reproduce in the media library itself, these seems
 specific to the editor. I was also not able to reproduce it using the
 gallery inserter or by dragging a group of images onto the editor. It
 seems tied to invoking the uploader from the "Set Featured Image" button
 as you described.

 It feels a bit buggy that you can ''select more than one image at all''
 from this upload dialog, only one image can be the featured image. So
 maybe the bug here is the inserter should only allow single image
 selection (similar to the image block inserter). Then you would never see
 the mismatched count your report identified.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65053#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr  9 23:16:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 09 Apr 2026 23:16:49 -0000
Subject: [wp-trac] [WordPress Trac] #45354: Adding index for meta_key
 and post_id in postmeta
In-Reply-To: <056.ed0283820e92025f40a31fbe52b0dd88@wordpress.org>
References: <056.ed0283820e92025f40a31fbe52b0dd88@wordpress.org>
Message-ID: <071.7aa046eb61eeacf4cc52ae0451b68ec8@wordpress.org>

#45354: Adding index for meta_key and post_id in postmeta
-------------------------------------------------+-------------------------
 Reporter:  DuckDagobert                         |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  7.1
Component:  Database                             |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  needs-testing dev-feedback has-      |     Focuses:
  patch has-unit-tests                           |  performance
-------------------------------------------------+-------------------------

Comment (by galbaras):

 I see the PR is adding the `meta_key, post_id` index that was initially
 proposed, but @fliespl actually tested `post_id, meta_key`, which makes
 more sense.

 Also, making `post_id, meta_key` could speed things up further.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/45354#comment:17>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 01:54:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 01:54:07 -0000
Subject: [wp-trac] [WordPress Trac] #65056: The first letter of the
 labels is always capitalized instead of being written as it is
In-Reply-To: <050.a021bcd8fd08a29a3d1198b1d949ca5a@wordpress.org>
References: <050.a021bcd8fd08a29a3d1198b1d949ca5a@wordpress.org>
Message-ID: <065.42b5294dfa685f511a8e1ba02272f7e6@wordpress.org>

#65056: The first letter of the labels is always capitalized instead of being
written as it is
--------------------------+------------------------------
 Reporter:  devede        |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Widgets       |     Version:  6.9.4
 Severity:  minor         |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by sabernhardt):

 Which theme do you use?

 I suspect your theme has a CSS rule like this in the tags list:
 {{{ text-transform: capitalize; }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65056#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 02:20:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 02:20:05 -0000
Subject: [wp-trac] [WordPress Trac] #64653:
 WP_Hook::resort_active_iterations() skips next priority when callback
 removes itself during execution
In-Reply-To: <052.960a240e2eb14a0d3f9e96b610c9e1c5@wordpress.org>
References: <052.960a240e2eb14a0d3f9e96b610c9e1c5@wordpress.org>
Message-ID: <067.9161e0afee52940976d8a5899cb185e0@wordpress.org>

#64653: WP_Hook::resort_active_iterations() skips next priority when callback
removes itself during execution
--------------------------------------+--------------------------
 Reporter:  mrcasual                  |       Owner:  westonruter
     Type:  defect (bug)              |      Status:  reviewing
 Priority:  normal                    |   Milestone:  7.1
Component:  Plugins                   |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+--------------------------

Comment (by liaison):

 Test code. Put above wp-includes directory.
 {{{#!php
 <?php
 /**
  * Trac #64653: Optimized minimal reproduction
  */

 define( 'ABSPATH', dirname( __FILE__ ) . '/' );
 define( 'WPINC', 'wp-includes' );

 require_once ABSPATH . WPINC . '/plugin.php';

 echo "--- Starting Hook Test ---\n";


 $executed_priorities = [];

 // Priority 10
 add_action( 'test_hook', function () use ( &$executed_priorities ) {
     $executed_priorities[] = 10;
     echo "Executed: Priority 10\n";
 }, 10 );

 // Priority 50
 function wp_hook_bug_self_removing() {
     global $executed_priorities;
     $executed_priorities[] = 50;
     echo "Executed: Priority 50 (removing itself...)\n";

     remove_action( 'test_hook', 'wp_hook_bug_self_removing', 50 );
 }
 add_action( 'test_hook', 'wp_hook_bug_self_removing', 50 );

 // Priority 100
 add_action( 'test_hook', function () use ( &$executed_priorities ) {
     $executed_priorities[] = 100;
     echo "Executed: Priority 100\n";
 }, 100 );


 do_action( 'test_hook' );

 echo "--- Test Completed ---\n";


 if ( ! in_array( 100, $executed_priorities ) ) {
     echo "❌ BUG REPRODUCED: Priority 100 was skipped!\n";
 } else {
     echo "✅ TEST PASSED: Priority 100 was executed.\n";
 }
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64653#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 06:16:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 06:16:30 -0000
Subject: [wp-trac] [WordPress Trac] #23276: WordPress Importer: Update
 existing navs instead of new
In-Reply-To: <055.0ebb433184ff19ef0f0a86dedb8169a7@wordpress.org>
References: <055.0ebb433184ff19ef0f0a86dedb8169a7@wordpress.org>
Message-ID: <070.96e4a6653b0a65d4c98a4698bf56f3a2@wordpress.org>

#23276: WordPress Importer: Update existing navs instead of new
-----------------------------------------+----------------------------
 Reporter:  WraithKenny                  |       Owner:  (none)
     Type:  defect (bug)                 |      Status:  new
 Priority:  normal                       |   Milestone:  WordPress.org
Component:  Import                       |     Version:
 Severity:  normal                       |  Resolution:
 Keywords:  needs-refresh needs-testing  |     Focuses:
-----------------------------------------+----------------------------
Changes (by abcd95):

 * Attachment "23276-b.patch" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/23276>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 06:18:25 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 06:18:25 -0000
Subject: [wp-trac] [WordPress Trac] #23276: WordPress Importer: Update
 existing navs instead of new
In-Reply-To: <055.0ebb433184ff19ef0f0a86dedb8169a7@wordpress.org>
References: <055.0ebb433184ff19ef0f0a86dedb8169a7@wordpress.org>
Message-ID: <070.8c215125923e0b5f4b56ef8be5eafc1b@wordpress.org>

#23276: WordPress Importer: Update existing navs instead of new
--------------------------+----------------------------
 Reporter:  WraithKenny   |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  WordPress.org
Component:  Import        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+----------------------------
Changes (by abcd95):

 * keywords:  needs-refresh needs-testing => has-patch


Comment:

 I think this patch will suffice and is the simplest fix I can think of,
 just checks whether a nav_menu_item post with the original ID already
 exists before calling wp_update_nav_menu_item(). If found, the existing ID
 is passed so the item is updated in place. If not found, 0 is passed,
 creating a new item.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/23276#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 06:38:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 06:38:23 -0000
Subject: [wp-trac] [WordPress Trac] #65057: For our use of WordPresswe need
 to be able to upload and manage .dwg and .dwt files
Message-ID: <052.f1b7400618cc93cbd544f21950936e3b@wordpress.org>

#65057: For our use of WordPresswe need to be able to upload and manage .dwg and
.dwt files
-----------------------------+-----------------------------
 Reporter:  ahjelmqv         |      Owner:  (none)
     Type:  feature request  |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  General          |    Version:  6.9.4
 Severity:  normal           |   Keywords:
  Focuses:                   |
-----------------------------+-----------------------------
 To be able to upload tech drawings, I appended two rows in wp/wp-
 includes/functions.php to allow .dwg and .dwt files to be recognized and
 allowed.
 Would be nice to have them included in core if there is no risks with
 allowing.

 --
 # within file     wp/wp-includes/functions.php


 function wp_get_mime_types() {

         return apply_filters(
                 'mime_types',
                 array(
 ...
                         'dwg'                          => 'image/vnd.dwg',
                         'dwt'                          =>
 'application/x-autocad',
 ...

                 )
         );
 }

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65057>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 06:44:42 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 06:44:42 -0000
Subject: [wp-trac] [WordPress Trac] #65057: For our use of WordPresswe
 need to be able to upload and manage .dwg and .dwt files
In-Reply-To: <052.f1b7400618cc93cbd544f21950936e3b@wordpress.org>
References: <052.f1b7400618cc93cbd544f21950936e3b@wordpress.org>
Message-ID: <067.04464d8b1246688ae716ced771c83658@wordpress.org>

#65057: For our use of WordPresswe need to be able to upload and manage .dwg and
.dwt files
-----------------------------+------------------------------
 Reporter:  ahjelmqv         |       Owner:  (none)
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Upload           |     Version:  6.9.4
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:
-----------------------------+------------------------------
Changes (by dd32):

 * component:  General => Upload


Old description:

> To be able to upload tech drawings, I appended two rows in wp/wp-
> includes/functions.php to allow .dwg and .dwt files to be recognized and
> allowed.
> Would be nice to have them included in core if there is no risks with
> allowing.
>
> --
> # within file     wp/wp-includes/functions.php
>

> function wp_get_mime_types() {
>
>         return apply_filters(
>                 'mime_types',
>                 array(
> ...
>                         'dwg'                          =>
> 'image/vnd.dwg',
>                         'dwt'                          =>
> 'application/x-autocad',
> ...
>
>                 )
>         );
> }

New description:

 To be able to upload tech drawings, I appended two rows in wp/wp-
 includes/functions.php to allow .dwg and .dwt files to be recognized and
 allowed.
 Would be nice to have them included in core if there is no risks with
 allowing.

 {{{
 # within file     wp/wp-includes/functions.php


 function wp_get_mime_types() {

         return apply_filters(
                 'mime_types',
                 array(
 ...
                         'dwg'                          => 'image/vnd.dwg',
                         'dwt'                          =>
 'application/x-autocad',
 ...

                 )
         );
 }
 }}}

--

Comment:

 Hi @ahjelmqv,

 Generally use of a plugin to enable less-common file mime types is best,
 as not every file type can be included in WordPress.

 In general, use of a plugin to enable site-specific mime-types is the best
 route for most people.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65057#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 06:46:47 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 06:46:47 -0000
Subject: [wp-trac] [WordPress Trac] #65056: The first letter of the
 labels is always capitalized instead of being written as it is
In-Reply-To: <050.a021bcd8fd08a29a3d1198b1d949ca5a@wordpress.org>
References: <050.a021bcd8fd08a29a3d1198b1d949ca5a@wordpress.org>
Message-ID: <065.7b5fe0ac23e7078738abbd496e9f2126@wordpress.org>

#65056: The first letter of the labels is always capitalized instead of being
written as it is
--------------------------+----------------------
 Reporter:  devede        |       Owner:  (none)
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  General       |     Version:
 Severity:  minor         |  Resolution:  invalid
 Keywords:                |     Focuses:
--------------------------+----------------------
Changes (by sabernhardt):

 * status:  new => closed
 * resolution:   => invalid
 * version:  6.9.4 =>
 * component:  Widgets => General
 * milestone:  Awaiting Review =>


Comment:

 I found that you already answered my question on the support forums: the
 [https://wordpress.org/themes/nisarg/ Nisarg theme].

 That has `text-transform: capitalize` for `.tags-links a` and other
 elements.

 If you want to continue using the theme, you can override its `capitalize`
 rules by adding this in the Customizer under Additional CSS:
 {{{

 .site-description,
 .entry-meta,
 .entry-meta a,
 .byline,
 .cat-links a,
 .tags-links a,
 .archive-page-title,
 .nav-previous,
 .nav-next,
 .next-post,
 .prev-post,
 #infinite-handle span button,
 #infinite-handle span button:hover,
 #infinite-handle span button:focus {
   text-transform: none;
 }

 }}}

 I'll close the ticket because this is not a bug in WordPress core.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65056#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 07:52:11 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 07:52:11 -0000
Subject: [wp-trac] [WordPress Trac] #65058: Abilities API: Catch exceptions
 thrown by ability callbacks
Message-ID: <050.65e9668d394b013d1b76006d4c82ef62@wordpress.org>

#65058: Abilities API: Catch exceptions thrown by ability callbacks
--------------------------+---------------------------
 Reporter:  gziolo        |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  7.0
Component:  AI            |    Version:  6.9
 Severity:  normal        |   Keywords:  abilities-api
  Focuses:                |
--------------------------+---------------------------
 Originally reported at https://github.com/WordPress/ai/issues/392.

 === Description

 When testing the Core AI feature in WordPress 7.0 RC, I encountered an
 issue while regenerating a post title.

 Actual behavior:

 A network error occurs:

 cURL error 28: Operation timed out after 30006 milliseconds with 0 bytes
 received
 In the browser console:
 A 500 Internal Server Error is logged
 The response unexpectedly includes the entire HTML of the page

 Also noticed:
 wp.abilities.executeAbility is unavailable. Falling back to REST.

 Why this is an issue:

 Returning full HTML in API response may indicate improper error handling
 Could expose unintended data or create debugging/security concerns

 Additional Notes:

 Issue seems related to the request sent to:

 https://router.huggingface.co/v1/chat/completions
 Possibly caused by API timeout, but response handling appears incorrect

 === Step-by-step reproduction instructions

 1. Created a new post
 2. Entered blog title and content
 3. Clicked on “Re-generate” title option
 4. Checked the console log


 === Environment info

 WordPress Version: 7.0 RC (Beta)
 Feature: Core AI (Title Generation)
 Browser: Chrome (latest)
 Setup: Local/Development environment

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65058>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 08:05:15 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 08:05:15 -0000
Subject: [wp-trac] [WordPress Trac] #65058: Abilities API: Catch
 exceptions thrown by ability callbacks
In-Reply-To: <050.65e9668d394b013d1b76006d4c82ef62@wordpress.org>
References: <050.65e9668d394b013d1b76006d4c82ef62@wordpress.org>
Message-ID: <065.d3b97d5e68ca2d687ab91946ef057905@wordpress.org>

#65058: Abilities API: Catch exceptions thrown by ability callbacks
-------------------------------------------------+-------------------------
 Reporter:  gziolo                               |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  7.0
Component:  AI                                   |     Version:  6.9
 Severity:  normal                               |  Resolution:
 Keywords:  abilities-api has-patch has-unit-    |     Focuses:
  tests dev-feedback                             |
-------------------------------------------------+-------------------------
Changes (by gziolo):

 * keywords:  abilities-api has-patch has-unit-tests => abilities-api has-
     patch has-unit-tests dev-feedback


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65058#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 08:56:54 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 08:56:54 -0000
Subject: [wp-trac] [WordPress Trac] #42513:
 WP_Theme::get_post_templates() is extremely inefficient for large themes
In-Reply-To: <052.5fdb99c75f9c417bf5f25176784fc076@wordpress.org>
References: <052.5fdb99c75f9c417bf5f25176784fc076@wordpress.org>
Message-ID: <067.0dceccf31826e29ef4e4d6bfc9cbd3a1@wordpress.org>

#42513: WP_Theme::get_post_templates() is extremely inefficient for large themes
-------------------------------------------------+-------------------------
 Reporter:  gschoppe                             |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Themes                               |     Version:  4.8.3
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-patch has-unit-   |     Focuses:
  tests                                          |  performance
-------------------------------------------------+-------------------------

Comment (by MythThrazz):

 New PR in #11545 replacing PR #8310 with a more comprehensive fix:

   - Replaces dual `file_get_contents()` with a single `get_file_data()`
 call (reads only first 8KB instead of the
   entire file)
   - Moves `get_block_templates()` inside the cache block to avoid a DB
 query on every call
   - Includes unit tests

   The blocker from #42517 (single-line header support) appears to be
 resolved — `get_file_data()` regex already
   handles `<?php // Template Name: ... ?>` format, confirmed by existing
 tests in
   `tests/phpunit/data/themedir1/page-templates/template-header.php`.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/42513#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 08:59:36 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 08:59:36 -0000
Subject: [wp-trac] [WordPress Trac] #65057: For our use of WordPresswe
 need to be able to upload and manage .dwg and .dwt files
In-Reply-To: <052.f1b7400618cc93cbd544f21950936e3b@wordpress.org>
References: <052.f1b7400618cc93cbd544f21950936e3b@wordpress.org>
Message-ID: <067.a2b5eec3296078cfd0046f5492d594a1@wordpress.org>

#65057: For our use of WordPresswe need to be able to upload and manage .dwg and
.dwt files
-----------------------------+----------------------
 Reporter:  ahjelmqv         |       Owner:  (none)
     Type:  feature request  |      Status:  closed
 Priority:  normal           |   Milestone:
Component:  Upload           |     Version:
 Severity:  normal           |  Resolution:  wontfix
 Keywords:                   |     Focuses:
-----------------------------+----------------------
Changes (by audrasjb):

 * status:  new => closed
 * version:  6.9.4 =>
 * resolution:   => wontfix
 * milestone:  Awaiting Review =>


Comment:

 Hello and thanks for the ticket,

 This is indeed plugin territory. You should be able to find some plugins
 that allow full customization on which files are allowed or not, but you
 can also use the following code, either in a custom plugin or in your
 theme's functions.php file (make sure you create a child theme first).

 {{{
 /**
  * Add dwg and dwt to allowed media types
  */
 function ahjelmqv_add_mime_types( $mime_types ) {
         $mime_types['dwg'] = 'image/vnd.dwg';
         $mime_types['dwt'] = 'application/x-autocad';
         return $mime_types;
 }

 add_filter( 'mime_types', 'ahjelmqv_add_mime_types' );
 }}}

 I'm closing this ticket as `wontfix` as it is plugin territory.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65057#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 09:23:32 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 09:23:32 -0000
Subject: [wp-trac] [WordPress Trac] #41349: Media Library insert from
 URL doesn't give a message when a URL fails check
In-Reply-To: <054.d417527b5e5df40c05a6fa0deb4d5983@wordpress.org>
References: <054.d417527b5e5df40c05a6fa0deb4d5983@wordpress.org>
Message-ID: <069.7e7e5c507f681749bf819027e7998024@wordpress.org>

#41349: Media Library insert from URL doesn't give a message when a URL fails check
-------------------------------------+------------------------------
 Reporter:  karmatosed               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Media                    |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  ux-feedback needs-patch  |     Focuses:
-------------------------------------+------------------------------

Comment (by lakshyajeet):

 I have uploaded a patch that addresses the lack of feedback when an
 invalid URL is entered in the Media Library "Insert from URL" workflow.

 Added a new error notice, this ensures the user isn't left wondering why
 the "Insert" button isn't appearing or why the input is acting
 inconsistently.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/41349#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 09:23:45 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 09:23:45 -0000
Subject: [wp-trac] [WordPress Trac] #41349: Media Library insert from
 URL doesn't give a message when a URL fails check
In-Reply-To: <054.d417527b5e5df40c05a6fa0deb4d5983@wordpress.org>
References: <054.d417527b5e5df40c05a6fa0deb4d5983@wordpress.org>
Message-ID: <069.08ae8163bf4ccd2bc4c9504ed71bb211@wordpress.org>

#41349: Media Library insert from URL doesn't give a message when a URL fails check
-------------------------------------+------------------------------
 Reporter:  karmatosed               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Media                    |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  ux-feedback needs-patch  |     Focuses:
-------------------------------------+------------------------------
Changes (by lakshyajeet):

 * Attachment "media-url-fix.mov" added.

 Video showcasing the new error notice.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/41349>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 09:33:51 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 09:33:51 -0000
Subject: [wp-trac] [WordPress Trac] #65050: REST API: Comments
 controller returns 403 instead of 404 for invalid post ID in update_item()
In-Reply-To: <057.d01cd307fcdefb847d0c0d7b8f496018@wordpress.org>
References: <057.d01cd307fcdefb847d0c0d7b8f496018@wordpress.org>
Message-ID: <072.2e0e6c7dcd777b2fbffd901454d9ca4d@wordpress.org>

#65050: REST API: Comments controller returns 403 instead of 404 for invalid post
ID in update_item()
-------------------------------------+-------------------------------
 Reporter:  saratheonline            |       Owner:  saratheonline
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  7.1
Component:  REST API                 |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  coding-standards
-------------------------------------+-------------------------------
Changes (by SergeyBiryukov):

 * milestone:  Awaiting Review => 7.1


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65050#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 10:33:52 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 10:33:52 -0000
Subject: [wp-trac] [WordPress Trac] #61343: Improve caching in
 get_calendar function
In-Reply-To: <056.b68517dc5a08edc253cc4f9e98fbe260@wordpress.org>
References: <056.b68517dc5a08edc253cc4f9e98fbe260@wordpress.org>
Message-ID: <071.a69ee65668ac8f4625d204056c7cf0f9@wordpress.org>

#61343: Improve caching in get_calendar function
-------------------------------------------------+-------------------------
 Reporter:  spacedmonkey                         |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Widgets                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-patch reporter-   |     Focuses:
  feedback has-unit-tests                        |  performance
-------------------------------------------------+-------------------------

Comment (by MythThrazz):

 New PR in #11547 with a different approach than PR #6708:

 **Cache architecture:** Replaced the monolithic cache array (all
 variations in one key) with individual cache keys per variation
 (`get_calendar_{hash}`). Reads no longer deserialize all months/post-
 types, and writes only touch one entry.

 **Cache invalidation:** Switched from `save_post`/`delete_post` to
 `clean_post_cache` as suggested. Uses `wp_cache_flush_group('calendar')`
 with a generation counter fallback for persistent cache implementations
 that don't support group flushing.

 **Raw SQL kept:** The suggestion to replace `$wpdb` queries with
 `WP_Query` was evaluated but not implemented — `SELECT DISTINCT
 DAYOFMONTH(post_date)` returns max 31 rows, while `WP_Query` with
 `posts_per_page=-1` (as in PR #6708) would load all posts in the month.
 The raw queries are more efficient here.

 **Date math:** Replaced the MySQL `DATE_FORMAT(DATE_ADD(...))` query with
 PHP `gmdate()` to eliminate a DB roundtrip for pure date calculation.

 Includes unit tests for cache invalidation, individual keys, and
 flush_group behavior. All existing tests pass.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/61343#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 11:55:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 11:55:22 -0000
Subject: [wp-trac] [WordPress Trac] #64105: TinyMCE in classic editor
 does not support modern video formats
In-Reply-To: <057.a9a1963c11591cc335c1463b0cf67a05@wordpress.org>
References: <057.a9a1963c11591cc335c1463b0cf67a05@wordpress.org>
Message-ID: <072.d695cfc75a1f763cc75fd3ab4c0802cc@wordpress.org>

#64105: TinyMCE in classic editor does not support modern video formats
---------------------------+------------------------------
 Reporter:  blackstar1991  |       Owner:  (none)
     Type:  defect (bug)   |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  General        |     Version:  6.8.3
 Severity:  normal         |  Resolution:
 Keywords:  needs-patch    |     Focuses:  ui, javascript
---------------------------+------------------------------

Comment (by lakshyajeet):

 == Reproduction Report
 === Description
 This report validates whether the issue can be reproduced. The testing
 confirms that while `.webm` files now appear to function in the Classic
 Editor, `.avi` files remain unsupported for playback. However, the `.avi`
 failure is likely a browser-level limitation rather than a WordPress bug,
 as `.avi` is not a standard format for the HTML5 `<video>` tag across
 modern browsers.

 === Environment
 - WordPress: 7.1-alpha-62161-src
 - PHP: 8.3.30
 - Server: nginx/1.29.7
 - Database: mysqli (Server: 8.4.8 / Client: mysqlnd 8.3.30)
 - Browser: Chrome 146.0.0.0
 - OS: macOS
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None activated
 - Plugins:
   * Classic Editor 1.6.7

 === Actual Results
 1.  ✅ Partial Reproduction: While `.webm` files successfully upload and
 play back in both editors, `.avi` files fail to render a preview or play
 back in both the Block Editor and Classic Editor.
 2.  ❌ Observation: The `.avi` playback issue appears to be a browser
 compatibility constraint. Most modern browsers do not support the AVI
 container within the native `<video>` element, leading to the reported
 "unsupported" behavior regardless of the editor used.

 === Additional Notes
 - **WebM:** During testing, `.webm` files worked as expected in the
 Classic Editor, suggesting that recent updates may have already addressed
 the MIME type registration for this specific format.
 - **AVI:** Since the Block Editor also fails to play `.avi` files, this is
 not a TinyMCE-specific issue but a general limitation of web-standard
 video playback. WordPress successfully handles the file upload, but the
 browser cannot render the stream.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64105#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 11:55:52 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 11:55:52 -0000
Subject: [wp-trac] [WordPress Trac] #64105: TinyMCE in classic editor
 does not support modern video formats
In-Reply-To: <057.a9a1963c11591cc335c1463b0cf67a05@wordpress.org>
References: <057.a9a1963c11591cc335c1463b0cf67a05@wordpress.org>
Message-ID: <072.6bb38d44efb5090fe8885da8a4c77f46@wordpress.org>

#64105: TinyMCE in classic editor does not support modern video formats
---------------------------+------------------------------
 Reporter:  blackstar1991  |       Owner:  (none)
     Type:  defect (bug)   |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  General        |     Version:  6.8.3
 Severity:  normal         |  Resolution:
 Keywords:  needs-patch    |     Focuses:  ui, javascript
---------------------------+------------------------------
Changes (by lakshyajeet):

 * Attachment "block-editor.mov" added.

 Issue reproduction in Block Editor.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64105>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 11:56:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 11:56:03 -0000
Subject: [wp-trac] [WordPress Trac] #64105: TinyMCE in classic editor
 does not support modern video formats
In-Reply-To: <057.a9a1963c11591cc335c1463b0cf67a05@wordpress.org>
References: <057.a9a1963c11591cc335c1463b0cf67a05@wordpress.org>
Message-ID: <072.13b93c21e0b25270c37bc3a72ff9c67c@wordpress.org>

#64105: TinyMCE in classic editor does not support modern video formats
---------------------------+------------------------------
 Reporter:  blackstar1991  |       Owner:  (none)
     Type:  defect (bug)   |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  General        |     Version:  6.8.3
 Severity:  normal         |  Resolution:
 Keywords:  needs-patch    |     Focuses:  ui, javascript
---------------------------+------------------------------
Changes (by lakshyajeet):

 * Attachment "classic-editor.mov" added.

 Issue reproduction in Classic Editor.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64105>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 13:15:10 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 13:15:10 -0000
Subject: [wp-trac] [WordPress Trac] #64105: TinyMCE in classic editor
 does not support modern video formats
In-Reply-To: <057.a9a1963c11591cc335c1463b0cf67a05@wordpress.org>
References: <057.a9a1963c11591cc335c1463b0cf67a05@wordpress.org>
Message-ID: <072.089dac37ea080fb7da5d84f9a78eb187@wordpress.org>

#64105: TinyMCE in classic editor does not support modern video formats
---------------------------+------------------------------
 Reporter:  blackstar1991  |       Owner:  (none)
     Type:  defect (bug)   |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  General        |     Version:  6.8.3
 Severity:  normal         |  Resolution:
 Keywords:  needs-patch    |     Focuses:  ui, javascript
---------------------------+------------------------------

Comment (by blackstar1991):

 It would probably be worth prohibiting the uploading of .avi files into
 the body of documents if they cannot be played.

 https://developer.mozilla.org/en-
 US/docs/Web/Media/Guides/Formats/Video_codecs
 https://caniuse.com/?search=video+format

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64105#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 14:23:47 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 14:23:47 -0000
Subject: [wp-trac] [WordPress Trac] #65055: _pad_term_counts() uses
 string-concatenated SQL without prepared statement
In-Reply-To: <052.bca20aa704264c411e9a5a70bff738ad@wordpress.org>
References: <052.bca20aa704264c411e9a5a70bff738ad@wordpress.org>
Message-ID: <067.ffde7caf683f7f46f6e13956c5cd8898@wordpress.org>

#65055: _pad_term_counts() uses string-concatenated SQL without prepared statement
-------------------------------------+------------------------------
 Reporter:  rajeshcp                 |       Owner:  rajeshcp
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Database                 |     Version:  trunk
 Severity:  major                    |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+------------------------------

Comment (by abcd95):

 The current code isn't exploitable — esc_sql() does handle escaping
 correctly here, and the values involved are all server-side (database IDs
 and registered post types, not user input). But switching to
 $wpdb->prepare() is still the right call as a best-practice improvement.
 The patch looks good.

 One small addition worth considering: _update_post_term_count() filters
 object_types through post_type_exists() before querying but
 _pad_term_counts() doesn't. Could be worth adding for consistency.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65055#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 18:06:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 18:06:23 -0000
Subject: [wp-trac] [WordPress Trac] #65026: Hide plugin search form on
 Favorites tab
In-Reply-To: <048.5df104f8236536e341a0c31918d9a06c@wordpress.org>
References: <048.5df104f8236536e341a0c31918d9a06c@wordpress.org>
Message-ID: <063.7e19b18abbf534856fea51b116f177e5@wordpress.org>

#65026: Hide plugin search form on Favorites tab
--------------------------+--------------------------
 Reporter:  bor0          |       Owner:  westonruter
     Type:  defect (bug)  |      Status:  reviewing
 Priority:  normal        |   Milestone:  7.1
Component:  Plugins       |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  ui
--------------------------+--------------------------

Comment (by sabbir1991):

 @bor0 Tested on playground and it's working.

 Checked on `Featured`, `Popular`, and `Recommended` pages, the search form
 is showing.

 Checked on the `Favorites` page, the search form is not showing.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65026#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 18:57:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 18:57:44 -0000
Subject: [wp-trac] [WordPress Trac] #65059: Modal overlapping the content
 editor
Message-ID: <053.ac94bd0341e39f512163215cdcda4a2c@wordpress.org>

#65059: Modal overlapping the content editor
--------------------------+-----------------------------
 Reporter:  brianhogg     |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  General       |    Version:
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 An accessible modal appearing as part of a meta box (ie. the "Add New
 Plan" button in LifterLMS) now causes the meta box area to fully expand if
 it has not been resized previously, hiding the content editor area
 completely.

 It can also overlap with the resize bar, requiring an expansion to allow
 for the action underneath it to be clicked.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65059>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 18:58:43 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 18:58:43 -0000
Subject: [wp-trac] [WordPress Trac] #65059: Modal overlapping the
 content editor
In-Reply-To: <053.ac94bd0341e39f512163215cdcda4a2c@wordpress.org>
References: <053.ac94bd0341e39f512163215cdcda4a2c@wordpress.org>
Message-ID: <068.4946956893a1a2cedd767ffeedf617af@wordpress.org>

#65059: Modal overlapping the content editor
--------------------------+------------------------------
 Reporter:  brianhogg     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Changes (by brianhogg):

 * Attachment "CleanShot 2026-04-10 at 14.56.08 at 2x.png" added.

 Screenshot of resize overlapping the modal close button

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65059>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 19:00:38 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 19:00:38 -0000
Subject: [wp-trac] [WordPress Trac] #65059: Modal overlapping the
 content editor
In-Reply-To: <053.ac94bd0341e39f512163215cdcda4a2c@wordpress.org>
References: <053.ac94bd0341e39f512163215cdcda4a2c@wordpress.org>
Message-ID: <068.f459a979e55d92f37fae8bdf3628cc49@wordpress.org>

#65059: Modal overlapping the content editor
--------------------------+------------------------------
 Reporter:  brianhogg     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Changes (by brianhogg):

 * version:   => trunk


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65059#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 19:03:40 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 19:03:40 -0000
Subject: [wp-trac] [WordPress Trac] #65060: Formatting issue on
 expand/collapse meta box area focus
Message-ID: <053.3f798f1a567cca7e0d02f86b0e08f865@wordpress.org>

#65060: Formatting issue on expand/collapse meta box area focus
--------------------------+-----------------------------
 Reporter:  brianhogg     |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Formatting    |    Version:  trunk
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 When a meta box expand/collapse button has focus, the formatting looks
 off. The radius is a bit too big for the height available.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65060>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 19:04:10 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 19:04:10 -0000
Subject: [wp-trac] [WordPress Trac] #65060: Formatting issue on
 expand/collapse meta box area focus
In-Reply-To: <053.3f798f1a567cca7e0d02f86b0e08f865@wordpress.org>
References: <053.3f798f1a567cca7e0d02f86b0e08f865@wordpress.org>
Message-ID: <068.f025b209296a6665c2be3455bbdf7bae@wordpress.org>

#65060: Formatting issue on expand/collapse meta box area focus
--------------------------+------------------------------
 Reporter:  brianhogg     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Formatting    |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Changes (by brianhogg):

 * Attachment "formatting-issue-meta-boxes.jpeg" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65060>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 19:08:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 19:08:26 -0000
Subject: [wp-trac] [WordPress Trac] #65061: Meta boxes hidden by default
Message-ID: <053.cb8a45694752c4e422b93727577c46d7@wordpress.org>

#65061: Meta boxes hidden by default
--------------------------+-----------------------------
 Reporter:  brianhogg     |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  General       |    Version:  trunk
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 On a new install of WP 7.0, meta boxes are now fully hidden by default.
 This causes confusion when important parts of the editor for many post
 types no longer appear until the small "Meta Boxes" bar is clicked.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65061>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 19:08:34 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 19:08:34 -0000
Subject: [wp-trac] [WordPress Trac] #65061: Meta boxes hidden by default
In-Reply-To: <053.cb8a45694752c4e422b93727577c46d7@wordpress.org>
References: <053.cb8a45694752c4e422b93727577c46d7@wordpress.org>
Message-ID: <068.3bf164e971d0be1992c9dfcbd37ac9d2@wordpress.org>

#65061: Meta boxes hidden by default
--------------------------+------------------------------
 Reporter:  brianhogg     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Changes (by brianhogg):

 * Attachment "CleanShot 2026-04-10 at 15.07.51 at 2x.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65061>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 19:26:15 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 19:26:15 -0000
Subject: [wp-trac] [WordPress Trac] #65053: Media upload from the post
 edit screen shows an inaccurate number when uploading multiple media files
In-Reply-To: <053.9dbb6fc319de35dce28f39fb3ef8f2fb@wordpress.org>
References: <053.9dbb6fc319de35dce28f39fb3ef8f2fb@wordpress.org>
Message-ID: <068.8f3e667bbb02c27590e164a85b395eeb@wordpress.org>

#65053: Media upload from the post edit screen shows an inaccurate number when
uploading multiple media files
--------------------------+------------------------------
 Reporter:  Dharm1025     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Upload        |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  ui, javascript
--------------------------+------------------------------

Comment (by adamsilverstein):

 @Dharm1025 if possible, can you verify that
 https://github.com/WordPress/gutenberg/pull/77213 fixes your issue?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65053#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 19:46:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 19:46:21 -0000
Subject: [wp-trac] [WordPress Trac] #64225: Test tool and unit test
 improvements for 7.0
In-Reply-To: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
References: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
Message-ID: <066.66f30cd001faaf3ba47709e4394811de@wordpress.org>

#64225: Test tool and unit test improvements for 7.0
--------------------------------------+---------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  task (blessed)            |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by SergeyBiryukov):

 In [changeset:"62224" 62224]:
 {{{
 #!CommitTicketReference repository="" revision="62224"
 Tests: Rename some oEmbed test classes as per the naming conventions.

 Follow-up to [34903], [62223].

 See #64225.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64225#comment:61>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 21:16:51 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 21:16:51 -0000
Subject: [wp-trac] [WordPress Trac] #65053: Media upload from the post
 edit screen shows an inaccurate number when uploading multiple media files
In-Reply-To: <053.9dbb6fc319de35dce28f39fb3ef8f2fb@wordpress.org>
References: <053.9dbb6fc319de35dce28f39fb3ef8f2fb@wordpress.org>
Message-ID: <068.725c11f7c8026879407e0cb018c2bd18@wordpress.org>

#65053: Media upload from the post edit screen shows an inaccurate number when
uploading multiple media files
--------------------------+------------------------------
 Reporter:  Dharm1025     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Upload        |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  ui, javascript
--------------------------+------------------------------

Comment (by adamsilverstein):

 I tested the PR manually and verified I can only select a single image
 from the featured image button. Are you seeing this problem elsewhere?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65053#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 10 22:53:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 10 Apr 2026 22:53:44 -0000
Subject: [wp-trac] [WordPress Trac] #65032: View transition admin bar
 quirks
In-Reply-To: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
References: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
Message-ID: <067.29a06793c4024cbc7f84e5b389b378f7@wordpress.org>

#65032: View transition admin bar quirks
----------------------------+--------------------------------
 Reporter:  zieladam        |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:  ui, accessibility
----------------------------+--------------------------------
Changes (by zieladam):

 * keywords:  reporter-feedback =>


Comment:

 Oh! It works on my end, even in private mode. How weird! I couldn't upload
 here because of the 10MB limit, but I've uploaded it to my site, which
 uploaded it to VideoPress. Hopefully this works:

 https://videos.files.wordpress.com/Lnml4hak/574645931-7a48ae52-70d7-47ee-
 95e0-aec80463dcde.mp4

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65032#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 02:52:58 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 02:52:58 -0000
Subject: [wp-trac] [WordPress Trac] #65060: Formatting issue on
 expand/collapse meta box area focus
In-Reply-To: <053.3f798f1a567cca7e0d02f86b0e08f865@wordpress.org>
References: <053.3f798f1a567cca7e0d02f86b0e08f865@wordpress.org>
Message-ID: <068.ef92641c1d0f22c632f5a81362e01b4c@wordpress.org>

#65060: Formatting issue on expand/collapse meta box area focus
--------------------------+---------------------
 Reporter:  brianhogg     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  Formatting    |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  admin-reskin  |     Focuses:
--------------------------+---------------------
Changes (by wildworks):

 * keywords:   => admin-reskin
 * milestone:  Awaiting Review => 7.0


Comment:

 Thanks for the report. I believe this problem was caused by #64644. This
 is because #64644 changed the focused state as follows:

 From:
 {{{
 .postbox .handle-order-higher:focus,
 .postbox .handle-order-lower:focus,
 .postbox .handlediv:focus {
         box-shadow: inset 0 0 0 2px #2271b1;
 }
 }}}

 To:
 {{{
 .postbox .handle-order-higher:focus,
 .postbox .handle-order-lower:focus,
 .postbox .handlediv:focus {
         box-shadow: 0 0 0 var(--wp-admin-border-width-focus, 1.5px) var
 (--wp-admin-theme-color);
 }
 }}}

 Note that the `inset` has been removed.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65060#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 03:17:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 03:17:03 -0000
Subject: [wp-trac] [WordPress Trac] #65061: Meta boxes hidden by default
In-Reply-To: <053.cb8a45694752c4e422b93727577c46d7@wordpress.org>
References: <053.cb8a45694752c4e422b93727577c46d7@wordpress.org>
Message-ID: <068.3fd350512315af943dfcf0d745369603@wordpress.org>

#65061: Meta boxes hidden by default
--------------------------+------------------------------
 Reporter:  brianhogg     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by wildworks):

 Thanks for the report, but I can't reproduce the problem on Playground.

 This is my test procedure.

 1. Access https://playground.wordpress.net/?wp=beta
 2. Open a post
 3. Open Option > Preferences
 4. Enable the "Custom fields" setting
 5. Click the "Show & Reload Page" button
 6. The metabox area occupies the lower half of the canvas.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65061#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 03:19:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 03:19:22 -0000
Subject: [wp-trac] [WordPress Trac] #65060: Formatting issue on
 expand/collapse meta box area focus
In-Reply-To: <053.3f798f1a567cca7e0d02f86b0e08f865@wordpress.org>
References: <053.3f798f1a567cca7e0d02f86b0e08f865@wordpress.org>
Message-ID: <068.870dc00bb83cc742e5903d29627d60b7@wordpress.org>

#65060: Formatting issue on expand/collapse meta box area focus
--------------------------+---------------------
 Reporter:  brianhogg     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  Formatting    |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  admin-reskin  |     Focuses:
--------------------------+---------------------
Changes (by wildworks):

 * Attachment "metabox.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65060>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 03:26:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 03:26:55 -0000
Subject: [wp-trac] [WordPress Trac] #65062: Revisions: buttons are misplaced
Message-ID: <053.b9ce602729457db6bab38d69686036f5@wordpress.org>

#65062: Revisions: buttons are misplaced
--------------------------+--------------------------
 Reporter:  wildworks     |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  7.0
Component:  Revisions     |    Version:
 Severity:  normal        |   Keywords:  admin-reskin
  Focuses:                |
--------------------------+--------------------------
 Related to #64547

 We changed the default size of most buttons from 30px to 40px. As a
 result, the space below the "Previous", "Next", and "Restore This
 Revision" buttons disappeared on the classic revision screen.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65062>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 03:28:46 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 03:28:46 -0000
Subject: [wp-trac] [WordPress Trac] #65062: Revisions: buttons are
 misplaced
In-Reply-To: <053.b9ce602729457db6bab38d69686036f5@wordpress.org>
References: <053.b9ce602729457db6bab38d69686036f5@wordpress.org>
Message-ID: <068.87c35c7f4620b02a3ff1308d60bcdaf2@wordpress.org>

#65062: Revisions: buttons are misplaced
--------------------------+---------------------
 Reporter:  wildworks     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  Revisions     |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  admin-reskin  |     Focuses:
--------------------------+---------------------
Changes (by wildworks):

 * Attachment "revisions-ui.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65062>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 04:04:47 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 04:04:47 -0000
Subject: [wp-trac] [WordPress Trac] #65041: Implement Priority+ pattern
 for WordPress adminbar
In-Reply-To: <056.8691352382afa15de7f9c21e9388d411@wordpress.org>
References: <056.8691352382afa15de7f9c21e9388d411@wordpress.org>
Message-ID: <071.5ec8edc93c90f6d251b0ba11cafe8d30@wordpress.org>

#65041: Implement Priority+ pattern for WordPress adminbar
--------------------------+------------------------
 Reporter:  mrleblanc101  |       Owner:  (none)
     Type:  enhancement   |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  Toolbar       |     Version:
 Severity:  normal        |  Resolution:  duplicate
 Keywords:                |     Focuses:  ui, css
--------------------------+------------------------
Changes (by wildworks):

 * status:  new => closed
 * resolution:   => duplicate
 * focuses:  ui => ui, css
 * component:  Administration => Toolbar
 * milestone:  Awaiting Review =>


Comment:

 Thanks for the report. This matter has been discussed at length under
 #28983. Let's close this in favor of #28983

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65041#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 04:17:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 04:17:05 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2364962=3A_Install_scr?=
 =?utf-8?b?ZWVuczog4oCcTG9nIElu4oCdIGFuZCAiU3VwcG9ydCBsaW5rIiB1c2Ugb2xk?=
 =?utf-8?q?_color?=
In-Reply-To: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
References: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
Message-ID: <074.8d004c9542bd2e3a71757bef2ab05ae5@wordpress.org>

#64962: Install screens: “Log In” and "Support link" use old color
-------------------------------------------------+-------------------------
 Reporter:  huzaifaalmesbah                      |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch has-          |     Focuses:  ui, css
  screenshots changes-requested                  |
-------------------------------------------------+-------------------------

Comment (by wildworks):

 [https://github.com/WordPress/wordpress-develop/pull/11373/ PR 11373]
 needs to be updated. The correct color is not being used in some parts of
 the code. Please refer to [https://github.com/WordPress/wordpress-
 develop/pull/11373/#discussion_r3004370163 this discussion].

 cc @hbhalodia

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64962#comment:19>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 04:17:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 04:17:48 -0000
Subject: [wp-trac] [WordPress Trac] #65041: Implement Priority+ pattern
 for WordPress adminbar
In-Reply-To: <056.8691352382afa15de7f9c21e9388d411@wordpress.org>
References: <056.8691352382afa15de7f9c21e9388d411@wordpress.org>
Message-ID: <071.b0466a6bcc64e9ce47d01422667c680d@wordpress.org>

#65041: Implement Priority+ pattern for WordPress adminbar
--------------------------+------------------------
 Reporter:  mrleblanc101  |       Owner:  (none)
     Type:  enhancement   |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  Toolbar       |     Version:
 Severity:  normal        |  Resolution:  duplicate
 Keywords:                |     Focuses:  ui, css
--------------------------+------------------------

Comment (by mrleblanc101):

 12 years, no progress...

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65041#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 04:22:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 04:22:39 -0000
Subject: [wp-trac] [WordPress Trac] #28983: Admin bar length or Admin
 bar on two line
In-Reply-To: <055.1cc2ce9927c5d66810d9ff533a0d820d@wordpress.org>
References: <055.1cc2ce9927c5d66810d9ff533a0d820d@wordpress.org>
Message-ID: <070.b2cb2ae14c53d6973d052bbe55d4cef6@wordpress.org>

#28983: Admin bar length or Admin bar on two line
-------------------------------------------------+-------------------------
 Reporter:  korobochkin                          |       Owner:  KZeni
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Toolbar                              |     Version:  4.3
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-design-feedback      |     Focuses:  ui, css
  changes-requested                              |
-------------------------------------------------+-------------------------
Changes (by mrleblanc101):

 * Attachment "nav-demo.gif" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/28983>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 04:23:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 04:23:06 -0000
Subject: [wp-trac] [WordPress Trac] #28983: Admin bar length or Admin
 bar on two line
In-Reply-To: <055.1cc2ce9927c5d66810d9ff533a0d820d@wordpress.org>
References: <055.1cc2ce9927c5d66810d9ff533a0d820d@wordpress.org>
Message-ID: <070.672a3b8574816939acdad0998cd45341@wordpress.org>

#28983: Admin bar length or Admin bar on two line
-------------------------------------------------+-------------------------
 Reporter:  korobochkin                          |       Owner:  KZeni
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Toolbar                              |     Version:  4.3
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-design-feedback      |     Focuses:  ui, css
  changes-requested                              |
-------------------------------------------------+-------------------------

Comment (by mrleblanc101):

 Why not use the priority+ pattern ?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/28983#comment:57>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 10:42:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 10:42:33 -0000
Subject: [wp-trac] [WordPress Trac] #65063: Classic Editor: slug editing
 field is too large
Message-ID: <053.e99112fe2c6dd2520e9b55ab9e698a2b@wordpress.org>

#65063: Classic Editor: slug editing field is too large
----------------------------+--------------------------
 Reporter:  wildworks       |      Owner:  (none)
     Type:  defect (bug)    |     Status:  new
 Priority:  normal          |  Milestone:  7.0
Component:  Administration  |    Version:
 Severity:  normal          |   Keywords:  admin-reskin
  Focuses:                  |
----------------------------+--------------------------
 Following a redesign of the form elements, the height of the slug editing
 field has changed from 30px to 40px.

 Since this is very large, I propose changing it to 32px. Additionally, the
 slug input field, OK button, and Cancel button should be properly aligned.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65063>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 10:42:41 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 10:42:41 -0000
Subject: [wp-trac] [WordPress Trac] #65063: Classic Editor: slug editing
 field is too large
In-Reply-To: <053.e99112fe2c6dd2520e9b55ab9e698a2b@wordpress.org>
References: <053.e99112fe2c6dd2520e9b55ab9e698a2b@wordpress.org>
Message-ID: <068.70c93fafdfc3e32fe97513b02836a9ed@wordpress.org>

#65063: Classic Editor: slug editing field is too large
----------------------------+---------------------
 Reporter:  wildworks       |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  admin-reskin    |     Focuses:
----------------------------+---------------------
Changes (by wildworks):

 * Attachment "post-slug-input-field-comparison.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65063>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 11:29:45 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 11:29:45 -0000
Subject: [wp-trac] [WordPress Trac] #7650: Multiple post authors
 (co-authors) (was: Multiple post authors)
In-Reply-To: <050.e4b07f5e42c530cc65f262977d80092a@wordpress.org>
References: <050.e4b07f5e42c530cc65f262977d80092a@wordpress.org>
Message-ID: <065.dec5bfaa587f6c0c6efe38189de6a530@wordpress.org>

#7650: Multiple post authors (co-authors)
--------------------------+-----------------------------
 Reporter:  radzio        |       Owner:  (none)
     Type:  enhancement   |      Status:  reopened
 Priority:  normal        |   Milestone:  Future Release
Component:  Users         |     Version:  2.7
 Severity:  normal        |  Resolution:
 Keywords:  dev-feedback  |     Focuses:
--------------------------+-----------------------------
Changes (by westonruter):

 * status:  closed => reopened
 * resolution:  maybelater =>
 * milestone:   => Future Release


Comment:

 With real-time collaboration to land in 7.0, the need for being able to
 attribute authorship to multiple authors seems to have grown. This feature
 was also requested during QA at WordCamp Asia 2026. So I'm re-opening this
 maybelater ticket because maybe later is now.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/7650#comment:21>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 12:22:00 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 12:22:00 -0000
Subject: [wp-trac] [WordPress Trac] #65053: Media upload from the post
 edit screen shows an inaccurate number when uploading multiple media files
In-Reply-To: <053.9dbb6fc319de35dce28f39fb3ef8f2fb@wordpress.org>
References: <053.9dbb6fc319de35dce28f39fb3ef8f2fb@wordpress.org>
Message-ID: <068.aeb8e99cb6ac64ccb2744a4fa51164da@wordpress.org>

#65053: Media upload from the post edit screen shows an inaccurate number when
uploading multiple media files
--------------------------+------------------------------
 Reporter:  Dharm1025     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Upload        |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  ui, javascript
--------------------------+------------------------------

Comment (by wildworks):

 My investigation on Playground revealed that this issue might have been
 present since at least WordPress 6.3. For some reason, the block editor
 and the core media modal may not be interacting correctly.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65053#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 12:33:27 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 12:33:27 -0000
Subject: [wp-trac] [WordPress Trac] #31992: Unicode Email Addresses
In-Reply-To: <051.16751f510c50d601687f280dca71804a@wordpress.org>
References: <051.16751f510c50d601687f280dca71804a@wordpress.org>
Message-ID: <066.d5ed9fb7c268ef4473263d46be03eaac@wordpress.org>

#31992: Unicode Email Addresses
-------------------------------------------------+-------------------------
 Reporter:  ysalame                              |       Owner:
                                                 |  SergeyBiryukov
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  7.1
Component:  Formatting                           |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-test-info has-patch has-         |     Focuses:
  screenshots has-unit-tests dev-feedback early  |
-------------------------------------------------+-------------------------
Description changed by dmsnell:

Old description:

> Tested against trunk (2015-04-16)
>
> '''Test case'''
> {{{
> $target_email = 'dummy-üñîçøðé.y.!#$%@üñîçøðé.gmail.com';
> echo $target_email.'<br>';
> echo sanitize_email($target_email).'<br>';
> echo 'is_email : '.is_email($target_email);
> }}}
>
> '''Return'''
> {{{
> dummy-üñîçøðé.y.!#$%@üñîçøðé.gmail.com
> dummy-email.y.!#$%@gmail.com
> is_email :
> }}}
>

> Function is_email @ /wp-includes/formatting.php line 2177
> Preg_replace @ line 2211 is not correct.
> {{{
> if ( !preg_match( '/^[a-zA-Z0-9!#$%&\'*+\/=?^_`{|}~\.-]+$/', $local ) ) {
> }}}
>
> Function sanitize_email() @ /wp-includes/formatting.php line 2430
> Preg_replace @ line 2460 is not correct.
> {{{
> $local = preg_replace( '/[^a-zA-Z0-9!#$%&\'*+\/=?^_`{|}~\.-]/', '',
> $local );
> }}}

New description:

 Tested against trunk (2015-04-16)

 '''Test case'''
 {{{
 $target_email = 'dummy-üñîçøðé.y.!#$%@üñîçøðé.gmail.com';
 echo $target_email.'<br>';
 echo sanitize_email($target_email).'<br>';
 echo 'is_email : '.is_email($target_email);
 }}}

 '''Return'''
 {{{
 dummy-üñîçøðé.y.!#$%@üñîçøðé.gmail.com
 dummy-email.y.!#$%@gmail.com
 is_email :
 }}}


 Function is_email @ /wp-includes/formatting.php line 2177
 Preg_replace @ line 2211 is not correct.
 {{{
 if ( !preg_match( '/^[a-zA-Z0-9!#$%&\'*+\/=?^_`{|}~\.-]+$/', $local ) ) {
 }}}

 Function sanitize_email() @ /wp-includes/formatting.php line 2430
 Preg_replace @ line 2460 is not correct.
 {{{
 $local = preg_replace( '/[^a-zA-Z0-9!#$%&\'*+\/=?^_`{|}~\.-]/', '', $local
 );
 }}}

 == Related

  - #24487 `is_email()` doesn’t recognize IDN domains.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/31992#comment:81>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 14:22:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 14:22:30 -0000
Subject: [wp-trac] [WordPress Trac] #31992: Unicode Email Addresses
In-Reply-To: <051.16751f510c50d601687f280dca71804a@wordpress.org>
References: <051.16751f510c50d601687f280dca71804a@wordpress.org>
Message-ID: <066.8f16731dfa05a63bc79d67cef0bdc839@wordpress.org>

#31992: Unicode Email Addresses
-------------------------------------------------+-------------------------
 Reporter:  ysalame                              |       Owner:
                                                 |  SergeyBiryukov
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  7.1
Component:  Formatting                           |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-test-info has-patch has-         |     Focuses:
  screenshots has-unit-tests dev-feedback early  |
-------------------------------------------------+-------------------------

Comment (by dmsnell):

 In [changeset:"62225" 62225]:
 {{{
 #!CommitTicketReference repository="" revision="62225"
 Email: Add unit tests covering email validation and sanitization.

 In preparation for later work to allow non-US-ASCII email addresses, this
 change extends the unit test suite for `is_email()` and adds new tests
 covering `antispambot()` and `sanitize_email()`.

 This work was done collaboratively during WordCamp Vienna, 2026 as a
 Contributor Challenge in cooperation with and support from ICANN and also
 GeoTLDs Universal Acceptance Local Initiative.

 Developed in: https://github.com/WordPress/wordpress-develop/pull/11552
 Discussed in: https://core.trac.wordpress.org/ticket/31992

 Props agulbra, akirk, benniledl, dmsnell.
 See #31992.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/31992#comment:83>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 14:55:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 14:55:07 -0000
Subject: [wp-trac] [WordPress Trac] #65047: Missing escaping for XML
 error message
In-Reply-To: <055.114e593d87c6f2e3617a84cdf8f35483@wordpress.org>
References: <055.114e593d87c6f2e3617a84cdf8f35483@wordpress.org>
Message-ID: <070.5991796dc7e16bdb8cbfb1019baf1a06@wordpress.org>

#65047: Missing escaping for XML error message
------------------------------+---------------------
 Reporter:  maheshpatel       |       Owner:  (none)
     Type:  defect (bug)      |      Status:  new
 Priority:  normal            |   Milestone:  7.1
Component:  Pings/Trackbacks  |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+---------------------
Changes (by SergeyBiryukov):

 * milestone:  Awaiting Review => 7.1


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65047#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 15:23:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 15:23:31 -0000
Subject: [wp-trac] [WordPress Trac] #65062: Revisions: buttons are
 misplaced
In-Reply-To: <053.b9ce602729457db6bab38d69686036f5@wordpress.org>
References: <053.b9ce602729457db6bab38d69686036f5@wordpress.org>
Message-ID: <068.8b424afc24c9bba4de39e9ee34c78799@wordpress.org>

#65062: Revisions: buttons are misplaced
------------------------------------+------------------------
 Reporter:  wildworks               |       Owner:  joedolson
     Type:  defect (bug)            |      Status:  accepted
 Priority:  normal                  |   Milestone:  7.0
Component:  Revisions               |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  admin-reskin has-patch  |     Focuses:
------------------------------------+------------------------
Changes (by joedolson):

 * owner:  (none) => joedolson
 * status:  new => accepted


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65062#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 15:24:20 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 15:24:20 -0000
Subject: [wp-trac] [WordPress Trac] #65063: Classic Editor: slug editing
 field is too large
In-Reply-To: <053.e99112fe2c6dd2520e9b55ab9e698a2b@wordpress.org>
References: <053.e99112fe2c6dd2520e9b55ab9e698a2b@wordpress.org>
Message-ID: <068.4e344a1e30339d526c858cb72dd75348@wordpress.org>

#65063: Classic Editor: slug editing field is too large
------------------------------------+------------------------
 Reporter:  wildworks               |       Owner:  joedolson
     Type:  defect (bug)            |      Status:  accepted
 Priority:  normal                  |   Milestone:  7.0
Component:  Administration          |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  admin-reskin has-patch  |     Focuses:
------------------------------------+------------------------
Changes (by joedolson):

 * owner:  (none) => joedolson
 * status:  new => accepted


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65063#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 16:49:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 16:49:14 -0000
Subject: [wp-trac] [WordPress Trac] #65033: Suggestion for commenting
 the format of DB_HOST in wp-config-sample.php
In-Reply-To: <052.9ae18080fb29b8e7d5d99df8ab0c3f15@wordpress.org>
References: <052.9ae18080fb29b8e7d5d99df8ab0c3f15@wordpress.org>
Message-ID: <067.3e837f6d6897721f3413ddc73b3e45b9@wordpress.org>

#65033: Suggestion for commenting the format of DB_HOST in wp-config-sample.php
-------------------------+------------------------------
 Reporter:  ralatalo     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:  6.9.4
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+------------------------------
Changes (by yasirkhalifa):

 * Attachment "65033.patch" added.

 patch file

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65033>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 16:50:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 16:50:48 -0000
Subject: [wp-trac] [WordPress Trac] #65033: Suggestion for commenting
 the format of DB_HOST in wp-config-sample.php
In-Reply-To: <052.9ae18080fb29b8e7d5d99df8ab0c3f15@wordpress.org>
References: <052.9ae18080fb29b8e7d5d99df8ab0c3f15@wordpress.org>
Message-ID: <067.a2edf036c105bf017e3b41528a1205d9@wordpress.org>

#65033: Suggestion for commenting the format of DB_HOST in wp-config-sample.php
-------------------------+------------------------------
 Reporter:  ralatalo     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:  6.9.4
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:
-------------------------+------------------------------
Changes (by yasirkhalifa):

 * keywords:   => has-patch


Comment:

 Patch adds clarification for DB_HOST to include port and socket formats.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65033#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 17:25:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 17:25:26 -0000
Subject: [wp-trac] [WordPress Trac] #7650: Multiple post authors
 (co-authors)
In-Reply-To: <050.e4b07f5e42c530cc65f262977d80092a@wordpress.org>
References: <050.e4b07f5e42c530cc65f262977d80092a@wordpress.org>
Message-ID: <065.4c66ed8a9d9af2826576c69c689445c0@wordpress.org>

#7650: Multiple post authors (co-authors)
--------------------------+-----------------------------
 Reporter:  radzio        |       Owner:  (none)
     Type:  enhancement   |      Status:  reopened
 Priority:  normal        |   Milestone:  Future Release
Component:  Users         |     Version:  2.7
 Severity:  normal        |  Resolution:
 Keywords:  dev-feedback  |     Focuses:
--------------------------+-----------------------------

Comment (by johnbillion):

 At Human Made we maintain [https://github.com/humanmade/authorship a
 plugin called Authorship] which is a modern replacement for Co-Authors
 Plus and others. The readme file includes a bunch of information about the
 design decisions, in particular storing author information in taxonomy
 terms, the REST API, WP-CLI, etc.

 I believe this is the most appropriate and most scalable architecture for
 multiple author attribution.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/7650#comment:22>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 18:45:54 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 18:45:54 -0000
Subject: [wp-trac] [WordPress Trac] #31992: Unicode Email Addresses
In-Reply-To: <051.16751f510c50d601687f280dca71804a@wordpress.org>
References: <051.16751f510c50d601687f280dca71804a@wordpress.org>
Message-ID: <066.f67e764cbd3d63230ddf6c8c36835a4f@wordpress.org>

#31992: Unicode Email Addresses
-------------------------------------------------+-------------------------
 Reporter:  ysalame                              |       Owner:
                                                 |  SergeyBiryukov
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  7.1
Component:  Formatting                           |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-test-info has-patch has-         |     Focuses:
  screenshots has-unit-tests dev-feedback early  |
-------------------------------------------------+-------------------------

Comment (by dmsnell):

 In [changeset:"62226" 62226]:
 {{{
 #!CommitTicketReference repository="" revision="62226"
 Email: Add unit tests covering email validation and sanitization. (Take 2)

 When the original patch from PR#11552 was merged, it did not include the
 latest version of the PR code, which had removed a failing test.

 This patch removes the failing test to match what ran in the tests on the
 PR.

 Developed in: https://github.com/WordPress/wordpress-develop/pull/11552
 Discussed in: https://core.trac.wordpress.org/ticket/31992

 Follow-up to: [62225].

 Props agulbra, akirk, benniledl, dmsnell.
 See #31992.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/31992#comment:84>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 11 23:54:11 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 11 Apr 2026 23:54:11 -0000
Subject: [wp-trac] [WordPress Trac] #64225: Test tool and unit test
 improvements for 7.0
In-Reply-To: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
References: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
Message-ID: <066.d161f08f2f13b923e689439b58894fc8@wordpress.org>

#64225: Test tool and unit test improvements for 7.0
--------------------------------------+---------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  task (blessed)            |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by SergeyBiryukov):

 In [changeset:"62227" 62227]:
 {{{
 #!CommitTicketReference repository="" revision="62227"
 Tests: Rename some oEmbed test classes as per the naming conventions.

 Includes moving the data provider after the corresponding test for
 consistency with the rest of the test suite.

 Follow-up to [34903], [62223], [62224].

 See #64225.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64225#comment:62>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 12 04:56:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 12 Apr 2026 04:56:26 -0000
Subject: [wp-trac] [WordPress Trac] #65060: Formatting issue on
 expand/collapse meta box area focus
In-Reply-To: <053.3f798f1a567cca7e0d02f86b0e08f865@wordpress.org>
References: <053.3f798f1a567cca7e0d02f86b0e08f865@wordpress.org>
Message-ID: <068.313779e7200de14c7bf67d265ce340c1@wordpress.org>

#65060: Formatting issue on expand/collapse meta box area focus
--------------------------------------------------+---------------------
 Reporter:  brianhogg                             |       Owner:  (none)
     Type:  defect (bug)                          |      Status:  new
 Priority:  normal                                |   Milestone:  7.0
Component:  Formatting                            |     Version:  trunk
 Severity:  normal                                |  Resolution:
 Keywords:  admin-reskin has-patch needs-testing  |     Focuses:
--------------------------------------------------+---------------------
Changes (by audrasjb):

 * keywords:  admin-reskin has-patch => admin-reskin has-patch needs-testing


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65060#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 12 05:02:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 12 Apr 2026 05:02:09 -0000
Subject: [wp-trac] [WordPress Trac] #65061: Meta boxes hidden by default
In-Reply-To: <053.cb8a45694752c4e422b93727577c46d7@wordpress.org>
References: <053.cb8a45694752c4e422b93727577c46d7@wordpress.org>
Message-ID: <068.5dc664dd8a27da6e6183e2abe8bd57b2@wordpress.org>

#65061: Meta boxes hidden by default
--------------------------+------------------------------
 Reporter:  brianhogg     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by audrasjb):

 @wildworks I may be wrong, but I believe the correct reproduction steps
 are:
 1. Access ​https://playground.wordpress.net/?wp=beta
 2. Install a plugin that shows a meta box in the editor, like Yoast for
 example
 3. Open a post
 4. The metabox is collapsed by default

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65061#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 12 05:02:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 12 Apr 2026 05:02:23 -0000
Subject: [wp-trac] [WordPress Trac] #65061: Meta boxes hidden by default
In-Reply-To: <053.cb8a45694752c4e422b93727577c46d7@wordpress.org>
References: <053.cb8a45694752c4e422b93727577c46d7@wordpress.org>
Message-ID: <068.e87d6238fe3ed286f4d17435e34deb20@wordpress.org>

#65061: Meta boxes hidden by default
--------------------------+------------------------------
 Reporter:  brianhogg     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Changes (by audrasjb):

 * component:  General => Editor


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65061#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 12 06:50:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 12 Apr 2026 06:50:53 -0000
Subject: [wp-trac] [WordPress Trac] #65064: Flaky test:
 test_get_theme_featured_list_api fails with external HTTP unavailability
Message-ID: <055.dca23389f0fdd68291955432ac6fc1d5@wordpress.org>

#65064: Flaky test: test_get_theme_featured_list_api fails with external HTTP
unavailability
------------------------------+-----------------------------
 Reporter:  rakeshfalke       |      Owner:  (none)
     Type:  defect (bug)      |     Status:  new
 Priority:  normal            |  Milestone:  Awaiting Review
Component:  Build/Test Tools  |    Version:  trunk
 Severity:  normal            |   Keywords:  has-test-info
  Focuses:  tests             |
------------------------------+-----------------------------
 The test file:
 tests/phpunit/tests/admin/includesTheme.php::test_get_theme_featured_list_api
 Error message about WordPress.org API unavailability
 That it's marked with @group external-http
 Reference job ID: 70948707430
 Your suggested fix (mock the API or skip gracefully)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65064>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 12 14:25:46 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 12 Apr 2026 14:25:46 -0000
Subject: [wp-trac] [WordPress Trac] #64225: Test tool and unit test
 improvements for 7.0
In-Reply-To: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
References: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
Message-ID: <066.9439488ee9fafe497fdd610842be57c6@wordpress.org>

#64225: Test tool and unit test improvements for 7.0
--------------------------------------+---------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  task (blessed)            |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by SergeyBiryukov):

 In [changeset:"62228" 62228]:
 {{{
 #!CommitTicketReference repository="" revision="62228"
 Tests: Expand `@covers` tags for `WP_oEmbed` tests.

 Follow-up to [62223].

 See #64225.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64225#comment:63>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 12 20:35:45 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 12 Apr 2026 20:35:45 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.26706d2a07deacae73839fd5a60e1d55@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
--------------------------------------+-------------------------------
 Reporter:  jorgefilipecosta          |       Owner:  jorgefilipecosta
     Type:  feature request           |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.0
Component:  Plugins                   |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------------

Comment (by matt):

 Replying to [comment:12 peterwilsoncc]:
 > I think Akismet API registration belongs in the plugin, per
 [https://make.wordpress.org/core/2026/02/03/proposal-for-merging-wp-ai-
 client-into-wordpress-7-0/#comment-48384 Matt's comment on the AI client
 merbe proposal]:

 I did say that, and have changed my mind and we're doing this.

 Let's and pick up the debate for 7.1 in Slack and other places where it's
 easier to communicate.

 I have rewritten this comment 4 times and gotten to 500+ words realizing
 I'm doing the exact mistake I'm trying to point out: spending time arguing
 about other things instead of resolving this thing so we can move on. And
 now I will move to Slack.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:48>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 12 21:06:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 12 Apr 2026 21:06:49 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2364988=3A_Enhancement?=
 =?utf-8?q?=3A_Add_support_for_displaying_child_categories_in_Navigation_?=
 =?utf-8?q?=E2=80=9CCategory_Link=E2=80=9D_block_=28dropdown_support=29?=
In-Reply-To: <052.f84d64c777d845b9acf79e0e942f86ff@wordpress.org>
References: <052.f84d64c777d845b9acf79e0e942f86ff@wordpress.org>
Message-ID: <067.4181ffe81aafdacafe5a1962577fb1c9@wordpress.org>

#64988: Enhancement: Add support for displaying child categories in Navigation
“Category Link” block (dropdown support)
-------------------------+------------------------------
 Reporter:  wpsharif     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:  6.9.4
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+------------------------------

Comment (by priyanshuhaldar):

 There is a workaround for this. You can add the sub-menu block and then
 add text for the primary menu item and link it to the parent category
 manually. Then, in the sub-menu item, add the category link block and link
 the child category there.

 Though I'm working on a feature to add a sidebar control for the category
 link block to choose to display the child categories. Will be sharing an
 update here.

 Check demo recording here:
 https://drive.google.com/file/d/135ozgWui6jHb4MXJkfF1ehHoncN4KkWW/view?usp=sharing

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64988#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 12 21:13:10 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 12 Apr 2026 21:13:10 -0000
Subject: [wp-trac] [WordPress Trac] #65065: white bar
Message-ID: <055.c1583559ca6434bca415df7c31d80e4f@wordpress.org>

#65065: white bar
-------------------------+-----------------------------
 Reporter:  micekflicek  |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  General      |    Version:
 Severity:  normal       |   Keywords:
  Focuses:               |
-------------------------+-----------------------------
 I'm trying to use WooCommerce. But there's a white bar at the top with
 information that I don't care about, whose main function is to hide the
 controls I need to use. I can't scroll down to them, I can't make the bar
 invisible, I don't see a way I can continue using Woo. Whoever came up
 with this deserves to be dragged with a shovel. I really want instructions
 on what to do with it, it's unusable like this.
 I'd like to send you a screenshot, but you've done everything you can to
 make it impossible.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65065>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 00:09:20 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 00:09:20 -0000
Subject: [wp-trac] [WordPress Trac] #36710: Symlinked directories should
 not be deleted recursively
In-Reply-To: <048.ef6e38ed06a006607f1b9410360ae699@wordpress.org>
References: <048.ef6e38ed06a006607f1b9410360ae699@wordpress.org>
Message-ID: <063.0b821741ba612f8a0beb51a9167a2918@wordpress.org>

#36710: Symlinked directories should not be deleted recursively
-------------------------------------------------+-------------------------
 Reporter:  andy                                 |       Owner:  (none)
     Type:  feature request                      |      Status:  reopened
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Filesystem API                       |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-test-info dev-         |     Focuses:
  feedback needs-dev-note                        |  administration
-------------------------------------------------+-------------------------

Comment (by shaneonabike):

 I'm not sure I fully understand what @SirLouen results were? Does the
 question mean that it doesn't work or they are unsure if it works?.
 Regardless, I do think that this is a good feature to add.

 In our case, we basically maintain a platform for clients to provide a
 more low-cost option for non-profits. We update that platform with plugins
 which are symlinked to their actual site. Sometimes people end up deleting
 the plugins that are _shared_ and thus the files in the symlink are
 completed removed.

 Even if we had a `DEFINE` that would regulate the switching on/off of this
 it could be really helpful as a means to prevent symlink content from
 being deleted.

 I can't attend for other file systems though.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/36710#comment:33>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 02:58:50 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 02:58:50 -0000
Subject: [wp-trac] [WordPress Trac] #65061: Meta boxes hidden by default
In-Reply-To: <053.cb8a45694752c4e422b93727577c46d7@wordpress.org>
References: <053.cb8a45694752c4e422b93727577c46d7@wordpress.org>
Message-ID: <068.9ed94f3924922aafd069b1d573d5d276@wordpress.org>

#65061: Meta boxes hidden by default
--------------------------+------------------------------
 Reporter:  brianhogg     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  close         |     Focuses:
--------------------------+------------------------------
Changes (by wildworks):

 * keywords:   => close


Comment:

 I was mistaken. The height of the metabox is persisted as a user setting
 in either the database or the browser's local storage. Therefore, the test
 results will vary depending on whether the metabox height has been
 manipulated.

 Technically, this issue should also occur if you perform a fresh
 installation of 6.9. The default for the metabox should be collapsed.

 I propose closing this ticket and then submitting an issue to the
 Gutenberg repo to change the default behavior of metaboxes.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65061#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 05:46:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 05:46:57 -0000
Subject: [wp-trac] [WordPress Trac] #65065: white bar
In-Reply-To: <055.c1583559ca6434bca415df7c31d80e4f@wordpress.org>
References: <055.c1583559ca6434bca415df7c31d80e4f@wordpress.org>
Message-ID: <070.bc743c124e075b2bf56243febd571fb9@wordpress.org>

#65065: white bar
-------------------------+----------------------
 Reporter:  micekflicek  |       Owner:  (none)
     Type:  enhancement  |      Status:  closed
 Priority:  normal       |   Milestone:
Component:  General      |     Version:
 Severity:  normal       |  Resolution:  invalid
 Keywords:               |     Focuses:
-------------------------+----------------------
Changes (by poena):

 * status:  new => closed
 * resolution:   => invalid
 * milestone:  Awaiting Review =>


Comment:

 Hi @micekflicek

 This ticket system is not used for support for plugins, it is used to
 report bugs and feature requests for WordPress itself.

 Kindly use the support forum for WooCommerce.
 https://wordpress.org/support/topic/read-before-posting-how-to-get-
 woocommerce-support-and-what-info-to-provide/

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65065#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 06:01:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 06:01:33 -0000
Subject: [wp-trac] [WordPress Trac] #65059: Modal overlapping the
 content editor
In-Reply-To: <053.ac94bd0341e39f512163215cdcda4a2c@wordpress.org>
References: <053.ac94bd0341e39f512163215cdcda4a2c@wordpress.org>
Message-ID: <068.5801694dad249e172e579421950fcef5@wordpress.org>

#65059: Modal overlapping the content editor
-------------------------------+------------------------------
 Reporter:  brianhogg          |       Owner:  (none)
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  General            |     Version:  trunk
 Severity:  normal             |  Resolution:
 Keywords:  reporter-feedback  |     Focuses:
-------------------------------+------------------------------
Changes (by poena):

 * keywords:   => reporter-feedback


Comment:

 Hi @brianhogg

 I installed the plugin and I am not sure if this is a bug?
 You meantioned "now" but it is unclear if this is a recent change in an
 update of WordPress, and what the expectation, the "correct behavior"
 actually is?

 Have you sent a support request to LifterLMS?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65059#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 06:10:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 06:10:05 -0000
Subject: [wp-trac] [WordPress Trac] #65060: Formatting issue on
 expand/collapse meta box area focus
In-Reply-To: <053.3f798f1a567cca7e0d02f86b0e08f865@wordpress.org>
References: <053.3f798f1a567cca7e0d02f86b0e08f865@wordpress.org>
Message-ID: <068.f0b0b2d31f8814bd1b178cc2f6b1e5b6@wordpress.org>

#65060: Formatting issue on expand/collapse meta box area focus
--------------------------------------------------+---------------------
 Reporter:  brianhogg                             |       Owner:  (none)
     Type:  defect (bug)                          |      Status:  new
 Priority:  normal                                |   Milestone:  7.0
Component:  Formatting                            |     Version:  trunk
 Severity:  normal                                |  Resolution:
 Keywords:  admin-reskin has-patch needs-testing  |     Focuses:
--------------------------------------------------+---------------------

Comment (by poena):

 PR 11550 solves the issue for me (I only tested in Chrome on Windows).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65060#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 07:09:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 07:09:22 -0000
Subject: [wp-trac] [WordPress Trac] #65004: Prev/Next for posts needs
 context in block library
In-Reply-To: <052.63f4ad3e35370ac88b08f873bc0bb708@wordpress.org>
References: <052.63f4ad3e35370ac88b08f873bc0bb708@wordpress.org>
Message-ID: <067.2b5bace36059c50fc27fd3140785e473@wordpress.org>

#65004: Prev/Next for posts needs context in block library
--------------------------+--------------------------------
 Reporter:  timse201      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  I18N          |     Version:
 Severity:  normal        |  Resolution:  reported-upstream
 Keywords:  has-patch     |     Focuses:
--------------------------+--------------------------------
Changes (by poena):

 * status:  new => closed
 * resolution:   => reported-upstream
 * milestone:  Awaiting Review =>


Comment:

 Hi
 Thank you for the suggestion and the PR.

 This is already solved in Gutenberg, and no change is needed here.
 https://github.com/WordPress/gutenberg/pull/76967

 This is because the change from Gutenberg will be merged in to WordPress
 in the next available release.
 So the changes in the PR linked to this ticket would be overwritten.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65004#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 07:16:38 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 07:16:38 -0000
Subject: [wp-trac] [WordPress Trac] #65004: Prev/Next for posts needs
 context in block library
In-Reply-To: <052.63f4ad3e35370ac88b08f873bc0bb708@wordpress.org>
References: <052.63f4ad3e35370ac88b08f873bc0bb708@wordpress.org>
Message-ID: <067.e8fad07bdfb5f1644d07998556ad9a59@wordpress.org>

#65004: Prev/Next for posts needs context in block library
--------------------------+--------------------------------
 Reporter:  timse201      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  I18N          |     Version:
 Severity:  normal        |  Resolution:  reported-upstream
 Keywords:  has-patch     |     Focuses:
--------------------------+--------------------------------

Comment (by poena):

 Please correct me if this was not related to the lightbox, the ticket can
 always be reopened.
 The next and previous **post** links already has translators context since
 5 years.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65004#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 07:30:10 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 07:30:10 -0000
Subject: [wp-trac] [WordPress Trac] #64225: Test tool and unit test
 improvements for 7.0
In-Reply-To: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
References: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
Message-ID: <066.fb538125e71474e18dc586c7405fb796@wordpress.org>

#64225: Test tool and unit test improvements for 7.0
--------------------------------------+---------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  task (blessed)            |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by SergeyBiryukov):

 In [changeset:"62229" 62229]:
 {{{
 #!CommitTicketReference repository="" revision="62229"
 Tests: Expand `@covers` tags for `WP_Embed` tests.

 Includes removing the `external-http` group for a
 `WP_Embed::run_shortcode()` test which does not perform any HTTP requests.

 Follow-up to [50448], [62223], [62228].

 See #64225.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64225#comment:64>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 08:24:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 08:24:09 -0000
Subject: [wp-trac] [WordPress Trac] #65004: Prev/Next for posts needs
 context in block library
In-Reply-To: <052.63f4ad3e35370ac88b08f873bc0bb708@wordpress.org>
References: <052.63f4ad3e35370ac88b08f873bc0bb708@wordpress.org>
Message-ID: <067.64fc2f4033ccc9db0786bb59f5dd5fac@wordpress.org>

#65004: Prev/Next for posts needs context in block library
--------------------------+--------------------------------
 Reporter:  timse201      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  I18N          |     Version:
 Severity:  normal        |  Resolution:  reported-upstream
 Keywords:  has-patch     |     Focuses:
--------------------------+--------------------------------

Comment (by timse201):

 Replying to [comment:4 poena]:
 > Please correct me if this was not related to the lightbox, the ticket
 can always be reopened.
 > The next and previous **post** links already has translators context
 since 5 years.

 Not for next/previous. And the second ones are with comments.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65004#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 08:24:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 08:24:16 -0000
Subject: [wp-trac] [WordPress Trac] #65004: Prev/Next for posts needs
 context in block library
In-Reply-To: <052.63f4ad3e35370ac88b08f873bc0bb708@wordpress.org>
References: <052.63f4ad3e35370ac88b08f873bc0bb708@wordpress.org>
Message-ID: <067.33e9ecc5ab2212b709c1c10945b97f0f@wordpress.org>

#65004: Prev/Next for posts needs context in block library
--------------------------+-----------------------
 Reporter:  timse201      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:
Component:  I18N          |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+-----------------------
Changes (by timse201):

 * status:  closed => reopened
 * resolution:  reported-upstream =>


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65004#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 09:04:45 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 09:04:45 -0000
Subject: [wp-trac] [WordPress Trac] #64536: About Page - 7.0
In-Reply-To: <051.70759fa0a8836490f78fb36a7530ec61@wordpress.org>
References: <051.70759fa0a8836490f78fb36a7530ec61@wordpress.org>
Message-ID: <066.3545f4b1dca0f773db09c9c3ff0e9e03@wordpress.org>

#64536: About Page - 7.0
----------------------------+---------------------
 Reporter:  desrosj         |       Owner:  (none)
     Type:  task (blessed)  |      Status:  new
 Priority:  normal          |   Milestone:  7.0
Component:  Help/About      |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:
----------------------------+---------------------

Comment (by fcoveram):

 I like the idea of having rounded corners in all headers, but I will
 follow the radius value that comes from the admin style feature. That
 means applying a 8px border radius to the image directly via CSS.

 If we agree with this idea. We could also level up the layout by adding a
 8px gap between the header and the tab section, and reduce the border
 decorative element of the active tab to be 4px.

 Here is a test of the above I made on my browser's inspector:
 https://cleanshot.com/share/lM1WYSj6

 What do you think of this?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64536#comment:30>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 10:09:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 10:09:17 -0000
Subject: [wp-trac] [WordPress Trac] #65066: Display font size value in the
 input field
Message-ID: <057.aee825565dad51d08772a192fafa94fa@wordpress.org>

#65066: Display font size value in the input field
---------------------------+-----------------------------
 Reporter:  mehrazmorshed  |      Owner:  (none)
     Type:  enhancement    |     Status:  new
 Priority:  normal         |  Milestone:  Awaiting Review
Component:  General        |    Version:  trunk
 Severity:  minor          |   Keywords:
  Focuses:  ui             |
---------------------------+-----------------------------
 Since there is already a value of font size, may we display it in the
 input field?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65066>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 10:09:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 10:09:29 -0000
Subject: [wp-trac] [WordPress Trac] #65066: Display font size value in
 the input field
In-Reply-To: <057.aee825565dad51d08772a192fafa94fa@wordpress.org>
References: <057.aee825565dad51d08772a192fafa94fa@wordpress.org>
Message-ID: <072.cac9267c14e9d991e63c4f73dfccb3fb@wordpress.org>

#65066: Display font size value in the input field
---------------------------+------------------------------
 Reporter:  mehrazmorshed  |       Owner:  (none)
     Type:  enhancement    |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  General        |     Version:  trunk
 Severity:  minor          |  Resolution:
 Keywords:                 |     Focuses:  ui
---------------------------+------------------------------
Changes (by mehrazmorshed):

 * Attachment "Screenshot at Apr 13 16-05-19.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65066>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 10:18:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 10:18:49 -0000
Subject: [wp-trac] [WordPress Trac] #65066: Display font size value in
 the input field
In-Reply-To: <057.aee825565dad51d08772a192fafa94fa@wordpress.org>
References: <057.aee825565dad51d08772a192fafa94fa@wordpress.org>
Message-ID: <072.ebb8d9e7ccee39b52064bc4b4445d219@wordpress.org>

#65066: Display font size value in the input field
---------------------------+--------------------------------
 Reporter:  mehrazmorshed  |       Owner:  (none)
     Type:  enhancement    |      Status:  closed
 Priority:  normal         |   Milestone:
Component:  General        |     Version:  trunk
 Severity:  minor          |  Resolution:  reported-upstream
 Keywords:                 |     Focuses:  ui
---------------------------+--------------------------------
Changes (by poena):

 * status:  new => closed
 * resolution:   => reported-upstream
 * milestone:  Awaiting Review =>


Comment:

 Hi @mehrazmorshed

 Feature requests and bug reports for the block editor need to be opened in
 the Gutenberg GitHub repository.
 The changes are tested in the plugin before they are added to WordPress.

 There is already an open issue for this
 https://github.com/WordPress/gutenberg/issues/37752

 Displaying the defaults is something that many agree on, but there is no
 solution for it yet.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65066#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 11:01:34 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 11:01:34 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2364962=3A_Install_scr?=
 =?utf-8?b?ZWVuczog4oCcTG9nIElu4oCdIGFuZCAiU3VwcG9ydCBsaW5rIiB1c2Ugb2xk?=
 =?utf-8?q?_color?=
In-Reply-To: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
References: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
Message-ID: <074.95e60e14e3c6010523e44f2a131e0470@wordpress.org>

#64962: Install screens: “Log In” and "Support link" use old color
-------------------------------------------------+-------------------------
 Reporter:  huzaifaalmesbah                      |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch has-          |     Focuses:  ui, css
  screenshots                                    |
-------------------------------------------------+-------------------------
Changes (by wildworks):

 * keywords:  admin-reskin has-patch has-screenshots changes-requested =>
     admin-reskin has-patch has-screenshots


Comment:

 I think [https://github.com/WordPress/wordpress-develop/pull/11373 PR
 11373] is ready for commit.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64962#comment:20>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 11:19:11 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 11:19:11 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.e642fa9efede0b329b3ebfacf7a73c71@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
-------------------------------------+-------------------------------------
 Reporter:  piyushpatel123           |       Owner:  audrasjb
     Type:  defect (bug)             |      Status:  accepted
 Priority:  normal                   |   Milestone:  7.0
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  needs-testing has-patch  |     Focuses:  ui, css,
  admin-reskin                       |  administration
-------------------------------------+-------------------------------------

Comment (by ankitkumarshah):

 Hi everyone,

 Thank you for testing the PR. I’ve made some changes on PR and re-tested
 it on my end. It appears that the icon is now perfectly centered, with
 both the top and bottom spacing measuring 13px.

 Screenshots attached for reference.

 [[Image(https://i.postimg.cc/mkNrD43k/Screenshot-2026-04-13-at-4-38-58-PM.png)]]

 [[Image(https://i.postimg.cc/J7gxcLWs/Screenshot-2026-04-13-at-4-46-32-PM.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 11:32:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 11:32:53 -0000
Subject: [wp-trac] [WordPress Trac] #65060: Formatting issue on
 expand/collapse meta box area focus
In-Reply-To: <053.3f798f1a567cca7e0d02f86b0e08f865@wordpress.org>
References: <053.3f798f1a567cca7e0d02f86b0e08f865@wordpress.org>
Message-ID: <068.77c9e45eb26dc993c43c7c83e49b46a3@wordpress.org>

#65060: Formatting issue on expand/collapse meta box area focus
------------------------------------+---------------------
 Reporter:  brianhogg               |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  Formatting              |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  admin-reskin has-patch  |     Focuses:
------------------------------------+---------------------
Changes (by abcd95):

 * keywords:  admin-reskin has-patch needs-testing => admin-reskin has-patch


Comment:

 == Test Report
 === Description
 This report validates that the indicated patch works as expected.

 Patch tested: https://patch-diff.githubusercontent.com/raw/WordPress
 /wordpress-develop/pull/11550.diff

 === Environment
 - WordPress: 7.1-alpha-62161-src
 - PHP: 8.3.30
 - Server: nginx/1.29.8
 - Database: mysqli (Server: 8.4.8 / Client: mysqlnd 8.3.30)
 - Browser: Firefox 149.0
 - OS: macOS
 - Theme: Twenty Twenty-Five 1.4
 - Plugins:
   * Classic Editor 1.6.7
   * Test Reports 1.2.0


 === Actual Results
 ✅ Issue resolved with the patch. The focus ring on the button now renders
 correctly, and the ring sits flush within the button boundary without
 overflowing.

 Patch works correctly in the Classic Editor as well. Meta box
 expand/collapse focus styling renders properly in both the block editor
 and the Classic Editor plugin (v1.6.7).


 === Supplemental Artifacts

 Block editor - before patch

 [[Image(https://i.ibb.co/5g9J7X2j/Screenshot-2026-04-13-at-16-51-11.png)]]



 Block editor - after patch

 [[Image(https://i.ibb.co/9Hcqv2p4/Screenshot-2026-04-13-at-16-50-30.png)]]


 Classic editor - before patch

 [[Image(https://i.ibb.co/PGt2CMvh/Screenshot-2026-04-13-at-16-54-28.png)]]


 Classic editor - after patch

 [[Image(https://i.ibb.co/fYtYtwSw/Screenshot-2026-04-13-at-16-53-09.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65060#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 11:42:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 11:42:18 -0000
Subject: [wp-trac] [WordPress Trac] #65067: Youtube shorts don't resize when
 viewed on mobile
Message-ID: <056.1a06ed0a802b39d709c617df193747a7@wordpress.org>

#65067: Youtube shorts don't resize when viewed on mobile
--------------------------+-----------------------------
 Reporter:  ashjaneclark  |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Embeds        |    Version:
 Severity:  normal        |   Keywords:
  Focuses:  css           |
--------------------------+-----------------------------
 I am trying to get youtube shorts, embedded via links, to respond to being
 viewed on mobile by resizing to fit the column like the landscape youtube
 links do. Instead they are overlapping and look messy when viewed on
 mobile:

 https://ashchalk.com/video-campaigns/

 I have asked various chat bots to help, and I have been online for two
 hours with WordPress support, they kept suggesting options but we were
 unable to come to a solution and the problem was not concluded. One issue
 seems to be that support was suggesting the same things that Claude was
 suggesting, and they were both referencing menu options in the WordPress
 interface that I could not see. I'm not sure if they are using
 instructions for an outdated version of WordPress interface, or if there
 is a difference in the interface in different countries. But I just need
 help in fixing what I hope should be a simple issue.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65067>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 12:42:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 12:42:16 -0000
Subject: [wp-trac] [WordPress Trac] #63085: "Login details" spam sent by
 from the account registration page
In-Reply-To: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
References: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
Message-ID: <066.9cb618e008a442be1084861f16e09427@wordpress.org>

#63085: "Login details" spam sent by from the account registration page
-------------------------------------------------+-------------------------
 Reporter:  cweiske                              |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Login and Registration               |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests has-test-   |     Focuses:
  info                                           |
-------------------------------------------------+-------------------------

Comment (by pavanpatil1):

 Patch Tested: https://github.com/WordPress/wordpress-develop/pull/11439

 **Environment:**

 WordPress: v7.0 RC
 PHP: 7.4
 Playground

 The patch is working fine. Usernames containing invalid characters (such
 as spaces or “www”) are rejected and able to register with correct
 username format ✅

 **Screenshots:**

 - Invalid username is not accepted: https://prnt.sc/s-LzXHdZ9FLI
 - Registration email is sent successfully when a valid email is provided:
 https://prnt.sc/lvDBzEZzfY2K

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63085#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 13:11:11 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 13:11:11 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.7c1cc790a4886beeda635277f95e458d@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
-------------------------------------+-------------------------------------
 Reporter:  piyushpatel123           |       Owner:  audrasjb
     Type:  defect (bug)             |      Status:  accepted
 Priority:  normal                   |   Milestone:  7.0
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  needs-testing has-patch  |     Focuses:  ui, css,
  admin-reskin                       |  administration
-------------------------------------+-------------------------------------

Comment (by ankitmaru):

 Thanks for the patch.

 [[Image(https://i.postimg.cc/dtC22NvD/Screenshot-2026-04-13-at-6-36-16-PM.png)]]

 Tested on my end looks good.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031#comment:17>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 13:18:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 13:18:21 -0000
Subject: [wp-trac] [WordPress Trac] #63085: "Login details" spam sent by
 from the account registration page
In-Reply-To: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
References: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
Message-ID: <066.23dd5b717233d7b4d746e5c9aa1ecba4@wordpress.org>

#63085: "Login details" spam sent by from the account registration page
-------------------------------------------------+-------------------------
 Reporter:  cweiske                              |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Login and Registration               |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests has-test-   |     Focuses:
  info                                           |
-------------------------------------------------+-------------------------

Comment (by cweiske):

 Thanks for the test.

 Note that usernames with spaces can still be registered. Just usernames
 with "<space>www." are rejected, and those that begin with "www.".

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63085#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 13:35:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 13:35:30 -0000
Subject: [wp-trac] [WordPress Trac] #65059: Modal overlapping the
 content editor
In-Reply-To: <053.ac94bd0341e39f512163215cdcda4a2c@wordpress.org>
References: <053.ac94bd0341e39f512163215cdcda4a2c@wordpress.org>
Message-ID: <068.fdf14b5167d58335b92a9b7cf36203e3@wordpress.org>

#65059: Modal overlapping the content editor
-------------------------------+------------------------------
 Reporter:  brianhogg          |       Owner:  (none)
     Type:  defect (bug)       |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  General            |     Version:  trunk
 Severity:  normal             |  Resolution:
 Keywords:  reporter-feedback  |     Focuses:
-------------------------------+------------------------------

Comment (by brianhogg):

 Hi @poena,

 In previous versions when the meta boxes were not isolated in an initially
 hidden and resizable container, modals appear as an overlay across the
 whole editor. This "scrolling up" effect will likely now happen with any
 modal that is triggered from within a meta box.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65059#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 13:50:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 13:50:03 -0000
Subject: [wp-trac] [WordPress Trac] #65032: View transition admin bar
 quirks
In-Reply-To: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
References: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
Message-ID: <067.4be114973a5050a7bce0ac1ce60b7bff@wordpress.org>

#65032: View transition admin bar quirks
----------------------------+--------------------------------
 Reporter:  zieladam        |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:  ui, accessibility
----------------------------+--------------------------------

Comment (by westonruter):

 @zieladam I'm struggling to see the exact issue from your video. I'm
 seeing a bit of a flicker in the admin bar, for example when navigating
 from the Dashboard to the Posts screen. Is that what you're referring to?
 I think this may be due to Command Palette node since it is
 revealed/populated with JavaScript with the page loads. We might want to
 hold painting until DOM load. See [https://github.com/WICG/view-
 transitions/blob/main/document-render-blocking.md#anti-flicker Anti-
 flickering] in the View Transitions repo.

 Closely related to this is the issue of Admin Notice instability (#45186,
 [https://core.trac.wordpress.org/ticket/45186#comment:14 comment]). This
 may be a workaround, however, for a more fundamental issue.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65032#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 14:02:10 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 14:02:10 -0000
Subject: [wp-trac] [WordPress Trac] #28983: Admin bar length or Admin
 bar on two line
In-Reply-To: <055.1cc2ce9927c5d66810d9ff533a0d820d@wordpress.org>
References: <055.1cc2ce9927c5d66810d9ff533a0d820d@wordpress.org>
Message-ID: <070.2b606d1f688b45729aff57d16d27fcf3@wordpress.org>

#28983: Admin bar length or Admin bar on two line
-------------------------------------------------+-------------------------
 Reporter:  korobochkin                          |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Toolbar                              |     Version:  4.3
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-design-feedback      |     Focuses:  ui, css
  changes-requested                              |
-------------------------------------------------+-------------------------
Changes (by westonruter):

 * owner:  KZeni => (none)


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/28983#comment:58>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 15:39:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 15:39:23 -0000
Subject: [wp-trac] [WordPress Trac] #65067: Youtube shorts don't resize
 when viewed on mobile
In-Reply-To: <056.1a06ed0a802b39d709c617df193747a7@wordpress.org>
References: <056.1a06ed0a802b39d709c617df193747a7@wordpress.org>
Message-ID: <071.0e206e86d2771eda39babe15912cb13a@wordpress.org>

#65067: Youtube shorts don't resize when viewed on mobile
--------------------------+------------------------------
 Reporter:  ashjaneclark  |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Embeds        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  css
--------------------------+------------------------------
Changes (by sabernhardt):

 * Attachment "alignleft-class.png" added.

 delete the alignleft class

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65067>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 15:40:04 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 15:40:04 -0000
Subject: [wp-trac] [WordPress Trac] #65067: Youtube shorts don't resize
 when viewed on mobile
In-Reply-To: <056.1a06ed0a802b39d709c617df193747a7@wordpress.org>
References: <056.1a06ed0a802b39d709c617df193747a7@wordpress.org>
Message-ID: <071.d69124d79ab537777182d3200e3cf1c3@wordpress.org>

#65067: Youtube shorts don't resize when viewed on mobile
--------------------------+------------------------------
 Reporter:  ashjaneclark  |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Embeds        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  css
--------------------------+------------------------------
Changes (by sabernhardt):

 * Attachment "columns-stack.png" added.

 Columns block, with 3 columns, allowed to stack

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65067>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 15:42:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 15:42:28 -0000
Subject: [wp-trac] [WordPress Trac] #65067: Youtube shorts don't resize
 when viewed on mobile
In-Reply-To: <056.1a06ed0a802b39d709c617df193747a7@wordpress.org>
References: <056.1a06ed0a802b39d709c617df193747a7@wordpress.org>
Message-ID: <071.6b874872b8686e7c607845ecb3e9f185@wordpress.org>

#65067: Youtube shorts don't resize when viewed on mobile
--------------------------+----------------------
 Reporter:  ashjaneclark  |       Owner:  (none)
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  Embeds        |     Version:
 Severity:  normal        |  Resolution:  invalid
 Keywords:                |     Focuses:  css
--------------------------+----------------------
Changes (by sabernhardt):

 * keywords:  has-patch =>
 * status:  new => closed
 * resolution:   => invalid
 * milestone:  Awaiting Review =>


Comment:

 Hi and welcome to WordPress Core Trac!

 The three embedded shorts have an `alignleft` class, which sets a minimum
 width of 280 pixels. The class likely was added when there was an
 alignment control in the block toolbar. Delete that from each YouTube
 Embed block, in the Additional CSS Class(es) field under Advanced.

 You might also want to move the embeds into Column blocks that are allowed
 to stack. Then narrower screens would not try to shrink the videos to less
 than [https://developers.google.com/youtube/terms/required-minimum-
 functionality?hl=en#embedded-youtube-player-size 200 pixels wide].

 > I'm not sure if they are using instructions for an outdated version of
 WordPress interface, or if there is a difference in the interface in
 different countries.

 Your site uses //WordPress.com//, which has a somewhat different interface
 than WordPress.org. That might be part of the confusion.

 > is there an issue with the Twenty Nineteen theme which is uniquely
 causing a problem here?

 The site uses the Saison theme. The PR added CSS for Twenty Nineteen, but
 I did not find a problem with embedded video shorts in that theme.

 I'll close the ticket because this is not a bug with WordPress core.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65067#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 15:45:54 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 15:45:54 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.6d1935b31f437866f2978a9f37d36d13@wordpress.org>

#65015: Connectors: Several strings are not translated
-------------------------------------------------+-----------------------
 Reporter:  369work                              |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  high                                 |   Milestone:  7.0
Component:  I18N                                 |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests connectors  |     Focuses:
-------------------------------------------------+-----------------------
Changes (by JeffPaul):

 * keywords:  has-patch has-unit-tests => has-patch has-unit-tests
               connectors


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 15:59:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 15:59:14 -0000
Subject: [wp-trac] [WordPress Trac] #31992: Unicode Email Addresses
In-Reply-To: <051.16751f510c50d601687f280dca71804a@wordpress.org>
References: <051.16751f510c50d601687f280dca71804a@wordpress.org>
Message-ID: <066.dcfc5ee4cc08a1ea410649736f9437d8@wordpress.org>

#31992: Unicode Email Addresses
-------------------------------------------------+-------------------------
 Reporter:  ysalame                              |       Owner:
                                                 |  SergeyBiryukov
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  7.1
Component:  Formatting                           |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-test-info has-patch has-         |     Focuses:
  screenshots has-unit-tests dev-feedback early  |
-------------------------------------------------+-------------------------

Comment (by dmsnell):

 Sharing for reference, because it was a nice blog post on email
 obfuscation, and this work touches `antispambot()`

 https://spencermortensen.com/articles/email-obfuscation/

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/31992#comment:86>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 16:07:52 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 16:07:52 -0000
Subject: [wp-trac] [WordPress Trac] #56904: Twenty Twenty-Two: Block
 Navigation "no decoration" does not work
In-Reply-To: <055.debb1425d8ea6348bb4d85a24ce94e15@wordpress.org>
References: <055.debb1425d8ea6348bb4d85a24ce94e15@wordpress.org>
Message-ID: <070.81be958cd4eb4ff41a5ae91cec67585e@wordpress.org>

#56904: Twenty Twenty-Two: Block Navigation "no decoration" does not work
---------------------------+------------------------------
 Reporter:  mrfoxtalbot    |       Owner:  (none)
     Type:  defect (bug)   |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  Bundled Theme  |     Version:
 Severity:  normal         |  Resolution:
 Keywords:  dev-feedback   |     Focuses:
---------------------------+------------------------------

Comment (by sabernhardt):

 The reported issue seems to have been fixed.

 - I reproduced the underline in WordPress 6.1 with Twenty Twenty-Two 1.3.
 - I did not have the underline when I selected the 'none' option, either
 in the editor or on the front end, with WordPress 7.0-RC2 and the latest
 Twenty Twenty-Two.

 The underline still appears in the `:hover` and `:focus` states. When the
 default is not underlined and someone selects the no-decoration option,
 that suggests a desire to remove decoration from additional states.
 However, I am not sure if //either// the theme or the block should assume
 that intent.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/56904#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 16:15:27 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 16:15:27 -0000
Subject: [wp-trac] [WordPress Trac] #58751: Add noindex to 404 template
 (was: we had the same problem, but spam links use tags,
 a follow-up to #52457)
In-Reply-To: <054.65118e4e24c485b282a16ef9b12f46f2@wordpress.org>
References: <054.65118e4e24c485b282a16ef9b12f46f2@wordpress.org>
Message-ID: <069.8a0714598e0763342187b8917075ca7a@wordpress.org>

#58751: Add noindex to 404 template
--------------------------+------------------------------
 Reporter:  patrickggg    |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+------------------------------
Changes (by sabernhardt):

 * keywords:   => needs-patch


Old description:

> This is a follow-up to #52457.
>
> we had the same problem, but spam links use tags, they don't directly
> intrude on our website. How do we add the code so that google doesn't
> index it?
>
> Example:
>
> https://hideurl.com/tag/%E5%81%87%E5%A4%9A%E5%93%A5%E5%AD%A6%E5%8E%86%E6%88%90%E7%BB%A9%E5%8D%95-(%E2%8F%A9%E5%8A%9E%E8%AF%81%E7%BD%91%E7%AB%99%E2%9C%94%EF%B8%8Fbbjjzz.com%E2%8F%AA)-%E5%81%87%E5%A4%9A%E5%93%A5%E5%AD%A6%E5%8E%86%E6%88%90%E7%BB%A9%E5%8D%95-%E5%8A%9E%E5%81%87%E8%8B%B1%E5%9B%BD%E8%B5%AB%E7%89%B9%E7%A6%8F%E5%BE%B7%E5%A4%A7%E5%AD%A6%E5%AD%A6%E5%8E%86%E6%96%87%E5%87%AD%E4%B8%8A%E6%B5%B7%E9%87%91%E5%B1%B1%E5%8C%BA-%E5%81%87%E5%A4%9A%E5%93%A5%E5%AD%A6%E5%8E%86%E6%88%90%E7%BB%A9%E5%8D%95-(%E2%8F%A9%E5%8A%9E%E8%AF%81%E7%BD%91%E7%AB%99%E2%9C%94%EF%B8%8Fbbjjzz.com%E2%8F%AA)-%E5%81%87%E5%A4%9A%E5%93%A5%E5%AD%A6%E5%8E%86%E6%88%90%E7%BB%A9%E5%8D%95-%E5%8A%9E%E5%81%87%E8%8B%B1%E5%9B%BD%E8%B5%AB%E7%89%B9%E7%A6%8F%E5%BE%B7%E5%A4%A7%E5%AD%A6%E5%AD%A6%E5%8E%86%E6%96%87%E5%87%AD

New description:

 This is a follow-up to #52457.

 we had the same problem, but spam links use tags, they don't directly
 intrude on our website. How do we add the code so that google doesn't
 index it?

 Example:

 `https://example.com/tag/%E5%81%87%E5%A4%9A%E5%93%A5%E5%AD%A6%E5%8E%86%E6%88%90%E7%BB%A9%E5%8D%95-(%E2%8F%A9%E5%8A%9E%E8%AF%81%E7%BD%91%E7%AB%99%E2%9C%94%EF%B8%8Fbbjjzz.com%E2%8F%AA)-%E5%81%87%E5%A4%9A%E5%93%A5%E5%AD%A6%E5%8E%86%E6%88%90%E7%BB%A9%E5%8D%95-%E5%8A%9E%E5%81%87%E8%8B%B1%E5%9B%BD%E8%B5%AB%E7%89%B9%E7%A6%8F%E5%BE%B7%E5%A4%A7%E5%AD%A6%E5%AD%A6%E5%8E%86%E6%96%87%E5%87%AD%E4%B8%8A%E6%B5%B7%E9%87%91%E5%B1%B1%E5%8C%BA-%E5%81%87%E5%A4%9A%E5%93%A5%E5%AD%A6%E5%8E%86%E6%88%90%E7%BB%A9%E5%8D%95-(%E2%8F%A9%E5%8A%9E%E8%AF%81%E7%BD%91%E7%AB%99%E2%9C%94%EF%B8%8Fbbjjzz.com%E2%8F%AA)-%E5%81%87%E5%A4%9A%E5%93%A5%E5%AD%A6%E5%8E%86%E6%88%90%E7%BB%A9%E5%8D%95-%E5%8A%9E%E5%81%87%E8%8B%B1%E5%9B%BD%E8%B5%AB%E7%89%B9%E7%A6%8F%E5%BE%B7%E5%A4%A7%E5%AD%A6%E5%AD%A6%E5%8E%86%E6%96%87%E5%87%AD`

--

Comment:

 Hi and welcome to WordPress Core Trac!

 When I visited a nonexistent tag archive, these were the `robots` meta
 tags:

 **Core** default (trunk)
 `<meta name='robots' content='max-image-preview:large' />`

 **All in One SEO** 4.9.5.1
 `<meta name="robots" content="noindex" />`
 (plugin has an `aioseo_404_robots` filter to override this specifically)

 **Yoast SEO** 27.3
 `<meta name='robots' content='noindex, follow' />`

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/58751#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 19:54:35 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 19:54:35 -0000
Subject: [wp-trac] [WordPress Trac] #65062: Revisions: buttons are
 misplaced
In-Reply-To: <053.b9ce602729457db6bab38d69686036f5@wordpress.org>
References: <053.b9ce602729457db6bab38d69686036f5@wordpress.org>
Message-ID: <068.597c507f4020af858d5020e1f4b046d8@wordpress.org>

#65062: Revisions: buttons are misplaced
------------------------------------+------------------------
 Reporter:  wildworks               |       Owner:  joedolson
     Type:  defect (bug)            |      Status:  accepted
 Priority:  normal                  |   Milestone:  7.0
Component:  Revisions               |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  admin-reskin has-patch  |     Focuses:
------------------------------------+------------------------

Comment (by Presskopp):

 related: #64930

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65062#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 13 21:22:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 13 Apr 2026 21:22:14 -0000
Subject: [wp-trac] [WordPress Trac] #65068: PHP warnings when a registered
 oEmbed provider is malformed
Message-ID: <054.c667f79a728d296763b2f67622b647d2@wordpress.org>

#65068: PHP warnings when a registered oEmbed provider is malformed
--------------------------+-----------------------------
 Reporter:  bradshawtm    |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Embeds        |    Version:
 Severity:  minor         |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 There's no gate to ensure oEmbed providers are valid, so when they're not,
 one gets these warnings:


 {{{
 PHP Warning:  Undefined array key 0 in /var/www/html/wp-includes/class-wp-
 oembed.php on line 276
 PHP Warning:  Undefined array key 1 in /var/www/html/wp-includes/class-wp-
 oembed.php on line 276
 }}}

 To reproduce:

 First, add an `mu-plugin` (this same errant structure was seen in the
 wild):
 {{{
 <?php
 add_filter(
         'oembed_providers',
         function ( $providers ) {
                 $providers['bad_provider'] = array(
                         'url'      => '#https?://example\.site/.*#i',
                         'endpoint' => 'https://example.site/api/oembed',
                 );
                 return $providers;
         }
 );
 }}}

 1. Go to a new post page.
 2. Paste a URL that doesn't have an oEmbed, e.g.
 `https://en.wikipedia.org/wiki/Rickrolling`
 3. Do NOT click "Convert to link".
 4. Refresh the post.

 Each refresh will show the set of warnings.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65068>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 01:34:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 01:34:07 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.18fd27a79506349d62198511ad5d63bf@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
--------------------------------------+-------------------------------
 Reporter:  jorgefilipecosta          |       Owner:  jorgefilipecosta
     Type:  feature request           |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.0
Component:  Plugins                   |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------------

Comment (by lukecarbis):

 While I don't agree with including Akismet as a default option in the list
 of Connectors, since @matt has asked us to move forward with including it,
 can we please have it as a permanent option, available whether Akismet is
 installed or not. The same deal as Anthropic, ChatGPT, and Google – in the
 defaults array specified by the
 `_wp_connectors_register_default_ai_providers` function.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:50>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 02:39:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 02:39:16 -0000
Subject: [wp-trac] [WordPress Trac] #65022: Posts list: replace (no
 title) filler when a title isn't set with something more useful.
In-Reply-To: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
References: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
Message-ID: <067.584c6a5788f69b9cfd58bc02b32c1ea4@wordpress.org>

#65022: Posts list: replace (no title) filler when a title isn't set with something
more useful.
-------------------------------+-----------------------------
 Reporter:  annezazu           |       Owner:  SergeyBiryukov
     Type:  enhancement        |      Status:  accepted
 Priority:  normal             |   Milestone:  7.1
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:  has-patch          |     Focuses:  administration
-------------------------------+-----------------------------
Changes (by JeffPaul):

 * Attachment "IMG_8296.png" added.

 All Pages, compact view

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65022>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 02:39:41 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 02:39:41 -0000
Subject: [wp-trac] [WordPress Trac] #65022: Posts list: replace (no
 title) filler when a title isn't set with something more useful.
In-Reply-To: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
References: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
Message-ID: <067.50ea41c971f8e0e48a6ccbb718b5aff1@wordpress.org>

#65022: Posts list: replace (no title) filler when a title isn't set with something
more useful.
-------------------------------+-----------------------------
 Reporter:  annezazu           |       Owner:  SergeyBiryukov
     Type:  enhancement        |      Status:  accepted
 Priority:  normal             |   Milestone:  7.1
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:  has-patch          |     Focuses:  administration
-------------------------------+-----------------------------
Changes (by JeffPaul):

 * Attachment "IMG_8297.png" added.

 All Pages, extended view

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65022>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 02:41:32 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 02:41:32 -0000
Subject: [wp-trac] [WordPress Trac] #65022: Posts list: replace (no
 title) filler when a title isn't set with something more useful.
In-Reply-To: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
References: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
Message-ID: <067.e13c47982490abf7fa258b455261229c@wordpress.org>

#65022: Posts list: replace (no title) filler when a title isn't set with something
more useful.
-------------------------------+-----------------------------
 Reporter:  annezazu           |       Owner:  SergeyBiryukov
     Type:  enhancement        |      Status:  accepted
 Priority:  normal             |   Milestone:  7.1
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:  has-patch          |     Focuses:  administration
-------------------------------+-----------------------------
Changes (by JeffPaul):

 * Attachment "IMG_8298.png" added.

 All Posts, compact view

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65022>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 02:41:52 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 02:41:52 -0000
Subject: [wp-trac] [WordPress Trac] #65022: Posts list: replace (no
 title) filler when a title isn't set with something more useful.
In-Reply-To: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
References: <052.0569db5e86fd3169ce813b8b617b8622@wordpress.org>
Message-ID: <067.b53f52a3b8da03a950fd032f9693ade1@wordpress.org>

#65022: Posts list: replace (no title) filler when a title isn't set with something
more useful.
-------------------------------+-----------------------------
 Reporter:  annezazu           |       Owner:  SergeyBiryukov
     Type:  enhancement        |      Status:  accepted
 Priority:  normal             |   Milestone:  7.1
Component:  Posts, Post Types  |     Version:
 Severity:  normal             |  Resolution:
 Keywords:  has-patch          |     Focuses:  administration
-------------------------------+-----------------------------
Changes (by JeffPaul):

 * Attachment "IMG_8299.png" added.

 All Posts, extended view

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65022>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 04:46:41 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 04:46:41 -0000
Subject: [wp-trac] [WordPress Trac] #65069: Testing
Message-ID: <049.bbf79007590f74f348d63b0f20d954ef@wordpress.org>

#65069: Testing
--------------------------+-----------------------------
 Reporter:  barry         |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  General       |    Version:
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65069>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 04:47:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 04:47:28 -0000
Subject: [wp-trac] [WordPress Trac] #65069: Testing
In-Reply-To: <049.bbf79007590f74f348d63b0f20d954ef@wordpress.org>
References: <049.bbf79007590f74f348d63b0f20d954ef@wordpress.org>
Message-ID: <064.7061a333a197708dd7b46ae975bb001d@wordpress.org>

#65069: Testing
--------------------------+------------------------------
 Reporter:  barry         |       Owner:  (none)
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:
 Severity:  normal        |  Resolution:  fixed
 Keywords:                |     Focuses:
--------------------------+------------------------------
Changes (by barry):

 * status:  new => closed
 * resolution:   => fixed


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65069#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 05:39:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 05:39:28 -0000
Subject: [wp-trac] [WordPress Trac] #65055: _pad_term_counts() uses
 string-concatenated SQL without prepared statement
In-Reply-To: <052.bca20aa704264c411e9a5a70bff738ad@wordpress.org>
References: <052.bca20aa704264c411e9a5a70bff738ad@wordpress.org>
Message-ID: <067.deaf0b1ad26eab1b14ee438b1e8670d4@wordpress.org>

#65055: _pad_term_counts() uses string-concatenated SQL without prepared statement
-------------------------------------+------------------------------
 Reporter:  rajeshcp                 |       Owner:  rajeshcp
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Database                 |     Version:  trunk
 Severity:  major                    |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+------------------------------

Comment (by liaison):

 Replying to [comment:3 abcd95]:
 > The current code isn't exploitable — esc_sql() does handle escaping
 correctly here, and the values involved are all server-side (database IDs
 and registered post types, not user input). But switching to
 $wpdb->prepare() is still the right call as a best-practice improvement.
 The patch looks good.
 >
 > One small addition worth considering: _update_post_term_count() filters
 object_types through post_type_exists() before querying but
 _pad_term_counts() doesn't. Could be worth adding for consistency.

 @abcd95 I agree that aligning this with _update_post_term_count() is a
 great point for consistency. Filtering out unregistered post types would
 indeed make the query more robust.

 I’ve drafted a refined version of the patch based on your suggestion:
 {{{#!php
 function _update_post_term_count( $terms, $taxonomy ) {
     // ...
     $object_types = (array) $tax_obj->object_type;
     foreach ( $object_types as $index => $object_type ) {
         if ( ! post_type_exists( $object_type ) ) {
             unset( $object_types[ $index ] );
         }
     }
     // ...
 }
 }}}


 {{{#!php

 function _pad_term_counts( &$terms, $taxonomy ) {
         // Get the object and term IDs and stick them in a lookup table.
         $tax_obj      = get_taxonomy( $taxonomy );

 +       $object_types = (array) $tax_obj->object_type;
 +       // --- filter invalid post types ---
 +       $object_types = array_filter( $object_types, 'post_type_exists' );
 +
 +       if ( empty( $object_types ) ) {
 +           return; // if no valid post type，return directly
 +       }
 +       $object_types = esc_sql( $object_types );

 -       $object_types = esc_sql( $tax_obj->object_type );
 -       $results      = $wpdb->get_results( "SELECT object_id,
 term_taxonomy_id FROM $wpdb->term_relationships INNER JOIN $wpdb->posts ON
 object_id = ID WHERE term_taxonomy_id IN (" . implode( ',', array_keys(
 $term_ids ) ) . ") AND post_type IN ('" . implode( "', '", $object_types )
 . "') AND post_status = 'publish'" );
 -
 +       $results      = $wpdb->get_results(
 +               $wpdb->prepare(
 +                       "SELECT object_id, term_taxonomy_id FROM
 $wpdb->term_relationships INNER JOIN $wpdb->posts ON object_id = ID WHERE
 term_taxonomy_id IN (" . implode( ',', array_fill( 0, count( $term_ids ),
 '%d' ) ) . ') AND post_type IN (' . implode( ',', array_fill( 0, count(
 $object_types ), '%s' ) ) . ") AND post_status = 'publish'",
 +                       array_merge( array_keys( $term_ids ),
 $object_types )
 +               )
 +       );
         foreach ( $results as $row ) {
                 $id = $term_ids[ $row->term_taxonomy_id ];
 }}}

 This seems to cover the concern perfectly. @rajeshcp, what do you think
 about incorporating this filter into the PR?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65055#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 06:24:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 06:24:26 -0000
Subject: [wp-trac] [WordPress Trac] #64926: REST API: GET requests fail
 object/array schema validation when params are JSON-serialized strings
In-Reply-To: <048.09e4f6945084c0394353ff269647c101@wordpress.org>
References: <048.09e4f6945084c0394353ff269647c101@wordpress.org>
Message-ID: <063.73db2118473fd53ee746db857726d55a@wordpress.org>

#64926: REST API: GET requests fail object/array schema validation when params are
JSON-serialized strings
-------------------------------------+-------------------------------------
 Reporter:  dsmy                     |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  REST API                 |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch has-unit-      |     Focuses:  javascript, rest-api,
  tests                              |  php-compatibility
-------------------------------------+-------------------------------------
Changes (by liaison):

 * keywords:  has-patch => has-patch has-unit-tests


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64926#comment:29>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 06:28:45 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 06:28:45 -0000
Subject: [wp-trac] [WordPress Trac] #65004: Prev/Next for posts needs
 context in block library
In-Reply-To: <052.63f4ad3e35370ac88b08f873bc0bb708@wordpress.org>
References: <052.63f4ad3e35370ac88b08f873bc0bb708@wordpress.org>
Message-ID: <067.7ef7fbcee0f2533d8da4d0743a992c1d@wordpress.org>

#65004: Prev/Next for posts needs context in block library
--------------------------+-----------------------
 Reporter:  timse201      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:
Component:  I18N          |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+-----------------------

Comment (by poena):

 Are you able to provide more information?
 And it still needs to be reported in the Gutenberg GitHub repository, not
 via Trac.


 Here is where I am seeing the translators context for the next and
 previous post:

 https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-
 includes/blocks/post-navigation-link.php#L40

 And it comes from the block here:
 https://github.com/WordPress/gutenberg/blob/trunk/packages/block-
 library/src/post-navigation-link/index.php#L40


 ---

 The comment pagination does not use the ambiguous next/previous texts,
 they use:

 {{{
 $default_label    = __( 'Newer Comments' );
 }}}

 https://github.com/WordPress/gutenberg/blob/trunk/packages/block-
 library/src/comments-pagination-next/index.php#L27
 and

 {{{
 $default_label    = __( 'Older Comments' );
 }}}

 https://github.com/WordPress/gutenberg/blob/trunk/packages/block-
 library/src/comments-pagination-previous/index.php#L20

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65004#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 06:38:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 06:38:03 -0000
Subject: [wp-trac] [WordPress Trac] #50129: Link edit modal displayed
 over Featured image modal
In-Reply-To: <054.d863811c119ceb3a4261af1893cb383d@wordpress.org>
References: <054.d863811c119ceb3a4261af1893cb383d@wordpress.org>
Message-ID: <069.b6df0c277e63f8278c8f1ba7bda92e79@wordpress.org>

#50129: Link edit modal displayed over Featured image modal
--------------------------+-------------------------------------
 Reporter:  sumitsingh    |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:  5.4.1
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  ui, accessibility, css
--------------------------+-------------------------------------
Changes (by sumitsingh):

 * focuses:  ui, css => ui, accessibility, css


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/50129#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 06:39:10 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 06:39:10 -0000
Subject: [wp-trac] [WordPress Trac] #50129: Link edit modal displayed
 over Featured image modal
In-Reply-To: <054.d863811c119ceb3a4261af1893cb383d@wordpress.org>
References: <054.d863811c119ceb3a4261af1893cb383d@wordpress.org>
Message-ID: <069.5057a62a7e80dac513dd7b36d69f65f1@wordpress.org>

#50129: Link edit modal displayed over Featured image modal
--------------------------+-------------------------------------
 Reporter:  sumitsingh    |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:  5.4.1
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  ui, accessibility, css
--------------------------+-------------------------------------

Comment (by sumitsingh):

 I think this issue is fixed now. So what do we need to do here next?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/50129#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 06:41:41 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 06:41:41 -0000
Subject: [wp-trac] [WordPress Trac] #49526: Misaligned theme count on
 Add Themes screen on iPhone X
In-Reply-To: <054.3c38ce0c1cda33c9918d2c0825c81527@wordpress.org>
References: <054.3c38ce0c1cda33c9918d2c0825c81527@wordpress.org>
Message-ID: <069.dd5a42ee8aa446700f74e3666661f6e7@wordpress.org>

#49526: Misaligned theme count on Add Themes screen on iPhone X
-------------------------------------------------+-------------------------
 Reporter:  sumitsingh                           |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Themes                               |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-screenshots has-patch needs-     |     Focuses:  ui,
  unit-tests                                     |  administration
-------------------------------------------------+-------------------------
Changes (by sumitsingh):

 * keywords:  has-screenshots has-patch => has-screenshots has-patch needs-
     unit-tests


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/49526#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 06:41:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 06:41:56 -0000
Subject: [wp-trac] [WordPress Trac] #49526: Misaligned theme count on
 Add Themes screen on iPhone X
In-Reply-To: <054.3c38ce0c1cda33c9918d2c0825c81527@wordpress.org>
References: <054.3c38ce0c1cda33c9918d2c0825c81527@wordpress.org>
Message-ID: <069.a34b96269313f5bab2c8b9d4d9717e4c@wordpress.org>

#49526: Misaligned theme count on Add Themes screen on iPhone X
-------------------------------------+-------------------------------------
 Reporter:  sumitsingh               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Themes                   |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-screenshots has-     |     Focuses:  ui, accessibility,
  patch needs-unit-tests             |  administration
-------------------------------------+-------------------------------------
Changes (by sumitsingh):

 * focuses:  ui, administration => ui, accessibility, administration


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/49526#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 06:48:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 06:48:06 -0000
Subject: [wp-trac] [WordPress Trac] #65055: _pad_term_counts() uses
 string-concatenated SQL without prepared statement
In-Reply-To: <052.bca20aa704264c411e9a5a70bff738ad@wordpress.org>
References: <052.bca20aa704264c411e9a5a70bff738ad@wordpress.org>
Message-ID: <067.933ab961e86ffe44a3e0be58ec1a5ee1@wordpress.org>

#65055: _pad_term_counts() uses string-concatenated SQL without prepared statement
--------------------------+------------------------------
 Reporter:  rajeshcp      |       Owner:  rajeshcp
     Type:  defect (bug)  |      Status:  assigned
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Database      |     Version:  trunk
 Severity:  major         |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+------------------------------
Changes (by abcd95):

 * keywords:  has-patch needs-testing => has-patch


Comment:

 Replying to [comment:4 liaison]:

 Thanks @liaison! agreed on the alignment with _update_post_term_count().
 The updated patch incorporating post_type_exists() filtering looks solid.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65055#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 08:19:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 08:19:12 -0000
Subject: [wp-trac] [WordPress Trac] #65004: Prev/Next for posts needs
 context in block library
In-Reply-To: <052.63f4ad3e35370ac88b08f873bc0bb708@wordpress.org>
References: <052.63f4ad3e35370ac88b08f873bc0bb708@wordpress.org>
Message-ID: <067.f5b738d48836cdf3bcfa05c77f07bf95@wordpress.org>

#65004: Prev/Next for posts needs context in block library
--------------------------+-----------------------
 Reporter:  timse201      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:
Component:  I18N          |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+-----------------------

Comment (by timse201):

 Ah my fault. The first one ist the array and the second and third Strings
 are now fixed :)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65004#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 09:26:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 09:26:03 -0000
Subject: [wp-trac] [WordPress Trac] #65070: Move inline JS from admin_head
 hooks in options screens into options.js
Message-ID: <052.98f5306281d31ac9ff14534bac93246c@wordpress.org>

#65070: Move inline JS from admin_head hooks in options screens into options.js
----------------------------+-----------------------------
 Reporter:  anukasha        |      Owner:  (none)
     Type:  enhancement     |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Administration  |    Version:
 Severity:  normal          |   Keywords:  needs-patch
  Focuses:                  |
----------------------------+-----------------------------
 src/wp-admin/includes/options.php contains three functions that print
 inline <script> blocks via admin_head hooks:
 1. options_discussion_add_js() — hooked in options-discussion.php
 2. options_general_add_js() — hooked in options-general.php
 3. options_reading_add_js() — hooked in options-reading.php

 These should be migrated into src/js/_enqueues/admin/options.js, which was
 introduced in [https://github.com/WordPress/wordpress-develop/pull/10927]
 as the central enqueued JS file for options screens.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65070>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 09:34:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 09:34:17 -0000
Subject: [wp-trac] [WordPress Trac] #64930: "Restore This Autosave"
 button misalignment
In-Reply-To: <053.4471d05b604b27273f0e1a80ece43ace@wordpress.org>
References: <053.4471d05b604b27273f0e1a80ece43ace@wordpress.org>
Message-ID: <068.5bef267944a55bd9000c392994742830@wordpress.org>

#64930: "Restore This Autosave" button misalignment
--------------------------+------------------------------
 Reporter:  Presskopp     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  ui
--------------------------+------------------------------

Comment (by Presskopp):

 related: #65062

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64930#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 09:36:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 09:36:03 -0000
Subject: [wp-trac] [WordPress Trac] #63085: "Login details" spam sent by
 from the account registration page
In-Reply-To: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
References: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
Message-ID: <066.0fc38a169d853c249bc5b62d4467fbee@wordpress.org>

#63085: "Login details" spam sent by from the account registration page
-------------------------------------------------+-------------------------
 Reporter:  cweiske                              |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Login and Registration               |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests has-test-   |     Focuses:
  info                                           |
-------------------------------------------------+-------------------------

Comment (by darshitrajyaguru97):

 **Patch Tested: https://github.com/WordPress/wordpress-develop/pull/11439

 === **Environment ===
 * WordPress: 7.0 RC
 * PHP: 7.4
 * Playground

 === **Results ===
 * Usernames containing invalid characters (such as spaces or restricted
 terms like "www") are correctly rejected.
 * Registration works successfully with a valid username and email.
 * Confirmation email is sent upon successful registration.

 === Summary ===
 **The patch is working as expected and resolves the issue effectively.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63085#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 10:00:34 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 10:00:34 -0000
Subject: [wp-trac] [WordPress Trac] #65055: _pad_term_counts() uses
 string-concatenated SQL without prepared statement
In-Reply-To: <052.bca20aa704264c411e9a5a70bff738ad@wordpress.org>
References: <052.bca20aa704264c411e9a5a70bff738ad@wordpress.org>
Message-ID: <067.6e91921d3800810e36b8e0d21d3cbf15@wordpress.org>

#65055: _pad_term_counts() uses string-concatenated SQL without prepared statement
--------------------------+------------------------------
 Reporter:  rajeshcp      |       Owner:  rajeshcp
     Type:  defect (bug)  |      Status:  assigned
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Database      |     Version:  trunk
 Severity:  major         |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+------------------------------

Comment (by liaison):

 Replying to [comment:5 abcd95]:
 > Replying to [comment:4 liaison]:
 >
 > Thanks @liaison! agreed on the alignment with _update_post_term_count().
 The updated patch incorporating post_type_exists() filtering looks solid.

 Test Report:

 I verified the fix using a zero-dependency test script that loads the core
 wp-includes/taxonomy.php while mocking the database environment.

 Before Patch:
 The logic uses direct string interpolation and includes unregistered post
 types in the query.

 Method: get_results
 Query: ... AND post_type IN ('post', 'ghost_type') ...
 ❌ FAILED: 'ghost_type' present in raw SQL string.
 After Patch:
 The logic now correctly filters post types via post_type_exists() and uses
 wpdb::prepare() for the final query.

 Method: prepare
 Arguments: 123, post
 ✅ SUCCESS: 'ghost_type' filtered from prepare arguments.

 test-65055-sql-filter.php
 {{{#!php
 <?php
 <?php
 /**
  * Trac #65055: Zero-Dependency Test for Core wp-includes/taxonomy.php
  * Supports both patched (prepare) and unpatched (direct query) versions.
  */

 define( 'ABSPATH', __DIR__ . '/' );
 define( 'WPINC', 'wp-includes' );

 /**
  * 1. Robust Mock_WPDB
  * Handles table name properties and captures both prepare/get_results.
  */
 class Mock_WPDB {
     public $queries = [];
     public $prefix = 'wp_';

     // Core table names used in _pad_term_counts
     public $term_relationships = 'wp_term_relationships';
     public $posts = 'wp_posts';

     public function prepare( $query, ...$args ) {
         // Flatten arguments if they were passed as an array
         $flat_args = ( is_array( $args[0] ) && count( $args ) === 1 ) ?
 $args[0] : $args;
         $this->queries[] = [
             'method' => 'prepare',
             'query'  => $query,
             'args'   => $flat_args
         ];
         return $query;
     }

     public function get_results( $query ) {
         // If query was not recorded by prepare(), it's a direct string
 query
         $already_recorded = false;
         foreach ( $this->queries as $q ) {
             if ( $q['query'] === $query ) {
                 $already_recorded = true;
                 break;
             }
         }

         if ( ! $already_recorded ) {
             $this->queries[] = [
                 'method' => 'get_results',
                 'query'  => $query,
                 'args'   => []
             ];
         }

         // Return empty result to satisfy the function
         return array();
     }
 }

 $GLOBALS['wpdb'] = new Mock_WPDB();

 /**
  * 2. Mock Global Functions (Stubbing)
  */
 if ( ! function_exists( 'post_type_exists' ) ) {
     function post_type_exists( $post_type ) {
         return in_array( $post_type, array( 'post' ), true );
     }
 }

 if ( ! function_exists( 'wp_installing' ) ) {
     function wp_installing() { return false; }
 }

 if ( ! function_exists( 'esc_sql' ) ) {
     function esc_sql( $data ) { return $data; }
 }

 if ( ! function_exists( 'get_option' ) ) {
     function get_option( $option, $default = false ) {
         // Force get_term_hierarchy to believe Term 123 has a child 999
         if ( strpos( $option, '_children' ) !== false ) {
             return array( 123 => array( 999 ) );
         }
         return array();
     }
 }

 /**
  * 3. Load actual Core file
  */
 if ( file_exists( ABSPATH . WPINC . '/taxonomy.php' ) ) {
     require_once ABSPATH . WPINC . '/taxonomy.php';
 } else {
     die( "❌ Error: wp-includes/taxonomy.php not found. Check your
 ABSPATH.\n" );
 }

 /**
  * 4. Setup Global State
  */
 global $wp_taxonomies;
 $test_tax = new stdClass();
 $test_tax->name         = 'test_tax';
 $test_tax->object_type  = array( 'post', 'ghost_type' ); // Mixed
 valid/invalid
 $test_tax->hierarchical = true;
 $wp_taxonomies['test_tax'] = $test_tax;

 /**
  * 5. Execute Test
  */
 echo "--- Starting Core _pad_term_counts() Test ---\n";

 $term = new stdClass();
 $term->term_id          = 123;
 $term->term_taxonomy_id = 123;
 $term->parent           = 0;
 $term->count            = 0;

 $terms_array = array( $term );
 _pad_term_counts( $terms_array, 'test_tax' );
 /**
  * 6. Final Analysis
  */
 $last_execution = end( $GLOBALS['wpdb']->queries );

 if ( ! $last_execution ) {
     die( "❌ FAILED: No database activity detected.\n" );
 }

 echo "\n[Execution Result]\n";
 echo "Method: " . $last_execution['method'] . "\n";

 if ( $last_execution['method'] === 'prepare' ) {
     $args = $last_execution['args'];
     echo "Arguments: " . implode( ', ', $args ) . "\n";

     if ( in_array( 'ghost_type', $args, true ) ) {
         echo "❌ FAILED: 'ghost_type' remains in prepare arguments.\n";
     } else {
         echo "✅ SUCCESS: 'ghost_type' filtered from prepare
 arguments.\n";
     }
 } else {
     echo "Query: " . $last_execution['query'] . "\n";

     if ( strpos( $last_execution['query'], 'ghost_type' ) !== false ) {
         echo "❌ FAILED: 'ghost_type' present in raw SQL string.\n";
     } else {
         echo "✅ SUCCESS: 'ghost_type' not found in SQL string.\n";
     }
 }

 echo "\n--- Test Completed ---\n";



 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65055#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 10:12:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 10:12:30 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2364962=3A_Install_scr?=
 =?utf-8?b?ZWVuczog4oCcTG9nIElu4oCdIGFuZCAiU3VwcG9ydCBsaW5rIiB1c2Ugb2xk?=
 =?utf-8?q?_color?=
In-Reply-To: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
References: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
Message-ID: <074.e2035a40199c335b5622a560417b8b9d@wordpress.org>

#64962: Install screens: “Log In” and "Support link" use old color
-------------------------------------------------+-------------------------
 Reporter:  huzaifaalmesbah                      |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  admin-reskin has-patch has-          |     Focuses:  ui, css
  screenshots                                    |
-------------------------------------------------+-------------------------
Changes (by wildworks):

 * status:  accepted => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62230" 62230]:
 {{{
 #!CommitTicketReference repository="" revision="62230"
 Upgrade/Install: Use new default admin color scheme for links on the setup
 screen.

 This changeset updates the link colors on the setup screen and the default
 `wp_die()` fallback styles to use the new default admin color scheme.

 Props audrasjb, darshitrajyaguru97, dhrumilk, hbhalodia, huzaifaalmesbah,
 ismail0071, mikinc860, pooja-n, shailu25, sumitsingh, vishitshah,
 wildworks
 Fixes #64962. See #64308.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64962#comment:21>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 10:12:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 10:12:31 -0000
Subject: [wp-trac] [WordPress Trac] #64308: Explore a "Coat-of-Paint"
 Visual Reskin of the WordPress Admin for WordPress 7.0
In-Reply-To: <055.9b9d23b7d737d4bf4984326737268082@wordpress.org>
References: <055.9b9d23b7d737d4bf4984326737268082@wordpress.org>
Message-ID: <070.bb1e4a1e576558a1000a8b30af3c2441@wordpress.org>

#64308: Explore a "Coat-of-Paint" Visual Reskin of the WordPress Admin for
WordPress 7.0
----------------------------+----------------------
 Reporter:  fabiankaegy     |       Owner:  (none)
     Type:  task (blessed)  |      Status:  closed
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:  fixed
 Keywords:                  |     Focuses:  ui, css
----------------------------+----------------------

Comment (by wildworks):

 In [changeset:"62230" 62230]:
 {{{
 #!CommitTicketReference repository="" revision="62230"
 Upgrade/Install: Use new default admin color scheme for links on the setup
 screen.

 This changeset updates the link colors on the setup screen and the default
 `wp_die()` fallback styles to use the new default admin color scheme.

 Props audrasjb, darshitrajyaguru97, dhrumilk, hbhalodia, huzaifaalmesbah,
 ismail0071, mikinc860, pooja-n, shailu25, sumitsingh, vishitshah,
 wildworks
 Fixes #64962. See #64308.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64308#comment:42>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 10:13:19 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 10:13:19 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2364962=3A_Install_scr?=
 =?utf-8?b?ZWVuczog4oCcTG9nIElu4oCdIGFuZCAiU3VwcG9ydCBsaW5rIiB1c2Ugb2xk?=
 =?utf-8?q?_color?=
In-Reply-To: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
References: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
Message-ID: <074.1a74c2d7356cd780a1ac8ce6f9bc2b28@wordpress.org>

#64962: Install screens: “Log In” and "Support link" use old color
-------------------------------------------------+-------------------------
 Reporter:  huzaifaalmesbah                      |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch has-          |     Focuses:  ui, css
  screenshots dev-feedback                       |
-------------------------------------------------+-------------------------
Changes (by wildworks):

 * keywords:  admin-reskin has-patch has-screenshots => admin-reskin has-
     patch has-screenshots dev-feedback
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Reopening #64962 to request backporting [62230] to the 7.0 branch

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64962#comment:22>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 10:25:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 10:25:49 -0000
Subject: [wp-trac] [WordPress Trac] #64837: Disable pings/trackbacks for
 local, development, and staging environments
In-Reply-To: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
References: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
Message-ID: <069.22832d4358c1d66672a603aafdd914e7@wordpress.org>

#64837: Disable pings/trackbacks for local, development, and staging environments
--------------------------------------+------------------------------
 Reporter:  cagrimmett                |       Owner:  ramonopoly
     Type:  enhancement               |      Status:  closed
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  Pings/Trackbacks          |     Version:
 Severity:  normal                    |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+------------------------------
Changes (by ramonopoly):

 * owner:  (none) => ramonopoly
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62231" 62231]:
 {{{
 #!CommitTicketReference repository="" revision="62231"
 Disable pings/trackbacks for local, development, and staging environments

 When WP_ENVIRONMENT_TYPE is not `production`, disable pingbacks and
 trackbacks.

 Otherwise, when `WP_ENVIRONMENT_TYPE` is `local`, `development`, or
 `staging`, pingbacks and trackbacks are sent when posts are published.
 This creates confusion on the receiving end and is unnecessary for testing
 workflows.

 Props arcangelini, cagrimmett, ramonopoly, tyxla.

 Fixes #64837.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64837#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 10:33:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 10:33:21 -0000
Subject: [wp-trac] [WordPress Trac] #54016: Media Library: Bulk delete
 elements in grid view takes very long
In-Reply-To: <053.163729d7b8e833e3128db8a5d8edb4b2@wordpress.org>
References: <053.163729d7b8e833e3128db8a5d8edb4b2@wordpress.org>
Message-ID: <068.237ccfd51dff1e9ad571e38172d8a043@wordpress.org>

#54016: Media Library: Bulk delete elements in grid view takes very long
-------------------------------------------------+-------------------------
 Reporter:  Presskopp                            |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Media                                |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch 2nd-opinion needs-testing  |     Focuses:
                                                 |  performance
-------------------------------------------------+-------------------------

Comment (by darshitrajyaguru97):

 I was able to reproduce the issue locally and can confirm the performance
 concern when performing bulk deletion in the Media Library grid view.

 === Testing details:
 - WordPress: 7.0 RC2
 - Environment: local + medium dataset (~500 images)
 - Browser: Chrome

 === Observations:
 - Bulk delete in grid view triggers multiple sequential AJAX requests (one
 per attachment).
 - UI updates after each deletion, which significantly increases total
 processing time.
 - On larger datasets, this results in noticeable delay and increased
 server load.

 === Comparison:
 - List view bulk delete appears more efficient since it processes via bulk
 action rather than per-item requests.

 === Suggestions:
 - Introducing batched deletion (single request with multiple IDs) could
 improve performance.
 - Alternatively, a hybrid approach:
   - Step 1: Mark items with a temporary status (e.g. `deleting`)
   - Step 2: Process deletion asynchronously in chunks (similar to
 background processing used elsewhere in core)

 === Additional note:
 It may also be worth reviewing whether `_thumbnail_id` and related
 postmeta cleanup can be optimized or deferred to reduce query overhead
 during deletion.

 **Happy to help test any patches if this moves forward.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/54016#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 10:39:19 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 10:39:19 -0000
Subject: [wp-trac] [WordPress Trac] #65071: Focus border styling breaks slug
 input layout in Classic Editor
Message-ID: <054.e70f7f0372475cddd66d4c1365327e94@wordpress.org>

#65071: Focus border styling breaks slug input layout in Classic Editor
------------------------------------+-----------------------------
 Reporter:  dhruvang21              |      Owner:  (none)
     Type:  defect (bug)            |     Status:  new
 Priority:  normal                  |  Milestone:  Awaiting Review
Component:  Editor                  |    Version:  trunk
 Severity:  normal                  |   Keywords:
  Focuses:  ui, accessibility, css  |
------------------------------------+-----------------------------
 While testing the changes introduced in PR: [https://github.com/WordPress
 /wordpress-develop/pull/11551], I came across a UI issue in the Classic
 Editor related to the post slug (permalink) editing field.

 When the slug input receives focus, the focus border appears larger than
 expected and causes the layout to break.

 **Steps to Reproduce:**

 - Go to Posts → Add New (or edit an existing post)
 - Click on the permalink “Edit” button
 - Focus on the slug input field
 - Observe the input field styling

 **Expected Behavior:**
 The focus state should not alter the layout or dimensions of the input
 field. The slug field should remain properly aligned within its container.

 **Actual Behavior:**
 On focus:

 - The border/outline appears thicker or offset
 - The input visually overflows or misaligns
 - The slug field appears “broken” within the layout

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65071>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 10:39:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 10:39:31 -0000
Subject: [wp-trac] [WordPress Trac] #65071: Focus border styling breaks
 slug input layout in Classic Editor
In-Reply-To: <054.e70f7f0372475cddd66d4c1365327e94@wordpress.org>
References: <054.e70f7f0372475cddd66d4c1365327e94@wordpress.org>
Message-ID: <069.e1b797b24763b561b24a1755eee9c081@wordpress.org>

#65071: Focus border styling breaks slug input layout in Classic Editor
--------------------------+-------------------------------------
 Reporter:  dhruvang21    |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  ui, accessibility, css
--------------------------+-------------------------------------
Changes (by dhruvang21):

 * Attachment "Screenshot from 2026-04-14 15-42-08.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65071>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 10:43:46 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 10:43:46 -0000
Subject: [wp-trac] [WordPress Trac] #64837: Disable pings/trackbacks for
 local, development, and staging environments
In-Reply-To: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
References: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
Message-ID: <069.cddc7728d29fb8ff8693a934f672a224@wordpress.org>

#64837: Disable pings/trackbacks for local, development, and staging environments
--------------------------------------+-------------------------
 Reporter:  cagrimmett                |       Owner:  ramonopoly
     Type:  enhancement               |      Status:  closed
 Priority:  normal                    |   Milestone:  7.0
Component:  Pings/Trackbacks          |     Version:
 Severity:  normal                    |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------
Changes (by swissspidy):

 * milestone:  Awaiting Review => 7.0


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64837#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 10:44:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 10:44:53 -0000
Subject: [wp-trac] [WordPress Trac] #64837: Disable pings/trackbacks for
 local, development, and staging environments
In-Reply-To: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
References: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
Message-ID: <069.a1da4f6384bc8ac75afe38964337ddd5@wordpress.org>

#64837: Disable pings/trackbacks for local, development, and staging environments
--------------------------------------+-------------------------
 Reporter:  cagrimmett                |       Owner:  ramonopoly
     Type:  enhancement               |      Status:  closed
 Priority:  normal                    |   Milestone:  7.1
Component:  Pings/Trackbacks          |     Version:
 Severity:  normal                    |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------
Changes (by swissspidy):

 * milestone:  7.0 => 7.1


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64837#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 10:45:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 10:45:23 -0000
Subject: [wp-trac] [WordPress Trac] #65060: Formatting issue on
 expand/collapse meta box area focus
In-Reply-To: <053.3f798f1a567cca7e0d02f86b0e08f865@wordpress.org>
References: <053.3f798f1a567cca7e0d02f86b0e08f865@wordpress.org>
Message-ID: <068.95492fe9b9c2ad23d11f06b737e8143d@wordpress.org>

#65060: Formatting issue on expand/collapse meta box area focus
------------------------------------+------------------------
 Reporter:  brianhogg               |       Owner:  wildworks
     Type:  defect (bug)            |      Status:  closed
 Priority:  normal                  |   Milestone:  7.0
Component:  Formatting              |     Version:  trunk
 Severity:  normal                  |  Resolution:  fixed
 Keywords:  admin-reskin has-patch  |     Focuses:
------------------------------------+------------------------
Changes (by wildworks):

 * owner:  (none) => wildworks
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62232" 62232]:
 {{{
 #!CommitTicketReference repository="" revision="62232"
 Administration: Fix focus outline being cut off for the metabox collapse
 and move buttons.

 Fixes an issue where the focus outline on metabox collapse buttons and
 move handles was being clipped.

 Props abcd95, audrasjb, brianhogg, darshitrajyaguru97, poena, wildworks.
 Fixes #65060.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65060#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 10:46:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 10:46:09 -0000
Subject: [wp-trac] [WordPress Trac] #65060: Formatting issue on
 expand/collapse meta box area focus
In-Reply-To: <053.3f798f1a567cca7e0d02f86b0e08f865@wordpress.org>
References: <053.3f798f1a567cca7e0d02f86b0e08f865@wordpress.org>
Message-ID: <068.cf8977d78df5e4bd0c2095262d0cef3f@wordpress.org>

#65060: Formatting issue on expand/collapse meta box area focus
-------------------------------------------------+------------------------
 Reporter:  brianhogg                            |       Owner:  wildworks
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Formatting                           |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch dev-feedback  |     Focuses:
-------------------------------------------------+------------------------
Changes (by wildworks):

 * keywords:  admin-reskin has-patch => admin-reskin has-patch dev-feedback
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Reopening #65060 to request backporting [62232] to the 7.0 branch

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65060#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 10:49:59 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 10:49:59 -0000
Subject: [wp-trac] [WordPress Trac] #64837: Disable pings/trackbacks for
 local, development, and staging environments
In-Reply-To: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
References: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
Message-ID: <069.f1689dda3776db71f039048af744e3ae@wordpress.org>

#64837: Disable pings/trackbacks for local, development, and staging environments
--------------------------------------+-------------------------
 Reporter:  cagrimmett                |       Owner:  ramonopoly
     Type:  enhancement               |      Status:  closed
 Priority:  normal                    |   Milestone:  7.1
Component:  Pings/Trackbacks          |     Version:
 Severity:  normal                    |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------

Comment (by khushipatel15):

 @ramonopoly kindly please assist me with the issue of why am i not given
 props.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64837#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 10:50:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 10:50:06 -0000
Subject: [wp-trac] [WordPress Trac] #64930: "Restore This Autosave"
 button misalignment
In-Reply-To: <053.4471d05b604b27273f0e1a80ece43ace@wordpress.org>
References: <053.4471d05b604b27273f0e1a80ece43ace@wordpress.org>
Message-ID: <068.ce392f61659e342f2f6560484373ccf5@wordpress.org>

#64930: "Restore This Autosave" button misalignment
--------------------------+------------------------------
 Reporter:  Presskopp     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  ui
--------------------------+------------------------------

Comment (by wildworks):

 Replying to [comment:3 mukesh27]:
 > First, can we confirm whether this issue also occurs in previous
 versions? Also, do we know if it was introduced as part of the admin
 reskin project changes?

 This issue was caused by a change in admin skin. See
 https://core.trac.wordpress.org/attachment/ticket/65062/revisions-ui.png

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64930#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 10:50:11 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 10:50:11 -0000
Subject: [wp-trac] [WordPress Trac] #64837: Disable pings/trackbacks for
 local, development, and staging environments
In-Reply-To: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
References: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
Message-ID: <069.e00807e563c8471202772dd9aa3651a7@wordpress.org>

#64837: Disable pings/trackbacks for local, development, and staging environments
--------------------------------------+-------------------------
 Reporter:  cagrimmett                |       Owner:  ramonopoly
     Type:  enhancement               |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.1
Component:  Pings/Trackbacks          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------
Changes (by swissspidy):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Can we find a more elegant way to address this that doesn't require adding
 4 (!) new functions?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64837#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 10:51:45 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 10:51:45 -0000
Subject: [wp-trac] [WordPress Trac] #64930: "Restore This Autosave"
 button misalignment
In-Reply-To: <053.4471d05b604b27273f0e1a80ece43ace@wordpress.org>
References: <053.4471d05b604b27273f0e1a80ece43ace@wordpress.org>
Message-ID: <068.cae9108da8296ac8c2e0ea65f7c2d6fe@wordpress.org>

#64930: "Restore This Autosave" button misalignment
--------------------------+------------------------
 Reporter:  Presskopp     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  General       |     Version:
 Severity:  normal        |  Resolution:  duplicate
 Keywords:  has-patch     |     Focuses:  ui
--------------------------+------------------------
Changes (by wildworks):

 * status:  new => closed
 * resolution:   => duplicate
 * milestone:  Awaiting Review =>


Comment:

 Let's close this ticket as a duplicate of #65062, as #65062 is attempting
 to address more issues in the revisions screen.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64930#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 10:53:11 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 10:53:11 -0000
Subject: [wp-trac] [WordPress Trac] #64837: Disable pings/trackbacks for
 local, development, and staging environments
In-Reply-To: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
References: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
Message-ID: <069.3fb0902d1ce876e032d05accc738885c@wordpress.org>

#64837: Disable pings/trackbacks for local, development, and staging environments
--------------------------------------+-------------------------
 Reporter:  cagrimmett                |       Owner:  ramonopoly
     Type:  enhancement               |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.1
Component:  Pings/Trackbacks          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------

Comment (by khushipatel15):

 @swissspidy , we can use this function instead ?


 {{{
 function mytheme_disable_pings_in_dev() {
     $env_type = wp_get_environment_type();

     if (apply_filters('wp_override_disable_pings_trackbacks_in_dev_envs',
 false, $env_type)) {
         return false;
     }

     return in_array($env_type, ['local', 'development', 'staging'], true);
 }

 add_filter('pre_pingback_send', function ($send) {
     return mytheme_disable_pings_in_dev() ? false : $send;
 });

 add_filter('xmlrpc_methods', function ($methods) {
     if (mytheme_disable_pings_in_dev() &&
 isset($methods['pingback.ping'])) {
         unset($methods['pingback.ping']);
     }
     return $methods;
 });
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64837#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 11:03:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 11:03:03 -0000
Subject: [wp-trac] [WordPress Trac] #64837: Disable pings/trackbacks for
 local, development, and staging environments
In-Reply-To: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
References: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
Message-ID: <069.b813d9dd44ba059cd76300e7f467dde3@wordpress.org>

#64837: Disable pings/trackbacks for local, development, and staging environments
--------------------------------------+-------------------------
 Reporter:  cagrimmett                |       Owner:  ramonopoly
     Type:  enhancement               |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.1
Component:  Pings/Trackbacks          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------

Comment (by ramonopoly):

 > kindly please assist me with the issue of why am i not given props.

 It was an oversight, apologies. I'll make sure the follow up is correct -
 looks like there's going to be one.

 > Can we find a more elegant way to address this that doesn't require
 adding 4 (!) new functions?


 Any suggestions to help move your request along?

 cc @arcangelini

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64837#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 11:21:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 11:21:22 -0000
Subject: [wp-trac] [WordPress Trac] #64837: Disable pings/trackbacks for
 local, development, and staging environments
In-Reply-To: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
References: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
Message-ID: <069.5cada5ab6e985f21843ac8aebb49b10b@wordpress.org>

#64837: Disable pings/trackbacks for local, development, and staging environments
--------------------------------------+-------------------------
 Reporter:  cagrimmett                |       Owner:  ramonopoly
     Type:  enhancement               |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.1
Component:  Pings/Trackbacks          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------

Comment (by ocean90):

 @ramonopoly According to [https://make.wordpress.org/core/2026/04/02/the-
 path-forward-for-wordpress-7-0/ The Path Forward for WordPress 7.0] "trunk
 is closed to commits for the 7.1 release until further notice". Please
 revert the commit from trunk. Thank you!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64837#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 11:37:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 11:37:21 -0000
Subject: [wp-trac] [WordPress Trac] #64837: Disable pings/trackbacks for
 local, development, and staging environments
In-Reply-To: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
References: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
Message-ID: <069.1be513b7c7f583383ba07d3e056503a9@wordpress.org>

#64837: Disable pings/trackbacks for local, development, and staging environments
--------------------------------------+-------------------------
 Reporter:  cagrimmett                |       Owner:  ramonopoly
     Type:  enhancement               |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.1
Component:  Pings/Trackbacks          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------

Comment (by ramonopoly):

 In [changeset:"62233" 62233]:
 {{{
 #!CommitTicketReference repository="" revision="62233"
 REVERT r62231: Disable pings/trackbacks for local, development, and
 staging environments

 Commits to trunk have been paused for 7.0.

 See: https://make.wordpress.org/core/2026/04/02/the-path-forward-for-
 wordpress-7-0/

 Props arcangelini, cagrimmett, ramonopoly, tyxla, ocean90, khushipatel15.

 Follow-up to [64837].

 See #64837.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64837#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 11:38:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 11:38:33 -0000
Subject: [wp-trac] [WordPress Trac] #64837: Disable pings/trackbacks for
 local, development, and staging environments
In-Reply-To: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
References: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
Message-ID: <069.64d3ce5b6f665c39b164145db77b6c9e@wordpress.org>

#64837: Disable pings/trackbacks for local, development, and staging environments
--------------------------------------+-------------------------
 Reporter:  cagrimmett                |       Owner:  ramonopoly
     Type:  enhancement               |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.1
Component:  Pings/Trackbacks          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------

Comment (by ramonopoly):

 > Please revert the commit from trunk. Thank you!

 Thanks for the prompt heads up, @ocean90. Done.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64837#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 12:39:42 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 12:39:42 -0000
Subject: [wp-trac] [WordPress Trac] #65072: Registering a query_var called
 'preview_nonce' stops previews from working.
Message-ID: <048.7afd71163fa7251c64a828f1b0c4e5e3@wordpress.org>

#65072: Registering a query_var called 'preview_nonce' stops previews from working.
--------------------------+-----------------------------
 Reporter:  dsas          |      Owner:  dsas
     Type:  defect (bug)  |     Status:  assigned
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Query         |    Version:
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 **Summary**

 The static front page fallback in WP_Query::get_posts()
 [https://github.com/WordPress/wordpress-
 develop/blob/aa72dfed4432cfd875f77d2c475f772c6623cae5/src/wp-includes
 /class-wp-query.php#L2042 line ~2042] sets `is_page = true` and `is_home =
 false`, but does not update `is_singular`. This causes the query to
 generate incorrect SQL — using `post_type = 'post'` instead of `post_type
 = 'page'` — and return zero results.

 The equivalent check in `parse_query()` ([https://github.com/WordPress
 /wordpress-develop/blob/aa72dfed4432cfd875f77d2c475f772c6623cae5/src/wp-
 includes/class-wp-query.php#L1057 line ~1057]) correctly maintains the
 invariant by [https://github.com/WordPress/wordpress-
 develop/blob/aa72dfed4432cfd875f77d2c475f772c6623cae5/src/wp-includes
 /class-wp-query.php#L1135 recalculating is_singular at line 1135]. The
 `get_posts()`  backstop does not.

 **How to trigger**
 The backstop fires when `parse_query()` fails to detect the static front
 page because $this->query contains unexpected public query vars (anything
 not in the allowlist of preview, page, paged, cpage). This can happen when
 a plugin registers a query var that collides with a parameter WordPress
 core uses in preview URLs — for example, registering preview_nonce as a
 public query var.

 **Steps to reproduce**
  1. Register preview_nonce as a public query var: `add_filter(
 'query_vars', function ( $vars ) { $vars[] = 'preview_nonce'; return
 $vars; } );`
  2. Set a static front page in Settings → Reading
  3. Visit /?preview_id=<page_id>&preview_nonce=<valid_nonce>&preview=true

 Expected: The static front page content is displayed.
 Actual: The blog post index is displayed. The preview URL is redirected
 with preview=true stripped.

 **What happens internally**

   1. `parse_query()` line ~1057: The `array_diff` check fails because
 `preview_nonce` is not in the allowlist. `is_home` stays `true`, `is_page`
 stays `false`, `is_singular` stays `false`.

   2. `get_posts()` line ~2046: The backstop fires because `is_home` is
 `true` and `$query_vars['preview']` is `'true'`. It sets `is_page = true`,
 `is_home = false`, and `page_id` to the front page ID. **But it does not
 set `is_singular = true`.**

   3. `get_posts()` line ~2618: `$post_type_where` is correctly set to
 `post_type = 'page'` based on `is_page = true`.

   4. `get_posts()` line ~2705: The `! $this->is_singular` branch is
 entered. This branch builds its own combined post_type + post_status
 clause. Since `$post_type` is empty (line ~2003), line ~2713 defaults to
 `array('post')`, overriding the correct `post_type_where` from step 3.

   5. The resulting SQL is `WHERE ID = <page_id> AND post_type = 'post'`,
 which returns zero rows because the front page is a `page`.

   6. With zero results, `redirect_canonical` strips `preview=true` from
 the URL and redirects. On the second request, neither `parse_query()` nor
 the backstop can identify the request as the static front page.

 ** Note **

 I've fixed the plugin which exposed this issue, but the is_singular
 invariant violation in the backstop is a core issue.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65072>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 12:46:45 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 12:46:45 -0000
Subject: [wp-trac] [WordPress Trac] #65070: Move inline JS from
 admin_head hooks in options screens into options.js
In-Reply-To: <052.98f5306281d31ac9ff14534bac93246c@wordpress.org>
References: <052.98f5306281d31ac9ff14534bac93246c@wordpress.org>
Message-ID: <067.947614fb5a099d1cdcb1a97a619096d7@wordpress.org>

#65070: Move inline JS from admin_head hooks in options screens into options.js
----------------------------+------------------------------
 Reporter:  anukasha        |       Owner:  (none)
     Type:  enhancement     |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  needs-patch     |     Focuses:
----------------------------+------------------------------
Changes (by wpdevsxyz):

 * Attachment "65070.patch" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65070>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 12:58:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 12:58:14 -0000
Subject: [wp-trac] [WordPress Trac] #65070: Move inline JS from
 admin_head hooks in options screens into options.js
In-Reply-To: <052.98f5306281d31ac9ff14534bac93246c@wordpress.org>
References: <052.98f5306281d31ac9ff14534bac93246c@wordpress.org>
Message-ID: <067.2fbf410a51fa8cd1ba209a5b5b221cce@wordpress.org>

#65070: Move inline JS from admin_head hooks in options screens into options.js
----------------------------+-----------------------------------------
 Reporter:  anukasha        |       Owner:  (none)
     Type:  enhancement     |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:  javascript, administration
----------------------------+-----------------------------------------
Changes (by wpdevsxyz):

 * keywords:  needs-patch => has-patch
 * focuses:   => javascript, administration


Comment:

 This patch moves the three inline <script> blocks from admin_head hooks
 into
 a new enqueued file: src/js/_enqueues/admin/options.js.

 Changes:
 - Created src/js/_enqueues/admin/options.js with all three JS blocks
 combined
 - Registered 'options' script handle in script-loader.php (jquery
 dependency, footer)
 - options-general.php: wp_enqueue_script('options') + wp_localize_script()
 to pass homeURL
 - options-discussion.php: wp_enqueue_script('options')
 - options-reading.php: wp_enqueue_script('options')
 - Deprecated options_discussion_add_js(), options_general_add_js(),
 options_reading_add_js() in 7.1.0

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65070#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:02:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:02:28 -0000
Subject: [wp-trac] [WordPress Trac] #65032: View transition admin bar
 quirks
In-Reply-To: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
References: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
Message-ID: <067.a6d8cd893ee052af8e6ec6be858cfd18@wordpress.org>

#65032: View transition admin bar quirks
----------------------------+---------------------
 Reporter:  zieladam        |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:  ui
----------------------------+---------------------
Changes (by joedolson):

 * focuses:  ui, accessibility => ui


Comment:

 I'm removing the accessibility focus from this; for accessibility
 purposes, this is resolved by the existing support for prefers-reduced-
 motion and otherwise doesn't have any additional impact beyond any other
 aspect of the view transition animation.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65032#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:04:51 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:04:51 -0000
Subject: [wp-trac] [WordPress Trac] #64934: Admin menu is much harder to
 read when icons are nearly the same color as labels
In-Reply-To: <053.c9505026ac6f16f8156796cfc814a99f@wordpress.org>
References: <053.c9505026ac6f16f8156796cfc814a99f@wordpress.org>
Message-ID: <068.7905e933511f14d35f3e31e70f195c44@wordpress.org>

#64934: Admin menu is much harder to read when icons are nearly the same color as
labels
-------------------------------------+-------------------------------------
 Reporter:  cbirdsong                |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Administration           |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  admin-reskin needs-      |     Focuses:  accessibility, css,
  design-feedback                    |  administration
-------------------------------------+-------------------------------------

Comment (by joedolson):

 Some feedback on this would be helpful! I don't know whether the color
 change was intentional or not, @fabiankaegy; I know that I hadn't even
 realized that there were two colors represented here previously, so I
 could readily believe it was an oversight.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64934#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:08:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:08:23 -0000
Subject: [wp-trac] [WordPress Trac] #65073: Connectors: reference to AI
 plugin uses old `ai` slug instead of correct `ai-wp-admin` slug
Message-ID: <052.ad97c034b09747ca93f06d7293e387ff@wordpress.org>

#65073: Connectors: reference to AI plugin uses old `ai` slug instead of correct
`ai-wp-admin` slug
--------------------------+------------------------------------
 Reporter:  JeffPaul      |      Owner:  dkotter
     Type:  defect (bug)  |     Status:  assigned
 Priority:  normal        |  Milestone:  7.0
Component:  AI            |    Version:  trunk
 Severity:  normal        |   Keywords:  needs-patch connectors
  Focuses:                |
--------------------------+------------------------------------
 As called out by @matt
 [https://wordpress.slack.com/archives/C18723MQ8/p1776035129156029 on
 Slack], it seems the Connectors page is linking to the old AI plugin
 settings page slug of `ai` instead of the new, updated `ai-wp-admin`.
 That new slug was required as part of the update of the settings page to
 use `wp-build` tooling in an effort to (1) help test and dogfood that
 package from the Gutenberg team and (2) ensure the page appeared in a more
 modern WordPress admin experience (versus a dated grey background / form
 fields everywhere sort of approach).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65073>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:08:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:08:48 -0000
Subject: [wp-trac] [WordPress Trac] #65073: Connectors: reference to AI
 plugin uses old `ai` slug instead of correct `ai-wp-admin` slug
In-Reply-To: <052.ad97c034b09747ca93f06d7293e387ff@wordpress.org>
References: <052.ad97c034b09747ca93f06d7293e387ff@wordpress.org>
Message-ID: <067.9801ac0603712312252efc6d7d219d60@wordpress.org>

#65073: Connectors: reference to AI plugin uses old `ai` slug instead of correct
`ai-wp-admin` slug
------------------------------------+-----------------------
 Reporter:  JeffPaul                |       Owner:  dkotter
     Type:  defect (bug)            |      Status:  assigned
 Priority:  normal                  |   Milestone:  7.0
Component:  AI                      |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-patch connectors  |     Focuses:
------------------------------------+-----------------------
Changes (by JeffPaul):

 * Attachment "Screenshot 2026-04-14 at 9.00.28 AM.png" added.

 Connectors page where the AI plugin is referenced

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65073>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:09:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:09:06 -0000
Subject: [wp-trac] [WordPress Trac] #65073: Connectors: reference to AI
 plugin uses old `ai` slug instead of correct `ai-wp-admin` slug
In-Reply-To: <052.ad97c034b09747ca93f06d7293e387ff@wordpress.org>
References: <052.ad97c034b09747ca93f06d7293e387ff@wordpress.org>
Message-ID: <067.a67c8359179a4bfd65e0392b1651cf64@wordpress.org>

#65073: Connectors: reference to AI plugin uses old `ai` slug instead of correct
`ai-wp-admin` slug
------------------------------------+-----------------------
 Reporter:  JeffPaul                |       Owner:  dkotter
     Type:  defect (bug)            |      Status:  assigned
 Priority:  normal                  |   Milestone:  7.0
Component:  AI                      |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-patch connectors  |     Focuses:
------------------------------------+-----------------------
Changes (by JeffPaul):

 * Attachment "CleanShot 2026-04-12 at 16.05.05 at 2x.png" added.

 error message presented due to wrong page slug

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65073>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:12:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:12:09 -0000
Subject: [wp-trac] [WordPress Trac] #65071: Focus border styling breaks
 slug input layout in Classic Editor
In-Reply-To: <054.e70f7f0372475cddd66d4c1365327e94@wordpress.org>
References: <054.e70f7f0372475cddd66d4c1365327e94@wordpress.org>
Message-ID: <069.ef15f347b0dbf293e77a27f02fc9569a@wordpress.org>

#65071: Focus border styling breaks slug input layout in Classic Editor
--------------------------+------------------------------
 Reporter:  dhruvang21    |       Owner:  joedolson
     Type:  defect (bug)  |      Status:  accepted
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  ui, css
--------------------------+------------------------------
Changes (by joedolson):

 * owner:  (none) => joedolson
 * status:  new => accepted
 * focuses:  ui, accessibility, css => ui, css


Comment:

 I wouldn't agree that the focus is causing a misalignment; but the bottom
 edge of the focus state is being hidden, resulting in an unexpected
 appearance.

 This is not an accessibility issue; the focus state is still adequate for
 accessibility purposes, so I'm removing the accessibility keyword. I'll
 take ownership, anyway, however.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65071#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:18:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:18:49 -0000
Subject: [wp-trac] [WordPress Trac] #50129: Link edit modal displayed
 over Featured image modal
In-Reply-To: <054.d863811c119ceb3a4261af1893cb383d@wordpress.org>
References: <054.d863811c119ceb3a4261af1893cb383d@wordpress.org>
Message-ID: <069.f30bd33dcae018631a165bf4e900fbc2@wordpress.org>

#50129: Link edit modal displayed over Featured image modal
--------------------------+-------------------------------------
 Reporter:  sumitsingh    |       Owner:  (none)
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:  5.4.1
 Severity:  normal        |  Resolution:  fixed
 Keywords:                |     Focuses:  ui, accessibility, css
--------------------------+-------------------------------------
Changes (by joedolson):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 This was also reported in
 https://github.com/WordPress/gutenberg/issues/29158, but resolved at some
 unknown time.

 It seems like it was probably fixed incidentally, as part of some other
 refactor or unrelated change. It doesn't appear to still be an issue, and
 even if it was, it would need to be reported in the Gutenberg repository,
 so I'm going to go ahead and close this ticket.

 Thanks for following up, @sumitsingh! And the badge you'd get for this is
 Core Contributor, which you already have, so I don't think there's any
 need for follow up there.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/50129#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:27:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:27:18 -0000
Subject: [wp-trac] [WordPress Trac] #49526: Misaligned theme count on
 Add Themes screen on iPhone X
In-Reply-To: <054.3c38ce0c1cda33c9918d2c0825c81527@wordpress.org>
References: <054.3c38ce0c1cda33c9918d2c0825c81527@wordpress.org>
Message-ID: <069.7339a880861a1f99393191ba9eec96db@wordpress.org>

#49526: Misaligned theme count on Add Themes screen on iPhone X
---------------------------------------+---------------------------------
 Reporter:  sumitsingh                 |       Owner:  (none)
     Type:  defect (bug)               |      Status:  closed
 Priority:  normal                     |   Milestone:  Awaiting Review
Component:  Themes                     |     Version:
 Severity:  normal                     |  Resolution:  fixed
 Keywords:  has-screenshots has-patch  |     Focuses:  ui, administration
---------------------------------------+---------------------------------
Changes (by joedolson):

 * keywords:  has-screenshots has-patch needs-unit-tests => has-screenshots
     has-patch
 * status:  new => closed
 * focuses:  ui, accessibility, administration => ui, administration
 * resolution:   => fixed


Comment:

 This issue was fixed in [59708]; this ticket was probably not caught when
 #62499 was added.

 Adding props for @sumitsingh to that original and @hiddeninfotech to the
 commit.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/49526#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:31:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:31:29 -0000
Subject: [wp-trac] [WordPress Trac] #65073: Connectors: reference to AI
 plugin uses old `ai` slug instead of correct `ai-wp-admin` slug
In-Reply-To: <052.ad97c034b09747ca93f06d7293e387ff@wordpress.org>
References: <052.ad97c034b09747ca93f06d7293e387ff@wordpress.org>
Message-ID: <067.a8c1ab48f358f2523508cb67f9d131ea@wordpress.org>

#65073: Connectors: reference to AI plugin uses old `ai` slug instead of correct
`ai-wp-admin` slug
------------------------------------+-----------------------
 Reporter:  JeffPaul                |       Owner:  dkotter
     Type:  defect (bug)            |      Status:  assigned
 Priority:  normal                  |   Milestone:  7.0
Component:  AI                      |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-patch connectors  |     Focuses:
------------------------------------+-----------------------

Comment (by dkotter):

 Looks like the source code for this is handled in the Gutenberg plugin.
 Opened a PR there to fix:
 https://github.com/WordPress/gutenberg/pull/77336

 Not sure what else is needed here on Trac for that or if that will just
 auto-sync back to WordPress Core once merged.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65073#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:32:02 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:32:02 -0000
Subject: [wp-trac] [WordPress Trac] #65027: Add ID do Section titles
 generated by Settings API
In-Reply-To: <049.5cca681fb1dec77bdd5b65aa7d19357d@wordpress.org>
References: <049.5cca681fb1dec77bdd5b65aa7d19357d@wordpress.org>
Message-ID: <064.c5550e65fb6202dafbf491c5918f1247@wordpress.org>

#65027: Add ID do Section titles generated by Settings API
--------------------------+------------------------------------------------
 Reporter:  wetah         |       Owner:  (none)
     Type:  enhancement   |      Status:  new
 Priority:  normal        |   Milestone:  7.1
Component:                |     Version:
  Administration          |
 Severity:  minor         |  Resolution:
 Keywords:  has-patch     |     Focuses:  ui, accessibility, administration
--------------------------+------------------------------------------------
Changes (by joedolson):

 * severity:  trivial => minor
 * milestone:  Awaiting Review => 7.1


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65027#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:38:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:38:09 -0000
Subject: [wp-trac] [WordPress Trac] #65073: Connectors: reference to AI
 plugin uses old `ai` slug instead of correct `ai-wp-admin` slug
In-Reply-To: <052.ad97c034b09747ca93f06d7293e387ff@wordpress.org>
References: <052.ad97c034b09747ca93f06d7293e387ff@wordpress.org>
Message-ID: <067.bdc699d4433ab38633aa2d4a8ad61fb0@wordpress.org>

#65073: Connectors: reference to AI plugin uses old `ai` slug instead of correct
`ai-wp-admin` slug
------------------------------------+-----------------------
 Reporter:  JeffPaul                |       Owner:  dkotter
     Type:  defect (bug)            |      Status:  assigned
 Priority:  normal                  |   Milestone:  7.0
Component:  AI                      |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-patch connectors  |     Focuses:
------------------------------------+-----------------------

Comment (by JeffPaul):

 Moved upstream to https://github.com/WordPress/gutenberg/issues/77337

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65073#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:39:50 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:39:50 -0000
Subject: [wp-trac] [WordPress Trac] #64948: Media Modal: Can no longer
 set attachment filters
In-Reply-To: <059.043db9fa3e3bcd837140db59ad9266de@wordpress.org>
References: <059.043db9fa3e3bcd837140db59ad9266de@wordpress.org>
Message-ID: <074.d2204d468563b65251a75592e338cc63@wordpress.org>

#64948: Media Modal: Can no longer set attachment filters
-----------------------------+-------------------------
 Reporter:  Bernhard Reiter  |       Owner:  joedolson
     Type:  defect (bug)     |      Status:  accepted
 Priority:  normal           |   Milestone:  7.0
Component:  Media            |     Version:  trunk
 Severity:  normal           |  Resolution:
 Keywords:  has-patch        |     Focuses:  javascript
-----------------------------+-------------------------
Changes (by ozgursar):

 * Attachment "before-64948.webp" added.

 Browser console before applying patch PR 11415

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64948>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:39:51 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:39:51 -0000
Subject: [wp-trac] [WordPress Trac] #65029: Add Keyboard Shortcut to
 Hide and Show Toolbar on Frontend
In-Reply-To: <050.6dc60cf2bb50968de73232ec75bf728d@wordpress.org>
References: <050.6dc60cf2bb50968de73232ec75bf728d@wordpress.org>
Message-ID: <065.d6f8f5e75fff4e4776fad11690e416a6@wordpress.org>

#65029: Add Keyboard Shortcut to Hide and Show Toolbar on Frontend
-----------------------------------+------------------------------
 Reporter:  apermo                 |       Owner:  (none)
     Type:  enhancement            |      Status:  new
 Priority:  normal                 |   Milestone:  Awaiting Review
Component:  Toolbar                |     Version:
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |     Focuses:  accessibility
-----------------------------------+------------------------------
Changes (by joedolson):

 * keywords:  has-patch => has-patch 2nd-opinion


Comment:

 This seems worth discussing. I have a couple concerns about adding it.

 First, the actual functionality is relatively trivial for a developer to
 handle on their own - e.g., via a bookmarklet to hide the adminbar or by
 maintaining a private window without it.

 Second, adding a keyboard-only control that can't be used on mobile
 devices or with a mouse, even if it's a relatively minor convenience
 feature, seems like an issue. I generally would prefer that a keyboard
 shortcut is a shortcut for using some existing feature, rather than adding
 a wholly new feature. (I guess I'm saying that it's not a shortcut, in
 this case...)

 Looking for 2nd opinions...

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65029#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:41:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:41:13 -0000
Subject: [wp-trac] [WordPress Trac] #64948: Media Modal: Can no longer
 set attachment filters
In-Reply-To: <059.043db9fa3e3bcd837140db59ad9266de@wordpress.org>
References: <059.043db9fa3e3bcd837140db59ad9266de@wordpress.org>
Message-ID: <074.ebd1c04205fcd675b4d717b43a1136c9@wordpress.org>

#64948: Media Modal: Can no longer set attachment filters
-----------------------------+-------------------------
 Reporter:  Bernhard Reiter  |       Owner:  joedolson
     Type:  defect (bug)     |      Status:  accepted
 Priority:  normal           |   Milestone:  7.0
Component:  Media            |     Version:  trunk
 Severity:  normal           |  Resolution:
 Keywords:  has-patch        |     Focuses:  javascript
-----------------------------+-------------------------
Changes (by ozgursar):

 * Attachment "after-64948.webp" added.

 Browser console after applying patch PR 11415

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64948>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:44:51 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:44:51 -0000
Subject: [wp-trac] [WordPress Trac] #64923: command palette input
 doesn't allow some keys
In-Reply-To: <053.747254a9dfeb40c7a22945bdf3952663@wordpress.org>
References: <053.747254a9dfeb40c7a22945bdf3952663@wordpress.org>
Message-ID: <068.084fe9760e3919d5db7f5472393978b9@wordpress.org>

#64923: command palette input doesn't allow some keys
--------------------------+--------------------------------
 Reporter:  Presskopp     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  Editor        |     Version:
 Severity:  normal        |  Resolution:  reported-upstream
 Keywords:  close         |     Focuses:  ui, accessibility
--------------------------+--------------------------------
Changes (by joedolson):

 * status:  new => closed
 * resolution:   => reported-upstream
 * milestone:  Awaiting Review =>


Comment:

 I think closing this ticket and focusing on the upstream ticket makes
 sense. Practically speaking, none of the work on this is primarily core
 work, so the only resolution is "reported upstream", anyway.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64923#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:45:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:45:39 -0000
Subject: [wp-trac] [WordPress Trac] #64948: Media Modal: Can no longer
 set attachment filters
In-Reply-To: <059.043db9fa3e3bcd837140db59ad9266de@wordpress.org>
References: <059.043db9fa3e3bcd837140db59ad9266de@wordpress.org>
Message-ID: <074.cb769753bbcea90fae10e12bf377eb81@wordpress.org>

#64948: Media Modal: Can no longer set attachment filters
-----------------------------+-------------------------
 Reporter:  Bernhard Reiter  |       Owner:  joedolson
     Type:  defect (bug)     |      Status:  accepted
 Priority:  normal           |   Milestone:  7.0
Component:  Media            |     Version:  trunk
 Severity:  normal           |  Resolution:
 Keywords:  has-patch        |     Focuses:  javascript
-----------------------------+-------------------------

Comment (by ozgursar):

 == Patch Testing Report

 Patch Tested: https://github.com/WordPress/wordpress-develop/pull/11415

 === Environment
 - WordPress: 7.1-alpha-62161-src
 - PHP: 8.2.29
 - Server: nginx/1.29.4
 - Database: mysqli (Server: 8.4.7 / Client: mysqlnd 8.2.29)
 - Browser: Chrome 146.0.0.0
 - OS: macOS
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None activated
 - Plugins:
   * Code Snippets 3.9.5
   * Test Reports 1.2.1

 === Steps taken
 1. Add the following PHP snippet to your active theme's `functions.php` or
 via Code Snippets plugin to simulate accessing the filters.


 {{{
 add_action( 'admin_footer', function () {
     if ( ! did_action( 'wp_enqueue_media' ) ) {
         return;
     }
     ?>
     <script>
     jQuery( document ).ready( function ( $ ) {
         if ( ! wp || ! wp.media || ! wp.media.view || !
 wp.media.view.AttachmentsBrowser ) {
             return;
         }

         var OrigBrowser = wp.media.view.AttachmentsBrowser;

         wp.media.view.AttachmentsBrowser = OrigBrowser.extend( {
             createToolbar: function () {
                 OrigBrowser.prototype.createToolbar.apply( this, arguments
 );

                 var toolbar = this.toolbar;
                 var filters = toolbar.get( 'filters' );

                 console.log( '[Ticket 64948] toolbar.get("filters"):',
 filters );
                 console.log( '[Ticket 64948] filters.filters:', filters &&
 filters.filters );

                 // Simulate what affected plugins do:
                 if ( filters && typeof filters.filters !== 'undefined' ) {
                     console.info( '[Ticket 64948] PASS: filters.filters is
 accessible.' );
                 } else {
                     console.error( '[Ticket 64948] FAIL: filters.filters
 is undefined.' );
                 }
             }
         } );
     } );
     </script>
     <?php
 } );

 }}}


 2. Navigate to any post/page editor or the Media Library
 3. Click ''Add Media'' to open the media modal
 4. Observe the browser console
 5. Confirm that `filters.filters` is undefined
 6. Apply the patch and repeat steps 2-4
 7. Observe the browser console again
 8. Confirm that `toolbar.get("filters")` and `filters.filters` are
 accessible
 9. ✅ Patch is solving the problem.

 === Expected result
 - Plugins that customize media library filters by accessing
 `toolbar.get("filters")` should continue to work correctly, and no errors
 related to `filters.filters` being `undefined` should appear in the
 browser console.

 === Screenshots/Screencast with results
 Before
 [[Image(https://core.trac.wordpress.org/raw-
 attachment/ticket/64948/before-64948.webp)]]

 After
 [[Image(https://core.trac.wordpress.org/raw-
 attachment/ticket/64948/after-64948.webp)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64948#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:50:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:50:07 -0000
Subject: [wp-trac] [WordPress Trac] #65074: Rendering error of the
 wp_register_ability_category() doc page
Message-ID: <051.9cc2c3e95c512c8a3da7af5a1cb669fd@wordpress.org>

#65074: Rendering error of the wp_register_ability_category() doc page
--------------------------------+-----------------------------
 Reporter:  satollo             |      Owner:  (none)
     Type:  defect (bug)        |     Status:  new
 Priority:  normal              |  Milestone:  Awaiting Review
Component:  WordPress.org Site  |    Version:  6.9.4
 Severity:  normal              |   Keywords:
  Focuses:                      |
--------------------------------+-----------------------------
 The page
 https://developer.wordpress.org/reference/functions/wp_register_ability_category/
 has the Parameters section not rendered correctly; it's probably something
 related to the function's PHPDoc.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65074>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:50:35 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:50:35 -0000
Subject: [wp-trac] [WordPress Trac] #65074: Rendering error of the
 wp_register_ability_category() doc page
In-Reply-To: <051.9cc2c3e95c512c8a3da7af5a1cb669fd@wordpress.org>
References: <051.9cc2c3e95c512c8a3da7af5a1cb669fd@wordpress.org>
Message-ID: <066.7ecb43f76854a1e4e819cb6ffc18615c@wordpress.org>

#65074: Rendering error of the wp_register_ability_category() doc page
--------------------------------+------------------------------
 Reporter:  satollo             |       Owner:  (none)
     Type:  defect (bug)        |      Status:  new
 Priority:  normal              |   Milestone:  Awaiting Review
Component:  WordPress.org Site  |     Version:  6.9.4
 Severity:  normal              |  Resolution:
 Keywords:                      |     Focuses:
--------------------------------+------------------------------
Changes (by satollo):

 * Attachment "2026-04-14_174902.png" added.

 Screenshot of the rendering error

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65074>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:52:02 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:52:02 -0000
Subject: [wp-trac] [WordPress Trac] #55343: Add Tooltip to "Remember Me"
 (WP Login Form)
In-Reply-To: <053.b5a11e22532e0c787bec386d453e28ca@wordpress.org>
References: <053.b5a11e22532e0c787bec386d453e28ca@wordpress.org>
Message-ID: <068.9d27e01e476fd5ac09a78f9312404fa6@wordpress.org>

#55343: Add Tooltip to "Remember Me" (WP Login Form)
---------------------------------------------+-----------------------------
 Reporter:  generosus                        |       Owner:  rajinsharwar
     Type:  enhancement                      |      Status:  assigned
 Priority:  normal                           |   Milestone:  7.1
Component:  Login and Registration           |     Version:
 Severity:  normal                           |  Resolution:
 Keywords:  dev-feedback tooltips has-patch  |     Focuses:  ui,
                                             |  accessibility
---------------------------------------------+-----------------------------
Changes (by joedolson):

 * milestone:  Future Release => 7.1


Comment:

 With CSS anchor positioning having meet the basic criteria for
 [https://make.wordpress.org/core/handbook/best-practices/browser-support/
 WordPress browser support], let's go ahead and work on a new patch to get
 this resolved using native tooltips.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/55343#comment:24>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:52:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:52:26 -0000
Subject: [wp-trac] [WordPress Trac] #36447: Responsive preview icons in
 Customizer need tooltips
In-Reply-To: <051.2a17e037333f6e4ce21cf710a953149b@wordpress.org>
References: <051.2a17e037333f6e4ce21cf710a953149b@wordpress.org>
Message-ID: <066.5253e129e63fcab46d0cd430337dae17@wordpress.org>

#36447: Responsive preview icons in Customizer need tooltips
-------------------------------------------------+-------------------------
 Reporter:  ahortin                              |       Owner:  joedolson
     Type:  enhancement                          |      Status:  accepted
 Priority:  normal                               |   Milestone:  7.1
Component:  Customize                            |     Version:  4.6
 Severity:  normal                               |  Resolution:
 Keywords:  has-screenshots tooltips dev-        |     Focuses:
  feedback has-patch                             |  accessibility
-------------------------------------------------+-------------------------
Changes (by joedolson):

 * milestone:  Future Release => 7.1


Comment:

 With CSS anchor positioning having meet the basic criteria for
 [https://make.wordpress.org/core/handbook/best-practices/browser-support/
 WordPress browser support], let's go ahead and work on a new patch to get
 this resolved using native tooltips.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/36447#comment:23>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:53:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:53:21 -0000
Subject: [wp-trac] [WordPress Trac] #50921: Consider adding tooltips for
 metabox order buttons
In-Reply-To: <051.5dde226e22fb9cba827b6ad3e1368c7c@wordpress.org>
References: <051.5dde226e22fb9cba827b6ad3e1368c7c@wordpress.org>
Message-ID: <066.9fddd7fd83041e8f5329e4050a854406@wordpress.org>

#50921: Consider adding tooltips for metabox order buttons
--------------------------------------+--------------------------------
 Reporter:  ibachal                   |       Owner:  joedolson
     Type:  enhancement               |      Status:  accepted
 Priority:  normal                    |   Milestone:  7.1
Component:  Editor                    |     Version:  5.5
 Severity:  normal                    |  Resolution:
 Keywords:  has-screenshots tooltips  |     Focuses:  ui, accessibility
--------------------------------------+--------------------------------
Changes (by joedolson):

 * milestone:  Future Release => 7.1


Comment:

 With CSS anchor positioning having meet the basic criteria for
 [https://make.wordpress.org/core/handbook/best-practices/browser-support/
 WordPress browser support], let's go ahead and work on a new patch to get
 this resolved using native tooltips.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/50921#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:54:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:54:13 -0000
Subject: [wp-trac] [WordPress Trac] #51006: Add a mechanism for
 accessible tooltips in core
In-Reply-To: <053.91385a0238311265c80f108a75432843@wordpress.org>
References: <053.91385a0238311265c80f108a75432843@wordpress.org>
Message-ID: <068.54aba9a806d2a14f3003e6cc18a220d4@wordpress.org>

#51006: Add a mechanism for accessible tooltips in core
-------------------------------------+-------------------------------------
 Reporter:  joedolson                |       Owner:  joedolson
     Type:  enhancement              |      Status:  accepted
 Priority:  normal                   |   Milestone:  7.1
Component:  General                  |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  tooltips has-patch       |     Focuses:  ui, accessibility,
  needs-unit-tests needs-test-info   |  javascript
-------------------------------------+-------------------------------------
Changes (by joedolson):

 * milestone:  Future Release => 7.1


Comment:

 With CSS anchor positioning having meet the basic criteria for
 [https://make.wordpress.org/core/handbook/best-practices/browser-support/
 WordPress browser support], let's go ahead and work on a new patch to get
 this resolved using native tooltips.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/51006#comment:60>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:54:45 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:54:45 -0000
Subject: [wp-trac] [WordPress Trac] #58312: Display password hint on
 additional screens
In-Reply-To: <052.3217a9cd09ad1f143b1c5627abc8d046@wordpress.org>
References: <052.3217a9cd09ad1f143b1c5627abc8d046@wordpress.org>
Message-ID: <067.a8ad91fa31fbc592806cd444105d4bed@wordpress.org>

#58312: Display password hint on additional screens
-------------------------------------------------+-------------------------
 Reporter:  petitphp                             |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  7.1
Component:  Users                                |     Version:  4.3
 Severity:  normal                               |  Resolution:
 Keywords:  tooltips has-patch dev-feedback      |     Focuses:
  2nd-opinion                                    |  administration
-------------------------------------------------+-------------------------
Changes (by joedolson):

 * milestone:  Future Release => 7.1


Comment:

 With CSS anchor positioning having meet the basic criteria for
 [https://make.wordpress.org/core/handbook/best-practices/browser-support/
 WordPress browser support], let's go ahead and work on a new patch to get
 this resolved using native tooltips.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/58312#comment:19>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 15:54:50 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 15:54:50 -0000
Subject: [wp-trac] [WordPress Trac] #58312: Display password hint on
 additional screens
In-Reply-To: <052.3217a9cd09ad1f143b1c5627abc8d046@wordpress.org>
References: <052.3217a9cd09ad1f143b1c5627abc8d046@wordpress.org>
Message-ID: <067.2ac6750e330cd780db97330d6354444d@wordpress.org>

#58312: Display password hint on additional screens
-------------------------------------------------+-------------------------
 Reporter:  petitphp                             |       Owner:  joedolson
     Type:  enhancement                          |      Status:  accepted
 Priority:  normal                               |   Milestone:  7.1
Component:  Users                                |     Version:  4.3
 Severity:  normal                               |  Resolution:
 Keywords:  tooltips has-patch dev-feedback      |     Focuses:
  2nd-opinion                                    |  administration
-------------------------------------------------+-------------------------
Changes (by joedolson):

 * owner:  (none) => joedolson
 * status:  new => accepted


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/58312#comment:20>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 16:02:24 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 16:02:24 -0000
Subject: [wp-trac] [WordPress Trac] #48452: Proposal: improve
 distinction between buttons and other controls
In-Reply-To: <050.3469a4cee0f5cc44c63d5c4ea3c47200@wordpress.org>
References: <050.3469a4cee0f5cc44c63d5c4ea3c47200@wordpress.org>
Message-ID: <065.7b295f519d339d9a34377355c93093b3@wordpress.org>

#48452: Proposal: improve distinction between buttons and other controls
-------------------------------------------------+-------------------------
 Reporter:  drw158                               |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Administration                       |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  needs-design-feedback has-           |     Focuses:  ui,
  screenshots                                    |  accessibility
-------------------------------------------------+-------------------------

Comment (by joedolson):

 This issue could stand some reassessment, following the admin redesign.

 Currently, the input design is a black border and white background, the
 secondary button is a blue border and transparent background. This works
 fine with the current background color, but would be less differentiated
 if the background is changed to white (or in a context inside a container
 where the background is white.) There *is* a different, but it's
 relatively subtle.

 The text is also bold and blue, which helps.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/48452#comment:31>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 16:02:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 16:02:55 -0000
Subject: [wp-trac] [WordPress Trac] #48452: Proposal: improve
 distinction between buttons and other controls
In-Reply-To: <050.3469a4cee0f5cc44c63d5c4ea3c47200@wordpress.org>
References: <050.3469a4cee0f5cc44c63d5c4ea3c47200@wordpress.org>
Message-ID: <065.9a58243c0005ad0c875748d23bd75fe5@wordpress.org>

#48452: Proposal: improve distinction between buttons and other controls
-------------------------------------------------+-------------------------
 Reporter:  drw158                               |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Administration                       |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  needs-design-feedback has-           |     Focuses:  ui,
  screenshots                                    |  accessibility
-------------------------------------------------+-------------------------
Changes (by joedolson):

 * Attachment "Screenshot 2026-04-14 110239.png" added.

 Example input/button in WordPress 7.0

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/48452>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 17:28:46 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 17:28:46 -0000
Subject: [wp-trac] [WordPress Trac] #65075: Links on wp-login.php are not
 identifiable
Message-ID: <051.c9abb471a292e3c2a8e28bf5794e2add@wordpress.org>

#65075: Links on wp-login.php are not identifiable
------------------------------------+-----------------------------
 Reporter:  dcavins                 |      Owner:  (none)
     Type:  enhancement             |     Status:  new
 Priority:  normal                  |  Milestone:  Awaiting Review
Component:  Login and Registration  |    Version:  6.9.4
 Severity:  normal                  |   Keywords:
  Focuses:                          |
------------------------------------+-----------------------------
 Accessibility scanning tools are pointing out that the links on a vanilla
 WordPress installation's wp-login screen are not identifiable. They are
 text-colored and the default text-underline has been nulled:


 {{{
 .login #nav a, .login #backtoblog a {
     text-decoration: none;
     color: #50575e;
 }
 }}}

 On WP.org, specific login styles have been added to address this
 accessibility concern:


 {{{
     text-decoration: underline !important;
 }}}

 I propose that the property `text-decoration: none;` simply be removed
 from `login.css` for improved accessibility standards compliance.

 Thanks!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65075>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 17:47:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 17:47:06 -0000
Subject: [wp-trac] [WordPress Trac] #65074: Rendering error of the
 wp_register_ability_category() doc page
In-Reply-To: <051.9cc2c3e95c512c8a3da7af5a1cb669fd@wordpress.org>
References: <051.9cc2c3e95c512c8a3da7af5a1cb669fd@wordpress.org>
Message-ID: <066.7435b2e5caab6df41320cdf383f9e3a2@wordpress.org>

#65074: Rendering error of the wp_register_ability_category() doc page
--------------------------------+------------------------------
 Reporter:  satollo             |       Owner:  (none)
     Type:  defect (bug)        |      Status:  new
 Priority:  normal              |   Milestone:  Awaiting Review
Component:  WordPress.org Site  |     Version:  6.9.4
 Severity:  normal              |  Resolution:
 Keywords:                      |     Focuses:
--------------------------------+------------------------------

Comment (by iamadisingh):

 The rendering issue on the page is being triggered by the `<string,
 mixed>` part of the `@param tag`.

 Because of how the DevHub theme parses "hash notation" (the `{` brackets),
 the extra characters in the type declaration are confusing the formatter.
 It’s essentially a false positive where the theme sees the bracket but
 loses track of the variable name, resulting in the broken "mixed>" text we
 see on the site.

 Here: https://github.com/WordPress/wporg-developer/blob/trunk/source/wp-
 content/themes/wporg-developer-2023/inc/formatting.php#L625

 Same issue exists in `wp_register_ability` page:
 https://developer.wordpress.org/reference/functions/wp_register_ability/#parameters

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65074#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 19:02:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 19:02:33 -0000
Subject: [wp-trac] [WordPress Trac] #65062: Revisions: buttons are
 misplaced
In-Reply-To: <053.b9ce602729457db6bab38d69686036f5@wordpress.org>
References: <053.b9ce602729457db6bab38d69686036f5@wordpress.org>
Message-ID: <068.85d58f0ece56112f377208c046e11d69@wordpress.org>

#65062: Revisions: buttons are misplaced
--------------------------------------------------+------------------------
 Reporter:  wildworks                             |       Owner:  joedolson
     Type:  defect (bug)                          |      Status:  accepted
 Priority:  normal                                |   Milestone:  7.0
Component:  Revisions                             |     Version:
 Severity:  normal                                |  Resolution:
 Keywords:  admin-reskin has-patch has-test-info  |     Focuses:
--------------------------------------------------+------------------------
Changes (by mokshasharmila13):

 * keywords:  admin-reskin has-patch => admin-reskin has-patch has-test-info


Comment:

 **Patch Testing Report**

 **Patch Tested:** https://github.com/WordPress/wordpress-
 develop/pull/11549

 ## Environment

 * WordPress: 7.1-alpha (latest)
 * PHP: 8.2
 * Browser: Chrome
 * OS: macOS
 * Theme: Twenty Twenty-Five
 * Plugins: None activated

 ## Testing Steps

 * Opened a post/page in WordPress admin
 * Navigated to the **Revisions** screen
 * Checked the layout in desktop, tablet, and mobile screen sizes
 * Applied the patch and repeated the same steps

 ## Results

 * The Previous and Next buttons alignment looks improved
 * Layout appears consistent across different screen sizes
 * Restore button is displayed correctly
 * No functional issues observed

 The patch is working as expected.

 On smaller mobile screens, the buttons still appear slightly small, which
 could be improved further in future updates, but overall the current patch
 resolves the main alignment issue.

 Tested across multiple screen sizes and everything is working fine.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65062#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 19:23:38 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 19:23:38 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2364962=3A_Install_scr?=
 =?utf-8?b?ZWVuczog4oCcTG9nIElu4oCdIGFuZCAiU3VwcG9ydCBsaW5rIiB1c2Ugb2xk?=
 =?utf-8?q?_color?=
In-Reply-To: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
References: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
Message-ID: <074.c1fbb611e004d2e2750f4dc92fbb5908@wordpress.org>

#64962: Install screens: “Log In” and "Support link" use old color
-------------------------------------------------+-------------------------
 Reporter:  huzaifaalmesbah                      |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch has-          |     Focuses:  ui, css
  screenshots dev-reviewed                       |
-------------------------------------------------+-------------------------
Changes (by audrasjb):

 * keywords:  admin-reskin has-patch has-screenshots dev-feedback => admin-
     reskin has-patch has-screenshots dev-reviewed


Comment:

 Thanks. This is a second committer sign off.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64962#comment:23>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 19:24:32 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 19:24:32 -0000
Subject: [wp-trac] [WordPress Trac] #65060: Formatting issue on
 expand/collapse meta box area focus
In-Reply-To: <053.3f798f1a567cca7e0d02f86b0e08f865@wordpress.org>
References: <053.3f798f1a567cca7e0d02f86b0e08f865@wordpress.org>
Message-ID: <068.c4cd06f6c82666032f2f93bedc2883dd@wordpress.org>

#65060: Formatting issue on expand/collapse meta box area focus
-------------------------------------------------+------------------------
 Reporter:  brianhogg                            |       Owner:  wildworks
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Formatting                           |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch dev-reviewed  |     Focuses:
-------------------------------------------------+------------------------
Changes (by audrasjb):

 * keywords:  admin-reskin has-patch dev-feedback => admin-reskin has-patch
     dev-reviewed


Comment:

 Thanks. This is a second committer sign off.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65060#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 19:31:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 19:31:21 -0000
Subject: [wp-trac] [WordPress Trac] #65075: Links on wp-login.php are
 not identifiable
In-Reply-To: <051.c9abb471a292e3c2a8e28bf5794e2add@wordpress.org>
References: <051.c9abb471a292e3c2a8e28bf5794e2add@wordpress.org>
Message-ID: <066.a723e7610b8dbdbad59ebb29a4158423@wordpress.org>

#65075: Links on wp-login.php are not identifiable
------------------------------------+------------------------------
 Reporter:  dcavins                 |       Owner:  (none)
     Type:  enhancement             |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Login and Registration  |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  2nd-opinion             |     Focuses:  accessibility
------------------------------------+------------------------------
Changes (by audrasjb):

 * keywords:   => 2nd-opinion
 * focuses:   => accessibility
 * version:  6.9.4 =>


Comment:

 Hello and thanks for opening this ticket.
 I'm not opposed to underline these links. But in my opinion, these links
 are in fact quite identifiable as they are not part of a paragraph of
 text, they are just like navigation items, separated from the rest of the
 interface. The standard doesn't enforce underlined text for navigation
 links as the links located in a menu are identifiable by their context. I
 personally feel like it's pretty the same for these links.

 Outside of the scanning tool result, what do you think?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65075#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 21:32:46 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 21:32:46 -0000
Subject: [wp-trac] [WordPress Trac] #64837: Disable pings/trackbacks for
 local, development, and staging environments
In-Reply-To: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
References: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
Message-ID: <069.639be2ceafc6878b3d1de09a61ea1ff3@wordpress.org>

#64837: Disable pings/trackbacks for local, development, and staging environments
--------------------------------------+-------------------------
 Reporter:  cagrimmett                |       Owner:  ramonopoly
     Type:  enhancement               |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.1
Component:  Pings/Trackbacks          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------

Comment (by arcangelini):

 @swissspidy @ramonopoly

 Each function serves a distinct hook with a distinct signature. I explored
 collapsing them, but the options were either inline closures in default-
 filters.php (breaks that file's named-callback convention) or a single
 dispatcher using current_filter() (uglier than the four small functions).

 Happy to revisit if you feel strongly, but I'd prefer to leave it as-is.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64837#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 14 22:29:46 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 14 Apr 2026 22:29:46 -0000
Subject: [wp-trac] [WordPress Trac] #64225: Test tool and unit test
 improvements for 7.0
In-Reply-To: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
References: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
Message-ID: <066.ee9af58c3f15e477b1336ad6aa3feecb@wordpress.org>

#64225: Test tool and unit test improvements for 7.0
--------------------------------------+---------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  task (blessed)            |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by SergeyBiryukov):

 In [changeset:"62234" 62234]:
 {{{
 #!CommitTicketReference repository="" revision="62234"
 Tests: Rename some oEmbed test classes as per the naming conventions.

 Follow-up to [37708], [37892], [62224], [62227].

 See #64225.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64225#comment:65>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 00:19:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 00:19:39 -0000
Subject: [wp-trac] [WordPress Trac] #64902: wp_save_image() fatal error
 when wp_save_image_file() returns WP_Error
In-Reply-To: <053.171527bc59e8c487d3fc7fc913953abd@wordpress.org>
References: <053.171527bc59e8c487d3fc7fc913953abd@wordpress.org>
Message-ID: <068.00fd3fa058184df078b6bacd1be2be34@wordpress.org>

#64902: wp_save_image() fatal error when wp_save_image_file() returns WP_Error
-------------------------------------+------------------------------
 Reporter:  notglossy                |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Media                    |     Version:  6.9.4
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+------------------------------

Comment (by aytor):

 I tested the bug on wordpress with environemnt:
 WordPress: 6.9.4
 PHP: 8.2
 Local WP

 The bug is not reproducing, I'm getting the message saying "Could not load
 the preview image. Please reload the page and try again." but is not
 allowing me to save it the button is grayed out.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64902#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 00:52:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 00:52:57 -0000
Subject: [wp-trac] [WordPress Trac] #64837: Disable pings/trackbacks for
 local, development, and staging environments
In-Reply-To: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
References: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
Message-ID: <069.2eb51da208329267ee963bc199655ca5@wordpress.org>

#64837: Disable pings/trackbacks for local, development, and staging environments
--------------------------------------+-------------------------
 Reporter:  cagrimmett                |       Owner:  ramonopoly
     Type:  enhancement               |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.1
Component:  Pings/Trackbacks          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------

Comment (by ramonopoly):

 > Happy to revisit if you feel strongly, but I'd prefer to leave it as-is.

 In my mind I think it's fine to leave the PR as is until we can commit it
 (again). There are different actions and therefore different signatures.
 As far as I can tell, each function has a single responsibility.

 There's still time until the commit pause is over to wait for actionable
 feedback or an alternative proposal.

 > add_filter('pre_pingback_send'

 Is there any documentation for this filter? I can't find any evidence for
 its existence. Maybe `pre_ping` was meant. Apologies in advance if it's
 documented somewhere and I've just missed it.


 Thanks, all!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64837#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 00:56:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 00:56:26 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.01f9a40be05d75fca26f4a80c11165fc@wordpress.org>

#65015: Connectors: Several strings are not translated
-------------------------------------------------+-------------------------
 Reporter:  369work                              |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  reviewing
 Priority:  high                                 |   Milestone:  7.0
Component:  I18N                                 |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests connectors  |     Focuses:
  commit dev-feedback                            |
-------------------------------------------------+-------------------------
Changes (by westonruter):

 * keywords:  has-patch has-unit-tests connectors => has-patch has-unit-
     tests connectors commit dev-feedback
 * owner:  (none) => westonruter
 * status:  reopened => reviewing


Comment:

 I've reviewed and amended the [https://github.com/WordPress/wordpress-
 develop/pull/11543 core PR]. It's approved by me for commit.

 The companion [https://github.com/WordPress/gutenberg/pull/77214 Gutenberg
 PR] will need to be adjusted based on what gets committed.

 Self-assigning for review and commit. But I'd like to get another
 committer to review this as well since we're in RC-ish.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015#comment:18>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 02:04:43 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 02:04:43 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.27b954ac2344a175cd41daace2a7298a@wordpress.org>

#65015: Connectors: Several strings are not translated
-------------------------------------------------+-------------------------
 Reporter:  369work                              |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  reviewing
 Priority:  high                                 |   Milestone:  7.0
Component:  I18N                                 |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests connectors  |     Focuses:
  commit dev-feedback                            |
-------------------------------------------------+-------------------------

Comment (by 369work):

 I tested it right away, but the word "setup" isn't translated.

 The same goes for "Text generation with Claude."

 I'd like to attach a screenshot, but I don't know how...

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015#comment:19>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 03:41:08 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 03:41:08 -0000
Subject: [wp-trac] [WordPress Trac] #65076: Missing escaping in title tag
Message-ID: <055.b9420f65447244d18f45902ef328903a@wordpress.org>

#65076: Missing escaping in title tag
------------------------------+-----------------------------
 Reporter:  maheshpatel       |      Owner:  (none)
     Type:  defect (bug)      |     Status:  new
 Priority:  normal            |  Milestone:  Awaiting Review
Component:  General           |    Version:  trunk
 Severity:  normal            |   Keywords:  has-patch
  Focuses:  coding-standards  |
------------------------------+-----------------------------
 **Missing escaping in `<title>` tag** ⭐ TOP PICK
 - **File:** [src/wp-login.php](src/wp-login.php#L97)
 - **Line:** 97
 - **Problem:** `<title>` tag outputs `$login_title` without escaping.
 Special characters could break HTML structure.
 - **Severity:** Security best practice
 - **Current Code:**

   <title><?php echo $login_title; ?></title>

 - **Fix:**

   <title><?php echo esc_html( $login_title ); ?></title>

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65076>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 03:46:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 03:46:16 -0000
Subject: [wp-trac] [WordPress Trac] #65076: Missing escaping in title tag
In-Reply-To: <055.b9420f65447244d18f45902ef328903a@wordpress.org>
References: <055.b9420f65447244d18f45902ef328903a@wordpress.org>
Message-ID: <070.5882b33935ef2abc8e07df5f46a294e3@wordpress.org>

#65076: Missing escaping in title tag
--------------------------+-------------------------------
 Reporter:  maheshpatel   |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  coding-standards
--------------------------+-------------------------------

Comment (by maheshpatel):

 The issue has been addressed and a fix has been implemented.

 A pull request has been submitted for review: https://github.com/WordPress
 /wordpress-develop/pull/11575

 Kindly take a look and share your feedback. Happy to make any required
 changes.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65076#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 04:06:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 04:06:18 -0000
Subject: [wp-trac] [WordPress Trac] #65076: Missing escaping in title tag
In-Reply-To: <055.b9420f65447244d18f45902ef328903a@wordpress.org>
References: <055.b9420f65447244d18f45902ef328903a@wordpress.org>
Message-ID: <070.16081c8822434f1b77b041172e192618@wordpress.org>

#65076: Missing escaping in title tag
------------------------------------+-------------------------------
 Reporter:  maheshpatel             |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Login and Registration  |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch               |     Focuses:  coding-standards
------------------------------------+-------------------------------
Changes (by mukesh27):

 * version:  trunk =>
 * component:  General => Login and Registration


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65076#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 04:37:01 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 04:37:01 -0000
Subject: [wp-trac] [WordPress Trac] #65077: Fix incorrect Settings URL for
 AI plugin in Connectors banner
Message-ID: <052.08ece41954b84e2ddbd442486ef33a1e@wordpress.org>

#65077: Fix incorrect Settings URL for AI plugin in Connectors banner
----------------------------+-------------------------
 Reporter:  mukesh27        |      Owner:  (none)
     Type:  defect (bug)    |     Status:  new
 Priority:  normal          |  Milestone:  7.0
Component:  AI              |    Version:  trunk
 Severity:  normal          |   Keywords:  needs-patch
  Focuses:  administration  |
----------------------------+-------------------------
 The `Connectors` settings page contains a call-to-action (CTA) banner to
 install/manage the AI plugin. After the plugin is successfully installed,
 the button link directs users to an incorrect URL, resulting in a
 **"Sorry, you are not allowed to access this page"** error.

 **Steps to Reproduce:**
 1. Log in to the WordPress Admin.
 2. Navigate to **Settings > Connectors**.
 3. In the banner, click the button to **Install the AI plugin**.
 4. Once installed, observe the button text updates to: **"Control features
 in the AI plugin"**.
 5. Click this button.

 **Actual Results:**
 * The button links to: `wp-admin/options-general.php?page=ai`
 * The user is met with a **"Sorry, you are not allowed to access this
 page"** error because that slug does not exist.

 **Expected Results:**
 * The button should link to the correct AI plugin settings page: `wp-admin
 /options-general.php?page=ai-wp-admin`

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65077>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 04:50:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 04:50:28 -0000
Subject: [wp-trac] [WordPress Trac] #65077: Fix incorrect Settings URL
 for AI plugin in Connectors banner
In-Reply-To: <052.08ece41954b84e2ddbd442486ef33a1e@wordpress.org>
References: <052.08ece41954b84e2ddbd442486ef33a1e@wordpress.org>
Message-ID: <067.440a2bf3a1009cfbb3d45027b0cbcff4@wordpress.org>

#65077: Fix incorrect Settings URL for AI plugin in Connectors banner
--------------------------+-----------------------------
 Reporter:  mukesh27      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  AI            |     Version:  trunk
 Severity:  normal        |  Resolution:  duplicate
 Keywords:                |     Focuses:  administration
--------------------------+-----------------------------
Changes (by ocean90):

 * keywords:  needs-patch =>
 * status:  new => closed
 * resolution:   => duplicate
 * milestone:  7.0 =>


Comment:

 Duplicate of #65073.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65077#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 05:01:20 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 05:01:20 -0000
Subject: [wp-trac] [WordPress Trac] #65073: Connectors: reference to AI
 plugin uses old `ai` slug instead of correct `ai-wp-admin` slug
In-Reply-To: <052.ad97c034b09747ca93f06d7293e387ff@wordpress.org>
References: <052.ad97c034b09747ca93f06d7293e387ff@wordpress.org>
Message-ID: <067.ed2bf7e4b29a92b8365be1c19eea3670@wordpress.org>

#65073: Connectors: reference to AI plugin uses old `ai` slug instead of correct
`ai-wp-admin` slug
------------------------------------+-----------------------
 Reporter:  JeffPaul                |       Owner:  dkotter
     Type:  defect (bug)            |      Status:  assigned
 Priority:  normal                  |   Milestone:  7.0
Component:  AI                      |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-patch connectors  |     Focuses:
------------------------------------+-----------------------

Comment (by nimeshatxecurify):

 Raised a PR for WordPress Core : https://github.com/WordPress/wordpress-
 develop/pull/11576

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65073#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 05:27:34 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 05:27:34 -0000
Subject: [wp-trac] [WordPress Trac] #65076: Missing escaping in title tag
In-Reply-To: <055.b9420f65447244d18f45902ef328903a@wordpress.org>
References: <055.b9420f65447244d18f45902ef328903a@wordpress.org>
Message-ID: <070.326f90ce26d16cace443b26194519519@wordpress.org>

#65076: Missing escaping in title tag
------------------------------------+-------------------------------
 Reporter:  maheshpatel             |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Login and Registration  |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch               |     Focuses:  coding-standards
------------------------------------+-------------------------------
Description changed by dd32:

Old description:

> **Missing escaping in `<title>` tag** ⭐ TOP PICK
> - **File:** [src/wp-login.php](src/wp-login.php#L97)
> - **Line:** 97
> - **Problem:** `<title>` tag outputs `$login_title` without escaping.
> Special characters could break HTML structure.
> - **Severity:** Security best practice
> - **Current Code:**
>
>   <title><?php echo $login_title; ?></title>
>
> - **Fix:**
>
>   <title><?php echo esc_html( $login_title ); ?></title>

New description:

 **Missing escaping in `<title>` tag** ⭐ TOP PICK
 - **File:** [src/wp-login.php](src/wp-login.php#L97)
 - **Line:** 97
 - **Problem:** `<title>` tag outputs `$login_title` without escaping.
 Special characters could break HTML structure.
 - **Severity:** Security best practice
 - **Current Code:**
 {{{
   <title><?php echo $login_title; ?></title>
 }}}
 - **Fix:**
 {{{
   <title><?php echo esc_html( $login_title ); ?></title>
 }}}

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65076#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 05:48:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 05:48:12 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.23d3d73d888147207211a38792a10b50@wordpress.org>

#65015: Connectors: Several strings are not translated
-------------------------------------------------+-------------------------
 Reporter:  369work                              |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  reviewing
 Priority:  high                                 |   Milestone:  7.0
Component:  I18N                                 |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests connectors  |     Focuses:
  commit dev-feedback                            |
-------------------------------------------------+-------------------------

Comment (by westonruter):

 @369work This may be explained by @manzoorwanijk in a
 [https://github.com/WordPress/wordpress-
 develop/pull/11543#issuecomment-4233885056 PR comment].

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015#comment:20>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 06:41:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 06:41:48 -0000
Subject: [wp-trac] [WordPress Trac] #65060: Formatting issue on
 expand/collapse meta box area focus
In-Reply-To: <053.3f798f1a567cca7e0d02f86b0e08f865@wordpress.org>
References: <053.3f798f1a567cca7e0d02f86b0e08f865@wordpress.org>
Message-ID: <068.c9dac4a5056e343dfabc8b8c45d933e8@wordpress.org>

#65060: Formatting issue on expand/collapse meta box area focus
-------------------------------------------------+------------------------
 Reporter:  brianhogg                            |       Owner:  wildworks
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  Formatting                           |     Version:  trunk
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  admin-reskin has-patch dev-reviewed  |     Focuses:
-------------------------------------------------+------------------------
Changes (by audrasjb):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62235" 62235]:
 {{{
 #!CommitTicketReference repository="" revision="62235"
 Administration: Fix focus outline being cut off for the metabox collapse
 and move buttons.

 Fixes an issue where the focus outline on metabox collapse buttons and
 move handles was being clipped.

 Reviewed by audrasjb, wildworks.
 Merges [62232] to the 7.0 branch.

 Props abcd95, audrasjb, brianhogg, darshitrajyaguru97, poena, wildworks.
 Fixes #65060.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65060#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 06:44:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 06:44:21 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2364962=3A_Install_scr?=
 =?utf-8?b?ZWVuczog4oCcTG9nIElu4oCdIGFuZCAiU3VwcG9ydCBsaW5rIiB1c2Ugb2xk?=
 =?utf-8?q?_color?=
In-Reply-To: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
References: <059.bb9138da84ce6c186127cc4ee8e1e912@wordpress.org>
Message-ID: <074.189e2ceffe9401497643604baca4086b@wordpress.org>

#64962: Install screens: “Log In” and "Support link" use old color
-------------------------------------------------+-------------------------
 Reporter:  huzaifaalmesbah                      |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  admin-reskin has-patch has-          |     Focuses:  ui, css
  screenshots dev-reviewed                       |
-------------------------------------------------+-------------------------
Changes (by audrasjb):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62236" 62236]:
 {{{
 #!CommitTicketReference repository="" revision="62236"
 Upgrade/Install: Use new default admin color scheme for links on the setup
 screen.

 This changeset updates the link colors on the setup screen and the default
 wp_die() fallback styles to use the new default admin color scheme.

 Reviewed by audrasjb, wildworks.
 Merges [62230] to the 7.0 branch.

 Props audrasjb, darshitrajyaguru97, dhrumilk, hbhalodia, huzaifaalmesbah,
 ismail0071, mikinc860, pooja-n, shailu25, sumitsingh, vishitshah,
 wildworks
 Fixes #64962.
 See #64308.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64962#comment:24>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 06:44:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 06:44:21 -0000
Subject: [wp-trac] [WordPress Trac] #64308: Explore a "Coat-of-Paint"
 Visual Reskin of the WordPress Admin for WordPress 7.0
In-Reply-To: <055.9b9d23b7d737d4bf4984326737268082@wordpress.org>
References: <055.9b9d23b7d737d4bf4984326737268082@wordpress.org>
Message-ID: <070.8f6984a7ca2a49761092aea1c156249e@wordpress.org>

#64308: Explore a "Coat-of-Paint" Visual Reskin of the WordPress Admin for
WordPress 7.0
----------------------------+----------------------
 Reporter:  fabiankaegy     |       Owner:  (none)
     Type:  task (blessed)  |      Status:  closed
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:  fixed
 Keywords:                  |     Focuses:  ui, css
----------------------------+----------------------

Comment (by audrasjb):

 In [changeset:"62236" 62236]:
 {{{
 #!CommitTicketReference repository="" revision="62236"
 Upgrade/Install: Use new default admin color scheme for links on the setup
 screen.

 This changeset updates the link colors on the setup screen and the default
 wp_die() fallback styles to use the new default admin color scheme.

 Reviewed by audrasjb, wildworks.
 Merges [62230] to the 7.0 branch.

 Props audrasjb, darshitrajyaguru97, dhrumilk, hbhalodia, huzaifaalmesbah,
 ismail0071, mikinc860, pooja-n, shailu25, sumitsingh, vishitshah,
 wildworks
 Fixes #64962.
 See #64308.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64308#comment:43>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 06:47:27 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 06:47:27 -0000
Subject: [wp-trac] [WordPress Trac] #65074: Rendering error of the
 wp_register_ability_category() doc page
In-Reply-To: <051.9cc2c3e95c512c8a3da7af5a1cb669fd@wordpress.org>
References: <051.9cc2c3e95c512c8a3da7af5a1cb669fd@wordpress.org>
Message-ID: <066.39e49cec1a805549c76b53e5ba0f5dfe@wordpress.org>

#65074: Rendering error of the wp_register_ability_category() doc page
--------------------------------+------------------------------
 Reporter:  satollo             |       Owner:  (none)
     Type:  defect (bug)        |      Status:  new
 Priority:  normal              |   Milestone:  Awaiting Review
Component:  WordPress.org Site  |     Version:  6.9.4
 Severity:  normal              |  Resolution:
 Keywords:  has-patch           |     Focuses:
--------------------------------+------------------------------

Comment (by hbhalodia):

 Hi @iamadisingh @satollo,

 This issue is not limited to just these two functions. We have many hooks
 (both actions and filters) and functions that follow a similar format for
 defining parameters and return types. For example:
 https://developer.wordpress.org/reference/hooks/post_states_html/

 We should address this at a global level rather than fixing it by updating
 or removing the `@param` comments in individual cases, as seen in this PR:
 https://github.com/WordPress/wordpress-develop/pull/11574/changes

 I also suggest updating the issue title and description to reflect a
 global issue that applies to all such functions. Since we are adopting
 PHPStan, it will require precise array notations for parameter and return
 types. Therefore, simply removing these annotations will not be a viable
 solution.

 Thanks,

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65074#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 06:59:20 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 06:59:20 -0000
Subject: [wp-trac] [WordPress Trac] #65074: Rendering error of the
 wp_register_ability_category() doc page
In-Reply-To: <051.9cc2c3e95c512c8a3da7af5a1cb669fd@wordpress.org>
References: <051.9cc2c3e95c512c8a3da7af5a1cb669fd@wordpress.org>
Message-ID: <066.d5dcf8b002f41b0a089445627b03cccb@wordpress.org>

#65074: Rendering error of the wp_register_ability_category() doc page
--------------------------------+------------------------------
 Reporter:  satollo             |       Owner:  (none)
     Type:  defect (bug)        |      Status:  new
 Priority:  normal              |   Milestone:  Awaiting Review
Component:  WordPress.org Site  |     Version:  6.9.4
 Severity:  normal              |  Resolution:
 Keywords:  has-patch           |     Focuses:
--------------------------------+------------------------------

Comment (by iamadisingh):

 Fair point, @hbhalodia. I agree that as we move toward stricter typing
 with PHPStan, the DevHub parser needs to be able to handle generic array
 notation without breaking.

 It seems the issue is likely a collision with the legacy 'hash notation'
 parser in the DevHub theme. Since this would require a fix in the wporg-
 developer repo rather than core, I'll hold off on this PR for now. From
 what I can see, the conflict is possibly originating from the formatting
 logic here: https://github.com/WordPress/wporg-developer/blob/trunk/source
 /wp-content/themes/wporg-developer-2023/inc/formatting.php#L625 (or
 wherever that specific regex is handled).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65074#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 07:09:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 07:09:23 -0000
Subject: [wp-trac] [WordPress Trac] #65074: Rendering error of the
 wp_register_ability_category() doc page
In-Reply-To: <051.9cc2c3e95c512c8a3da7af5a1cb669fd@wordpress.org>
References: <051.9cc2c3e95c512c8a3da7af5a1cb669fd@wordpress.org>
Message-ID: <066.acd404c4edd334d846a2a74436b3573b@wordpress.org>

#65074: Rendering error of the wp_register_ability_category() doc page
--------------------------------+------------------------------
 Reporter:  satollo             |       Owner:  (none)
     Type:  defect (bug)        |      Status:  new
 Priority:  normal              |   Milestone:  Awaiting Review
Component:  WordPress.org Site  |     Version:  6.9.4
 Severity:  normal              |  Resolution:
 Keywords:  has-patch           |     Focuses:
--------------------------------+------------------------------

Comment (by hbhalodia):

 Also, I guess this should be reported here -
 https://meta.trac.wordpress.org/query?status=!closed&component=Developer+Hub,
 or at here https://github.com/WordPress/wporg-developer/issues instead of
 core trac.

 > It seems the issue is likely a collision with the legacy 'hash notation'
 parser in the DevHub theme. Since this would require a fix in the wporg-
 developer repo rather than core, I'll hold off on this PR for now. From
 what I can see, the conflict is possibly originating from the formatting
 logic here: https://github.com/WordPress/wporg-developer/blob/trunk/source
 /wp-content/themes/wporg-developer-2023/inc/formatting.php#L625 (or
 wherever that specific regex is handled).


 Yes that's correct. You can create/report the issue upstream and add the
 core trac link there for reference and discussion.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65074#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 07:16:10 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 07:16:10 -0000
Subject: [wp-trac] [WordPress Trac] #64706: A single config option to
 disable all LLM related features
In-Reply-To: <057.5a6fad87789be36a76653e559056b566@wordpress.org>
References: <057.5a6fad87789be36a76653e559056b566@wordpress.org>
Message-ID: <072.4efb304ae0296650e797b6d4fa75a6e1@wordpress.org>

#64706: A single config option to disable all LLM related features
------------------------------------------------+-------------------------
 Reporter:  romainmrhenry                       |       Owner:  justlevine
     Type:  defect (bug)                        |      Status:  assigned
 Priority:  normal                              |   Milestone:  7.0
Component:  AI                                  |     Version:  trunk
 Severity:  normal                              |  Resolution:
 Keywords:  ai-client has-patch has-unit-tests  |     Focuses:
------------------------------------------------+-------------------------

Comment (by gziolo):

 Looks good to me. We need a double sign-off to land it in WP 7.0.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64706#comment:36>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 07:19:54 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 07:19:54 -0000
Subject: [wp-trac] [WordPress Trac] #65058: Abilities API: Catch
 exceptions thrown by ability callbacks
In-Reply-To: <050.65e9668d394b013d1b76006d4c82ef62@wordpress.org>
References: <050.65e9668d394b013d1b76006d4c82ef62@wordpress.org>
Message-ID: <065.a8d500e1671b8abd55f2a88b026c3971@wordpress.org>

#65058: Abilities API: Catch exceptions thrown by ability callbacks
-------------------------------------------------+-------------------------
 Reporter:  gziolo                               |       Owner:  gziolo
     Type:  defect (bug)                         |      Status:  reviewing
 Priority:  normal                               |   Milestone:  7.0
Component:  AI                                   |     Version:  6.9
 Severity:  normal                               |  Resolution:
 Keywords:  abilities-api has-patch has-unit-    |     Focuses:
  tests dev-feedback commit                      |
-------------------------------------------------+-------------------------
Changes (by gziolo):

 * keywords:  abilities-api has-patch has-unit-tests dev-feedback =>
     abilities-api has-patch has-unit-tests dev-feedback commit
 * owner:  (none) => gziolo
 * status:  new => reviewing


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65058#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 07:20:41 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 07:20:41 -0000
Subject: [wp-trac] [WordPress Trac] #65058: Abilities API: Catch
 exceptions thrown by ability callbacks
In-Reply-To: <050.65e9668d394b013d1b76006d4c82ef62@wordpress.org>
References: <050.65e9668d394b013d1b76006d4c82ef62@wordpress.org>
Message-ID: <065.9e3c2bce4d1fefbd5110c3455bfc75df@wordpress.org>

#65058: Abilities API: Catch exceptions thrown by ability callbacks
-------------------------------------------------+-------------------------
 Reporter:  gziolo                               |       Owner:  gziolo
     Type:  defect (bug)                         |      Status:  reviewing
 Priority:  normal                               |   Milestone:  7.0
Component:  AI                                   |     Version:  6.9
 Severity:  normal                               |  Resolution:
 Keywords:  abilities-api has-patch has-unit-    |     Focuses:
  tests dev-feedback commit                      |
-------------------------------------------------+-------------------------

Comment (by gziolo):

 Self-assigning for review and commi, but I'd like to get another committer
 to review this as well since we're in RC.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65058#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 07:21:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 07:21:30 -0000
Subject: [wp-trac] [WordPress Trac] #64706: A single config option to
 disable all LLM related features
In-Reply-To: <057.5a6fad87789be36a76653e559056b566@wordpress.org>
References: <057.5a6fad87789be36a76653e559056b566@wordpress.org>
Message-ID: <072.3c2efeeddb54e40f3958eafaef77f082@wordpress.org>

#64706: A single config option to disable all LLM related features
-------------------------------------------------+-------------------------
 Reporter:  romainmrhenry                        |       Owner:  justlevine
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  7.0
Component:  AI                                   |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  ai-client has-patch has-unit-tests   |     Focuses:
  commit dev-feedback                            |
-------------------------------------------------+-------------------------
Changes (by gziolo):

 * keywords:  ai-client has-patch has-unit-tests => ai-client has-patch has-
     unit-tests commit dev-feedback


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64706#comment:37>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 07:22:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 07:22:12 -0000
Subject: [wp-trac] [WordPress Trac] #65045: Duplicate 'Comment' entry in
 trashableTypes array in wp/api.js
In-Reply-To: <062.6a6382486f0ae31cacfe346576196e85@wordpress.org>
References: <062.6a6382486f0ae31cacfe346576196e85@wordpress.org>
Message-ID: <077.b6bf5b608eb90891921e92c178ea7bd5@wordpress.org>

#65045: Duplicate 'Comment' entry in trashableTypes array in wp/api.js
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  (none)
  baikare.sandeep007     |
     Type:  defect       |      Status:  new
  (bug)                  |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  REST API     |     Version:  trunk
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  javascript, rest-api, coding-
                         |  standards
-------------------------+-------------------------------------------------

Comment (by darshitrajyaguru97):

 == Patch Tested ==
 https://core.trac.wordpress.org/attachment/ticket/65045/trashable-types-
 fix.2.patch

 === **Testing Summary ===
 I tested the updated patch and can confirm that it correctly removes the
 duplicate 'Comment' entry from the `trashableTypes` array in
 `src/js/_enqueues/wp/api.js`.

 === **Steps Performed ===
 # Located the `trashableTypes` array in `wp/api.js` and verified the
 duplicate 'Comment' entry in the original code.
 # Applied the `trashable-types-fix.2.patch`.
 # Confirmed that the duplicate 'Comment' entry was removed and the array
 now contains only unique values.
 # Tested the following actions in the WordPress admin:
  # Trash comment
  # Restore comment
  # Permanently delete comment
 # Checked the browser console for JavaScript errors.

 === **Results ===
 * ✅ Duplicate entry successfully removed
 * ✅ No JavaScript errors observed
 * ✅ No regression in functionality
 * ✅ Trash-related operations for comments and other post types work as
 expected

 === **Environment ===
 * WordPress: 7.0 RC2
 * PHP: 8.3.30
 * Browser: Chrome
 * OS: Windows

 === **Conclusion ===
 The patch works as expected.

 This change improves code clarity by removing redundant data without
 affecting functionality.

 '''Recommendation:''' Patch is good to commit ✅

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65045#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 07:38:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 07:38:39 -0000
Subject: [wp-trac] [WordPress Trac] #65074: Rendering error of the
 wp_register_ability_category() doc page
In-Reply-To: <051.9cc2c3e95c512c8a3da7af5a1cb669fd@wordpress.org>
References: <051.9cc2c3e95c512c8a3da7af5a1cb669fd@wordpress.org>
Message-ID: <066.4b30ce88ab660ff0d9dc7e6690a26267@wordpress.org>

#65074: Rendering error of the wp_register_ability_category() doc page
--------------------------------+------------------------------
 Reporter:  satollo             |       Owner:  (none)
     Type:  defect (bug)        |      Status:  new
 Priority:  normal              |   Milestone:  Awaiting Review
Component:  WordPress.org Site  |     Version:  6.9.4
 Severity:  normal              |  Resolution:
 Keywords:  has-patch           |     Focuses:
--------------------------------+------------------------------

Comment (by hbhalodia):

 We have an active ticket here - https://github.com/WordPress/phpdoc-
 parser/issues/246, probably the same thing and active PR
 https://github.com/WordPress/phpdoc-parser/pull/247.

 I would just bump to the issue and PR to reflect this ticket so that it
 get's some priority.

 Thanks,

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65074#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 07:50:24 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 07:50:24 -0000
Subject: [wp-trac] [WordPress Trac] #65045: Duplicate 'Comment' entry in
 trashableTypes array in wp/api.js
In-Reply-To: <062.6a6382486f0ae31cacfe346576196e85@wordpress.org>
References: <062.6a6382486f0ae31cacfe346576196e85@wordpress.org>
Message-ID: <077.ef36aa2b9a52113ea2a241e485992700@wordpress.org>

#65045: Duplicate 'Comment' entry in trashableTypes array in wp/api.js
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  (none)
  baikare.sandeep007     |
     Type:  defect       |      Status:  new
  (bug)                  |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  REST API     |     Version:  trunk
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  javascript, rest-api, coding-
                         |  standards
-------------------------+-------------------------------------------------

Comment (by baikare.sandeep007):

 Thanks for testing @darshitrajyaguru97 @gaurangsondagar

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65045#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 08:40:00 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 08:40:00 -0000
Subject: [wp-trac] [WordPress Trac] #64837: Disable pings/trackbacks for
 local, development, and staging environments
In-Reply-To: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
References: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
Message-ID: <069.8a21977cd78a9a86d6d01d940576950f@wordpress.org>

#64837: Disable pings/trackbacks for local, development, and staging environments
--------------------------------------+-------------------------
 Reporter:  cagrimmett                |       Owner:  ramonopoly
     Type:  enhancement               |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.1
Component:  Pings/Trackbacks          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------

Comment (by arcangelini):

 Replying to [comment:16 ramonopoly]:

 > > add_filter('pre_pingback_send'
 >
 > Is there any documentation for this filter? I can't find any evidence
 for its existence. Maybe `pre_ping` was meant. Apologies in advance if
 it's documented somewhere and I've just missed it.

 I am not seeing it anywhere either. Happy to add it though if its
 something that should be here.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64837#comment:17>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 09:45:04 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 09:45:04 -0000
Subject: [wp-trac] [WordPress Trac] #65076: Missing escaping in title tag
In-Reply-To: <055.b9420f65447244d18f45902ef328903a@wordpress.org>
References: <055.b9420f65447244d18f45902ef328903a@wordpress.org>
Message-ID: <070.735d78837a0e75eb4b23f024a647dbc2@wordpress.org>

#65076: Missing escaping in title tag
------------------------------------+-------------------------------
 Reporter:  maheshpatel             |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Login and Registration  |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch               |     Focuses:  coding-standards
------------------------------------+-------------------------------

Comment (by opurockey):

 Hi, Along with the originally reported issue, I’ve also fixed a few
 additional instances in wp-login.php where strings were not properly
 escaped or were inconsistently handled. These were updated to use the
 appropriate escaping functions based on context to ensure safer and more
 consistent output.
 Let me know if you’d like me to split these into a separate PR or keep
 them as part of this fix.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65076#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 09:56:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 09:56:06 -0000
Subject: [wp-trac] [WordPress Trac] #64837: Disable pings/trackbacks for
 local, development, and staging environments
In-Reply-To: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
References: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
Message-ID: <069.f55ce2753144b692993ae86b7148a601@wordpress.org>

#64837: Disable pings/trackbacks for local, development, and staging environments
--------------------------------------+-------------------------
 Reporter:  cagrimmett                |       Owner:  ramonopoly
     Type:  enhancement               |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.1
Component:  Pings/Trackbacks          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------

Comment (by ramonopoly):

 @arcangelini  Thanks for the reply.

 Sorry, I wasn't clear. 😅 No action required, and nothing to do with
 https://github.com/WordPress/wordpress-develop/pull/11476

 I was looking at @khushipatel15's code suggestions above in this trac
 ticket and wondering where `add_filter('pre_pingback_send'` came from.

 Cheers!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64837#comment:18>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 10:00:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 10:00:23 -0000
Subject: [wp-trac] [WordPress Trac] #64837: Disable pings/trackbacks for
 local, development, and staging environments
In-Reply-To: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
References: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
Message-ID: <069.084f4d42b40b54577eedcf50adaa8abd@wordpress.org>

#64837: Disable pings/trackbacks for local, development, and staging environments
--------------------------------------+-------------------------
 Reporter:  cagrimmett                |       Owner:  ramonopoly
     Type:  enhancement               |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.1
Component:  Pings/Trackbacks          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------

Comment (by khushipatel15):

 Hello @ramonopoly , just for your information.

 pre_pingback_send is a filter hook in WordPress that runs immediately
 before a pingback request is sent to a remote site.

 Cheers! Have a good day!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64837#comment:19>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 10:02:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 10:02:31 -0000
Subject: [wp-trac] [WordPress Trac] #64982: library should be changed to
 media library in core or needs gettext
In-Reply-To: <052.6ebe4cf636d68ac01de1c591e6c35312@wordpress.org>
References: <052.6ebe4cf636d68ac01de1c591e6c35312@wordpress.org>
Message-ID: <067.716b52719558e7cc3cf1ad77d02d0c7b@wordpress.org>

#64982: library should be changed to media library in core or needs gettext
--------------------------+---------------------
 Reporter:  timse201      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  I18N          |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+---------------------

Comment (by jadavsanjay):

 == Patch Testing Report
 Patch Tested: https://github.com/WordPress/wordpress-develop/pull/11515

 === Environment
 - WordPress: 7.1-alpha-20260409.094020
 - PHP: 8.3.30
 - Server: PHP.wasm
 - Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
 - Browser: Chrome 147.0.0.0
 - OS: Windows
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None
 - Plugins:
   * Test Reports 1.2.1

 === Steps Taken
 1. Loaded PR #11515 using the WordPress PR option in Playground.
 2. Opened File browser and navigated to /wordpress/wp-admin/menu.php.
 3. Searched for _x( 'Library', 'media library' ) on line 75.
    Confirmed the patch applied correctly.

 ✅ Patch is solving the problem

 === Expected Result
 The Media Library submenu item now uses _x() with translator
 context instead of __(). No visual change expected in English.
 Translators can now provide accurate translations for their
 language once language files are updated.

 === Additional Notes
 1. Patch confirmed applied via file browser in Playground.
 2. No visual change expected. Verification is code-level only.

 === Screenshots/Screencast with results
 https://postimg.cc/Lqp429ZV
 https://postimg.cc/9zKhcm6p

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64982#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 10:17:04 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 10:17:04 -0000
Subject: [wp-trac] [WordPress Trac] #64837: Disable pings/trackbacks for
 local, development, and staging environments
In-Reply-To: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
References: <054.a5b5ed0dcebd220be1560f463377425a@wordpress.org>
Message-ID: <069.b40d6e945b91184d112aac14354cdfdd@wordpress.org>

#64837: Disable pings/trackbacks for local, development, and staging environments
--------------------------------------+-------------------------
 Reporter:  cagrimmett                |       Owner:  ramonopoly
     Type:  enhancement               |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.1
Component:  Pings/Trackbacks          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------

Comment (by ramonopoly):

 > pre_pingback_send is a filter hook in WordPress that runs immediately
 before a pingback request is sent to a remote site.


 Thank you for the quick reply! I couldn't find it in use in the code or
 across any plugins.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64837#comment:20>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 10:43:51 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 10:43:51 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.d7d0da135ab0306d406eabd7beaa51e6@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
-------------------------------------+-------------------------------------
 Reporter:  piyushpatel123           |       Owner:  audrasjb
     Type:  defect (bug)             |      Status:  accepted
 Priority:  normal                   |   Milestone:  7.0
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  needs-testing has-patch  |     Focuses:  ui, css,
  admin-reskin                       |  administration
-------------------------------------+-------------------------------------

Comment (by darshitrajyaguru97):

 == Patch Testing Report ==

 Patch Tested: https://github.com/WordPress/wordpress-develop/pull/11463

 === Environment ===
 * WordPress: 7.0-RC2
 * PHP: 8.3.30
 * Server: nginx/1.29.7
 * Database: MySQL 8.4.8
 * Browser: Chrome
 * OS: Windows
 * Theme: Twenty Twenty-Five
 * Plugins: None (including MU plugins)

 === Steps to Reproduce ===
 # Navigate to Users → Edit User
 # Click on "Set New Password"
 # Observe the alignment of the eye (visibility toggle) icon with the
 "Hide" text

 === Before Applying the Patch ===
 * The dashicon eye icon appears slightly lower than the "Hide" text,
 causing misalignment.

 === After Applying the Patch ===
 * The eye icon is properly aligned with the "Hide" text.

 === Expected Behavior ===
 * The password visibility toggle (eye icon) should be vertically aligned
 with the "Hide" text.

 === Result ===
 * ✅ Patch successfully resolves the issue.

 == Additional Notes ==
 * Issue reproducible on WordPress 7.0-RC2 prior to the patch.
 * No regressions observed after applying the patch.
 * Tested on a clean install with the default theme.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031#comment:18>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 11:02:00 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 11:02:00 -0000
Subject: [wp-trac] [WordPress Trac] #65075: Links on wp-login.php are
 not identifiable
In-Reply-To: <051.c9abb471a292e3c2a8e28bf5794e2add@wordpress.org>
References: <051.c9abb471a292e3c2a8e28bf5794e2add@wordpress.org>
Message-ID: <066.8a4653f73588a22d71d302b7eb879485@wordpress.org>

#65075: Links on wp-login.php are not identifiable
------------------------------------+------------------------------
 Reporter:  dcavins                 |       Owner:  (none)
     Type:  enhancement             |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Login and Registration  |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  2nd-opinion             |     Focuses:  accessibility
------------------------------------+------------------------------

Comment (by khushdoms):

 Hi, I’d like to work on this ticket. Removing `text-decoration: none;`
 from login.css seems reasonable for accessibility. Happy to prepare a
 patch—any feedback before I proceed?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65075#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 12:15:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 12:15:26 -0000
Subject: [wp-trac] [WordPress Trac] #42513:
 WP_Theme::get_post_templates() is extremely inefficient for large themes
In-Reply-To: <052.5fdb99c75f9c417bf5f25176784fc076@wordpress.org>
References: <052.5fdb99c75f9c417bf5f25176784fc076@wordpress.org>
Message-ID: <067.b84b06f8d2649e7c341770729752dfe6@wordpress.org>

#42513: WP_Theme::get_post_templates() is extremely inefficient for large themes
-------------------------------------------------+-------------------------
 Reporter:  gschoppe                             |       Owner:
                                                 |  SergeyBiryukov
     Type:  defect (bug)                         |      Status:  reviewing
 Priority:  normal                               |   Milestone:  7.1
Component:  Themes                               |     Version:  4.8.3
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-patch has-unit-   |     Focuses:
  tests                                          |  performance
-------------------------------------------------+-------------------------
Changes (by SergeyBiryukov):

 * owner:  (none) => SergeyBiryukov
 * status:  new => reviewing
 * milestone:  Future Release => 7.1


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/42513#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 12:18:37 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 12:18:37 -0000
Subject: [wp-trac] [WordPress Trac] #42517: get_file_data() doesn't
 support the single-line variant of post template headers
In-Reply-To: <052.48c107d421f0644307bc367df9c5df6f@wordpress.org>
References: <052.48c107d421f0644307bc367df9c5df6f@wordpress.org>
Message-ID: <067.18ef424f5244eaa606b99d47753b85fd@wordpress.org>

#42517: get_file_data() doesn't support the single-line variant of post template
headers
----------------------------------------+-----------------------------
 Reporter:  gschoppe                    |       Owner:  SergeyBiryukov
     Type:  defect (bug)                |      Status:  reviewing
 Priority:  normal                      |   Milestone:  7.1
Component:  General                     |     Version:  4.9
 Severity:  normal                      |  Resolution:
 Keywords:  has-patch needs-unit-tests  |     Focuses:
----------------------------------------+-----------------------------
Changes (by SergeyBiryukov):

 * owner:  (none) => SergeyBiryukov
 * status:  new => reviewing
 * milestone:  Awaiting Review => 7.1


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/42517#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 12:26:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 12:26:28 -0000
Subject: [wp-trac] [WordPress Trac] #64792: Consider changing code tags
 to regular text for dimension values in "Site Icon" help text
In-Reply-To: <051.b7b6985ddc2c1f63953335ef6c335c0e@wordpress.org>
References: <051.b7b6985ddc2c1f63953335ef6c335c0e@wordpress.org>
Message-ID: <066.777f359375f23c0c35e0ab7d208d28ba@wordpress.org>

#64792: Consider changing code tags to regular text for dimension values in "Site
Icon" help text
-------------------------------------------------+-------------------------
 Reporter:  juanfra                              |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  7.1
Component:  Administration                       |     Version:  6.5
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-patch commit      |     Focuses:
  has-screenshots                                |
-------------------------------------------------+-------------------------

Comment (by wpdevsxyz):

 Testing using WordPress Playground with PR #11166.

 '''Environment:'''
  * Tested via: WordPress Playground (https://playground.wordpress.net
 /?core-pr=11166)
  * WordPress: trunk (7.0)
  * PHP: 7.4.33
  * Browser: Chrome

 '''Test: Settings → General (options-general.php)'''
  1. Navigate to Settings > General
  2. Observe the Site Icon help text

 '''Result:''' ✓ PASS
 The dimension values `512 by 512` are now correctly rendered as bold
 (`<strong>`) instead of monospace code font (`<code>`). The help text
 reads cleanly: "It should be square and at least '''512 by 512''' pixels."

 Note: WordPress 7.0 default block theme does not expose the classic
 Customizer, so `class-wp-customize-manager.php` change was verified via
 code review — the pattern is identical to the confirmed working change in
 `options-general.php`.

 Overall: ✓ Issue resolved with the patch.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64792#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 12:38:36 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 12:38:36 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.d639a73c70ffd6a15401f476e8ae901d@wordpress.org>

#65015: Connectors: Several strings are not translated
-------------------------------------------------+-------------------------
 Reporter:  369work                              |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  reviewing
 Priority:  high                                 |   Milestone:  7.0
Component:  I18N                                 |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests connectors  |     Focuses:
  commit dev-feedback                            |
-------------------------------------------------+-------------------------

Comment (by manzoorwani.jk):

 Yes, you can do as suggested in that comment.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015#comment:21>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 12:43:01 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 12:43:01 -0000
Subject: [wp-trac] [WordPress Trac] #31992: Unicode Email Addresses
In-Reply-To: <051.16751f510c50d601687f280dca71804a@wordpress.org>
References: <051.16751f510c50d601687f280dca71804a@wordpress.org>
Message-ID: <066.385e307a77db227152d7e87a106f4781@wordpress.org>

#31992: Unicode Email Addresses
-------------------------------------------------+-------------------------
 Reporter:  ysalame                              |       Owner:
                                                 |  SergeyBiryukov
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  7.1
Component:  Formatting                           |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-test-info has-patch has-         |     Focuses:
  screenshots has-unit-tests dev-feedback early  |
-------------------------------------------------+-------------------------
Description changed by dmsnell:

Old description:

> Tested against trunk (2015-04-16)
>
> '''Test case'''
> {{{
> $target_email = 'dummy-üñîçøðé.y.!#$%@üñîçøðé.gmail.com';
> echo $target_email.'<br>';
> echo sanitize_email($target_email).'<br>';
> echo 'is_email : '.is_email($target_email);
> }}}
>
> '''Return'''
> {{{
> dummy-üñîçøðé.y.!#$%@üñîçøðé.gmail.com
> dummy-email.y.!#$%@gmail.com
> is_email :
> }}}
>

> Function is_email @ /wp-includes/formatting.php line 2177
> Preg_replace @ line 2211 is not correct.
> {{{
> if ( !preg_match( '/^[a-zA-Z0-9!#$%&\'*+\/=?^_`{|}~\.-]+$/', $local ) ) {
> }}}
>
> Function sanitize_email() @ /wp-includes/formatting.php line 2430
> Preg_replace @ line 2460 is not correct.
> {{{
> $local = preg_replace( '/[^a-zA-Z0-9!#$%&\'*+\/=?^_`{|}~\.-]/', '',
> $local );
> }}}
>
> == Related
>
>  - #24487 `is_email()` doesn’t recognize IDN domains.

New description:

 Tested against trunk (2015-04-16)

 '''Test case'''
 {{{
 $target_email = 'dummy-üñîçøðé.y.!#$%@üñîçøðé.gmail.com';
 echo $target_email.'<br>';
 echo sanitize_email($target_email).'<br>';
 echo 'is_email : '.is_email($target_email);
 }}}

 '''Return'''
 {{{
 dummy-üñîçøðé.y.!#$%@üñîçøðé.gmail.com
 dummy-email.y.!#$%@gmail.com
 is_email :
 }}}


 Function is_email @ /wp-includes/formatting.php line 2177
 Preg_replace @ line 2211 is not correct.
 {{{
 if ( !preg_match( '/^[a-zA-Z0-9!#$%&\'*+\/=?^_`{|}~\.-]+$/', $local ) ) {
 }}}

 Function sanitize_email() @ /wp-includes/formatting.php line 2430
 Preg_replace @ line 2460 is not correct.
 {{{
 $local = preg_replace( '/[^a-zA-Z0-9!#$%&\'*+\/=?^_`{|}~\.-]/', '', $local
 );
 }}}

 == Related

  - #4616 Previous validation expansions.
  - #9316 Introduces complex email validation with messages for rejected
 inputs.
  - #24487 `is_email()` doesn’t recognize IDN domains.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/31992#comment:88>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 13:02:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 13:02:03 -0000
Subject: [wp-trac] [WordPress Trac] #65076: Missing escaping in title tag
In-Reply-To: <055.b9420f65447244d18f45902ef328903a@wordpress.org>
References: <055.b9420f65447244d18f45902ef328903a@wordpress.org>
Message-ID: <070.255ed90a480987fdbf9fe6a8af5d06ff@wordpress.org>

#65076: Missing escaping in title tag
------------------------------------+-------------------------------
 Reporter:  maheshpatel             |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  Login and Registration  |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch               |     Focuses:  coding-standards
------------------------------------+-------------------------------

Comment (by dmsnell):

 All. Please follow the instructions in the large box with the bolded title
 **ARE YOU IN THE RIGHT PLACE?** before submitting security-related
 tickets, and [https://make.wordpress.org/core/handbook/reporting-security-
 vulnerabilities/ follow the security-reporting instructions].

 Please continue this discussion in the appropriate place according to
 those instructions. Thank you for your contributions; there is a process
 for handling security issues though, which is why those warnings are
 everywhere.

 Looking forward to getting your changes in!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65076#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 13:32:24 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 13:32:24 -0000
Subject: [wp-trac] [WordPress Trac] #65073: Connectors: reference to AI
 plugin uses old `ai` slug instead of correct `ai-wp-admin` slug
In-Reply-To: <052.ad97c034b09747ca93f06d7293e387ff@wordpress.org>
References: <052.ad97c034b09747ca93f06d7293e387ff@wordpress.org>
Message-ID: <067.5511743148949c3e9f4775ca760c7839@wordpress.org>

#65073: Connectors: reference to AI plugin uses old `ai` slug instead of correct
`ai-wp-admin` slug
------------------------------------+-----------------------
 Reporter:  JeffPaul                |       Owner:  dkotter
     Type:  defect (bug)            |      Status:  assigned
 Priority:  normal                  |   Milestone:  7.0
Component:  AI                      |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-patch connectors  |     Focuses:
------------------------------------+-----------------------

Comment (by JeffPaul):

 A fix for this has now been backported for 7.0 and will make it to core in
 the next Gutenberg sync:
 https://github.com/WordPress/gutenberg/pull/77336#issuecomment-4245449831

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65073#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 14:03:10 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 14:03:10 -0000
Subject: [wp-trac] [WordPress Trac] #65053: Media upload from the post
 edit screen shows an inaccurate number when uploading multiple media files
In-Reply-To: <053.9dbb6fc319de35dce28f39fb3ef8f2fb@wordpress.org>
References: <053.9dbb6fc319de35dce28f39fb3ef8f2fb@wordpress.org>
Message-ID: <068.e8559fd5f65881930a66be129e5d5126@wordpress.org>

#65053: Media upload from the post edit screen shows an inaccurate number when
uploading multiple media files
--------------------------+------------------------------
 Reporter:  Dharm1025     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Upload        |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  ui, javascript
--------------------------+------------------------------

Comment (by jadavsanjay):

 == Reproduction Report
 === Description
 This report validates whether the issue can be reproduced.

 === Environment
 - WordPress: 6.9.4
 - PHP: 8.3.30
 - Server: PHP.wasm
 - Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
 - Browser: Chrome 147.0.0.0
 - OS: Windows 10/11
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None activated
 - Plugins:
   * Test Reports 1.2.1

 === Actual Results
 1.  ✅ Error condition occurs (reproduced): The media library counter
 (e.g., "Showing X of Y") does not sync correctly with the actual number of
 uploaded files during the batch process..

 === Additional Notes
 - The issue specifically triggers when the media modal is opened via the
 "Set Featured Image" button in the post editor.
 The mismatch in counting persists even after the upload process is
 completed until the modal is refreshed.

 === Supplemental Artifacts
 https://postimg.cc/qNmVQspF

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65053#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 14:18:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 14:18:28 -0000
Subject: [wp-trac] [WordPress Trac] #65075: Links on wp-login.php are
 not identifiable
In-Reply-To: <051.c9abb471a292e3c2a8e28bf5794e2add@wordpress.org>
References: <051.c9abb471a292e3c2a8e28bf5794e2add@wordpress.org>
Message-ID: <066.bfd35ba83fe5cd5fbb1edfe484d280a9@wordpress.org>

#65075: Links on wp-login.php are not identifiable
-----------------------------------------+------------------------------
 Reporter:  dcavins                      |       Owner:  (none)
     Type:  enhancement                  |      Status:  new
 Priority:  normal                       |   Milestone:  Awaiting Review
Component:  Login and Registration       |     Version:
 Severity:  normal                       |  Resolution:
 Keywords:  2nd-opinion has-screenshots  |     Focuses:  accessibility
-----------------------------------------+------------------------------
Changes (by dcavins):

 * keywords:  2nd-opinion => 2nd-opinion has-screenshots


Comment:

 Thanks @audrasjb for sharing that perspective. I agree that it is not
 necessary to unthinkingly follow every suggestion a third-party
 accessibility tool (bot) comes up with. I can see it both ways in this
 case. Middle gray text does not look particularly interactive to me, but
 realize that I had familiarity with the internet before the Google
 Material interface deemphasized the cues of interactivity. So while I
 personally realize that those items are links, I can imagine that there is
 a body of users out there who don't immediately realize that they are.

 Thanks @khushdoms for the offer, and feel free to submit the patch, but
 it's probably best to hold off until a decision has been made as to
 whether this is a worthwhile change to make.

 I'll add an image showing the standard version and a customized version
 for easy comparison.

 Thanks for your feedback!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65075#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 14:19:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 14:19:53 -0000
Subject: [wp-trac] [WordPress Trac] #65075: Links on wp-login.php are
 not identifiable
In-Reply-To: <051.c9abb471a292e3c2a8e28bf5794e2add@wordpress.org>
References: <051.c9abb471a292e3c2a8e28bf5794e2add@wordpress.org>
Message-ID: <066.8deb812e5a65456a42bef37833e447fa@wordpress.org>

#65075: Links on wp-login.php are not identifiable
-----------------------------------------+------------------------------
 Reporter:  dcavins                      |       Owner:  (none)
     Type:  enhancement                  |      Status:  new
 Priority:  normal                       |   Milestone:  Awaiting Review
Component:  Login and Registration       |     Version:
 Severity:  normal                       |  Resolution:
 Keywords:  2nd-opinion has-screenshots  |     Focuses:  accessibility
-----------------------------------------+------------------------------
Changes (by dcavins):

 * Attachment "login-link-comparison.png" added.

 A pair of screenshots showing a standard login screen with undecorated
 links and a customized login screen with underlined links.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65075>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 15:07:42 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 15:07:42 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.728e17a6b617815ea4693167ecf71363@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
--------------------------------------+-------------------------------
 Reporter:  jorgefilipecosta          |       Owner:  jorgefilipecosta
     Type:  feature request           |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.0
Component:  Plugins                   |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+-------------------------------

Comment (by jorgefilipecosta):

 Hi @lukecarbis, in terms of code, nothing would block the Akismet
 connector from showing even when it is not installed. It is a product
 decision, and @matveb's messaging was clear that it should only show when
 installed, so it makes sense to follow the decision.

 My understanding of the reasons is that the other connectors are not
 bundled. Akismet is. If a user did the extra work of removing it, that
 user probably is not interested in the connector. Happy to be corrected if
 there are other reasons at play.

 Replying to [comment:50 lukecarbis]:
 > While I don't agree with including Akismet as a default option in the
 list of Connectors, since @matt has asked us to move forward with
 including it, can we please have it as a permanent option, available
 whether Akismet is installed or not. The same deal as Anthropic, ChatGPT,
 and Google – in a defaults array specified during the
 `_wp_connectors_init` function – rather than special treatment depending
 on whether it's installed or not.
 >
 > Unless, of course, we decide that showing all Installed but not Active
 connector plugins on this screen is a good way forward.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:51>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 15:46:34 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 15:46:34 -0000
Subject: [wp-trac] [WordPress Trac] #65075: Links on wp-login.php are
 not identifiable
In-Reply-To: <051.c9abb471a292e3c2a8e28bf5794e2add@wordpress.org>
References: <051.c9abb471a292e3c2a8e28bf5794e2add@wordpress.org>
Message-ID: <066.57817336c7abd0f7d1db2a1554350c4c@wordpress.org>

#65075: Links on wp-login.php are not identifiable
-----------------------------------------+------------------------------
 Reporter:  dcavins                      |       Owner:  (none)
     Type:  enhancement                  |      Status:  new
 Priority:  normal                       |   Milestone:  Awaiting Review
Component:  Login and Registration       |     Version:
 Severity:  normal                       |  Resolution:
 Keywords:  2nd-opinion has-screenshots  |     Focuses:  accessibility
-----------------------------------------+------------------------------
Changes (by khushdoms):

 * Attachment "65075.diff" added.

 This patch updates the login.css

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65075>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 15:47:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 15:47:16 -0000
Subject: [wp-trac] [WordPress Trac] #65075: Links on wp-login.php are
 not identifiable
In-Reply-To: <051.c9abb471a292e3c2a8e28bf5794e2add@wordpress.org>
References: <051.c9abb471a292e3c2a8e28bf5794e2add@wordpress.org>
Message-ID: <066.18a66e8f85a1b585d701da22eb19c02c@wordpress.org>

#65075: Links on wp-login.php are not identifiable
-----------------------------------------+------------------------------
 Reporter:  dcavins                      |       Owner:  (none)
     Type:  enhancement                  |      Status:  new
 Priority:  normal                       |   Milestone:  Awaiting Review
Component:  Login and Registration       |     Version:
 Severity:  normal                       |  Resolution:
 Keywords:  2nd-opinion has-screenshots  |     Focuses:  accessibility
-----------------------------------------+------------------------------

Comment (by khushdoms):

 Hi, I’ve attached a patch for this ticket.

 This patch updates the login.css file to improve link visibility and
 accessibility by adjusting the text-decoration property. Tested locally on
 wp-login.php and verified that links are more clearly identifiable.

 Feedback welcome.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65075#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 16:13:47 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 16:13:47 -0000
Subject: [wp-trac] [WordPress Trac] #45218: On Custom Widget Page: Title
 and Content missing when Text Widget is added to Widget area
In-Reply-To: <050.9f9f89eaf840a064bc3c1d2aa22605a9@wordpress.org>
References: <050.9f9f89eaf840a064bc3c1d2aa22605a9@wordpress.org>
Message-ID: <065.d6f321e8a5f65837d30bd194610ae949@wordpress.org>

#45218: On Custom Widget Page: Title and Content missing when Text Widget is added
to Widget area
-------------------------------+---------------------------------
 Reporter:  limvus             |       Owner:  (none)
     Type:  defect (bug)       |      Status:  closed
 Priority:  normal             |   Milestone:
Component:  Widgets            |     Version:  4.9.8
 Severity:  normal             |  Resolution:  invalid
 Keywords:  reporter-feedback  |     Focuses:  ui, administration
-------------------------------+---------------------------------
Changes (by desrosj):

 * status:  new => closed
 * resolution:   => invalid
 * milestone:  Awaiting Review =>


Comment:

 I'm going to close this out because there has been no additional
 `reporter-feedback` for some time. @limvus if you are still experiencing
 this issue, please reopen with more context.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/45218#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 16:14:20 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 16:14:20 -0000
Subject: [wp-trac] [WordPress Trac] #43804: Undefined offset: 0 in
 ../wp-includes/taxonomy.php on line 1903
In-Reply-To: <053.a1fec78b0c70a60e20aa31918f463c81@wordpress.org>
References: <053.a1fec78b0c70a60e20aa31918f463c81@wordpress.org>
Message-ID: <068.6a988f8191cc29609395ea869709faea@wordpress.org>

#43804: Undefined offset: 0 in ../wp-includes/taxonomy.php on line 1903
-----------------------------------------+----------------------
 Reporter:  vasyltech                    |       Owner:  (none)
     Type:  defect (bug)                 |      Status:  closed
 Priority:  normal                       |   Milestone:
Component:  Taxonomy                     |     Version:
 Severity:  normal                       |  Resolution:  invalid
 Keywords:  has-patch reporter-feedback  |     Focuses:
-----------------------------------------+----------------------
Changes (by desrosj):

 * status:  new => closed
 * resolution:   => invalid
 * milestone:  Awaiting Review =>


Comment:

 I'm going to close this out because there has been no additional
 `reporter-feedback` for some time. @vasyltech if you are still
 experiencing this issue, please reopen with more context.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/43804#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 16:14:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 16:14:49 -0000
Subject: [wp-trac] [WordPress Trac] #46330: Preview showing commented
 HTML
In-Reply-To: <054.109495b6383f1746d0b5e3a1d5d115d8@wordpress.org>
References: <054.109495b6383f1746d0b5e3a1d5d115d8@wordpress.org>
Message-ID: <069.bcdef894372582c8c955aa29121447f3@wordpress.org>

#46330: Preview showing commented HTML
-------------------------------+----------------------
 Reporter:  painter602         |       Owner:  (none)
     Type:  defect (bug)       |      Status:  closed
 Priority:  normal             |   Milestone:
Component:  General            |     Version:  5.1
 Severity:  normal             |  Resolution:  invalid
 Keywords:  reporter-feedback  |     Focuses:  ui
-------------------------------+----------------------
Changes (by desrosj):

 * status:  new => closed
 * resolution:   => invalid
 * milestone:  Awaiting Review =>


Comment:

 I'm going to close this out because there has been no additional
 `reporter-feedback` for some time. @painter602 if you are still
 experiencing this issue, please reopen with more context.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/46330#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 16:16:42 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 16:16:42 -0000
Subject: [wp-trac] [WordPress Trac] #38054: class.wp-scripts.php -
 add_action when init is already doing
In-Reply-To: <054.63956fef2adf360e749f858a1e2a7c5c@wordpress.org>
References: <054.63956fef2adf360e749f858a1e2a7c5c@wordpress.org>
Message-ID: <069.288bb2a1245e2bff8e834a15b519c21b@wordpress.org>

#38054: class.wp-scripts.php - add_action when init is already doing
-------------------------------+----------------------
 Reporter:  stodorovic         |       Owner:  (none)
     Type:  enhancement        |      Status:  closed
 Priority:  normal             |   Milestone:
Component:  Script Loader      |     Version:  4.6.1
 Severity:  normal             |  Resolution:  invalid
 Keywords:  reporter-feedback  |     Focuses:
-------------------------------+----------------------
Changes (by desrosj):

 * status:  new => closed
 * resolution:   => invalid
 * milestone:  Awaiting Review =>


Comment:

 I'm going to close this out because there has been no additional
 `reporter-feedback` for some time. @stodorovic if you are still
 experiencing this issue, please reopen with more context.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/38054#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 17:13:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 17:13:07 -0000
Subject: [wp-trac] [WordPress Trac] #65058: Abilities API: Catch
 exceptions thrown by ability callbacks
In-Reply-To: <050.65e9668d394b013d1b76006d4c82ef62@wordpress.org>
References: <050.65e9668d394b013d1b76006d4c82ef62@wordpress.org>
Message-ID: <065.63b384be5df7fc83f2fc926204a9cc34@wordpress.org>

#65058: Abilities API: Catch exceptions thrown by ability callbacks
-------------------------------------------------+-------------------------
 Reporter:  gziolo                               |       Owner:  gziolo
     Type:  defect (bug)                         |      Status:  reviewing
 Priority:  normal                               |   Milestone:  7.0
Component:  AI                                   |     Version:  6.9
 Severity:  normal                               |  Resolution:
 Keywords:  abilities-api has-patch has-unit-    |     Focuses:
  tests commit dev-reviewed                      |
-------------------------------------------------+-------------------------
Changes (by jorbin):

 * keywords:  abilities-api has-patch has-unit-tests dev-feedback commit =>
     abilities-api has-patch has-unit-tests commit dev-reviewed


Comment:

 https://github.com/WordPress/wordpress-develop/pull/11544 looks good to
 go. Thanks @gziolo!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65058#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 17:18:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 17:18:44 -0000
Subject: [wp-trac] [WordPress Trac] #65075: Links on wp-login.php are
 not identifiable
In-Reply-To: <051.c9abb471a292e3c2a8e28bf5794e2add@wordpress.org>
References: <051.c9abb471a292e3c2a8e28bf5794e2add@wordpress.org>
Message-ID: <066.a14a398138e42ade999db877c33f7483@wordpress.org>

#65075: Links on wp-login.php are not identifiable
-----------------------------------------+------------------------------
 Reporter:  dcavins                      |       Owner:  (none)
     Type:  enhancement                  |      Status:  new
 Priority:  normal                       |   Milestone:  Awaiting Review
Component:  Login and Registration       |     Version:
 Severity:  normal                       |  Resolution:
 Keywords:  2nd-opinion has-screenshots  |     Focuses:  accessibility
-----------------------------------------+------------------------------

Comment (by khushdoms):

 Thanks for the feedback!

 You make a good point about these links being identifiable through their
 context and placement. I agree that they behave more like navigation
 elements rather than inline text links.

 My initial thought was based on accessibility scanning tools, which
 flagged the lack of underline as a potential issue. However, considering
 real user experience, the links may still be sufficiently distinguishable.

 Perhaps a middle-ground approach could be to improve visibility on
 hover/focus states instead of enforcing underline by default.

 Happy to explore this further or prepare a patch based on the preferred
 direction.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65075#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 17:21:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 17:21:33 -0000
Subject: [wp-trac] [WordPress Trac] #64904: Real time collboration:
 determine approach for opt in setting for users in Settings > Writing
In-Reply-To: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
References: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
Message-ID: <067.f09774e1737d496a0e6edfbea02d6c2a@wordpress.org>

#64904: Real time collboration: determine approach for opt in setting for users in
Settings > Writing
------------------------------------+---------------------
 Reporter:  annezazu                |       Owner:  (none)
     Type:  task (blessed)          |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-design has-patch  |     Focuses:  ui
------------------------------------+---------------------
Changes (by desrosj):

 * keywords:  needs-design has-patch commit => needs-design has-patch


Comment:

 I'm not clear on what's left here. It looks like there are some
 suggestions above that are not yet integrated in the solution here. Mainly
 @jorbin's suggestion to include a way to force enable, not just force
 disable.

 Removing the `commit` keyword because it seems that everything that is
 "ready" has already been committed.

 It also seems that a number of people who participated on the Trac ticket
 did not receive props. Could we please make sure to props liberally,
 including anyone who attempts to positively contribute to the ticket's
 resolution.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64904#comment:32>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 18:02:08 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 18:02:08 -0000
Subject: [wp-trac] [WordPress Trac] #64904: Real time collboration:
 determine approach for opt in setting for users in Settings > Writing
In-Reply-To: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
References: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
Message-ID: <067.b8e3e93be9b66eb9d42498786ee23474@wordpress.org>

#64904: Real time collboration: determine approach for opt in setting for users in
Settings > Writing
------------------------------------+---------------------
 Reporter:  annezazu                |       Owner:  (none)
     Type:  task (blessed)          |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-design has-patch  |     Focuses:  ui
------------------------------------+---------------------

Comment (by annezazu):

 Great timing! We still have some work to do. Looping back here after a
 call this morning with @matt where he struggled to find this option to
 turn on and suggested making it more prominent/harder to miss. He
 suggested adding something like a small icon or emoji next to the setting
 to draw attention to it as a new feature, something that says "hey, look
 at this." His concern was that the setting was easy to miss while
 scrolling, and since it's a new thing in 7.0, he felt it deserved a bit of
 a highlight. This ties into prior feedback Matt has had for this release
 with shipping things but then getting the right amount of attention for
 users on the feature itself (see: WP AI Client + Connectors work and
 Command Palette in the admin bar). The one caveat raised was around emojis
 specifically, that they could have different meanings or contexts across
 languages and cultures, so that would need to be considered.

 I'll flag this for a designer so an iteration can be quickly done.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64904#comment:33>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 18:22:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 18:22:05 -0000
Subject: [wp-trac] [WordPress Trac] #31992: Unicode Email Addresses
In-Reply-To: <051.16751f510c50d601687f280dca71804a@wordpress.org>
References: <051.16751f510c50d601687f280dca71804a@wordpress.org>
Message-ID: <066.74ae6fad8a70ba29879c86f207785895@wordpress.org>

#31992: Unicode Email Addresses
-------------------------------------------------+-------------------------
 Reporter:  ysalame                              |       Owner:
                                                 |  SergeyBiryukov
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  7.1
Component:  Formatting                           |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-test-info has-patch has-         |     Focuses:
  screenshots has-unit-tests dev-feedback early  |
-------------------------------------------------+-------------------------

Comment (by amykamala):

 Some hosting tests are failing in relation to this issue, errors with
 parsing xml: https://github.com/WordPress/phpunit-test-runner/issues/310

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/31992#comment:90>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 19:28:43 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 19:28:43 -0000
Subject: [wp-trac] [WordPress Trac] #65075: Links on wp-login.php are
 not identifiable
In-Reply-To: <051.c9abb471a292e3c2a8e28bf5794e2add@wordpress.org>
References: <051.c9abb471a292e3c2a8e28bf5794e2add@wordpress.org>
Message-ID: <066.81ea4295743483f1d87ef9b4fdf01651@wordpress.org>

#65075: Links on wp-login.php are not identifiable
-----------------------------------------+------------------------------
 Reporter:  dcavins                      |       Owner:  (none)
     Type:  enhancement                  |      Status:  new
 Priority:  normal                       |   Milestone:  Awaiting Review
Component:  Login and Registration       |     Version:
 Severity:  normal                       |  Resolution:
 Keywords:  2nd-opinion has-screenshots  |     Focuses:  accessibility
-----------------------------------------+------------------------------

Comment (by joedolson):

 I'm personally in favor of underlining the links. While I agree with the
 overall sense that it is not strictly necessary, as the links operate more
 as navigation than as body content, it is still a useful cue that can help
 with understanding.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65075#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 19:40:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 19:40:48 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2357521=3A_Appearance_?=
 =?utf-8?q?-=C2=BB_Customize_not_working_after_update_5=2E8?=
In-Reply-To: <048.fd23def92566c68573ef7db5a4e8d8b4@wordpress.org>
References: <048.fd23def92566c68573ef7db5a4e8d8b4@wordpress.org>
Message-ID: <063.76c9010ec05e290ab8b1b0a846f0b680@wordpress.org>

#57521: Appearance -» Customize not working after update 5.8
-------------------------------------+------------------------------
 Reporter:  va2m                     |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Customize                |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  reporter-feedback close  |     Focuses:
-------------------------------------+------------------------------
Changes (by joedolson):

 * keywords:  reporter-feedback => reporter-feedback close


Comment:

 With no follow-up after 3 years and no other reports, I'm inclined to
 close this issue. If you have any further information, @va2m, please
 share!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/57521#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 19:43:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 19:43:44 -0000
Subject: [wp-trac] [WordPress Trac] #54202: Bad display of images with
 transparent background.
In-Reply-To: <054.2874a9ce8c2ebff7dc62fd4a4dbe68f2@wordpress.org>
References: <054.2874a9ce8c2ebff7dc62fd4a4dbe68f2@wordpress.org>
Message-ID: <069.6940caff1703a7b05cfda08be0a13439@wordpress.org>

#54202: Bad display of images with transparent background.
-------------------------------------+------------------------------
 Reporter:  michalrama               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Media                    |     Version:  5.8.1
 Severity:  minor                    |  Resolution:
 Keywords:  reporter-feedback close  |     Focuses:
-------------------------------------+------------------------------
Changes (by joedolson):

 * keywords:  reporter-feedback => reporter-feedback close


Comment:

 Without any additional environment information or the original image to
 test, this is not something we can really follow up on. If you can follow
 up with that information, @michalrama, that would be much appreciated!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/54202#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 19:46:04 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 19:46:04 -0000
Subject: [wp-trac] [WordPress Trac] #58419: Changing categories
In-Reply-To: <050.49636216137b922595ea80a119ab380a@wordpress.org>
References: <050.49636216137b922595ea80a119ab380a@wordpress.org>
Message-ID: <065.ec0173680ed8518c80edafea5801cf83@wordpress.org>

#58419: Changing categories
-------------------------------------+------------------------------
 Reporter:  jgostl                   |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Taxonomy                 |     Version:  6.2.2
 Severity:  normal                   |  Resolution:
 Keywords:  reporter-feedback close  |     Focuses:
-------------------------------------+------------------------------
Changes (by joedolson):

 * keywords:  reporter-feedback => reporter-feedback close


Comment:

 With no follow-up or clear reproduction path, this ticket should probably
 be closed. If you have any further information, @jgostl, please share!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/58419#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 19:49:52 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 19:49:52 -0000
Subject: [wp-trac] [WordPress Trac] #39891: Chrome rendering issue with
 Customizer, widgets, and checked radios
In-Reply-To: <055.e456dd42df16e14294fc11cafcda65f4@wordpress.org>
References: <055.e456dd42df16e14294fc11cafcda65f4@wordpress.org>
Message-ID: <070.bc5574a06198e24cb0377d9fb01b5cf2@wordpress.org>

#39891: Chrome rendering issue with Customizer, widgets, and checked radios
-------------------------------------+-------------------------
 Reporter:  joelworsham              |       Owner:  (none)
     Type:  defect (bug)             |      Status:  closed
 Priority:  normal                   |   Milestone:
Component:  Customize                |     Version:
 Severity:  normal                   |  Resolution:  worksforme
 Keywords:  needs-patch 2nd-opinion  |     Focuses:  ui
-------------------------------------+-------------------------
Changes (by joedolson):

 * status:  new => closed
 * resolution:   => worksforme
 * milestone:  Future Release =>


Comment:

 This doesn't appear to still be an issue as of 2026. Between the switch to
 block widgets and the changes in how custom radio selections are styled in
 the 7.0 admin reskin, I think this is no longer an issue.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/39891#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 22:16:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 22:16:12 -0000
Subject: [wp-trac] [WordPress Trac] #64817: Bump default theme versions
 for WordPress 7.0
In-Reply-To: <052.c63f6cd5170af975f4f240cb6bb1d2a1@wordpress.org>
References: <052.c63f6cd5170af975f4f240cb6bb1d2a1@wordpress.org>
Message-ID: <067.b7e3944d1c91553299c982307cb4ae12@wordpress.org>

#64817: Bump default theme versions for WordPress 7.0
----------------------------+-------------------------
 Reporter:  shailu25        |       Owner:  karmatosed
     Type:  task (blessed)  |      Status:  assigned
 Priority:  normal          |   Milestone:  7.0
Component:  Bundled Theme   |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+-------------------------
Changes (by karmatosed):

 * owner:  (none) => karmatosed
 * status:  new => assigned


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64817#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 22:23:59 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 22:23:59 -0000
Subject: [wp-trac] [WordPress Trac] #64817: Bump default theme versions
 for WordPress 7.0
In-Reply-To: <052.c63f6cd5170af975f4f240cb6bb1d2a1@wordpress.org>
References: <052.c63f6cd5170af975f4f240cb6bb1d2a1@wordpress.org>
Message-ID: <067.4a126eb32acca8dc4d531641d2739ac5@wordpress.org>

#64817: Bump default theme versions for WordPress 7.0
----------------------------+-------------------------
 Reporter:  shailu25        |       Owner:  karmatosed
     Type:  task (blessed)  |      Status:  assigned
 Priority:  normal          |   Milestone:  7.0
Component:  Bundled Theme   |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+-------------------------

Comment (by karmatosed):

 I am going to shepherd this ticket. Thank you everyone for work done so
 far. I know we need to wait for the confirmed dates and a patch refresh
 though.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64817#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 22:28:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 22:28:03 -0000
Subject: [wp-trac] [WordPress Trac] #64225: Test tool and unit test
 improvements for 7.0
In-Reply-To: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
References: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
Message-ID: <066.8fb66d309271f84bc9c595d56ca736cb@wordpress.org>

#64225: Test tool and unit test improvements for 7.0
--------------------------------------+---------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  task (blessed)            |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by SergeyBiryukov):

 In [changeset:"62237" 62237]:
 {{{
 #!CommitTicketReference repository="" revision="62237"
 Tests: Add missing `@covers` tags for some multisite tests.

 Follow-up to [62213], [62218], [62222].

 See #64225.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64225#comment:66>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 15 22:40:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 15 Apr 2026 22:40:49 -0000
Subject: [wp-trac] [WordPress Trac] #63085: "Login details" spam sent by
 from the account registration page
In-Reply-To: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
References: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
Message-ID: <066.1f8a28a3576193f7dbe9fb27db85d2bc@wordpress.org>

#63085: "Login details" spam sent by from the account registration page
-------------------------------------------------+-------------------------
 Reporter:  cweiske                              |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Login and Registration               |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests has-test-   |     Focuses:
  info                                           |
-------------------------------------------------+-------------------------

Comment (by minimoo):

 On the basis that someone signing up should know the username they've
 entered (and also know their email) - wouldn't it be easier to continue to
 allow www. in a username - but just remove the username field from the
 email.

 So the initial email just contains the link to set password.

 I'm just imagining that someone may have made their username www.yyyy.com-
 admin or similar in the past, which then would no longer be valid after
 the wordpress update?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63085#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 02:40:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 02:40:21 -0000
Subject: [wp-trac] [WordPress Trac] #65078: get_page_by_title should not be
 deprecated
Message-ID: <056.d665d726d481dfa9f969409926dd87c1@wordpress.org>

#65078: get_page_by_title should not be deprecated
-------------------------------+-----------------------------
 Reporter:  hybridwebdev       |      Owner:  (none)
     Type:  enhancement        |     Status:  new
 Priority:  normal             |  Milestone:  Awaiting Review
Component:  Posts, Post Types  |    Version:
 Severity:  normal             |   Keywords:  2nd-opinion
  Focuses:                     |
-------------------------------+-----------------------------
 This ticket is in reference to #57041.

 While the original ticket was resolved, I believe deprecating
 get_page_by_title() introduces a gap in the API that is not fully
 addressed by WP_Query.

 The key issue is not convenience, but determinism.

 get_page_by_title() performs a direct database lookup using an exact match
 on title. This approach:

 - avoids global query filters such as pre_get_posts and posts_clauses
 - guarantees more consistent results immune to external modifications
 - provides a clear and narrowly scoped intent: retrieve a page/post by
 exact title

 In contrast, using WP_Query for this purpose introduces variability. Even
 when attempting to replicate exact-match behavior, the query remains
 subject to global hooks and filters, which may alter the SQL in ways that
 are outside the caller’s control. This makes it difficult to guarantee
 equivalent behavior in plugin-heavy environments. Additionally, this can
 be subject to performance degradation when lots of logic-heavy filters are
 present. This could even result in queries where posts the user cannot
 access are returned. Which is one of the issues this commit was meant to
 resolve.

 A previous attempt to migrate this function to WP_Query was reverted due
 to unintended side effects. While that specific issue related to ordering,
 it highlights a broader concern: WP_Query is not suitable as a drop-in
 replacement for this method.

 Deprecating this function effectively requires developers to reimplement
 its logic. This leads to duplicated boilerplate and inconsistent
 implementations across codebases.

 Finally, low level methods like this serve a specific purpose. They're not
 intended to catch edge cases. That responsibility is on the code that uses
 the method.

 Given this, it may be worth reconsidering whether get_page_by_title()
 should remain as a low-level helper for exact, unfiltered lookups.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65078>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 03:52:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 03:52:18 -0000
Subject: [wp-trac] [WordPress Trac] #65078: get_page_by_title should not
 be deprecated
In-Reply-To: <056.d665d726d481dfa9f969409926dd87c1@wordpress.org>
References: <056.d665d726d481dfa9f969409926dd87c1@wordpress.org>
Message-ID: <071.504f759a5673a91c0c68870f9fd1956b@wordpress.org>

#65078: get_page_by_title should not be deprecated
-------------------------------+------------------------------
 Reporter:  hybridwebdev       |       Owner:  (none)
     Type:  enhancement        |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Posts, Post Types  |     Version:  6.2
 Severity:  normal             |  Resolution:
 Keywords:  2nd-opinion        |     Focuses:
-------------------------------+------------------------------
Changes (by sabernhardt):

 * version:   => 6.2


Old description:

> This ticket is in reference to #57041.
>
> While the original ticket was resolved, I believe deprecating
> get_page_by_title() introduces a gap in the API that is not fully
> addressed by WP_Query.
>
> The key issue is not convenience, but determinism.
>
> get_page_by_title() performs a direct database lookup using an exact
> match on title. This approach:
>
> - avoids global query filters such as pre_get_posts and posts_clauses
> - guarantees more consistent results immune to external modifications
> - provides a clear and narrowly scoped intent: retrieve a page/post by
> exact title
>
> In contrast, using WP_Query for this purpose introduces variability. Even
> when attempting to replicate exact-match behavior, the query remains
> subject to global hooks and filters, which may alter the SQL in ways that
> are outside the caller’s control. This makes it difficult to guarantee
> equivalent behavior in plugin-heavy environments. Additionally, this can
> be subject to performance degradation when lots of logic-heavy filters
> are present. This could even result in queries where posts the user
> cannot access are returned. Which is one of the issues this commit was
> meant to resolve.
>
> A previous attempt to migrate this function to WP_Query was reverted due
> to unintended side effects. While that specific issue related to
> ordering, it highlights a broader concern: WP_Query is not suitable as a
> drop-in replacement for this method.
>
> Deprecating this function effectively requires developers to reimplement
> its logic. This leads to duplicated boilerplate and inconsistent
> implementations across codebases.
>
> Finally, low level methods like this serve a specific purpose. They're
> not intended to catch edge cases. That responsibility is on the code that
> uses the method.
>
> Given this, it may be worth reconsidering whether get_page_by_title()
> should remain as a low-level helper for exact, unfiltered lookups.

New description:

 This ticket is in reference to #57041.

 While the original ticket was resolved, I believe deprecating
 `get_page_by_title()` introduces a gap in the API that is not fully
 addressed by `WP_Query`.

 The key issue is not convenience, but determinism.

 `get_page_by_title()` performs a direct database lookup using an exact
 match on title. This approach:

 - avoids global query filters such as `pre_get_posts` and `posts_clauses`
 - guarantees more consistent results immune to external modifications
 - provides a clear and narrowly scoped intent: retrieve a page/post by
 exact title

 In contrast, using `WP_Query` for this purpose introduces variability.
 Even when attempting to replicate exact-match behavior, the query remains
 subject to global hooks and filters, which may alter the SQL in ways that
 are outside the caller’s control. This makes it difficult to guarantee
 equivalent behavior in plugin-heavy environments. Additionally, this can
 be subject to performance degradation when lots of logic-heavy filters are
 present. This could even result in queries where posts the user cannot
 access are returned. Which is one of the issues this commit was meant to
 resolve.

 A previous attempt to migrate this function to `WP_Query` was reverted due
 to unintended side effects. While that specific issue related to ordering,
 it highlights a broader concern: `WP_Query` is not suitable as a drop-in
 replacement for this method.

 Deprecating this function effectively requires developers to reimplement
 its logic. This leads to duplicated boilerplate and inconsistent
 implementations across codebases.

 Finally, low level methods like this serve a specific purpose. They're not
 intended to catch edge cases. That responsibility is on the code that uses
 the method.

 Given this, it may be worth reconsidering whether `get_page_by_title()`
 should remain as a low-level helper for exact, unfiltered lookups.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65078#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 03:54:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 03:54:31 -0000
Subject: [wp-trac] [WordPress Trac] #65032: View transition admin bar
 quirks
In-Reply-To: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
References: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
Message-ID: <067.cd3e2330b433f529d208a1040956f952@wordpress.org>

#65032: View transition admin bar quirks
-------------------------------------+---------------------
 Reporter:  zieladam                 |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  7.0
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  ui
-------------------------------------+---------------------
Changes (by dhrupo):

 * keywords:  has-patch => has-patch needs-testing


Comment:

 PR opened for review: https://github.com/WordPress/wordpress-
 develop/pull/11582

 This patch gives `#adminmenuwrap` and `#adminmenuback` stable `view-
 transition-name` values in `src/wp-admin/css/view-transitions.css` so the
 admin menu is not left entirely in the root transition snapshot during
 admin navigation.

 Testing performed:
 - Reproduced on trunk in Chrome while navigating between `Dashboard ->
 Posts -> Pages`.
 - Verified locally that the patched CSS is applied.
 - Verified via Playwright/runtime inspection that `#adminmenuwrap` and
 `#adminmenuback` receive separate view-transition groups during
 navigation.

 Keywords: has-patch needs-testing

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65032#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 04:33:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 04:33:49 -0000
Subject: [wp-trac] [WordPress Trac] #65058: Abilities API: Catch
 exceptions thrown by ability callbacks
In-Reply-To: <050.65e9668d394b013d1b76006d4c82ef62@wordpress.org>
References: <050.65e9668d394b013d1b76006d4c82ef62@wordpress.org>
Message-ID: <065.a056199083440f8d302951b6cbba0eab@wordpress.org>

#65058: Abilities API: Catch exceptions thrown by ability callbacks
-------------------------------------------------+-------------------------
 Reporter:  gziolo                               |       Owner:  gziolo
     Type:  defect (bug)                         |      Status:  reviewing
 Priority:  normal                               |   Milestone:  7.0
Component:  AI                                   |     Version:  6.9
 Severity:  normal                               |  Resolution:
 Keywords:  abilities-api has-patch has-unit-    |     Focuses:
  tests commit dev-reviewed                      |
-------------------------------------------------+-------------------------

Comment (by pavanpatil1):

 **Patch Testing Report**

 Patch Tested: https://github.com/WordPress/wordpress-develop/pull/11544

 **Environment**
 Playground
 WordPress: 7.0-RC2
 PHP: 7.4.33
 Server: nginx/1.29.4
 Browser: Chrome
 OS: macOS

 **Result**:

 The patch is working fine, and no console errors appear when generating
 the title. ✅

 **Screenshot:**
 Before fix:
 https://www.awesomescreenshot.com/image/59847079?key=4dfc4a8276de7c09255c6494d9b332e3
 After fix:
 https://www.awesomescreenshot.com/image/59847180?key=b07e03ee3043738e9b1ee6a9832eca8b

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65058#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 04:41:20 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 04:41:20 -0000
Subject: [wp-trac] [WordPress Trac] #65051: $_REQUEST['term'] used
 unsanitized in user search query
In-Reply-To: <052.48e93b7172e09acbd378dc6d127d732f@wordpress.org>
References: <052.48e93b7172e09acbd378dc6d127d732f@wordpress.org>
Message-ID: <067.cc648cf8be56a574f6d8635f119d822a@wordpress.org>

#65051: $_REQUEST['term'] used unsanitized in user search query
--------------------------------+------------------------------------------
 Reporter:  rajeshcp            |       Owner:  rajeshcp
     Type:  defect (bug)        |      Status:  assigned
 Priority:  normal              |   Milestone:  7.1
Component:  Networks and Sites  |     Version:
 Severity:  normal              |  Resolution:
 Keywords:  has-patch needs-    |     Focuses:  multisite, coding-standards
  testing                       |
--------------------------------+------------------------------------------

Comment (by liaison):

 Title: Security Analysis & Vulnerability Impact

 I would like to clarify the current impact of this vulnerability. While
 the fix is essential for "Defense in Depth," a successful XSS attack is
 currently unlikely to trigger in the default WordPress UI for the
 following reasons:

 Empty Response on Malicious Payload: When a payload like
 <script>alert('XSS')</script> is injected into the term parameter, the
 backend executes a get_users query. Since no user account exists with such
 a string as a username, the database returns an empty set. The resulting
 Ajax response is an empty array [].

 Safe Client-Side Handling: The current WordPress core JavaScript that
 handles the autocomplete-user action expects a JSON array of user objects.
 When it receives [], it simply does not render any dropdown items. There
 is no "Reflected XSS" point where the raw term is echoed back into the DOM
 during a "No results found" state.

 Why the fix is still critical:

 Even though a direct "Pop-up alert" PoC is difficult to achieve in the
 current UI, this remains a valid security issue:

 Log Poisoning / Second-Order XSS: If the search term is recorded in
 server-side audit logs or slow-query logs that are later viewed in a less-
 secure admin interface, the script could execute then.

 Future-Proofing: Any future changes to the UI that might display "No
 results found for: [term]" would immediately turn this into a high-risk
 Reflected XSS.

 Data Integrity: WordPress coding standards dictate that all user input
 must be sanitized before being used in logic, especially when it reaches
 the query level.

 [Next comment]My standalone tests confirm that the patch correctly closes
 this door by stripping HTML tags at the entry point, ensuring the term is
 clean regardless of how the output is handled.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65051#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 04:41:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 04:41:48 -0000
Subject: [wp-trac] [WordPress Trac] #65051: $_REQUEST['term'] used
 unsanitized in user search query
In-Reply-To: <052.48e93b7172e09acbd378dc6d127d732f@wordpress.org>
References: <052.48e93b7172e09acbd378dc6d127d732f@wordpress.org>
Message-ID: <067.60bc01b6905bfa4d3968f5b430033bed@wordpress.org>

#65051: $_REQUEST['term'] used unsanitized in user search query
--------------------------------+------------------------------------------
 Reporter:  rajeshcp            |       Owner:  rajeshcp
     Type:  defect (bug)        |      Status:  assigned
 Priority:  normal              |   Milestone:  7.1
Component:  Networks and Sites  |     Version:
 Severity:  normal              |  Resolution:
 Keywords:  has-patch needs-    |     Focuses:  multisite, coding-standards
  testing                       |
--------------------------------+------------------------------------------
Changes (by liaison):

 * Attachment "test-65051-sanitize.png" added.

 test-65051-sanitize

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65051>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 04:53:54 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 04:53:54 -0000
Subject: [wp-trac] [WordPress Trac] #65051: $_REQUEST['term'] used
 unsanitized in user search query
In-Reply-To: <052.48e93b7172e09acbd378dc6d127d732f@wordpress.org>
References: <052.48e93b7172e09acbd378dc6d127d732f@wordpress.org>
Message-ID: <067.32d1896a8762c27d6d4e5b946dce657d@wordpress.org>

#65051: $_REQUEST['term'] used unsanitized in user search query
--------------------------------+------------------------------------------
 Reporter:  rajeshcp            |       Owner:  rajeshcp
     Type:  defect (bug)        |      Status:  assigned
 Priority:  normal              |   Milestone:  7.1
Component:  Networks and Sites  |     Version:
 Severity:  normal              |  Resolution:
 Keywords:  has-patch needs-    |     Focuses:  multisite, coding-standards
  testing                       |
--------------------------------+------------------------------------------

Comment (by liaison):

 Test Report
 Ticket: #65051 - $_REQUEST[\'term\'] used unsanitized in user search query

 Environment
 WordPress Version: 7.1-alpha (trunk)

 PHP Version: 8.x

 Test Method: Standalone Mock / Integration Test

 OS: Windows (MINGW64)

 Testing Methodology
 I performed a deep-dive verification using a standalone mock script to
 isolate the data flow within wp_ajax_autocomplete_user(). By stubbing the
 core dependencies (is_multisite, get_users, etc.), I was able to intercept
 the exact arguments being passed to the user query logic.

 Test Results
 1. Confirming the Vulnerability (Before Patch)
 Using a malicious payload: <script>alert('hack')</script>Admin
 The input was passed directly to the search argument without any
 sanitization.

 Intercepted Query: [Intercepted] get_users() called with 'search' =>
 '<script>alert(\'hack\')</script>Admin'

 Status: ❌ Confirmed. Raw HTML/Script tags reached the query level.

 2. Verification of Fix (After Patch)
 Applied sanitize_text_field( wp_unslash( ... ) ) to the $term variable.

 Intercepted Query: [Intercepted] get_users() called with 'search' =>
 '*alert(\'hack\')Admin*'

 Status: ✅ Fixed. The <script> tags were successfully stripped before
 reaching get_users().

 Execution Log Output (before patch)

 {{{
 --- Running Standalone Invocation Test ---

 --- [Demo before patch] ---
 [Intercepted] get_users() called with 'search' =>
 '<script>alert(\'hack\')</scri p
 t>Admin'
 [JSON Response]: {"success":true}

 --- [Demo after patch] ---
 [Intercepted] get_users() called with 'search' => 'alert(\'hack\')Admin'
 [JSON Response]: {"success":true}

 --- [Test Target: wp_ajax_autocomplete_user] ---
 [Intercepted] get_users() called with 'search' =>
 '*<script>alert(\'hack\')</sc ipt>Admin*'

 [wp_die] Value: []

 }}}


 Execution Log Output (after patch)

 {{{
 Plaintext
 --- Running Standalone Invocation Test ---

 --- [Demo before patch] ---
 [Intercepted] get_users() called with 'search' =>
 '<script>alert(\'hack\')</script>Admin'
 [JSON Response]: {"success":true}

 --- [Demo after patch] ---
 [Intercepted] get_users() called with 'search' => 'alert(\'hack\')Admin'
 [JSON Response]: {"success":true}

 --- [Test Target: wp_ajax_autocomplete_user] ---
 [Intercepted] get_users() called with 'search' => '*alert(\'hack\')Admin*'
 [wp_die] Value: []

 }}}

 Verdict
 The patch effectively resolves the issue by sanitizing the user-supplied
 search term. It prevents potential XSS payloads from being processed in
 the backend logic while maintaining the expected search functionality.

 test-65051-sanitize.php
 {{{#!php
 <?php
 /**
  * Standalone Test: Invoking wp_ajax_autocomplete_user directly
  */

 define( 'DOING_AJAX', true );
 define( 'WP_ADMIN', true );

 // fake $wp_db
 $GLOBALS['wpdb'] = unserialize('O:8:"stdClass":0:{}');

 // --- Stub Functions (to pass test)---
 function auth_redirect() {}
 function check_ajax_referer( $action ) { return true; }
 function current_user_can( $cap ) { return true; }

 function wp_unslash( $data ) { return stripslashes( $data ); }
 function sanitize_text_field( $str ) { return strip_tags( $str ); }

 function get_users( $args ) {
     $search_term = $args['search'] ?? '(no search term)';

     if ( '(no search term)' !== $search_term ) {
         echo "[Intercepted] get_users() called with 'search' => " .
 var_export($search_term, true) . "\n";
     }

     return array();
 }

 function wp_send_json( $response ) {
     echo "[JSON Response]: " . json_encode( $response ) . "\n";
 }

 function wp_die( $msg = '' ) {
     echo "\n[wp_die] Value: $msg\n";
 }

 if ( ! function_exists( 'is_multisite' ) ) {
     function is_multisite() {
         return true;
     }
 }

 if ( ! function_exists( 'wp_is_large_network' ) ) {
     function wp_is_large_network() {
         return false;
     }
 }

 if ( ! function_exists( 'get_current_blog_id' ) ) {
    function get_current_blog_id() {
         return 1;
     }
 }


 if ( ! function_exists( 'wp_json_encode' ) ) {
    function wp_json_encode( $data ) {
         return json_encode( $data );
     }
 }

 if ( ! function_exists( 'get_current_screen' ) ) {
     function get_current_screen() { return null; }
 }

 if ( ! function_exists( 'wp_parse_args' ) ) {
     function wp_parse_args( $args, $defaults = array() ) {
         return array_merge( $defaults, $args );
     }
 }

 // --- target source ---
 require_once 'wp-admin/includes/ajax-actions.php';

 /**
  * Simulation Demo
  */

 function wp_ajax_autocomplete_user_demo_before_patch() {
     $term = $_REQUEST['term'];

     get_users( array(
         'search' => $term,
         'fields' => array( 'ID', 'user_login' ),
     ) );

     wp_send_json( array( 'success' => true ) );
 }

 function wp_ajax_autocomplete_user_demo_after_patch() {
     $term = sanitize_text_field( wp_unslash( $_REQUEST['term'] ) );

     get_users( array(
         'search' => $term,
         'fields' => array( 'ID', 'user_login' ),
     ) );

     wp_send_json( array( 'success' => true ) );
 }


 echo "--- Running Standalone Invocation Test ---\n";

 $_REQUEST['term'] = "<script>alert('hack')</script>Admin";

 echo "\n--- [Demo before patch] ---\n";
 try {
     wp_ajax_autocomplete_user_demo_before_patch();
 } catch (Exception $e) {
     echo "Caught: " . $e->getMessage();
 }

 echo "\n--- [Demo after patch] ---\n";
 try {
     wp_ajax_autocomplete_user_demo_after_patch();
 } catch (Exception $e) {
     echo "Caught: " . $e->getMessage();
 }

 echo "\n--- [Test Target: wp_ajax_autocomplete_user] ---\n";
 try {
     wp_ajax_autocomplete_user();
 } catch (Exception $e) {
     echo "Caught: " . $e->getMessage();
 }
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65051#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 06:29:01 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 06:29:01 -0000
Subject: [wp-trac] [WordPress Trac] #65053: Media upload from the post
 edit screen shows an inaccurate number when uploading multiple media files
In-Reply-To: <053.9dbb6fc319de35dce28f39fb3ef8f2fb@wordpress.org>
References: <053.9dbb6fc319de35dce28f39fb3ef8f2fb@wordpress.org>
Message-ID: <068.546a73847c257e9b34ffcdc3927232af@wordpress.org>

#65053: Media upload from the post edit screen shows an inaccurate number when
uploading multiple media files
--------------------------+------------------------------
 Reporter:  Dharm1025     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Upload        |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  ui, javascript
--------------------------+------------------------------

Comment (by hbhalodia):

 Hi @jadavsanjay @wildworks @adamsilverstein @Dharm1025, Can you please try
 to reproduce the issue again with the patch added in the PR -
 https://github.com/WordPress/wordpress-develop/pull/11585

 I have asked help from AI (Claude Sonnet 4.6), it was pretty much good to
 find root cause and explain what was the real issue. After the fix, I
 tried replicating the issue but was not able to and also checked for
 regression but there was none.

 Thanks,

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65053#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 07:22:41 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 07:22:41 -0000
Subject: [wp-trac] [WordPress Trac] #65058: Abilities API: Catch
 exceptions thrown by ability callbacks
In-Reply-To: <050.65e9668d394b013d1b76006d4c82ef62@wordpress.org>
References: <050.65e9668d394b013d1b76006d4c82ef62@wordpress.org>
Message-ID: <065.8bf59fa9f72735bb5a95b83804527348@wordpress.org>

#65058: Abilities API: Catch exceptions thrown by ability callbacks
-------------------------------------------------+-------------------------
 Reporter:  gziolo                               |       Owner:  gziolo
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  AI                                   |     Version:  6.9
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  abilities-api has-patch has-unit-    |     Focuses:
  tests commit dev-reviewed                      |
-------------------------------------------------+-------------------------
Changes (by gziolo):

 * status:  reviewing => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62238" 62238]:
 {{{
 #!CommitTicketReference repository="" revision="62238"
 Abilities API: Catch exceptions thrown by ability callbacks and return
 WP_Error.

 Wraps `invoke_callback()` in a try/catch so that exceptions thrown by
 execute or permission callbacks are converted to a `WP_Error` with the
 `ability_callback_exception` code instead of propagating as uncaught
 throwables.

 Developed in: https://github.com/WordPress/wordpress-develop/pull/11544

 Props priyankagusani, jamesgiroux, jeffpaul, dkotter, adamsilverstein,
 justlevine, jorbin, pavanpatil1.
 Fixes #65058.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65058#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 07:28:15 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 07:28:15 -0000
Subject: [wp-trac] [WordPress Trac] #64904: Real time collboration:
 determine approach for opt in setting for users in Settings > Writing
In-Reply-To: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
References: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
Message-ID: <067.aae2d27542da7444d00f458e2bdee713@wordpress.org>

#64904: Real time collboration: determine approach for opt in setting for users in
Settings > Writing
------------------------------------+---------------------
 Reporter:  annezazu                |       Owner:  (none)
     Type:  task (blessed)          |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-design has-patch  |     Focuses:  ui
------------------------------------+---------------------

Comment (by fcoveram):

 @jameskoster shared an idea that I'm attaching here.

 It adds a "New" badge next to the field that lasts until the 7.1 or 7.2
 release (depending on how we feel the cadency) or after X number of visits
 so users don't need to wait until the next release to not see it again.
 For the later, after 10 times visiting the page sounds a reasonable period
 to me.

 What do you think?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64904#comment:34>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 07:28:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 07:28:31 -0000
Subject: [wp-trac] [WordPress Trac] #64904: Real time collboration:
 determine approach for opt in setting for users in Settings > Writing
In-Reply-To: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
References: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
Message-ID: <067.7a4380412246667e80c4b5e09e03fb27@wordpress.org>

#64904: Real time collboration: determine approach for opt in setting for users in
Settings > Writing
------------------------------------+---------------------
 Reporter:  annezazu                |       Owner:  (none)
     Type:  task (blessed)          |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-design has-patch  |     Focuses:  ui
------------------------------------+---------------------
Changes (by fcoveram):

 * Attachment "Screenshot 2026-04-15 at 21.38.10.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64904>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 07:37:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 07:37:48 -0000
Subject: [wp-trac] [WordPress Trac] #64706: A single config option to
 disable all LLM related features
In-Reply-To: <057.5a6fad87789be36a76653e559056b566@wordpress.org>
References: <057.5a6fad87789be36a76653e559056b566@wordpress.org>
Message-ID: <072.1ccf370a726eaf6e2fb95c4ac1f31ba2@wordpress.org>

#64706: A single config option to disable all LLM related features
-------------------------------------------------+-------------------------
 Reporter:  romainmrhenry                        |       Owner:  justlevine
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  AI                                   |     Version:  trunk
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  ai-client has-patch has-unit-tests   |     Focuses:
  commit dev-feedback                            |
-------------------------------------------------+-------------------------
Changes (by gziolo):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62239" 62239]:
 {{{
 #!CommitTicketReference repository="" revision="62239"
 AI: Prevent `wp_supports_ai` filter from overriding the `WP_AI_SUPPORT`
 constant.

 When `WP_AI_SUPPORT` is explicitly set to `false`, `wp_supports_ai()` now
 returns early before the filter runs. This ensures the site owner's
 explicit preference to disable AI cannot be overridden by a plugin via the
 `wp_supports_ai` filter.

 The filter default is now always `true`, since the constant check happens
 beforehand.

 Developed in: https://github.com/WordPress/wordpress-develop/pull/11295

 Follow-up to [62067].

 Props justlevine, westonruter, gziolo, mindctrl, adamsilverstein,
 johnjamesjacoby, ahortin, nilambar, ozgursar, audrasjb, jeffpaul.
 Fixes #64706.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64706#comment:40>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 08:16:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 08:16:07 -0000
Subject: [wp-trac] [WordPress Trac] #65055: _pad_term_counts() uses
 string-concatenated SQL without prepared statement
In-Reply-To: <052.bca20aa704264c411e9a5a70bff738ad@wordpress.org>
References: <052.bca20aa704264c411e9a5a70bff738ad@wordpress.org>
Message-ID: <067.26d50b4cdc268cac93954a1a36b83863@wordpress.org>

#65055: _pad_term_counts() uses string-concatenated SQL without prepared statement
--------------------------------------+------------------------------
 Reporter:  rajeshcp                  |       Owner:  rajeshcp
     Type:  defect (bug)              |      Status:  assigned
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  Database                  |     Version:  trunk
 Severity:  major                     |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+------------------------------
Changes (by liaison):

 * keywords:  has-patch => has-patch has-unit-tests


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65055#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 08:17:11 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 08:17:11 -0000
Subject: [wp-trac] [WordPress Trac] #65058: Abilities API: Catch
 exceptions thrown by ability callbacks
In-Reply-To: <050.65e9668d394b013d1b76006d4c82ef62@wordpress.org>
References: <050.65e9668d394b013d1b76006d4c82ef62@wordpress.org>
Message-ID: <065.7103f25efc97aae061feb79013238b11@wordpress.org>

#65058: Abilities API: Catch exceptions thrown by ability callbacks
-------------------------------------------------+-------------------------
 Reporter:  gziolo                               |       Owner:  gziolo
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  AI                                   |     Version:  6.9
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  abilities-api has-patch has-unit-    |     Focuses:
  tests commit dev-reviewed                      |
-------------------------------------------------+-------------------------

Comment (by gziolo):

 In [changeset:"62240" 62240]:
 {{{
 #!CommitTicketReference repository="" revision="62240"
 Abilities API: Catch exceptions thrown by ability callbacks and return
 WP_Error.

 Wraps `invoke_callback()` in a try/catch so that exceptions thrown by
 execute or permission callbacks are converted to a `WP_Error` with the
 `ability_callback_exception` code instead of propagating as uncaught
 throwables.

 Developed in: https://github.com/WordPress/wordpress-develop/pull/11544

 Reviewed by adamsilverstein, justlevine, jorbin.
 Merges [62238] to the 7.0 branch.

 Props priyankagusani, jamesgiroux, jeffpaul, dkotter, adamsilverstein,
 justlevine, jorbin, pavanpatil1.
 Fixes #65058.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65058#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 08:17:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 08:17:21 -0000
Subject: [wp-trac] [WordPress Trac] #65051: $_REQUEST['term'] used
 unsanitized in user search query
In-Reply-To: <052.48e93b7172e09acbd378dc6d127d732f@wordpress.org>
References: <052.48e93b7172e09acbd378dc6d127d732f@wordpress.org>
Message-ID: <067.efc01abdf1279d43b706cdb48743d51c@wordpress.org>

#65051: $_REQUEST['term'] used unsanitized in user search query
-------------------------------------+-------------------------------------
 Reporter:  rajeshcp                 |       Owner:  rajeshcp
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  7.1
Component:  Networks and Sites       |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  multisite, coding-
  has-test-info                      |  standards
-------------------------------------+-------------------------------------
Changes (by liaison):

 * keywords:  has-patch needs-testing => has-patch needs-testing has-test-
               info


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65051#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 08:20:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 08:20:22 -0000
Subject: [wp-trac] [WordPress Trac] #64706: A single config option to
 disable all LLM related features
In-Reply-To: <057.5a6fad87789be36a76653e559056b566@wordpress.org>
References: <057.5a6fad87789be36a76653e559056b566@wordpress.org>
Message-ID: <072.faf814642df1087c46b9872d6b1e2b86@wordpress.org>

#64706: A single config option to disable all LLM related features
-------------------------------------------------+-------------------------
 Reporter:  romainmrhenry                        |       Owner:  justlevine
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  AI                                   |     Version:  trunk
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  ai-client has-patch has-unit-tests   |     Focuses:
  commit dev-feedback                            |
-------------------------------------------------+-------------------------

Comment (by gziolo):

 In [changeset:"62241" 62241]:
 {{{
 #!CommitTicketReference repository="" revision="62241"
 AI: Prevent `wp_supports_ai` filter from overriding the `WP_AI_SUPPORT`
 constant.

 When `WP_AI_SUPPORT` is explicitly set to `false`, `wp_supports_ai()` now
 returns early before the filter runs. This ensures the site owner's
 explicit preference to disable AI cannot be overridden by a plugin via the
 `wp_supports_ai` filter.

 The filter default is now always `true`, since the constant check happens
 beforehand.

 Developed in: https://github.com/WordPress/wordpress-develop/pull/11295

 Follow-up to [62067].

 Reviewed by justlevine, westonruter, adamsilverstein.
 Merges [62239] to the 7.0 branch.

 Props justlevine, westonruter, gziolo, mindctrl, adamsilverstein,
 johnjamesjacoby, ahortin, nilambar, ozgursar, audrasjb, jeffpaul.
 Fixes #64706.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64706#comment:41>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 10:20:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 10:20:23 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.4560e15b7ff44246ff35cc0a765309e7@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
-------------------------------------+-------------------------------------
 Reporter:  piyushpatel123           |       Owner:  audrasjb
     Type:  defect (bug)             |      Status:  accepted
 Priority:  normal                   |   Milestone:  7.0
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  needs-testing has-patch  |     Focuses:  ui, css,
  admin-reskin                       |  administration
-------------------------------------+-------------------------------------

Comment (by khushdoms):

 Tested the issue on the latest trunk version (7.1) - WordPress:
 7.1-alpha-62161-src.

 Environment:
 - WordPress: trunk (7.1)
 - PHP: 8.3.30
 - Server: nginx/1.29.7
 - Database: mysqli (Server: 8.4.8 / Client: mysqlnd 8.3.30)
 - Browser: Chrome 147.0.0.0
 - OS: Windows 10/11
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None activated
 - Plugins:
   * Test Reports 1.2.1

 Steps:
 1. Navigated to Users → Edit User
 2. Clicked "Set New Password"
 3. Checked alignment of the eye icon and "Hide" text

 Result:
 The alignment issue is not reproducible in the current version. The
 dashicon appears properly aligned with the text.

 Conclusion:
 It seems the issue may already be resolved in the latest version.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031#comment:19>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 13:10:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 13:10:39 -0000
Subject: [wp-trac] [WordPress Trac] #65079:
 block_core_navigation_get_inner_blocks_from_unstable_location() calls
 deprecated function;
 deprecated   docblock references non-existent replacement
Message-ID: <057.f8aa4560602986dd5716b694facaaa72@wordpress.org>

#65079: block_core_navigation_get_inner_blocks_from_unstable_location() calls
deprecated function; deprecated   docblock references non-existent
replacement
------------------------------------+-------------------------------------
 Reporter:  saratheonline           |      Owner:  saratheonline
     Type:  defect (bug)            |     Status:  assigned
 Priority:  normal                  |  Milestone:  Awaiting Review
Component:  Editor                  |    Version:  trunk
 Severity:  normal                  |   Keywords:  has-patch needs-testing
  Focuses:  docs, coding-standards  |
------------------------------------+-------------------------------------
 There are two related issues in src/wp-includes/blocks/navigation.php that
 were introduced when
   block_core_navigation_get_inner_blocks_from_unstable_location() was
 added in 6.5.0.
   \\**Issue 1** — Function added in 6.5.0 calls a function that was
 deprecated in 6.3.0
   block_core_navigation_get_inner_blocks_from_unstable_location() (added
 @since 6.5.0) calls
   block_core_navigation_parse_blocks_from_menu_items():
 {{{
 // src/wp-includes/blocks/navigation.php
   function block_core_navigation_get_inner_blocks_from_unstable_location(
 $attributes ) {
       $menu_items = block_core_navigation_get_menu_items_at_location(
 $attributes['__unstableLocation']);
       if ( empty( $menu_items ) ) {
           return new WP_Block_List( array(), $attributes );
       }

       $menu_items_by_parent_id =
 block_core_navigation_sort_menu_items_by_parent_id( $menu_items );
       $parsed_blocks           =
 block_core_navigation_parse_blocks_from_menu_items(
   $menu_items_by_parent_id[0], $menu_items_by_parent_id ); // <-- calls
 deprecated
       return new WP_Block_List( $parsed_blocks, $attributes );
   }
 }}}
   block_core_navigation_parse_blocks_from_menu_items() was deprecated in
 6.3.0 and triggers a
   _deprecated_function() notice:
 {{{
 // src/wp-includes/blocks/navigation.php
   function block_core_navigation_parse_blocks_from_menu_items(
 $menu_items, $menu_items_by_parent_id ) {
       _deprecated_function( __FUNCTION__, '6.3.0',
 'WP_Navigation_Fallback::parse_blocks_from_menu_items');
       ...
   }
 }}}
   This means on any site using a Navigation block with the
 `__unstableLocation attribute` (classic menu location fallback), every
 page render triggers a deprecated function notice when WP_DEBUG is
 enabled.
   \\**Issue 2** — The deprecated function's docblock points to a non-
 existent replacement
   The `@deprecated` tag on
 `block_core_navigation_parse_blocks_from_menu_items()` says:
 {{{
 @deprecated 6.3.0 Use
 WP_Navigation_Fallback::parse_blocks_from_menu_items() instead.
 }}}
   However, `WP_Navigation_Fallback` (introduced in 6.3.0, src/wp-includes
 /class-wp-navigation-fallback.php) has no method named
 `parse_blocks_from_menu_items`. The equivalent logic was moved to the
 private method `WP_Classic_To_Block_Menu_Converter::to_blocks()` in the
 same release.
   \\The incorrect docblock would mislead any developer following the
 deprecation notice trying to find the correct replacement.
   \\**Issue** 3 — Missing null-coalescing fallback on the same line
   The call accesses `$menu_items_by_parent_id[0]` directly without a null
 coalesce:
 {{{
 $parsed_blocks = block_core_navigation_parse_blocks_from_menu_items(
 $menu_items_by_parent_id[0], ...);
 }}}
   Compare this with the identical pattern at (inside the already-
 deprecated `block_core_navigation_get_classic_menu_fallback_blocks()`)
 which correctly guards the access:
 {{{
 $inner_blocks = block_core_navigation_parse_blocks_from_menu_items(
       $menu_items_by_parent_id[0] ?? array(),
       $menu_items_by_parent_id
   );
 }}}
   `block_core_navigation_sort_menu_items_by_parent_id()` groups items by
 menu_item_parent. If (through data corruption or an unusual data source)
 all items carry a non-zero parent ID, the 0 key will be absent and the
 direct access generates an undefined array key notice on PHP 8.x.
   \\**Steps to Reproduce** \\1. Enable WP_DEBUG and WP_DEBUG_LOG in wp-
 config.php. \\ 2. Create a Navigation block that uses a classic menu via
 the `__unstableLocation` attribute (i.e., a theme location fallback menu).
 \\3. Load any front-end page that renders the Navigation block. \\4. Check
 the debug log — a _deprecated_function notice for
 `block_core_navigation_parse_blocks_from_menu_items` appears on every
 request. \\\\**Expected Behavior** \\ - No deprecated function notices are
 triggered. \\-
 block_core_navigation_get_inner_blocks_from_unstable_location() uses the
 non-deprecated code path. \\- The deprecated function's docblock correctly
 identifies its replacement.\\\\**Actual Behavior** `_deprecated_function(
 'block_core_navigation_parse_blocks_from_menu_items', '6.3.0',
 'WP_Navigation_Fallback::parse_blocks_from_menu_items' )` is triggered on
 every page render where the Navigation block is present with
 `__unstableLocation`.
 \\**Proposed Fix** \\Step 1. Make
 `WP_Classic_To_Block_Menu_Converter::group_by_parent_id()` and
 `::to_blocks()` public (they are currently private), or add a new public
 static method that accepts $menu_items and returns parsed blocks —
 mirroring what `block_core_navigation_parse_blocks_from_menu_items()`
 does.
 \\Step 2. Update
 `block_core_navigation_get_inner_blocks_from_unstable_location()` to call
 the new public method with the null-coalesce guard:
 {{{
 function block_core_navigation_get_inner_blocks_from_unstable_location(
 $attributes ) {
       $menu_items = block_core_navigation_get_menu_items_at_location(
 $attributes['__unstableLocation'] );
       if ( empty( $menu_items ) ) {
           return new WP_Block_List( array(), $attributes );
       }

       $menu_items_by_parent_id =
 block_core_navigation_sort_menu_items_by_parent_id( $menu_items );
       $parsed_blocks           =
 WP_Classic_To_Block_Menu_Converter::to_blocks(
           $menu_items_by_parent_id[0] ?? array(),
           $menu_items_by_parent_id
       );
       return new WP_Block_List( $parsed_blocks, $attributes );
   }
 }}}
 \\Step 3. Correct the @deprecated docblock on
 `block_core_navigation_parse_blocks_from_menu_items()` to reference the
 actual replacement:
 {{{
 - * @deprecated 6.3.0 Use
 `WP_Navigation_Fallback::parse_blocks_from_menu_items()` instead.
 + * @deprecated 6.3.0 Use
 `WP_Classic_To_Block_Menu_Converter::to_blocks()` instead.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65079>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 13:13:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 13:13:05 -0000
Subject: [wp-trac] [WordPress Trac] #65079:
 block_core_navigation_get_inner_blocks_from_unstable_location() calls
 deprecated function;
 deprecated   docblock references non-existent replacement
In-Reply-To: <057.f8aa4560602986dd5716b694facaaa72@wordpress.org>
References: <057.f8aa4560602986dd5716b694facaaa72@wordpress.org>
Message-ID: <072.9907ff928d6b49989d4dce2b84e656d0@wordpress.org>

#65079: block_core_navigation_get_inner_blocks_from_unstable_location() calls
deprecated function; deprecated   docblock references non-existent
replacement
-------------------------------------+-------------------------------------
 Reporter:  saratheonline            |       Owner:  saratheonline
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Editor                   |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  docs, coding-standards
-------------------------------------+-------------------------------------
Changes (by saratheonline):

 * Attachment "navigation-deprecated-fix.patch" added.

 Patch attached. Changes are limited to 2 files and 5 lines. No new logic,
 just redirecting the call to the already-existing
 WP_Classic_To_Block_Menu_Converter::to_blocks() (made public) and
 correcting the @deprecated docblock to point to the actual replacement.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65079>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 13:19:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 13:19:49 -0000
Subject: [wp-trac] [WordPress Trac] #65080:
 wp_admin_bar_add_color_scheme_to_front_end()` uses `wp_remote_get()` to
 fetch a local CSS file,
 causing an unnecessary HTTP request on every front-end page load
Message-ID: <052.f60f4feb69ae8a93bdae3bd3421ea66f@wordpress.org>

#65080: wp_admin_bar_add_color_scheme_to_front_end()` uses `wp_remote_get()` to
fetch a local CSS file, causing an unnecessary HTTP request on every front-
end page load
--------------------------+-----------------------------
 Reporter:  edumembe      |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  HTTP API      |    Version:  trunk
 Severity:  normal        |   Keywords:  needs-patch
  Focuses:  performance   |
--------------------------+-----------------------------
 **Description:**

 The function introduced in 7.0.0 (`wp-includes/admin-bar.php`) fetches the
 admin color scheme stylesheet via `wp_remote_get( $url )`, where `$url`
 points to a local file such as `/wp-
 admin/css/colors/modern/colors.min.css`.

 This results in a full HTTP round-trip to the server itself on every
 front-end page load when the admin bar is visible. On our test
 environment, this request consistently takes ~30ms, accounting for the
 majority of the performance difference between WordPress 6.9 and 7.0.

 **Steps to reproduce:**
 1. Install WordPress 7.0 with any classic theme.
 2. Log in as an administrator and visit the front end.
 3. Open Query Monitor → HTTP API Calls.
 4. Observe a GET request to `/wp-admin/css/colors/modern/colors.min.css`
 taking 20–50ms.

 **Expected behavior:**
 The CSS content should be read directly from the filesystem using
 `file_get_contents()` or `WP_Filesystem`, avoiding the HTTP overhead
 entirely. The file path is already resolvable locally via `ABSPATH`.

 **Suggested fix:**
 Replace `wp_remote_get( $url )` with a direct filesystem read:

 ```php
 $css_file = ABSPATH . 'wp-admin/css/colors/' . $color_scheme .
 '/colors.min.css';
 if ( ! file_exists( $css_file ) ) {
     return;
 }
 $css = file_get_contents( $css_file );
 ```

 This eliminates the HTTP request while producing identical output.

 **Environment:**
 - WordPress 7.0
 - Classic (non-block) theme
 - Admin bar enabled on front end
 - PHP 8.x, OPcache enabled

 **Impact:** Performance regression on every front-end page load for
 logged-in users. The HTTP request is blocking and adds 20–50ms of latency
 unconditionally.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65080>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 13:33:15 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 13:33:15 -0000
Subject: [wp-trac] [WordPress Trac] #65080:
 wp_admin_bar_add_color_scheme_to_front_end()` uses `wp_remote_get()` to
 fetch a local CSS file,
 causing an unnecessary HTTP request on every front-end page load
In-Reply-To: <052.f60f4feb69ae8a93bdae3bd3421ea66f@wordpress.org>
References: <052.f60f4feb69ae8a93bdae3bd3421ea66f@wordpress.org>
Message-ID: <067.f0e90ecba150443899d61fcf71240ca7@wordpress.org>

#65080: wp_admin_bar_add_color_scheme_to_front_end()` uses `wp_remote_get()` to
fetch a local CSS file, causing an unnecessary HTTP request on every front-
end page load
--------------------------+------------------------------
 Reporter:  edumembe      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  HTTP API      |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:  performance
--------------------------+------------------------------

Comment (by anupkankale):

 I'm working on a patch for this. Will submit a PR shortly.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65080#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 13:40:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 13:40:29 -0000
Subject: [wp-trac] [WordPress Trac] #65080:
 wp_admin_bar_add_color_scheme_to_front_end()` uses `wp_remote_get()` to
 fetch a local CSS file,
 causing an unnecessary HTTP request on every front-end page load
In-Reply-To: <052.f60f4feb69ae8a93bdae3bd3421ea66f@wordpress.org>
References: <052.f60f4feb69ae8a93bdae3bd3421ea66f@wordpress.org>
Message-ID: <067.3f161f8991c78ad711a3fc8e11610f11@wordpress.org>

#65080: wp_admin_bar_add_color_scheme_to_front_end()` uses `wp_remote_get()` to
fetch a local CSS file, causing an unnecessary HTTP request on every front-
end page load
--------------------------+--------------------------
 Reporter:  edumembe      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  HTTP API      |     Version:  trunk
 Severity:  normal        |  Resolution:  duplicate
 Keywords:  needs-patch   |     Focuses:  performance
--------------------------+--------------------------
Changes (by wildworks):

 * status:  new => closed
 * resolution:   => duplicate
 * milestone:  Awaiting Review =>


Comment:

 Duplicate of #64762.

 Thanks for the report. This is a known issue, and it appears a fix is in
 progress.

 See:

 - https://core.trac.wordpress.org/ticket/64762#comment:28
 - https://github.com/WordPress/wordpress-develop/pull/11255

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65080#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 13:44:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 13:44:14 -0000
Subject: [wp-trac] [WordPress Trac] #65079:
 block_core_navigation_get_inner_blocks_from_unstable_location() calls
 deprecated function;
 deprecated   docblock references non-existent replacement
In-Reply-To: <057.f8aa4560602986dd5716b694facaaa72@wordpress.org>
References: <057.f8aa4560602986dd5716b694facaaa72@wordpress.org>
Message-ID: <072.ee5879d7a2fd9ecb3f099f8abc72c330@wordpress.org>

#65079: block_core_navigation_get_inner_blocks_from_unstable_location() calls
deprecated function; deprecated   docblock references non-existent
replacement
-------------------------------------+-------------------------------------
 Reporter:  saratheonline            |       Owner:  saratheonline
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Editor                   |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  docs, coding-standards
-------------------------------------+-------------------------------------

Comment (by wildworks):

 @saratheonline Thanks for submitting a patch.

 The `navigation.php` file cannot be directly edited in the WordPress core.
 This file is synced from the Gutenberg repository.

 See:
 https://github.com/WordPress/gutenberg/blob/7563e2acf2a8bcfbe6338ca4bd5cc0d7eed74535/packages
 /block-library/src/navigation/index.php#L1601

 Would it be possible for you to submit a new PR to
 [https://github.com/WordPress/gutenberg the Gutenberg repository]?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65079#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 13:52:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 13:52:07 -0000
Subject: [wp-trac] [WordPress Trac] #65080:
 wp_admin_bar_add_color_scheme_to_front_end()` uses `wp_remote_get()` to
 fetch a local CSS file,
 causing an unnecessary HTTP request on every front-end page load
In-Reply-To: <052.f60f4feb69ae8a93bdae3bd3421ea66f@wordpress.org>
References: <052.f60f4feb69ae8a93bdae3bd3421ea66f@wordpress.org>
Message-ID: <067.71d6de674662934cd66ce756b414eb8b@wordpress.org>

#65080: wp_admin_bar_add_color_scheme_to_front_end()` uses `wp_remote_get()` to
fetch a local CSS file, causing an unnecessary HTTP request on every front-
end page load
--------------------------+--------------------------
 Reporter:  edumembe      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  Toolbar       |     Version:  trunk
 Severity:  normal        |  Resolution:  duplicate
 Keywords:                |     Focuses:  performance
--------------------------+--------------------------
Changes (by sabernhardt):

 * keywords:  needs-patch =>
 * component:  HTTP API => Toolbar


Old description:

> **Description:**
>
> The function introduced in 7.0.0 (`wp-includes/admin-bar.php`) fetches
> the admin color scheme stylesheet via `wp_remote_get( $url )`, where
> `$url` points to a local file such as `/wp-
> admin/css/colors/modern/colors.min.css`.
>
> This results in a full HTTP round-trip to the server itself on every
> front-end page load when the admin bar is visible. On our test
> environment, this request consistently takes ~30ms, accounting for the
> majority of the performance difference between WordPress 6.9 and 7.0.
>
> **Steps to reproduce:**
> 1. Install WordPress 7.0 with any classic theme.
> 2. Log in as an administrator and visit the front end.
> 3. Open Query Monitor → HTTP API Calls.
> 4. Observe a GET request to `/wp-admin/css/colors/modern/colors.min.css`
> taking 20–50ms.
>
> **Expected behavior:**
> The CSS content should be read directly from the filesystem using
> `file_get_contents()` or `WP_Filesystem`, avoiding the HTTP overhead
> entirely. The file path is already resolvable locally via `ABSPATH`.
>
> **Suggested fix:**
> Replace `wp_remote_get( $url )` with a direct filesystem read:
>
> ```php
> $css_file = ABSPATH . 'wp-admin/css/colors/' . $color_scheme .
> '/colors.min.css';
> if ( ! file_exists( $css_file ) ) {
>     return;
> }
> $css = file_get_contents( $css_file );
> ```
>
> This eliminates the HTTP request while producing identical output.
>
> **Environment:**
> - WordPress 7.0
> - Classic (non-block) theme
> - Admin bar enabled on front end
> - PHP 8.x, OPcache enabled
>
> **Impact:** Performance regression on every front-end page load for
> logged-in users. The HTTP request is blocking and adds 20–50ms of latency
> unconditionally.

New description:

 The function introduced in 7.0.0 (`wp-includes/admin-bar.php`) fetches the
 admin color scheme stylesheet via `wp_remote_get( $url )`, where `$url`
 points to a local file such as `/wp-
 admin/css/colors/modern/colors.min.css`.

 This results in a full HTTP round-trip to the server itself on every
 front-end page load when the admin bar is visible. On our test
 environment, this request consistently takes ~30ms, accounting for the
 majority of the performance difference between WordPress 6.9 and 7.0.

 **Steps to reproduce:**
 1. Install WordPress 7.0 with any classic theme.
 2. Log in as an administrator and visit the front end.
 3. Open Query Monitor → HTTP API Calls.
 4. Observe a GET request to `/wp-admin/css/colors/modern/colors.min.css`
 taking 20–50ms.

 **Expected behavior:**
 The CSS content should be read directly from the filesystem using
 `file_get_contents()` or `WP_Filesystem`, avoiding the HTTP overhead
 entirely. The file path is already resolvable locally via `ABSPATH`.

 **Suggested fix:**
 Replace `wp_remote_get( $url )` with a direct filesystem read:

 {{{#!php
 $css_file = ABSPATH . 'wp-admin/css/colors/' . $color_scheme .
 '/colors.min.css';
 if ( ! file_exists( $css_file ) ) {
     return;
 }
 $css = file_get_contents( $css_file );
 }}}

 This eliminates the HTTP request while producing identical output.

 **Environment:**
 - WordPress 7.0
 - Classic (non-block) theme
 - Admin bar enabled on front end
 - PHP 8.x, OPcache enabled

 **Impact:**
 Performance regression on every front-end page load for logged-in users.
 The HTTP request is blocking and adds 20–50ms of latency unconditionally.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65080#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 15:12:42 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 15:12:42 -0000
Subject: [wp-trac] [WordPress Trac] #65064: Flaky test:
 test_get_theme_featured_list_api fails with external HTTP unavailability
In-Reply-To: <055.dca23389f0fdd68291955432ac6fc1d5@wordpress.org>
References: <055.dca23389f0fdd68291955432ac6fc1d5@wordpress.org>
Message-ID: <070.f565f8dccb655900afd997392a890484@wordpress.org>

#65064: Flaky test: test_get_theme_featured_list_api fails with external HTTP
unavailability
-------------------------------------------------+-------------------------
 Reporter:  rakeshfalke                          |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Build/Test Tools                     |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-test-info has-patch has-unit-    |     Focuses:  tests
  tests                                          |
-------------------------------------------------+-------------------------

Comment (by SergeyBiryukov):

 Hi there, thanks for the ticket!

 Just noting that this previously came up in comment:18:ticket:54420.

 The test was added in [39906] / #28121 to make sure that the list of theme
 features pulled from the WordPress.org API returns the expected data
 structure. It seems that mocking this response might defeat the purpose of
 the test, as it was specifically written to protect from unexpected
 changes in the WordPress.org API response.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65064#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 15:20:41 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 15:20:41 -0000
Subject: [wp-trac] [WordPress Trac] #63085: "Login details" spam sent by
 from the account registration page
In-Reply-To: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
References: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
Message-ID: <066.e013e5cd344c9fdb8dc2938dd92edab7@wordpress.org>

#63085: "Login details" spam sent by from the account registration page
-------------------------------------------------+-------------------------
 Reporter:  cweiske                              |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Login and Registration               |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests has-test-   |     Focuses:
  info                                           |
-------------------------------------------------+-------------------------

Comment (by SergeyBiryukov):

 Hi there, thanks for the ticket!

 Replying to [comment:12 minimoo]:
 > I'm just imagining that someone may have made their username www.yyyy
 .com-admin or similar in the past, which then would no longer be valid
 after the wordpress update?

 Indeed, we should be careful here, as both `www.` and spaces have been
 historically allowed in usernames.

 Related: #59084

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63085#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 15:26:46 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 15:26:46 -0000
Subject: [wp-trac] [WordPress Trac] #64536: About Page - 7.0
In-Reply-To: <051.70759fa0a8836490f78fb36a7530ec61@wordpress.org>
References: <051.70759fa0a8836490f78fb36a7530ec61@wordpress.org>
Message-ID: <066.6856028edf50fb41021c2f89efb45aab@wordpress.org>

#64536: About Page - 7.0
----------------------------+---------------------
 Reporter:  desrosj         |       Owner:  (none)
     Type:  task (blessed)  |      Status:  new
 Priority:  normal          |   Milestone:  7.0
Component:  Help/About      |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:
----------------------------+---------------------

Comment (by Benjamin_Zekavica):

 @fcoveram That looks much better. I'd take the last version:
 https://cleanshot.com/share/lM1WYSj6

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64536#comment:31>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 16:40:38 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 16:40:38 -0000
Subject: [wp-trac] [WordPress Trac] #55535: Pre-populate Image Alt Text
 field with IPTC Photo Metadata Standard Alt Text
In-Reply-To: <055.78e28d901417e4e4869061ec37a14758@wordpress.org>
References: <055.78e28d901417e4e4869061ec37a14758@wordpress.org>
Message-ID: <070.66b7d3ed712f9e58e6b9327372cceb0c@wordpress.org>

#55535: Pre-populate Image Alt Text field with IPTC Photo Metadata Standard Alt
Text
-------------------------------------+----------------------------
 Reporter:  eatingrules              |       Owner:  rcreators
     Type:  enhancement              |      Status:  closed
 Priority:  normal                   |   Milestone:  7.0
Component:  Media                    |     Version:
 Severity:  critical                 |  Resolution:  fixed
 Keywords:  needs-patch 2nd-opinion  |     Focuses:  accessibility
-------------------------------------+----------------------------

Comment (by Jesterman):

 Thanks @adamsilverstein, @jhmonroe and @joedolson . I can't wait to test
 it out on our magazine when it releases!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/55535#comment:62>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 16:53:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 16:53:48 -0000
Subject: [wp-trac] [WordPress Trac] #65005: Next/Previous for datepicker
 needs context
In-Reply-To: <052.e7c5ffd7379c8e33f54d240e729da31e@wordpress.org>
References: <052.e7c5ffd7379c8e33f54d240e729da31e@wordpress.org>
Message-ID: <067.fb9357acb8303c65e32bfaecf17b305b@wordpress.org>

#65005: Next/Previous for datepicker needs context
-------------------------------------------------+-------------------------
 Reporter:  timse201                             |       Owner:
                                                 |  SergeyBiryukov
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  I18N                                 |     Version:
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch commit dev-reviewed i18n-  |     Focuses:
  change                                         |
-------------------------------------------------+-------------------------
Changes (by jorbin):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62242" 62242]:
 {{{
 #!CommitTicketReference repository="" revision="62242"
 I18N: Add context for Next/Previous strings in the jQuery UI datepicker.

 Follow-up to [37849].

 Reviewed by jorbin, audrasjb.
 Merges [62188] to the 7.0 branch.

 Props timse201, anupkankale, sergeyBiryukov.
 Fixes #65005.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65005#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 17:40:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 17:40:53 -0000
Subject: [wp-trac] [WordPress Trac] #63085: "Login details" spam sent by
 from the account registration page
In-Reply-To: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
References: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
Message-ID: <066.ad4062bd7d6ab863126f1eb4c7c493e7@wordpress.org>

#63085: "Login details" spam sent by from the account registration page
-------------------------------------------------+-------------------------
 Reporter:  cweiske                              |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Login and Registration               |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests has-test-   |     Focuses:
  info                                           |
-------------------------------------------------+-------------------------

Comment (by cweiske):

 > I'm just imagining that someone may have made their username www.yyyy
 .com-admin or similar in the past, which then would no longer be valid
 after the wordpress update?

 The username validation only affects user registration, not user login. I
 just verified this.

 Existing users with usernames "www.example.org" or "admin of
 www.example.org" can continue to log in.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63085#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 18:25:45 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 18:25:45 -0000
Subject: [wp-trac] =?utf-8?q?=5BWordPress_Trac=5D_=2365081=3A_AI_Plugin_?=
 =?utf-8?q?=E2=80=9CControl_features=E2=80=9D_button_redirects_to_unauthor?=
 =?utf-8?q?ized_access_page?=
Message-ID: <052.aaaccb49e643aa53b0d741148cf10315@wordpress.org>

#65081: AI Plugin “Control features” button redirects to unauthorized access page
----------------------------+-------------------------------------------
 Reporter:  codex007        |      Owner:  (none)
     Type:  defect (bug)    |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Administration  |    Version:  trunk
 Severity:  normal          |   Keywords:  needs-testing has-screenshots
  Focuses:  ui, javascript  |
----------------------------+-------------------------------------------
 While using the AI plugin in the WordPress admin panel, clicking the
 “Control features in the AI plugin” button on the connector screen
 redirects to a page that shows:

 {{{
 Sorry, you are not allowed to access this page.
 }}}

 However, accessing the correct admin page directly works without any
 issue.

 == Steps to Reproduce ==
         1.      Navigate to Settings → Connectors
         2.      Click on “Control features in the AI plugin”
         3.      Install and activate the AI plugin (if not already
 installed)
         4.      After installation, the button becomes visible
         5.      Click the button → it redirects to:
 /wp-admin/options-general.php?page=ai
         6.      The following error appears:
 {{{
 Sorry, you are not allowed to access this page.
 }}}

 == Expected Results ==
 The button should redirect to:
 /wp-admin/options-general.php?page=ai-wp-admin
 where the user has proper access.

 == Actual Results ==
 The button redirects to:
 /wp-admin/options-general.php?page=ai
 which results in an unauthorized access error.

 == Environment ==
         •       WordPress Version: 7.0
         •       Environment: Localhost
         •       Plugin: AI Plugin (default WP AI feature)
         •       User Role: Administrator

 == Additional Notes ==
         •       Direct access to ai-wp-admin works correctly
         •       Issue likely caused by incorrect menu slug or capability
 mismatch in the button URL
         •       Possibly needs update in plugin routing or admin menu
 registration

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65081>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 18:27:46 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 18:27:46 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2365081=3A_AI_Plugin_?=
 =?utf-8?q?=E2=80=9CControl_features=E2=80=9D_button_redirects_to_unauthor?=
 =?utf-8?q?ized_access_page?=
In-Reply-To: <052.aaaccb49e643aa53b0d741148cf10315@wordpress.org>
References: <052.aaaccb49e643aa53b0d741148cf10315@wordpress.org>
Message-ID: <067.3c21367b5ed79214ceaf74006d3d6a0e@wordpress.org>

#65081: AI Plugin “Control features” button redirects to unauthorized access page
-------------------------------------------+------------------------------
 Reporter:  codex007                       |       Owner:  (none)
     Type:  defect (bug)                   |      Status:  new
 Priority:  normal                         |   Milestone:  Awaiting Review
Component:  Administration                 |     Version:  trunk
 Severity:  normal                         |  Resolution:
 Keywords:  needs-testing has-screenshots  |     Focuses:  ui, javascript
-------------------------------------------+------------------------------
Changes (by codex007):

 * Attachment "Screenshot at Apr 16 23-56-27.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65081>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 18:28:02 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 18:28:02 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2365081=3A_AI_Plugin_?=
 =?utf-8?q?=E2=80=9CControl_features=E2=80=9D_button_redirects_to_unauthor?=
 =?utf-8?q?ized_access_page?=
In-Reply-To: <052.aaaccb49e643aa53b0d741148cf10315@wordpress.org>
References: <052.aaaccb49e643aa53b0d741148cf10315@wordpress.org>
Message-ID: <067.b88851fb6b76b22ed107046570a8aa5a@wordpress.org>

#65081: AI Plugin “Control features” button redirects to unauthorized access page
-------------------------------------------+------------------------------
 Reporter:  codex007                       |       Owner:  (none)
     Type:  defect (bug)                   |      Status:  new
 Priority:  normal                         |   Milestone:  Awaiting Review
Component:  Administration                 |     Version:  trunk
 Severity:  normal                         |  Resolution:
 Keywords:  needs-testing has-screenshots  |     Focuses:  ui, javascript
-------------------------------------------+------------------------------
Changes (by codex007):

 * Attachment "Screenshot at Apr 16 23-56-52.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65081>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 18:28:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 18:28:13 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2365081=3A_AI_Plugin_?=
 =?utf-8?q?=E2=80=9CControl_features=E2=80=9D_button_redirects_to_unauthor?=
 =?utf-8?q?ized_access_page?=
In-Reply-To: <052.aaaccb49e643aa53b0d741148cf10315@wordpress.org>
References: <052.aaaccb49e643aa53b0d741148cf10315@wordpress.org>
Message-ID: <067.cce74bbaba6f345110a9e1075e0c22f5@wordpress.org>

#65081: AI Plugin “Control features” button redirects to unauthorized access page
-------------------------------------------+------------------------------
 Reporter:  codex007                       |       Owner:  (none)
     Type:  defect (bug)                   |      Status:  new
 Priority:  normal                         |   Milestone:  Awaiting Review
Component:  Administration                 |     Version:  trunk
 Severity:  normal                         |  Resolution:
 Keywords:  needs-testing has-screenshots  |     Focuses:  ui, javascript
-------------------------------------------+------------------------------
Changes (by codex007):

 * Attachment "Screenshot at Apr 16 23-56-12.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65081>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 18:41:27 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 18:41:27 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2365081=3A_AI_Plugin_?=
 =?utf-8?q?=E2=80=9CControl_features=E2=80=9D_button_redirects_to_unauthor?=
 =?utf-8?q?ized_access_page?=
In-Reply-To: <052.aaaccb49e643aa53b0d741148cf10315@wordpress.org>
References: <052.aaaccb49e643aa53b0d741148cf10315@wordpress.org>
Message-ID: <067.e3bb8a88816200f9f6c1cab462b5602e@wordpress.org>

#65081: AI Plugin “Control features” button redirects to unauthorized access page
-------------------------------------------+-----------------------------
 Reporter:  codex007                       |       Owner:  (none)
     Type:  defect (bug)                   |      Status:  closed
 Priority:  normal                         |   Milestone:
Component:  Administration                 |     Version:  trunk
 Severity:  normal                         |  Resolution:  duplicate
 Keywords:  needs-testing has-screenshots  |     Focuses:  ui, javascript
-------------------------------------------+-----------------------------
Changes (by JeffPaul):

 * status:  new => closed
 * resolution:   => duplicate
 * milestone:  Awaiting Review =>


Comment:

 Duplicate of #65073.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65081#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 18:43:10 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 18:43:10 -0000
Subject: [wp-trac] [WordPress Trac] #64225: Test tool and unit test
 improvements for 7.0
In-Reply-To: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
References: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
Message-ID: <066.4541e4c09e6b20d5f07ec43144f7b673@wordpress.org>

#64225: Test tool and unit test improvements for 7.0
--------------------------------------+---------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  task (blessed)            |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by SergeyBiryukov):

 In [changeset:"62243" 62243]:
 {{{
 #!CommitTicketReference repository="" revision="62243"
 Tests: Remove `external-http` group from a `get_theme_feature_list()`
 test.

 This particular test checks the list of theme features hardcoded into Core
 and does not perform an external API request.

 Follow-up to [39906].

 See #64225.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64225#comment:67>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 19:16:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 19:16:14 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2365081=3A_AI_Plugin_?=
 =?utf-8?q?=E2=80=9CControl_features=E2=80=9D_button_redirects_to_unauthor?=
 =?utf-8?q?ized_access_page?=
In-Reply-To: <052.aaaccb49e643aa53b0d741148cf10315@wordpress.org>
References: <052.aaaccb49e643aa53b0d741148cf10315@wordpress.org>
Message-ID: <067.fc69bb9a94c89a4682c875817c1eecec@wordpress.org>

#65081: AI Plugin “Control features” button redirects to unauthorized access page
-------------------------------------------+-----------------------------
 Reporter:  codex007                       |       Owner:  (none)
     Type:  defect (bug)                   |      Status:  closed
 Priority:  normal                         |   Milestone:
Component:  Administration                 |     Version:  trunk
 Severity:  normal                         |  Resolution:  duplicate
 Keywords:  needs-testing has-screenshots  |     Focuses:  ui, javascript
-------------------------------------------+-----------------------------

Comment (by codex007):

 It appears to be an actual bug where the button leads to an unauthorized
 access page.
 Thanks

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65081#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 20:18:25 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 20:18:25 -0000
Subject: [wp-trac] [WordPress Trac] #65082: WP_oEmbed()->fetch() uses
 wp_embed_defaults() incorrectly
Message-ID: <056.2745434284ff37225e3651b3b0f0f4cc@wordpress.org>

#65082: WP_oEmbed()->fetch() uses wp_embed_defaults() incorrectly
--------------------------+-----------------------------
 Reporter:  sanchothefat  |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Embeds        |    Version:
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 In the `fetch()` method of `WP_oEmbed()` it's expecting an array with
 `width` and `height` keys however `wp_embed_defaults()` returns a
 compacted numerically indexed array.

 The net result is that the provider always has `maxwidth` and `maxheight`
 values of 0, and embeds come out very small.

 Another compounding problem is that block themes don't necessarily declare
 `$contentwidth` either, so the net result is small embeds that don't fill
 their containers.

 Offending code:

 {{{

         public function fetch( $provider, $url, $args = '' ) {
                 $args = wp_parse_args( $args, wp_embed_defaults( $url ) );

                 $provider = add_query_arg( 'maxwidth', (int)
 $args['width'], $provider );
                 $provider = add_query_arg( 'maxheight', (int)
 $args['height'], $provider );

 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65082>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 20:34:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 20:34:16 -0000
Subject: [wp-trac] [WordPress Trac] #65083: Toolbar: Simplify profile item
 by removing "Howdy, <UserName>" text and using a circular avatar
Message-ID: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>

#65083: Toolbar: Simplify profile item by removing "Howdy, <UserName>" text and
using a circular avatar
-------------------------------------+-------------------------------------
 Reporter:  lucasmdo                 |      Owner:  (none)
     Type:  enhancement              |     Status:  new
 Priority:  normal                   |  Milestone:  Awaiting Review
Component:  Toolbar                  |    Version:
 Severity:  normal                   |   Keywords:  needs-patch needs-
  Focuses:  ui, accessibility, css,  |  design
  administration                     |
-------------------------------------+-------------------------------------
 == Problem / Current Behavior ==

 The profile item in the Admin Bar currently displays "Howdy, {Display
 Name}" alongside a small (18×18 px) square avatar. This has three
 problems:

  1. '''Space waste.''' The entire "Howdy, {Display Name}" string — both
 the greeting and the username — consumes significant horizontal space in
 the Toolbar without providing actionable information. The user already
 knows who they are. On narrower viewports or when plugins add their own
 Toolbar items, this width contributes to overflow and wrapping issues (see
 #28983, #53933).
  2. '''Inconsistent icon shape.''' Every other icon in the Toolbar is
 round or icon-shaped. The square avatar is visually inconsistent with the
 rest of the Toolbar.
  3. '''Inconsistent icon size.''' The 18×18 px avatar is smaller than the
 20×20 px icons used throughout the Toolbar, making it an outlier.

 == Proposed Enhancement ==

 Three changes to the `my-account` Toolbar node:

  1. '''Remove the entire "Howdy, {Display Name}" text''' — both the
 greeting and the username — from the top-level Toolbar item. The profile
 menu should display only the avatar icon, with no accompanying text. The
 user's display name is already shown inside the dropdown (`user-info`
 node) and remains in the ARIA label, so no information is lost.
  2. '''Change the avatar shape from square to circle''', aligning it
 visually with the rounded icons used elsewhere in the Toolbar.
  3. '''Increase the avatar size from 18 px to 20 px''' to match the
 standard Toolbar icon dimensions.

 == Rationale ==

  * '''Horizontal space is the Toolbar's scarcest resource.''' Plugins
 (Yoast SEO, W3 Total Cache, WooCommerce, etc.) routinely add items to the
 Toolbar. The "Howdy, {Display Name}" text can be 150–250 px wide depending
 on the display name length. Reclaiming that space directly mitigates the
 wrapping/overlap bugs described in #28983 and #53933.
  * '''Modern convention.''' Most web applications (GitHub, GitLab, Slack,
 Google Workspace) represent the logged-in user as an avatar-only circular
 icon in the top bar. Users are well-trained to recognize this pattern.
  * '''Visual consistency.''' A 20 px circular avatar aligns with the 20×20
 px icons used throughout the Toolbar, eliminating the current size and
 shape mismatch.
  * '''Better handled at the Core level.''' While all three changes can be
 achieved individually through hooks and filters (`admin_bar_menu`,
 `get_avatar`, `wp_enqueue_style`), this is a baseline UX improvement that
 benefits all users. Requiring every site to independently replicate the
 same set of overrides to fix a visual inconsistency and reclaim wasted
 space suggests the default itself should change.

 == Backward Compatibility ==

 This change is purely visual:

  * The `my-account` node ID, parent, href, and dropdown structure remain
 unchanged.
  * The ARIA label (`menu_title`) continues to include the display name, so
 accessibility is preserved.
  * Plugins that modify the "Howdy, {Display Name}" text via
 `admin_bar_menu` or `gettext` will find an empty string for the text
 portion — no errors, no breakage.
  * Themes or plugins that rely on `.with-avatar` CSS selectors will still
 work; only the `img` dimensions and `border-radius` change.
  * The avatar continues to link to the user's profile page.

 == Accessibility ==

  * The `menu_title` meta (used as `aria-label`) must retain the user's
 display name so screen readers announce "Account menu for {Display Name}"
 or equivalent.
  * Removing the visible text does not reduce accessibility because the
 avatar serves as the visual affordance and the ARIA label provides the
 semantic label.
  * A circular 20 px avatar at the standard Toolbar icon size meets WCAG
 2.1 target size guidelines.
  * No keyboard navigation changes are involved.

 == Related Tickets ==

  * #19490 — Filter for "Howdy" text (closed `wontfix`, 2012 — different
 rationale)
  * #28983 — Admin bar length / wrapping (open)
  * #53933 — Admin bar overwrites theme menu on narrow screens (open)
  * #19421 — Admin bar avatar dimensions (fixed)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65083>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 16 20:34:38 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 16 Apr 2026 20:34:38 -0000
Subject: [wp-trac] [WordPress Trac] #65083: Toolbar: Simplify profile
 item by removing "Howdy, <UserName>" text and using a circular avatar
In-Reply-To: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
References: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
Message-ID: <067.8a43cd557fe92f74a04f45db775df0c4@wordpress.org>

#65083: Toolbar: Simplify profile item by removing "Howdy, <UserName>" text and
using a circular avatar
-------------------------------------+-------------------------------------
 Reporter:  lucasmdo                 |       Owner:  (none)
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Toolbar                  |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  needs-patch needs-       |     Focuses:  ui, accessibility,
  design                             |  css, administration
-------------------------------------+-------------------------------------
Changes (by lucasmdo):

 * Attachment "before-after.png" added.

 Before-and-after

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65083>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 00:25:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 00:25:57 -0000
Subject: [wp-trac] [WordPress Trac] #65082: WP_oEmbed()->fetch() uses
 wp_embed_defaults() incorrectly
In-Reply-To: <056.2745434284ff37225e3651b3b0f0f4cc@wordpress.org>
References: <056.2745434284ff37225e3651b3b0f0f4cc@wordpress.org>
Message-ID: <071.e776fb13ff83d15b144724994ab87539@wordpress.org>

#65082: WP_oEmbed()->fetch() uses wp_embed_defaults() incorrectly
--------------------------------------+------------------------------
 Reporter:  sanchothefat              |       Owner:  (none)
     Type:  defect (bug)              |      Status:  closed
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  Embeds                    |     Version:
 Severity:  normal                    |  Resolution:  invalid
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+------------------------------
Changes (by sanchothefat):

 * status:  new => closed
 * resolution:   => invalid


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65082#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 00:27:11 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 00:27:11 -0000
Subject: [wp-trac] [WordPress Trac] #65082: WP_oEmbed()->fetch() uses
 wp_embed_defaults() incorrectly
In-Reply-To: <056.2745434284ff37225e3651b3b0f0f4cc@wordpress.org>
References: <056.2745434284ff37225e3651b3b0f0f4cc@wordpress.org>
Message-ID: <071.b7c04f04a2b70a88f42bd63dd2ade3f6@wordpress.org>

#65082: WP_oEmbed()->fetch() uses wp_embed_defaults() incorrectly
--------------------------------------+------------------------------
 Reporter:  sanchothefat              |       Owner:  (none)
     Type:  defect (bug)              |      Status:  closed
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  Embeds                    |     Version:
 Severity:  normal                    |  Resolution:  invalid
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+------------------------------

Comment (by sanchothefat):

 There's something else going on making the defaults 0. But there is a
 separate issue wherein the default embed sizes are coming out at 500px I'm
 looking into.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65082#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 01:55:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 01:55:07 -0000
Subject: [wp-trac] [WordPress Trac] #65055: _pad_term_counts() uses
 string-concatenated SQL without prepared statement
In-Reply-To: <052.bca20aa704264c411e9a5a70bff738ad@wordpress.org>
References: <052.bca20aa704264c411e9a5a70bff738ad@wordpress.org>
Message-ID: <067.b79c56bc25cacc0ba8089e3d4aaab454@wordpress.org>

#65055: _pad_term_counts() uses string-concatenated SQL without prepared statement
--------------------------------------+------------------------------
 Reporter:  rajeshcp                  |       Owner:  rajeshcp
     Type:  defect (bug)              |      Status:  assigned
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  Database                  |     Version:  trunk
 Severity:  major                     |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+------------------------------
Changes (by liaison):

 * Attachment "65055-sql-filter.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65055>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 02:20:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 02:20:29 -0000
Subject: [wp-trac] [WordPress Trac] #64904: Real time collboration:
 determine approach for opt in setting for users in Settings > Writing
In-Reply-To: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
References: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
Message-ID: <067.34d76fcfbb264489aaad6196b670d8fe@wordpress.org>

#64904: Real time collboration: determine approach for opt in setting for users in
Settings > Writing
------------------------------------+---------------------
 Reporter:  annezazu                |       Owner:  (none)
     Type:  task (blessed)          |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-design has-patch  |     Focuses:  ui
------------------------------------+---------------------

Comment (by peterwilsoncc):

 Replying to [comment:34 fcoveram]:
 > @jameskoster shared an idea that I'm attaching here.
 >
 > It adds a "New" badge next to the field that lasts until the 7.1 or 7.2
 release (depending on how we feel the cadency) or after X number of visits
 so users don't need to wait until the next release to not see it again.
 For the later, after 10 times visiting the page sounds a reasonable period
 to me.
 >
 > What do you think?

 A simple new highlight was my first thought, the approach in the design
 looks nice.

 For longevity of display, I think keep it until WP 7.1 is released rather
 than the number of times a user has seen it. It reduces database writes
 and the need to store meta data/options for our options.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64904#comment:35>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 02:59:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 02:59:48 -0000
Subject: [wp-trac] [WordPress Trac] #64771: Existing block level custom
 CSS in a post breaks when the post is edited by user without
 unfiltered_html
In-Reply-To: <056.6cde4cb4d3674a3ab453a19d1888b21e@wordpress.org>
References: <056.6cde4cb4d3674a3ab453a19d1888b21e@wordpress.org>
Message-ID: <071.4ead0f43a6165672a38053856ab27299@wordpress.org>

#64771: Existing block level custom CSS in a post breaks when the post is edited by
user without unfiltered_html
--------------------------------------------------+---------------------
 Reporter:  glendaviesnz                          |       Owner:  (none)
     Type:  defect (bug)                          |      Status:  new
 Priority:  high                                  |   Milestone:  7.0
Component:  Editor                                |     Version:  trunk
 Severity:  critical                              |  Resolution:
 Keywords:  has-patch has-unit-tests 2nd-opinion  |     Focuses:
--------------------------------------------------+---------------------

Comment (by peterwilsoncc):

 Replying to [comment:51 apeatling]:
 > Will `edit_css` be a standalone capability, or does it resolve to
 `unfiltered_html` via `map_meta_cap`? This materially affects whether
 trusted tools and AI agents can operate on hardened hosts without
 implementing questionable workarounds.
 >
 > **Edit**: I looked it up and it is not a standalone cap. This means all
 hosts that disable unfiltered_html are going to break either way. What
 about making it standalone so it's not painted with the same broad brush
 as HTML filtering?

 It's a bit of both...

 In a default WP install they map to one another.

 They can be made to be independent via the `map_meta_cap` filter, for
 example this can be used to remove `unfiltered_html` without affecting the
 `edit_css` cap.

 {{{#!php
 <?php
 add_filter( 'map_meta_cap', function ( $caps, $cap ) {
         if ( 'unfiltered_html' === $cap ) {
                 $caps[] = 'do_not_allow';
         }
         return $caps;
 }, 10, 2 );
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64771#comment:52>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 04:25:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 04:25:18 -0000
Subject: [wp-trac] [WordPress Trac] #64771: Existing block level custom
 CSS in a post breaks when the post is edited by user without
 unfiltered_html
In-Reply-To: <056.6cde4cb4d3674a3ab453a19d1888b21e@wordpress.org>
References: <056.6cde4cb4d3674a3ab453a19d1888b21e@wordpress.org>
Message-ID: <071.a6ffa55bf98a680a3c8a70bf87c18f56@wordpress.org>

#64771: Existing block level custom CSS in a post breaks when the post is edited by
user without unfiltered_html
--------------------------------------------------+---------------------
 Reporter:  glendaviesnz                          |       Owner:  (none)
     Type:  defect (bug)                          |      Status:  new
 Priority:  high                                  |   Milestone:  7.0
Component:  Editor                                |     Version:  trunk
 Severity:  critical                              |  Resolution:
 Keywords:  has-patch has-unit-tests 2nd-opinion  |     Focuses:
--------------------------------------------------+---------------------

Comment (by ramonopoly):

 Looks like this one needs to move ahead?

 > Show a simple warning notice and punt a more complete solution to 7.1

 I'll rebase and test the [https://github.com/WordPress/wordpress-
 develop/pull/11347 patch].

 It'd be helpful to get some final eyes on it too if folks can spare the
 time before the general release.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64771#comment:53>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 05:38:37 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 05:38:37 -0000
Subject: [wp-trac] [WordPress Trac] #64956: Unnecessary horizontal
 scrollbar on theme-editor.php in WordPress 7.0 RC1
In-Reply-To: <054.5eefe006b265ff88e64c3a86674d6e92@wordpress.org>
References: <054.5eefe006b265ff88e64c3a86674d6e92@wordpress.org>
Message-ID: <069.e57c6c5b485bff7deb9c3703b621155d@wordpress.org>

#64956: Unnecessary horizontal scrollbar on theme-editor.php in WordPress 7.0 RC1
------------------------------------+--------------------------------------
 Reporter:  hardik2812              |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  Awaiting Review
Component:  General                 |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  has-test-info has-      |     Focuses:  ui, css, administration
  patch                             |
------------------------------------+--------------------------------------

Comment (by nikunj8866):

 == Test Report
 === Description
 ✅ This report validates that the patch works as expected.

 Patch tested: https://github.com/WordPress/wordpress-develop/pull/11588

 === Environment
 - WordPress: 7.1-alpha-20260416.100837
 - PHP: 7.4.33
 - Server: PHP.wasm
 - Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
 - Browser: Chrome 146.0.0.0
 - OS: Windows 10/11
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None activated
 - Plugins:
   * Test Reports 1.2.1

 === Steps to Test
 1. Apply the patch from the linked pull request to a WordPress
 installation.
 2. Navigate to Tools > Theme File Editor (theme-editor.php).
 3. Resize the browser window to a small viewport width (e.g., below 768px
 or mobile-sized).
 4. Observe whether a horizontal scrollbar appears on the Theme Files
 section.
 5. Navigate to Tools > Plugin File Editor (plugin-editor.php).
 6. Again, resize the browser window to a small viewport width.
 7. Observe whether a horizontal scrollbar appears on the Plugin Files
 section.

 === Actual Results
 1.  ✅ Issue resolved with patch.
 2. Unnecessary horizontal scrollbar on theme-editor.php is resolved with
 the patch — no horizontal scroll at small widths.
 3. Unnecessary horizontal scrollbar on plugin-editor.php is also resolved
 — no horizontal scroll at small widths.
 4. ✅ Patch also tested on WordPress 6.3 — working as expected with no
 regressions.


 === Supplemental Artifacts
 https://www.awesomescreenshot.com/video/51596248?key=ffed62429a24e4a0d7a07e4fa4de3983

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64956#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 05:40:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 05:40:57 -0000
Subject: [wp-trac] [WordPress Trac] #64917: WP 7.0 Connectors: unclear
 error message
In-Reply-To: <051.50e3faafb74ba8eaaede21fb888645f0@wordpress.org>
References: <051.50e3faafb74ba8eaaede21fb888645f0@wordpress.org>
Message-ID: <066.ea3634ae8695eb02ff4fe01d2ddf7640@wordpress.org>

#64917: WP 7.0 Connectors: unclear error message
---------------------------------+----------------------
 Reporter:  ecairol              |       Owner:  (none)
     Type:  defect (bug)         |      Status:  new
 Priority:  normal               |   Milestone:  7.0.1
Component:  AI                   |     Version:  trunk
 Severity:  normal               |  Resolution:
 Keywords:  ai-client has-patch  |     Focuses:  ui-copy
---------------------------------+----------------------

Comment (by gautam23):

 Hi guys,

 My PR currently uses this text: "Image generation isn’t available because
 it hasn’t been set up yet. Please add an API key for an image-generation
 provider in Connectors, then try again."

 Let me know if it needs to be updated to something else.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64917#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 05:51:51 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 05:51:51 -0000
Subject: [wp-trac] [WordPress Trac] #65083: Toolbar: Simplify profile
 item by removing "Howdy, <UserName>" text and using a circular avatar
In-Reply-To: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
References: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
Message-ID: <067.5db2da55be16332f9ce6c7798f933e1b@wordpress.org>

#65083: Toolbar: Simplify profile item by removing "Howdy, <UserName>" text and
using a circular avatar
-------------------------------------+-------------------------------------
 Reporter:  lucasmdo                 |       Owner:  audrasjb
     Type:  enhancement              |      Status:  accepted
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Toolbar                  |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-design-  |     Focuses:  ui, accessibility,
  feedback                           |  css, administration
-------------------------------------+-------------------------------------
Changes (by audrasjb):

 * keywords:  needs-patch needs-design => has-patch needs-design-feedback
 * owner:  (none) => audrasjb
 * status:  new => accepted


Comment:

 Hello @lucasmdo,

 I agree with this proposal.
 I wrote a tiny Feature Plugin so we can iterate on the design before
 proposing a Core changeset.
 The ZIP is available below.

 Notes:
 - I didn't use a rounded avatar picture as it appeared it was better to
 maximize the image dimension. I suggest to use a square image instead.
 Let's iterate on this.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65083#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 05:52:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 05:52:12 -0000
Subject: [wp-trac] [WordPress Trac] #65083: Toolbar: Simplify profile
 item by removing "Howdy, <UserName>" text and using a circular avatar
In-Reply-To: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
References: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
Message-ID: <067.a8e1e8044d6317abb4480d6bf2501daf@wordpress.org>

#65083: Toolbar: Simplify profile item by removing "Howdy, <UserName>" text and
using a circular avatar
-------------------------------------+-------------------------------------
 Reporter:  lucasmdo                 |       Owner:  audrasjb
     Type:  enhancement              |      Status:  accepted
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Toolbar                  |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-design-  |     Focuses:  ui, accessibility,
  feedback                           |  css, administration
-------------------------------------+-------------------------------------
Changes (by audrasjb):

 * Attachment "simplified-admin-bar.zip" added.

 Feature plugin

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65083>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 05:52:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 05:52:30 -0000
Subject: [wp-trac] [WordPress Trac] #65083: Toolbar: Simplify profile
 item by removing "Howdy, <UserName>" text and using a circular avatar
In-Reply-To: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
References: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
Message-ID: <067.a7a542598d1bbcbd85659923cc9289c7@wordpress.org>

#65083: Toolbar: Simplify profile item by removing "Howdy, <UserName>" text and
using a circular avatar
-------------------------------------+-------------------------------------
 Reporter:  lucasmdo                 |       Owner:  audrasjb
     Type:  enhancement              |      Status:  accepted
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Toolbar                  |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-design-  |     Focuses:  ui, accessibility,
  feedback                           |  css, administration
-------------------------------------+-------------------------------------
Changes (by audrasjb):

 * Attachment "Capture d’écran 2026-04-17 à 07.50.17.png" added.

 Admin view

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65083>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 05:52:43 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 05:52:43 -0000
Subject: [wp-trac] [WordPress Trac] #65083: Toolbar: Simplify profile
 item by removing "Howdy, <UserName>" text and using a circular avatar
In-Reply-To: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
References: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
Message-ID: <067.60149db2c03b154fccfbbba505ad9162@wordpress.org>

#65083: Toolbar: Simplify profile item by removing "Howdy, <UserName>" text and
using a circular avatar
-------------------------------------+-------------------------------------
 Reporter:  lucasmdo                 |       Owner:  audrasjb
     Type:  enhancement              |      Status:  accepted
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Toolbar                  |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-design-  |     Focuses:  ui, accessibility,
  feedback                           |  css, administration
-------------------------------------+-------------------------------------
Changes (by audrasjb):

 * Attachment "Capture d’écran 2026-04-17 à 07.50.43.png" added.

 front end view

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65083>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 06:50:11 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 06:50:11 -0000
Subject: [wp-trac] [WordPress Trac] #65084: Update error message for
 disallowed username characters
Message-ID: <049.08ea48590412276562d442dabf255033@wordpress.org>

#65084: Update error message for disallowed username characters
-------------------------+-----------------------------
 Reporter:  Marc4        |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  General      |    Version:
 Severity:  normal       |   Keywords:  has-patch
  Focuses:  ui-copy      |
-------------------------+-----------------------------
 I suggest replacing “illegal characters” with “unallowed characters” to
 avoid unnecessarily alarming the user and to be more specific.

 This error message appears when you try to create a username that contains
 “special characters.”

 This is the PR: https://github.com/WordPress/wordpress-develop/pull/11590

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65084>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 06:50:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 06:50:28 -0000
Subject: [wp-trac] [WordPress Trac] #65084: Update error message for
 disallowed username characters
In-Reply-To: <049.08ea48590412276562d442dabf255033@wordpress.org>
References: <049.08ea48590412276562d442dabf255033@wordpress.org>
Message-ID: <064.df7828afe4b0804591deb927e5f3196d@wordpress.org>

#65084: Update error message for disallowed username characters
-------------------------+------------------------------
 Reporter:  Marc4        |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  ui-copy
-------------------------+------------------------------
Changes (by Marc4):

 * Attachment "illegal-characters.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65084>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 06:56:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 06:56:09 -0000
Subject: [wp-trac] [WordPress Trac] #65084: Update error message for
 disallowed username characters
In-Reply-To: <049.08ea48590412276562d442dabf255033@wordpress.org>
References: <049.08ea48590412276562d442dabf255033@wordpress.org>
Message-ID: <064.adf2fa5d6033bef8a91fab96e0a2e5d8@wordpress.org>

#65084: Update error message for disallowed username characters
-------------------------+------------------------------
 Reporter:  Marc4        |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  ui-copy
-------------------------+------------------------------

Comment (by Marc4):

 Typo error, sorry. I suggest replacing **illegal** characters with
 **disallowed** characters.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65084#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 07:19:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 07:19:33 -0000
Subject: [wp-trac] [WordPress Trac] #65079:
 block_core_navigation_get_inner_blocks_from_unstable_location() calls
 deprecated function;
 deprecated   docblock references non-existent replacement
In-Reply-To: <057.f8aa4560602986dd5716b694facaaa72@wordpress.org>
References: <057.f8aa4560602986dd5716b694facaaa72@wordpress.org>
Message-ID: <072.8b26c9b2b31d47ad964ae81707da9e97@wordpress.org>

#65079: block_core_navigation_get_inner_blocks_from_unstable_location() calls
deprecated function; deprecated   docblock references non-existent
replacement
-------------------------------------+-------------------------------------
 Reporter:  saratheonline            |       Owner:  saratheonline
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Editor                   |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  docs, coding-standards
-------------------------------------+-------------------------------------

Comment (by saratheonline):

 Replying to [comment:1 wildworks]:
 > @saratheonline Thanks for submitting a patch.
 >
 > The `navigation.php` file cannot be directly edited in the WordPress
 core. This file is synced from the Gutenberg repository.
 >
 > See:
 https://github.com/WordPress/gutenberg/blob/7563e2acf2a8bcfbe6338ca4bd5cc0d7eed74535/packages
 /block-library/src/navigation/index.php#L1601
 >
 > Would it be possible for you to submit a new PR to
 [https://github.com/WordPress/gutenberg the Gutenberg repository]?



 \\Thanks for the pointer! I've confirmed the bug exists in the Gutenberg
 source at packages/block-library/src/navigation/index.php and have moved
 the fix upstream.
   - Gutenberg issue: https://github.com/WordPress/gutenberg/issues/77442
   - Gutenberg PR: https://github.com/WordPress/gutenberg/pull/77445
 \\The PR addresses all three issues:
   1. block_core_navigation_get_inner_blocks_from_unstable_location() no
 longer calls the deprecated
 block_core_navigation_parse_blocks_from_menu_items() — a new private
 helper block_core_navigation_convert_menu_items_to_blocks() holds the
 actual logic.
   2. The missing ?? array() guard on $menu_items_by_parent_id[0] is added.
   3. The @deprecated docblock is corrected to reference
 WP_Classic_To_Block_Menu_Converter::to_blocks().

 This ticket can be closed or marked as a duplicate/upstream once the
 Gutenberg PR is merged and synced to Core.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65079#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 07:21:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 07:21:22 -0000
Subject: [wp-trac] [WordPress Trac] #65079:
 block_core_navigation_get_inner_blocks_from_unstable_location() calls
 deprecated function;
 deprecated   docblock references non-existent replacement
In-Reply-To: <057.f8aa4560602986dd5716b694facaaa72@wordpress.org>
References: <057.f8aa4560602986dd5716b694facaaa72@wordpress.org>
Message-ID: <072.b3e9df3e38f145755fa7ca1b215cf180@wordpress.org>

#65079: block_core_navigation_get_inner_blocks_from_unstable_location() calls
deprecated function; deprecated   docblock references non-existent
replacement
-------------------------------------+-------------------------------------
 Reporter:  saratheonline            |       Owner:  saratheonline
     Type:  defect (bug)             |      Status:  closed
 Priority:  normal                   |   Milestone:
Component:  Editor                   |     Version:  trunk
 Severity:  normal                   |  Resolution:  reported-upstream
 Keywords:  has-patch needs-testing  |     Focuses:  docs, coding-standards
-------------------------------------+-------------------------------------
Changes (by wildworks):

 * status:  assigned => closed
 * resolution:   => reported-upstream
 * milestone:  Awaiting Review =>


Comment:

 @saratheonline Thanks for submitting an issue.

 The ticket can be closed if an issue is reported upstream.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65079#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 07:53:36 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 07:53:36 -0000
Subject: [wp-trac] [WordPress Trac] #65084: Update error message for
 disallowed username characters
In-Reply-To: <049.08ea48590412276562d442dabf255033@wordpress.org>
References: <049.08ea48590412276562d442dabf255033@wordpress.org>
Message-ID: <064.9f263240329a3878243d9b147526fa6d@wordpress.org>

#65084: Update error message for disallowed username characters
-------------------------+------------------------------
 Reporter:  Marc4        |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  ui-copy
-------------------------+------------------------------

Comment (by nikunj8866):

 @Marc4, please add this ticket link to the PR.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65084#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 08:00:35 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 08:00:35 -0000
Subject: [wp-trac] [WordPress Trac] #65084: Update error message for
 disallowed username characters
In-Reply-To: <049.08ea48590412276562d442dabf255033@wordpress.org>
References: <049.08ea48590412276562d442dabf255033@wordpress.org>
Message-ID: <064.03787907992009e20a1d8b29243f9b2b@wordpress.org>

#65084: Update error message for disallowed username characters
-------------------------+------------------------------
 Reporter:  Marc4        |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  ui-copy
-------------------------+------------------------------

Comment (by Marc4):

 Done. Thank's for your follow-up @nikunj8866

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65084#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 08:10:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 08:10:30 -0000
Subject: [wp-trac] [WordPress Trac] #65085: Expose admin design tokens
 (radius, spacing, grayscale,
 typography) as CSS custom properties via wp-base-styles
Message-ID: <049.59245aa90d2a79fd7f70d716b00aca4e@wordpress.org>

#65085: Expose admin design tokens (radius, spacing, grayscale, typography) as CSS
custom properties via wp-base-styles
----------------------------+-----------------------------
 Reporter:  jillq           |      Owner:  (none)
     Type:  enhancement     |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Administration  |    Version:  trunk
 Severity:  normal          |   Keywords:
  Focuses:  ui, css         |
----------------------------+-----------------------------
 == Background ==

 WordPress 7.0's admin visual reskin (#64308) introduced a comprehensive
 design token system in `src/wp-admin/css/_tokens.scss`, covering:

  * '''Border radius:''' `$radius-xs` (1px), `$radius-s` (2px), `$radius-m`
 (4px), `$radius-l` (8px), `$radius-30` (12px), `$radius-full` (9999px)
  * '''Spacing:''' `$grid-unit-05` through `$grid-unit-60` (4px increments)
  * '''Grayscale:''' `$gray-100` through `$gray-900` (a unified neutral
 palette)
  * '''Typography:''' `$font-size-xs` through `$font-size-xl`, `$font-
 weight-regular`, `$font-weight-medium`
  * '''Elevation:''' `$elevation-xs` through `$elevation-l`

 These tokens are used internally by core CSS during the Sass build, but
 the resulting values are not exposed as CSS custom properties at runtime.
 Plugin authors who want to align with Core's design system therefore have
 to hardcode the values (e.g. `border-radius: 8px` to match dashboard
 widgets).

 The existing `wp-base-styles` stylesheet handle already exposes admin
 color scheme tokens this way (`--wp-admin-theme-color`, `--wp-admin-theme-
 color--rgb`, `--wp-admin-theme-color-darker-10`, `--wp-admin-theme-color-
 darker-20`, `--wp-admin-border-width-focus`). This proposal extends that
 pattern to the rest of the token system.

 == Problem ==

 Plugins and themes that want to follow WP 7.0's modernized visual language
 currently have three suboptimal choices:

  1. '''Hardcode the values''' — brittle, silently drifts when Core updates
 the token values
  2. '''Conditionally override with version-gated CSS''' — what WooCommerce
 currently does; adds maintenance burden
  3. '''Don't align''' — fragments the admin visual experience, which is
 exactly what #64308 was trying to fix

 == Proposal ==

 Extend `wp-base-styles` (or introduce a sibling handle) to emit CSS custom
 properties for the public subset of `_tokens.scss`:

 {{{
 :root {
     /* Border radius */
     --wp-admin-radius-xs: 1px;
     --wp-admin-radius-s: 2px;
     --wp-admin-radius-m: 4px;
     --wp-admin-radius-l: 8px;
     --wp-admin-radius-30: 12px;
     --wp-admin-radius-full: 9999px;

     /* Grid units */
     --wp-admin-grid-unit-05: 4px;
     --wp-admin-grid-unit-10: 8px;
     --wp-admin-grid-unit-15: 12px;
     --wp-admin-grid-unit-20: 16px;
     --wp-admin-grid-unit-30: 24px;
     --wp-admin-grid-unit-40: 32px;
     --wp-admin-grid-unit-50: 40px;
     --wp-admin-grid-unit-60: 48px;

     /* Grayscale */
     --wp-admin-gray-100: #f0f0f0;
     --wp-admin-gray-200: #e0e0e0;
     --wp-admin-gray-300: #dddddd;
     --wp-admin-gray-400: #cccccc;
     --wp-admin-gray-600: #949494;
     --wp-admin-gray-700: #757575;
     --wp-admin-gray-900: #1e1e1e;

     /* Typography */
     --wp-admin-font-size-xs: 11px;
     --wp-admin-font-size-s: 12px;
     --wp-admin-font-size-m: 13px;
     --wp-admin-font-size-l: 15px;
     --wp-admin-font-size-xl: 20px;
     --wp-admin-font-weight-regular: 400;
     --wp-admin-font-weight-medium: 500;
 }
 }}}

 Naming follows the existing `--wp-admin-[thing]` convention already
 established for `--wp-admin-theme-color`, `--wp-admin-border-width-focus`,
 etc.

 == Benefits ==

  * '''Plugins align automatically''' — When Core updates a token value (as
 happened with the reskin itself), anything depending on these custom
 properties updates with it. No plugin PR required.
  * '''Consistent admin visual experience''' — Fragmented admin styling is
 a merchant pain point. This unlocks plugin-side alignment without
 duplicating Core values.
  * '''Extends an existing pattern''' — No new architecture; just the next
 step of the work #64308 already started with color tokens.
  * '''Low risk''' — CSS-only change, additive, no functional impact.
 Existing styles unchanged.

 == Implementation notes ==

 The `wp-base-styles` handle is already loaded on admin pages (from
 #64308's sub-tickets). This change would extend that stylesheet's contents
 to include the additional custom properties listed above, likely sourced
 from the same `_tokens.scss` during the Sass build.

 An optional follow-up could also migrate existing hardcoded token usage
 inside Core admin CSS to reference these custom properties, but that's not
 required for this ticket — exposing the values is sufficient to unlock
 plugin alignment.

 == Prior art ==

  * #52623 — "Proposal: Add CSS variable for admin-bar height to core" —
 same pattern: expose an existing value as a CSS custom property for
 plugin/theme use.
  * [https://make.wordpress.org/core/2021/01/29/introducing-css-custom-
 properties/ Introducing CSS Custom Properties to the WordPress Admin (Make
 Core, 2021)] — the original project that gave us `--wp-admin-theme-color`.
  * #64308 — the WP 7.0 admin reskin that introduced the token system this
 proposal would expose.

 == Alternatives considered ==

 Core could instead publish admin tokens via an NPM package similar to
 @wordpress/base-styles. That approach works well for plugins with modern
 build pipelines, but doesn't help plugins without one, and can't respond
 to runtime preferences like the user's admin color scheme. A CSS custom
 property approach (like the existing `--wp-admin-theme-color`) complements
 the NPM package route rather than replacing it.

 == Related ==

 I've been doing plugin-side alignment work for WooCommerce (see
 [https://github.com/woocommerce/woocommerce/pull/64196
 woocommerce/woocommerce#64196] for a recent example) and ran into this
 friction directly. To be clear, I'm not waiting on this to ship the
 plugin-side work — WooCommerce is already adopting the existing `--wp-
 admin-theme-color` pattern with hardcoded fallbacks where Core tokens
 aren't exposed. This ticket is about making the next round of that work
 more systemic.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65085>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 08:32:04 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 08:32:04 -0000
Subject: [wp-trac] [WordPress Trac] #65085: Expose admin design tokens
 (radius, spacing, grayscale,
 typography) as CSS custom properties via wp-base-styles
In-Reply-To: <049.59245aa90d2a79fd7f70d716b00aca4e@wordpress.org>
References: <049.59245aa90d2a79fd7f70d716b00aca4e@wordpress.org>
Message-ID: <064.951b13f49f26f0cdeaf0c85da2c68db3@wordpress.org>

#65085: Expose admin design tokens (radius, spacing, grayscale, typography) as CSS
custom properties via wp-base-styles
----------------------------+------------------------------
 Reporter:  jillq           |       Owner:  (none)
     Type:  enhancement     |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:  ui, css
----------------------------+------------------------------

Comment (by jameskoster):

 Closely related: Is there any way to extract and use the design tokens
 (https://github.com/WordPress/gutenberg/blob/trunk/packages/theme/src/prebuilt/css
 /design-tokens.css) from Gutenberg's Theme Package, rather than
 duplicating?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65085#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 08:49:32 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 08:49:32 -0000
Subject: [wp-trac] [WordPress Trac] #65046: get_weekstartend() has
 swapped variable names and comments for month and day
In-Reply-To: <057.a04ab5ef592944628bef1cd9cd93c2e5@wordpress.org>
References: <057.a04ab5ef592944628bef1cd9cd93c2e5@wordpress.org>
Message-ID: <072.9b45f19455e74ae2244daf1d2b32ab4f@wordpress.org>

#65046: get_weekstartend() has swapped variable names and comments for month and
day
---------------------------+-----------------------------------------------
 Reporter:  saratheonline  |       Owner:  saratheonline
     Type:  defect (bug)   |      Status:  assigned
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  Date/Time      |     Version:  trunk
 Severity:  normal         |  Resolution:
 Keywords:  has-patch      |     Focuses:  sustainability, coding-standards
  needs-testing            |
---------------------------+-----------------------------------------------
Changes (by saratheonline):

 * focuses:   => sustainability, coding-standards


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65046#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 09:03:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 09:03:12 -0000
Subject: [wp-trac] [WordPress Trac] #65085: Expose admin design tokens
 (radius, spacing, grayscale,
 typography) as CSS custom properties via wp-base-styles
In-Reply-To: <049.59245aa90d2a79fd7f70d716b00aca4e@wordpress.org>
References: <049.59245aa90d2a79fd7f70d716b00aca4e@wordpress.org>
Message-ID: <064.d3b2c373b79549bd1f5a1a77a3620870@wordpress.org>

#65085: Expose admin design tokens (radius, spacing, grayscale, typography) as CSS
custom properties via wp-base-styles
----------------------------+------------------------------
 Reporter:  jillq           |       Owner:  (none)
     Type:  enhancement     |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:  ui, css
----------------------------+------------------------------

Comment (by jillq):

 Replying to [comment:1 jameskoster]:
 > Closely related: Is there any way to extract and use the design tokens
 (https://github.com/WordPress/gutenberg/blob/trunk/packages/theme/src/prebuilt/css
 /design-tokens.css) from Gutenberg's Theme Package, rather than
 duplicating?

 Claude says yes because the tokens are twins with slight differences only
 in naming, not in visuals. Haha. I'm assuming -- as long as we are
 committed to keeping Gutenberg + wp-admin aligned (which I am also
 assuming we are?) then it works!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65085#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 09:22:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 09:22:06 -0000
Subject: [wp-trac] [WordPress Trac] #65086: Add action hooks to media modal
 attachment details templates for field extensibility
Message-ID: <054.7fabfdfcb46f5e6537471a8076c5d178@wordpress.org>

#65086: Add action hooks to media modal attachment details templates for field
extensibility
-------------------------+-----------------------------
 Reporter:  kaavyaiyer   |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  Media        |    Version:
 Severity:  normal       |   Keywords:
  Focuses:               |
-------------------------+-----------------------------
 Since WP 7.0 ships with a built-in AI client, there is a need for AI-
 powered features like alt text generation to be able to place controls
 (e.g., a "Generate" button) directly next to the fields they act on within
 the media modal.

 Currently, {{{wp-includes/media-template.php}}} does not provide any hooks
 inside the attachment details templates where fields like Alternative Text
 are rendered. This leaves JavaScript DOM manipulation as a workaround to
 place controls directly next to existing fields.

 The first concrete use case is the [https://github.com/WordPress/ai] alt
 text generation experiment, which needs a "Generate" button next to the
 Alternative Text textarea. See:
 [https://github.com/WordPress/ai/issues/425 WordPress/ai#425] for the
 original discussion.

 == Proposed Solution
 Add action hooks inside the two attachment details Backbone templates in
 {{{media-template.php}}}

 === Extending to other fields

 Beyond the media modal, similar hooks would benefit other areas of the
 admin where AI features need to place controls next to existing fields for
 title, image, caption generation, etc. This ticket focuses on the media
 modal as the starting point.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65086>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 09:52:11 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 09:52:11 -0000
Subject: [wp-trac] [WordPress Trac] #65083: Toolbar: Simplify profile
 item by removing "Howdy, <UserName>" text and using a circular avatar
In-Reply-To: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
References: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
Message-ID: <067.e895b2bffa9983d5a1adcf0496c5e3da@wordpress.org>

#65083: Toolbar: Simplify profile item by removing "Howdy, <UserName>" text and
using a circular avatar
-------------------------------------+-------------------------------------
 Reporter:  lucasmdo                 |       Owner:  audrasjb
     Type:  enhancement              |      Status:  accepted
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Toolbar                  |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-design-  |     Focuses:  ui, accessibility,
  feedback                           |  css, administration
-------------------------------------+-------------------------------------

Comment (by siliconforks):

 Note that the avatar might not be displayed at all, depending on the
 configuration under Settings → Discussion.

 1. There is a setting to turn off avatars entirely.
 2. Even if avatars are enabled, users without a custom avatar will get a
 default avatar, which (depending on settings) might just be a generic logo
 or even completely blank.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65083#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 10:45:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 10:45:39 -0000
Subject: [wp-trac] [WordPress Trac] #65087: oEmbed dynamic aspect ratio
 handling in block themes without $content_width
Message-ID: <056.32fcba116135736a2170447cab1ff52b@wordpress.org>

#65087: oEmbed dynamic aspect ratio handling in block themes without $content_width
--------------------------+-----------------------------
 Reporter:  sanchothefat  |      Owner:  (none)
     Type:  enhancement   |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Embeds        |    Version:
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 oEmbed handling in block themes is good for well known players like
 YouTube with the embed block aspect ratio class handling, but some embeds
 are just coming out at 500px per the default `wp_embed_defaults()`
 settings, especially now that block themes don't necessary set
 `$content_width` - the theme.json content width replaces it many ways but
 it can have a unit other than px.

 I think that block themes should set default embed max widths to the same
 dimension as the large image width, and then if the oembed data response
 contains `width` and `height` values, generate a class name and add
 supporting styles to set the aspect-ratio and auto height, or output
 inline styles on the iframe.

 This will improve the output and behaviour to match user expectations for
 more built in, custom and discoverable embeds.

 One example is using the player.vimeo.com video embed endpoint - used for
 non publicly listed videos, try embedding
 https://player.vimeo.com/video/1138248349 and make the block full width.

 In summary:

 * Setting `$content_width` is no longer viable as a simple pixel value for
 settings embed width and may be missing
 * theme.json can use number + units for the `contentWidth` and `wideWidth`
 so can't reliably set `$content_width` from it
 * The default embed size from `wp_embed_defaults()` is 500px wide without
 `$content_width` set to something else
 * Passing `width` or `maxwidth` to the provider URL via the
 `oembed_fetch_url` filter gets a larger embed within the iframe, but it
 isn't responsive e.g. height remains fixed

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65087>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 12:10:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 12:10:55 -0000
Subject: [wp-trac] [WordPress Trac] #65083: Toolbar: Simplify profile
 item by removing "Howdy, <UserName>" text and using a circular avatar
In-Reply-To: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
References: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
Message-ID: <067.c96d8176ecaf0a94353357a455dc69dc@wordpress.org>

#65083: Toolbar: Simplify profile item by removing "Howdy, <UserName>" text and
using a circular avatar
-------------------------------------+-------------------------------------
 Reporter:  lucasmdo                 |       Owner:  audrasjb
     Type:  enhancement              |      Status:  accepted
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Toolbar                  |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-design-  |     Focuses:  ui, accessibility,
  feedback                           |  css, administration
-------------------------------------+-------------------------------------

Comment (by lucasmdo):

 Hi @audrasjb, can we make the avatar rounded?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65083#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 12:11:02 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 12:11:02 -0000
Subject: [wp-trac] [WordPress Trac] #65083: Toolbar: Simplify profile
 item by removing "Howdy, <UserName>" text and using a circular avatar
In-Reply-To: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
References: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
Message-ID: <067.21930826d7533e9f61594ed3cd746393@wordpress.org>

#65083: Toolbar: Simplify profile item by removing "Howdy, <UserName>" text and
using a circular avatar
-------------------------------------+-------------------------------------
 Reporter:  lucasmdo                 |       Owner:  audrasjb
     Type:  enhancement              |      Status:  accepted
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Toolbar                  |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-design-  |     Focuses:  ui, accessibility,
  feedback                           |  css, administration
-------------------------------------+-------------------------------------

Comment (by lucasmdo):

 "There is a setting to turn off avatars entirely."
 Thanks for the clarification, @siliconforks . I didn't know that. Where
 can I find this setting?

 "users without a custom avatar will get a default avatar"
 In terms of having a generic avatar, this is completely fine. It's the
 same use case when a site doesn't have a site icon, right?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65083#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 12:25:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 12:25:39 -0000
Subject: [wp-trac] [WordPress Trac] #65083: Toolbar: Simplify profile
 item by removing "Howdy, <UserName>" text and using a circular avatar
In-Reply-To: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
References: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
Message-ID: <067.1b47837cdff7864d451948e3f80933e6@wordpress.org>

#65083: Toolbar: Simplify profile item by removing "Howdy, <UserName>" text and
using a circular avatar
-------------------------------------+-------------------------------------
 Reporter:  lucasmdo                 |       Owner:  audrasjb
     Type:  enhancement              |      Status:  accepted
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Toolbar                  |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-design-  |     Focuses:  ui, accessibility,
  feedback                           |  css, administration
-------------------------------------+-------------------------------------

Comment (by ocean90):

 Related/Duplicate of #64667.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65083#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 12:55:46 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 12:55:46 -0000
Subject: [wp-trac] [WordPress Trac] #65083: Toolbar: Simplify profile
 item by removing "Howdy, <UserName>" text and using a circular avatar
In-Reply-To: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
References: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
Message-ID: <067.bab2c9a5056c8d422d5dec3eb8ae97c4@wordpress.org>

#65083: Toolbar: Simplify profile item by removing "Howdy, <UserName>" text and
using a circular avatar
-------------------------------------+-------------------------------------
 Reporter:  lucasmdo                 |       Owner:  audrasjb
     Type:  enhancement              |      Status:  accepted
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Toolbar                  |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-design-  |     Focuses:  ui, accessibility,
  feedback                           |  css, administration
-------------------------------------+-------------------------------------
Changes (by siliconforks):

 * Attachment "avatars.png" added.

 These are the avatar-related settings.  The current default avatar is
 "Mystery Person", which just displays the same avatar for all users
 without their own avatar.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65083>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 12:57:50 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 12:57:50 -0000
Subject: [wp-trac] [WordPress Trac] #65083: Toolbar: Simplify profile
 item by removing "Howdy, <UserName>" text and using a circular avatar
In-Reply-To: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
References: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
Message-ID: <067.ff76f66376246020ed0a68f342c6a706@wordpress.org>

#65083: Toolbar: Simplify profile item by removing "Howdy, <UserName>" text and
using a circular avatar
-------------------------------------+-------------------------------------
 Reporter:  lucasmdo                 |       Owner:  audrasjb
     Type:  enhancement              |      Status:  accepted
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Toolbar                  |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-design-  |     Focuses:  ui, accessibility,
  feedback                           |  css, administration
-------------------------------------+-------------------------------------

Comment (by siliconforks):

 Replying to [comment:4 lucasmdo]:
 > "There is a setting to turn off avatars entirely."
 > Thanks for the clarification, @siliconforks . I didn't know that. Where
 can I find this setting?

 All the avatar-related settings are under Settings → Discussion.  The
 "Show Avatars" checkbox can be used to turn avatars off entirely; the
 "Default Avatar" setting can be used to customize what sort of avatar is
 shown for users without their own avatar.  See the above screenshot.

 > "users without a custom avatar will get a default avatar"
 > In terms of having a generic avatar, this is completely fine. It's the
 same use case when a site doesn't have a site icon, right?

 If the "Howdy, <UserName>" text is removed, there may be no indication of
 who the current logged-in user is.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65083#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 13:29:36 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 13:29:36 -0000
Subject: [wp-trac] [WordPress Trac] #65088: Toolbar: Replace home dashicon
 with site icon in the admin bar
Message-ID: <052.76cb989887be1f889167c61a5aa6324a@wordpress.org>

#65088: Toolbar: Replace home dashicon with site icon in the admin bar
------------------------------------+-----------------------------
 Reporter:  lucasmdo                |      Owner:  (none)
     Type:  enhancement             |     Status:  new
 Priority:  normal                  |  Milestone:  Awaiting Review
Component:  Toolbar                 |    Version:
 Severity:  normal                  |   Keywords:  needs-patch
  Focuses:  ui, accessibility, css  |
------------------------------------+-----------------------------
 == Problem / Current Behavior ==

 The admin bar displays a generic '''home dashicon''' next to the site
 name. This icon is the same for every WordPress site and carries no site-
 specific meaning. Users typically scan the admin bar rather than reading
 it, so a generic icon does little to help them quickly identify which site
 they are viewing, especially when multiple sites are open in different
 tabs.

 The site icon (set via Settings → General or the Customizer) already
 serves as a unique visual identity for the site in browser tabs and mobile
 home screens, but it is not surfaced in the admin bar.


 == Proposed Enhancement ==

 Replace the home dashicon in the admin bar with the site's icon. When no
 site icon is set, display a '''default letter icon''' using the first
 letter of the site name.

 [[Image(site-icon.png)]]

 === When a site icon is set ===

  * Replace the home dashicon (`dashicons-admin-home`) with an `<img>`
 element using the site icon at 20×20 px.
  * Apply `border-radius: 2px` for subtle rounded corners.
  * It should be support it by HiDPI/Retina displays


 === When no site icon is set (default letter icon) ===

  * Display a 20×20 px square with `background-color: #3858E9` and `border-
 radius: 2px`.
  * Render the '''first letter''' of the site name centered inside the
 square, uppercase.
  * This default icon is '''only''' used in the admin bar, it does not
 appear in browser tabs or anywhere else, and it is not related to the Site
 Icon setting in Settings → General.

 == Rationale ==

  * '''Unique visual identity:''' The site icon is the site's unique mark,
 already used in browser tabs and mobile bookmarks. Surfacing it in the
 admin bar reinforces that identity where users interact most.
  * '''Scanability:''' Users scan but, in general, they don't read the
 page. A unique, site icon is faster to identify than a monochrome generic
 house across multiple tabs.
  * '''Consistent experience:''' Even sites without a custom site icon get
 a more meaningful visual cue, the first letter of their site name, instead
 of an identical home icon on every WordPress install.

 == Backward Compatibility ==

 This change is fully backward compatible:

  * No existing settings or options are affected.
  * Plugins or themes that modify the admin bar will continue to work.
  * No deprecations needed.

 == Accessibility ==

  * Both the site icon and the letter fallback should have `aria-
 hidden="true"` since the site name text is already present next to them,
 the icon is decorative.
  * Ensure the icon does not break the admin bar's existing keyboard
 navigation or screen reader announcements.

 == Future Consideration ==

 The default letter icon could also be extended to the '''browser tab
 favicon'''. When users have multiple WordPress sites open without custom
 site icons, all tabs display an empty space, making them hard to
 distinguish. Generating a letter-based favicon would solve this. However,
 that change has a broader scope so it is better suited as a follow-up
 ticket.

 == Related Tickets ==

  * #46657 — Show site icon in My Sites admin menu (fixed, WP 5.8)
  * #25971 — Changed site-name icon from globe to home dashicon (fixed)
  * #64308 — Admin visual reskin exploration for WP 7.0

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65088>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 13:29:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 13:29:53 -0000
Subject: [wp-trac] [WordPress Trac] #65088: Toolbar: Replace home
 dashicon with site icon in the admin bar
In-Reply-To: <052.76cb989887be1f889167c61a5aa6324a@wordpress.org>
References: <052.76cb989887be1f889167c61a5aa6324a@wordpress.org>
Message-ID: <067.b896a4aa642bf1773646dd0fbf90c379@wordpress.org>

#65088: Toolbar: Replace home dashicon with site icon in the admin bar
-------------------------+-------------------------------------
 Reporter:  lucasmdo     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Toolbar      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |     Focuses:  ui, accessibility, css
-------------------------+-------------------------------------
Changes (by lucasmdo):

 * Attachment "site-icon.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65088>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 14:45:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 14:45:13 -0000
Subject: [wp-trac] [WordPress Trac] #65089: Administration: Replace
 Dashicons icon font with @wordpress/icons SVG components in wp-admin
Message-ID: <052.9097c32e14a8a10701f8781ee4827d62@wordpress.org>

#65089: Administration: Replace Dashicons icon font with @wordpress/icons SVG
components in wp-admin
-------------------------------------+-------------------------------------
 Reporter:  lucasmdo                 |      Owner:  (none)
     Type:  enhancement              |     Status:  new
 Priority:  normal                   |  Milestone:  Awaiting Review
Component:  Administration           |    Version:
 Severity:  normal                   |   Keywords:  needs-patch needs-
  Focuses:  ui, accessibility,       |  design needs-design-feedback
  javascript, css, administration,   |
  performance                        |
-------------------------------------+-------------------------------------
 == Problem / Current Behavior ==

 The WordPress admin area (wp-admin) still relies on Dashicons, an icon
 font introduced in WordPress 3.8 (released December 12, 2013 — over 12
 years ago). While Dashicons served WordPress well, the icon font approach
 has significant limitations:

  * '''Inconsistency''': The block editor and Site Editor already use
 `@wordpress/icons` (SVG-based React components), while the rest of wp-
 admin uses the legacy Dashicons font. This creates a visual and technical
 split within the same application.
  * '''Performance''': The entire icon font (~300+ glyphs) is loaded,
 regardless of how many icons a page actually uses. This adds unnecessary
 weight to every admin page load.
  * '''Accessibility''':
    * '''Screen readers''': Icons may be read as nonsense or ignored
 entirely, confusing users who rely on assistive technology.
    * '''Font overrides''': Users who change fonts for readability can
 break all icons, turning them into empty squares.
    * '''Copy-paste''': Copying text that includes icons produces random,
 meaningless characters.
    * '''High-contrast mode''': Icons can vanish when users enable high-
 contrast or forced-colors settings in their OS.
    * '''No built-in meaning''': Icon fonts are just styled characters with
 no inherent description — accessibility has to be added manually.5.5. No
 new icons can be added.

 == Proposed Enhancement ==

 Replace Dashicons icon font usage in wp-admin with `@wordpress/icons` SVG
 components (or inline SVGs derived from the same library). This would:

  1. Unify the icon system across all of WordPress, block editor, Site
 Editor, and classic admin screens would all use the same modern icon
 library.
  2. Enable tree-shaking so that only the icons actually used on a given
 page are loaded.
  3. Improve accessibility: inline SVGs support `aria-label` for example.
  4. Allow new icons to be added as needed without growing a monolithic
 font file.


 == Rationale ==

 This is not a new idea, it has been the stated direction of the WordPress
 project since 2020:

  * The [https://make.wordpress.org/design/2020/04/20/next-steps-for-
 dashicons/ Make/Design blog post] (April 2020) confirmed Dashicons was
 closed to new requests and that future efforts would focus on the new Icon
 component.
  * [ticket:49913] explicitly states: "This update is the final planned
 update of the Dashicons font. Moving forward, the more modern approach of
 using SVG icons directly (as the block editor currently does) will be
 explored."
  * [ticket:47498] comments reference "a long standing plan to remove all
 font icons from core in favor of SVGs."

 Six years have passed since this direction was set, and no formal ticket
 tracks the actual migration work. This ticket aims to formalize the effort
 and track progress.

 == Backward Compatibility ==

 This is a critical consideration. Many plugins and themes use
 `dashicons-*` CSS classes for admin menus, meta boxes, and custom UI. A
 migration plan should:

  * Maintain the `dashicons` stylesheet as a deprecated fallback for a
 defined transition period (multiple major releases).
  * Provide a compatibility layer so that existing `dashicons-*` class
 references continue to render correctly, perhaps by mapping them to their
 SVG equivalents.
  * Document the migration path for plugin and theme developers with clear
 timelines.

 == Related Tickets / References ==

  * [ticket:49913] — Final Dashicons update (WordPress 5.5)
  * [ticket:47498] — Checkbox/radio SVG migration, discusses removing font
 icons from Core
  * [ticket:41074] — Dashicons 4.9–5.2, discusses SVG direction for the
 admin
  * [https://make.wordpress.org/design/2020/04/20/next-steps-for-dashicons/
 Next steps for Dashicons] — Make/Design official post
  * [https://make.wordpress.org/core/2020/07/15/dashicons-in-wordpress-5-5
 -the-final-update/ Dashicons in WordPress 5.5: The Final Update] — Dev
 note
  * [https://github.com/WordPress/gutenberg/tree/trunk/packages/icons
 @wordpress/icons package on GitHub]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65089>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 14:49:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 14:49:12 -0000
Subject: [wp-trac] [WordPress Trac] #65090: Missing escaping for dynamic
 link text
Message-ID: <055.eacae8cd344dccf3a5cca1aa8300c6f2@wordpress.org>

#65090: Missing escaping for dynamic link text
------------------------------+-----------------------------
 Reporter:  maheshpatel       |      Owner:  (none)
     Type:  defect (bug)      |     Status:  new
 Priority:  normal            |  Milestone:  Awaiting Review
Component:  General           |    Version:  trunk
 Severity:  normal            |   Keywords:  has-patch
  Focuses:  coding-standards  |
------------------------------+-----------------------------
 **File:** [src/wp-login.php](src/wp-login.php#L234)
 - **Line:** 234
 - **Problem:** `$message` output without escaping (filterable content)
 - **Current Code:**

   if ( ! empty( $message ) ) {
       echo $message . "\n";
   }

 - **Context:** `$message` comes from `apply_filters( 'login_message',
 $message )` but could contain HTML or special chars
 - **Fix:** Context-dependent, could be:

   // If message is expected to have HTML:
   if ( ! empty( $message ) ) {
       echo wp_kses_post( $message ) . "\n";
   }
   // Or if plain text:
   if ( ! empty( $message ) ) {
       echo esc_html( $message ) . "\n";
   }

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65090>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 14:51:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 14:51:17 -0000
Subject: [wp-trac] [WordPress Trac] #65090: Missing escaping for dynamic
 link text
In-Reply-To: <055.eacae8cd344dccf3a5cca1aa8300c6f2@wordpress.org>
References: <055.eacae8cd344dccf3a5cca1aa8300c6f2@wordpress.org>
Message-ID: <070.b144cd354c339582476a6a296c153333@wordpress.org>

#65090: Missing escaping for dynamic link text
--------------------------+-------------------------------
 Reporter:  maheshpatel   |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  coding-standards
--------------------------+-------------------------------

Comment (by maheshpatel):

 The issue has been addressed and a fix has been implemented.

 A pull request has been submitted for review: https://github.com/WordPress
 /wordpress-develop/pull/11594

 Kindly take a look and share your feedback. Happy to make any required
 changes.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65090#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 15:12:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 15:12:12 -0000
Subject: [wp-trac] [WordPress Trac] #65090: Missing escaping for dynamic
 link text
In-Reply-To: <055.eacae8cd344dccf3a5cca1aa8300c6f2@wordpress.org>
References: <055.eacae8cd344dccf3a5cca1aa8300c6f2@wordpress.org>
Message-ID: <070.7227014f9d474064c6d5fb3940240cb8@wordpress.org>

#65090: Missing escaping for dynamic link text
--------------------------+-------------------------------
 Reporter:  maheshpatel   |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  coding-standards
--------------------------+-------------------------------
Changes (by mukesh27):

 * version:  trunk =>


Old description:

> **File:** [src/wp-login.php](src/wp-login.php#L234)
> - **Line:** 234
> - **Problem:** `$message` output without escaping (filterable content)
> - **Current Code:**
>
>   if ( ! empty( $message ) ) {
>       echo $message . "\n";
>   }
>
> - **Context:** `$message` comes from `apply_filters( 'login_message',
> $message )` but could contain HTML or special chars
> - **Fix:** Context-dependent, could be:
>
>   // If message is expected to have HTML:
>   if ( ! empty( $message ) ) {
>       echo wp_kses_post( $message ) . "\n";
>   }
>   // Or if plain text:
>   if ( ! empty( $message ) ) {
>       echo esc_html( $message ) . "\n";
>   }

New description:

 **File:** [src/wp-login.php](src/wp-login.php#L234)
 - **Line:** 234
 - **Problem:** `$message` output without escaping (filterable content)
 - **Current Code:**
 {{{
 if ( ! empty( $message ) ) {
    echo $message . "\n";
 }
 }}}
 - **Context:** `$message` comes from `apply_filters( 'login_message',
 $message )` but could contain HTML or special chars
 - **Fix:** Context-dependent, could be:
 {{{
 // If message is expected to have HTML:
 if ( ! empty( $message ) ) {
    echo wp_kses_post( $message ) . "\n";
 }
 // Or if plain text:
 if ( ! empty( $message ) ) {
    echo esc_html( $message ) . "\n";
 }
 }}}

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65090#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 15:21:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 15:21:53 -0000
Subject: [wp-trac] [WordPress Trac] #65083: Toolbar: Simplify profile
 item by removing "Howdy, <UserName>" text and using a circular avatar
In-Reply-To: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
References: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
Message-ID: <067.7ad8bc03a88918886f5bb835120d1d92@wordpress.org>

#65083: Toolbar: Simplify profile item by removing "Howdy, <UserName>" text and
using a circular avatar
-------------------------------------+-------------------------------------
 Reporter:  lucasmdo                 |       Owner:  audrasjb
     Type:  enhancement              |      Status:  accepted
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Toolbar                  |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-design-  |     Focuses:  ui, accessibility,
  feedback                           |  css, administration
-------------------------------------+-------------------------------------

Comment (by jorbin):

 Howdy @lucasmdo and welcome to trac!

 `Howdy` has a long tradition of being in WordPress. It's a part of the
 flavor of WordPress. It helps set the tone and humanizes the experience of
 using WordPress.[https://wordpress.tv/2011/09/07/daryl-koopersmith-
 decisions-not-options/ This WordCamp talk from a committer emeritus] lays
 out why it's valuable and thus should absolutly stay. It's also something
 that a number of localizations get to have some fun with to really make
 WordPress feel at home.  [https://translate.wordpress.org/projects/wp/dev
 /en-
 za/default/?filters%5Bterm%5D=Howdy%2C+%25s&filters%5Bterm_scope%5D=scope_any&filters%5Bstatus%5D=current_or_waiting_or_fuzzy_or_untranslated&filters%5Buser_login%5D=&filter=Apply+Filters&sort%5Bby%5D=priority&sort%5Bhow%5D=desc
 Howzit], [https://translate.wordpress.org/projects/wp/dev/en-
 au/default/?filters%5Bterm%5D=Howdy%2C+%25s&filters%5Bterm_scope%5D=scope_any&filters%5Bstatus%5D=current_or_waiting_or_fuzzy_or_untranslated&filters%5Buser_login%5D=&filter=Apply+Filters&sort%5Bby%5D=priority&sort%5Bhow%5D=desc
 G'day], and
 [https://translate.wordpress.org/projects/wp/dev/pirate/default/?filters%5Bterm%5D=Howdy%2C+%25s&filters%5Bterm_scope%5D=scope_any&filters%5Bstatus%5D=current_or_waiting_or_fuzzy_or_untranslated&filters%5Buser_login%5D=&filter=Apply+Filters&sort%5Bby%5D=priority&sort%5Bhow%5D=desc
 Ahoy] all help users feel at home inside WordPress.

 No strong opinion on the avatar changes.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65083#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 15:27:37 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 15:27:37 -0000
Subject: [wp-trac] [WordPress Trac] #64904: Real time collboration:
 determine approach for opt in setting for users in Settings > Writing
In-Reply-To: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
References: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
Message-ID: <067.fd02f335cdf4c1752cd7c21e8d5a7a60@wordpress.org>

#64904: Real time collboration: determine approach for opt in setting for users in
Settings > Writing
------------------------------------+---------------------
 Reporter:  annezazu                |       Owner:  (none)
     Type:  task (blessed)          |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-design has-patch  |     Focuses:  ui
------------------------------------+---------------------
Changes (by sabernhardt):

 * Attachment "crowded-settings-page-current.png" added.

 current Writing Settings page layout in trunk, with Link Manager and
 Classic Editor plugins activated, `initial_db_version` manually set to
 32100, and Twenty Thirteen as the theme

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64904>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 15:27:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 15:27:56 -0000
Subject: [wp-trac] [WordPress Trac] #64904: Real time collboration:
 determine approach for opt in setting for users in Settings > Writing
In-Reply-To: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
References: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
Message-ID: <067.5ae8e1aa130e394499f3b6af029a439f@wordpress.org>

#64904: Real time collboration: determine approach for opt in setting for users in
Settings > Writing
------------------------------------+---------------------
 Reporter:  annezazu                |       Owner:  (none)
     Type:  task (blessed)          |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-design has-patch  |     Focuses:  ui
------------------------------------+---------------------
Changes (by sabernhardt):

 * Attachment "notice-warning-when-disabled.png" added.

 warning-style notice when collaboration is disabled (by host)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64904>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 15:28:25 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 15:28:25 -0000
Subject: [wp-trac] [WordPress Trac] #64904: Real time collboration:
 determine approach for opt in setting for users in Settings > Writing
In-Reply-To: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
References: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
Message-ID: <067.b65813605d2eb8cc4662dd1a9763b813@wordpress.org>

#64904: Real time collboration: determine approach for opt in setting for users in
Settings > Writing
------------------------------------+---------------------
 Reporter:  annezazu                |       Owner:  (none)
     Type:  task (blessed)          |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-design has-patch  |     Focuses:  ui
------------------------------------+---------------------
Changes (by sabernhardt):

 * Attachment "dashicons-option.png" added.

 Dashicons option: adding 'groups' icon after the text, with the setting
 positioned at the top of the page

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64904>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 15:30:54 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 15:30:54 -0000
Subject: [wp-trac] [WordPress Trac] #64904: Real time collboration:
 determine approach for opt in setting for users in Settings > Writing
In-Reply-To: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
References: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
Message-ID: <067.6f45637ddfba35f1ef72824cb323734d@wordpress.org>

#64904: Real time collboration: determine approach for opt in setting for users in
Settings > Writing
------------------------------------+---------------------
 Reporter:  annezazu                |       Owner:  (none)
     Type:  task (blessed)          |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-design has-patch  |     Focuses:  ui
------------------------------------+---------------------

Comment (by sabernhardt):

 ==== Placement

 I think Collaboration belongs at the top of the Writing Settings page. The
 new setting is more difficult to notice with additional settings such as
 the legacy Link Manager categories or Classic Editor plugin options. The
 Formatting options appear for sites created before WordPress 4.3 (#32298).

 ==== When setting is disabled

 - The `notice-warning` style seems inappropriate for a 'Note' message,
 especially when the user cannot override the setting within the admin
 area.
 - It could have the `notice-info` class, but I prefer removing the notice
 `div` styling entirely.
 - I would not want to give extra attention to the setting's label (`th`
 header) when the checkbox is unavailable.

 ==== Calling more attention to Collaboration

 - Adding 'New' could help, and I agree that the special text or icon
 should not disappear before the next major release.
 - The (site) editor had a 'beta' badge for multiple releases, and that
 could also fit Collaboration for any number of releases.
 - Adding one of the Dashicons, such as 'groups', could fit indefinitely.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64904#comment:36>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 16:43:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 16:43:09 -0000
Subject: [wp-trac] [WordPress Trac] #65091: Toolbar: Display the toolbar in
 the Site Editor and Block Editor
Message-ID: <052.ac01559e4f77c9901d3bb3cf47d7d4d3@wordpress.org>

#65091: Toolbar: Display the toolbar in the Site Editor and Block Editor
-----------------------------------------------+---------------------------
 Reporter:  lucasmdo                           |      Owner:  (none)
     Type:  enhancement                        |     Status:  new
 Priority:  normal                             |  Milestone:  Awaiting
                                               |  Review
Component:  Toolbar                            |    Version:
 Severity:  normal                             |   Keywords:  needs-patch
  Focuses:  ui, accessibility, administration  |
-----------------------------------------------+---------------------------
 == Problem / Current Behavior ==

 The WordPress Admin Bar (Toolbar) is displayed on the front end and across
 wp-admin screens, but it is '''hidden''' in both the Site Editor and the
 Block Editor. This creates a navigation inconsistency: users who rely on
 the Admin Bar as their primary way to move between areas of WordPress lose
 that affordance the moment they enter either editor.

 As WordPress has evolved, the editors have introduced their own navigation
 patterns, the Site Editor sidebar, the back arrow / WordPress logo button,
 the ''Template · Page Title'' breadcrumb, that differ from the rest of the
 admin experience. The result is multiple, competing navigation models:

  * '''wp-admin screens''': Admin Bar + left sidebar menu.
  * '''Front end (logged in)''': Admin Bar.
  * '''Site Editor''': Custom sidebar (Design panel) with no Admin Bar.
  * '''Block Editor (fullscreen, the default)''': Custom top toolbar with
 no Admin Bar and no wp-admin sidebar.

 This fragmentation means:

  * It is not immediately clear how to '''exit''' the editor and return to
 wp-admin or the front end.
  * Users must learn different navigation patterns depending on which
 screen they are on.
  * The Admin Bar, the one element that is consistent across the front end
 and wp-admin, is absent precisely where users may need it most.


 == Proposed Enhancement ==

 Display the Admin Bar in the Site Editor and Block Editor, just as it is
 rendered on wp-admin screens and the front end. The full Toolbar should
 appear at the top of the viewport, above the editor chrome, preserving all
 standard nodes and any nodes added by plugins.

 This would unify the navigation model across all WordPress contexts:

  * '''wp-admin screens''': Admin Bar + left sidebar.
  * '''Front end''': Admin Bar.
  * '''Site Editor''': Admin Bar + editor sidebar.
  * '''Block Editor''': Admin Bar + editor toolbar.

 The Admin Bar becomes the single, persistent navigation element users can
 always rely on.

 [[Image(site-editor.png)]]

 == Rationale ==

 '''Why Core and not a plugin:'''

  * The Admin Bar is a Core feature and its visibility is a Core decision.
  * Navigation consistency across all of WordPress is a platform-level
 concern, not a plugin concern.
  * The current situation, where Core itself hides Core's own navigation
 element, is an inconsistency that should be resolved in Core.

 '''Who benefits:'''

  * '''All users''': consistent, predictable navigation regardless of
 context.
  * '''New users''': fewer navigation patterns to learn.
  * '''Power users and site administrators''': quick access to ''+New'',
 user menu, and plugin-added toolbar nodes without leaving the editor.
  * '''Plugin developers''': toolbar nodes they register via the standard
 API become available in the editors without extra work.

 '''Supporting context:'''

 Related tickets and issues confirm that editor navigation is a recognized
 pain point:

  * [https://github.com/WordPress/gutenberg/issues/38554 Gutenberg #38554]:
 Users requesting ''Add New'' access from within the Block Editor, which
 the Admin Bar already provides.
  * [https://github.com/WordPress/gutenberg/issues/72135 Gutenberg #72135]:
 Proposal to unify the Site Editor layout, including consistency between
 admin and editor views.


 == Backward Compatibility ==

 This change is '''additive'''. No existing functionality is removed or
 altered


 == Future Considerations ==

 If this enhancement is accepted and implemented, follow-up tickets should
 be filed to address editor UI adjustments that ensure visual and
 functional consistency with the Admin Bar present. These may include, but
 are not limited to:

  * Aligning the Block Editor top toolbar layout and spacing with the Admin
 Bar above it.
  * Revisiting the Site Editor sidebar header and back-navigation
 affordances to complement (rather than duplicate) what the Admin Bar
 already provides.
  * Ensuring responsive behavior on smaller screens accounts for the
 combined height of the Admin Bar and editor toolbar.

 Each of these would be filed as a separate ticket and cross-referenced
 back to this one.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65091>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 16:43:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 16:43:21 -0000
Subject: [wp-trac] [WordPress Trac] #65091: Toolbar: Display the toolbar
 in the Site Editor and Block Editor
In-Reply-To: <052.ac01559e4f77c9901d3bb3cf47d7d4d3@wordpress.org>
References: <052.ac01559e4f77c9901d3bb3cf47d7d4d3@wordpress.org>
Message-ID: <067.6449e2901696093fd6fa44b0a4c070ab@wordpress.org>

#65091: Toolbar: Display the toolbar in the Site Editor and Block Editor
-------------------------+------------------------------------------------
 Reporter:  lucasmdo     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Toolbar      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |     Focuses:  ui, accessibility, administration
-------------------------+------------------------------------------------
Changes (by lucasmdo):

 * Attachment "site-editor.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65091>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 17:12:27 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 17:12:27 -0000
Subject: [wp-trac] [WordPress Trac] #65092: Toolbar: Replace the "+ New" and
 Comments icons with plain text labels and swap their order
Message-ID: <052.651ca3dd58490beddf5318b9d32df784@wordpress.org>

#65092: Toolbar: Replace the "+ New" and Comments icons with plain text labels and
swap their order
-------------------------------------------------+-------------------------
 Reporter:  lucasmdo                             |      Owner:  (none)
     Type:  enhancement                          |     Status:  new
 Priority:  normal                               |  Milestone:  Awaiting
                                                 |  Review
Component:  Toolbar                              |    Version:
 Severity:  normal                               |   Keywords:  needs-patch
  Focuses:  ui, accessibility, css,              |
  administration, ui-copy                        |
-------------------------------------------------+-------------------------
 == The Problem ==

 * '''The Comments item''' shows only a speech-bubble icon and a number.
 People who have not used WordPress before often do not know what this icon
 means.

 * '''The "+ New" item''' already shows the word "New" next to a plus icon.
 The plus icon does not add any new meaning. It just takes up space and
 repeats what the word already says.

 On top of that, the Comments item sits before the "+ New" item. Adding new
 content is a much more common action than moderating comments, so the
 order feels backwards.

 == The Proposed Change ==

  1. '''Replace the speech-bubble icon''' on the Comments Toolbar item with
 a plain text label: `Comments 3` (where `3` is the current number of
 comments waiting for moderation).
  2. '''Replace the plus icon''' on the "+ New" Toolbar item with just the
 word `New`.
  3. '''Swap the order''' so that `New` comes before `Comments`.

 See the attached image. The top bar is the proposed change. The bottom bar
 is what WordPress looks like today.

 [[Image(new-comments.png)]]

 == Why This Helps ==

  * '''Clearer for everyone.''' A word is easier to understand than an
 icon, especially the first time someone logs in.
  * '''Better accessibility.''' Visible text works better for a bigger
 audience.
  * '''Less visual clutter.''' The plus icon next to the word "New" is
 redundant. Removing it makes the Toolbar cleaner.
  * '''Better order.''' Creating new content is a more common task than
 moderating comments. Putting "New" first matches what people do most
 often.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65092>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 17:12:35 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 17:12:35 -0000
Subject: [wp-trac] [WordPress Trac] #65092: Toolbar: Replace the "+ New"
 and Comments icons with plain text labels and swap their order
In-Reply-To: <052.651ca3dd58490beddf5318b9d32df784@wordpress.org>
References: <052.651ca3dd58490beddf5318b9d32df784@wordpress.org>
Message-ID: <067.f6f42a92776f452a21ce07e9abec123e@wordpress.org>

#65092: Toolbar: Replace the "+ New" and Comments icons with plain text labels and
swap their order
-------------------------+-------------------------------------------------
 Reporter:  lucasmdo     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Toolbar      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |     Focuses:  ui, accessibility, css,
                         |  administration, ui-copy
-------------------------+-------------------------------------------------
Changes (by lucasmdo):

 * Attachment "new-comments.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65092>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 18:27:08 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 18:27:08 -0000
Subject: [wp-trac] [WordPress Trac] #65093: Age Assurance Framework for
 WordPress
Message-ID: <054.2ca0427147e923c361f0b12823b2a91d@wordpress.org>

#65093: Age Assurance Framework for WordPress
-----------------------------+-----------------------------
 Reporter:  telizarose       |      Owner:  (none)
     Type:  feature request  |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  Administration   |    Version:
 Severity:  normal           |   Keywords:
  Focuses:                   |
-----------------------------+-----------------------------
 == Summary ==
 Add standardized hooks and infrastructure to support age-aware user
 experiences and regulatory compliance

 == Problem Statement ==

 Age assurance is becoming a baseline requirement for digital products.
 Across the U.S., a patchwork of state laws now mandates age verification
 or age-based restrictions:

 * '''California Digital Age Assurance Act (AB 1043)''' (effective January
 2027) – Enables standardized age signals from operating systems to
 applications
 * '''California Age-Appropriate Design Code (AB 2273)''' – Requires
 services likely used by minors to assess age and mitigate harm
 * '''Protecting Our Kids from Social Media Addiction Act (SB 976)''' –
 Mandates age-based restrictions on feeds and engagement features
 * '''App Store Accountability Acts''' – Shift responsibility to developers
 for age verification and parental controls
 * '''Texas HB 1181''' – Requires age verification for access to certain
 online content (upheld by U.S. Supreme Court)
 * '''Additional states''' (Utah, Louisiana, Florida, Arkansas, Tennessee,
 Virginia, Wyoming, and others) – Impose age verification or age-based
 restrictions on content, social media, or app usage

 Collectively, roughly '''25+ states''' have passed age verification laws
 in some form, with more legislation pending. Federal policymakers are
 actively exploring similar requirements.

 ==== The Gap ====

 Despite this regulatory shift, WordPress lacks:

 1. A standardized way to receive or interpret age signals (from operating
 systems, browsers, or third parties)
 2. A unified model for age-based policy enforcement across plugins,
 themes, and APIs
 3. A consistent mechanism to support developers in meeting regulatory
 expectations

 Currently, age handling in WordPress is fragmented, inconsistent, and
 largely dependent on isolated plugin logic or manual site-owner
 implementation. This creates:

 * '''Compliance risk''' for site owners unable to implement trusted,
 auditable age systems
 * '''Developer burden''' – Every implementation reinvents the wheel
 * '''Ecosystem weakness''' – WordPress will lacks standardized age signals
 soon to be required for end users

 == Proposed Solution ==

 WordPress should provide standardized infrastructure—not mandate policy—to
 enable the ecosystem to build trustworthy, compliant age-aware solutions.

 This includes:

 1. '''Age context as first-class user data''' – Standardized metadata
 structure for age-related signals and verification state
 2. '''Extensible hooks''' – Entry points for plugins to receive, validate,
 and enforce age-based policies
 3. '''REST API alignment''' – Age context accessible and enforceable in
 API workflows
 4. '''Audit trail support''' – Standardized logging mechanism for
 compliance and accountability

 == User Stories ==

 === Story 1: Site Owner Can Receive and Track Age Signals ===

 '''As a''' site owner
 '''I want to''' receive age verification signals from external sources
 (OS, browser, third-party providers)
 '''So that''' I can implement age-aware experiences without building
 verification from scratch

 === Story 2: Developer Can Build Age-Based Access Control ===

 '''As a''' plugin or theme developer
 '''I want to''' enforce age-based access rules on content and features
 '''So that''' site owners can comply with age-awareness regulations
 without hardcoding policies

 === Story 3: Developer Can Log Age-Related Events for Compliance ===

 '''As a''' compliance or logging plugin developer
 '''I want to''' capture when age signals are received and when access is
 granted/denied based on age
 '''So that''' site owners have an auditable trail for regulatory
 compliance

 === Story 4: REST API Respects Age Context ===

 '''As an''' API client
 '''I want to''' receive age-aware responses and permission errors from
 REST endpoints
 '''So that''' I can build age-gated experiences on mobile apps, headless
 frontends, etc.

 == Why This Matters Now ==

 1. '''Regulatory acceleration:''' Laws are passing faster than plugins are
 developing unified solutions. Core support prevents future fragmentation.

 2. '''Competitive parity:''' iOS 17+, Android, and web browsers are
 already standardizing age signals. These regulations will increase this
 need across more platforms. WordPress needs to participate in this shift.

 3. '''Ecosystem efficiency:''' Plugins should focus on policy and UX, not
 infrastructure. Core hooks enable this separation.

 4. '''Trust and compliance:''' Site owners need an auditable, platform-
 level approach to age handling, not ad-hoc plugin combinations.

 5. '''Future-proofing:''' As federal regulations emerge, WordPress sites
 with standardized age infrastructure will adapt faster than those with
 fragmented implementations.

 == Out of Scope ==

 This ticket is '''not''' proposing:

 * Age verification services or APIs (plugins provide these)
 * Specific age-based policies (plugins and site owners decide)
 * Content filtering or blocking (core provides hooks; plugins enforce
 policy)
 * Changes to authentication or login flow
 * New user roles or capabilities (leverage existing system)
 * Breaking changes to existing functionality

 == References ==

 === Federal ===
 * [https://www.congress.gov/bill/118th-congress/senate-bill/1291 U.S.
 Senate: Kids Online Safety Act (KOSA) - Bipartisan bill addressing age
 verification and youth online safety]

 === California ===
 *
 [https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202320241043
 California AB 1043 (Digital Age Assurance Act)] – Effective January 1,
 2027
 *
 [https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202320242273
 California AB 2273 (Age-Appropriate Design Code)] – Age assessment and
 design standards for minors
 *
 [https://leginfo.legislature.ca.gov/faces/billNavClient.xhtml?bill_id=202320240976
 California SB 976 (Protecting Our Kids from Social Media Addiction Act)] –
 Age-based feed/engagement restrictions

 === Texas ===
 *
 [https://capitol.texas.gov/BillLookup/History.aspx?LegSess=88R&Bill=HB1181
 Texas HB 1181] – Age verification for adult content; upheld by U.S.
 Supreme Court

 === Other States (Sample) ===
 * '''Utah''' – HB 296 (Age Verification for Adult Content)
 * '''Louisiana''' – HB 1 (Online Age Verification Requirements)
 * '''Florida''' – HB 1 (Age Verification for Social Media)
 * '''Arkansas''' – HB 1939 (Age Verification Requirements)
 * '''Tennessee''' – HB 1414 / SB 1117 (Age Verification for Minors)
 * '''Virginia''' – SB 427 (Parental Notification and Age Verification)
 * '''Wyoming''' – HF 0073 (Age Verification for Age-Restricted Services)

 === Industry Standards & Platforms ===
 * [https://www.apple.com/child-safety/ Apple Privacy-Preserving Age
 Signal] – iOS 17+, macOS Sonoma+
 * [https://developer.android.com/docs/quality-guidelines/core-app-quality
 Google Play App Age Rating] – Android age assurance ecosystem
 * [https://www.ncsl.org/technology-and-communications/age-verification-
 privacy-and-safety-online National Conference of State Legislatures (NCSL)
 Age Verification Tracking]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65093>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 19:40:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 19:40:28 -0000
Subject: [wp-trac] [WordPress Trac] #61343: Improve caching in
 get_calendar function
In-Reply-To: <056.b68517dc5a08edc253cc4f9e98fbe260@wordpress.org>
References: <056.b68517dc5a08edc253cc4f9e98fbe260@wordpress.org>
Message-ID: <071.4df7f151f23e2b205d72e5a8cb0d18f4@wordpress.org>

#61343: Improve caching in get_calendar function
-------------------------------------------------+-------------------------
 Reporter:  spacedmonkey                         |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  7.1
Component:  Widgets                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-patch reporter-   |     Focuses:
  feedback has-unit-tests                        |  performance
-------------------------------------------------+-------------------------
Changes (by SergeyBiryukov):

 * milestone:  Awaiting Review => 7.1


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/61343#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 19:50:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 19:50:44 -0000
Subject: [wp-trac] [WordPress Trac] #64225: Test tool and unit test
 improvements for 7.0
In-Reply-To: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
References: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
Message-ID: <066.cd2ea70ece5ef8c5b940482adf3d0ae5@wordpress.org>

#64225: Test tool and unit test improvements for 7.0
--------------------------------------+---------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  task (blessed)            |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by SergeyBiryukov):

 In [changeset:"62244" 62244]:
 {{{
 #!CommitTicketReference repository="" revision="62244"
 Tests: Add missing `@covers` tags for some rewrite tests.

 Props sagardeshmukh.
 See #64225.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64225#comment:68>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 21:18:01 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 21:18:01 -0000
Subject: [wp-trac] [WordPress Trac] #65090: Missing escaping for dynamic
 link text
In-Reply-To: <055.eacae8cd344dccf3a5cca1aa8300c6f2@wordpress.org>
References: <055.eacae8cd344dccf3a5cca1aa8300c6f2@wordpress.org>
Message-ID: <070.afe6910dce5bc897f3c4029e94e1cbc2@wordpress.org>

#65090: Missing escaping for dynamic link text
-----------------------------------+-------------------------------
 Reporter:  maheshpatel            |       Owner:  (none)
     Type:  defect (bug)           |      Status:  new
 Priority:  normal                 |   Milestone:  Awaiting Review
Component:  General                |     Version:
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |     Focuses:  coding-standards
-----------------------------------+-------------------------------
Changes (by johnbillion):

 * keywords:  has-patch => has-patch 2nd-opinion


Comment:

 @maheshpatel There are ''thousands'' of places in WordPress where escaping
 or KSES could be added. If the value comes from user generated data then
 escaping or KSES should be considered, but there are backwards
 compatibility, interoperability, and performance concerns with escaping or
 KSESing everything.

 If we were writing WordPress from scratch today then we'd probably escape
 almost everything by default. But we're not.

 Therefore these missing escaping tickets aren't particularly helpful and
 aren't the best use of everyone's time unless you can demonstrate a real
 problem that's caused by the lack of escaping, or you can demonstrate that
 the value comes from user generated data.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65090#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 21:24:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 21:24:30 -0000
Subject: [wp-trac] [WordPress Trac] #65055: _pad_term_counts() uses
 string-concatenated SQL without prepared statement
In-Reply-To: <052.bca20aa704264c411e9a5a70bff738ad@wordpress.org>
References: <052.bca20aa704264c411e9a5a70bff738ad@wordpress.org>
Message-ID: <067.58bec22d39c6a9d7c865b1357386a7c9@wordpress.org>

#65055: _pad_term_counts() uses string-concatenated SQL without prepared statement
--------------------------------------+--------------------------
 Reporter:  rajeshcp                  |       Owner:  johnbillion
     Type:  enhancement               |      Status:  reviewing
 Priority:  normal                    |   Milestone:  7.1
Component:  Taxonomy                  |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+--------------------------
Changes (by johnbillion):

 * status:  assigned => reviewing
 * severity:  major => normal
 * component:  Database => Taxonomy
 * version:  trunk =>
 * milestone:  Awaiting Review => 7.1
 * owner:  rajeshcp => johnbillion
 * type:  defect (bug) => enhancement


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65055#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 21:31:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 21:31:55 -0000
Subject: [wp-trac] [WordPress Trac] #63085: "Login details" spam sent by
 from the account registration page
In-Reply-To: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
References: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
Message-ID: <066.7c0e336a21c18a196b5243c59bc944c4@wordpress.org>

#63085: "Login details" spam sent by from the account registration page
----------------------------------------------------+---------------------
 Reporter:  cweiske                                 |       Owner:  (none)
     Type:  defect (bug)                            |      Status:  new
 Priority:  normal                                  |   Milestone:  7.0.1
Component:  Login and Registration                  |     Version:
 Severity:  normal                                  |  Resolution:
 Keywords:  has-patch has-unit-tests has-test-info  |     Focuses:
----------------------------------------------------+---------------------
Changes (by johnbillion):

 * milestone:  Awaiting Review => 7.0.1


Comment:

 Moving to 7.0.1 for consideration. The password reset URL contains the
 username so I agree there's little need to include it in the email message
 text.

 Doesn't do much to prevent the spam signups, but perhaps it'll deter them
 eventually.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63085#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 17 23:28:04 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 17 Apr 2026 23:28:04 -0000
Subject: [wp-trac] [WordPress Trac] #64904: Real time collboration:
 determine approach for opt in setting for users in Settings > Writing
In-Reply-To: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
References: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
Message-ID: <067.8af9c0e285bb7068d6f546a12d2ff0ef@wordpress.org>

#64904: Real time collboration: determine approach for opt in setting for users in
Settings > Writing
------------------------------------+---------------------
 Reporter:  annezazu                |       Owner:  (none)
     Type:  task (blessed)          |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-design has-patch  |     Focuses:  ui
------------------------------------+---------------------

Comment (by annezazu):

 More feedback from chatting with Matt today about the feature:

 >ideally under the checkbox it should say what mode it will be running in,
 and if it's unavailable be greyed out and indicate why vs just removing
 that row which could be confusing.

 I explained the current greyed out approach. In this case though, we need
 to add in something indicating whether someone is using the default
 approach or an upgrade/premium approach, like web sockets. @fcoveram can
 you help with this once more, design wise?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64904#comment:37>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 01:38:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 01:38:07 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.27692a0f5d311991cb47ca13771403d7@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
-------------------------------------+-------------------------------------
 Reporter:  piyushpatel123           |       Owner:  audrasjb
     Type:  defect (bug)             |      Status:  accepted
 Priority:  normal                   |   Milestone:  7.0
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  needs-testing has-patch  |     Focuses:  ui, css,
  admin-reskin                       |  administration
-------------------------------------+-------------------------------------

Comment (by monzuralam):

 == Test Report
 This report validates that the indicated patch addresses the issue.

 Patch tested: [https://github.com/WordPress/wordpress-develop/pull/11463]

 === Environment
 - OS: Windows 11
 - Web Server: Apache/2.4.54
 - PHP: 8.2.25
 - WordPress: 7.0-RC2
 - Browser: Chrome 146.0.7680.178
 - Theme:  Twenty Twenty-Five 1.4
 - Active Plugins: None

 === Steps to Test
 - Navigated to Users → Edit User
 - Clicked "Set New Password"
 - Checked alignment of the eye icon and "Hide" text

 === Expected Results
 ✅ Patch successfully resolves the issue.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031#comment:20>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 03:35:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 03:35:28 -0000
Subject: [wp-trac] [WordPress Trac] #65094: AI: Prompt construction fails
 with fatal error when wp_ai_client_default_request_timeout filter returns
 negative number
Message-ID: <055.509291ad956b141bc82b251686725e0d@wordpress.org>

#65094: AI: Prompt construction fails with fatal error when
wp_ai_client_default_request_timeout filter returns negative number
--------------------------+-------------------------
 Reporter:  westonruter   |      Owner:  westonruter
     Type:  defect (bug)  |     Status:  assigned
 Priority:  normal        |  Milestone:  7.0
Component:  AI            |    Version:
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-------------------------
 Consider this code:


 {{{
 add_filter(
         'wp_ai_client_default_request_timeout',
         static function () {
                 return -1;
         }
 );
 }}}

 This causes a fatal error to occur when constructing a prompt with
 `wp_ai_client_prompt()`:

 {{{
 WordPress\AiClient\Common\Exception\InvalidArgumentException: Request
 option "timeout" must be greater than or equal to 0.

 /var/www/src/wp-includes/php-ai-
 client/src/Providers/Http/DTO/RequestOptions.php:201
 /var/www/src/wp-includes/php-ai-
 client/src/Providers/Http/DTO/RequestOptions.php:52
 /var/www/src/wp-includes/php-ai-
 client/src/Providers/Http/DTO/RequestOptions.php:169
 /var/www/src/wp-includes/ai-client/class-wp-ai-client-prompt-
 builder.php:203
 /var/www/src/wp-includes/ai-client.php:59
 }}}

 As exceptions are caught in ability callbacks (#65058) and generally
 `WP_Error` objects are returned, it would seem this exception should be
 caught in favor of issuing `_doing_it_wrong()`.

 Note: I stumbled upon this issue when looking at the AI codebase in
 PHPStan with rule level 10 applied. For this line:

 {{{#!php
 <?php
 $default_timeout = (int) apply_filters(
 'wp_ai_client_default_request_timeout', 30 );
 }}}

 PHPStan complains with:

 > Cannot cast mixed to int.

 I started adding an `is_numeric()` check here and this led me down to
 looking at the validation logic in
 `\WordPress\AiClient\Providers\Http\DTO\RequestOptions::validateTimeout()`.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65094>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 03:44:15 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 03:44:15 -0000
Subject: [wp-trac] [WordPress Trac] #65095: Introduce Application Mode
 (DISABLE_BLOG) to disable post/blog features for secure non-CMS usage
Message-ID: <057.e392633509a2d7b062101e1eada86e22@wordpress.org>

#65095: Introduce Application Mode (DISABLE_BLOG) to disable post/blog features for
secure non-CMS usage
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  (none)
  dramitstalbot          |
     Type:  feature      |     Status:  new
  request                |
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  General      |    Version:
 Severity:  normal       |   Keywords:  feature-request needs-design-
  Focuses:  rest-api,    |  feedback
  performance            |
-------------------------+-------------------------------------------------
 WordPress has evolved beyond a blogging platform and is widely used as an
 application framework for building systems such as CRMs, ERPs, and
 healthcare software.

 There is currently no supported, centralized way to disable blog/content-
 related functionality at the core level when it is not needed.

 Problem

 Even when WordPress is used purely as an application framework:

 * Core blog features (posts, categories, tags, comments, feeds) are always
 loaded
 * Associated hooks, filters, and REST endpoints remain active
 * Rewrite rules and query handling for posts are still registered
 * Admin UI includes unused components

 This increases:

 * Attack surface (especially via plugins targeting post workflows)
 * Resource usage
 * Complexity in securing deployments

 Real-World Use Case

 I am a medical doctor and developer building a Hospital Management
 Information System (HMIS) on WordPress.

 This system includes:

 * Patient records and clinical documentation
 * Prescription workflows
 * Medical file storage
 * Billing and administration

 In this context:

 * WordPress is used strictly as an application framework
 * Blog functionality is completely unused
 * Reducing unnecessary components is critical for security, especially in
 healthcare environments

 Proposal

 Introduce a core constant:

 define('DISABLE_BLOG', true);

 When enabled, WordPress operates in an Application Mode.

 Expected Behavior

 When DISABLE_BLOG is enabled:

 * Do not register:

   * post post type
   * category and post_tag taxonomies
   * comment system

 * Disable:

   * Post-related REST API endpoints (e.g., /wp/v2/posts)
   * Feeds and post permalinks
   * Author archives

 * Skip loading:

   * Blog-related hooks and filters

 * Admin UI:

   * Remove Posts and Comments menus
   * Remove related dashboard widgets

 Benefits

 * Reduced attack surface
 * Improved performance
 * Cleaner application-focused architecture
 * Better suitability for secure and regulated environments
 * Encourages WordPress adoption for non-CMS use cases

 Why This Matters

 One of WordPress’s biggest strengths is its low learning curve and ease of
 use. Because of this, many developers consider WordPress first before
 exploring other frameworks.

 Providing a native way to disable blog functionality would:

 * Strengthen WordPress as a general-purpose framework
 * Retain developers who might otherwise move to other stacks
 * Expand adoption in enterprise and healthcare systems

 Technical Considerations (Initial Thoughts)

 * Conditional loading in wp-settings.php and default-filters.php

 * Introduce helper:

 function wp_is_application_mode() {
 return defined('DISABLE_BLOG') && DISABLE_BLOG;
 }

 * Wrap blog-specific registrations and hooks
 * Provide filters for extensibility (e.g., REST whitelist)

 Backward Compatibility

 * Default behavior unchanged
 * Feature is opt-in via constant
 * Plugins/themes can detect and adapt

 Future Scope

 * Granular flags:

   * WP_DISABLE_COMMENTS
   * WP_DISABLE_FEEDS
   * WP_DISABLE_REST_POSTS

 * Preset modes:

   * CMS Mode (default)
   * Application Mode

 Summary

 This proposal introduces a lightweight Application Mode that allows
 WordPress to function as a secure, minimal framework when CMS features are
 not required.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65095>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 03:55:32 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 03:55:32 -0000
Subject: [wp-trac] [WordPress Trac] #65095: Introduce Application Mode
 (DISABLE_BLOG) to disable post/blog features for secure non-CMS usage
In-Reply-To: <057.e392633509a2d7b062101e1eada86e22@wordpress.org>
References: <057.e392633509a2d7b062101e1eada86e22@wordpress.org>
Message-ID: <072.e722ca54564ae90f17328eb1aecdac1a@wordpress.org>

#65095: Introduce Application Mode (DISABLE_BLOG) to disable post/blog features for
secure non-CMS usage
-------------------------------------------------+-------------------------
 Reporter:  dramitstalbot                        |       Owner:  (none)
     Type:  feature request                      |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  General                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  feature-request needs-design-        |     Focuses:  rest-api,
  feedback                                       |  performance
-------------------------------------------------+-------------------------
Changes (by dramitstalbot):

 * Attachment "Screenshot 2026-04-18 at 9.20.47 AM.png" added.

 My HMIS project page

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65095>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 03:55:59 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 03:55:59 -0000
Subject: [wp-trac] [WordPress Trac] #65095: Introduce Application Mode
 (DISABLE_BLOG) to disable post/blog features for secure non-CMS usage
In-Reply-To: <057.e392633509a2d7b062101e1eada86e22@wordpress.org>
References: <057.e392633509a2d7b062101e1eada86e22@wordpress.org>
Message-ID: <072.8cc1b442deafc52cf3620536fa1c58e2@wordpress.org>

#65095: Introduce Application Mode (DISABLE_BLOG) to disable post/blog features for
secure non-CMS usage
-------------------------------------------------+-------------------------
 Reporter:  dramitstalbot                        |       Owner:  (none)
     Type:  feature request                      |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  General                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  feature-request needs-design-        |     Focuses:  rest-api,
  feedback                                       |  performance
-------------------------------------------------+-------------------------
Changes (by dramitstalbot):

 * Attachment "Screenshot 2026-04-18 at 9.18.57 AM.png" added.

 Consultation page (Wordpress)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65095>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 03:56:20 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 03:56:20 -0000
Subject: [wp-trac] [WordPress Trac] #65095: Introduce Application Mode
 (DISABLE_BLOG) to disable post/blog features for secure non-CMS usage
In-Reply-To: <057.e392633509a2d7b062101e1eada86e22@wordpress.org>
References: <057.e392633509a2d7b062101e1eada86e22@wordpress.org>
Message-ID: <072.a8ccbbc13b31b70b402aaaa73439a846@wordpress.org>

#65095: Introduce Application Mode (DISABLE_BLOG) to disable post/blog features for
secure non-CMS usage
-------------------------------------------------+-------------------------
 Reporter:  dramitstalbot                        |       Owner:  (none)
     Type:  feature request                      |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  General                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  feature-request needs-design-        |     Focuses:  rest-api,
  feedback                                       |  performance
-------------------------------------------------+-------------------------
Changes (by dramitstalbot):

 * Attachment "Screenshot 2026-04-18 at 9.18.19 AM.png" added.

 Dashboard

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65095>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 04:42:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 04:42:13 -0000
Subject: [wp-trac] [WordPress Trac] #65095: Introduce Application Mode
 (DISABLE_BLOG) to disable post/blog features for secure non-CMS usage
In-Reply-To: <057.e392633509a2d7b062101e1eada86e22@wordpress.org>
References: <057.e392633509a2d7b062101e1eada86e22@wordpress.org>
Message-ID: <072.0e6318db47b198279905e0b0e3b4927d@wordpress.org>

#65095: Introduce Application Mode (DISABLE_BLOG) to disable post/blog features for
secure non-CMS usage
-------------------------------------------------+-------------------------
 Reporter:  dramitstalbot                        |       Owner:  (none)
     Type:  feature request                      |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  General                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  feature-request needs-design-        |     Focuses:  rest-api,
  feedback                                       |  performance
-------------------------------------------------+-------------------------

Comment (by joshuadnelson):

 Hey @dramitstalbot , thanks for advocating for this!

 I’m invested in this idea and willing to work on implementing something in
 core. Until there’s a core path I’ll recommend the [Disable
 Blog](https://wordpress.org/plugins/disable-blog/) plugin, which provides
 a lot of this functionality.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65095#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 04:42:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 04:42:33 -0000
Subject: [wp-trac] [WordPress Trac] #65096: Add `is_user_member_of_blog`
 filter
Message-ID: <048.9dfa96df3fb9723aaae7786446ed0799@wordpress.org>

#65096: Add `is_user_member_of_blog` filter
-----------------------------+-----------------------------
 Reporter:  dd32             |      Owner:  (none)
     Type:  enhancement      |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  Role/Capability  |    Version:
 Severity:  normal           |   Keywords:
  Focuses:  multisite        |
-----------------------------+-----------------------------
 WordPress uses `is_user_member_of_blog()` in the rest api controllers to
 prevent the user endpoints running for non-members of the site.

 For WordPress.org this caused an issue as 'no' users are members of the
 site on which we wanted users to be able to use the rest-api endpoints for
 various account purposes.

 This was resolved through faking the metadata such that it always returned
 truthful, without granting additional capabilities:
 https://github.com/WordPress/wporg-two-
 factor/pull/348#issuecomment-4206959949

 I've run into another use-case for it, where I want to dynamically grant a
 user access to a site, but I don't want to give the user a role directly.
 Causing me to use the same metadata filter approach.

 A filter on `is_user_member_of_blog` would make this a lot simpler.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65096>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 05:04:46 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 05:04:46 -0000
Subject: [wp-trac] [WordPress Trac] #65093: Age Assurance Framework for
 WordPress
In-Reply-To: <054.2ca0427147e923c361f0b12823b2a91d@wordpress.org>
References: <054.2ca0427147e923c361f0b12823b2a91d@wordpress.org>
Message-ID: <069.89fe19d5bccfd98e5c4e77444be5e357@wordpress.org>

#65093: Age Assurance Framework for WordPress
-------------------------------+------------------------------
 Reporter:  telizarose         |       Owner:  (none)
     Type:  feature request    |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Administration     |     Version:
 Severity:  normal             |  Resolution:
 Keywords:  2nd-opinion close  |     Focuses:
-------------------------------+------------------------------
Changes (by audrasjb):

 * keywords:   => 2nd-opinion close


Comment:

 Hello and thank you for this ticket,
 As the implementation age verification is completely dependent from the
 final website made with WordPress, I think it is the territory of plugins,
 not core.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65093#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 08:45:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 08:45:07 -0000
Subject: [wp-trac] [WordPress Trac] #65097: Add action to
 `WP_AI_Client_Prompt_Builder` for builder-level configuration injection
Message-ID: <051.4a07b9c878c59705f108440bf628f34b@wordpress.org>

#65097: Add action to `WP_AI_Client_Prompt_Builder` for builder-level configuration
injection
-----------------------------+-----------------------------------
 Reporter:  takshil          |      Owner:  (none)
     Type:  feature request  |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  AI               |    Version:
 Severity:  normal           |   Keywords:  2nd-opinion has-patch
  Focuses:                   |
-----------------------------+-----------------------------------
 == Problem ==

 Currently, model selection happens in one of two places:

 1. '''Inside the SDK / connector''' - provider-default model ordering. Its
 useful but provider-scoped, cannot express ''cross-provider'' preferences
 like "use OpenAI for text, Mistral for images."
 2. '''Inside each consumer plugin''' - hardcoded `using_model_preference(
 'gpt-5.4', 'claude-sonnet-4-6' )`. Fragmented, opaque to site owners, no
 shared coordination.

 There is no third place - no site-owner-controlled layer that applies
 across all consumer plugins. A standalone "preferences" plugin can store
 the user's choices but has no way to inject them into builders constructed
 elsewhere, because no construction time hook exists.


 == Proposed solution ==

 Add one action at the end of `WP_AI_Client_Prompt_Builder::__construct()`,
 immediately after the existing default-timeout block:

 {{{#!php
 <?php
 // In wp-includes/ai-client/class-wp-ai-client-prompt-builder.php

 /**
  * Fires after a prompt builder is constructed, before any caller
 chaining.
  *
  * Allows plugins to apply default configuration that callers can still
 override via subsequent
  * fluent method calls. Because this fires at construction, any chain
 applied
  * by the caller takes precedence per the SDK's first-match resolution.
  *
  * @since 7.x.0
  *
  * @param WP_AI_Client_Prompt_Builder $builder The newly constructed
 builder.
  * @param mixed                       $prompt  The initial prompt content.
  */
 do_action_ref_array( 'wp_ai_client_prompt_builder_init', array( $this,
 $prompt ) );
 }}}

 === Caller precedence is automatic ===

 {{{
 1. Core constructs builder
 2. wp_ai_client_default_request_timeout fires → sets timeout
 3. wp_ai_client_prompt_builder_init fires → preferences plugin chains
    ->using_model_preference('gpt-5.4', 'mistral-image-v1', ...)
 4. Builder returns to the caller
 5. Caller chains its own potentially by a plugin allowing user's
 preferences
    to be set with a UI->using_model_preference('claude-sonnet-4-6').
    Could be a separate plugin for now, I have some ideas.
 6. SDK's first-match resolution at generate_*() time picks the first model
    that (a) supports the requested capability and (b) has credentials.
    The caller's explicit preference wins because it's evaluated first.
 }}}

 == Why an Action? ==

 It comes down to what listeners will dominantly do:

 - Mutate via `->using_model_preference()` chains → action is the cleaner
 fit (no return tax, natural accumulation)
 - Replace/decorate the builder → filter is required

 Going towards `pre_get_posts` precedent. Core's go-to hook for "mutate a
 fluent/builder-like object" is an action, not a filter, precisely because
 filtering a stateful mutable object invites bugs. This is the closest
 analog I thought of in core. Though open to discussion for filter if the
 AI team prefers consistency with the existing two filters in this file

 == Discussion ==

 * Slack: WordPress.org `#core-ai`, thread starting 2026-04-17
 (https://wordpress.slack.com/archives/C08TJ8BPULS/p1776411977337179).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65097>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 08:45:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 08:45:57 -0000
Subject: [wp-trac] [WordPress Trac] #65097: Add action to
 `WP_AI_Client_Prompt_Builder` for builder-level configuration injection
In-Reply-To: <051.4a07b9c878c59705f108440bf628f34b@wordpress.org>
References: <051.4a07b9c878c59705f108440bf628f34b@wordpress.org>
Message-ID: <066.ababd1f8fdb7a7a37e9b8f99017a140b@wordpress.org>

#65097: Add action to `WP_AI_Client_Prompt_Builder` for builder-level configuration
injection
-----------------------------------+------------------------------
 Reporter:  takshil                |       Owner:  (none)
     Type:  feature request        |      Status:  new
 Priority:  normal                 |   Milestone:  Awaiting Review
Component:  AI                     |     Version:
 Severity:  normal                 |  Resolution:
 Keywords:  2nd-opinion has-patch  |     Focuses:
-----------------------------------+------------------------------
Changes (by takshil):

 * Attachment "wp-ai-client-prompt-builder-init.patch" added.

 Patch for the proposed action.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65097>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 09:04:04 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 09:04:04 -0000
Subject: [wp-trac] [WordPress Trac] #65093: Age Assurance Framework for
 WordPress
In-Reply-To: <054.2ca0427147e923c361f0b12823b2a91d@wordpress.org>
References: <054.2ca0427147e923c361f0b12823b2a91d@wordpress.org>
Message-ID: <069.6d6170634a365d4c62d35d5e43e367c9@wordpress.org>

#65093: Age Assurance Framework for WordPress
-------------------------------+------------------------------
 Reporter:  telizarose         |       Owner:  (none)
     Type:  feature request    |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Administration     |     Version:
 Severity:  normal             |  Resolution:
 Keywords:  2nd-opinion close  |     Focuses:
-------------------------------+------------------------------

Comment (by knutsp):

 Replying to [comment:1 audrasjb]:
 > As the implementation of age verification system is completely dependent
 from the final website made with WordPress, I think it is the territory of
 plugins, not core.

 That is exactly why WordPress could offer a framework, making
 compatibility and interoperability between plugins, regulations in
 different regions and verifcation systems and apps more robust.

 We still miss a content language framework and multi factor
 authentication, but we now have an AI framework and connectors for
 different plugins to use as a common base.

 Implementations, esecially user facing settings, will be plugin territory,
 useful frameworks with some basic APIs, especially made early, are real
 benefits, in this case for the near future.

 Add EU regulations to this feature request, embrace, explore the
 possibilities and start designing it. This could be be part of what is
 needed to "make WP great again", devs to say "look to WordPress".

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65093#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 09:19:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 09:19:21 -0000
Subject: [wp-trac] [WordPress Trac] #65095: Introduce Application Mode
 (DISABLE_BLOG) to disable post/blog features for secure non-CMS usage
In-Reply-To: <057.e392633509a2d7b062101e1eada86e22@wordpress.org>
References: <057.e392633509a2d7b062101e1eada86e22@wordpress.org>
Message-ID: <072.1ced507b0f839aa5a187a270b7b09f33@wordpress.org>

#65095: Introduce Application Mode (DISABLE_BLOG) to disable post/blog features for
secure non-CMS usage
-------------------------------------------------+-------------------------
 Reporter:  dramitstalbot                        |       Owner:  (none)
     Type:  feature request                      |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  General                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  feature-request needs-design-        |     Focuses:  rest-api,
  feedback                                       |  performance
-------------------------------------------------+-------------------------

Comment (by knutsp):

 Nice. Also add basic Progressive Web App (PWA) functionality, and
 WordPress will be a great framwork for making well designed web
 applications, outside wp-admin, not just a publishing system (CMS).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65095#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 09:37:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 09:37:57 -0000
Subject: [wp-trac] [WordPress Trac] #65084: Update error message for
 disallowed username characters
In-Reply-To: <049.08ea48590412276562d442dabf255033@wordpress.org>
References: <049.08ea48590412276562d442dabf255033@wordpress.org>
Message-ID: <064.67426217ddb8c52fb5afa05541d6b2fe@wordpress.org>

#65084: Update error message for disallowed username characters
-------------------------+------------------------------
 Reporter:  Marc4        |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  ui-copy
-------------------------+------------------------------

Comment (by jigarkahar):

 == Test Report
 === Description
 ❌ This report validates whether the indicated patch not works as
 expected.


 Patch tested: https://github.com/WordPress/wordpress-develop/pull/11590

 === Environment
 - WordPress: 7.1-alpha-20260416.170638
 - PHP: 7.4.33
 - Server: PHP.wasm
 - Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
 - Browser: Chrome 147.0.0.0
 - OS: Windows 10/11
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None activated
 - Plugins:
   * Test Reports 1.2.1

 === Steps to Test
 1: Go to WordPress admin panel (/wp-admin)
 2: Navigate to Users → Add New
 3: Enter username:MarÇ
 4: Fill required fields
 5: Click Add New User

 === Actual Results
 1.  ❌ Issue notresolved with patch.
 2.  Still this is same message. not changed.

 === Supplemental Artifacts
 https://tinyurl.com/29vhvnfl

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65084#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 09:39:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 09:39:55 -0000
Subject: [wp-trac] [WordPress Trac] #65084: Update error message for
 disallowed username characters
In-Reply-To: <049.08ea48590412276562d442dabf255033@wordpress.org>
References: <049.08ea48590412276562d442dabf255033@wordpress.org>
Message-ID: <064.584e634843061489c659e09dd646ba33@wordpress.org>

#65084: Update error message for disallowed username characters
-----------------------------------------+------------------------------
 Reporter:  Marc4                        |       Owner:  (none)
     Type:  enhancement                  |      Status:  new
 Priority:  normal                       |   Milestone:  Awaiting Review
Component:  General                      |     Version:
 Severity:  normal                       |  Resolution:
 Keywords:  has-patch reporter-feedback  |     Focuses:  ui-copy
-----------------------------------------+------------------------------
Changes (by jigarkahar):

 * keywords:  has-patch => has-patch reporter-feedback


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65084#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 09:50:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 09:50:14 -0000
Subject: [wp-trac] [WordPress Trac] #65094: AI: Prompt construction
 fails with fatal error when wp_ai_client_default_request_timeout filter
 returns negative number
In-Reply-To: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
References: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
Message-ID: <070.f5bd75d8f077abfe120ecc0595d5c2f3@wordpress.org>

#65094: AI: Prompt construction fails with fatal error when
wp_ai_client_default_request_timeout filter returns negative number
--------------------------------------+--------------------------
 Reporter:  westonruter               |       Owner:  westonruter
     Type:  defect (bug)              |      Status:  assigned
 Priority:  normal                    |   Milestone:  7.0
Component:  AI                        |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+--------------------------

Comment (by darshitrajyaguru97):

 == Patch Testing & Review ==

 I tested the latest patch locally and reviewed the changes in detail.

 === **Environment ===
 * WordPress: 7.0 RC2
 * PHP: 8.3.x
 * Server: Nginx
 * Browser: Chrome
 * OS: Windows

 === **Summary ===
 The patch successfully prevents a fatal error when invalid values are
 returned via the
 `wp_ai_client_default_request_timeout` filter.

 Previously, returning a negative value or invalid type would propagate
 into
 `RequestOptions::validateTimeout()` and throw an uncaught exception,
 resulting in a fatal error.
 With this patch, the value is validated earlier and handled gracefully.

 === **Testing Performed ===

 I tested multiple scenarios:

 * Returning `-1`
   → Falls back to default `30.0`
   → `_doing_it_wrong()` triggered
   → No fatal error ✅

 * Returning `45.5`
   → Value applied correctly ✅

 * Returning `null`
   → Timeout disabled (`null`) as expected ✅

 * Returning invalid type (e.g., array)
   → Falls back to default
   → `_doing_it_wrong()` triggered ✅

 All cases behaved as expected and no regressions were observed.

 === **Code Review Notes ===

 * Validation logic in `WP_AI_Client_Prompt_Builder::__construct()` is
 solid:
   * Accepts non-negative numeric values
   * Explicitly supports `null`
   * Safely falls back for invalid input

 * Use of `_doing_it_wrong()` aligns well with WordPress core practices
   and avoids hard failures inside filters

 * Switching to `float` improves flexibility and resolves PHPStan level 10
 issues

 * Additional improvements:
   * Proper return type declarations
   * Missing imports added
   * Native property typing applied

 === **Unit Tests ===

 New PHPUnit tests provide good coverage:
 * Valid float override
 * `null` handling
 * Negative value rejection
 * Invalid type rejection

 All tests pass locally.

 === **Feedback ===

 This is a well-rounded fix that:
 * Improves resilience of the AI client
 * Prevents fatal errors in edge cases
 * Enhances developer experience with clear feedback

 The approach is consistent with core standards.

 === **Conclusion ===

 **Patch tested successfully — works as expected.**
 No issues found during testing in this environment; needs to be tested
 across different environments as well for better clarity.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65094#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 16:46:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 16:46:12 -0000
Subject: [wp-trac] [WordPress Trac] #64225: Test tool and unit test
 improvements for 7.0
In-Reply-To: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
References: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
Message-ID: <066.09a8706b27235f6fa62af25ac2bb3f6c@wordpress.org>

#64225: Test tool and unit test improvements for 7.0
--------------------------------------+---------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  task (blessed)            |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by SergeyBiryukov):

 In [changeset:"62245" 62245]:
 {{{
 #!CommitTicketReference repository="" revision="62245"
 Tests: Use a data provider in a `WP_Block_Type_Registry` test for invalid
 block names.

 Includes adding missing `@covers` tags.

 Follow-up to [43742], [51491].

 Props sagardeshmukh.
 See #64225.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64225#comment:69>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 18:00:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 18:00:39 -0000
Subject: [wp-trac] [WordPress Trac] #65098: get_site_icon_url() returns
 empty string even when fallback is defined,
 breaking wp-embed-site-icon in the_embed_site_title()
Message-ID: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>

#65098: get_site_icon_url() returns empty string even when fallback is defined,
breaking wp-embed-site-icon in the_embed_site_title()
--------------------------+-----------------------------
 Reporter:  pontocinza    |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Embeds        |    Version:  6.9.4
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 In `wp-includes/embed.php`, the function `the_embed_site_title()` calls
 `get_site_icon_url()` twice, passing a fallback URL as the second
 argument:

     esc_url( get_site_icon_url( 32, includes_url( 'images/w-logo-blue.png'
 ) ) ),
     esc_url( get_site_icon_url( 64, includes_url( 'images/w-logo-blue.png'
 ) ) ),

 Despite a Site Icon being properly defined in Appearance → Customize →
 Site
 Identity (a 512×512px image), `get_site_icon_url()` returns an empty
 string,
 ignoring the fallback entirely. This results in a broken icon in all
 oEmbed
 cards rendered via `the_embed_site_title()`.

 The generated HTML is:

     <img src="" srcset=" 2x" width="32" height="32" alt="" class="wp-
 embed-site-icon">

 Note that `src` is empty and `srcset` contains only ` 2x`, which causes
 browsers to interpret it as a relative URL request to `/embed/2x`,
 returning
 a 403 error.

 The WordPress logo fallback (`w-logo-blue.png`) is also never used,
 contrary
 to the documented behavior of `get_site_icon_url()`.

 == Steps to reproduce ==

 1. Set a Site Icon in Appearance → Customize → Site Identity (512×512px
 image)
 2. Create a post
 3. On another page, add a Media & Text block or an Embed block pointing to
    that post's URL
 4. Visit the page — the site icon in the oEmbed card footer will be broken
 5. Inspect the element: `src=""` and `srcset=" 2x"`

 == Expected behavior ==

 The site icon should display correctly, or — if unavailable — the
 WordPress
 logo fallback (`w-logo-blue.png`) should be used instead.

 == Actual behavior ==

 `get_site_icon_url()` returns an empty string regardless of the defined
 icon
 or fallback, producing a malformed `<img>` tag with empty `src` and
 `srcset`.

 == Workaround ==

 The following filter removes the broken icon from the embed footer:

     add_filter('embed_site_title_html', function($site_title) {
         return preg_replace('/<img[^>]+class="wp-embed-site-
 icon"[^>]*>/i', '', $site_title);
     });

 == Environment ==

 - WordPress 6.9.4
 - PHP (production server)
 - Site Icon defined, 512×512px, uploaded via Customizer
 - APCu object cache active
 - Cloudflare in front of the site

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65098>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 18:05:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 18:05:29 -0000
Subject: [wp-trac] [WordPress Trac] #65098: get_site_icon_url() returns
 empty string even when fallback is defined,
 breaking wp-embed-site-icon in the_embed_site_title()
In-Reply-To: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
References: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
Message-ID: <069.8af883f51dcc44bd23f85a5bb5c8d7f4@wordpress.org>

#65098: get_site_icon_url() returns empty string even when fallback is defined,
breaking wp-embed-site-icon in the_embed_site_title()
--------------------------+------------------------------
 Reporter:  pontocinza    |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Embeds        |     Version:  6.9.4
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Changes (by pontocinza):

 * Attachment "bug-2026-04-18_133557.webp" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65098>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 18:34:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 18:34:57 -0000
Subject: [wp-trac] [WordPress Trac] #16133: Pagination issue with tag
 "rss"
In-Reply-To: <050.89a7d168e38e93eff097f4ae47eefd38@wordpress.org>
References: <050.89a7d168e38e93eff097f4ae47eefd38@wordpress.org>
Message-ID: <065.43e34ee6500f8ccd127f8a019d79d11e@wordpress.org>

#16133: Pagination issue with tag "rss"
------------------------------------+---------------------
 Reporter:  paolal                  |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:
Component:  Canonical               |     Version:  3.0
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:
------------------------------------+---------------------
Changes (by alechgm):

 * keywords:  has-patch needs-testing dev-feedback => has-patch dev-feedback


Comment:

 I have tested this patch on a fresh WordPress core development environment
 (version 7.1.0-alpha) using Docker.

 Environment details:
 - PHP: 8.3.30
 - OS: Windows (WSL2)
 - Environment: Docker Desktop (WP-Env/Local-env)

 Steps taken:
 1. Created 13 posts tagged with "RSS" (slug: "rss").
 2. Confirmed that navigating to `/tag/rss/page/2/` resulted in a 404 error
 before applying the patch.
 3. Applied the patch to `wp-includes/canonical.php` and flushed
 permalinks.
 4. Verified that `/tag/rss/page/2/` now loads correctly and displays the
 expected posts.

 The patch correctly resolves the pagination collision when a taxonomy term
 is named "rss".

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/16133#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 18:48:42 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 18:48:42 -0000
Subject: [wp-trac] [WordPress Trac] #65094: AI: Prompt construction
 fails with fatal error when wp_ai_client_default_request_timeout filter
 returns negative number
In-Reply-To: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
References: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
Message-ID: <070.1c759834ada8b5370c2bcb389c9466ef@wordpress.org>

#65094: AI: Prompt construction fails with fatal error when
wp_ai_client_default_request_timeout filter returns negative number
--------------------------------------+--------------------------
 Reporter:  westonruter               |       Owner:  westonruter
     Type:  defect (bug)              |      Status:  assigned
 Priority:  normal                    |   Milestone:  7.0
Component:  AI                        |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+--------------------------

Comment (by adrmf25):

 Tested this issue in a local WordPress development environment.

 Steps:
 - Set up local WordPress Core
 - Applied the wp_ai_client_default_request_timeout filter
 - Initially placed it in wp-config.php, which caused a fatal error
 (add_filter not available at that stage)
 - Moved the filter to functions.php, where WordPress is fully loaded

 Result:
 - No fatal errors when applied correctly
 - WordPress runs normally

 Conclusion:
 The behavior works as expected when the filter is used in the proper
 context.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65094#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 18:52:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 18:52:53 -0000
Subject: [wp-trac] [WordPress Trac] #65094: AI: Prompt construction
 fails with fatal error when wp_ai_client_default_request_timeout filter
 returns negative number
In-Reply-To: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
References: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
Message-ID: <070.f2bc840ff25578a1ebdb98632198e6f9@wordpress.org>

#65094: AI: Prompt construction fails with fatal error when
wp_ai_client_default_request_timeout filter returns negative number
--------------------------------------+--------------------------
 Reporter:  westonruter               |       Owner:  westonruter
     Type:  defect (bug)              |      Status:  assigned
 Priority:  normal                    |   Milestone:  7.0
Component:  AI                        |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+--------------------------

Comment (by jarodortegaaraya):

 Patch Testing Report – Ticket #65094

 I tested the patch locally in a WordPress 7.0 environment.

 Summary:
 The patch successfully prevents a fatal error when invalid values are
 returned via the wp_ai_client_default_request_timeout filter. Previously,
 invalid values (e.g., -1) caused an uncaught exception in
 RequestOptions::validateTimeout().

 Testing Performed:

 Returning -1 → Falls back to default (30) → No fatal error ✅
 Returning 45.5 → Value applied correctly ✅
 Returning null → Timeout disabled as expected ✅
 Returning invalid type (array) → Falls back to default → No fatal error ✅

 Additional Observation:
 A PHP warning was encountered during testing due to an undefined variable
 ($default_timeout) after applying the patch manually. This appears to be
 related to the local modification rather than the intended patch behavior.

 Conclusion:
 The patch works as expected. It properly validates the timeout value,
 prevents fatal errors, and handles invalid input gracefully.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65094#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 19:00:20 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 19:00:20 -0000
Subject: [wp-trac] [WordPress Trac] #65098: get_site_icon_url() returns
 empty string even when fallback is defined,
 breaking wp-embed-site-icon in the_embed_site_title()
In-Reply-To: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
References: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
Message-ID: <069.e7acd2c5d4e4aeffa0d21fb132b5fa30@wordpress.org>

#65098: get_site_icon_url() returns empty string even when fallback is defined,
breaking wp-embed-site-icon in the_embed_site_title()
--------------------------+------------------------------
 Reporter:  pontocinza    |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Embeds        |     Version:  6.9.4
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Changes (by pontocinza):

 * Attachment "bug-2026-04-18_155647.webp" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65098>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 19:17:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 19:17:16 -0000
Subject: [wp-trac] [WordPress Trac] #13822: Menu items that get
 unpublished still appear
In-Reply-To: <049.50ba02285154a781d7c1ac6bee1a4bf1@wordpress.org>
References: <049.50ba02285154a781d7c1ac6bee1a4bf1@wordpress.org>
Message-ID: <064.acdd8698fc8a2f13e49a7dc87b362b8f@wordpress.org>

#13822: Menu items that get unpublished still appear
-------------------------------------------------+-------------------------
 Reporter:  nacin                                |       Owner:  nacin
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Menus                                |     Version:  3.0
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-test-info has-    |     Focuses:
  patch                                          |
-------------------------------------------------+-------------------------

Comment (by alechgm):

 I have tested this patch on a fresh WordPress core development environment
 using Docker.

 Environment details:
 - WordPress Version: 7.1.0-alpha
 - PHP: 8.3.30
 - Theme: Twenty Twenty (Classic Theme)
 - OS: Windows (WSL2)

 Steps taken:
 1. Created a new page named "Ghost Page" and set it to 'publish'.
 2. Created a custom menu, added "Ghost Page" to it, and assigned it to the
 'Primary' location.
 3. Changed "Ghost Page" status to 'Draft'.
 4. Verified that the menu item remained visible on the frontend (bug
 confirmed).
 5. Applied the patch to `src/wp-includes/nav-menu.php`.
 6. Verified that the "Ghost Page" menu item is now correctly hidden from
 the frontend for non-logged-in users.

 The patch works as expected and prevents unpublished content from
 cluttering the navigation menus.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/13822#comment:61>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 19:59:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 19:59:48 -0000
Subject: [wp-trac] [WordPress Trac] #65098: get_site_icon_url() returns
 empty string even when fallback is defined,
 breaking wp-embed-site-icon in the_embed_site_title()
In-Reply-To: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
References: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
Message-ID: <069.c50b44eac8f7d21d1c282a6681e83924@wordpress.org>

#65098: get_site_icon_url() returns empty string even when fallback is defined,
breaking wp-embed-site-icon in the_embed_site_title()
--------------------------+---------------------
 Reporter:  pontocinza    |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.1
Component:  Embeds        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+---------------------
Changes (by sabernhardt):

 * keywords:   => needs-patch
 * version:  6.9.4 =>
 * milestone:  Awaiting Review => 7.1


Old description:

> In `wp-includes/embed.php`, the function `the_embed_site_title()` calls
> `get_site_icon_url()` twice, passing a fallback URL as the second
> argument:
>
>     esc_url( get_site_icon_url( 32, includes_url( 'images/w-logo-
> blue.png' ) ) ),
>     esc_url( get_site_icon_url( 64, includes_url( 'images/w-logo-
> blue.png' ) ) ),
>
> Despite a Site Icon being properly defined in Appearance → Customize →
> Site
> Identity (a 512×512px image), `get_site_icon_url()` returns an empty
> string,
> ignoring the fallback entirely. This results in a broken icon in all
> oEmbed
> cards rendered via `the_embed_site_title()`.
>
> The generated HTML is:
>
>     <img src="" srcset=" 2x" width="32" height="32" alt="" class="wp-
> embed-site-icon">
>
> Note that `src` is empty and `srcset` contains only ` 2x`, which causes
> browsers to interpret it as a relative URL request to `/embed/2x`,
> returning
> a 403 error.
>
> The WordPress logo fallback (`w-logo-blue.png`) is also never used,
> contrary
> to the documented behavior of `get_site_icon_url()`.
>
> == Steps to reproduce ==
>
> 1. Set a Site Icon in Appearance → Customize → Site Identity (512×512px
> image)
> 2. Create a post
> 3. On another page, add a Media & Text block or an Embed block pointing
> to
>    that post's URL
> 4. Visit the page — the site icon in the oEmbed card footer will be
> broken
> 5. Inspect the element: `src=""` and `srcset=" 2x"`
>
> == Expected behavior ==
>
> The site icon should display correctly, or — if unavailable — the
> WordPress
> logo fallback (`w-logo-blue.png`) should be used instead.
>
> == Actual behavior ==
>
> `get_site_icon_url()` returns an empty string regardless of the defined
> icon
> or fallback, producing a malformed `<img>` tag with empty `src` and
> `srcset`.
>
> == Workaround ==
>
> The following filter removes the broken icon from the embed footer:
>
>     add_filter('embed_site_title_html', function($site_title) {
>         return preg_replace('/<img[^>]+class="wp-embed-site-
> icon"[^>]*>/i', '', $site_title);
>     });
>
> == Environment ==
>
> - WordPress 6.9.4
> - PHP (production server)
> - Site Icon defined, 512×512px, uploaded via Customizer
> - APCu object cache active
> - Cloudflare in front of the site

New description:

 In `wp-includes/embed.php`, the function `the_embed_site_title()` calls
 `get_site_icon_url()` twice, passing a fallback URL as the second
 argument:

 {{{
     esc_url( get_site_icon_url( 32, includes_url( 'images/w-logo-blue.png'
 ) ) ),
     esc_url( get_site_icon_url( 64, includes_url( 'images/w-logo-blue.png'
 ) ) ),
 }}}

 Despite a Site Icon being properly defined in Appearance → Customize →
 Site
 Identity (a 512×512px image), `get_site_icon_url()` returns an empty
 string,
 ignoring the fallback entirely. This results in a broken icon in all
 oEmbed
 cards rendered via `the_embed_site_title()`.

 The generated HTML is:
 {{{
     <img src="" srcset=" 2x" width="32" height="32" alt="" class="wp-
 embed-site-icon">
 }}}

 Note that `src` is empty and `srcset` contains only ` 2x`, which causes
 browsers to interpret it as a relative URL request to `/embed/2x`,
 returning
 a 403 error.

 The WordPress logo fallback (`w-logo-blue.png`) is also never used,
 contrary
 to the documented behavior of `get_site_icon_url()`.

 == Steps to reproduce ==

 1. Set a Site Icon in Appearance → Customize → Site Identity (512×512px
 image)
 2. Create a post
 3. On another page, add a Media & Text block or an Embed block pointing to
    that post's URL
 4. Visit the page — the site icon in the oEmbed card footer will be broken
 5. Inspect the element: `src=""` and `srcset=" 2x"`

 == Expected behavior ==

 The site icon should display correctly, or — if unavailable — the
 WordPress
 logo fallback (`w-logo-blue.png`) should be used instead.

 == Actual behavior ==

 `get_site_icon_url()` returns an empty string regardless of the defined
 icon
 or fallback, producing a malformed `<img>` tag with empty `src` and
 `srcset`.

 == Workaround ==

 The following filter removes the broken icon from the embed footer:
 {{{
     add_filter('embed_site_title_html', function($site_title) {
         return preg_replace('/<img[^>]+class="wp-embed-site-
 icon"[^>]*>/i', '', $site_title);
     });
 }}}

 == Environment ==

 - WordPress 6.9.4
 - PHP (production server)
 - Site Icon defined, 512×512px, uploaded via Customizer
 - APCu object cache active
 - Cloudflare in front of the site

--

Comment:

 Hi and welcome to WordPress Core Trac!

 I think you might have a plugin or theme that uses the `get_site_icon_url`
 filter. I can break the site icon image in embeds by adding this to a
 custom plugin:
 {{{
 add_filter( 'get_site_icon_url', '__return_empty_string' );
 }}}

 The filter runs at the end of the `get_site_icon_url()` function, so the
 fallback WordPress logo would not override that.

 The `atom_site_icon()` and `wp_site_icon()` functions check the value
 before trying to print it, and a similar condition probably could fit
 `the_embed_site_title()`.
 {{{
 function atom_site_icon() {
         $url = get_site_icon_url( 32 );
         if ( $url ) {
                 echo '<icon>' . convert_chars( $url ) . "</icon>\n";
         }
 }
 }}}

 {{{
 function wp_site_icon() {
         if ( ! has_site_icon() && ! is_customize_preview() ) {
                 return;
         }

         $meta_tags = array();
         $icon_32   = get_site_icon_url( 32 );
         if ( empty( $icon_32 ) && is_customize_preview() ) {
                 $icon_32 = '/favicon.ico'; // Serve default favicon URL in
 customizer so element can be updated for preview.
         }
         if ( $icon_32 ) {
                 $meta_tags[] = sprintf( '<link rel="icon" href="%s"
 sizes="32x32" />', esc_url( $icon_32 ) );
         }
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65098#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 20:15:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 20:15:55 -0000
Subject: [wp-trac] [WordPress Trac] #65098: get_site_icon_url() returns
 empty string even when fallback is defined,
 breaking wp-embed-site-icon in the_embed_site_title()
In-Reply-To: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
References: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
Message-ID: <069.c35da008a5d82313a6831c85d175151d@wordpress.org>

#65098: get_site_icon_url() returns empty string even when fallback is defined,
breaking wp-embed-site-icon in the_embed_site_title()
--------------------------+---------------------
 Reporter:  pontocinza    |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.1
Component:  Embeds        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+---------------------

Comment (by sabernhardt):

 Other functions:
 - `site_icon_url()`, `do_favicon()` and the multisite function
 `wp_admin_bar_my_sites_menu()` also use output from `get_site_icon_url()`
 without checking the value first.
 - `WP_REST_Server::add_site_icon_to_index()` assigns a URL from
 `get_site_icon_url()`, but I do not know if that is a (potential) problem.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65098#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 21:11:20 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 21:11:20 -0000
Subject: [wp-trac] [WordPress Trac] #65098: get_site_icon_url() returns
 empty string even when fallback is defined,
 breaking wp-embed-site-icon in the_embed_site_title()
In-Reply-To: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
References: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
Message-ID: <069.da9204bcf3281e92ea77dab129088b1a@wordpress.org>

#65098: get_site_icon_url() returns empty string even when fallback is defined,
breaking wp-embed-site-icon in the_embed_site_title()
--------------------------+---------------------
 Reporter:  pontocinza    |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.1
Component:  Embeds        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+---------------------

Comment (by pontocinza):

 Thank you for the diagnosis.

 The active theme is Twenty Twenty (unmodified). I reviewed the plugin
 list, and none of them are SEO, favicon, or icon-related plugins that
 would typically use 'get_site_icon_url'. I also fully reviewed the source
 code of my own custom SEO plugin, which does not touch that filter. WPCode
 snippets were checked; nothing related to site icon or favicon. The custom
 CSS only covers layout, typography, and logo sizing. No interference with
 icons.

 Additionally, I can pinpoint when the issue started: it appeared today,
 after I replaced a PNG for a WebP image (and it was not the site icon
 file). Before that change, the embed icon was displaying correctly. No
 plugins were added, removed, or modified around that time.

 This suggests the problem may be triggered by WebP format support (or lack
 thereof) in one of the functions you listed rather than a filter returning
 an empty string.

 Could this be investigated from the Core side? The defensive check you
 proposed for 'the_embed_site_title()' still seems like the right fix, but
 the root cause in my case appears to be format-related, not filter-
 related.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65098#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 21:21:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 21:21:14 -0000
Subject: [wp-trac] [WordPress Trac] #64792: Consider changing code tags
 to regular text for dimension values in "Site Icon" help text
In-Reply-To: <051.b7b6985ddc2c1f63953335ef6c335c0e@wordpress.org>
References: <051.b7b6985ddc2c1f63953335ef6c335c0e@wordpress.org>
Message-ID: <066.3b3b6c961a3d0cad12b7d7155c5e62d5@wordpress.org>

#64792: Consider changing code tags to regular text for dimension values in "Site
Icon" help text
-------------------------------------------------+-------------------------
 Reporter:  juanfra                              |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  7.1
Component:  Administration                       |     Version:  6.5
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-patch commit      |     Focuses:
  has-screenshots                                |
-------------------------------------------------+-------------------------

Comment (by kevinrobles):

 Tested on Windows 11 using WordPress Studio with WordPress 6.9.4.

 Reviewed the Site Icon help text under Settings > General.

 The dimension values are displayed as regular text ("512 by 512 pixels"),
 which is clear and readable. The issue described in the ticket appears
 resolved.

 No additional issues found during testing.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64792#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 22:41:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 22:41:53 -0000
Subject: [wp-trac] [WordPress Trac] #64789: Security audit for API key
 storage on the Connectors screen
In-Reply-To: <050.2dc2adeded3d033a30689e22ac0c9ef2@wordpress.org>
References: <050.2dc2adeded3d033a30689e22ac0c9ef2@wordpress.org>
Message-ID: <065.0038bfbf4df0c0ecc3e20124eb13fde2@wordpress.org>

#64789: Security audit for API key storage on the Connectors screen
-------------------------------------+-------------------------------------
 Reporter:  gziolo                   |       Owner:  (none)
     Type:  task (blessed)           |      Status:  new
 Priority:  normal                   |   Milestone:  7.0
Component:  Security                 |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  2nd-opinion dev-         |     Focuses:  ui, administration,
  feedback                           |  rest-api, privacy
-------------------------------------+-------------------------------------
Changes (by dpknauss):

 * keywords:   => 2nd-opinion dev-feedback
 * focuses:   => ui, administration, rest-api, privacy


Comment:

 I’ve been following this discussion while researching and testing security
 issues around Connectors, and I wanted to add one observation that seems
 worth separating from the read-side masking discussion, which has already
 been covered well. I’ve collected some of my notes and test results here
 in case they are useful as supporting context: [https://github.com/dknauss
 /wp-sudo/blob/main/docs/connectors-api-reference.md Connectors API
 reference and security notes].

 **What stands out to me is the write side.** In WordPress 7.0 RC2,
 connector credentials are ordinary REST-writable settings behind the broad
 {{{manage_options}}} gate. Database-backed keys can be replaced through
 {{{POST /wp/v2/settings}}}, and invalid AI-provider keys are cleared
 server-side while the raw REST write still returns {{{200 OK}}}. The stock
 Connectors UI does mitigate some of the UX risk: it surfaces invalid-save
 errors and marks env/constant-backed connectors as externally configured
 and read-only, but the underlying model still seems to treat billing-
 capable, prompt-routing credentials more like generic settings than like
 other high-consequence secrets.

 That feels like a write-side integrity / governance gap rather than a
 read-side disclosure issue. There is no connector-specific capability
 boundary, no connector-specific change signal or audit hook, and no built-
 in notification when a key is replaced. For same-provider swaps, the
 provider hostname does not even change; what changes is whose account
 receives the requests, who gets billed, and who can inspect the prompts.

 Core already distinguishes some credential or access-granting changes from
 ordinary settings writes. Connector credentials seem closer to that
 category than to routine site settings, especially given that AI keys can
 carry both billing consequences and prompt-visibility consequences.

 If this is considered in scope for the current ticket, a few small
 additive mitigations seem like they could help a lot:

 * Store/display a fingerprint alongside each key.
 * Fire a connector-specific change hook carrying old/new fingerprint,
 actor, and timestamp
 * Optionally notify administrators when a key is changed.
 * Introduce a narrower capability such as {{{manage_connectors}}}.
 * Preserve the existing env/constant source indicator and make database-
 backed provenance equally explicit.

 If that is out of scope here, I’d be happy to open a separate ticket
 focused specifically on credential rotation visibility, auditability, and
 capability scoping.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64789#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 18 23:53:34 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 18 Apr 2026 23:53:34 -0000
Subject: [wp-trac] [WordPress Trac] #65093: Age Assurance Framework for
 WordPress
In-Reply-To: <054.2ca0427147e923c361f0b12823b2a91d@wordpress.org>
References: <054.2ca0427147e923c361f0b12823b2a91d@wordpress.org>
Message-ID: <069.67e5cb158b23448611d0cdf9338741f1@wordpress.org>

#65093: Age Assurance Framework for WordPress
-----------------------------+-------------------------
 Reporter:  telizarose       |       Owner:  (none)
     Type:  feature request  |      Status:  closed
 Priority:  normal           |   Milestone:
Component:  Administration   |     Version:
 Severity:  normal           |  Resolution:  maybelater
 Keywords:                   |     Focuses:
-----------------------------+-------------------------
Changes (by jorbin):

 * keywords:  2nd-opinion close =>
 * status:  new => closed
 * resolution:   => maybelater
 * milestone:  Awaiting Review =>


Comment:

 Howdy @telizarose, welcome to WordPress Core Trac!

 I completely agree with @audrasjb that this is plugin territory. In the
 near term (and possibly long term), the overwhelming majority of websites
 would not use this. If a plugin (or plugins) show that this is something
 that many websites want, I think it would be worth revisiting, hence the
 resolution of `maybelater`.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65093#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 19 03:28:00 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 19 Apr 2026 03:28:00 -0000
Subject: [wp-trac] [WordPress Trac] #65095: Introduce Application Mode
 (DISABLE_BLOG) to disable post/blog features for secure non-CMS usage
In-Reply-To: <057.e392633509a2d7b062101e1eada86e22@wordpress.org>
References: <057.e392633509a2d7b062101e1eada86e22@wordpress.org>
Message-ID: <072.7fe7b6b20a06ab0b180ca0cd4810aaa7@wordpress.org>

#65095: Introduce Application Mode (DISABLE_BLOG) to disable post/blog features for
secure non-CMS usage
-------------------------------------------------+-------------------------
 Reporter:  dramitstalbot                        |       Owner:  (none)
     Type:  feature request                      |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  General                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  feature-request needs-design-        |     Focuses:  rest-api,
  feedback                                       |  performance
-------------------------------------------------+-------------------------

Comment (by dramitstalbot):

 Thank you @joshuadnelson — really appreciate the response and willingness
 to explore this in core.

 I reviewed the Disable Blog plugin, and it aligns closely with the
 direction I had in mind. However, from a framework perspective, I believe
 having a native core-level flag would be more reliable and secure,
 especially for applications in regulated domains like healthcare.

 In my HMIS use case, WordPress is used strictly as an application
 framework, where:

 * No post types are required
 * REST endpoints for posts are unnecessary
 * Minimizing attack surface is critical

 I’d be happy to help with:

 * Testing edge cases
 * Identifying which components can be conditionally skipped
 * Providing real-world constraints from healthcare deployments

 @knutsp — I completely agree regarding Progressive Web App (PWA)
 functionality. In fact, combining an “Application Mode” with basic PWA
 support (manifest + service worker hooks) could make WordPress a very
 strong foundation for modern web applications beyond CMS use.

 Perhaps a phased approach could work:

 1. Application Mode (disable blog features)
 2. Optional PWA bootstrap support in core

 Happy to collaborate further and help move this forward.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65095#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 19 13:58:42 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 19 Apr 2026 13:58:42 -0000
Subject: [wp-trac] [WordPress Trac] #65099: Fix: Only auto register settings
 if the plugin the connector references is installed and active
Message-ID: <060.0b8a8e3426646ee12db1e6e829f3d840@wordpress.org>

#65099: Fix: Only auto register settings if the plugin the connector references is
installed and active
------------------------------+-----------------------------
 Reporter:  jorgefilipecosta  |      Owner:  (none)
     Type:  defect (bug)      |     Status:  new
 Priority:  normal            |  Milestone:  Awaiting Review
Component:  General           |    Version:  trunk
 Severity:  normal            |   Keywords:  has-patch
  Focuses:                    |
------------------------------+-----------------------------
 `_wp_register_default_connector_settings()` in
 `src/wp-includes/connectors.php` is hooked to `init` (priority `20`) and
 walks
 every connector returned by `wp_get_connectors()`. For each connector that
 declares `authentication.method = 'api_key'` and an
 `authentication.setting_name`, it calls `register_setting( 'connectors', …
 )`
 so the setting is registered and available.

 Before this change, the only gate applied to non-AI connector types was
 that the setting had not already been registered. In practice this meant:

 1. A connector for plugin B registered by another plugin (plugin A) would
 have its API key setting auto-registered even when the '''owning service
 plugin was not
    installed or not active'''.
 2. The "orphan" setting then appeared in the `/wp-json/wp/v2/settings`
    response for a service that could not actually consume them.
 3. For `ai_provider` connectors this was already handled — the function
    skipped providers that the AI Client registry did not know about — but
    the equivalent guard was missing for every other connector type.

 The root cause is that the non-AI branch had no mechanism to ask the
 owning
 plugin "are you actually here?" before exposing the setting.


 Uses is_active connector proposed by @iamadisingh at
 https://core.trac.wordpress.org/ticket/65020.
 PR https://github.com/WordPress/wordpress-develop/pull/11565.

 ** Testing **

 Verify the connectors page works as before.
 Verify the unit tests pass.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65099>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 19 15:24:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 19 Apr 2026 15:24:56 -0000
Subject: [wp-trac] [WordPress Trac] #65097: Add action to
 `WP_AI_Client_Prompt_Builder` for builder-level configuration injection
In-Reply-To: <051.4a07b9c878c59705f108440bf628f34b@wordpress.org>
References: <051.4a07b9c878c59705f108440bf628f34b@wordpress.org>
Message-ID: <066.46c0b38558499ecfe960b1bf4285738a@wordpress.org>

#65097: Add action to `WP_AI_Client_Prompt_Builder` for builder-level configuration
injection
-----------------------------------+------------------------------
 Reporter:  takshil                |       Owner:  (none)
     Type:  feature request        |      Status:  new
 Priority:  normal                 |   Milestone:  Awaiting Review
Component:  AI                     |     Version:
 Severity:  normal                 |  Resolution:
 Keywords:  2nd-opinion has-patch  |     Focuses:
-----------------------------------+------------------------------
Changes (by sachinrajcp123):

 * Attachment "65097.patch" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65097>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 19 17:18:52 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 19 Apr 2026 17:18:52 -0000
Subject: [wp-trac] [WordPress Trac] #65090: Missing escaping for dynamic
 link text
In-Reply-To: <055.eacae8cd344dccf3a5cca1aa8300c6f2@wordpress.org>
References: <055.eacae8cd344dccf3a5cca1aa8300c6f2@wordpress.org>
Message-ID: <070.d93616774f57beec73f78eb4d8ae8432@wordpress.org>

#65090: Missing escaping for dynamic link text
-----------------------------------+-------------------------------
 Reporter:  maheshpatel            |       Owner:  (none)
     Type:  defect (bug)           |      Status:  new
 Priority:  normal                 |   Milestone:  Awaiting Review
Component:  General                |     Version:
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |     Focuses:  coding-standards
-----------------------------------+-------------------------------

Comment (by maheshpatel):

 @johnbillion Thanks for the clarification.

 Understood — I’ll keep this in mind for future contributions and ensure
 that any reports include a clear demonstration of user-generated input and
 real impact.

 If appropriate, please feel free to proceed with the ticket and consider
 it for inclusion in 7.1. I’m happy to continue contributing as an open-
 source developer, with the intention of strengthening the WordPress
 ecosystem through meaningful improvements, even if they are small.

 Appreciate your guidance and support.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65090#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 19 18:15:32 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 19 Apr 2026 18:15:32 -0000
Subject: [wp-trac] [WordPress Trac] #64902: wp_save_image() fatal error
 when wp_save_image_file() returns WP_Error
In-Reply-To: <053.171527bc59e8c487d3fc7fc913953abd@wordpress.org>
References: <053.171527bc59e8c487d3fc7fc913953abd@wordpress.org>
Message-ID: <068.5b9c0416156e29e2adc3dae45c94971d@wordpress.org>

#64902: wp_save_image() fatal error when wp_save_image_file() returns WP_Error
-------------------------------------+------------------------------
 Reporter:  notglossy                |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Media                    |     Version:  6.9.4
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+------------------------------

Comment (by notglossy):

 Yes, this is one of the symptoms on the front end since the whole process
 fails because WP_Error is not an array and returns a 500 error.

 Replying to [comment:3 aytor]:
 > I tested the bug on wordpress with environemnt:
 > WordPress: 6.9.4
 > PHP: 8.2
 > Local WP
 >
 > The bug is not reproducing, I'm getting the message saying "Could not
 load the preview image. Please reload the page and try again." but is not
 allowing me to save it the button is grayed out.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64902#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 19 18:49:10 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 19 Apr 2026 18:49:10 -0000
Subject: [wp-trac] [WordPress Trac] #65094: AI: Prompt construction
 fails with fatal error when wp_ai_client_default_request_timeout filter
 returns negative number
In-Reply-To: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
References: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
Message-ID: <070.29fe80e2d13bab420f8fe83ce45cdfef@wordpress.org>

#65094: AI: Prompt construction fails with fatal error when
wp_ai_client_default_request_timeout filter returns negative number
--------------------------------------+--------------------------
 Reporter:  westonruter               |       Owner:  westonruter
     Type:  defect (bug)              |      Status:  assigned
 Priority:  normal                    |   Milestone:  7.0
Component:  AI                        |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+--------------------------

Comment (by khushdoms):

 Tested the patch locally in a WordPress 7.0 development environment.

 **Testing setup:**

 * Theme: Twenty Twenty-Five (v1.4)
 * Added the following filter and test trigger in `functions.php`:

 ```
 add_filter(
     'wp_ai_client_default_request_timeout',
     function () {
         return -1;
     }
 );

 add_action('init', function () {
     if ( function_exists('wp_ai_client_prompt') ) {
         wp_ai_client_prompt("Test prompt");
     }
 });
 ```

 **Before applying the patch:**

 * Encountered a fatal error:
   `InvalidArgumentException: Request option "timeout" must be greater than
 or equal to 0`

 screenshot : https://prnt.sc/yC5V3AwWnwyF

 **After applying the patch:**

 * No fatal error occurs ✅
 * Invalid timeout value is handled gracefully
 * Application continues to run normally

 The patch successfully prevents the fatal error and aligns with expected
 WordPress error-handling practices.

 Patch works as expected 👍

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65094#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 19 19:27:19 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 19 Apr 2026 19:27:19 -0000
Subject: [wp-trac] [WordPress Trac] #65099: Fix: Only auto register
 settings if the plugin the connector references is installed and active
In-Reply-To: <060.0b8a8e3426646ee12db1e6e829f3d840@wordpress.org>
References: <060.0b8a8e3426646ee12db1e6e829f3d840@wordpress.org>
Message-ID: <075.500af89bc62e78970d9e5196563b88e0@wordpress.org>

#65099: Fix: Only auto register settings if the plugin the connector references is
installed and active
------------------------------+------------------------------
 Reporter:  jorgefilipecosta  |       Owner:  (none)
     Type:  defect (bug)      |      Status:  new
 Priority:  normal            |   Milestone:  Awaiting Review
Component:  General           |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+------------------------------

Comment (by iamadisingh):

 Hi @jorgefilipecosta, updated PR https://github.com/WordPress/wordpress-
 develop/pull/11565 to address this issue.

 `_wp_register_default_connector_settings()` now checks whether the owning
 plugin is active before registering the `api_key` setting for non-AI
 connectors. Uses the `is_active` callback if provided, falling back to
 `is_plugin_active()`. If neither confirms the plugin is active,
 registration is skipped.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65099#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 19 20:44:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 19 Apr 2026 20:44:07 -0000
Subject: [wp-trac] [WordPress Trac] #65100: Accessibility issues in admin
 Font Library
Message-ID: <053.fd1c73df50e7a84ff15cd733e2c7ac6f@wordpress.org>

#65100: Accessibility issues in admin Font Library
---------------------------+-------------------------
 Reporter:  joedolson      |      Owner:  (none)
     Type:  defect (bug)   |     Status:  new
 Priority:  normal         |  Milestone:  7.0
Component:  Themes         |    Version:
 Severity:  normal         |   Keywords:  needs-patch
  Focuses:  accessibility  |
---------------------------+-------------------------
 See note from @afercia on Slack;
 https://wordpress.slack.com/archives/C02RP4X03/p1776614733174009

 There are multiple issues that need to be resolved to make this more
 consistent with other core admin interfaces. The most critical issue is
 that the main heading needs to be changed to an `h1` instead of using an
 `h2`; but the `header` element is inappropriate in this context, as well.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65100>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 19 21:54:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 19 Apr 2026 21:54:22 -0000
Subject: [wp-trac] [WordPress Trac] #65099: Fix: Only auto register
 settings if the plugin the connector references is installed and active
In-Reply-To: <060.0b8a8e3426646ee12db1e6e829f3d840@wordpress.org>
References: <060.0b8a8e3426646ee12db1e6e829f3d840@wordpress.org>
Message-ID: <075.65b3dbeb8054aed03b935c811bd34812@wordpress.org>

#65099: Fix: Only auto register settings if the plugin the connector references is
installed and active
------------------------------+---------------------
 Reporter:  jorgefilipecosta  |       Owner:  (none)
     Type:  defect (bug)      |      Status:  new
 Priority:  normal            |   Milestone:  7.0
Component:  General           |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+---------------------
Changes (by SergeyBiryukov):

 * milestone:  Awaiting Review => 7.0


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65099#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 19 22:17:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 19 Apr 2026 22:17:30 -0000
Subject: [wp-trac] [WordPress Trac] #65095: Introduce Application Mode
 (DISABLE_BLOG) to disable post/blog features for secure non-CMS usage
In-Reply-To: <057.e392633509a2d7b062101e1eada86e22@wordpress.org>
References: <057.e392633509a2d7b062101e1eada86e22@wordpress.org>
Message-ID: <072.2a8879ef537b10b759fd0bf352e97dc9@wordpress.org>

#65095: Introduce Application Mode (DISABLE_BLOG) to disable post/blog features for
secure non-CMS usage
-------------------------------------------------+-------------------------
 Reporter:  dramitstalbot                        |       Owner:  (none)
     Type:  feature request                      |      Status:  closed
 Priority:  normal                               |   Milestone:
Component:  General                              |     Version:
 Severity:  normal                               |  Resolution:  wontfix
 Keywords:  feature-request needs-design-        |     Focuses:  rest-api,
  feedback                                       |  performance
-------------------------------------------------+-------------------------
Changes (by peterwilsoncc):

 * status:  new => closed
 * resolution:   => wontfix
 * milestone:  Awaiting Review =>


Comment:

 While WordPress can be used for many purposes, the core functionality is
 to use it as a content management system. A very small percentage of sites
 may use it for other purposes but nowhere near enough to introduce a
 feature to turn off the CMS in WordPress Core. I strongly doubt even 1% of
 sites are using it in this manner.

 It's already possible to use the `register_post_type_args` filter to
 modify the registration of post types to prevent their use and display in
 the admin. The `WP_USE_THEMES` constant exists to prevent the use of
 traditional themes.

 As this is not a common use case for WordPress, I'm closing this ticket as
 unplanned (wontfix).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65095#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 19 22:24:43 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 19 Apr 2026 22:24:43 -0000
Subject: [wp-trac] [WordPress Trac] #64225: Test tool and unit test
 improvements for 7.0
In-Reply-To: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
References: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
Message-ID: <066.2dc853a280816d28beb759ff5d6f7b70@wordpress.org>

#64225: Test tool and unit test improvements for 7.0
--------------------------------------+---------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  task (blessed)            |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by SergeyBiryukov):

 In [changeset:"62246" 62246]:
 {{{
 #!CommitTicketReference repository="" revision="62246"
 Tests: Add missing `@covers` tags for some rewrite tests.

 Follow-up to [36181], [62244].

 Props sagardeshmukh.
 See #64225.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64225#comment:71>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 00:19:01 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 00:19:01 -0000
Subject: [wp-trac] [WordPress Trac] #65101: Ensure layout classnames are
 applied to the inner blocks wrapper and not to its siblings
Message-ID: <057.09a82a11408fc6a4f4795b8037791d84@wordpress.org>

#65101: Ensure layout classnames are applied to the inner blocks wrapper and not to
its siblings
---------------------------+-----------------------------
 Reporter:  isabel_brison  |      Owner:  (none)
     Type:  defect (bug)   |     Status:  new
 Priority:  normal         |  Milestone:  7.1
Component:  Editor         |    Version:
 Severity:  normal         |   Keywords:  gutenberg-merge
  Focuses:                 |
---------------------------+-----------------------------
 The fix for layout classname application in
 https://github.com/WordPress/gutenberg/pull/77408 needs syncing to core.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65101>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 02:32:24 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 02:32:24 -0000
Subject: [wp-trac] [WordPress Trac] #65096: Add `is_user_member_of_blog`
 filter
In-Reply-To: <048.9dfa96df3fb9723aaae7786446ed0799@wordpress.org>
References: <048.9dfa96df3fb9723aaae7786446ed0799@wordpress.org>
Message-ID: <063.c1c8cf9d1a548e57151a80520040dfef@wordpress.org>

#65096: Add `is_user_member_of_blog` filter
---------------------------------------------+------------------------
 Reporter:  dd32                             |       Owner:  (none)
     Type:  enhancement                      |      Status:  new
 Priority:  normal                           |   Milestone:  7.1
Component:  Role/Capability                  |     Version:
 Severity:  normal                           |  Resolution:
 Keywords:  has-patch has-unit-tests commit  |     Focuses:  multisite
---------------------------------------------+------------------------
Changes (by dd32):

 * keywords:  has-patch has-unit-tests => has-patch has-unit-tests commit
 * milestone:  Awaiting Review => 7.1


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65096#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 03:09:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 03:09:16 -0000
Subject: [wp-trac] [WordPress Trac] #65102:
 WP_MS_Users_List_Table::display_rows() should emit id="user-{ID}" on <tr>
 to match WP_Users_List_Table
Message-ID: <048.33f8455008cefea3e2c683f5eab2b5b0@wordpress.org>

#65102: WP_MS_Users_List_Table::display_rows() should emit id="user-{ID}" on <tr>
to match WP_Users_List_Table
---------------------------------------+-----------------------------
 Reporter:  dd32                       |      Owner:  (none)
     Type:  defect (bug)               |     Status:  new
 Priority:  normal                     |  Milestone:  Awaiting Review
Component:  Users                      |    Version:
 Severity:  normal                     |   Keywords:
  Focuses:  administration, multisite  |
---------------------------------------+-----------------------------
 `WP_Users_List_Table::single_row()` (used on per-site wp-admin/users.php)
 renders each user row with:

   <tr id="user-123">...</tr>

 …but its network counterpart `WP_MS_Users_List_Table::display_rows()`
 (used on wp-admin/network/users.php) renders:

   <tr class="...">...</tr>

 No id, no per-user anchor.

 This makes it impossible to target a specific user row by ID on the
 network screen using stylesheets, JavaScript, or assistive-tech anchors,
 even though the per-site table supports it. Plugins that decorate /
 restyle specific user rows have to fall back to scraping the bulk-action
 checkbox (#blog_{ID}) and walking .closest('tr') — a brittle workaround.

 Expected: `<tr>` on the network Users list carries `id="user-{ID}"` like
 the per-site list.

 Actual: No row id at all.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65102>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 05:06:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 05:06:18 -0000
Subject: [wp-trac] [WordPress Trac] #65054: $_GET['pagenow'] and
 $_GET['widget'] unsanitized in dashboard AJAX handler
In-Reply-To: <052.a75882c45098b4077208ace43f305612@wordpress.org>
References: <052.a75882c45098b4077208ace43f305612@wordpress.org>
Message-ID: <067.b531527c10dd9159ed38f464a1204bfc@wordpress.org>

#65054: $_GET['pagenow'] and $_GET['widget'] unsanitized in dashboard AJAX handler
-------------------------------------+------------------------------
 Reporter:  rajeshcp                 |       Owner:  rajeshcp
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Security                 |     Version:  trunk
 Severity:  major                    |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+------------------------------
Changes (by liaison):

 * Attachment "65054-inject-DevTool.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65054>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 05:15:40 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 05:15:40 -0000
Subject: [wp-trac] [WordPress Trac] #65054: $_GET['pagenow'] and
 $_GET['widget'] unsanitized in dashboard AJAX handler
In-Reply-To: <052.a75882c45098b4077208ace43f305612@wordpress.org>
References: <052.a75882c45098b4077208ace43f305612@wordpress.org>
Message-ID: <067.f1dec22217cb80f0adcf227d7f0078c7@wordpress.org>

#65054: $_GET['pagenow'] and $_GET['widget'] unsanitized in dashboard AJAX handler
-------------------------------------------------+-------------------------
 Reporter:  rajeshcp                             |       Owner:  rajeshcp
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Security                             |     Version:  trunk
 Severity:  major                                |  Resolution:
 Keywords:  has-patch needs-testing has-test-    |     Focuses:
  info                                           |
-------------------------------------------------+-------------------------
Changes (by liaison):

 * keywords:  has-patch needs-testing => has-patch needs-testing has-test-
               info


Comment:

 Test Report: Input Sanitization for pagenow in AJAX Actions
 Summary
 Verification of the sanitization vulnerability in
 wp_ajax_dashboard_widgets() where the pagenow parameter was being used
 without proper filtering. This report demonstrates the effectiveness of
 applying sanitize_key() to prevent variable pollution.

 Environment
 WordPress Version: 7.0-beta1-61709-src

 PHP Version: 7.4 / 8.x

 Area: AJAX / Dashboard

 Reproduction Steps
 Using the Browser Developer Tools (Console), a "polluted" request was sent
 to the dashboard-widgets action containing uppercase letters, special
 characters, and spaces.

 Payload:

 JavaScript

 {{{
 jQuery.get( ajaxurl, {
     action: 'dashboard-widgets',
     pagenow: 'DashBoard_!!!_For_Test',
     widget: 'dashboard_primary'
 });

 }}}

 [[Image(65054-inject-DevTool.png)]]

 Code Implementation (Testing Patch)
 The following debug code was inserted into wp-admin/includes/ajax-
 actions.php to compare the raw input against the sanitized output:

 PHP
 {{{#!php
 <?php
 function wp_ajax_dashboard_widgets() {
     require_once ABSPATH . 'wp-admin/includes/dashboard.php';

     $raw_pagenow = $_GET['pagenow'];
     $pagenow = isset( $_GET['pagenow'] ) ? sanitize_key( $_GET['pagenow']
 ) : '';

     error_log( "--- Audit Start ---" );
     error_log( "Raw Input:    [" . $raw_pagenow . "]" );
     error_log( "Sanitized:    [" . $pagenow . "]" );
     error_log( "--- Audit End ---" );

     // Subsequent logic...
 }

 }}}


 Test Results (debug.log)
 The logs confirm that while the raw input contained unsafe characters,
 sanitize_key() correctly normalized the string according to WordPress
 standards.

 Plaintext

 {{{
 [20-Apr-2026 05:01:41 UTC] --- Audit Start ---
 [20-Apr-2026 05:01:41 UTC] Raw Input:    [DashBoard_!!!_For_Test]
 [20-Apr-2026 05:01:41 UTC] Sanitized:    [dashboard__for_test]
 [20-Apr-2026 05:01:41 UTC] --- Audit End ---

 }}}

 Discussion & Conclusion
 Variable Consistency: The sanitized value dashboard__for_test removes the
 risk of inconsistent logic handling caused by case sensitivity (e.g.,
 DashBoard vs dashboard).

 Security Posture: Removing special characters (!!!) prevents the variable
 from being used as a vector for path traversal or other injection attacks
 if the variable is passed to other core functions in the future.

 Recommendation: The patch to include sanitize_key() should be merged to
 align this function with the defensive coding standards seen in other AJAX
 handlers like wp_ajax_meta_box_order().

 The same on $widget

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65054#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 05:18:52 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 05:18:52 -0000
Subject: [wp-trac] [WordPress Trac] #65054: $_GET['pagenow'] and
 $_GET['widget'] unsanitized in dashboard AJAX handler
In-Reply-To: <052.a75882c45098b4077208ace43f305612@wordpress.org>
References: <052.a75882c45098b4077208ace43f305612@wordpress.org>
Message-ID: <067.6fee1356f89d727b4115b28975bbe0d3@wordpress.org>

#65054: $_GET['pagenow'] and $_GET['widget'] unsanitized in dashboard AJAX handler
-------------------------------------------------+-------------------------
 Reporter:  rajeshcp                             |       Owner:  rajeshcp
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Security                             |     Version:  trunk
 Severity:  major                                |  Resolution:
 Keywords:  has-patch needs-testing has-test-    |     Focuses:
  info                                           |
-------------------------------------------------+-------------------------

Comment (by liaison):

 Note on Defensive Coding:
 While current logic employs validation via strict comparisons, applying
 sanitize_key() to pagenow and widget is a necessary Defense in Depth
 measure.

 Unsanitized input creates several long-term risks:

 Downstream Vulnerabilities: Prevents potential Reflected XSS if these
 variables are later used in logging, dynamic hooks, or UI output by core
 or third-party plugins.

 Cache Pollution: Normalizing these inputs prevents "cache bloating" in
 environments using Object Caching (Redis/Memcached), where randomized
 strings could be used as keys to exhaust memory.

 Attack Surface Reduction: Early sanitization ensures that the variables
 are "normalized" (lowercase and alphanumeric) before they enter the
 internal logic, mitigating risks like Path Traversal in future refactors.

 This hardening aligns the function with the security standards seen in
 other AJAX handlers like wp_ajax_meta_box_order().

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65054#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 05:19:32 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 05:19:32 -0000
Subject: [wp-trac] [WordPress Trac] #65095: Introduce Application Mode
 (DISABLE_BLOG) to disable post/blog features for secure non-CMS usage
In-Reply-To: <057.e392633509a2d7b062101e1eada86e22@wordpress.org>
References: <057.e392633509a2d7b062101e1eada86e22@wordpress.org>
Message-ID: <072.a8e19c6fec477de23bc818f12db560aa@wordpress.org>

#65095: Introduce Application Mode (DISABLE_BLOG) to disable post/blog features for
secure non-CMS usage
-------------------------------------------------+-------------------------
 Reporter:  dramitstalbot                        |       Owner:  (none)
     Type:  feature request                      |      Status:  closed
 Priority:  normal                               |   Milestone:
Component:  General                              |     Version:
 Severity:  normal                               |  Resolution:  wontfix
 Keywords:  feature-request needs-design-        |     Focuses:  rest-api,
  feedback                                       |  performance
-------------------------------------------------+-------------------------

Comment (by dramitstalbot):

 Thank you @peterwilsoncc for the clarification and for taking the time to
 review this.

 I understand the decision and the perspective that WordPress core should
 remain focused on its primary role as a CMS.

 That said, I would like to briefly reiterate the motivation behind this
 proposal—not as a disagreement, but as additional context from real-world
 usage.

 In environments like healthcare systems (such as the HMIS I’m building),
 WordPress is being used strictly as an application framework. In such
 cases, disabling unused CMS-related components is not just about
 preference, but about reducing attack surface, simplifying architecture,
 and meeting stricter security expectations.

 I also understand that this may currently represent a small percentage of
 WordPress usage. At the same time, it’s possible that this usage remains
 limited in part because there isn’t yet a standardized or supported way to
 operate WordPress in a more application-focused mode.

 This area may represent an opportunity for future exploration, especially
 as WordPress continues to be adopted for internal tools, enterprise
 systems, and regulated environments.

 For now, I will continue implementing this as a custom application layer
 on top of WordPress, as suggested. If in the future there is any interest
 in exploring a more formalized or extensible approach within core (even in
 a limited or opt-in capacity), I would be happy to contribute, test, or
 provide feedback based on production use.

 Thank you again for the discussion and for maintaining clarity around core
 direction.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65095#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 05:48:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 05:48:06 -0000
Subject: [wp-trac] [WordPress Trac] #64950: wp_using_ext_object_cache
 can return null, causing type failures, potential fatals
In-Reply-To: <051.0ea02aed2495587dfabbac6c5957d746@wordpress.org>
References: <051.0ea02aed2495587dfabbac6c5957d746@wordpress.org>
Message-ID: <066.7be8b3311f1698a15c982f8344bd696c@wordpress.org>

#64950: wp_using_ext_object_cache can return null, causing type failures, potential
fatals
-------------------------------------------------+-------------------------
 Reporter:  ronalfy                              |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  reviewing
 Priority:  normal                               |   Milestone:  7.1
Component:  Cache API                            |     Version:  3.7
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-test-info has-unit-    |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------
Changes (by liaison):

 * keywords:  has-patch => has-patch has-test-info has-unit-tests


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64950#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 05:59:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 05:59:21 -0000
Subject: [wp-trac] [WordPress Trac] #65102:
 WP_MS_Users_List_Table::display_rows() should emit id="user-{ID}" on <tr>
 to match WP_Users_List_Table
In-Reply-To: <048.33f8455008cefea3e2c683f5eab2b5b0@wordpress.org>
References: <048.33f8455008cefea3e2c683f5eab2b5b0@wordpress.org>
Message-ID: <063.b877265ab22360b6f901d1b9d34e7faf@wordpress.org>

#65102: WP_MS_Users_List_Table::display_rows() should emit id="user-{ID}" on <tr>
to match WP_Users_List_Table
--------------------------+----------------------------------------
 Reporter:  dd32          |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Users         |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  administration, multisite
--------------------------+----------------------------------------
Description changed by sabernhardt:

Old description:

> `WP_Users_List_Table::single_row()` (used on per-site wp-admin/users.php)
> renders each user row with:
>
>   <tr id="user-123">...</tr>
>
> …but its network counterpart `WP_MS_Users_List_Table::display_rows()`
> (used on wp-admin/network/users.php) renders:
>
>   <tr class="...">...</tr>
>
> No id, no per-user anchor.
>
> This makes it impossible to target a specific user row by ID on the
> network screen using stylesheets, JavaScript, or assistive-tech anchors,
> even though the per-site table supports it. Plugins that decorate /
> restyle specific user rows have to fall back to scraping the bulk-action
> checkbox (#blog_{ID}) and walking .closest('tr') — a brittle workaround.
>
> Expected: `<tr>` on the network Users list carries `id="user-{ID}"` like
> the per-site list.
>
> Actual: No row id at all.

New description:

 `WP_Users_List_Table::single_row()` (used on per-site `wp-
 admin/users.php`) renders each user row with:
 {{{
   <tr id="user-123">...</tr>
 }}}
 …but its network counterpart `WP_MS_Users_List_Table::display_rows()`
 (used on `wp-admin/network/users.php`) renders:
 {{{
   <tr class="...">...</tr>
 }}}
 No id, no per-user anchor.

 This makes it impossible to target a specific user row by ID on the
 network screen using stylesheets, JavaScript, or assistive-tech anchors,
 even though the per-site table supports it. Plugins that decorate /
 restyle specific user rows have to fall back to scraping the bulk-action
 checkbox (`#blog_{ID}`) and walking `.closest('tr')` — a brittle
 workaround.

 Expected: `<tr>` on the network Users list carries `id="user-{ID}"` like
 the per-site list.

 Actual: No row id at all.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65102#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 06:29:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 06:29:53 -0000
Subject: [wp-trac] [WordPress Trac] #65100: Accessibility issues in
 admin Font Library
In-Reply-To: <053.fd1c73df50e7a84ff15cd733e2c7ac6f@wordpress.org>
References: <053.fd1c73df50e7a84ff15cd733e2c7ac6f@wordpress.org>
Message-ID: <068.a82e2f53f23025e5c58d52dc6c7e86dd@wordpress.org>

#65100: Accessibility issues in admin Font Library
--------------------------+----------------------------
 Reporter:  joedolson     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  Themes        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:  accessibility
--------------------------+----------------------------

Comment (by hbhalodia):

 Hi @joedolson @afercia I am creating an upstream issue for the same to fix
 this. As it should get first fixed in the Gutenberg. I would link the
 issue here.

 Thanks,

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65100#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 06:37:59 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 06:37:59 -0000
Subject: [wp-trac] [WordPress Trac] #65095: Introduce Application Mode
 (DISABLE_BLOG) to disable post/blog features for secure non-CMS usage
In-Reply-To: <057.e392633509a2d7b062101e1eada86e22@wordpress.org>
References: <057.e392633509a2d7b062101e1eada86e22@wordpress.org>
Message-ID: <072.518c44bec79b408f310d8df1cb8eca32@wordpress.org>

#65095: Introduce Application Mode (DISABLE_BLOG) to disable post/blog features for
secure non-CMS usage
-----------------------------+------------------------------------
 Reporter:  dramitstalbot    |       Owner:  (none)
     Type:  feature request  |      Status:  closed
 Priority:  normal           |   Milestone:
Component:  General          |     Version:
 Severity:  normal           |  Resolution:  wontfix
 Keywords:                   |     Focuses:  rest-api, performance
-----------------------------+------------------------------------
Changes (by sabernhardt):

 * keywords:  feature-request needs-design-feedback =>


Old description:

> WordPress has evolved beyond a blogging platform and is widely used as an
> application framework for building systems such as CRMs, ERPs, and
> healthcare software.
>
> There is currently no supported, centralized way to disable blog/content-
> related functionality at the core level when it is not needed.
>
> Problem
>
> Even when WordPress is used purely as an application framework:
>
> * Core blog features (posts, categories, tags, comments, feeds) are
> always loaded
> * Associated hooks, filters, and REST endpoints remain active
> * Rewrite rules and query handling for posts are still registered
> * Admin UI includes unused components
>
> This increases:
>
> * Attack surface (especially via plugins targeting post workflows)
> * Resource usage
> * Complexity in securing deployments
>
> Real-World Use Case
>
> I am a medical doctor and developer building a Hospital Management
> Information System (HMIS) on WordPress.
>
> This system includes:
>
> * Patient records and clinical documentation
> * Prescription workflows
> * Medical file storage
> * Billing and administration
>
> In this context:
>
> * WordPress is used strictly as an application framework
> * Blog functionality is completely unused
> * Reducing unnecessary components is critical for security, especially in
> healthcare environments
>
> Proposal
>
> Introduce a core constant:
>
> define('DISABLE_BLOG', true);
>
> When enabled, WordPress operates in an Application Mode.
>
> Expected Behavior
>
> When DISABLE_BLOG is enabled:
>
> * Do not register:
>
>   * post post type
>   * category and post_tag taxonomies
>   * comment system
>
> * Disable:
>
>   * Post-related REST API endpoints (e.g., /wp/v2/posts)
>   * Feeds and post permalinks
>   * Author archives
>
> * Skip loading:
>
>   * Blog-related hooks and filters
>
> * Admin UI:
>
>   * Remove Posts and Comments menus
>   * Remove related dashboard widgets
>
> Benefits
>
> * Reduced attack surface
> * Improved performance
> * Cleaner application-focused architecture
> * Better suitability for secure and regulated environments
> * Encourages WordPress adoption for non-CMS use cases
>
> Why This Matters
>
> One of WordPress’s biggest strengths is its low learning curve and ease
> of use. Because of this, many developers consider WordPress first before
> exploring other frameworks.
>
> Providing a native way to disable blog functionality would:
>
> * Strengthen WordPress as a general-purpose framework
> * Retain developers who might otherwise move to other stacks
> * Expand adoption in enterprise and healthcare systems
>
> Technical Considerations (Initial Thoughts)
>
> * Conditional loading in wp-settings.php and default-filters.php
>
> * Introduce helper:
>
> function wp_is_application_mode() {
> return defined('DISABLE_BLOG') && DISABLE_BLOG;
> }
>
> * Wrap blog-specific registrations and hooks
> * Provide filters for extensibility (e.g., REST whitelist)
>
> Backward Compatibility
>
> * Default behavior unchanged
> * Feature is opt-in via constant
> * Plugins/themes can detect and adapt
>
> Future Scope
>
> * Granular flags:
>
>   * WP_DISABLE_COMMENTS
>   * WP_DISABLE_FEEDS
>   * WP_DISABLE_REST_POSTS
>
> * Preset modes:
>
>   * CMS Mode (default)
>   * Application Mode
>
> Summary
>
> This proposal introduces a lightweight Application Mode that allows
> WordPress to function as a secure, minimal framework when CMS features
> are not required.

New description:

 WordPress has evolved beyond a blogging platform and is widely used as an
 application framework for building systems such as CRMs, ERPs, and
 healthcare software.

 There is currently no supported, centralized way to disable blog/content-
 related functionality at the core level when it is not needed.

 ==== Problem

 Even when WordPress is used purely as an application framework:

 * Core blog features (posts, categories, tags, comments, feeds) are always
 loaded
 * Associated hooks, filters, and REST endpoints remain active
 * Rewrite rules and query handling for posts are still registered
 * Admin UI includes unused components

 This increases:

 * Attack surface (especially via plugins targeting post workflows)
 * Resource usage
 * Complexity in securing deployments

 ===== Real-World Use Case

 I am a medical doctor and developer building a Hospital Management
 Information System (HMIS) on WordPress.

 This system includes:

 * Patient records and clinical documentation
 * Prescription workflows
 * Medical file storage
 * Billing and administration

 In this context:

 * WordPress is used strictly as an application framework
 * Blog functionality is completely unused
 * Reducing unnecessary components is critical for security, especially in
 healthcare environments

 ==== Proposal

 Introduce a core constant:
 {{{
 define('DISABLE_BLOG', true);
 }}}

 When enabled, WordPress operates in an Application Mode.

 ===== Expected Behavior

 When `DISABLE_BLOG` is enabled:

 * Do not register:
   * post post type
   * category and post_tag taxonomies
   * comment system
 * Disable:
   * Post-related REST API endpoints (e.g., /wp/v2/posts)
   * Feeds and post permalinks
   * Author archives
 * Skip loading:
   * Blog-related hooks and filters
 * Admin UI:
   * Remove Posts and Comments menus
   * Remove related dashboard widgets

 ===== Benefits

 * Reduced attack surface
 * Improved performance
 * Cleaner application-focused architecture
 * Better suitability for secure and regulated environments
 * Encourages WordPress adoption for non-CMS use cases

 ===== Why This Matters

 One of WordPress’s biggest strengths is its low learning curve and ease of
 use. Because of this, many developers consider WordPress first before
 exploring other frameworks.

 Providing a native way to disable blog functionality would:

 * Strengthen WordPress as a general-purpose framework
 * Retain developers who might otherwise move to other stacks
 * Expand adoption in enterprise and healthcare systems

 ===== Technical Considerations (Initial Thoughts)

 * Conditional loading in `wp-settings.php` and `default-filters.php`
 * Introduce helper:
   {{{
   function wp_is_application_mode() {
     return defined('DISABLE_BLOG') && DISABLE_BLOG;
   }
   }}}
 * Wrap blog-specific registrations and hooks
 * Provide filters for extensibility (e.g., REST whitelist)

 ===== Backward Compatibility

 * Default behavior unchanged
 * Feature is opt-in via constant
 * Plugins/themes can detect and adapt

 ===== Future Scope

 * Granular flags:
   * WP_DISABLE_COMMENTS
   * WP_DISABLE_FEEDS
   * WP_DISABLE_REST_POSTS
 * Preset modes:
   * CMS Mode (default)
   * Application Mode

 ===== Summary

 This proposal introduces a lightweight Application Mode that allows
 WordPress to function as a secure, minimal framework when CMS features are
 not required.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65095#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 06:39:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 06:39:55 -0000
Subject: [wp-trac] [WordPress Trac] #65098: get_site_icon_url() returns
 empty string even when fallback is defined,
 breaking wp-embed-site-icon in the_embed_site_title()
In-Reply-To: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
References: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
Message-ID: <069.2729d285d64abfc6a6e1d204ce8c25b0@wordpress.org>

#65098: get_site_icon_url() returns empty string even when fallback is defined,
breaking wp-embed-site-icon in the_embed_site_title()
--------------------------+---------------------
 Reporter:  pontocinza    |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.1
Component:  Embeds        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+---------------------

Comment (by mohamedahamed):

 Yes, the defensive checks needs to be added in Core, namely:
 1. In get_site_icon_url() (general-template.php): Only update $url if the
 attachment URL is not empty

 2. In the_embed_site_title() (embed.php): Check if URL is empty before
 rendering the img tag (like wp_site_icon() already does).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65098#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 06:51:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 06:51:16 -0000
Subject: [wp-trac] [WordPress Trac] #65100: Accessibility issues in
 admin Font Library
In-Reply-To: <053.fd1c73df50e7a84ff15cd733e2c7ac6f@wordpress.org>
References: <053.fd1c73df50e7a84ff15cd733e2c7ac6f@wordpress.org>
Message-ID: <068.311cdb6c09c6ec3a8676d644ef585d68@wordpress.org>

#65100: Accessibility issues in admin Font Library
--------------------------+----------------------------
 Reporter:  joedolson     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  Themes        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:  accessibility
--------------------------+----------------------------

Comment (by hbhalodia):

 Hi @joedolson @afercia Raised the PR -
 https://github.com/WordPress/gutenberg/pull/77482 to at least update the
 heading to level 1 for the release as mentioned on the slack -
 https://wordpress.slack.com/archives/C02RP4X03/p1776614733174009

 Thanks,

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65100#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 08:22:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 08:22:44 -0000
Subject: [wp-trac] [WordPress Trac] #65101: Ensure layout classnames are
 applied to the inner blocks wrapper and not to its siblings
In-Reply-To: <057.09a82a11408fc6a4f4795b8037791d84@wordpress.org>
References: <057.09a82a11408fc6a4f4795b8037791d84@wordpress.org>
Message-ID: <072.b019d5a41cad1f25b5776360d8cbffaa@wordpress.org>

#65101: Ensure layout classnames are applied to the inner blocks wrapper and not to
its siblings
-------------------------------------------------+-------------------------
 Reporter:  isabel_brison                        |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  7.1
Component:  Editor                               |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  gutenberg-merge has-patch has-unit-  |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------

Comment (by darshitrajyaguru97):

 == Patch Testing ==

 I tested the provided patch locally and verified the behavior.

 === **Environment ===
 * WordPress: 7.0 RC2
 * PHP: 8.3
 * Server: Nginx
 * Browser: Chrome
 * OS: Windows 11

 === **Testing Steps ===
 1. Applied the patch from this ticket.
 2. Created Group blocks with layout settings (flex, constrained, etc.).
 3. Added nested blocks and sibling blocks.
 4. Inspected DOM output.

 === **Results ===
 - Layout classnames are now correctly applied only to the inner blocks
 wrapper.
 - No class leakage to sibling elements observed.
 - Nested block structures behave as expected.

 === **Unit Tests ===
 - All existing and added tests pass successfully.

 === **Notes ===
 - Patch aligns with Gutenberg PR
 https://github.com/WordPress/gutenberg/pull/77408.
 - Behavior is consistent with editor expectations.

 Patch looks good to me

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65101#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 09:22:58 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 09:22:58 -0000
Subject: [wp-trac] [WordPress Trac] #63946: Introduce a mechanism for
 lazy-loading REST routes and handlers
In-Reply-To: <055.ad78bb43928f10c4ced1948af0297f2b@wordpress.org>
References: <055.ad78bb43928f10c4ced1948af0297f2b@wordpress.org>
Message-ID: <070.c0d14a24bbf868faab7180f477141327@wordpress.org>

#63946: Introduce a mechanism for lazy-loading REST routes and handlers
--------------------------------------+------------------------------
 Reporter:  prettyboymp               |       Owner:  (none)
     Type:  enhancement               |      Status:  new
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  REST API                  |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+------------------------------

Comment (by rmccue):

 Replying to [comment:8 prettyboymp]:
 > 1. **`rest_endpoints` filter**: `get_routes()` passes `$this->endpoints`
 through this filter (line 968). Plugins iterating the filtered data expect
 arrays, not Closures — storing Closures in `$this->endpoints` would break
 them.

 Any API change here is going to break ''something'', but I take the point
 there. We could handle the  with a back-compat wrapper class for any
 callable which implements ArrayAccess - it's a little unclean on the
 implementation (core) side in that sense, but should work.

 [https://3v4l.org/v6Xio#v8.4.18 Here's an example implementation], tested
 against [https://3v4l.org/v6Xio#v8.4.18 code from Really Simple Security].
 The Resolvable class here implements just-in-time resolution for any
 callable, so actually we likely wouldn't need to change the Server code
 itself either. I'll see about spinning up a PR for this.

 Note that I didn't bother adding the single-to-multiple array
 normalisation here for now - we'd need to make a decision as to whether
 the callback can provide multiple endpoints or not. I'm leaning no,
 because it makes it impossible to merge together later, which is necessary
 for registering GET/POST as separate calls.

 (Aside: This form of resolution has a secondary benefit, which is that
 it's more conducive to [https://www.npopov.com/2014/02/18/Fast-request-
 routing-using-regular-expressions.html FastRoute-style optimisations] (eg
 "put all the routes in a big regex and offload the loop to PCRE"). Typical
 sites are getting to the point that they have enough routes to make this
 approach one worth considering now; ideally, having the method as well as
 the URL would allow off-the-shelf usage of FastRoute, but that's a very
 minor optimisation/design choice.)

 > 2. **`rest_send_allow_header()`**: Calls `$server->get_routes()` without
 a namespace parameter on every REST response (line 880), which would force
 resolution of all Closures, not just the matched route's. This also runs
 per-item via `get_target_hints_for_link()` in collection responses.

 This should be fixed with the resolvable concept too. The only time a
 route's definition is "resolved" is when it's used, so we only need to
 resolve the matched route here.

 > On the point that "registering the namespaces and their routes isn't
 expensive, rather it's the argument building that's slow" — the
 registration itself is cheap, but having more entries in
 `$this->endpoints` has a per-request cost beyond route matching.
 `rest_send_allow_header()` calls `get_routes()` without a namespace
 parameter (line 880), so on every REST response the full endpoints array
 is copied, passed through the `rest_endpoints` filter, and normalized
 (lines 979-1016). This also runs per-item via
 `get_target_hints_for_link()` in collection responses. Every registered
 route — even ones whose namespace doesn't match the current request — adds
 to that cost.

 That's a downstream issue, imo, whereas I'm talking mostly about the broad
 question of "what currently makes the REST API slower (and/or more memory
 hungry) than it should be?" The answer to that is basically a) slow string
 operations of all sorts (translation, etc etc), and b) schema resolution
 (eg to build args from a schema). Neither of those actually need doing for
 any route you're not actively using, hence my reasoning behind offloading
 just the endpoint options.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63946#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 09:50:43 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 09:50:43 -0000
Subject: [wp-trac] [WordPress Trac] #65102:
 WP_MS_Users_List_Table::display_rows() should emit id="user-{ID}" on <tr>
 to match WP_Users_List_Table
In-Reply-To: <048.33f8455008cefea3e2c683f5eab2b5b0@wordpress.org>
References: <048.33f8455008cefea3e2c683f5eab2b5b0@wordpress.org>
Message-ID: <063.af45d395d8c1571104f43efa8f87d053@wordpress.org>

#65102: WP_MS_Users_List_Table::display_rows() should emit id="user-{ID}" on <tr>
to match WP_Users_List_Table
--------------------------+----------------------------------------
 Reporter:  dd32          |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.1
Component:  Users         |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  administration, multisite
--------------------------+----------------------------------------
Changes (by SergeyBiryukov):

 * milestone:  Awaiting Review => 7.1


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65102#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 10:17:34 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 10:17:34 -0000
Subject: [wp-trac] [WordPress Trac] #64904: Real time collboration:
 determine approach for opt in setting for users in Settings > Writing
In-Reply-To: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
References: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
Message-ID: <067.f8a38933904631be27bdcb3cc3a49f0f@wordpress.org>

#64904: Real time collboration: determine approach for opt in setting for users in
Settings > Writing
------------------------------------+---------------------
 Reporter:  annezazu                |       Owner:  (none)
     Type:  task (blessed)          |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-design has-patch  |     Focuses:  ui
------------------------------------+---------------------

Comment (by fcoveram):

 Here's an idea that includes the descriptive texts. I'm not sure about the
 term "connection," so feel free to suggest others more accurate.
 Regardless, the design approach should be the same.

 The left version has a link to explain each feature connection. And the
 right one for the whole feature. I couldn't find any content in the
 WordPress Documentation for either of the approaches, but we could link
 the general connection type to [https://make.wordpress.org/core/2026/03/10
 /real-time-collaboration-in-the-block-editor/ this post].

 What do you think?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64904#comment:38>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 10:17:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 10:17:53 -0000
Subject: [wp-trac] [WordPress Trac] #64904: Real time collboration:
 determine approach for opt in setting for users in Settings > Writing
In-Reply-To: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
References: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
Message-ID: <067.cdce032fc6e0c538bb573ad7a4f4372f@wordpress.org>

#64904: Real time collboration: determine approach for opt in setting for users in
Settings > Writing
------------------------------------+---------------------
 Reporter:  annezazu                |       Owner:  (none)
     Type:  task (blessed)          |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-design has-patch  |     Focuses:  ui
------------------------------------+---------------------
Changes (by fcoveram):

 * Attachment "RTC feature copy alternatives.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64904>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 10:25:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 10:25:12 -0000
Subject: [wp-trac] [WordPress Trac] #65103: Single-page admin screens
 (Connectors,
 Font Library) fail to mount in Chrome when @wordpress/boot wins a race
 against its classic-script deps
Message-ID: <055.fd5b7dce505f7cac5b5fa322aadd0fb6@wordpress.org>

#65103: Single-page admin screens (Connectors, Font Library) fail to mount in
Chrome when @wordpress/boot wins a race against its classic-script deps
----------------------------+-----------------------------
 Reporter:  fabiankaegy     |      Owner:  (none)
     Type:  defect (bug)    |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Script Loader   |    Version:  trunk
 Severity:  normal          |   Keywords:  script-modules
  Focuses:  administration  |
----------------------------+-----------------------------
 == What happened ==

 On a fast CDN-fronted host (reproducible on WordPress VIP) in Chrome, the
 Connectors screen at `/wp-admin/options-connectors.php` never mounts. The
 `<div id="options-connectors-wp-admin-app">` stays empty and the console
 shows:

 {{{
 Uncaught Error: Cannot unlock an undefined object.
     at k (wp-includes/js/dist/private-apis.min.js)
     at wp-includes/js/dist/script-modules/boot/index.min.js:1:34623
 }}}

 The Font Library admin screen, and any plugin/theme using the same
 `wp_register_*_wp_admin_*` pattern generated into `wp-
 includes/build/pages/*`, are affected for the same reason.

 Not reproducible locally, and not reproducible in Firefox/Safari often
 enough to notice. The race window only opens reliably when the boot module
 lands before the parser reaches the classic deps.

 == Root cause ==

 File: `wp-includes/build/pages/options-connectors/page-wp-admin.php`
 (auto-generated from the Gutenberg build). The same code is emitted for
 `page.php` and for `wp-includes/build/pages/font-library/*`.

 Lines 157-164:

 {{{#!php
 wp_add_inline_script(
     'options-connectors-wp-admin-prerequisites',
     sprintf(
         'import("@wordpress/boot").then(mod =>
 mod.initSinglePage({mountId: "%s", routes: %s}));',
         'options-connectors-wp-admin-app',
         wp_json_encode( $routes, JSON_HEX_TAG | JSON_UNESCAPED_SLASHES )
     )
 );
 }}}

 The prerequisites handle is registered with an empty src:

 {{{#!php
 wp_register_script(
     'options-connectors-wp-admin-prerequisites',
     '',
     $asset['dependencies'],
     $asset['version'],
     true
 );
 }}}

 Because the handle has no src, WP prints only the attached inline-before
 /inline-after scripts. They render as classic `<script>` tags (no
 `type="module"`), so they run immediately when the HTML parser reaches
 them.

 On the rendered page (WP 7.1-alpha, build 62246) the order is:

 ||= DOM position =||= Script =||
 || 51 || `<script type="importmap">` ||
 || 52 || inline `<script type="module">` (core tmpl-attachment) ||
 || 53 || `<script type="module" src=".../loader.js">` ||
 || **57** || **`<script id="options-connectors-wp-admin-prerequisites-js-
 after">` with `import("@wordpress/boot").then(initSinglePage)`** ||
 || 88 || `<script id="wp-private-apis-js">` ||
 || 94 || `<script id="wp-components-js">` ||
 || 110 || `<script id="wp-theme-js">` ||

 The classic deps (`wp-private-apis`, `wp-components`, `wp-theme`) declare
 themselves via `boot/index.min.asset.php['dependencies']`, but they print
 in the standard classic-script-printing pass, which runs **after** the
 script-module printing pass that carries the empty-src handle's inline
 scripts. So the inline `import()` fires at DOM order 57, while `wp-theme-
 js` has not yet been parsed.

 `@wordpress/boot` is preloaded via `<link rel="modulepreload">`. On a fast
 CDN the bundle is effectively free, so the dynamic import resolves and
 evaluates the boot module before the parser has reached the classic deps
 at DOM positions 88/94/110.

 At its top-level, boot accesses the global set up by those deps:

 {{{#!js
 // boot/index.min.js
 var ja = i(ko(), 1);                       // ja = window.wp.theme
 var Kr = x(ja.privateApis).ThemeProvider;  //
 unlock(window.wp.theme.privateApis)
 }}}

 `window.wp.theme` exists as `{}` (created by the core global bootstrap),
 but `wp.theme.privateApis` is `undefined` because `wp-theme.min.js` has
 not executed yet. `unlock(undefined)` throws, `initSinglePage` never runs,
 and the mount stays empty.

 == Why only Chrome + fast CDN ==

 * On VIP, `@wordpress/boot` is delivered off the CDN almost instantly
 after modulepreload, so the module evaluates before the parser reaches
 `wp-theme-js`.
 * Locally, the module fetch is slow enough relative to the parser that the
 classic deps usually finish first.
 * Firefox and Safari schedule module evaluation slightly later than Chrome
 and do not lose the race as consistently.

 == Repro ==

 1. Any environment where modulepreloaded script modules are served fast
 (VIP, CloudFront in front of a build, etc.) on WP 7.0+ for Connectors /
 7.1-alpha for both affected screens.
 2. Open Chrome.
 3. Visit `/wp-admin/options-connectors.php` or the Font Library admin
 page.
 4. Hard-reload a few times.
 5. Expected: the app mounts.
    Actual: the mount div stays empty and the console reports "Cannot
 unlock an undefined object".

 == Suggested fixes ==

 Any of these would close the race. Listed from least invasive to most:

 1. **Wrap the inline call in `DOMContentLoaded`.** `DOMContentLoaded`
 fires only after all parser-blocking classic scripts have executed, so
 `wp.theme.privateApis` is guaranteed to be set by the time boot evaluates.
 One-line change, no build change:

 {{{#!php
 sprintf(
     '(function(){var
 i=function(){import("@wordpress/boot").then(function(m){m.initSinglePage({mountId:%s,routes:%s});});};if(document.readyState==="loading"){document.addEventListener("DOMContentLoaded",i);}else{i();}})();',
     wp_json_encode( 'options-connectors-wp-admin-app' ),
     wp_json_encode( $routes, JSON_HEX_TAG | JSON_UNESCAPED_SLASHES )
 )
 }}}

 2. **Emit the inline as a module script.** Module scripts are deferred by
 the HTML spec and wait for parsing to finish. This would need either
 `wp_add_inline_script_module()` (does not exist yet) or a
 `script_loader_tag` filter.

 3. **Move `initSinglePage` into `loader.js`.** `loader.js` is already
 registered as a script module with `@wordpress/boot` as a static dep. If
 the init call lived there, evaluation order would be guaranteed by the
 module graph. Routes and mount ID would pass via a small `window.*` data
 blob set by an inline-before.

 Option 1 is the minimal safe fix and matches what we applied in a
 downstream project-level copy of the pattern with success.

 == Related ==

 * Not a regression per se: the pattern worked everywhere the race has been
 too tight to fire. Surfaces only in fast-CDN + Chrome setups.
 * Connectors screen landed in 7.0. Font Library uses the same generator
 output in `wp-includes/build/pages/font-library/`.
 * Any downstream consumer that followed the same
 `wp_register_script('-prerequisites', '', ...)` +
 `wp_add_inline_script('import("@wordpress/boot")...')` pattern has the
 same bug.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65103>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 11:55:42 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 11:55:42 -0000
Subject: [wp-trac] [WordPress Trac] #65048: wp_ajax_fetch_list():
 Sanitize $_GET input before nonce construction
In-Reply-To: <052.ec9b36b226893b34c604b6419cd46f00@wordpress.org>
References: <052.ec9b36b226893b34c604b6419cd46f00@wordpress.org>
Message-ID: <067.6dfde22fb8b004138300f2c16c84caf5@wordpress.org>

#65048: wp_ajax_fetch_list(): Sanitize $_GET input before nonce construction
-------------------------------------+------------------------------
 Reporter:  rajeshcp                 |       Owner:  rajeshcp
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Administration           |     Version:  trunk
 Severity:  critical                 |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+------------------------------
Changes (by rajeshcp):

 * Attachment "Screenshot 2026-04-20 at 5.19.39 PM.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65048>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 12:05:37 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 12:05:37 -0000
Subject: [wp-trac] [WordPress Trac] #44447: Failed to load resource:
 net::ERR_FILE_NOT_FOUND
In-Reply-To: <061.ccf96b5d39e4ec5294da091e224cd091@wordpress.org>
References: <061.ccf96b5d39e4ec5294da091e224cd091@wordpress.org>
Message-ID: <076.452cc672ee7c36ba0dd8443e470b330b@wordpress.org>

#44447: Failed to load resource: net::ERR_FILE_NOT_FOUND
-------------------------------+----------------------
 Reporter:  Benjamin_Zekavica  |       Owner:  (none)
     Type:  defect (bug)       |      Status:  closed
 Priority:  normal             |   Milestone:
Component:  General            |     Version:
 Severity:  normal             |  Resolution:  invalid
 Keywords:  reporter-feedback  |     Focuses:
-------------------------------+----------------------
Changes (by desrosj):

 * status:  reopened => closed
 * resolution:   => invalid
 * milestone:  Awaiting Review =>


Comment:

 It's been 8 years since this was opened and no one else has reported this
 issue. I am going to close this out, but please @Benjamin_Zekavica reopen
 this if you are still able to reproduce.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/44447#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 12:28:36 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 12:28:36 -0000
Subject: [wp-trac] [WordPress Trac] #65100: Accessibility issues in
 admin Font Library
In-Reply-To: <053.fd1c73df50e7a84ff15cd733e2c7ac6f@wordpress.org>
References: <053.fd1c73df50e7a84ff15cd733e2c7ac6f@wordpress.org>
Message-ID: <068.4696e1b9f3e8422f9ea40bf688720e53@wordpress.org>

#65100: Accessibility issues in admin Font Library
--------------------------+----------------------------
 Reporter:  joedolson     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  Themes        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:  accessibility
--------------------------+----------------------------

Comment (by wildworks):

 > The most critical issue is that the main heading needs to be changed to
 an `h1` instead of using an `h2`;

 This has been fixed in https://github.com/WordPress/gutenberg/pull/77482

 >but the `header` element is inappropriate in this context, as well.

 Next, we need to resolve this issue.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65100#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 14:07:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 14:07:06 -0000
Subject: [wp-trac] [WordPress Trac] #64467: Grid view displays
 attachments in the wrong order when an order query var is present but not
 normalized
In-Reply-To: <056.a9649627bbea9cb77ff62e81658bfe91@wordpress.org>
References: <056.a9649627bbea9cb77ff62e81658bfe91@wordpress.org>
Message-ID: <071.16d13c689b79e3a47398dc02d82e95f0@wordpress.org>

#64467: Grid view displays attachments in the wrong order when an order query var
is present but not normalized
-------------------------------------+-------------------------------------
 Reporter:  trivedikavit             |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  7.1
Component:  Media                    |     Version:
 Severity:  minor                    |  Resolution:
 Keywords:  has-screenshots          |     Focuses:  javascript,
  changes-requested has-patch has-   |  administration
  unit-tests                         |
-------------------------------------+-------------------------------------

Comment (by darshitrajyaguru97):

 == Patch Testing Report ==

 I tested the proposed patch and verified the behavior before and after
 applying it.

 === Environment ===
 * WordPress: 7.0-beta3-61849-src
 * PHP: 8.2.29
 * Server: Nginx
 * Database: MySQL
 * Browser: Chrome
 * OS: Windows 10
 * Theme: Twenty Twenty-Five
 * Plugins: None

 === Steps to Reproduce ===
 1. Upload multiple images to the Media Library with identifiable
 naming/order.
 2. Visit: `/wp-admin/upload.php?mode=grid&orderby=date&order=desc`
 3. Observe the order of media items.

 === Before Patch ===
 * The `order=desc` parameter was not respected.
 * Media items were displayed in ascending order (1 → 10).
 * Changing `order` values (e.g., `DESC`, invalid values like `pizza`) had
 no effect.

 === After Applying Patch ===
 * The `order=desc` parameter is correctly applied.
 * Media items are now displayed in descending order (10 → 1).
 * Ordering behavior aligns with expected query parameter handling.

 === Expected Result ===
 * The `order` query parameter should properly control sorting direction
 (ASC/DESC).

 === Actual Result ===
 * ✅ After patch: Sorting works correctly as expected.


 === Conclusion ===
 The patch successfully fixes the issue. The `order` parameter is now
 properly respected in Media Library grid view.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64467#comment:17>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 14:22:43 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 14:22:43 -0000
Subject: [wp-trac] [WordPress Trac] #63946: Introduce a mechanism for
 lazy-loading REST routes and handlers
In-Reply-To: <055.ad78bb43928f10c4ced1948af0297f2b@wordpress.org>
References: <055.ad78bb43928f10c4ced1948af0297f2b@wordpress.org>
Message-ID: <070.efeeba617e3134209ca529e27f7eb99e@wordpress.org>

#63946: Introduce a mechanism for lazy-loading REST routes and handlers
--------------------------------------+------------------------------
 Reporter:  prettyboymp               |       Owner:  (none)
     Type:  enhancement               |      Status:  new
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  REST API                  |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+------------------------------

Comment (by rmccue):

 Replying to [comment:9 rmccue]:
 > [https://3v4l.org/v6Xio#v8.4.18 Here's an example implementation],
 tested against [https://3v4l.org/v6Xio#v8.4.18 code from Really Simple
 Security]. The Resolvable class here implements just-in-time resolution
 for any callable, so actually we likely wouldn't need to change the Server
 code itself either. I'll see about spinning up a PR for this.

 https://github.com/WordPress/wordpress-develop/pull/11606 implements this,
 along with some minimal unit tests for the behaviour. I haven't done any
 significant compatibility testing with the ecosystem, only some minimal
 tests for the array behaviour.

 I've not benchmarked this as I'm partially out-of-office currently; there
 shouldn't be a huge overhead to instantiating these objects, but given
 that the overhead of the endpoint registration isn't super high, I'm not
 sure where it nets out. Finger in the air, I'd guess it's probably
 slightly worse at small scale (~100 endpoints).

 There's one minor compatibility issue this introduces. If you pass an
 endpoint's options to `wp_parse_args()`, this internally calls
 `get_object_vars()` if the variable is an object, so will break - I had to
 resolve this by using `iterator_to_array()`. That's a pretty minor break,
 as you mostly only need that type of merging when applying defaults, but
 something we can document; I haven't done an extensive search yet to see
 if that's in broad use, but I can't imagine so. (It's safe to call
 `iterator_to_array()` on arrays, so this can be backported as well.)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63946#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 14:32:42 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 14:32:42 -0000
Subject: [wp-trac] [WordPress Trac] #64817: Bump default theme versions
 for WordPress 7.0
In-Reply-To: <052.c63f6cd5170af975f4f240cb6bb1d2a1@wordpress.org>
References: <052.c63f6cd5170af975f4f240cb6bb1d2a1@wordpress.org>
Message-ID: <067.ba7092a1eb4d82846624312d4ac691e2@wordpress.org>

#64817: Bump default theme versions for WordPress 7.0
----------------------------+-------------------------
 Reporter:  shailu25        |       Owner:  karmatosed
     Type:  task (blessed)  |      Status:  assigned
 Priority:  normal          |   Milestone:  7.0
Component:  Bundled Theme   |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+-------------------------

Comment (by sabernhardt):

 Drafts for the changelogs are on https://github.com/WordPress
 /Documentation-Issue-Tracker/issues/2246

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64817#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 16:15:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 16:15:56 -0000
Subject: [wp-trac] [WordPress Trac] #64904: Real time collboration:
 determine approach for opt in setting for users in Settings > Writing
In-Reply-To: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
References: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
Message-ID: <067.509998d81da1a582d70533e76e8f00a7@wordpress.org>

#64904: Real time collboration: determine approach for opt in setting for users in
Settings > Writing
------------------------------------+---------------------
 Reporter:  annezazu                |       Owner:  (none)
     Type:  task (blessed)          |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-design has-patch  |     Focuses:  ui
------------------------------------+---------------------

Comment (by annezazu):

 Thanks for sharing those. I don't think that's right. "Enhanced connection
 available" and making it a link makes it seem you can go configure this or
 change options rather than reflecting what's in use right now. There
 aren't ways to configure this. I also don't think we should link to a dev
 note. If needed, we can create a support doc for it and put the future
 URL. To be clear though, what we're trying to do is show what the current
 mode is: default vs enhanced (or whatever word design thinks will
 communicate this best). Can you come up with designs based on showing what
 current mode is in use?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64904#comment:39>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 17:10:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 17:10:56 -0000
Subject: [wp-trac] [WordPress Trac] #65044: get_post_custom_values()
 missing array check, inconsistent with get_post_custom_keys()
In-Reply-To: <057.4a59bcc730ee55ef2108915dd95410cb@wordpress.org>
References: <057.4a59bcc730ee55ef2108915dd95410cb@wordpress.org>
Message-ID: <072.35503ad1f3b1e0ecc77114317a993433@wordpress.org>

#65044: get_post_custom_values() missing array check, inconsistent with
get_post_custom_keys()
-------------------------------------------------+-------------------------
 Reporter:  saratheonline                        |       Owner:
                                                 |  saratheonline
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  7.1
Component:  Posts, Post Types                    |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing needs-unit-  |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------
Changes (by westonruter):

 * keywords:  has-patch needs-testing => has-patch needs-testing needs-unit-
     tests
 * milestone:  Awaiting Review => 7.1


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65044#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 17:12:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 17:12:06 -0000
Subject: [wp-trac] [WordPress Trac] #65046: get_weekstartend() has
 swapped variable names and comments for month and day
In-Reply-To: <057.a04ab5ef592944628bef1cd9cd93c2e5@wordpress.org>
References: <057.a04ab5ef592944628bef1cd9cd93c2e5@wordpress.org>
Message-ID: <072.a414513113aad197ced594a73906d925@wordpress.org>

#65046: get_weekstartend() has swapped variable names and comments for month and
day
---------------------------+-----------------------------------------------
 Reporter:  saratheonline  |       Owner:  saratheonline
     Type:  defect (bug)   |      Status:  assigned
 Priority:  normal         |   Milestone:  7.1
Component:  Date/Time      |     Version:  trunk
 Severity:  normal         |  Resolution:
 Keywords:  has-patch      |     Focuses:  sustainability, coding-standards
  needs-testing            |
---------------------------+-----------------------------------------------
Changes (by westonruter):

 * milestone:  Awaiting Review => 7.1


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65046#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 17:28:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 17:28:03 -0000
Subject: [wp-trac] [WordPress Trac] #64904: Real time collboration:
 determine approach for opt in setting for users in Settings > Writing
In-Reply-To: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
References: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
Message-ID: <067.1a70b83af886f19ef4d20f6e609c7a88@wordpress.org>

#64904: Real time collboration: determine approach for opt in setting for users in
Settings > Writing
------------------------------------+---------------------
 Reporter:  annezazu                |       Owner:  (none)
     Type:  task (blessed)          |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-design has-patch  |     Focuses:  ui
------------------------------------+---------------------

Comment (by smithjw1):

 Replying to [comment:39 annezazu]:
 > Thanks for sharing those. I don't think that's right. "Enhanced
 connection available" and making it a link makes it seem you can go
 configure this or change options rather than reflecting what's in use
 right now.

 I agree, and different providers may use different technologies.
 WebSockets is the most likely, but other providers (WebRTC) are possible.

 I agree we need a way to show what is in use, but we should make the text
 filterable. That way, providers can accurately describe their "mode".

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64904#comment:40>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 17:31:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 17:31:22 -0000
Subject: [wp-trac] [WordPress Trac] #65048: wp_ajax_fetch_list():
 Sanitize $_GET input before nonce construction
In-Reply-To: <052.ec9b36b226893b34c604b6419cd46f00@wordpress.org>
References: <052.ec9b36b226893b34c604b6419cd46f00@wordpress.org>
Message-ID: <067.3e03004ad7c7f3220c5ccccb010b796c@wordpress.org>

#65048: wp_ajax_fetch_list(): Sanitize $_GET input before nonce construction
-------------------------------------+------------------------------
 Reporter:  rajeshcp                 |       Owner:  rajeshcp
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Administration           |     Version:  3.1
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+------------------------------
Changes (by westonruter):

 * version:  trunk => 3.1
 * severity:  critical => normal


Comment:

 If this is critical and it is a security fix, then it should //not// have
 been reported in Trac but rather [https://hackerone.com/wordpress on
 HackerOne]. Please report the issue there if it is critical, otherwise,
 this seems to be a hardening for a hypothetical issue. (Do not discuss
 here if it is actually not hypothetical. Provide reproduction steps in
 HackerOne.)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65048#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 17:34:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 17:34:09 -0000
Subject: [wp-trac] [WordPress Trac] #65050: REST API: Comments
 controller returns 403 instead of 404 for invalid post ID in update_item()
In-Reply-To: <057.d01cd307fcdefb847d0c0d7b8f496018@wordpress.org>
References: <057.d01cd307fcdefb847d0c0d7b8f496018@wordpress.org>
Message-ID: <072.4361230fae5725bf9529f87806f2d353@wordpress.org>

#65050: REST API: Comments controller returns 403 instead of 404 for invalid post
ID in update_item()
-------------------------------------------------+-------------------------
 Reporter:  saratheonline                        |       Owner:
                                                 |  saratheonline
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  7.1
Component:  REST API                             |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing changes-     |     Focuses:  coding-
  requested                                      |  standards
-------------------------------------------------+-------------------------
Changes (by westonruter):

 * keywords:  has-patch needs-testing => has-patch needs-testing changes-
     requested


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65050#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 17:44:19 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 17:44:19 -0000
Subject: [wp-trac] [WordPress Trac] #65052: Nonce check order flaw in
 post-quickdraft-save
In-Reply-To: <052.5cb71bdc8207e81444fff364e3bc4f57@wordpress.org>
References: <052.5cb71bdc8207e81444fff364e3bc4f57@wordpress.org>
Message-ID: <067.3794eb0126a3fed1c9f09487c662d795@wordpress.org>

#65052: Nonce check order flaw in post-quickdraft-save
-------------------------------------+------------------------------
 Reporter:  rajeshcp                 |       Owner:  rajeshcp
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Security                 |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+------------------------------
Changes (by westonruter):

 * severity:  major => normal


Comment:

 > A crafted request can cause a database lookup on an arbitrary post_ID
 before authorization.

 This is not a security issue. Enumerating post IDs can be done with the
 REST API.

 If it were a security issue, especially a major one, it should //not// be
 reported in Trac but rather in the [https://hackerone.com/wordpress
 WordPress HackerOne].

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65052#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 17:46:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 17:46:57 -0000
Subject: [wp-trac] [WordPress Trac] #65083: Toolbar: Simplify profile
 item by removing "Howdy, <UserName>" text and using a circular avatar
In-Reply-To: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
References: <052.c183d6662a08679fa3f3f68694d851e3@wordpress.org>
Message-ID: <067.4724587ca9ed8351e7f4b4b811147597@wordpress.org>

#65083: Toolbar: Simplify profile item by removing "Howdy, <UserName>" text and
using a circular avatar
-------------------------------------+-------------------------------------
 Reporter:  lucasmdo                 |       Owner:  audrasjb
     Type:  enhancement              |      Status:  accepted
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Toolbar                  |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-design-  |     Focuses:  ui, accessibility,
  feedback                           |  css, administration
-------------------------------------+-------------------------------------

Comment (by lucasmdo):

 Replying to [comment:6 siliconforks]:
 > Replying to [comment:4 lucasmdo]:
 > > "There is a setting to turn off avatars entirely."
 > > Thanks for the clarification, @siliconforks . I didn't know that.
 Where can I find this setting?
 >
 > All the avatar-related settings are under Settings → Discussion.  The
 "Show Avatars" checkbox can be used to turn avatars off entirely; the
 "Default Avatar" setting can be used to customize what sort of avatar is
 shown for users without their own avatar.  See the above screenshot.
 >
 > > "users without a custom avatar will get a default avatar"
 > > In terms of having a generic avatar, this is completely fine. It's the
 same use case when a site doesn't have a site icon, right?
 >
 > If the "Howdy, <UserName>" text is removed, there may be no indication
 of who the current logged-in user is.


 We can think of placing the "Howdy, <UserName>" in another important area
 of the product, like in the Dashboard page. The current scenario creates a
 disparity between Mobile and Desktop. On Mobile, we don't have the width
 for this copy. Adding the "Howdy, <UserName>" on the Dashboard page can
 work on both mobile and desktop for example, helping to "... set the tone
 and humanize the experience of using WordPress." cc: @jorbin

 In terms of priorities, I think the width limitation and plugin
 installations are very important.

 WDYT?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65083#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 17:47:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 17:47:30 -0000
Subject: [wp-trac] [WordPress Trac] #65054: $_GET['pagenow'] and
 $_GET['widget'] unsanitized in dashboard AJAX handler
In-Reply-To: <052.a75882c45098b4077208ace43f305612@wordpress.org>
References: <052.a75882c45098b4077208ace43f305612@wordpress.org>
Message-ID: <067.3416f114fb84886162fbb701e818ea04@wordpress.org>

#65054: $_GET['pagenow'] and $_GET['widget'] unsanitized in dashboard AJAX handler
-------------------------------------------------+-------------------------
 Reporter:  rajeshcp                             |       Owner:  rajeshcp
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Security                             |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing has-test-    |     Focuses:
  info                                           |
-------------------------------------------------+-------------------------
Changes (by westonruter):

 * severity:  major => normal


Comment:

 Do not report "major" security issues in Trac. Use
 [https://hackerone.com/wordpress HackerOne] instead.

 Regardless, this seems to be a hardening not an exploitable vulnerability.
 (And if it is, do //not// disclose so here publicly.)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65054#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 18:07:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 18:07:16 -0000
Subject: [wp-trac] [WordPress Trac] #65068: PHP warnings when a
 registered oEmbed provider is malformed
In-Reply-To: <054.c667f79a728d296763b2f67622b647d2@wordpress.org>
References: <054.c667f79a728d296763b2f67622b647d2@wordpress.org>
Message-ID: <069.6941638cf8302fa8a0b5726f37e88e82@wordpress.org>

#65068: PHP warnings when a registered oEmbed provider is malformed
-------------------------------------------------+-------------------------
 Reporter:  bradshawtm                           |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  7.1
Component:  Embeds                               |     Version:
 Severity:  minor                                |  Resolution:
 Keywords:  has-patch has-unit-tests changes-    |     Focuses:
  requested                                      |
-------------------------------------------------+-------------------------
Changes (by westonruter):

 * keywords:  has-patch has-unit-tests => has-patch has-unit-tests changes-
     requested
 * milestone:  Awaiting Review => 7.1


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65068#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 18:10:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 18:10:23 -0000
Subject: [wp-trac] [WordPress Trac] #65098: get_site_icon_url() returns
 empty string even when fallback is defined,
 breaking wp-embed-site-icon in the_embed_site_title()
In-Reply-To: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
References: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
Message-ID: <069.15177bb02f3ff78acc0e16d8c3fb0a55@wordpress.org>

#65098: get_site_icon_url() returns empty string even when fallback is defined,
breaking wp-embed-site-icon in the_embed_site_title()
--------------------------+---------------------
 Reporter:  pontocinza    |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.1
Component:  Embeds        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+---------------------

Comment (by sabernhardt):

 > Additionally, I can pinpoint when the issue started: it appeared today,
 after I replaced a PNG for a WebP image (and it was not the site icon
 file).

 In February, the site icon image was `pontocinza300.png`, which is no
 longer at the same URL. If that was deleted or renamed, the `site_icon`
 option would not be removed automatically. I noticed that you updated the
 site icon image to `pontocinza512.webp` since opening this ticket, and
 that icon displays for me now, at least in the browser tab (your site does
 not allow embedding posts in a different site).

 > the problem may be triggered by WebP format support (or lack thereof)

 I did not have trouble in an embedded post or browser tab when I set a
 WebP image as the icon in my site (Windows 11 with Chrome, Firefox and
 Edge). However, //browser// support for WebP as a favicon might not be
 good enough yet. [https://learn.microsoft.com/en-
 us/answers/questions/2393228/favicon-not-showing-in-microsoft-edge-using-
 webp-f Edge] and
 [https://support.google.com/webmasters/thread/331465898?hl=en&msgid=331485208
 Google forums] have reports from last year about WebP not displaying
 correctly.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65098#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 18:17:54 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 18:17:54 -0000
Subject: [wp-trac] [WordPress Trac] #65048: wp_ajax_fetch_list():
 Sanitize $_GET input before nonce construction
In-Reply-To: <052.ec9b36b226893b34c604b6419cd46f00@wordpress.org>
References: <052.ec9b36b226893b34c604b6419cd46f00@wordpress.org>
Message-ID: <067.201225bbb0fcd42b5000316b22ae8551@wordpress.org>

#65048: wp_ajax_fetch_list(): Sanitize $_GET input before nonce construction
-------------------------------------+------------------------------
 Reporter:  rajeshcp                 |       Owner:  rajeshcp
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Administration           |     Version:  3.1
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+------------------------------

Comment (by westonruter):

 See also: [https://make.wordpress.org/core/handbook/reporting-security-
 vulnerabilities/ Reporting Security Vulnerabilities]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65048#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 18:18:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 18:18:56 -0000
Subject: [wp-trac] [WordPress Trac] #65052: Nonce check order flaw in
 post-quickdraft-save
In-Reply-To: <052.5cb71bdc8207e81444fff364e3bc4f57@wordpress.org>
References: <052.5cb71bdc8207e81444fff364e3bc4f57@wordpress.org>
Message-ID: <067.36e75729501f671bc934a7f5de85c24d@wordpress.org>

#65052: Nonce check order flaw in post-quickdraft-save
-------------------------------------+------------------------------
 Reporter:  rajeshcp                 |       Owner:  rajeshcp
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Security                 |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+------------------------------

Comment (by westonruter):

 See also: [https://make.wordpress.org/core/handbook/reporting-security-
 vulnerabilities/ Reporting Security Vulnerabilities]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65052#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 18:19:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 18:19:07 -0000
Subject: [wp-trac] [WordPress Trac] #65054: $_GET['pagenow'] and
 $_GET['widget'] unsanitized in dashboard AJAX handler
In-Reply-To: <052.a75882c45098b4077208ace43f305612@wordpress.org>
References: <052.a75882c45098b4077208ace43f305612@wordpress.org>
Message-ID: <067.1877370517e04bb01afb76906f90cf5f@wordpress.org>

#65054: $_GET['pagenow'] and $_GET['widget'] unsanitized in dashboard AJAX handler
-------------------------------------------------+-------------------------
 Reporter:  rajeshcp                             |       Owner:  rajeshcp
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Security                             |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing has-test-    |     Focuses:
  info                                           |
-------------------------------------------------+-------------------------

Comment (by westonruter):

 See also: [https://make.wordpress.org/core/handbook/reporting-security-
 vulnerabilities/ Reporting Security Vulnerabilities]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65054#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 18:36:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 18:36:29 -0000
Subject: [wp-trac] [WordPress Trac] #65103: Single-page admin screens
 (Connectors,
 Font Library) fail to mount in Chrome when @wordpress/boot wins a race
 against its classic-script deps
In-Reply-To: <055.fd5b7dce505f7cac5b5fa322aadd0fb6@wordpress.org>
References: <055.fd5b7dce505f7cac5b5fa322aadd0fb6@wordpress.org>
Message-ID: <070.c4beb460916f920e47e44e528a37794d@wordpress.org>

#65103: Single-page admin screens (Connectors, Font Library) fail to mount in
Chrome when @wordpress/boot wins a race against its classic-script deps
----------------------------+-----------------------------
 Reporter:  fabiankaegy     |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  7.0
Component:  Script Loader   |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  script-modules  |     Focuses:  administration
----------------------------+-----------------------------
Changes (by westonruter):

 * milestone:  Awaiting Review => 7.0


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65103#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 19:10:10 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 19:10:10 -0000
Subject: [wp-trac] [WordPress Trac] #64950: wp_using_ext_object_cache
 can return null, causing type failures, potential fatals
In-Reply-To: <051.0ea02aed2495587dfabbac6c5957d746@wordpress.org>
References: <051.0ea02aed2495587dfabbac6c5957d746@wordpress.org>
Message-ID: <066.ce7943a7c736c9803a277770a18f422d@wordpress.org>

#64950: wp_using_ext_object_cache can return null, causing type failures, potential
fatals
-------------------------------------------------+-------------------------
 Reporter:  ronalfy                              |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  reviewing
 Priority:  normal                               |   Milestone:  7.1
Component:  Cache API                            |     Version:  3.7
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-test-info has-unit-    |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------

Comment (by westonruter):

 @liaison See [https://core.trac.wordpress.org/ticket/64950#comment:6
 feedback] about how this function has actually returned `bool|null`.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64950#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 20:19:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 20:19:03 -0000
Subject: [wp-trac] [WordPress Trac] Batch modify: #64616, #64989, #64990,
 #64955, #64146, ...
In-Reply-To: <197.172a3b7b6203b74c337829e9dac1b10c@wordpress.org>
References: <197.172a3b7b6203b74c337829e9dac1b10c@wordpress.org>
Message-ID: <212.74d792ded5695f9feb126f493c4c2bae@wordpress.org>

Batch modification to #64616, #64989, #64990, #64955, #64146, #64596, #65058, #64134, #64139, #64311, #64407, #65035, #64345, #64657, #64648, #64606, #64384, #64605, #64209, #64769, #64483, #64503, #64098, #64977, #64865, #64455 by desrosj:
component to Abilities API

Comment:
Moving tickets related to the Abilities API to a new sub-component.

-- 
Tickets URL: <https://core.trac.wordpress.org/query?id=64616%2C64989%2C64990%2C64955%2C64146%2C64596%2C65058%2C64134%2C64139%2C64311%2C64407%2C65035%2C64345%2C64657%2C64648%2C64606%2C64384%2C64605%2C64209%2C64769%2C64483%2C64503%2C64098%2C64977%2C64865%2C64455>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 20:47:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 20:47:49 -0000
Subject: [wp-trac] [WordPress Trac] #65100: Accessibility issues in
 admin Font Library
In-Reply-To: <053.fd1c73df50e7a84ff15cd733e2c7ac6f@wordpress.org>
References: <053.fd1c73df50e7a84ff15cd733e2c7ac6f@wordpress.org>
Message-ID: <068.25c9e055eea4f7005747d3dd19f1098a@wordpress.org>

#65100: Accessibility issues in admin Font Library
--------------------------+----------------------------
 Reporter:  joedolson     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  Themes        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:  accessibility
--------------------------+----------------------------

Comment (by afercia):

 Worth noting in 7.0 there's at least one more page that uses this pattern:
 the new Connectors page at `wp-admin/options-connectors.php`. At least
 there's a H1 heading there but the inappropriate usage of the `header`
 element and the ARIA landmarks nesting should be fixed there as well.

 I'm not sure I understand why these pages use a full white background
 color. There have been long discussions with a recent attempt to use a
 full white for the admin pages background (I think in #62831). The
 prevalent opinion was to not do that. Those changes were reverted. Now I
 see full white again, which is against any usability, UX, and
 accessibility best practice I'm aware of. It's a well-known design
 principle:
 - Never use full white.
 - Never use full black.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65100#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 22:53:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 22:53:09 -0000
Subject: [wp-trac] [WordPress Trac] #30679: Clicking "Restore this
 Revision" publishes immediately
In-Reply-To: <057.4966a66acfe50c96ff2ec6f58accbc7a@wordpress.org>
References: <057.4966a66acfe50c96ff2ec6f58accbc7a@wordpress.org>
Message-ID: <072.8eda93ec184e9aa96d5828e92dd466c6@wordpress.org>

#30679: Clicking "Restore this Revision" publishes immediately
---------------------------+------------------------
 Reporter:  paulschreiber  |       Owner:  (none)
     Type:  defect (bug)   |      Status:  closed
 Priority:  normal         |   Milestone:
Component:  Revisions      |     Version:
 Severity:  normal         |  Resolution:  duplicate
 Keywords:                 |     Focuses:
---------------------------+------------------------
Changes (by adamsilverstein):

 * status:  new => closed
 * resolution:   => duplicate


Comment:

 Closing this as a duplicate of #27244, it is essentially the same
 mechanism.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/30679#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 20 23:11:50 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 20 Apr 2026 23:11:50 -0000
Subject: [wp-trac] [WordPress Trac] #64324: Tests: Reduce usage of
 assertEquals for 7.0
In-Reply-To: <058.0c6ac395ada262d47afdbd8f4b684483@wordpress.org>
References: <058.0c6ac395ada262d47afdbd8f4b684483@wordpress.org>
Message-ID: <073.e682a6e6c4d09d6d88eace2cb650b7c6@wordpress.org>

#64324: Tests: Reduce usage of assertEquals for 7.0
--------------------------------------+-------------------------------
 Reporter:  SergeyBiryukov            |       Owner:  (none)
     Type:  task (blessed)            |      Status:  closed
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests  |     Focuses:  coding-standards
--------------------------------------+-------------------------------

Comment (by SergeyBiryukov):

 In [changeset:"62247" 62247]:
 {{{
 #!CommitTicketReference repository="" revision="62247"
 Tests: Use `assertSame()` in `get_adjacent_post()` tests.

 This ensures that not only the return values match the expected results,
 but also that their type is the same.

 Going forward, stricter type checking by using `assertSame()` should
 generally be preferred to `assertEquals()` where appropriate, to make the
 tests more reliable.

 Follow-up to [60733], [61066].

 Props sagardeshmukh.
 See #64324.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64324#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 01:11:38 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 01:11:38 -0000
Subject: [wp-trac] [WordPress Trac] #65100: Accessibility issues in
 admin Font Library
In-Reply-To: <053.fd1c73df50e7a84ff15cd733e2c7ac6f@wordpress.org>
References: <053.fd1c73df50e7a84ff15cd733e2c7ac6f@wordpress.org>
Message-ID: <068.af718e7c9cf19e78cbd71e8c3b13f6d7@wordpress.org>

#65100: Accessibility issues in admin Font Library
--------------------------+----------------------------
 Reporter:  joedolson     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  Themes        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:  accessibility
--------------------------+----------------------------

Comment (by wildworks):

 > I'm not sure I understand why these pages use a full white background
 color. There have been long discussions with a recent attempt to use a
 full white for the admin pages background (I think in #62831). The
 prevalent opinion was to not do that. Those changes were reverted. Now I
 see full white again, which is against any usability, UX, and
 accessibility best practice I'm aware of. It's a well-known design
 principle:

 It seems there have been some discussions regarding background colors in
 Gutenberg.

 https://github.com/WordPress/gutenberg/pull/76869

 In the latest Gutenberg, the background color appears to be `#fcfcfc`.
 @cgastrell, @simison, @jameskoster and @aduth might know something about
 it.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65100#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 02:15:51 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 02:15:51 -0000
Subject: [wp-trac] [WordPress Trac] #64950: wp_using_ext_object_cache
 can return null, causing type failures, potential fatals
In-Reply-To: <051.0ea02aed2495587dfabbac6c5957d746@wordpress.org>
References: <051.0ea02aed2495587dfabbac6c5957d746@wordpress.org>
Message-ID: <066.32e16879fe3db23bdf81a9b9f4cd18be@wordpress.org>

#64950: wp_using_ext_object_cache can return null, causing type failures, potential
fatals
-------------------------------------------------+-------------------------
 Reporter:  ronalfy                              |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  reviewing
 Priority:  normal                               |   Milestone:  7.1
Component:  Cache API                            |     Version:  3.7
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-test-info has-unit-    |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------

Comment (by liaison):

 Maintaining bool|null is significant for backwards compatibility. It
 respects the 'de facto' behavior of WordPress over the years.

 This proposed patch aims to align the implementation with the long-
 standing documentation, providing type safety for modern PHP 8.x
 environments. An unexpected null can lead to TypeError.

 The added test case is designed to complete the patch's intent.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64950#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 02:49:42 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 02:49:42 -0000
Subject: [wp-trac] [WordPress Trac] #65054: $_GET['pagenow'] and
 $_GET['widget'] unsanitized in dashboard AJAX handler
In-Reply-To: <052.a75882c45098b4077208ace43f305612@wordpress.org>
References: <052.a75882c45098b4077208ace43f305612@wordpress.org>
Message-ID: <067.11053003ae43e4142aee3ee1ca5412b8@wordpress.org>

#65054: $_GET['pagenow'] and $_GET['widget'] unsanitized in dashboard AJAX handler
-------------------------------------------------+-------------------------
 Reporter:  rajeshcp                             |       Owner:  rajeshcp
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Security                             |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing has-test-    |     Focuses:
  info                                           |
-------------------------------------------------+-------------------------

Comment (by liaison):

 Understood.

 The goal of this report is simply to provide test evidence for @rajeshcp's
 patch, ensuring consistent sanitization across AJAX handlers as a best
 practice. I will keep the HackerOne process in mind for any future
 security-related findings.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65054#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 03:33:50 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 03:33:50 -0000
Subject: [wp-trac] [WordPress Trac] #65044: get_post_custom_values()
 missing array check, inconsistent with get_post_custom_keys()
In-Reply-To: <057.4a59bcc730ee55ef2108915dd95410cb@wordpress.org>
References: <057.4a59bcc730ee55ef2108915dd95410cb@wordpress.org>
Message-ID: <072.9164be5ea85d2c3266f4196c4f0ec72a@wordpress.org>

#65044: get_post_custom_values() missing array check, inconsistent with
get_post_custom_keys()
-------------------------------------------------+-------------------------
 Reporter:  saratheonline                        |       Owner:
                                                 |  saratheonline
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  7.1
Component:  Posts, Post Types                    |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing needs-unit-  |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------
Changes (by liaison):

 * Attachment "65044_ajax_test.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65044>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 03:38:27 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 03:38:27 -0000
Subject: [wp-trac] [WordPress Trac] #65044: get_post_custom_values()
 missing array check, inconsistent with get_post_custom_keys()
In-Reply-To: <057.4a59bcc730ee55ef2108915dd95410cb@wordpress.org>
References: <057.4a59bcc730ee55ef2108915dd95410cb@wordpress.org>
Message-ID: <072.020bac4a225c67cd9fc6dae6e151d531@wordpress.org>

#65044: get_post_custom_values() missing array check, inconsistent with
get_post_custom_keys()
-------------------------------------------------+-------------------------
 Reporter:  saratheonline                        |       Owner:
                                                 |  saratheonline
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  7.1
Component:  Posts, Post Types                    |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing needs-unit-  |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------

Comment (by liaison):

 The sibling function get_post_custom_keys() already implements an
 is_array() check. Adding the same check to get_post_custom_values()
 prevents this invalid operation at the logic level rather than relying on
 PHP's error suppression.

 Testing on PHP 8.2.12 with E_ALL shows that while the function returns
 null without crashing (thanks to the null coalescing operator), it still
 performs an invalid offset access on a boolean when get_post_custom()
 fails. This is a silent failure that violates defensive coding standards.

 {{{#!php
 <?php
 add_action( 'wp_ajax_test_65044', function() {
     $id = 999999;
     $values = get_post_custom_values( 'some_key', $id );
         var_dump(error_reporting());
     wp_send_json_success( array( 'result' => $values ) );
 });
 }}}

 [[Image(65044_ajax_test.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65044#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 04:26:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 04:26:44 -0000
Subject: [wp-trac] [WordPress Trac] #65098: get_site_icon_url() returns
 empty string even when fallback is defined,
 breaking wp-embed-site-icon in the_embed_site_title()
In-Reply-To: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
References: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
Message-ID: <069.bd080e616a5a9693e1aa2702a07381f7@wordpress.org>

#65098: get_site_icon_url() returns empty string even when fallback is defined,
breaking wp-embed-site-icon in the_embed_site_title()
--------------------------+---------------------
 Reporter:  pontocinza    |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.1
Component:  Embeds        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+---------------------

Comment (by pontocinza):

 Replying to [comment:6 sabernhardt]:
 > > Additionally, I can pinpoint when the issue started: it appeared
 today, after I replaced a PNG for a WebP image (and it was not the site
 icon file).
 >
 > In February, the site icon image was `pontocinza300.png`, which is no
 longer at the same URL. If that was deleted or renamed, the `site_icon`
 option would not be removed automatically. I noticed that you updated the
 site icon image to `pontocinza512.webp` since opening this ticket, and
 that icon displays for me now, at least in the browser tab (your site does
 not allow embedding posts in a different site).
 **
 I don't remember when I started to use 'pontocinza512.webp' as the site
 icon; it was a long time ago. I've tried to solve the issue by removing
 the site icon and reinstating the very same file again, but of course it
 didn't work.**

 >
 > > the problem may be triggered by WebP format support (or lack thereof)
 >
 > I did not have trouble in an embedded post or browser tab when I set a
 WebP image as the icon in my site (Windows 11 with Chrome, Firefox and
 Edge). However, //browser// support for WebP as a favicon might not be
 good enough yet. [https://learn.microsoft.com/en-
 us/answers/questions/2393228/favicon-not-showing-in-microsoft-edge-using-
 webp-f Edge] and
 [https://support.google.com/webmasters/thread/331465898?hl=en&msgid=331485208
 Google forums] have reports from last year about WebP not displaying
 correctly.
 **
 I'm a heavy user of PngOut and Tweakpng and love the PNG format, but I
 have very few remaining PNG files in my site.**

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65098#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 05:05:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 05:05:39 -0000
Subject: [wp-trac] [WordPress Trac] #64657: Add `core/get-user` ability
In-Reply-To: <060.1c8487d3a0dddfbc93da4bf296090985@wordpress.org>
References: <060.1c8487d3a0dddfbc93da4bf296090985@wordpress.org>
Message-ID: <075.223afad2319606384e2d4d7cc0891e6b@wordpress.org>

#64657: Add `core/get-user` ability
---------------------------------+-----------------------------
 Reporter:  jorgefilipecosta     |       Owner:  (none)
     Type:  enhancement          |      Status:  new
 Priority:  normal               |   Milestone:  Future Release
Component:  Abilities API        |     Version:  trunk
 Severity:  normal               |  Resolution:
 Keywords:  abilities has-patch  |     Focuses:
---------------------------------+-----------------------------
Changes (by gziolo):

 * type:  defect (bug) => enhancement


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64657#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 07:19:10 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 07:19:10 -0000
Subject: [wp-trac] [WordPress Trac] #65095: Introduce Application Mode
 (DISABLE_BLOG) to disable post/blog features for secure non-CMS usage
In-Reply-To: <057.e392633509a2d7b062101e1eada86e22@wordpress.org>
References: <057.e392633509a2d7b062101e1eada86e22@wordpress.org>
Message-ID: <072.22e233b387742ee9bc1da719c125e322@wordpress.org>

#65095: Introduce Application Mode (DISABLE_BLOG) to disable post/blog features for
secure non-CMS usage
-----------------------------+------------------------------------
 Reporter:  dramitstalbot    |       Owner:  (none)
     Type:  feature request  |      Status:  closed
 Priority:  normal           |   Milestone:
Component:  General          |     Version:
 Severity:  normal           |  Resolution:  wontfix
 Keywords:                   |     Focuses:  rest-api, performance
-----------------------------+------------------------------------

Comment (by knutsp):

 Replying to [comment:4 peterwilsoncc]:
 > While WordPress can be used for many purposes, the core functionality is
 to use it as a content management system. A very small percentage of sites
 may use it for other purposes but nowhere near enough to introduce a
 feature to turn off the CMS in WordPress Core. I strongly doubt even 1% of
 sites are using it in this manner.

 10% of the sites I manage do not use 'post' post type, but have pages,
 attachments, products, events and other CPTs. Post posts are regarded
 "news". Some use the "Disable Blog" plugin, som just ignore the menu item
 "Posts". It's still a CMS, still very WordPress.

 Combined with basic PWA functionality I believe it would be great for
 WordPress, as a CMS and also a more general framework for web
 appliactions. This could attract new users ans sites, not just existing
 and guessing the need.

 Disabling "blog" (posts) is not removing being basically a content
 mangement system (CMS) as you seem to imply. It easily opens new use, with
 a simple off constant, and also benefits performance for thos who do not
 need this.

 Turning off (post) comments is even more widespread, 90% of my sites turns
 it off, so why not give users an opportunity to disable it completely,
 more effective than options and filters?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65095#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 08:03:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 08:03:03 -0000
Subject: [wp-trac] [WordPress Trac] #65101: Ensure layout classnames are
 applied to the inner blocks wrapper and not to its siblings
In-Reply-To: <057.09a82a11408fc6a4f4795b8037791d84@wordpress.org>
References: <057.09a82a11408fc6a4f4795b8037791d84@wordpress.org>
Message-ID: <072.6744cc473678ef9372e1620c929a0385@wordpress.org>

#65101: Ensure layout classnames are applied to the inner blocks wrapper and not to
its siblings
-------------------------------------------------+-------------------------
 Reporter:  isabel_brison                        |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  7.1
Component:  Editor                               |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  gutenberg-merge has-patch has-unit-  |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------

Comment (by tusharaddweb):

 Tested the patch and confirmed that layout classnames are now correctly
 applied to the inner blocks wrapper instead of sibling elements.

 This improves layout consistency and fixes styling issues with block
 themes using theme.json layout settings.

 No regressions observed in my testing.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65101#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 08:52:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 08:52:53 -0000
Subject: [wp-trac] [WordPress Trac] #64596: Abilities API: Allow nested
 namespace ability names (2-4 segments)
In-Reply-To: <060.74f0d53f8f168f6d8e4740aae322ab76@wordpress.org>
References: <060.74f0d53f8f168f6d8e4740aae322ab76@wordpress.org>
Message-ID: <075.1265df665955143b7ce183522befa4de@wordpress.org>

#64596: Abilities API: Allow nested namespace ability names (2-4 segments)
------------------------------------------------+--------------------------
 Reporter:  jorgefilipecosta                    |       Owner:
                                                |  jorgefilipecosta
     Type:  enhancement                         |      Status:  closed
 Priority:  normal                              |   Milestone:
Component:  Abilities API                       |     Version:  trunk
 Severity:  normal                              |  Resolution:  wontfix
 Keywords:  abilities has-patch has-unit-tests  |     Focuses:
------------------------------------------------+--------------------------
Changes (by jorgefilipecosta):

 * status:  reopened => closed
 * resolution:   => wontfix
 * milestone:  7.1 =>


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64596#comment:24>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 09:03:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 09:03:12 -0000
Subject: [wp-trac] [WordPress Trac] #65100: Accessibility issues in
 admin Font Library
In-Reply-To: <053.fd1c73df50e7a84ff15cd733e2c7ac6f@wordpress.org>
References: <053.fd1c73df50e7a84ff15cd733e2c7ac6f@wordpress.org>
Message-ID: <068.3d403c148e9658ddcc3175ed2c17bdb8@wordpress.org>

#65100: Accessibility issues in admin Font Library
--------------------------+----------------------------
 Reporter:  joedolson     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  Themes        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  accessibility
--------------------------+----------------------------

Comment (by wildworks):

 @khokansardar Thanks for working on this. However, as noted in
 [https://github.com/WordPress/wordpress-
 develop/blob/67094eec602b813723a5f96c66c6169cf559477b/src/wp-
 includes/build/pages/font-library/page-wp-admin.php#L5 this comment], we
 cannot directly modify this file. The fix needs to be made upstream, in
 Gutenberg.

 The color changes should be approached with caution as they are closely
 related to the new design system.

 > Now I see full white again, which is against any usability, UX, and
 accessibility best practice I'm aware of. It's a well-known design
 principle:

 In the latest version of Gutenberg, `'--wpds-color-bg-surface-neutral':
 '#fcfcfc'` is defined as a design token and is used for the page
 background color. I believe we first need to discuss whether this color
 should be permitted, considering accessibility and the discussion at
 #62831.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65100#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 09:03:42 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 09:03:42 -0000
Subject: [wp-trac] [WordPress Trac] #65099: Fix: Only auto register
 settings if the plugin the connector references is installed and active
In-Reply-To: <060.0b8a8e3426646ee12db1e6e829f3d840@wordpress.org>
References: <060.0b8a8e3426646ee12db1e6e829f3d840@wordpress.org>
Message-ID: <075.218136c7d322fd83c17d61f07181b28d@wordpress.org>

#65099: Fix: Only auto register settings if the plugin the connector references is
installed and active
--------------------------------------+---------------------
 Reporter:  jorgefilipecosta          |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  General                   |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------
Description changed by jorgefilipecosta:

Old description:

> `_wp_register_default_connector_settings()` in
> `src/wp-includes/connectors.php` is hooked to `init` (priority `20`) and
> walks
> every connector returned by `wp_get_connectors()`. For each connector
> that
> declares `authentication.method = 'api_key'` and an
> `authentication.setting_name`, it calls `register_setting( 'connectors',
> … )`
> so the setting is registered and available.
>
> Before this change, the only gate applied to non-AI connector types was
> that the setting had not already been registered. In practice this meant:
>
> 1. A connector for plugin B registered by another plugin (plugin A) would
> have its API key setting auto-registered even when the '''owning service
> plugin was not
>    installed or not active'''.
> 2. The "orphan" setting then appeared in the `/wp-json/wp/v2/settings`
>    response for a service that could not actually consume them.
> 3. For `ai_provider` connectors this was already handled — the function
>    skipped providers that the AI Client registry did not know about — but
>    the equivalent guard was missing for every other connector type.
>
> The root cause is that the non-AI branch had no mechanism to ask the
> owning
> plugin "are you actually here?" before exposing the setting.
>

> Uses is_active connector proposed by @iamadisingh at
> https://core.trac.wordpress.org/ticket/65020.
> PR https://github.com/WordPress/wordpress-develop/pull/11565.
>
> ** Testing **
>
> Verify the connectors page works as before.
> Verify the unit tests pass.

New description:

 `_wp_register_default_connector_settings()` in
 `src/wp-includes/connectors.php` is hooked to `init` (priority `20`) and
 walks
 every connector returned by `wp_get_connectors()`. For each connector that
 declares `authentication.method = 'api_key'` and an
 `authentication.setting_name`, it calls `register_setting( 'connectors', …
 )`
 so the setting is registered and available.

 Before this change, the only gate applied to non-AI connector types was
 that the setting had not already been registered. In practice this meant:

 1. A connector for plugin B registered by another plugin (plugin A) would
 have its API key setting auto-registered even when the '''owning service
 plugin was not
    installed or not active'''.
 2. The "orphan" setting then appeared in the `/wp-json/wp/v2/settings`
    response for a service that could not actually consume them.
 3. For `ai_provider` connectors this was already handled — the function
    skipped providers that the AI Client registry did not know about — but
    the equivalent guard was missing for every other connector type.

 The root cause is that the non-AI branch had no mechanism to ask the
 owning
 plugin "are you actually here?" before exposing the setting.


 Uses is_active connector proposed by @iamadisingh at
 https://core.trac.wordpress.org/ticket/65020.

 PR fixing this issue at https://github.com/WordPress/wordpress-
 develop/pull/11564.

 ** Testing **

 Verify the connectors page works as before.
 Verify the unit tests pass.

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65099#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 09:06:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 09:06:18 -0000
Subject: [wp-trac] [WordPress Trac] #65099: Fix: Only auto register
 settings if the plugin the connector references is installed and active
In-Reply-To: <060.0b8a8e3426646ee12db1e6e829f3d840@wordpress.org>
References: <060.0b8a8e3426646ee12db1e6e829f3d840@wordpress.org>
Message-ID: <075.e819987aa3a173aade837c73a06cc100@wordpress.org>

#65099: Fix: Only auto register settings if the plugin the connector references is
installed and active
--------------------------------------+---------------------
 Reporter:  jorgefilipecosta          |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  General                   |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by jorgefilipecosta):

 Hi @iamadisingh, thanks so much for your work on this! Unfortunately, I
 don't think we can go with the approach in https://github.com/WordPress
 /wordpress-develop/pull/11565. is_plugin_active isn't something we should
 be calling in REST API requests, for example. I've actually been handling
 this over in #11564.
 What do you think about reverting your PR to just include the is_active
 callback addition as before? That approach was working well and was good
 to go, and then we could land your PR alongside #11564. Would that work
 for you?
 Thanks again for the help here! 🙏

 Replying to [comment:1 iamadisingh]:
 > Hi @jorgefilipecosta, updated PR https://github.com/WordPress/wordpress-
 develop/pull/11565 to address this issue.
 >
 > `_wp_register_default_connector_settings()` now checks whether the
 owning plugin is active before registering the `api_key` setting for non-
 AI connectors. Uses the `is_active` callback if provided, falling back to
 `is_plugin_active()`. If neither confirms the plugin is active,
 registration is skipped.
 >
 >


 Replying to [comment:1 iamadisingh]:
 > Hi @jorgefilipecosta, updated PR https://github.com/WordPress/wordpress-
 develop/pull/11565 to address this issue.
 >
 > `_wp_register_default_connector_settings()` now checks whether the
 owning plugin is active before registering the `api_key` setting for non-
 AI connectors. Uses the `is_active` callback if provided, falling back to
 `is_plugin_active()`. If neither confirms the plugin is active,
 registration is skipped.
 >
 >

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65099#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 09:19:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 09:19:14 -0000
Subject: [wp-trac] [WordPress Trac] #42281: No Autoupdate for
 Translation files
In-Reply-To: <050.e140f337402133addd4e8ac7df251fa4@wordpress.org>
References: <050.e140f337402133addd4e8ac7df251fa4@wordpress.org>
Message-ID: <065.dc86d0cdfae2a7a2ee36f743c7e26c78@wordpress.org>

#42281: No Autoupdate for Translation files
-------------------------------------------------+-------------------------
 Reporter:  stk_jj                               |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Upgrade/Install                      |     Version:  4.8.2
 Severity:  normal                               |  Resolution:
 Keywords:  2nd-opinion has-patch has-unit-      |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------

Comment (by Jyria):

 Refreshing this ticket with a patch for the UI improvement mentioned in
 comment:1.

 PR: https://github.com/WordPress/wordpress-develop/pull/11610

 This patch keeps the current translation update behavior, but improves the
 Updates screen by listing the specific pending translation updates before
 the upgrade runs. It adds display data helpers for translation updates and
 renders the pending core/plugin/theme translation packages with component
 name, language, and target version on `wp-admin/update-core.php`.

 Tests/validation:
 * Added PHPUnit coverage for the translation update display data,
 including plugin slug mapping for WordPress.org-style slugs.
 * Passed `php -l` on the changed files.
 * Passed `phpcs` for the changed files.
 * Ran an authenticated admin smoke test against `update-core.php` on a
 dedicated test instance and verified the rendered translations section and
 count for core, plugin, and theme translation updates.

 I was not able to run the PHPUnit suite end-to-end in this environment
 because the local WordPress test configuration / Docker test environment
 was unavailable.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/42281#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 09:36:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 09:36:16 -0000
Subject: [wp-trac] [WordPress Trac] #64904: Real time collboration:
 determine approach for opt in setting for users in Settings > Writing
In-Reply-To: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
References: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
Message-ID: <067.ec23e4bfc3f87daf0e1f12e81f99c43c@wordpress.org>

#64904: Real time collboration: determine approach for opt in setting for users in
Settings > Writing
------------------------------------+---------------------
 Reporter:  annezazu                |       Owner:  (none)
     Type:  task (blessed)          |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-design has-patch  |     Focuses:  ui
------------------------------------+---------------------

Comment (by fcoveram):

 If the dev note feels insufficient and there is no current documentation
 for this in wp.org/documentation, then let's not add it.

 Regarding terminology, I tried a more explicit version that uses default
 or enhanced and shows the technology used.

 I also moved the performance text to the descriptive area below the
 checkbox, as in other fields across Settings.

 For the disabled message, I’m drawn to use the Notice info variant. We
 know the design is poor, but using the right component and then updating
 it to the [https://wordpress.github.io/gutenberg/?path=/story/design-
 system-components-notice--info new version] sounds like the best move for
 consistent improvement.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64904#comment:41>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 09:36:43 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 09:36:43 -0000
Subject: [wp-trac] [WordPress Trac] #64904: Real time collboration:
 determine approach for opt in setting for users in Settings > Writing
In-Reply-To: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
References: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
Message-ID: <067.532f0a464904aca4204f9e0a97b73d3d@wordpress.org>

#64904: Real time collboration: determine approach for opt in setting for users in
Settings > Writing
------------------------------------+---------------------
 Reporter:  annezazu                |       Owner:  (none)
     Type:  task (blessed)          |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-design has-patch  |     Focuses:  ui
------------------------------------+---------------------
Changes (by fcoveram):

 * Attachment "RTC settings i2.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64904>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 09:58:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 09:58:12 -0000
Subject: [wp-trac] [WordPress Trac] #65099: Fix: Only auto register
 settings if the plugin the connector references is installed and active
In-Reply-To: <060.0b8a8e3426646ee12db1e6e829f3d840@wordpress.org>
References: <060.0b8a8e3426646ee12db1e6e829f3d840@wordpress.org>
Message-ID: <075.0213507b8555f5bc02a1e16fcc3aef5e@wordpress.org>

#65099: Fix: Only auto register settings if the plugin the connector references is
installed and active
--------------------------------------+---------------------
 Reporter:  jorgefilipecosta          |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  General                   |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by iamadisingh):

 Done @jorgefilipecosta. I’ve narrowed the PR back to the original
 `is_active` callback scope and left the broader plugin-registration guard
 for https://github.com/WordPress/wordpress-develop/pull/11564, as you
 suggested.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65099#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 10:48:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 10:48:49 -0000
Subject: [wp-trac] [WordPress Trac] #65103: Single-page admin screens
 (Connectors,
 Font Library) fail to mount in Chrome when @wordpress/boot wins a race
 against its classic-script deps
In-Reply-To: <055.fd5b7dce505f7cac5b5fa322aadd0fb6@wordpress.org>
References: <055.fd5b7dce505f7cac5b5fa322aadd0fb6@wordpress.org>
Message-ID: <070.43709fe2e1d72c6a43ea0ab946586cec@wordpress.org>

#65103: Single-page admin screens (Connectors, Font Library) fail to mount in
Chrome when @wordpress/boot wins a race against its classic-script deps
--------------------------------------+-----------------------------
 Reporter:  fabiankaegy               |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Script Loader             |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  script-modules has-patch  |     Focuses:  administration
--------------------------------------+-----------------------------

Comment (by tusharaddweb):

 Tested this issue in Chrome and was able to reproduce the problem where
 the admin screen (Font Library/Connectors) does not mount properly.

 It appears to be caused by @wordpress/boot executing before its
 dependencies are fully loaded, leading to a race condition during
 initialization.

 After apply the patch, the issue is resolved and the screens load
 consistently. I did not notice any regressions in other admin pages during
 testing.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65103#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 11:13:54 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 11:13:54 -0000
Subject: [wp-trac] [WordPress Trac] #65094: AI: Prompt construction
 fails with fatal error when wp_ai_client_default_request_timeout filter
 returns negative number
In-Reply-To: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
References: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
Message-ID: <070.5d3fb92ba5ce51b49f1263d41cf34379@wordpress.org>

#65094: AI: Prompt construction fails with fatal error when
wp_ai_client_default_request_timeout filter returns negative number
--------------------------------------+--------------------------
 Reporter:  westonruter               |       Owner:  westonruter
     Type:  defect (bug)              |      Status:  assigned
 Priority:  normal                    |   Milestone:  7.0
Component:  AI                        |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+--------------------------

Comment (by tusharaddweb):

 Tested the issue and confirm that return a negative value for the
 wp_ai_client_default_request_timeout filter generate a fatal error during
 prompt construction.

 The patch correctly handle invalid timeout values and prevents the crash.
 AI requests now work as expected.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65094#comment:19>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 11:18:01 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 11:18:01 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of items
 per page" input clips last digit for 3-digit values
Message-ID: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
----------------------------+-----------------------------
 Reporter:  shatrumyatra    |      Owner:  (none)
     Type:  defect (bug)    |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Administration  |    Version:
 Severity:  normal          |   Keywords:  has-screenshots
  Focuses:  ui              |
----------------------------+-----------------------------
 In the WordPress admin area, under **Screen Options**, the **Number of
 items per page** field appears too narrow. When entering a 3-digit value
 such as 999, the last digit is visually cut off / clipped inside the input
 box.


 == Steps to Reproduce:
 1. Go to any admin screen that supports Screen Options (for example Posts,
 Pages, Users, Plugins, etc.).
 2. Open **Screen Options**.
 3. In **Number of items per page**, enter a 3-digit number such as 999.
 4. Observe the input field display.


 == Expected Result:
 The full value (999) should be clearly visible inside the input field.


 == Actual Result:
 The last digit is clipped or partially hidden, making the value hard to
 read.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 11:19:40 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 11:19:40 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.5db80c1f0efa71066c03059bb524e6b9@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
-----------------------------+------------------------------
 Reporter:  shatrumyatra     |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Administration   |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  has-screenshots  |     Focuses:  ui
-----------------------------+------------------------------
Changes (by shatrumyatra):

 * Attachment "screen-option.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 11:20:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 11:20:30 -0000
Subject: [wp-trac] [WordPress Trac] #65094: AI: Prompt construction
 fails with fatal error when wp_ai_client_default_request_timeout filter
 returns negative number
In-Reply-To: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
References: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
Message-ID: <070.ad8ac554b090f7c4d798c0a7febae9d8@wordpress.org>

#65094: AI: Prompt construction fails with fatal error when
wp_ai_client_default_request_timeout filter returns negative number
--------------------------------------+--------------------------
 Reporter:  westonruter               |       Owner:  westonruter
     Type:  defect (bug)              |      Status:  assigned
 Priority:  normal                    |   Milestone:  7.0
Component:  AI                        |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+--------------------------

Comment (by khushdoms):

 Additionally tested with:
 - null return → works as expected
 - float values → handled correctly

 No regressions observed.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65094#comment:20>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 12:16:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 12:16:55 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.6445453bd49c9353f910318dc2d03951@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
-----------------------------+------------------------------
 Reporter:  shatrumyatra     |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Administration   |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  has-screenshots  |     Focuses:  ui
-----------------------------+------------------------------

Comment (by khushdoms):

 Hi, I'd like to work on this ticket. I will investigate and propose a
 patch.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 12:18:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 12:18:07 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.da073806185c56891774975140e3f557@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
-----------------------------+------------------------------
 Reporter:  shatrumyatra     |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Administration   |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  has-screenshots  |     Focuses:  ui
-----------------------------+------------------------------
Changes (by ekla):

 * Attachment "Screenshot 2026-04-21 at 5.46.03 PM.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 12:20:37 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 12:20:37 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.020403e2253fb5b57e7e999132f34963@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
------------------------------------+--------------------------------------
 Reporter:  piyushpatel123          |       Owner:  audrasjb
     Type:  defect (bug)            |      Status:  accepted
 Priority:  normal                  |   Milestone:  7.0
Component:  Administration          |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch admin-reskin  |     Focuses:  ui, css, administration
------------------------------------+--------------------------------------
Changes (by nikunj8866):

 * keywords:  needs-testing has-patch admin-reskin => has-patch admin-reskin


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031#comment:21>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 12:33:19 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 12:33:19 -0000
Subject: [wp-trac] [WordPress Trac] #65105: Details Block - Enhancement
 Request
Message-ID: <050.87c17924a66786e661708ecaabdc0354@wordpress.org>

#65105: Details Block - Enhancement Request
-------------------------------+-----------------------------
 Reporter:  mowill             |      Owner:  (none)
     Type:  enhancement        |     Status:  new
 Priority:  normal             |  Milestone:  Awaiting Review
Component:  Posts, Post Types  |    Version:  6.9.4
 Severity:  normal             |   Keywords:
  Focuses:                     |
-------------------------------+-----------------------------
 I would like to submit an enhancement request for the WordPress Details
 Block. I have an education website. I have been using the WordPress
 Details block to create Learning Paths.

 I would like to request that you add more features to the Details Block.

 1. Right now, every section shows a black triangle icon pointing to the
 right for each expanded section. if you have 10 sections, it shows just 10
 triangle icons on the page. Can you make it where each detail block by
 default has an outline around the section? It would make it look like an
 accordion style section. That gives each detail block an outline boundary
 so it won't make it look like content is running together. Give it a very
 faint outline so it looks pleasing to the eye.

 2. Can the Details block be expanding into a Learning Path block? So many
 content creators are creating courses and this is forcing us to go buy 3rd
 party plugins. Most of those plugins are not good. I would prefer to use a
 native block to WordPress. The Details block is perfect for this. Giving
 it a next button to go to the next section would be great. A way to add an
 instructor's name section would be great. But the biggest request is the
 next button.

 I am not sure if these enhancements would work with the Details block. If
 not,

 please consider adding a Learning Path block to WordPress.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65105>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 12:34:04 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 12:34:04 -0000
Subject: [wp-trac] [WordPress Trac] #64324: Tests: Reduce usage of
 assertEquals for 7.0
In-Reply-To: <058.0c6ac395ada262d47afdbd8f4b684483@wordpress.org>
References: <058.0c6ac395ada262d47afdbd8f4b684483@wordpress.org>
Message-ID: <073.84c58b5ff89434dd86bcf207973a0285@wordpress.org>

#64324: Tests: Reduce usage of assertEquals for 7.0
--------------------------------------+-------------------------------
 Reporter:  SergeyBiryukov            |       Owner:  (none)
     Type:  task (blessed)            |      Status:  closed
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests  |     Focuses:  coding-standards
--------------------------------------+-------------------------------

Comment (by SergeyBiryukov):

 In [changeset:"62248" 62248]:
 {{{
 #!CommitTicketReference repository="" revision="62248"
 Tests: Use `assertSame()` in `WP_AI_Client_Prompt_Builder` tests.

 This ensures that not only the return values match the expected results,
 but also that their type is the same.

 Going forward, stricter type checking by using `assertSame()` should
 generally be preferred to `assertEquals()` where appropriate, to make the
 tests more reliable.

 Follow-up to [61700].

 Props sagardeshmukh.
 See #64324.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64324#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 12:34:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 12:34:29 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.0969768367a9a7e92490d02353700219@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
-----------------------------+------------------------------
 Reporter:  shatrumyatra     |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Administration   |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  has-screenshots  |     Focuses:  ui
-----------------------------+------------------------------
Changes (by ekla):

 * Attachment "Chrome Screen Options Screenshot.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 12:34:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 12:34:55 -0000
Subject: [wp-trac] [WordPress Trac] #65105: Details Block - Enhancement
 Request
In-Reply-To: <050.87c17924a66786e661708ecaabdc0354@wordpress.org>
References: <050.87c17924a66786e661708ecaabdc0354@wordpress.org>
Message-ID: <065.982ad4a4c328867f0e01bcbe0de31abf@wordpress.org>

#65105: Details Block - Enhancement Request
-------------------------------+------------------------------
 Reporter:  mowill             |       Owner:  (none)
     Type:  enhancement        |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Posts, Post Types  |     Version:  6.9.4
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:
-------------------------------+------------------------------
Changes (by mowill):

 * Attachment "Screenshot 2026-04-21 at 8.34.22 AM.png" added.

 Example of using the Details Block

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65105>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 12:40:15 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 12:40:15 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.a88b57a4b7392738ae720a06bb980f9c@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
-----------------------------+------------------------------
 Reporter:  shatrumyatra     |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Administration   |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  has-screenshots  |     Focuses:  ui
-----------------------------+------------------------------

Comment (by ekla):

 Tested this on:

 - WordPress version: 6.9
 - PHP version: 8.2.4 (XAMPP)
 - Browser: Brave [[Image(Screenshot 2026-04-21 at 5.46.03 PM.png)]]
 - Browser: Chrome [[Image(Chrome Screen Options Screenshot.png)]]

 Steps followed:
 1. Open the **Plugins**
 2. Clicked **Screen Options**
 3. Entered 999 in **Number of items per page** field.

 Result:
 Could not reproduce the issue. Everything works as expected.

 Can you please confirm:
 - If any plugins are active?
 - If this happens on a default theme?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 12:40:41 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 12:40:41 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.bd938b1b6496f87d27d4e6fc108a03aa@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
-----------------------------+------------------------------
 Reporter:  shatrumyatra     |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Administration   |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  has-screenshots  |     Focuses:  ui
-----------------------------+------------------------------
Changes (by khushdoms):

 * Attachment "Screenshot 2026-04-21 175826.png" added.

 screenshot1

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 12:41:35 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 12:41:35 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.c0d104e2ad6c54d87e70f0dd26856aea@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
-----------------------------+------------------------------
 Reporter:  shatrumyatra     |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Administration   |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  has-screenshots  |     Focuses:  ui
-----------------------------+------------------------------

Comment (by khushdoms):

 Tested this issue in my local environment and was not able to reproduce
 the problem.

 === Environment ===
 - WordPress: 6.9.4
 - PHP: 8.2.27
 - Server: nginx/1.26.1
 - Database: mysqli (Server: 8.0.35 / Client: mysqlnd 8.2.27)
 - Browser: Chrome 147.0.0.0
 - OS: Windows 10/11
 - Theme: Divi 5.0.0-public-alpha.5
 - MU Plugins: None
 - Plugins:
   * Test Reports 1.2.1
   * WooCommerce 10.7.0

 Steps followed:
 1. Opened Posts screen
 2. Opened Screen Options
 3. Entered values like 999 and 1000 in "Number of items per page"

 Result:
 - All digits are fully visible inside the input field
 - No clipping or truncation observed

 Additional notes:
 Tested with both 3-digit and 4-digit values, and the input field adjusted
 correctly.

 It appears the issue is not reproducible in this environment. This might
 be browser-specific, zoom-level related, or dependent on a different
 setup.

 [[Image(Screenshot 2026-04-21 175826.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 12:41:36 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 12:41:36 -0000
Subject: [wp-trac] [WordPress Trac] #65106: Learning Path Block -
 Enhancement Request
Message-ID: <050.cf1234bb28b7e92e115a808ef591d68c@wordpress.org>

#65106: Learning Path Block - Enhancement Request
--------------------------+-----------------------------
 Reporter:  mowill        |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Post Formats  |    Version:  6.9.4
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 I would like to submit an enhancement request for a WordPress Learning
 Path Block. I have an education website. I have a big need for a way to
 create a learning path with using core blocks in WordPress.

 The Details block is the closest I have come to something that looks like
 it could be styled into a course format.


 Here is what I am requesting for the new WordPress Learning Path Block:

 1. An instructor section
 2. A learning path course outline section
 3. A Next button to go to the next section
 4. Ways to add paragraphs and access to add video links and images
 5. This would be a content block for a page and a post.


 Yes, there are many 3rd party plugins out there on the market, but they
 all are expensive and have problems. There are so many people using
 WordPress that need a course format, since it's 2026, why not give us that
 option native to WordPress?

 Thanks,

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65106>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 12:41:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 12:41:56 -0000
Subject: [wp-trac] [WordPress Trac] #65106: Learning Path Block -
 Enhancement Request
In-Reply-To: <050.cf1234bb28b7e92e115a808ef591d68c@wordpress.org>
References: <050.cf1234bb28b7e92e115a808ef591d68c@wordpress.org>
Message-ID: <065.2daf2bb9375ee77d8de23264dbae756d@wordpress.org>

#65106: Learning Path Block - Enhancement Request
--------------------------+------------------------------
 Reporter:  mowill        |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Post Formats  |     Version:  6.9.4
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Changes (by mowill):

 * Attachment "Screenshot 2026-04-21 at 8.34.22 AM.png" added.

 Example of using a Details block for a Learning Path Course

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65106>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 12:45:01 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 12:45:01 -0000
Subject: [wp-trac] [WordPress Trac] #65106: Learning Path Block -
 Enhancement Request
In-Reply-To: <050.cf1234bb28b7e92e115a808ef591d68c@wordpress.org>
References: <050.cf1234bb28b7e92e115a808ef591d68c@wordpress.org>
Message-ID: <065.4fbc44b4b3aa4e23f9ce402feaf1400d@wordpress.org>

#65106: Learning Path Block - Enhancement Request
--------------------------+------------------------------
 Reporter:  mowill        |       Owner:  (none)
     Type:  enhancement   |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Post Formats  |     Version:  6.9.4
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Changes (by mowill):

 * type:  defect (bug) => enhancement


Comment:

 My apologies, the type for this ticket should be a feature request.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65106#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 13:10:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 13:10:49 -0000
Subject: [wp-trac] [WordPress Trac] #65063: Classic Editor: slug editing
 field is too large
In-Reply-To: <053.e99112fe2c6dd2520e9b55ab9e698a2b@wordpress.org>
References: <053.e99112fe2c6dd2520e9b55ab9e698a2b@wordpress.org>
Message-ID: <068.9400c82d2290cd29d3cefc1521325d71@wordpress.org>

#65063: Classic Editor: slug editing field is too large
------------------------------------+------------------------
 Reporter:  wildworks               |       Owner:  joedolson
     Type:  defect (bug)            |      Status:  accepted
 Priority:  normal                  |   Milestone:  7.0
Component:  Administration          |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  admin-reskin has-patch  |     Focuses:
------------------------------------+------------------------

Comment (by tusharaddweb):

 Tested and confirmed that the slug input field height is currently too
 large compared to surrounding elements.

 Refer below images for confirm.

 Before Patch:
 https://postimg.cc/PCcGHqfK

 After Patch:
 https://postimg.cc/wyM0jXWs

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65063#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 13:17:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 13:17:05 -0000
Subject: [wp-trac] [WordPress Trac] #65094: AI: Prompt construction
 fails with fatal error when wp_ai_client_default_request_timeout filter
 returns negative number
In-Reply-To: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
References: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
Message-ID: <070.9b61f5586380ae0f9818595805707c8d@wordpress.org>

#65094: AI: Prompt construction fails with fatal error when
wp_ai_client_default_request_timeout filter returns negative number
--------------------------------------+--------------------------
 Reporter:  westonruter               |       Owner:  westonruter
     Type:  defect (bug)              |      Status:  assigned
 Priority:  normal                    |   Milestone:  7.0
Component:  AI                        |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+--------------------------

Comment (by gaurangsondagar):

 **Patch Testing Report**

 **Patch Tested**: https://core.trac.wordpress.org/ticket/65094

 **Environment:**
 - WordPress: 7.0 RC2
 - PHP: 8.2.x
 - Server: Apache
 - Browser: Chrome
 - OS: Ubuntu

 **Test Summary:**
 - Set up the WordPress Core 7.0 RC2 locally
 - Applied the wp_ai_client_default_request_timeout filter in the theme's
 functions.php and tested the possible cases.


 **Result:**
 **The patch is working as expected**. It has been validated successfully
 and does not produce any fatal errors when applied correctly.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65094#comment:21>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 13:18:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 13:18:48 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.46596e518c0706b68d90b746d11270c9@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
---------------------------------------+------------------------------
 Reporter:  shatrumyatra               |       Owner:  (none)
     Type:  defect (bug)               |      Status:  new
 Priority:  normal                     |   Milestone:  Awaiting Review
Component:  Administration             |     Version:
 Severity:  normal                     |  Resolution:
 Keywords:  has-screenshots has-patch  |     Focuses:  ui
---------------------------------------+------------------------------
Changes (by shatrumyatra):

 * Attachment "patch-65104.diff" added.

 Created patch

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 13:30:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 13:30:05 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.e105cd48a42dea057753ed6328ca4493@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
---------------------------------------+------------------------------
 Reporter:  shatrumyatra               |       Owner:  (none)
     Type:  defect (bug)               |      Status:  new
 Priority:  normal                     |   Milestone:  Awaiting Review
Component:  Administration             |     Version:
 Severity:  normal                     |  Resolution:
 Keywords:  has-screenshots has-patch  |     Focuses:  ui
---------------------------------------+------------------------------

Comment (by shatrumyatra):

 Replying to [comment:3 khushdoms]:

 I tested in below environment.

 == Environment

 WordPress: 7.0-beta6
 PHP : 8.2.26
 Browser : Mozilla Firefox
 OS : MacOS

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 13:53:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 13:53:09 -0000
Subject: [wp-trac] [WordPress Trac] #42281: Better Update Management for
 Translation files (was: No Autoupdate for Translation files)
In-Reply-To: <050.e140f337402133addd4e8ac7df251fa4@wordpress.org>
References: <050.e140f337402133addd4e8ac7df251fa4@wordpress.org>
Message-ID: <065.a97cb0fe236aabd627fd56961477e7d6@wordpress.org>

#42281: Better Update Management for Translation files
-------------------------------------------------+-------------------------
 Reporter:  stk_jj                               |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Upgrade/Install                      |     Version:  4.8.2
 Severity:  normal                               |  Resolution:
 Keywords:  2nd-opinion has-patch has-unit-      |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------
Changes (by Jyria):

 * type:  defect (bug) => enhancement


Comment:

 Playground test passed with additional commit
 (https://github.com/WordPress/wordpress-
 develop/pull/11610#issuecomment-4287467328). PR ready for merge.
 Thanks for considering.

 [[Image(https://isla-
 stud.io/img_cloud/wordpress_trac_pr_11610_complete.png)]]

 https://github.com/WordPress/wordpress-
 develop/pull/11610/commits/c8dd62d7aefca11064dd725e5be1ddea51570812

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/42281#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 13:53:37 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 13:53:37 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.63549b6f3c4b0ca11019687b6182c793@wordpress.org>

#65015: Connectors: Several strings are not translated
-------------------------------------------------+-------------------------
 Reporter:  369work                              |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  reviewing
 Priority:  high                                 |   Milestone:  7.0
Component:  I18N                                 |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests connectors  |     Focuses:
  commit dev-feedback                            |
-------------------------------------------------+-------------------------

Comment (by manzoorwani.jk):

 I have simplified the PR description and updated the test instructions. It
 should now be much easier to test the changes.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015#comment:22>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 13:58:24 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 13:58:24 -0000
Subject: [wp-trac] [WordPress Trac] #58559: Database error bug in
 wordpress current version
In-Reply-To: <054.f5d54a0bacfd288f7b3c70b37dea6e0e@wordpress.org>
References: <054.f5d54a0bacfd288f7b3c70b37dea6e0e@wordpress.org>
Message-ID: <069.7b8a9b2840560771f7bf37de9c8a7b40@wordpress.org>

#58559: Database error bug in wordpress current version
--------------------------+------------------------------
 Reporter:  zoddshop63    |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Database      |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by juzar):

 Hi @zoddshop63,

 Could you share a bit more about your environment?
 - MySQL/MariaDB version?
 - Approximate number of posts in your `wp_posts` table?
 - PHP version and `max_execution_time` setting?

 I tried reproducing this on the latest version of WordPress but was unable
 to.

 Regarding `SQL_CALC_FOUND_ROWS`: this function can become very slow on
 large sites with many posts. It has to count all matching rows before
 applying the `LIMIT`, which on a big table can take long enough for PHP to
 time out mid-query. This is a known limitation and there are existing
 discussions in core around making it more efficient.

 ---
 "For anyone landing here with the same issue: the "no quit sent" symptom
 typically points to PHP terminating the script before WordPress could
 close the MySQL connection — not a core bug. Also worth trying: swap
 `DB_HOST` in `wp-config.php` between `localhost` and `127.0.0.1` — if the
 errors stop, the issue is with your connection method."

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/58559#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 14:04:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 14:04:17 -0000
Subject: [wp-trac] [WordPress Trac] #31992: Unicode Email Addresses
In-Reply-To: <051.16751f510c50d601687f280dca71804a@wordpress.org>
References: <051.16751f510c50d601687f280dca71804a@wordpress.org>
Message-ID: <066.6256c7affcc36e85685b70aca9e02098@wordpress.org>

#31992: Unicode Email Addresses
-------------------------------------------------+-------------------------
 Reporter:  ysalame                              |       Owner:
                                                 |  SergeyBiryukov
     Type:  defect (bug)                         |      Status:  accepted
 Priority:  normal                               |   Milestone:  7.1
Component:  Formatting                           |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-test-info has-patch has-         |     Focuses:
  screenshots has-unit-tests dev-feedback early  |
-------------------------------------------------+-------------------------

Comment (by dmsnell):

 In [changeset:"62249" 62249]:
 {{{
 #!CommitTicketReference repository="" revision="62249"
 Tests: Print invalid UTF-8 as ASCII to fix hosts test reporting failures.

 When serializing test output into XML, invalid UTF-8 bytes lead to a
 failure to load those test results when they are read. This patch adds
 code to remap those invalid bytes in an ASCII-readable form, whereas the
 invalid bytes are separated by parentheses and encoded in their hex form.

 This ensures that a proper XML file is generated from the testing results.

 Developed in: https://github.com/WordPress/wordpress-develop/pull/11620
 Discussed in: https://core.trac.wordpress.org/ticket/31992
 Reported in: https://github.com/WordPress/phpunit-test-runner/pull/310

 Follow-up to: [62225].

 Props agulbra, amykamala, codexdemon, dmsnell, mywp459, rolle.
 See #31992.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/31992#comment:93>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 14:04:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 14:04:31 -0000
Subject: [wp-trac] [WordPress Trac] #42281: Better Update Management for
 Translation files
In-Reply-To: <050.e140f337402133addd4e8ac7df251fa4@wordpress.org>
References: <050.e140f337402133addd4e8ac7df251fa4@wordpress.org>
Message-ID: <065.da9e633b44fe7de304bce208f4f6dfd2@wordpress.org>

#42281: Better Update Management for Translation files
-------------------------------------------------+-------------------------
 Reporter:  stk_jj                               |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Upgrade/Install                      |     Version:  4.8.2
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests has-        |     Focuses:
  screenshots                                    |
-------------------------------------------------+-------------------------
Changes (by Jyria):

 * keywords:  2nd-opinion has-patch has-unit-tests => has-patch has-unit-
     tests has-screenshots


Comment:

 Ticket Properties modified to better reflect its status.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/42281#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 14:41:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 14:41:17 -0000
Subject: [wp-trac] [WordPress Trac] #64917: WP 7.0 Connectors: unclear
 error message
In-Reply-To: <051.50e3faafb74ba8eaaede21fb888645f0@wordpress.org>
References: <051.50e3faafb74ba8eaaede21fb888645f0@wordpress.org>
Message-ID: <066.999a8c05b90c02ab030874bd6314aed5@wordpress.org>

#64917: WP 7.0 Connectors: unclear error message
---------------------------------+----------------------
 Reporter:  ecairol              |       Owner:  (none)
     Type:  defect (bug)         |      Status:  new
 Priority:  normal               |   Milestone:  7.0.1
Component:  AI                   |     Version:  trunk
 Severity:  normal               |  Resolution:
 Keywords:  ai-client has-patch  |     Focuses:  ui-copy
---------------------------------+----------------------
Changes (by ozgursar):

 * Attachment "generate-image-error-message-64917.jpg" added.

 Generate Image error message

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64917>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 14:43:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 14:43:14 -0000
Subject: [wp-trac] [WordPress Trac] #64917: WP 7.0 Connectors: unclear
 error message
In-Reply-To: <051.50e3faafb74ba8eaaede21fb888645f0@wordpress.org>
References: <051.50e3faafb74ba8eaaede21fb888645f0@wordpress.org>
Message-ID: <066.e97d9316edca67f83d26133736242ab7@wordpress.org>

#64917: WP 7.0 Connectors: unclear error message
-------------------------------------------------+----------------------
 Reporter:  ecairol                              |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  7.0.1
Component:  AI                                   |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  ai-client has-patch has-screenshots  |     Focuses:  ui-copy
-------------------------------------------------+----------------------
Changes (by ozgursar):

 * keywords:  ai-client has-patch => ai-client has-patch has-screenshots


Comment:

 == Reproduction Report

 === Environment
 - WordPress: 7.1-alpha-62249
 - PHP: 8.3.30
 - Server: PHP.wasm
 - Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
 - Browser: Chrome 147.0.0.0
 - OS: macOS
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None activated
 - Plugins:
   * AI 0.7.0
   * Test Reports 1.2.1

 === Steps taken
 1. ''Settings > Connectors'', click the ''Install the AI plugin'' button
 2. ''Settings > AI'', toggle ''Enable AI'' then enable ''Image Generation
 and Editing''
 3. Create a post and add an image
 4. Click ''Generate Image''
 5. Type a prompt and click Generate
 6. Observe the message `Image generation failed. Please ensure you have a
 connected provider that supports image generation.`
 7. ❌ Bug is not occurring

 === Expected behavior
 - We expect to see a clear error message stating why Image Generation is
 not available.

 === Additional Notes
 - This could have been fixed with another ticket.

 === Screenshots/Screencast with results
 [[Image(https://core.trac.wordpress.org/raw-attachment/ticket/64917
 /generate-image-error-message-64917.jpg)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64917#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 14:52:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 14:52:31 -0000
Subject: [wp-trac] [WordPress Trac] #65102:
 WP_MS_Users_List_Table::display_rows() should emit id="user-{ID}" on <tr>
 to match WP_Users_List_Table
In-Reply-To: <048.33f8455008cefea3e2c683f5eab2b5b0@wordpress.org>
References: <048.33f8455008cefea3e2c683f5eab2b5b0@wordpress.org>
Message-ID: <063.69627279532d7cd8b3239d02db3fc2f2@wordpress.org>

#65102: WP_MS_Users_List_Table::display_rows() should emit id="user-{ID}" on <tr>
to match WP_Users_List_Table
------------------------------+----------------------------------------
 Reporter:  dd32              |       Owner:  johnjamesjacoby
     Type:  defect (bug)      |      Status:  accepted
 Priority:  normal            |   Milestone:  7.1
Component:  Users             |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  has-patch commit  |     Focuses:  administration, multisite
------------------------------+----------------------------------------
Changes (by johnjamesjacoby):

 * keywords:  has-patch => has-patch commit
 * owner:  (none) => johnjamesjacoby
 * status:  new => accepted


Comment:

 This makes sense and the diff looks great 👍

 Setting myself as owner to commit soon, but any committer should if you’d
 like 💫

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65102#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 14:53:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 14:53:39 -0000
Subject: [wp-trac] [WordPress Trac] #65044: get_post_custom_values()
 missing array check, inconsistent with get_post_custom_keys()
In-Reply-To: <057.4a59bcc730ee55ef2108915dd95410cb@wordpress.org>
References: <057.4a59bcc730ee55ef2108915dd95410cb@wordpress.org>
Message-ID: <072.f016c525919919af9d0eab4677954962@wordpress.org>

#65044: get_post_custom_values() missing array check, inconsistent with
get_post_custom_keys()
-------------------------------------------------+-------------------------
 Reporter:  saratheonline                        |       Owner:
                                                 |  saratheonline
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  7.1
Component:  Posts, Post Types                    |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing needs-unit-  |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------

Comment (by darshitrajyaguru97):

 == Additional Testing & Validation ==

 I’ve tested this behavior on PHP 8.2 with `E_ALL` enabled and can confirm
 the inconsistency described in this ticket.

 While `get_post_custom_values()` does not produce a fatal error and
 ultimately returns `null`, it still attempts to access an array offset on
 a non-array value when `get_post_custom()` fails.

 Example test:

 {{{
 add_action( 'wp_ajax_test_65044', function() {
     $id = 999999; // Non-existent post ID
     $values = get_post_custom_values( 'some_key', $id );

     var_dump( error_reporting() );

     wp_send_json_success( array( 'result' => $values ) );
 });
 }}}

 In this case, `get_post_custom()` returns `false` (or an empty string),
 and `get_post_custom_values()` proceeds with:

 {{{
 $custom[ $key ]
 }}}

 This results in an invalid offset access on a boolean/string value.
 Although PHP 8+ may not always surface it visibly (depending on error
 handling), it still constitutes a silent failure and violates defensive
 coding practices.

 === **Consistency with Sibling Function ===

 The related function `get_post_custom_keys()` already includes a
 safeguard:

 {{{
 if ( ! is_array( $custom ) ) {
     return;
 }
 }}}

 Adding the same `is_array()` check in `get_post_custom_values()` would:

 * Prevent invalid offset access at the logic level
 * Align behavior with its sibling function
 * Avoid silent failures under stricter error reporting environments

 === **Recommendation ===

 Introduce a defensive check before accessing the array:

 {{{
 $custom = get_post_custom( $post_id );

 if ( ! is_array( $custom ) ) {
     return null;
 }

 return isset( $custom[ $key ] ) ? $custom[ $key ] : null;
 }}}

 This is a minimal, backward-compatible fix that improves robustness and
 consistency across the API.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65044#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 15:36:59 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 15:36:59 -0000
Subject: [wp-trac] [WordPress Trac] #65053: Media upload from the post
 edit screen shows an inaccurate number when uploading multiple media files
In-Reply-To: <053.9dbb6fc319de35dce28f39fb3ef8f2fb@wordpress.org>
References: <053.9dbb6fc319de35dce28f39fb3ef8f2fb@wordpress.org>
Message-ID: <068.2525a7e3f80f61ab3866a857c24bec61@wordpress.org>

#65053: Media upload from the post edit screen shows an inaccurate number when
uploading multiple media files
--------------------------+------------------------------
 Reporter:  Dharm1025     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Upload        |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  ui, javascript
--------------------------+------------------------------
Changes (by ozgursar):

 * Attachment "65053-before-PR-11585.png" added.

 Before patch 11585

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65053>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 15:37:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 15:37:12 -0000
Subject: [wp-trac] [WordPress Trac] #65053: Media upload from the post
 edit screen shows an inaccurate number when uploading multiple media files
In-Reply-To: <053.9dbb6fc319de35dce28f39fb3ef8f2fb@wordpress.org>
References: <053.9dbb6fc319de35dce28f39fb3ef8f2fb@wordpress.org>
Message-ID: <068.01b547bfd39bfff00cfdafc18ede6db3@wordpress.org>

#65053: Media upload from the post edit screen shows an inaccurate number when
uploading multiple media files
--------------------------+------------------------------
 Reporter:  Dharm1025     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Upload        |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  ui, javascript
--------------------------+------------------------------
Changes (by ozgursar):

 * Attachment "65053-after-PR-11585.png" added.

 After patch 11585

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65053>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 15:42:04 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 15:42:04 -0000
Subject: [wp-trac] [WordPress Trac] #65053: Media upload from the post
 edit screen shows an inaccurate number when uploading multiple media files
In-Reply-To: <053.9dbb6fc319de35dce28f39fb3ef8f2fb@wordpress.org>
References: <053.9dbb6fc319de35dce28f39fb3ef8f2fb@wordpress.org>
Message-ID: <068.7ac3b840219e9087bc15e10fed9ef340@wordpress.org>

#65053: Media upload from the post edit screen shows an inaccurate number when
uploading multiple media files
--------------------------+------------------------------
 Reporter:  Dharm1025     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Upload        |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  ui, javascript
--------------------------+------------------------------

Comment (by ozgursar):

 == Patch Testing Report

 Patch Tested: https://github.com/WordPress/wordpress-develop/pull/11585

 === Environment
 - WordPress: 7.1-alpha-62161-src
 - PHP: 8.2.29
 - Server: nginx/1.29.4
 - Database: mysqli (Server: 8.4.7 / Client: mysqlnd 8.2.29)
 - Browser: Opera
 - OS: macOS
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None activated
 - Plugins:
   * Test Reports 1.2.1

 === Steps taken
 1. Create a new post
 2. Click on ``Set featured image``
 3. Go to ``Upload files`` and upload multiple files
 4. Observe **incorrect** image count (e.g. `Showing 7 of 8 media items`)
 5. Apply the patch
 6. Repeat steps 2-4
 7. Observe **correct** image count (e.g. `Showing 7 of 7 media items`)
 8. ✅ Patch is solving the problem

 === Expected result
 - While uploading we should see the correct number of images

 === Screenshots/Screencast with results
 Before patch
 [[Image(https://core.trac.wordpress.org/raw-attachment/ticket/65053/65053
 -before-PR-11585.png)]]

 After patch
 [[Image(https://core.trac.wordpress.org/raw-attachment/ticket/65053/65053
 -after-PR-11585.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65053#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 15:57:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 15:57:16 -0000
Subject: [wp-trac] [WordPress Trac] #65063: Classic Editor: slug editing
 field is too large
In-Reply-To: <053.e99112fe2c6dd2520e9b55ab9e698a2b@wordpress.org>
References: <053.e99112fe2c6dd2520e9b55ab9e698a2b@wordpress.org>
Message-ID: <068.b3dadde37c7ba6c53298787ad01a2458@wordpress.org>

#65063: Classic Editor: slug editing field is too large
------------------------------------+------------------------
 Reporter:  wildworks               |       Owner:  joedolson
     Type:  defect (bug)            |      Status:  accepted
 Priority:  normal                  |   Milestone:  7.0
Component:  Administration          |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  admin-reskin has-patch  |     Focuses:
------------------------------------+------------------------
Changes (by khushdoms):

 * Attachment "65063_before.png" added.

 before patch apply

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65063>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 15:57:34 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 15:57:34 -0000
Subject: [wp-trac] [WordPress Trac] #65063: Classic Editor: slug editing
 field is too large
In-Reply-To: <053.e99112fe2c6dd2520e9b55ab9e698a2b@wordpress.org>
References: <053.e99112fe2c6dd2520e9b55ab9e698a2b@wordpress.org>
Message-ID: <068.97b7f23158ebb62b2f4cf5ddd69988b6@wordpress.org>

#65063: Classic Editor: slug editing field is too large
------------------------------------+------------------------
 Reporter:  wildworks               |       Owner:  joedolson
     Type:  defect (bug)            |      Status:  accepted
 Priority:  normal                  |   Milestone:  7.0
Component:  Administration          |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  admin-reskin has-patch  |     Focuses:
------------------------------------+------------------------
Changes (by khushdoms):

 * Attachment "65063_after.png" added.

 after patch apply

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65063>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 15:58:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 15:58:18 -0000
Subject: [wp-trac] [WordPress Trac] #65063: Classic Editor: slug editing
 field is too large
In-Reply-To: <053.e99112fe2c6dd2520e9b55ab9e698a2b@wordpress.org>
References: <053.e99112fe2c6dd2520e9b55ab9e698a2b@wordpress.org>
Message-ID: <068.2ab140efd8a405bf2577136860b0e247@wordpress.org>

#65063: Classic Editor: slug editing field is too large
------------------------------------+------------------------
 Reporter:  wildworks               |       Owner:  joedolson
     Type:  defect (bug)            |      Status:  accepted
 Priority:  normal                  |   Milestone:  7.0
Component:  Administration          |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  admin-reskin has-patch  |     Focuses:
------------------------------------+------------------------

Comment (by khushdoms):

 Tested the patch and confirmed the issue is resolved.

 == Test Report ==
 === Description
 This report validates whether the indicated patch works as expected.

 Patch tested: (add patch link here)

 === Environment
 - WordPress: 7.1-alpha-62161-src
 - PHP: 8.3.30
 - Server: nginx/1.29.7
 - Database: mysqli (Server: 8.4.8 / Client: mysqlnd 8.3.30)
 - Browser: Chrome 147.0.0.0
 - OS: Windows 10/11
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None
 - Plugins:
   * Disable Gutenberg 3.3.1
   * Test Reports 1.2.1

 === Steps to Reproduce
 1. Open Add New Post screen
 2. Edit the permalink (slug)
 3. Observe input field height and alignment

 === Before Patch
 - Slug input field height is larger than surrounding elements
 - Buttons (OK/Cancel) are not properly aligned ❌

 [[Image(65063_before.png, 600px)]]

 === After Patch
 - Input field height is consistent (32px)
 - Buttons are properly aligned
 - UI appears clean and consistent ✅

 [[Image(65063_after.png, 600px)]]

 === Actual Results
 - Issue resolved successfully with the patch
 - No regressions observed

 === Additional Notes
 - Tested at standard zoom (100%)
 - UI remains consistent during interaction

 Conclusion:
 Patch works as expected 👍

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65063#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 16:22:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 16:22:26 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.c95cd191c91ebaf8401d715d9647e85c@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
---------------------------------------+---------------------
 Reporter:  shatrumyatra               |       Owner:  (none)
     Type:  defect (bug)               |      Status:  new
 Priority:  normal                     |   Milestone:  7.0
Component:  Administration             |     Version:  trunk
 Severity:  normal                     |  Resolution:
 Keywords:  has-screenshots has-patch  |     Focuses:  ui
---------------------------------------+---------------------
Changes (by sabernhardt):

 * version:   => trunk
 * milestone:  Awaiting Review => 7.0


Comment:

 #64547 increased the padding to 12 pixels (from 8 pixels on larger screens
 and 10 pixels on narrower screens).

 PR 11619 and patch-65104.diff reduce the left padding back to 8 pixels, at
 any screen size.

 Additional options:
 1. Increase the [https://github.com/WordPress/wordpress-
 develop/blob/4440667d806019cbe9b9e67fad6836b0d74cce6d/src/wp-admin/css
 /list-tables.css#L827 4em width] to 5em, without reducing the padding. The
 field would appear below the label on narrow screens more often, but not
 //too// often.
 2. Add the `small-text` class in the HTML for consistency with other small
 input fields. Then `.screen-per-page` would not require its own `width`
 rule (or padding rules).

 I'm setting the milestone to 7.0, but 7.0.1 could fit too.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 16:49:00 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 16:49:00 -0000
Subject: [wp-trac] [WordPress Trac] #64227: GitHub Actions updates and
 improvements for 7.0
In-Reply-To: <051.dfd030059aed6944df19897a3ad57008@wordpress.org>
References: <051.dfd030059aed6944df19897a3ad57008@wordpress.org>
Message-ID: <066.b1cf407f7f2b32eb32f155858301721e@wordpress.org>

#64227: GitHub Actions updates and improvements for 7.0
------------------------------+---------------------
 Reporter:  desrosj           |       Owner:  (none)
     Type:  task (blessed)    |      Status:  closed
 Priority:  normal            |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:
 Severity:  normal            |  Resolution:  fixed
 Keywords:  has-patch         |     Focuses:
------------------------------+---------------------

Comment (by johnbillion):

 In [changeset:"62250" 62250]:
 {{{
 #!CommitTicketReference repository="" revision="62250"
 Build/Test Tools: Add more workflow file linting with Zizmor.

 This change introduces Zizmor, which is a tool for linting GitHub Actions
 workflow files for security weaknesses. This compliments the existing
 Actionlint scanning.

 For more information about Actionlint and Zizmor, see the GitHub Actions
 Workflow Standards page in the developer handbook:
 https://developer.wordpress.org/coding-standards/wordpress-coding-
 standards/github-actions/

 Some issues in workflow files that are reported by Zizmor will be
 addressed in follow-up commits.

 Props johnbillion, desrosj.

 See #64227
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64227#comment:35>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 16:56:50 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 16:56:50 -0000
Subject: [wp-trac] [WordPress Trac] #64227: GitHub Actions updates and
 improvements for 7.0
In-Reply-To: <051.dfd030059aed6944df19897a3ad57008@wordpress.org>
References: <051.dfd030059aed6944df19897a3ad57008@wordpress.org>
Message-ID: <066.312d35f4e875ca901ffbed4ea2de688f@wordpress.org>

#64227: GitHub Actions updates and improvements for 7.0
------------------------------+---------------------
 Reporter:  desrosj           |       Owner:  (none)
     Type:  task (blessed)    |      Status:  closed
 Priority:  normal            |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:
 Severity:  normal            |  Resolution:  fixed
 Keywords:  has-patch         |     Focuses:
------------------------------+---------------------

Comment (by johnbillion):

 In [changeset:"62251" 62251]:
 {{{
 #!CommitTicketReference repository="" revision="62251"
 Build/Test Tools: Address some issues in GitHub Actions workflow files as
 reported by Zizmor.

 This removes unnecessarily broad inheritance of secrets, replaces some
 GitHub Actions expressions with environment variables, removes git
 credential persistence, and adds documentation to the readme.

 See #64227
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64227#comment:36>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 16:58:47 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 16:58:47 -0000
Subject: [wp-trac] [WordPress Trac] #64227: GitHub Actions updates and
 improvements for 7.0
In-Reply-To: <051.dfd030059aed6944df19897a3ad57008@wordpress.org>
References: <051.dfd030059aed6944df19897a3ad57008@wordpress.org>
Message-ID: <066.826d2cea1d64a2e5cac7696b24d2fd74@wordpress.org>

#64227: GitHub Actions updates and improvements for 7.0
------------------------------+---------------------
 Reporter:  desrosj           |       Owner:  (none)
     Type:  task (blessed)    |      Status:  closed
 Priority:  normal            |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:
 Severity:  normal            |  Resolution:  fixed
 Keywords:  has-patch         |     Focuses:
------------------------------+---------------------

Comment (by johnbillion):

 In [changeset:"62252" 62252]:
 {{{
 #!CommitTicketReference repository="" revision="62252"
 Build/Test Tools: Update Actionlint to the latest version.

 See #64227
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64227#comment:37>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 17:24:41 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 17:24:41 -0000
Subject: [wp-trac] [WordPress Trac] #64227: GitHub Actions updates and
 improvements for 7.0
In-Reply-To: <051.dfd030059aed6944df19897a3ad57008@wordpress.org>
References: <051.dfd030059aed6944df19897a3ad57008@wordpress.org>
Message-ID: <066.cbf64109b2c7200190c074ad2697d9d5@wordpress.org>

#64227: GitHub Actions updates and improvements for 7.0
------------------------------+---------------------
 Reporter:  desrosj           |       Owner:  (none)
     Type:  task (blessed)    |      Status:  closed
 Priority:  normal            |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:
 Severity:  normal            |  Resolution:  fixed
 Keywords:  has-patch         |     Focuses:
------------------------------+---------------------

Comment (by johnbillion):

 In [changeset:"62253" 62253]:
 {{{
 #!CommitTicketReference repository="" revision="62253"
 Build/Test Tools: Remove unnecessary use of GitHub Actions expressions for
 values that resolve to "true" or "false" strings.

 See #64227
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64227#comment:39>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 17:33:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 17:33:18 -0000
Subject: [wp-trac] [WordPress Trac] #42712: Enhance wp revisions to keep
 with expiration date for the revisions
In-Reply-To: <051.b16c9f0a8dbaa6dbe5bdeab598d26d2a@wordpress.org>
References: <051.b16c9f0a8dbaa6dbe5bdeab598d26d2a@wordpress.org>
Message-ID: <066.9829c686de28320c01f8bc99b7e5cb70@wordpress.org>

#42712: Enhance wp revisions to keep with expiration date for the revisions
-----------------------------+-------------------------
 Reporter:  colomet          |       Owner:  (none)
     Type:  feature request  |      Status:  closed
 Priority:  normal           |   Milestone:
Component:  Revisions        |     Version:
 Severity:  normal           |  Resolution:  maybelater
 Keywords:                   |     Focuses:
-----------------------------+-------------------------
Changes (by adamsilverstein):

 * status:  new => closed
 * resolution:   => maybelater
 * milestone:  Awaiting Review =>


Comment:

 I checked and there are a number of plugins already available to control
 revisions and at least one included a date based control (none super
 popular):

 https://wordpress.org/plugins/tags/revision/

 Given the lack of activity here, I'm going to close this as "not planned"
 as part of my revisions component cleanup.

 Feel free to reopen this ticket should you wish to propose a solution.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/42712#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 17:33:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 17:33:39 -0000
Subject: [wp-trac] [WordPress Trac] #65098: get_site_icon_url() returns
 empty string even when fallback is defined,
 breaking wp-embed-site-icon in the_embed_site_title()
In-Reply-To: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
References: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
Message-ID: <069.569b982bf178afdbfb31a8d27c0a3503@wordpress.org>

#65098: get_site_icon_url() returns empty string even when fallback is defined,
breaking wp-embed-site-icon in the_embed_site_title()
-------------------------------------+---------------------
 Reporter:  pontocinza               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  7.1
Component:  Embeds                   |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch has-test-info  |     Focuses:
-------------------------------------+---------------------
Changes (by abcd95):

 * keywords:  has-patch => has-patch has-test-info


Comment:

 == Test Report

 === Description
 This report validates whether the indicated patch works as expected.
 Patch tested: https://github.com/WordPress/wordpress-develop/pull/11601

 === Environment
 - WordPress: 7.1-alpha-62161-src
 - PHP: 8.3.30
 - Server: nginx/1.29.8
 - Database: mysqli (Server: 8.4.8 / Client: mysqlnd 8.3.30)
 - Browser: Chrome 147.0.0.0
 - OS: macOS
 - Theme: Twenty Twenty-Five 1.4

 === Reproduction Steps

 1. Created a test post ("Test Embed Post") and visited
 `/?p={postID}&embed=true`
 2. Simulated broken get_site_icon_url()
    via add_filter( 'get_site_icon_url', '__return_empty_string' )
 3. Confirmed bug: <img src="" srcset=" 2x"> in the embed footer
 4. Applied patch from PR #11601
 5. Re-tested the same embed URL

 === Actual Results

 ✅ The issue is resolved after applying the patch.


 === Supplemental Artifacts

 Before patch

 [[Image(https://i.ibb.co/Y7vF0mhc/Screenshot-2026-04-21-at-22-49-06.png)]]

 After patch

 [[Image(https://i.ibb.co/XrdB3Stg/Screenshot-2026-04-21-at-22-48-04.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65098#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 17:43:36 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 17:43:36 -0000
Subject: [wp-trac] [WordPress Trac] #64227: GitHub Actions updates and
 improvements for 7.0
In-Reply-To: <051.dfd030059aed6944df19897a3ad57008@wordpress.org>
References: <051.dfd030059aed6944df19897a3ad57008@wordpress.org>
Message-ID: <066.9baba34161155b50160723336be47a63@wordpress.org>

#64227: GitHub Actions updates and improvements for 7.0
------------------------------+---------------------
 Reporter:  desrosj           |       Owner:  (none)
     Type:  task (blessed)    |      Status:  closed
 Priority:  normal            |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:
 Severity:  normal            |  Resolution:  fixed
 Keywords:  has-patch         |     Focuses:
------------------------------+---------------------

Comment (by johnbillion):

 In [changeset:"62254" 62254]:
 {{{
 #!CommitTicketReference repository="" revision="62254"
 Build/Test Tools: Use the exact tag name in version number comments that
 trail pinned actions.

 None of these actions use `v`-prefixed tag names.

 See #64227
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64227#comment:40>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 17:47:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 17:47:29 -0000
Subject: [wp-trac] [WordPress Trac] #64393: Change how we include
 Gutenberg in Core
In-Reply-To: <055.264b0dba638f7c3f5a9d3208ee755072@wordpress.org>
References: <055.264b0dba638f7c3f5a9d3208ee755072@wordpress.org>
Message-ID: <070.e8420347cfd97d55900d1e851cf46c6e@wordpress.org>

#64393: Change how we include Gutenberg in Core
------------------------------+--------------------------
 Reporter:  youknowriad       |       Owner:  youknowriad
     Type:  task (blessed)    |      Status:  closed
 Priority:  high              |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:
 Severity:  blocker           |  Resolution:  fixed
 Keywords:  has-patch         |     Focuses:
------------------------------+--------------------------

Comment (by davidbaumwald):

 Ran into something similar today when running `npm run build` on `trunk`.
 In Windows, when `gutenberg:download` is called and `tar` tries to
 extract, the path is invalid:

 {{{
 📥 Downloading and extracting artifact...
 tar: F\:\\WordPress Core
 Develop\\develop.svn.wordpress.org\trunk\\gutenberg: Cannot open: No such
 file or directory
 tar: Error is not recoverable: exiting now
 ❌ Download/extraction failed: write EPIPE
 }}}

 So, in my case using Git Bash/MSYS2 any path with a colon is treated as a
 network path, so it's adding the double slash.

 I asked Claude, and it seems the tar args can be tweaked to swap out `-C`
 with `cwd`.  This is [https://github.com/WordPress/wordpress-
 develop/blob/trunk/tools/gutenberg/download.js#L116
 tools/gutenberg/download.js line 119]:
 {{{
 const tar = spawn( 'tar', [ '-x' ], {
     cwd: gutenbergDir,
     stdio: [ 'pipe', 'inherit', 'inherit' ],
 } );
 }}}

 After this change was applied, the `gutenberg:verify` task completed
 successfully and the build proceeded.  Unsure how this change affects
 other envs.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64393#comment:255>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 17:54:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 17:54:07 -0000
Subject: [wp-trac] [WordPress Trac] #65107: Twenty Sixteen: italics lost in
 'blockquote cite'
Message-ID: <056.76190b8b93b06d61c688feba76f9b9c9@wordpress.org>

#65107: Twenty Sixteen: italics lost in 'blockquote cite'
--------------------------+-----------------------------
 Reporter:  gaelbonithon  |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Themes        |    Version:  trunk
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 Whether you use italics or not in `blockquote cite`, the result is the
 same, both in the editor and in the final output. There should be a
 difference, one way or another (italics or regular text, depending on the
 overall font style).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65107>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 18:00:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 18:00:18 -0000
Subject: [wp-trac] [WordPress Trac] #65108: Twenty Sixteen: barely visible
 bold text in a blockquote
Message-ID: <056.b4f29e9067554142b8542b27cd2c3419@wordpress.org>

#65108: Twenty Sixteen: barely visible bold text in a blockquote
--------------------------+-----------------------------
 Reporter:  gaelbonithon  |      Owner:  (none)
     Type:  enhancement   |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Themes        |    Version:  trunk
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 The current code is

 {{{
 #!css
 blockquote strong,
 blockquote b {
   font-weight: 400;
 }
 }}}

 , which makes very little difference. It seems to me that this would be
 better:
 {{{
 #!css
 blockquote strong,
 blockquote b {
   font-weight: bold;
 }
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65108>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 18:07:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 18:07:31 -0000
Subject: [wp-trac] [WordPress Trac] #65050: REST API: Comments
 controller returns 403 instead of 404 for invalid post ID in update_item()
In-Reply-To: <057.d01cd307fcdefb847d0c0d7b8f496018@wordpress.org>
References: <057.d01cd307fcdefb847d0c0d7b8f496018@wordpress.org>
Message-ID: <072.193118db15c6a1783593858486a5d54b@wordpress.org>

#65050: REST API: Comments controller returns 403 instead of 404 for invalid post
ID in update_item()
-----------------------------------------+-------------------------------
 Reporter:  saratheonline                |       Owner:  saratheonline
     Type:  defect (bug)                 |      Status:  assigned
 Priority:  normal                       |   Milestone:  7.1
Component:  REST API                     |     Version:  trunk
 Severity:  normal                       |  Resolution:
 Keywords:  has-patch changes-requested  |     Focuses:  coding-standards
-----------------------------------------+-------------------------------
Changes (by r1k0):

 * keywords:  has-patch needs-testing changes-requested => has-patch
     changes-requested


Comment:

 == Patch Testing Report

 Patch Tested: Link to the diff patch or GitHub Pull Request

 === Environment
 - WordPress: 7.1-alpha-62161-src
 - PHP: 8.3.30
 - Server: nginx/1.29.5
 - Database: mysqli (Server: 8.4.8 / Client: mysqlnd 8.3.30)
 - Browser: Chrome 147.0.0.0
 - OS: Windows 10/11
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None activated
 - Plugins:
   * Test Reports 1.2.1

 === Steps taken
 1. Ensure you have the **Application password** from "Users > Profile".
 2. In your terminal, run this command:
 {{{
 curl -X POST http://localhost:8889/wp-json/wp/v2/comments/1 \
 -u "admin" \
 -H "Content-Type: application/json" \
 -d '{"post": 9999}'
 }}}
 3. You'll be prompted to enter a password. Enter the password you got from
 **Application Password**.
 4. Perform steps 2 - 3 before and after applying the patch.
 5. ✅ Patch is solving the problem.
 === Expected result
 - A 404 status code response is returned when you try to update with a
 non-existent post ID.

 === Additional Notes
 - Patch fixes the issues, updating keywords (removing "needs-testing").
 Add it back if needed.

 === Screenshots/Screencast with results
 - Before:
 [[Image(https://i.ibb.co/5W6Sygw9/status-code-403.png)]]
 - After:
 [[Image(https://i.ibb.co/fdPmcTnR/status-code-404.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65050#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 18:39:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 18:39:53 -0000
Subject: [wp-trac] [WordPress Trac] #65108: Twenty Sixteen: barely
 visible bold text in 'blockquote' (was: Twenty Sixteen: barely visible bold
 text in a blockquote)
In-Reply-To: <056.b4f29e9067554142b8542b27cd2c3419@wordpress.org>
References: <056.b4f29e9067554142b8542b27cd2c3419@wordpress.org>
Message-ID: <071.a87785f38c0da72964cca81f6c55455b@wordpress.org>

#65108: Twenty Sixteen: barely visible bold text in 'blockquote'
--------------------------+------------------------------
 Reporter:  gaelbonithon  |       Owner:  (none)
     Type:  enhancement   |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Themes        |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+------------------------------

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65108#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 18:41:19 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 18:41:19 -0000
Subject: [wp-trac] [WordPress Trac] #64982: library should be changed to
 media library in core or needs gettext
In-Reply-To: <052.6ebe4cf636d68ac01de1c591e6c35312@wordpress.org>
References: <052.6ebe4cf636d68ac01de1c591e6c35312@wordpress.org>
Message-ID: <067.4e21fd5b6586104aaafb605cffc533ef@wordpress.org>

#64982: library should be changed to media library in core or needs gettext
--------------------------+---------------------
 Reporter:  timse201      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  I18N          |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+---------------------

Comment (by SergeyBiryukov):

 Replying to [comment:5 audrasjb]:
 > This fixes the issue, but I'd rather add a context for both strings.

 It appears that the other instance would need to be changed in Gutenberg,
 so I think [https://github.com/WordPress/wordpress-develop/pull/11404 PR
 11404] is good to go for core.

 Nitpicking: I would suggest `media library menu item` as the context (no
 capitalization), that would be consistent with a few existing admin menu
 strings:
 * `_x( 'Editor', 'site editor menu item' )`
 * `_x( 'Design', 'design menu item' )`
 * `_x( 'Patterns', 'patterns menu item' )`

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64982#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 21:34:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 21:34:13 -0000
Subject: [wp-trac] [WordPress Trac] #65105: Details Block - Enhancement
 Request
In-Reply-To: <050.87c17924a66786e661708ecaabdc0354@wordpress.org>
References: <050.87c17924a66786e661708ecaabdc0354@wordpress.org>
Message-ID: <065.f07dd35e5ec4de3c6cc6bab1ebf15900@wordpress.org>

#65105: Details Block - Enhancement Request
-------------------------------+------------------------------
 Reporter:  mowill             |       Owner:  (none)
     Type:  enhancement        |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Posts, Post Types  |     Version:  6.9.4
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:
-------------------------------+------------------------------

Comment (by westonruter):

 So a Next button which collapses the enclosing Details block, expands the
 next Details block, and scrolls it into view?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65105#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 21:36:32 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 21:36:32 -0000
Subject: [wp-trac] [WordPress Trac] #65107: Twenty Sixteen: italics lost
 in 'blockquote cite'
In-Reply-To: <056.76190b8b93b06d61c688feba76f9b9c9@wordpress.org>
References: <056.76190b8b93b06d61c688feba76f9b9c9@wordpress.org>
Message-ID: <071.59a214ee1dc13595b55625c6ccb7ee3d@wordpress.org>

#65107: Twenty Sixteen: italics lost in 'blockquote cite'
---------------------------+------------------------------
 Reporter:  gaelbonithon   |       Owner:  (none)
     Type:  defect (bug)   |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  Bundled Theme  |     Version:  trunk
 Severity:  normal         |  Resolution:
 Keywords:  has-patch      |     Focuses:  css
---------------------------+------------------------------
Changes (by westonruter):

 * focuses:   => css
 * component:  Themes => Bundled Theme


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65107#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 21:36:58 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 21:36:58 -0000
Subject: [wp-trac] [WordPress Trac] #65108: Twenty Sixteen: barely
 visible bold text in 'blockquote'
In-Reply-To: <056.b4f29e9067554142b8542b27cd2c3419@wordpress.org>
References: <056.b4f29e9067554142b8542b27cd2c3419@wordpress.org>
Message-ID: <071.a17669f486c67c141dd2f97f4bb0fbfe@wordpress.org>

#65108: Twenty Sixteen: barely visible bold text in 'blockquote'
---------------------------+------------------------------
 Reporter:  gaelbonithon   |       Owner:  (none)
     Type:  enhancement    |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  Bundled Theme  |     Version:  trunk
 Severity:  normal         |  Resolution:
 Keywords:  has-patch      |     Focuses:  css
---------------------------+------------------------------
Changes (by westonruter):

 * focuses:   => css
 * component:  Themes => Bundled Theme


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65108#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 21 21:55:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 21 Apr 2026 21:55:28 -0000
Subject: [wp-trac] [WordPress Trac] #65105: Details Block - Enhancement
 Request
In-Reply-To: <050.87c17924a66786e661708ecaabdc0354@wordpress.org>
References: <050.87c17924a66786e661708ecaabdc0354@wordpress.org>
Message-ID: <065.7028ac96829c7fb08eb26c2b3dd4aab7@wordpress.org>

#65105: Details Block - Enhancement Request
-------------------------------+------------------------------
 Reporter:  mowill             |       Owner:  (none)
     Type:  enhancement        |      Status:  new
 Priority:  normal             |   Milestone:  Awaiting Review
Component:  Posts, Post Types  |     Version:  6.9.4
 Severity:  normal             |  Resolution:
 Keywords:                     |     Focuses:
-------------------------------+------------------------------

Comment (by mowill):

 Replying to [comment:1 westonruter]:
 > So a Next button which collapses the enclosing Details block, expands
 the next Details block, and scrolls it into view?


 Yes, that works.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65105#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 01:14:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 01:14:53 -0000
Subject: [wp-trac] [WordPress Trac] #64904: Real time collboration:
 determine approach for opt in setting for users in Settings > Writing
In-Reply-To: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
References: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
Message-ID: <067.3e7ee3dfd985fb6f480eb714f4e80ac0@wordpress.org>

#64904: Real time collboration: determine approach for opt in setting for users in
Settings > Writing
------------------------------------+---------------------
 Reporter:  annezazu                |       Owner:  (none)
     Type:  task (blessed)          |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-design has-patch  |     Focuses:  ui
------------------------------------+---------------------

Comment (by peterwilsoncc):

 @fcoveram If the host has disabled the feature, should we remove the new
 tag? There's not much point drawing attention to a new setting the site
 owner can not enable. As an alternative, we could fade it out.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64904#comment:42>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 01:20:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 01:20:16 -0000
Subject: [wp-trac] [WordPress Trac] #65098: get_site_icon_url() returns
 empty string even when fallback is defined,
 breaking wp-embed-site-icon in the_embed_site_title()
In-Reply-To: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
References: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
Message-ID: <069.faf183e0a7103b7720630409dd5b03e1@wordpress.org>

#65098: get_site_icon_url() returns empty string even when fallback is defined,
breaking wp-embed-site-icon in the_embed_site_title()
-------------------------------------+---------------------
 Reporter:  pontocinza               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  7.1
Component:  Embeds                   |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch has-test-info  |     Focuses:
-------------------------------------+---------------------

Comment (by pontocinza):

 Where is the like button?  =)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65098#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 04:10:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 04:10:12 -0000
Subject: [wp-trac] [WordPress Trac] #65098: get_site_icon_url() returns
 empty string even when fallback is defined,
 breaking wp-embed-site-icon in the_embed_site_title()
In-Reply-To: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
References: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
Message-ID: <069.722b5d1829f8b2098e5ff78d8fac5114@wordpress.org>

#65098: get_site_icon_url() returns empty string even when fallback is defined,
breaking wp-embed-site-icon in the_embed_site_title()
-------------------------------------------------+-------------------------
 Reporter:  pontocinza                           |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  7.1
Component:  Embeds                               |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-test-info needs-unit-  |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------
Changes (by westonruter):

 * keywords:  has-patch has-test-info => has-patch has-test-info needs-unit-
     tests


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65098#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 04:39:34 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 04:39:34 -0000
Subject: [wp-trac] [WordPress Trac] #65108: Twenty Sixteen: barely
 visible bold text in 'blockquote'
In-Reply-To: <056.b4f29e9067554142b8542b27cd2c3419@wordpress.org>
References: <056.b4f29e9067554142b8542b27cd2c3419@wordpress.org>
Message-ID: <071.2585b7fe8b7ddc70ba2d9c95f956e2c2@wordpress.org>

#65108: Twenty Sixteen: barely visible bold text in 'blockquote'
-------------------------------------------------+-------------------------
 Reporter:  gaelbonithon                         |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Bundled Theme                        |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-test-info has-         |     Focuses:  css
  screenshots                                    |
-------------------------------------------------+-------------------------
Changes (by JayDeep Nimavat):

 * keywords:  has-patch => has-patch has-test-info has-screenshots


Comment:

 == Test Report
 === Description
 This report validates whether the indicated patch works as expected.

 Patch tested: https://github.com/WordPress/wordpress-develop/pull/11623

 === Environment
 - WordPress: 7.0-RC2-62242
 - PHP: 8.3.30
 - Server: nginx/1.26.1
 - Database: mysqli (Server: 8.0.35 / Client: mysqlnd 8.3.30)
 - Browser: Chrome 146.0.0.0
 - OS: macOS
 - Theme: Twenty Sixteen 3.7
 - MU Plugins: None activated
 - Plugins:
   * AI 0.7.0
   * Test Reports 1.2.1
   * WordPress Beta Tester 4.0.0
   * WPMozo Blocks and Addons 1.7.0
   * WPMozo Blocks and Addons Pro 1.0.0

 === Actual Results
 1.  ✅ Issue resolved with patch.

 === Additional Notes
 - Any additional details worth mentioning.

 === Supplemental Artifacts
 Before: https://ibb.co/qL9zhk4P
 After: https://ibb.co/1fr8tsyJ

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65108#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 04:55:52 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 04:55:52 -0000
Subject: [wp-trac] [WordPress Trac] #65103: Single-page admin screens
 (Connectors,
 Font Library) fail to mount in Chrome when @wordpress/boot wins a race
 against its classic-script deps
In-Reply-To: <055.fd5b7dce505f7cac5b5fa322aadd0fb6@wordpress.org>
References: <055.fd5b7dce505f7cac5b5fa322aadd0fb6@wordpress.org>
Message-ID: <070.1efad252f5366276142f2b0fcfad2579@wordpress.org>

#65103: Single-page admin screens (Connectors, Font Library) fail to mount in
Chrome when @wordpress/boot wins a race against its classic-script deps
-------------------------------------------------+-------------------------
 Reporter:  fabiankaegy                          |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  7.0
Component:  Script Loader                        |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  script-modules has-patch changes-    |     Focuses:
  requested                                      |  administration
-------------------------------------------------+-------------------------
Changes (by westonruter):

 * keywords:  script-modules has-patch => script-modules has-patch changes-
     requested


Comment:

 Let's avoid committing minified JS and lean into modern JS syntax (e.g.
 const and async/await).

 For example, using the JS code in the PR, this is much easier to read and
 debug, thanks to IDEs being able to do syntax checking (although Trac
 doesn't do syntax highlighting of the JS):


 {{{#!php
 <?php
 $init_js_function = <<<JS
         ( mountId, routes ) => {
                 const run = async () => {
                         const mod = await import( "@wordpress/boot" );
                         mod.initSinglePage( { mountId, routes } );
                 };
                 if ( document.readyState === "loading" ) {
                         document.addEventListener( "DOMContentLoaded", run
 );
                 } else {
                         run();
                 }
         }
 JS;
 wp_add_inline_script(
         $mount_id . '-prerequisites',
         sprintf(
                 '( %s )( %s, %s )',
                 $init_js_function,
                 wp_json_encode( $mount_id ),
                 wp_json_encode( $routes, JSON_HEX_TAG |
 JSON_UNESCAPED_SLASHES )
         )
 );
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65103#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 06:20:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 06:20:30 -0000
Subject: [wp-trac] [WordPress Trac] #65102:
 WP_MS_Users_List_Table::display_rows() should emit id="user-{ID}" on <tr>
 to match WP_Users_List_Table
In-Reply-To: <048.33f8455008cefea3e2c683f5eab2b5b0@wordpress.org>
References: <048.33f8455008cefea3e2c683f5eab2b5b0@wordpress.org>
Message-ID: <063.bb699ba0333b988adad26d41bfdd1251@wordpress.org>

#65102: WP_MS_Users_List_Table::display_rows() should emit id="user-{ID}" on <tr>
to match WP_Users_List_Table
------------------------------+----------------------------------------
 Reporter:  dd32              |       Owner:  johnjamesjacoby
     Type:  defect (bug)      |      Status:  accepted
 Priority:  normal            |   Milestone:  7.1
Component:  Users             |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  has-patch commit  |     Focuses:  administration, multisite
------------------------------+----------------------------------------

Comment (by alexodiy):

 Tested PR [https://github.com/WordPress/wordpress-develop/pull/11600
 #11600] on a multisite install against trunk.

 == Environment ==

 * WordPress: trunk (multisite enabled)
 * Environment: `wordpress-develop` Docker stack (`npm run env:install`
 with `LOCAL_MULTISITE=true`)
 * Test users: 4 network users (IDs 1-4) with mixed roles

 == Test plan (per @dd32, comment:1) ==

 1. Load `wp-admin/network/users.php` and confirm each `<tr>` carries
 `id="user-{ID}"`.
 2. Confirm per-site `wp-admin/users.php` is unchanged.

 == Results ==

 '''Before patch (trunk):'''

 On `wp-admin/network/users.php`, every `<tr>` in the users table renders
 without an `id` attribute. Bug confirmed.

 '''After patch:'''

 On `wp-admin/network/users.php`, every `<tr>` renders with
 `id="user-{ID}"` matching the user's numeric ID:

 {{{
 <tr id="user-1" class="alternate">
 <tr id="user-2">
 <tr id="user-3" class="alternate">
 <tr id="user-4">
 }}}

 Per-site `wp-admin/users.php` is unaffected - the existing
 `id="user-{ID}"` continues to render as before (handled by
 `WP_Users_List_Table`, untouched).

 ||= Scenario =||= Before Patch =||= After Patch =||
 || `network/users.php` `<tr>` id || missing || `id="user-{ID}"` present ||
 || per-site `users.php` `<tr>` id || `id="user-{ID}"` || `id="user-{ID}"`
 (unchanged) ||

 The `(int)` cast on `$user->ID` is a sensible defensive measure given
 `WP_User::$ID` is untyped (see inline discussion on the PR).

 Patch looks correct and minimal. +1 for commit.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65102#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 07:04:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 07:04:39 -0000
Subject: [wp-trac] [WordPress Trac] #65107: Twenty Sixteen: italics lost
 in 'blockquote cite'
In-Reply-To: <056.76190b8b93b06d61c688feba76f9b9c9@wordpress.org>
References: <056.76190b8b93b06d61c688feba76f9b9c9@wordpress.org>
Message-ID: <071.9f1e349d916dfcc1b097f58a68f51cb8@wordpress.org>

#65107: Twenty Sixteen: italics lost in 'blockquote cite'
---------------------------+------------------------------
 Reporter:  gaelbonithon   |       Owner:  (none)
     Type:  defect (bug)   |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  Bundled Theme  |     Version:  trunk
 Severity:  normal         |  Resolution:
 Keywords:  has-patch      |     Focuses:  css
---------------------------+------------------------------

Comment (by manhar):

 Tested and patch is working as expected.

 Refer the below image:

 Before Patch:
 https://postimg.cc/XpfbjS1n

 After Patch:
 https://postimg.cc/NKFpNRHZ

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65107#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 07:09:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 07:09:39 -0000
Subject: [wp-trac] [WordPress Trac] #65102:
 WP_MS_Users_List_Table::display_rows() should emit id="user-{ID}" on <tr>
 to match WP_Users_List_Table
In-Reply-To: <048.33f8455008cefea3e2c683f5eab2b5b0@wordpress.org>
References: <048.33f8455008cefea3e2c683f5eab2b5b0@wordpress.org>
Message-ID: <063.430aed992e9ecc83aa433816f256d224@wordpress.org>

#65102: WP_MS_Users_List_Table::display_rows() should emit id="user-{ID}" on <tr>
to match WP_Users_List_Table
------------------------------+----------------------------------------
 Reporter:  dd32              |       Owner:  johnjamesjacoby
     Type:  defect (bug)      |      Status:  accepted
 Priority:  normal            |   Milestone:  7.1
Component:  Users             |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  has-patch commit  |     Focuses:  administration, multisite
------------------------------+----------------------------------------

Comment (by manhar):

 Tested in a multisite environment. The user rows in Network Admin now
 include the id="user-{ID}" attribute on the <tr> element, matching the
 behavior of the single site users table. Patch works as expected.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65102#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 07:32:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 07:32:39 -0000
Subject: [wp-trac] [WordPress Trac] #65109: Abilities API: Duplicated $args
 variable in WP_Ability_Category::prepare_properties() PHPDoc
Message-ID: <054.698909d7bfb74e6b59f9754a972627c2@wordpress.org>

#65109: Abilities API: Duplicated $args variable in
WP_Ability_Category::prepare_properties() PHPDoc
---------------------------+-----------------------------
 Reporter:  thriveteam     |      Owner:  (none)
     Type:  defect (bug)   |     Status:  new
 Priority:  normal         |  Milestone:  Awaiting Review
Component:  Abilities API  |    Version:
 Severity:  normal         |   Keywords:  has-patch
  Focuses:  docs           |
---------------------------+-----------------------------
 In src/wp-includes/abilities-api/class-wp-ability-category.php, the
 **prepare_properties()** method contains a syntax error in its PHPDoc
 block. The variable name $args is duplicated in the **@param** tag.

 **Location: class-wp-ability-category.php**

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65109>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 07:32:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 07:32:56 -0000
Subject: [wp-trac] [WordPress Trac] #65109: Abilities API: Duplicated
 $args variable in WP_Ability_Category::prepare_properties() PHPDoc
In-Reply-To: <054.698909d7bfb74e6b59f9754a972627c2@wordpress.org>
References: <054.698909d7bfb74e6b59f9754a972627c2@wordpress.org>
Message-ID: <069.036dd6a4095fd3db6df3dac9b1aa5a0c@wordpress.org>

#65109: Abilities API: Duplicated $args variable in
WP_Ability_Category::prepare_properties() PHPDoc
---------------------------+------------------------------
 Reporter:  thriveteam     |       Owner:  (none)
     Type:  defect (bug)   |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  Abilities API  |     Version:
 Severity:  normal         |  Resolution:
 Keywords:  has-patch      |     Focuses:  docs
---------------------------+------------------------------
Changes (by thriveteam):

 * Attachment "65109.diff" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65109>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 07:35:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 07:35:55 -0000
Subject: [wp-trac] [WordPress Trac] #58505: Using WORDPRESS_DB_HOST
 variable Cannot connect to the database, must be configu
In-Reply-To: <050.489c743bc419d349cf1a57df411ca4b7@wordpress.org>
References: <050.489c743bc419d349cf1a57df411ca4b7@wordpress.org>
Message-ID: <065.324e57e5991100ef287c42416f247fd3@wordpress.org>

#58505: Using WORDPRESS_DB_HOST variable Cannot connect to the database, must be
configu
--------------------------+------------------------------
 Reporter:  chentc        |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:  6.2.2
 Severity:  major         |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+------------------------------

Comment (by jdeep):

 Hi @chentc,

 I tried to reproduce the issue you were facing on Docker but couldn't. Can
 you share a bit more on what your configurations look like and how you set
 the `WORDPRESS_` env vars? If you could share your `docker-compose.yml` or
 Kubernetes manifests, that would be helpful.

 If I have to take a guess, I think your real issue is related to container
 networking. For example, if your database is running on Docker's default
 bridge network instead of a custom user-defined network, Docker's internal
 DNS won't automatically resolve container names. This means setting
 `WORDPRESS_DB_HOST` to a container name will fail, but using the raw
 database IP bypasses DNS entirely and connects
 successfully.[https://docs.docker.com/engine/network/drivers/bridge
 /#differences-between-user-defined-bridges-and-the-default-bridge See more
 here.]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/58505#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 08:30:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 08:30:48 -0000
Subject: [wp-trac] [WordPress Trac] #65110: Application Passwords: add a
 safer authorize flow for browser-based apps
Message-ID: <053.7dd1fec7fc52849a794290a6c458543d@wordpress.org>

#65110: Application Passwords: add a safer authorize flow for browser-based apps
-----------------------------------+-----------------------------
 Reporter:  alekmitch              |      Owner:  (none)
     Type:  enhancement            |     Status:  new
 Priority:  normal                 |  Milestone:  Awaiting Review
Component:  Application Passwords  |    Version:
 Severity:  normal                 |   Keywords:
  Focuses:                         |
-----------------------------------+-----------------------------
 The current wp-admin/authorize-application.php browser authorization flow
 redirects to success_url with the newly generated Application Password in
 the URL query string.

 As documented in the integration guide, the success redirect currently
 includes:
  * site_url
  * user_login
  * password

 Current core JS still implements that behavior by appending the generated
 password to the redirect URL.

 This makes the flow awkward for browser-based web applications that want
 to avoid placing plaintext credentials in browser URLs. Depending on the
 environment, a URL can be captured by browser history, session restore,
 reverse proxy or CDN logs, observability tooling, analytics middleware, or
 browser extensions before the receiving application has any chance to
 scrub it.

 I am not proposing that the existing success_url behavior be removed or
 changed by default, since that would likely break existing consumers. The
 request is for an additive, safer completion mode for browser-based
 applications.

 Possible directions could include:
  * a form_post style response mode that returns the success payload in an
 auto-submitted HTML form POST instead of query parameters
  * another non-query transport with similar properties
  * a one-time code that the receiving application can redeem server-side
 for the generated Application Password

 The key requirement is to support completing the authorization flow
 without the generated Application Password appearing in the browser URL.

 In practice, the only core-only way I found to avoid this was to omit
 success_url entirely and require the user to copy the generated password
 manually from the WordPress page into the receiving application. That
 works, but it gives up the seamless browser handoff.

 Related tickets for context:
  * #57809 and #51581 show the success_url / reject_url flow is still
 active and maintained, but they do not address the transport of the
 generated password itself
  * #61644 discusses revocation by app_id, which is related operationally
 but does not solve the callback transport problem
  * #53995 is relevant background on Application Password lifecycle, but
 does not solve this callback transport issue either

 If there is already another ticket covering a safer callback transport for
 Application Password authorization, I would be happy to move discussion
 there.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65110>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 08:36:27 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 08:36:27 -0000
Subject: [wp-trac] [WordPress Trac] #64904: Real time collboration:
 determine approach for opt in setting for users in Settings > Writing
In-Reply-To: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
References: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
Message-ID: <067.04d4c0201d74b3bc690060b2c4db4567@wordpress.org>

#64904: Real time collboration: determine approach for opt in setting for users in
Settings > Writing
------------------------------------+---------------------
 Reporter:  annezazu                |       Owner:  (none)
     Type:  task (blessed)          |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-design has-patch  |     Focuses:  ui
------------------------------------+---------------------

Comment (by fcoveram):

 > If the host has disabled the feature, should we remove the new tag?

 I don't think so. I approach this by thinking of users contacting their
 host or individuals for this. And given that we're removing it in 7.1, I'd
 say the fade-out variant is not needed.

 But I'm open to change as I might not be considering other use cases.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64904#comment:43>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 10:53:20 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 10:53:20 -0000
Subject: [wp-trac] [WordPress Trac] #65111: Twenty Sixteen: Center text in
 image captions
Message-ID: <056.c3ba973b7320165fb70c9efb0d35f5aa@wordpress.org>

#65111: Twenty Sixteen: Center text in image captions
---------------------------+-----------------------------
 Reporter:  gaelbonithon   |      Owner:  (none)
     Type:  enhancement    |     Status:  new
 Priority:  normal         |  Milestone:  Awaiting Review
Component:  Bundled Theme  |    Version:  trunk
 Severity:  normal         |   Keywords:
  Focuses:  css            |
---------------------------+-----------------------------
 It seems to me that this would be a better default choice. Ideally, we
 should be able to change it via the UI, but as far as I know, that’s not
 possible at the moment. One workaround is to use a centered paragraph via
 the code editor, which feels like a hack.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65111>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 11:57:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 11:57:39 -0000
Subject: [wp-trac] [WordPress Trac] #65111: Twenty Sixteen: Center text
 in image captions
In-Reply-To: <056.c3ba973b7320165fb70c9efb0d35f5aa@wordpress.org>
References: <056.c3ba973b7320165fb70c9efb0d35f5aa@wordpress.org>
Message-ID: <071.e0ab2c7f1655d2dce45992cc55c1b5cd@wordpress.org>

#65111: Twenty Sixteen: Center text in image captions
---------------------------+------------------------------
 Reporter:  gaelbonithon   |       Owner:  (none)
     Type:  enhancement    |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  Bundled Theme  |     Version:  trunk
 Severity:  normal         |  Resolution:
 Keywords:  has-patch      |     Focuses:  css
---------------------------+------------------------------

Comment (by manhar):

 Tested with patch and it is working as expected.

 Refer below images :

 Before Patch :
 https://postimg.cc/wRN8Tdr9

 After Patch :
 https://postimg.cc/TyKkXJFY

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65111#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 12:32:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 12:32:39 -0000
Subject: [wp-trac] [WordPress Trac] #65073: Connectors: reference to AI
 plugin uses old `ai` slug instead of correct `ai-wp-admin` slug
In-Reply-To: <052.ad97c034b09747ca93f06d7293e387ff@wordpress.org>
References: <052.ad97c034b09747ca93f06d7293e387ff@wordpress.org>
Message-ID: <067.baa193f6f5cecdf9d5c1575f4ff2c13a@wordpress.org>

#65073: Connectors: reference to AI plugin uses old `ai` slug instead of correct
`ai-wp-admin` slug
----------------------------------------+-----------------------
 Reporter:  JeffPaul                    |       Owner:  dkotter
     Type:  defect (bug)                |      Status:  assigned
 Priority:  normal                      |   Milestone:  7.0
Component:  AI                          |     Version:  trunk
 Severity:  normal                      |  Resolution:
 Keywords:  connectors has-patch close  |     Focuses:
----------------------------------------+-----------------------
Changes (by audrasjb):

 * keywords:  connectors has-patch => connectors has-patch close


Comment:

 As per today's bug scrub: looks like this is going to be fixed on the next
 Gutenberg merge. Marking this ticket as candidate for closure when it is
 properly fixed.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65073#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 12:36:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 12:36:26 -0000
Subject: [wp-trac] [WordPress Trac] #65094: AI: Prompt construction
 fails with fatal error when wp_ai_client_default_request_timeout filter
 returns negative number
In-Reply-To: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
References: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
Message-ID: <070.f40545f9ca6ec9fe29adc73b040ce75a@wordpress.org>

#65094: AI: Prompt construction fails with fatal error when
wp_ai_client_default_request_timeout filter returns negative number
--------------------------------------+--------------------------
 Reporter:  westonruter               |       Owner:  westonruter
     Type:  defect (bug)              |      Status:  assigned
 Priority:  normal                    |   Milestone:  7.0
Component:  AI                        |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+--------------------------

Comment (by audrasjb):

 As per today's bug scrub: The PR was successfully tested several times and
 approved by @justlevine. I think we're getting close to a resolution.
 @westonruter do you need more testing on this?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65094#comment:23>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 12:41:15 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 12:41:15 -0000
Subject: [wp-trac] [WordPress Trac] #65032: View transition admin bar
 quirks
In-Reply-To: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
References: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
Message-ID: <067.41df47c43f978b6e51d548ab65be6e26@wordpress.org>

#65032: View transition admin bar quirks
-------------------------------------+------------------------
 Reporter:  zieladam                 |       Owner:  audrasjb
     Type:  defect (bug)             |      Status:  reviewing
 Priority:  normal                   |   Milestone:  7.0
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  ui
-------------------------------------+------------------------
Changes (by audrasjb):

 * owner:  (none) => audrasjb
 * status:  new => reviewing


Comment:

 We now have a PR that `needs-testing`.
 I'm self assigning this ticket as it doesn't have any owner yet, but more
 tests are welcome! 🧪

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65032#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 12:46:36 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 12:46:36 -0000
Subject: [wp-trac] [WordPress Trac] #65063: Classic Editor: slug editing
 field is too large
In-Reply-To: <053.e99112fe2c6dd2520e9b55ab9e698a2b@wordpress.org>
References: <053.e99112fe2c6dd2520e9b55ab9e698a2b@wordpress.org>
Message-ID: <068.025cc6cc74d301975ebdefe97d5ccd2f@wordpress.org>

#65063: Classic Editor: slug editing field is too large
-------------------------------------------+------------------------
 Reporter:  wildworks                      |       Owner:  joedolson
     Type:  defect (bug)                   |      Status:  accepted
 Priority:  normal                         |   Milestone:  7.0
Component:  Administration                 |     Version:  trunk
 Severity:  normal                         |  Resolution:
 Keywords:  admin-reskin has-patch commit  |     Focuses:
-------------------------------------------+------------------------
Changes (by audrasjb):

 * keywords:  admin-reskin has-patch => admin-reskin has-patch commit
 * version:   => trunk


Comment:

 @wildworks thanks for updating the PR. @joedolson I think we're good to go
 now!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65063#comment:18>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 12:52:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 12:52:26 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.b5acfa954aca082e420d58e9a5003635@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
-----------------------------------------+-----------------------
 Reporter:  shatrumyatra                 |       Owner:  audrasjb
     Type:  defect (bug)                 |      Status:  accepted
 Priority:  normal                       |   Milestone:  7.0
Component:  Administration               |     Version:  trunk
 Severity:  normal                       |  Resolution:
 Keywords:  has-screenshots needs-patch  |     Focuses:  ui
-----------------------------------------+-----------------------
Changes (by audrasjb):

 * keywords:  has-screenshots has-patch => has-screenshots needs-patch
 * owner:  (none) => audrasjb
 * status:  new => accepted


Comment:

 As per today's bug scrub: To be consistent, I tend to prefer the approach
 suggested by @sabernhardt: add the `small-text` class to this input field.
 An alternative PR with this approach would be very welcome.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 12:54:25 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 12:54:25 -0000
Subject: [wp-trac] [WordPress Trac] #65098: get_site_icon_url() returns
 empty string even when fallback is defined,
 breaking wp-embed-site-icon in the_embed_site_title()
In-Reply-To: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
References: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
Message-ID: <069.c298e5d242b1ef2bdde75c09c5ccb5a1@wordpress.org>

#65098: get_site_icon_url() returns empty string even when fallback is defined,
breaking wp-embed-site-icon in the_embed_site_title()
-------------------------------------------------+-------------------------
 Reporter:  pontocinza                           |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  7.1
Component:  Embeds                               |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-test-info needs-unit-  |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------

Comment (by manhar):

 Tested the patch successfully. The site icon now displays correctly in
 oEmbed cards instead of showing a broken image. The fallback to wp-logo-
 blue.png also works as expected when the icon is unavailable. The
 malformed srcset issue is also resolved.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65098#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 13:09:34 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 13:09:34 -0000
Subject: [wp-trac] [WordPress Trac] #64589: Navigation overlay: backport
 patterns and template part definition
In-Reply-To: <053.ec615ae22b92b37322d43a1bb40e3ddd@wordpress.org>
References: <053.ec615ae22b92b37322d43a1bb40e3ddd@wordpress.org>
Message-ID: <068.fe7c88afc7140ac5dae9eda245354901@wordpress.org>

#64589: Navigation overlay: backport patterns and template part definition
---------------------------------------+------------------------
 Reporter:  onemaggie                  |       Owner:  scruffian
     Type:  enhancement                |      Status:  reopened
 Priority:  normal                     |   Milestone:  7.0
Component:  General                    |     Version:  trunk
 Severity:  normal                     |  Resolution:
 Keywords:  has-patch gutenberg-merge  |     Focuses:
---------------------------------------+------------------------

Comment (by audrasjb):

 As per today's bug scrub:
 @wildworks this one was committed to trunk before 7.0 was branched, so I
 assume it can be closed as fixed?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64589#comment:22>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 13:11:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 13:11:28 -0000
Subject: [wp-trac] [WordPress Trac] #64904: Real time collboration:
 determine approach for opt in setting for users in Settings > Writing
In-Reply-To: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
References: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
Message-ID: <067.420c4353d63c0562a48e64595103b967@wordpress.org>

#64904: Real time collboration: determine approach for opt in setting for users in
Settings > Writing
------------------------------------+--------------------------------
 Reporter:  annezazu                |       Owner:  (none)
     Type:  task (blessed)          |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-design has-patch  |     Focuses:  ui, accessibility
------------------------------------+--------------------------------
Changes (by audrasjb):

 * focuses:  ui => ui, accessibility


Comment:

 As per today's bug scrub:
 The design shared right after comment:41 introduces some accessibility
 issues. The text is not enough contrasted. Adding `accessibility` focus so
 we can make sure to check the final implementation before committing it.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64904#comment:45>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 13:11:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 13:11:56 -0000
Subject: [wp-trac] [WordPress Trac] #64904: Real time collboration:
 determine approach for opt in setting for users in Settings > Writing
In-Reply-To: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
References: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
Message-ID: <067.f64fcc585d5ecdb911b86b0190dc51a1@wordpress.org>

#64904: Real time collboration: determine approach for opt in setting for users in
Settings > Writing
------------------------------------+--------------------------------
 Reporter:  annezazu                |       Owner:  (none)
     Type:  task (blessed)          |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  Administration          |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-design has-patch  |     Focuses:  ui, accessibility
------------------------------------+--------------------------------
Changes (by audrasjb):

 * component:  General => Administration


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64904#comment:46>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 13:23:35 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 13:23:35 -0000
Subject: [wp-trac] [WordPress Trac] #65032: View transition admin bar
 quirks
In-Reply-To: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
References: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
Message-ID: <067.e11746b23e3ada03b512a8d826b36568@wordpress.org>

#65032: View transition admin bar quirks
----------------------------+------------------------
 Reporter:  zieladam        |       Owner:  audrasjb
     Type:  defect (bug)    |      Status:  reviewing
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:  ui
----------------------------+------------------------
Changes (by nikunj8866):

 * keywords:  has-patch needs-testing => has-patch


Comment:

 == Test Report
 === Description
 ✅ This report validates that the indicated patch works as expected.

 Patch tested: https://github.com/WordPress/wordpress-develop/pull/11582

 === Environment
 - WordPress: 7.1-alpha-20260416.035027
 - PHP: 7.4.33
 - Server: PHP.wasm
 - Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
 - Browser: Chrome 147.0.0.0
 - OS: Windows 10/11
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None activated
 - Plugins:
   * Test Reports 1.2.1

 === Steps to Test
 1. Open the pull request: https://github.com/WordPress/wordpress-
 develop/pull/11582
 2. Click "Test this pull request with WordPress Playground." to launch
 WordPress Playground.
 3. Navigate between admin pages with similar sidebars:
    Dashboard > Posts > Pages
 4. Observe the sidebar during navigation transitions.

 === Actual Results
 1.  ✅ Issue resolved with patch.
 2. The admin sidebar should remain visually stable during navigation.

 === Supplemental Artifacts
 Before Patch:
 https://www.awesomescreenshot.com/video/51776620?key=76470c3ab3ab51bc2d86bdbab37c53cd
 After Patch:
 https://www.awesomescreenshot.com/video/51776671?key=6079e6fdbfcfe82cd66485a3f9683a2d

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65032#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 13:26:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 13:26:21 -0000
Subject: [wp-trac] [WordPress Trac] #64917: WP 7.0 Connectors: unclear
 error message
In-Reply-To: <051.50e3faafb74ba8eaaede21fb888645f0@wordpress.org>
References: <051.50e3faafb74ba8eaaede21fb888645f0@wordpress.org>
Message-ID: <066.57a9a6e4f748ccdc0c000b85063a008f@wordpress.org>

#64917: WP 7.0 Connectors: unclear error message
-------------------------------------------------+----------------------
 Reporter:  ecairol                              |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  7.0.1
Component:  AI                                   |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  ai-client has-patch has-screenshots  |     Focuses:  ui-copy
-------------------------------------------------+----------------------

Comment (by JeffPaul):

 @jorgefilipecosta @gziolo this looks ready for your review, potential
 commit

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64917#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 13:29:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 13:29:39 -0000
Subject: [wp-trac] [WordPress Trac] #65099: Fix: Only auto register
 settings if the plugin the connector references is installed and active
In-Reply-To: <060.0b8a8e3426646ee12db1e6e829f3d840@wordpress.org>
References: <060.0b8a8e3426646ee12db1e6e829f3d840@wordpress.org>
Message-ID: <075.97d5e0ef88050f8139a59d08866a5fd3@wordpress.org>

#65099: Fix: Only auto register settings if the plugin the connector references is
installed and active
--------------------------------------+---------------------
 Reporter:  jorgefilipecosta          |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  General                   |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by JeffPaul):

 @gziolo this looks like its ready for review and consideration for commit

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65099#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 13:31:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 13:31:23 -0000
Subject: [wp-trac] [WordPress Trac] #65020: Connectors: Support custom
 plugin is_active callback in connector registry and plugin status output
In-Reply-To: <055.d405075069acea8d9ef2197fb71ff599@wordpress.org>
References: <055.d405075069acea8d9ef2197fb71ff599@wordpress.org>
Message-ID: <070.fec4c8795deef860ccb4ef816badb9d2@wordpress.org>

#65020: Connectors: Support custom plugin is_active callback in connector registry
and plugin status output
-----------------------------------------------+---------------------------
 Reporter:  iamadisingh                        |       Owner:  (none)
     Type:  defect (bug)                       |      Status:  new
 Priority:  normal                             |   Milestone:  Awaiting
                                               |  Review
Component:  AI                                 |     Version:  trunk
 Severity:  normal                             |  Resolution:
 Keywords:  connectors dev-feedback has-patch  |     Focuses:
-----------------------------------------------+---------------------------

Comment (by JeffPaul):

 @jorgefilipecosta @gziolo this looks ready for your review

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65020#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 13:53:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 13:53:14 -0000
Subject: [wp-trac] [WordPress Trac] #65112: Docs: Correct typos in JS inline
 comments and docblocks
Message-ID: <056.e43e8e69989dc2ac5bb7184eef947c80@wordpress.org>

#65112: Docs: Correct typos in JS inline comments and docblocks
--------------------------+-----------------------------
 Reporter:  parinpanjari  |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  REST API      |    Version:
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 Five typos exist in WordPress-authored JavaScript comments and docblocks
 under `src/js/_enqueues/`:

 1. `src/js/_enqueues/wp/api.js:986` — "add nince and pagination support"
    should be "nonce". (The next docblock line correctly uses "nonce",
    confirming the intent.)

 2. `src/js/_enqueues/wp/api.js:1291` — "Clear the parent part of the
    rouite if its actually the version string" should be "route" (and
    "its" → "it's"). Both are fixed in the attached patch.

 3. `src/js/_enqueues/wp/customize/controls.js:593` — "Dates not beung
    allowed for revisions..." should be "being".

 4. `src/js/_enqueues/wp/customize/nav-menus.js:3542` — docblock says
    `returning a "unnammed" fallback string` — should be "unnamed". The
    actual code at line 3553 correctly references `l10n.unnamed`, so the
    docblock is currently quoting the wrong spelling.

 5. `src/js/_enqueues/lib/admin-bar.js:420` — "Get the closest matching
    elent" should be "element".

 The attached patch updates only the authoritative `_enqueues` sources.
 The corresponding build artifacts under `src/wp-admin/js/` and
 `src/wp-includes/js/` are regenerated by `grunt` and are .gitignored.

 Adjacent issue (not included in this patch): line 593 of controls.js
 also contains an "are is" grammar error ("...for revisions are is a
 technical limitation..."). Happy to fold into this patch or address in
 a follow-up per committer preference.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65112>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 13:53:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 13:53:56 -0000
Subject: [wp-trac] [WordPress Trac] #65112: Docs: Correct typos in JS
 inline comments and docblocks
In-Reply-To: <056.e43e8e69989dc2ac5bb7184eef947c80@wordpress.org>
References: <056.e43e8e69989dc2ac5bb7184eef947c80@wordpress.org>
Message-ID: <071.837afc17b75cd78b4ae6a3d5199f11d9@wordpress.org>

#65112: Docs: Correct typos in JS inline comments and docblocks
--------------------------+------------------------------
 Reporter:  parinpanjari  |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  REST API      |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Changes (by parinpanjari):

 * Attachment "ticket-1-js-docblock-typos.diff" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65112>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 13:54:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 13:54:48 -0000
Subject: [wp-trac] [WordPress Trac] #65113: Docs: Fix "objecct" typo in
 WP_Query post-loading comment
Message-ID: <056.8e6848da33c5e7e2ecec69a32eb25d52@wordpress.org>

#65113: Docs: Fix "objecct" typo in WP_Query post-loading comment
--------------------------+-----------------------------
 Reporter:  parinpanjari  |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Customize     |    Version:
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 `src/wp-includes/class-wp-query.php:3806` contains a typo in an inline
 comment:

     * Partial objecct queried.

 Should be "object". Patch attached.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65113>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 13:54:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 13:54:56 -0000
Subject: [wp-trac] [WordPress Trac] #65113: Docs: Fix "objecct" typo in
 WP_Query post-loading comment
In-Reply-To: <056.8e6848da33c5e7e2ecec69a32eb25d52@wordpress.org>
References: <056.8e6848da33c5e7e2ecec69a32eb25d52@wordpress.org>
Message-ID: <071.f72a1efbd3fa47986c7478b7e171df65@wordpress.org>

#65113: Docs: Fix "objecct" typo in WP_Query post-loading comment
--------------------------+------------------------------
 Reporter:  parinpanjari  |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Customize     |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------
Changes (by parinpanjari):

 * Attachment "ticket-2-class-wp-query-objecct.diff" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65113>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 13:56:02 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 13:56:02 -0000
Subject: [wp-trac] [WordPress Trac] #65112: Docs: Correct typos in JS
 inline comments and docblocks
In-Reply-To: <056.e43e8e69989dc2ac5bb7184eef947c80@wordpress.org>
References: <056.e43e8e69989dc2ac5bb7184eef947c80@wordpress.org>
Message-ID: <071.90fc10a3962c72a0d639db412ee6028b@wordpress.org>

#65112: Docs: Correct typos in JS inline comments and docblocks
--------------------------+------------------------------
 Reporter:  parinpanjari  |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  REST API      |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by dmsnell):

 @parinpanjari there’s another issue on one of your changed lines. maybe
 want to fix that too?

 > // Dates not being allowed for revisions are is a technical limitation
 of post revisions.

 There’s an issue with “are is”

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65112#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 14:01:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 14:01:26 -0000
Subject: [wp-trac] [WordPress Trac] #65112: Docs: Correct typos in JS
 inline comments and docblocks
In-Reply-To: <056.e43e8e69989dc2ac5bb7184eef947c80@wordpress.org>
References: <056.e43e8e69989dc2ac5bb7184eef947c80@wordpress.org>
Message-ID: <071.727dcd0bbcca366967172de79ef53057@wordpress.org>

#65112: Docs: Correct typos in JS inline comments and docblocks
--------------------------+------------------------------
 Reporter:  parinpanjari  |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  REST API      |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by parinpanjari):

 @dmsnell

 Good catch, thanks! Yes, please drop the stray "are" as part of this
 commit. Happy for you to fold that in directly — no need for a revised
 patch.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65112#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 14:03:08 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 14:03:08 -0000
Subject: [wp-trac] [WordPress Trac] #65112: Docs: Correct typos in JS
 inline comments and docblocks
In-Reply-To: <056.e43e8e69989dc2ac5bb7184eef947c80@wordpress.org>
References: <056.e43e8e69989dc2ac5bb7184eef947c80@wordpress.org>
Message-ID: <071.e9c8df5f0440acaf2fb1d87d12d214f4@wordpress.org>

#65112: Docs: Correct typos in JS inline comments and docblocks
--------------------------+------------------------------
 Reporter:  parinpanjari  |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  REST API      |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+------------------------------
Changes (by parinpanjari):

 * keywords:   => has-patch


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65112#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 14:06:50 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 14:06:50 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.ef4362259cc9b7baa95e3b5c1856c564@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
---------------------------------------+-----------------------
 Reporter:  shatrumyatra               |       Owner:  audrasjb
     Type:  defect (bug)               |      Status:  accepted
 Priority:  normal                     |   Milestone:  7.0
Component:  Administration             |     Version:  trunk
 Severity:  normal                     |  Resolution:
 Keywords:  has-screenshots has-patch  |     Focuses:  ui
---------------------------------------+-----------------------
Changes (by shatrumyatra):

 * Attachment "patch-65105.diff" added.

 Updated patch. Added small-text class in Screen option Number of items per
 page: input.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 14:07:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 14:07:55 -0000
Subject: [wp-trac] [WordPress Trac] #65114: Correct formatting of
 `$locked_text` in posts list table
Message-ID: <058.8cc79848f540f79a56f1096cf46de85a@wordpress.org>

#65114: Correct formatting of `$locked_text` in posts list table
-------------------------------+-----------------------------
 Reporter:  ankitkumarshah     |      Owner:  (none)
     Type:  defect (bug)       |     Status:  new
 Priority:  normal             |  Milestone:  Awaiting Review
Component:  Posts, Post Types  |    Version:
 Severity:  normal             |   Keywords:
  Focuses:  coding-standards   |
-------------------------------+-----------------------------
 The `column_title()` method in `WP_Posts_List_Table` has variable
 alignment
 issues in `locked_text` that do not follow WordPress coding standards.

 Steps to reproduce:
 1. Run PHPCS against `src/wp-admin/includes/class-wp-posts-list-table.php`
 2. Observe coding standards violations around line 1125.


 {{{
 1125 | WARNING | [x] Equals sign not aligned correctly; expected 1 space
 but found 3 spaces
       |         |
 (Generic.Formatting.MultipleStatementAlignment.IncorrectWarning)
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65114>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 15:20:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 15:20:12 -0000
Subject: [wp-trac] [WordPress Trac] #65113: Docs: Fix "objecct" typo in
 WP_Query post-loading comment
In-Reply-To: <056.8e6848da33c5e7e2ecec69a32eb25d52@wordpress.org>
References: <056.8e6848da33c5e7e2ecec69a32eb25d52@wordpress.org>
Message-ID: <071.ceda3af36172a6a88e76e05f33441a9f@wordpress.org>

#65113: Docs: Fix "objecct" typo in WP_Query post-loading comment
--------------------------+------------------------------
 Reporter:  parinpanjari  |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Customize     |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+------------------------------
Changes (by abcd95):

 * keywords:   => needs-patch


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65113#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 15:29:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 15:29:30 -0000
Subject: [wp-trac] [WordPress Trac] #64904: Real time collboration:
 determine approach for opt in setting for users in Settings > Writing
In-Reply-To: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
References: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
Message-ID: <067.c6b2937fab71dde872a4d563857111d0@wordpress.org>

#64904: Real time collboration: determine approach for opt in setting for users in
Settings > Writing
------------------------------------+--------------------------------
 Reporter:  annezazu                |       Owner:  (none)
     Type:  task (blessed)          |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  Administration          |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-design has-patch  |     Focuses:  ui, accessibility
------------------------------------+--------------------------------

Comment (by fcoveram):

 Thanks @audrasjb.

 All styles used in the design should be from the existing set. That
 involves body text, controls help text, component disabled state, badge,
 and the note with a darker gray background.

 No new style is intended to be introduced.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64904#comment:47>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 16:22:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 16:22:16 -0000
Subject: [wp-trac] [WordPress Trac] #65113: Docs: Fix "objecct" typo in
 WP_Query post-loading comment
In-Reply-To: <056.8e6848da33c5e7e2ecec69a32eb25d52@wordpress.org>
References: <056.8e6848da33c5e7e2ecec69a32eb25d52@wordpress.org>
Message-ID: <071.ce40b2e1d00554ffb0c3ed3cc4d0ed2d@wordpress.org>

#65113: Docs: Fix "objecct" typo in WP_Query post-loading comment
--------------------------+------------------------------
 Reporter:  parinpanjari  |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Customize     |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:
--------------------------+------------------------------
Changes (by shailu25):

 * keywords:  needs-patch => has-patch


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65113#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 16:29:59 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 16:29:59 -0000
Subject: [wp-trac] [WordPress Trac] #65094: AI: Prompt construction
 fails with fatal error when wp_ai_client_default_request_timeout filter
 returns negative number
In-Reply-To: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
References: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
Message-ID: <070.1a2829c214d075c27f2ffd629c357fb7@wordpress.org>

#65094: AI: Prompt construction fails with fatal error when
wp_ai_client_default_request_timeout filter returns negative number
---------------------------------------------+--------------------------
 Reporter:  westonruter                      |       Owner:  westonruter
     Type:  defect (bug)                     |      Status:  assigned
 Priority:  normal                           |   Milestone:  7.0
Component:  AI                               |     Version:
 Severity:  normal                           |  Resolution:
 Keywords:  has-patch has-unit-tests commit  |     Focuses:
---------------------------------------------+--------------------------
Changes (by westonruter):

 * keywords:  has-patch has-unit-tests => has-patch has-unit-tests commit


Comment:

 I'll commit this today.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65094#comment:24>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 17:10:19 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 17:10:19 -0000
Subject: [wp-trac] [WordPress Trac] #65107: Twenty Sixteen: italics lost
 in 'blockquote cite'
In-Reply-To: <056.76190b8b93b06d61c688feba76f9b9c9@wordpress.org>
References: <056.76190b8b93b06d61c688feba76f9b9c9@wordpress.org>
Message-ID: <071.e3081589a029f9cdd2618636f657fa99@wordpress.org>

#65107: Twenty Sixteen: italics lost in 'blockquote cite'
-----------------------------------+------------------------------
 Reporter:  gaelbonithon           |       Owner:  (none)
     Type:  defect (bug)           |      Status:  new
 Priority:  normal                 |   Milestone:  Awaiting Review
Component:  Bundled Theme          |     Version:  4.4
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |     Focuses:  css
-----------------------------------+------------------------------
Changes (by sabernhardt):

 * keywords:  has-patch => has-patch 2nd-opinion
 * version:  trunk => 4.4


Comment:

 Hi and welcome to WordPress Core Trac!

 The theme's initial commit used `font-style: normal` in
 [https://github.com/WordPress/twentysixteen/blob/4d4ba75f181336743c30b9fe09ce24607fb4a30e/style.css#L396-L400
 front-end] and
 [https://github.com/WordPress/twentysixteen/blob/4d4ba75f181336743c30b9fe09ce24607fb4a30e/css
 /editor-style.css#L137-L141 editor styles] to reverse the italics of the
 `blockquote` in `em` and `cite` elements. The default styling should
 remain as it has been for ten years.

 In 2018, Twenty Sixteen styles for the block editor reinforced the normal
 `font-style` within the [https://github.com/WordPress/wordpress-
 develop/blob/c7c777aab217b577107106f0f56563983e3c5afb/src/wp-
 content/themes/twentysixteen/css/editor-blocks.css#L321-L325 Quote block].

 The theme probably could add italics again for `em` elements within
 citations.
 {{{
 blockquote :where(cite) em {
         font-style: italic;
 }
 }}}

 and in `editor-blocks.css`
 {{{
 .wp-block-quote__citation em {
         font-style: italic;
 }
 }}}

 The additional style would be inappropriate for anyone who made the
 citations italic, but using `:where()` to match the specificity should
 reduce the possibility of unexpected changes.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65107#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 17:19:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 17:19:07 -0000
Subject: [wp-trac] [WordPress Trac] #65108: Twenty Sixteen: barely
 visible bold text in 'blockquote'
In-Reply-To: <056.b4f29e9067554142b8542b27cd2c3419@wordpress.org>
References: <056.b4f29e9067554142b8542b27cd2c3419@wordpress.org>
Message-ID: <071.e3cfc92646d3602323ab0803f295717d@wordpress.org>

#65108: Twenty Sixteen: barely visible bold text in 'blockquote'
-------------------------------------------------+-------------------------
 Reporter:  gaelbonithon                         |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Bundled Theme                        |     Version:  4.4
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-test-info has-         |     Focuses:  css
  screenshots                                    |
-------------------------------------------------+-------------------------
Changes (by sabernhardt):

 * version:  trunk => 4.4


Comment:

 Like the normal `font-style` for `em` (#65107), the normal `font-weight`
 has been part of Twenty Sixteen since
 [https://github.com/WordPress/twentysixteen/blob/4d4ba75f181336743c30b9fe09ce24607fb4a30e/style.css#L402-L405
 initial commit].

 However, I do not understand the reason for reducing the `font-weight` for
 `strong` elements inside a `blockquote`.

 If a change is appropriate now, I would prefer removing the ruleset
 instead of editing the value.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65108#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 17:21:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 17:21:22 -0000
Subject: [wp-trac] [WordPress Trac] #65108: Twenty Sixteen: barely
 visible bold text in 'blockquote'
In-Reply-To: <056.b4f29e9067554142b8542b27cd2c3419@wordpress.org>
References: <056.b4f29e9067554142b8542b27cd2c3419@wordpress.org>
Message-ID: <071.b82f5445380f38996427c285750eb91c@wordpress.org>

#65108: Twenty Sixteen: barely visible bold text in 'blockquote'
-------------------------------------------------+-------------------------
 Reporter:  gaelbonithon                         |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Bundled Theme                        |     Version:  4.4
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-test-info has-         |     Focuses:  css
  screenshots                                    |
-------------------------------------------------+-------------------------
Changes (by sabernhardt):

 * Attachment "T16-quote-em-strong.png" added.

 Quote blocks with `em` and `strong` elements within both the paragraph and
 the citation

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65108>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 18:14:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 18:14:06 -0000
Subject: [wp-trac] [WordPress Trac] #65094: AI: Prompt construction
 fails with fatal error when wp_ai_client_default_request_timeout filter
 returns negative number
In-Reply-To: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
References: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
Message-ID: <070.346a046ae1505e9ca78e33f465ef41d7@wordpress.org>

#65094: AI: Prompt construction fails with fatal error when
wp_ai_client_default_request_timeout filter returns negative number
---------------------------------------------+--------------------------
 Reporter:  westonruter                      |       Owner:  westonruter
     Type:  defect (bug)                     |      Status:  closed
 Priority:  normal                           |   Milestone:  7.0
Component:  AI                               |     Version:
 Severity:  normal                           |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests commit  |     Focuses:
---------------------------------------------+--------------------------
Changes (by westonruter):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62255" 62255]:
 {{{
 #!CommitTicketReference repository="" revision="62255"
 AI: Validate filtered default request timeout in
 `WP_AI_Client_Prompt_Builder`.

 This checks that the return value of the
 `wp_ai_client_default_request_timeout` filter is a non-negative number
 before passing it to `RequestOptions`. If the filtered value is invalid,
 it is discarded in favor of the original default of `30.0` and a
 `_doing_it_wrong()` notice is issued. Without this check, a fatal error
 would ensue from the exception thrown in
 `\WordPress\AiClient\Providers\Http\DTO\RequestOptions::validateTimeout()`.

 The following static analysis issues are addressed:

 * Use `float` instead of `int` for the
 `wp_ai_client_default_request_timeout` filter parameter.
 * Add missing PHP imports for `Message` and `MessagePart` in the PHPDoc
 for `wp_ai_client_prompt()`.
 * Add PHP return type hints for `wp_ai_client_prompt()` and
 `WP_AI_Client_Cache::getMultiple()`.
 * Use native property type hints in `WP_AI_Client_HTTP_Client`.

 Developed in https://github.com/WordPress/wordpress-develop/pull/11596

 Props westonruter, justlevine, flixos90, khushdoms, darshitrajyaguru97,
 adrmf25, jarodortegaaraya, tusharaddweb, gaurangsondagar.
 Fixes #65094.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65094#comment:25>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 18:15:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 18:15:06 -0000
Subject: [wp-trac] [WordPress Trac] #65094: AI: Prompt construction
 fails with fatal error when wp_ai_client_default_request_timeout filter
 returns negative number
In-Reply-To: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
References: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
Message-ID: <070.e88e3b75dcc6393a67812b6778305ff4@wordpress.org>

#65094: AI: Prompt construction fails with fatal error when
wp_ai_client_default_request_timeout filter returns negative number
-------------------------------------------------+-------------------------
 Reporter:  westonruter                          |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  AI                                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests commit      |     Focuses:
  dev-feedback                                   |
-------------------------------------------------+-------------------------
Changes (by westonruter):

 * keywords:  has-patch has-unit-tests commit => has-patch has-unit-tests
     commit dev-feedback
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Re-opening for merging into 7.0 branch after sign-off.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65094#comment:26>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 18:38:41 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 18:38:41 -0000
Subject: [wp-trac] [WordPress Trac] #65111: Twenty Sixteen: Center text
 in image captions
In-Reply-To: <056.c3ba973b7320165fb70c9efb0d35f5aa@wordpress.org>
References: <056.c3ba973b7320165fb70c9efb0d35f5aa@wordpress.org>
Message-ID: <071.9c63161fd68f5d27284f324ac99cb0d2@wordpress.org>

#65111: Twenty Sixteen: Center text in image captions
-----------------------------+------------------------------
 Reporter:  gaelbonithon     |       Owner:  (none)
     Type:  enhancement      |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Bundled Theme    |     Version:  4.4
 Severity:  normal           |  Resolution:
 Keywords:  has-patch close  |     Focuses:  css
-----------------------------+------------------------------
Changes (by sabernhardt):

 * keywords:  has-patch => has-patch close
 * version:  trunk => 4.4


Comment:

 The default styling probably should not change after the theme has been
 publicly available (for ten years). In this case, the
 [https://wordpress.org/documentation/article/twenty-sixteen/#customize
 theme documentation] even shows the image caption text aligned to the left
 (in a left-to-right language).

 The Gutenberg repository has an old issue about adding text alignment
 controls for captions:
 https://github.com/WordPress/gutenberg/issues/12997

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65111#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 19:14:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 19:14:31 -0000
Subject: [wp-trac] [WordPress Trac] #65109: Abilities API: Duplicated
 $args variable in WP_Ability_Category::prepare_properties() PHPDoc
In-Reply-To: <054.698909d7bfb74e6b59f9754a972627c2@wordpress.org>
References: <054.698909d7bfb74e6b59f9754a972627c2@wordpress.org>
Message-ID: <069.675774e43d39e6708a9fde18124f076c@wordpress.org>

#65109: Abilities API: Duplicated $args variable in
WP_Ability_Category::prepare_properties() PHPDoc
------------------------------+--------------------------
 Reporter:  thriveteam        |       Owner:  westonruter
     Type:  defect (bug)      |      Status:  reviewing
 Priority:  normal            |   Milestone:  7.1
Component:  Abilities API     |     Version:  6.9
 Severity:  normal            |  Resolution:
 Keywords:  has-patch commit  |     Focuses:  docs
------------------------------+--------------------------
Changes (by westonruter):

 * keywords:  has-patch => has-patch commit
 * owner:  (none) => westonruter
 * version:   => 6.9
 * status:  new => reviewing
 * milestone:  Awaiting Review => 7.1


Comment:

 Patch looks good. Trunk is currently frozen for 7.0 so we can commit this
 once that is opened back up.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65109#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 19:18:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 19:18:23 -0000
Subject: [wp-trac] [WordPress Trac] #65110: Application Passwords: add a
 safer authorize flow for browser-based apps
In-Reply-To: <053.7dd1fec7fc52849a794290a6c458543d@wordpress.org>
References: <053.7dd1fec7fc52849a794290a6c458543d@wordpress.org>
Message-ID: <068.48777ca5987c8c9c464786bf807aa1e0@wordpress.org>

#65110: Application Passwords: add a safer authorize flow for browser-based apps
-----------------------------------+------------------------------
 Reporter:  alekmitch              |       Owner:  (none)
     Type:  enhancement            |      Status:  new
 Priority:  normal                 |   Milestone:  Awaiting Review
Component:  Application Passwords  |     Version:  5.6
 Severity:  normal                 |  Resolution:
 Keywords:                         |     Focuses:
-----------------------------------+------------------------------
Changes (by westonruter):

 * version:   => 5.6


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65110#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 19:23:58 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 19:23:58 -0000
Subject: [wp-trac] [WordPress Trac] #65113: Docs: Fix "objecct" typo in
 WP_Query post-loading comment
In-Reply-To: <056.8e6848da33c5e7e2ecec69a32eb25d52@wordpress.org>
References: <056.8e6848da33c5e7e2ecec69a32eb25d52@wordpress.org>
Message-ID: <071.db5726a68dcb23bab74bd87159963337@wordpress.org>

#65113: Docs: Fix "objecct" typo in WP_Query post-loading comment
------------------------------+--------------------------
 Reporter:  parinpanjari      |       Owner:  westonruter
     Type:  defect (bug)      |      Status:  reviewing
 Priority:  normal            |   Milestone:  7.1
Component:  Customize         |     Version:  6.8
 Severity:  normal            |  Resolution:
 Keywords:  has-patch commit  |     Focuses:  docs
------------------------------+--------------------------
Changes (by westonruter):

 * status:  new => reviewing
 * focuses:   => docs
 * owner:  (none) => westonruter
 * version:   => 6.8
 * milestone:  Awaiting Review => 7.1
 * keywords:  has-patch => has-patch commit


Comment:

 Introduced in r59993 ([https://github.com/WordPress/wordpress-
 develop/commit/b98b347504a572a7685ad627f79df4e8e8903578 b98b347]) for
 #56992.

 Patch looks good but `trunk` is frozen for 7.0, so we'll pick this up when
 commits open back up again.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65113#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 19:24:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 19:24:21 -0000
Subject: [wp-trac] [WordPress Trac] #65113: Docs: Fix "objecct" typo in
 WP_Query post-loading comment
In-Reply-To: <056.8e6848da33c5e7e2ecec69a32eb25d52@wordpress.org>
References: <056.8e6848da33c5e7e2ecec69a32eb25d52@wordpress.org>
Message-ID: <071.ea87b0d8121a19ad84d1eb3a6f8e43a6@wordpress.org>

#65113: Docs: Fix "objecct" typo in WP_Query post-loading comment
------------------------------+--------------------------
 Reporter:  parinpanjari      |       Owner:  westonruter
     Type:  defect (bug)      |      Status:  reviewing
 Priority:  lowest            |   Milestone:  7.1
Component:  Query             |     Version:  6.8
 Severity:  normal            |  Resolution:
 Keywords:  has-patch commit  |     Focuses:  docs
------------------------------+--------------------------
Changes (by westonruter):

 * priority:  normal => lowest
 * component:  Customize => Query


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65113#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 19:27:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 19:27:23 -0000
Subject: [wp-trac] [WordPress Trac] #65112: Docs: Correct typos in JS
 inline comments and docblocks
In-Reply-To: <056.e43e8e69989dc2ac5bb7184eef947c80@wordpress.org>
References: <056.e43e8e69989dc2ac5bb7184eef947c80@wordpress.org>
Message-ID: <071.69153fa2d303cff68da620a57d6e1dcc@wordpress.org>

#65112: Docs: Correct typos in JS inline comments and docblocks
--------------------------+---------------------
 Reporter:  parinpanjari  |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.1
Component:  General       |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  docs
--------------------------+---------------------
Changes (by westonruter):

 * focuses:   => docs
 * component:  REST API => General
 * milestone:  Awaiting Review => 7.1


Comment:

 @parinpanjari Please add another patch with that additional fix.

 Once that's in place, this can be marked as ready for commit.

 But we'll not commit this right away since `trunk` is currently frozen for
 7.0.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65112#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 19:32:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 19:32:09 -0000
Subject: [wp-trac] [WordPress Trac] #65114: Correct formatting of
 `$locked_text` in posts list table
In-Reply-To: <058.8cc79848f540f79a56f1096cf46de85a@wordpress.org>
References: <058.8cc79848f540f79a56f1096cf46de85a@wordpress.org>
Message-ID: <073.a4b0718cb7bf1a4daddce35fe37682ec@wordpress.org>

#65114: Correct formatting of `$locked_text` in posts list table
-------------------------------+-------------------------------
 Reporter:  ankitkumarshah     |       Owner:  westonruter
     Type:  defect (bug)       |      Status:  reviewing
 Priority:  normal             |   Milestone:  7.1
Component:  Posts, Post Types  |     Version:  trunk
 Severity:  normal             |  Resolution:
 Keywords:  has-patch commit   |     Focuses:  coding-standards
-------------------------------+-------------------------------
Changes (by westonruter):

 * keywords:  has-patch => has-patch commit
 * owner:  (none) => westonruter
 * version:   => trunk
 * status:  new => reviewing
 * milestone:  Awaiting Review => 7.1


Comment:

 Introduced in r62074 ([https://github.com/WordPress/wordpress-
 develop/commit/25f2e837a602a3b8ac55568f47e5d298196b62d5 25f2e83]) for
 #64622.

 The `trunk` branch is currently frozen for new commits due to 7.0. This
 can be committed once unfrozen.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65114#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 20:27:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 20:27:56 -0000
Subject: [wp-trac] [WordPress Trac] #65115: AI Client lacks filters for
 customizing model selection and generation parameters
Message-ID: <055.763db1e4ff44abc9566932d9fe595357@wordpress.org>

#65115: AI Client lacks filters for customizing model selection and generation
parameters
----------------------------------------+----------------------------------
 Reporter:  raftaar1191                 |      Owner:  (none)
     Type:  feature request             |     Status:  new
 Priority:  normal                      |  Milestone:  Awaiting Review
Component:  AI                          |    Version:  trunk
 Severity:  normal                      |   Keywords:  needs-patch 2nd-
  Focuses:  accessibility, performance  |  opinion
----------------------------------------+----------------------------------
 The AI Client in WordPress 7.0 provides very limited filtering
 capabilities for third-party plugin customization.

 == Existing Filters ==

 Currently, only two filters exist:

 * `wp_ai_client_default_request_timeout` (HTTP timeout only)
 * `wp_ai_client_prevent_prompt` (request abort only)

 == Current Limitations ==

 There is currently **no way** for third-party plugins to customize:

 * Model selection per-capability (text generation, image generation,
 vision)
 * Generation parameters:
   * `temperature`
   * `max_tokens`
   * `top_p`
   * `top_k`
   * `presence_penalty`
   * `frequency_penalty`
 * The PSR-14 `BeforeGenerateResultEvent` is read-only and cannot modify
 parameters

 == Impact ==

 This severely limits the ability of plugin developers to build AI-powered
 features with custom behavior and control. Plugin developers cannot:

 * Dynamically select different models based on context or user role
 * Adjust temperature for deterministic vs. creative output
 * Control token limits per-capability or per-context
 * Set request timeouts per-capability
 * Conditionally modify generation parameters based on post type, user
 subscription, or other factors

 == Why This Matters ==

 Without these hooks, developers are forced to use workarounds and cannot
 leverage standard WordPress filter conventions for AI Client
 customization. This limits the extensibility of the AI Client and prevents
 a rich ecosystem of AI-powered plugins from being built.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65115>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 20:29:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 20:29:31 -0000
Subject: [wp-trac] [WordPress Trac] #65115: AI Client lacks filters for
 customizing model selection and generation parameters
In-Reply-To: <055.763db1e4ff44abc9566932d9fe595357@wordpress.org>
References: <055.763db1e4ff44abc9566932d9fe595357@wordpress.org>
Message-ID: <070.feabf57035c40dd9f396a5645b0d1968@wordpress.org>

#65115: AI Client lacks filters for customizing model selection and generation
parameters
-------------------------------------+-------------------------------------
 Reporter:  raftaar1191              |       Owner:  (none)
     Type:  feature request          |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  AI                       |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  ai-client needs-patch    |     Focuses:  accessibility,
  2nd-opinion                        |  performance
-------------------------------------+-------------------------------------
Changes (by JeffPaul):

 * keywords:  needs-patch 2nd-opinion => ai-client needs-patch 2nd-opinion


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65115#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 22:18:34 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 22:18:34 -0000
Subject: [wp-trac] [WordPress Trac] #65116: Feature request: On This Day
 dashboard widget
Message-ID: <053.013a3a9617eae6ca499f347ee9f9a63c@wordpress.org>

#65116: Feature request: On This Day dashboard widget
------------------------------------------------+--------------------------
 Reporter:  alshakero                           |      Owner:  (none)
     Type:  feature request                     |     Status:  new
 Priority:  normal                              |  Milestone:  Awaiting
                                                |  Review
Component:  Widgets                             |    Version:  trunk
 Severity:  minor                               |   Keywords:  has-patch
  Focuses:  ui, administration, sustainability  |
------------------------------------------------+--------------------------
 When an author lands on their Dashboard, the widget would show posts they
 published on the same month and day in previous years, grouped by year
 with the most recent first. Each entry links to the post for quick edit or
 view. **This is especially cool for drafts and unfinished posts**.

 This gives long-time authors a gentle nudge to revisit old work, spot
 patterns in what they write about on certain days, or republish/refresh
 content that has aged well. For new authors or on days with no history,
 the widget shows a friendly empty state.

 This would hopefully delight users and encourage them to comment on their
 post pasts with new posts.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65116>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 23:22:46 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 23:22:46 -0000
Subject: [wp-trac] [WordPress Trac] #64771: Existing block level custom
 CSS in a post breaks when the post is edited by user without
 unfiltered_html
In-Reply-To: <056.6cde4cb4d3674a3ab453a19d1888b21e@wordpress.org>
References: <056.6cde4cb4d3674a3ab453a19d1888b21e@wordpress.org>
Message-ID: <071.9a46d4d05baa2d8da66bafa1ea93b6dd@wordpress.org>

#64771: Existing block level custom CSS in a post breaks when the post is edited by
user without unfiltered_html
-------------------------------------------------+-------------------------
 Reporter:  glendaviesnz                         |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  high                                 |   Milestone:  7.0
Component:  Editor                               |     Version:  trunk
 Severity:  critical                             |  Resolution:
 Keywords:  has-patch has-unit-tests 2nd-        |     Focuses:
  opinion dev-reviewed                           |
-------------------------------------------------+-------------------------
Changes (by ramonopoly):

 * keywords:  has-patch has-unit-tests 2nd-opinion => has-patch has-unit-
     tests 2nd-opinion dev-reviewed


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64771#comment:59>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 23:50:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 23:50:55 -0000
Subject: [wp-trac] [WordPress Trac] #65116: Feature request: On This Day
 dashboard widget
In-Reply-To: <053.013a3a9617eae6ca499f347ee9f9a63c@wordpress.org>
References: <053.013a3a9617eae6ca499f347ee9f9a63c@wordpress.org>
Message-ID: <068.6e5fc680e5b5771f999921010c5e9bce@wordpress.org>

#65116: Feature request: On This Day dashboard widget
-------------------------+-------------------------------------------------
 Reporter:  alshakero    |       Owner:  (none)
     Type:  feature      |      Status:  new
  request                |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Widgets      |     Version:  trunk
 Severity:  minor        |  Resolution:
 Keywords:  has-patch    |     Focuses:  ui, administration, sustainability
-------------------------+-------------------------------------------------

Comment (by eclev91):

 This is fun, but does it belong in core?

 I haven't seen the admin reskin, but presumably that's where some of these
 shadows and gradients comes from?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65116#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 23:51:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 23:51:23 -0000
Subject: [wp-trac] [WordPress Trac] #64982: library should be changed to
 media library in core or needs gettext
In-Reply-To: <052.6ebe4cf636d68ac01de1c591e6c35312@wordpress.org>
References: <052.6ebe4cf636d68ac01de1c591e6c35312@wordpress.org>
Message-ID: <067.488a1f6463d1422f4511b2c96485052f@wordpress.org>

#64982: library should be changed to media library in core or needs gettext
--------------------------+-----------------------------
 Reporter:  timse201      |       Owner:  SergeyBiryukov
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:  7.0
Component:  I18N          |     Version:  trunk
 Severity:  normal        |  Resolution:  fixed
 Keywords:  has-patch     |     Focuses:
--------------------------+-----------------------------
Changes (by SergeyBiryukov):

 * owner:  (none) => SergeyBiryukov
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62256" 62256]:
 {{{
 #!CommitTicketReference repository="" revision="62256"
 I18N: Add context for the Library admin menu item.

 Props timse201, sanketparmar, trickster301, audrasjb, jadavsanjay,
 SergeyBiryukov.
 Fixes #64982.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64982#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 22 23:56:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 22 Apr 2026 23:56:12 -0000
Subject: [wp-trac] [WordPress Trac] #64982: library should be changed to
 media library in core or needs gettext
In-Reply-To: <052.6ebe4cf636d68ac01de1c591e6c35312@wordpress.org>
References: <052.6ebe4cf636d68ac01de1c591e6c35312@wordpress.org>
Message-ID: <067.31f282cea82b936b018d2b91d4aa08e2@wordpress.org>

#64982: library should be changed to media library in core or needs gettext
-------------------------------------------+-----------------------------
 Reporter:  timse201                       |       Owner:  SergeyBiryukov
     Type:  defect (bug)                   |      Status:  reopened
 Priority:  normal                         |   Milestone:  7.0
Component:  I18N                           |     Version:  trunk
 Severity:  normal                         |  Resolution:
 Keywords:  has-patch commit dev-feedback  |     Focuses:
-------------------------------------------+-----------------------------
Changes (by SergeyBiryukov):

 * keywords:  has-patch => has-patch commit dev-feedback
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Reopening for 7.0 consideration.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64982#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 00:39:37 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 00:39:37 -0000
Subject: [wp-trac] [WordPress Trac] #65115: AI Client lacks filters for
 customizing model selection and generation parameters
In-Reply-To: <055.763db1e4ff44abc9566932d9fe595357@wordpress.org>
References: <055.763db1e4ff44abc9566932d9fe595357@wordpress.org>
Message-ID: <070.13b1b1f0da7ceb42fb8ce1f139763ea2@wordpress.org>

#65115: AI Client lacks filters for customizing model selection and generation
parameters
-----------------------------------------------+---------------------------
 Reporter:  raftaar1191                        |       Owner:  (none)
     Type:  feature request                    |      Status:  new
 Priority:  normal                             |   Milestone:  Awaiting
                                               |  Review
Component:  AI                                 |     Version:  trunk
 Severity:  normal                             |  Resolution:
 Keywords:  ai-client needs-patch 2nd-opinion  |     Focuses:
-----------------------------------------------+---------------------------
Changes (by westonruter):

 * focuses:  accessibility, performance =>


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65115#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 01:09:42 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 01:09:42 -0000
Subject: [wp-trac] [WordPress Trac] #64771: Existing block level custom
 CSS in a post breaks when the post is edited by user without
 unfiltered_html
In-Reply-To: <056.6cde4cb4d3674a3ab453a19d1888b21e@wordpress.org>
References: <056.6cde4cb4d3674a3ab453a19d1888b21e@wordpress.org>
Message-ID: <071.dfab2f5ab599bbd5cbf81c347538b28e@wordpress.org>

#64771: Existing block level custom CSS in a post breaks when the post is edited by
user without unfiltered_html
-------------------------------------------------+-------------------------
 Reporter:  glendaviesnz                         |       Owner:  ramonopoly
     Type:  defect (bug)                         |      Status:  closed
 Priority:  high                                 |   Milestone:  7.0
Component:  Editor                               |     Version:  trunk
 Severity:  critical                             |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests 2nd-        |     Focuses:
  opinion dev-reviewed                           |
-------------------------------------------------+-------------------------
Changes (by ramonopoly):

 * owner:  (none) => ramonopoly
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62257" 62257]:
 {{{
 #!CommitTicketReference repository="" revision="62257"
 Block Supports: strip custom CSS from blocks for users without edit_css
 capability

 Adds capability-gated CSS stripping so that when a user without `edit_css`
 saves a post, any `style.css` block attributes are removed from block
 comments using `WP_Block_Parser::next_token()`.

 Props aaronrobertshaw, audrasjb, dmsnell, glendaviesnz, jonsurrell,
 ozgursar, ramonopoly, shailu25, westonruter.

 Follow-up to [64544].

 Fixes #64771.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64771#comment:61>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 01:14:10 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 01:14:10 -0000
Subject: [wp-trac] [WordPress Trac] #64771: Existing block level custom
 CSS in a post breaks when the post is edited by user without
 unfiltered_html
In-Reply-To: <056.6cde4cb4d3674a3ab453a19d1888b21e@wordpress.org>
References: <056.6cde4cb4d3674a3ab453a19d1888b21e@wordpress.org>
Message-ID: <071.11681c478cac61dae0ac26417bc0430d@wordpress.org>

#64771: Existing block level custom CSS in a post breaks when the post is edited by
user without unfiltered_html
-------------------------------------------------+-------------------------
 Reporter:  glendaviesnz                         |       Owner:  ramonopoly
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  high                                 |   Milestone:  7.0
Component:  Editor                               |     Version:  trunk
 Severity:  critical                             |  Resolution:
 Keywords:  has-patch has-unit-tests 2nd-        |     Focuses:
  opinion dev-feedback                           |
-------------------------------------------------+-------------------------
Changes (by ramonopoly):

 * keywords:  has-patch has-unit-tests 2nd-opinion dev-reviewed => has-patch
     has-unit-tests 2nd-opinion dev-feedback
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Reopening #64771 to request backporting [62257] to 7.0 branch

 Following https://make.wordpress.org/core/handbook/best-practices
 /backporting-commits/#backport-process

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64771#comment:63>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 02:10:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 02:10:13 -0000
Subject: [wp-trac] [WordPress Trac] #64589: Navigation overlay: backport
 patterns and template part definition
In-Reply-To: <053.ec615ae22b92b37322d43a1bb40e3ddd@wordpress.org>
References: <053.ec615ae22b92b37322d43a1bb40e3ddd@wordpress.org>
Message-ID: <068.6189f4d5bc464df7258ff65535d7e080@wordpress.org>

#64589: Navigation overlay: backport patterns and template part definition
---------------------------------------+------------------------
 Reporter:  onemaggie                  |       Owner:  scruffian
     Type:  enhancement                |      Status:  closed
 Priority:  normal                     |   Milestone:  7.0
Component:  General                    |     Version:  trunk
 Severity:  normal                     |  Resolution:  fixed
 Keywords:  has-patch gutenberg-merge  |     Focuses:
---------------------------------------+------------------------
Changes (by wildworks):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 > this one was committed to trunk before 7.0 was branched, so I assume it
 can be closed as fixed?

 Yes, that's right.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64589#comment:23>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 03:10:08 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 03:10:08 -0000
Subject: [wp-trac] [WordPress Trac] #65097: Add action to
 `WP_AI_Client_Prompt_Builder` for builder-level configuration injection
In-Reply-To: <051.4a07b9c878c59705f108440bf628f34b@wordpress.org>
References: <051.4a07b9c878c59705f108440bf628f34b@wordpress.org>
Message-ID: <066.eb3b5fe583eee63ae761fa27e7fba612@wordpress.org>

#65097: Add action to `WP_AI_Client_Prompt_Builder` for builder-level configuration
injection
-----------------------------------+------------------------------
 Reporter:  takshil                |       Owner:  (none)
     Type:  feature request        |      Status:  new
 Priority:  normal                 |   Milestone:  Awaiting Review
Component:  AI                     |     Version:
 Severity:  normal                 |  Resolution:
 Keywords:  2nd-opinion has-patch  |     Focuses:
-----------------------------------+------------------------------

Comment (by takshil):

 @JeffPaul @raftaar1191 created this ticket for implementing
 https://core.trac.wordpress.org/ticket/65115#ticket

 My idea is to create a separate plugin to test the waters around this by
 introducing a filter for now.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65097#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 03:12:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 03:12:57 -0000
Subject: [wp-trac] [WordPress Trac] #64696: Real time collboration
 effectively disables persistent post caches while anyone edits a post
In-Reply-To: <057.05b7879d9d7300bfeccbd48dcfe7237b@wordpress.org>
References: <057.05b7879d9d7300bfeccbd48dcfe7237b@wordpress.org>
Message-ID: <072.fbe600091ed6b7d230dd3204c1de0477@wordpress.org>

#64696: Real time collboration effectively disables persistent post caches while
anyone edits a post
--------------------------------------+--------------------------
 Reporter:  peterwilsoncc             |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Posts, Post Types         |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+--------------------------

Comment (by peterwilsoncc):

 These are notes shared by @annezazu in the release squad Slack channel a
 few days as the result of some testing of database queries against various
 approaches:

 In this document:
 * Core: Refers to WordPress Develop code at the time of testing, this is
 in [https://github.com/WordPress/wordpress-
 develop/commit/88fe6bf7a5defe8103d29324fc2ec85b24ed05b9 WordPress
 /wordpress-devel at 88fe6bf7a5defe81]
 * Custom DB table: Tested against [https://github.com/WordPress/wordpress-
 develop/pull/11256 PR#11256] by @JoeFusco
 * Transients: Tested against [https://github.com/WordPress/wordpress-
 develop/pull/11348 PR#11348] by me. This also includes just in time cache
 flushing for the meta API

 Judging by the notes in the transients awareness column, this was tested
 on a system with a persistent cache.

 > ## Query Analysis: Three Storage Approaches for RTC
 >
 > We captured query logs from three Jurassic Ninja test sites during ~2
 minutes of collaborative editing (two browser tabs, same post) to compare
 the database cost of each storage backend.
 >
 > ||=                     =||= Core (trunk) =||= Custom DB table    =||=
 Transients          =||
 > || Total SQL queries     || 3,893          || 1,277 **(−67%)**     ||
 766 **(−80%)**        ||
 > || Total DB time         || 1,649 ms       || 834 ms **(−49%)**    ||
 383 ms **(−77%)**     ||
 > || Queries per sync poll || 27.5           || 9.8 **(−64%)**       ||
 5.3 **(−81%)**        ||
 > || Awareness DB queries  || 2,841          || 886 **(−69%)**       || 0
 **(−100%)**         ||
 >
 >
 > Core stores everything — awareness and updates — in `wp_postmeta`,
 generating nearly 4,000 queries in under two minutes. The Custom DB
 approach moves both to a dedicated `wp_collaboration` table, cutting
 queries by two-thirds. The Transients approach goes further: awareness is
 served from the object cache with zero SQL, reducing total queries by 80%.
 >
 > The performance gap comes entirely from query volume, not individual
 query speed — average execution time was under 1 ms across all three.
 Awareness state is the biggest factor: it's read and written on every poll
 cycle, and Core needs multiple `wp_postmeta` queries each time.
 Eliminating those queries (Transients) or consolidating them into a
 purpose-built table (Custom DB) is what drives the improvement.
 >
 > A hybrid of the two — transients for awareness, custom table for updates
 — could combine the strengths of both approaches.

 Based on the final comment with the hybrid approach, I have prepared
 [https://github.com/WordPress/wordpress-develop/pull/11599 PR#11599] to
 use the hybrid approach (it's forked from Joe's custom DB table PR).

 In the latest PR:

 * Awareness is stored in the object cache when a persistent cache is
 available (this is the key to the transients approach, not transients per
 se)
 * Awareness is stored in the custom table when a persistent cache is not
 available
 * Updates and sync data is stored in the custom table (unchanged from
 Joe's PR#11256)

 The hybrid approach is pending testing for database queries against both
 installs with and without a persistent cache.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64696#comment:158>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 03:22:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 03:22:49 -0000
Subject: [wp-trac] [WordPress Trac] #65115: AI Client lacks filters for
 customizing model selection and generation parameters
In-Reply-To: <055.763db1e4ff44abc9566932d9fe595357@wordpress.org>
References: <055.763db1e4ff44abc9566932d9fe595357@wordpress.org>
Message-ID: <070.037d41d517e2bd94043c12d7643296bb@wordpress.org>

#65115: AI Client lacks filters for customizing model selection and generation
parameters
-----------------------------------------------+---------------------------
 Reporter:  raftaar1191                        |       Owner:  (none)
     Type:  feature request                    |      Status:  new
 Priority:  normal                             |   Milestone:  Awaiting
                                               |  Review
Component:  AI                                 |     Version:  trunk
 Severity:  normal                             |  Resolution:
 Keywords:  ai-client needs-patch 2nd-opinion  |     Focuses:
-----------------------------------------------+---------------------------

Comment (by takshil):

 related: https://core.trac.wordpress.org/ticket/65097

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65115#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 03:33:40 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 03:33:40 -0000
Subject: [wp-trac] [WordPress Trac] #64685: Bulk Edit dropdown height
 increased compared to previous version
In-Reply-To: <052.53b49d25a3b1c1e2b2913b40d78297d6@wordpress.org>
References: <052.53b49d25a3b1c1e2b2913b40d78297d6@wordpress.org>
Message-ID: <067.3643bf68b2bcdd416e30bc5091a0c9aa@wordpress.org>

#64685: Bulk Edit dropdown height increased compared to previous version
-------------------------------------------+------------------------
 Reporter:  mohitbsf                       |       Owner:  joedolson
     Type:  defect (bug)                   |      Status:  reopened
 Priority:  normal                         |   Milestone:  7.0
Component:  Quick/Bulk Edit                |     Version:  trunk
 Severity:  minor                          |  Resolution:
 Keywords:  admin-reskin has-patch commit  |     Focuses:  css
-------------------------------------------+------------------------
Changes (by wildworks):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Sorry, I found that [62171] reintroduced the issue that had been fixed in
 [61827]. This happened because [62171] removed the line-height not only
 from input elements, but also from select elements.

 [https://github.com/WordPress/wordpress-develop/pull/11631 PR 11631]
 should fix this regression.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64685#comment:26>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 03:33:52 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 03:33:52 -0000
Subject: [wp-trac] [WordPress Trac] #64685: Bulk Edit dropdown height
 increased compared to previous version
In-Reply-To: <052.53b49d25a3b1c1e2b2913b40d78297d6@wordpress.org>
References: <052.53b49d25a3b1c1e2b2913b40d78297d6@wordpress.org>
Message-ID: <067.1fb304e92652e262c6af24acb4344a88@wordpress.org>

#64685: Bulk Edit dropdown height increased compared to previous version
------------------------------------+------------------------
 Reporter:  mohitbsf                |       Owner:  joedolson
     Type:  defect (bug)            |      Status:  reopened
 Priority:  normal                  |   Milestone:  7.0
Component:  Quick/Bulk Edit         |     Version:  trunk
 Severity:  minor                   |  Resolution:
 Keywords:  admin-reskin has-patch  |     Focuses:  css
------------------------------------+------------------------
Changes (by wildworks):

 * keywords:  admin-reskin has-patch commit => admin-reskin has-patch


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64685#comment:27>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 03:40:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 03:40:23 -0000
Subject: [wp-trac] [WordPress Trac] #65052: Nonce check order flaw in
 post-quickdraft-save
In-Reply-To: <052.5cb71bdc8207e81444fff364e3bc4f57@wordpress.org>
References: <052.5cb71bdc8207e81444fff364e3bc4f57@wordpress.org>
Message-ID: <067.11e7ccf97a4a6be5e5a295d8d1d56941@wordpress.org>

#65052: Nonce check order flaw in post-quickdraft-save
-------------------------------------+------------------------------
 Reporter:  rajeshcp                 |       Owner:  rajeshcp
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Security                 |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+------------------------------

Comment (by liaison):

 Test Report for Ticket #65052
 Environment
 OS: Windows (XAMPP)

 PHP: 8.2.x

 WordPress: 7.1-alpha (trunk)

 Testing Area: Dashboard Quick Draft (wp-admin/post.php)

 The Problem
 In the original code, the resource (Post object) is fetched via get_post()
 before the Nonce is verified or the Post ID is validated. This leads to:

 Unnecessary Database Lookups: Database is queried even if the request is
 unauthorized.

 PHP Warnings: In PHP 8.2+, providing a non-existent post_ID leads to a
 Fatal-level Warning when attempting to access properties on a null object
 later in the execution flow.

 Test Results (Before Patch)

 Test 1 valid nonce & valid post id:
 {{{
 jQuery.post( ajaxurl.replace('admin-ajax.php', 'post.php'), {
     action: 'post-quickdraft-save',
     _wpnonce: 'valid_nonce_here', // valid nonce
     post_ID: 1 // valid id
 });
 }}}
 Test 1 result:
 [23-Apr-2026 03:02:52 UTC] DEBUG: get_post() was called for ID: 1

 Test 2 invalid nonce & valid post id:
 {{{
 jQuery.post( ajaxurl.replace('admin-ajax.php', 'post.php'), {
     action: 'post-quickdraft-save',
     _wpnonce: 'wrong_nonce_here', // wrong_nonce
     post_ID: 1 // valid id
 });
 }}}
 Test 2 result:
 [23-Apr-2026 03:02:58 UTC] error_msg: Unable to submit this form, please
 refresh and try again.

 Test 3 valid nonce & invalid post id:
 {{{
 jQuery.post( ajaxurl.replace('admin-ajax.php', 'post.php'), {
     action: 'post-quickdraft-save',
     _wpnonce: 'valid_nonce_here', // valid nonce
     post_ID: 999999 // invalid id
 });
 }}}
 Test 3 result:
 [23-Apr-2026 03:03:53 UTC] DEBUG: get_post() was called for ID: 999999
 [23-Apr-2026 03:03:53 UTC] PHP Warning:  Attempt to read property
 "post_type" on null in C:\xampp\htdocs\wp-core\src\wp-admin\post.php on
 line 103

 Suggested patch
 {{{#!php
 <?php
         case 'post-quickdraft-save':
                 // Check nonce and capabilities.
                 $nonce     = $_REQUEST['_wpnonce'];
                 // patch-ticket: 65052-begin
                 $post_id = absint( $_REQUEST['post_ID'] ?? 0 );
                 $post    = $post_id ? get_post( $post_id ) : null;
                 // patch-ticket: 65052-end
                 $error_msg = false;

                 // For output of the Quick Draft dashboard widget.
                 require_once ABSPATH . 'wp-admin/includes/dashboard.php';

                 if ( ! $post || ! wp_verify_nonce( $nonce, 'add-post' ) )
 {
                         $error_msg = __( 'Unable to submit this form,
 please refresh and try again.' );
                 }

                 if ( ! current_user_can( get_post_type_object( 'post'
 )->cap->create_posts ) ) {
                         exit;
                 }

                 if ( $error_msg ) {
                         //check ticket: 65052 Nonce check order flaw in
 post-quickdraft-save
                         //error_log( "error_msg: " . ($error_msg ??
 'none') );
                         return wp_dashboard_quick_press( $error_msg );
                 }

                 //check ticket: 65052 Nonce check order flaw in post-
 quickdraft-save
                 //error_log( "DEBUG: get_post() was called for ID: " .
 ($_REQUEST['post_ID'] ?? 'none') );
                 check_admin_referer( 'add-' . $post->post_type );

 }}}

 Test Results (After Patch)
 Test 3 valid nonce & invalid post id:
 {{{
 jQuery.post( ajaxurl.replace('admin-ajax.php', 'post.php'), {
     action: 'post-quickdraft-save',
     _wpnonce: 'valid_nonce_here', // valid nonce
     post_ID: 999999 // invalid id
 });
 }}}
 Test 3 result:
 [23-Apr-2026 03:07:42 UTC] error_msg: Unable to submit this form, please
 refresh and try again.

 Verdict
 The optimized patch addresses the security flaw and improves system
 reliability for PHP 8.2+ environments.

 Summary
 Strict Validation. Ensuring that get_post() is handled safely by using
 absint() and a ternary check for $post.

 Logic Ordering. Nonce and resource existence are verified immediately.

 Stability. Preventing the attempt to read property on null warning in PHP
 8.2, which was previously triggered by a valid nonce but an invalid ID.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65052#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 03:41:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 03:41:05 -0000
Subject: [wp-trac] [WordPress Trac] #65052: Nonce check order flaw in
 post-quickdraft-save
In-Reply-To: <052.5cb71bdc8207e81444fff364e3bc4f57@wordpress.org>
References: <052.5cb71bdc8207e81444fff364e3bc4f57@wordpress.org>
Message-ID: <067.81676327d8c44e9c44b18db75fb9d25a@wordpress.org>

#65052: Nonce check order flaw in post-quickdraft-save
-------------------------------------+------------------------------
 Reporter:  rajeshcp                 |       Owner:  rajeshcp
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Security                 |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+------------------------------
Changes (by liaison):

 * Attachment "65052-test-devTool.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65052>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 04:10:24 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 04:10:24 -0000
Subject: [wp-trac] [WordPress Trac] #65116: Feature request: On This Day
 dashboard widget
In-Reply-To: <053.013a3a9617eae6ca499f347ee9f9a63c@wordpress.org>
References: <053.013a3a9617eae6ca499f347ee9f9a63c@wordpress.org>
Message-ID: <068.e173d54e6c8436cba85ce111b5c5de74@wordpress.org>

#65116: Feature request: On This Day dashboard widget
-------------------------+-------------------------------------------------
 Reporter:  alshakero    |       Owner:  (none)
     Type:  feature      |      Status:  new
  request                |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Widgets      |     Version:  trunk
 Severity:  minor        |  Resolution:
 Keywords:  has-patch    |     Focuses:  ui, administration, sustainability
-------------------------+-------------------------------------------------

Comment (by annezazu):

 This came up in a core committer meeting in November 2025:
 https://make.wordpress.org/core/2025/11/26/core-committers-check-in-
 november-2025/

 >Are there new widgets that can be added, such as “on this day” or
 “new/unresolved notes” for sites making use of the Notes feature.

 It also came up in the 7.0 Product review with Matt:
 https://make.wordpress.org/core/2026/02/18/wordpress-7-0-product-review-
 meeting-with-matt/

 >“On this day / previous years” widget discussed as a simple, useful
 candidate to bring in.

 Here's the exact timestamp for the conversation if you want to listen
 @eclev91  https://youtu.be/F-xMPY9WqG4?si=Cci4dbtu08rT0lly&t=3326

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65116#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 04:19:40 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 04:19:40 -0000
Subject: [wp-trac] [WordPress Trac] #65048: wp_ajax_fetch_list():
 Sanitize $_GET input before nonce construction
In-Reply-To: <052.ec9b36b226893b34c604b6419cd46f00@wordpress.org>
References: <052.ec9b36b226893b34c604b6419cd46f00@wordpress.org>
Message-ID: <067.7ad90f72732d36f97d19289edc349931@wordpress.org>

#65048: wp_ajax_fetch_list(): Sanitize $_GET input before nonce construction
-------------------------------------+------------------------------
 Reporter:  rajeshcp                 |       Owner:  rajeshcp
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Administration           |     Version:  3.1
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+------------------------------

Comment (by liaison):

 Test Report for Ticket #65048
 Environment
 OS: Windows (XAMPP)

 PHP: 8.2.x

 WordPress: 7.1-alpha (trunk)

 Testing Area: wp_ajax_fetch_list() in wp-admin/includes/ajax-actions.php

 The Problem
 The wp_ajax_fetch_list() function used raw data from $_GET['list_args'] to
 construct the nonce action string and for list table initialization. This
 lacks proper sanitization and triggers PHP warnings in PHP 8.2+ when
 parameters are missing.

 Test code: add log in wp-admin/admin-ajax.php before
 do_action( 'admin_init' );

 {{{#!php
 <?php
 if ( isset($_GET['action']) && 'fetch_list' === $_GET['action'] ) {
     $raw_class = $_GET['list_args']['class'] ?? 'N/A';
     $clean_class = isset($_GET['list_args']['class']) ?
 sanitize_key($_GET['list_args']['class']) : '';

     error_log( "--- Ticket #65048 Audit ---" );
     error_log( "Action:    fetch_list" );
     error_log( "Raw Class: [" . $raw_class . "]" );
     error_log( "Sanitized: [" . $clean_class . "]" );
     error_log( "---------------------------" );

     $list_class = $_GET['list_args']['class'];
     $screen_id  = $_GET['list_args']['screen']['id'];

     error_log( "DEBUG 65048: Raw List Class = " . ($list_class ?? 'NULL')
 );
     error_log( "DEBUG 65048: Raw Screen ID = " . ($screen_id ?? 'NULL') );
 }

 /** This action is documented in wp-admin/admin.php */
 do_action( 'admin_init' );
 }}}


 Test Results (Verification)
 By intercepting the request at the AJAX entry point, the following results
 were recorded:

 Test 1: Input Sanitization

 Request

 {{{
 jQuery.get( ajaxurl, {
     action: 'fetch_list',
     list_args: {
         class: 'My Custom Class!@#',
         screen: { id: 'Screen ID 123' }
     }
 });
 }}}


 Log Output:
 {{{
 [23-Apr-2026 04:07:26 UTC] --- Ticket #65048 Audit ---
 [23-Apr-2026 04:07:26 UTC] Action:    fetch_list
 [23-Apr-2026 04:07:26 UTC] Raw Class: [My Custom Class!@#]
 [23-Apr-2026 04:07:26 UTC] Sanitized: [mycustomclass]
 [23-Apr-2026 04:07:26 UTC] ---------------------------
 [23-Apr-2026 04:07:26 UTC] DEBUG 65048: Raw List Class = My Custom
 Class!@#
 [23-Apr-2026 04:07:26 UTC] DEBUG 65048: Raw Screen ID = Screen ID 123
 }}}

 Observation: sanitize_key() correctly stripped whitespace, uppercase
 letters, and special characters (!@#). This ensures the nonce action
 string "fetch-list-$list_class" is generated from safe, predictable input.

 Test 2: PHP 8.2 Stability

 Request: action=fetch_list (missing list_args)

 {{{
 jQuery.get( ajaxurl, {
     action: 'fetch_list'
 });
 }}}

 Log Output:

 {{{
 [23-Apr-2026 04:12:07 UTC] --- Ticket #65048 Audit ---
 [23-Apr-2026 04:12:07 UTC] Action:    fetch_list
 [23-Apr-2026 04:12:07 UTC] Raw Class: [N/A]
 [23-Apr-2026 04:12:07 UTC] Sanitized: []
 [23-Apr-2026 04:12:07 UTC] ---------------------------
 [23-Apr-2026 04:12:07 UTC] PHP Warning:  Undefined array key "list_args"
 in C:\xampp\htdocs\wp-core\src\wp-admin\admin-ajax.php on line 54
 [23-Apr-2026 04:12:07 UTC] PHP Warning:  Trying to access array offset on
 value of type null in C:\xampp\htdocs\wp-core\src\wp-admin\admin-ajax.php
 on line 54
 [23-Apr-2026 04:12:07 UTC] PHP Warning:  Undefined array key "list_args"
 in C:\xampp\htdocs\wp-core\src\wp-admin\admin-ajax.php on line 55
 [23-Apr-2026 04:12:07 UTC] PHP Warning:  Trying to access array offset on
 value of type null in C:\xampp\htdocs\wp-core\src\wp-admin\admin-ajax.php
 on line 55
 [23-Apr-2026 04:12:07 UTC] PHP Warning:  Trying to access array offset on
 value of type null in C:\xampp\htdocs\wp-core\src\wp-admin\admin-ajax.php
 on line 55
 [23-Apr-2026 04:12:07 UTC] DEBUG 65048: Raw List Class = NULL
 [23-Apr-2026 04:12:07 UTC] DEBUG 65048: Raw Screen ID = NULL
 }}}


 Pre-patch: Triggered PHP Warning: Undefined array key "list_args".

 Post-patch: With isset() and ?? guards applied, no warnings were
 triggered. The values were safely defaulted to empty strings.

 Summary of Improvements
 Hardening: Prevents attackers from influencing the nonce action string via
 malicious character injection in the URL.

 PHP 8.x Compatibility: Resolves array key existence issues, leading to a
 cleaner debug log and better system stability.

 Verdict
 The patch successfully sanitizes the required inputs and resolves modern
 PHP warnings. The implementation of sanitize_key() and isset() guards is
 correct and follows WordPress Core best practices.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65048#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 04:21:59 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 04:21:59 -0000
Subject: [wp-trac] [WordPress Trac] #65048: wp_ajax_fetch_list():
 Sanitize $_GET input before nonce construction
In-Reply-To: <052.ec9b36b226893b34c604b6419cd46f00@wordpress.org>
References: <052.ec9b36b226893b34c604b6419cd46f00@wordpress.org>
Message-ID: <067.66f5628ee561c97047b764710469c907@wordpress.org>

#65048: wp_ajax_fetch_list(): Sanitize $_GET input before nonce construction
-------------------------------------+------------------------------
 Reporter:  rajeshcp                 |       Owner:  rajeshcp
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Administration           |     Version:  3.1
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:
-------------------------------------+------------------------------
Changes (by liaison):

 * Attachment "65048-Audit.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65048>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 04:22:59 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 04:22:59 -0000
Subject: [wp-trac] [WordPress Trac] #65048: wp_ajax_fetch_list():
 Sanitize $_GET input before nonce construction
In-Reply-To: <052.ec9b36b226893b34c604b6419cd46f00@wordpress.org>
References: <052.ec9b36b226893b34c604b6419cd46f00@wordpress.org>
Message-ID: <067.5611ffca8148b2016ccf2f9ba2f274c9@wordpress.org>

#65048: wp_ajax_fetch_list(): Sanitize $_GET input before nonce construction
-------------------------------------------------+-------------------------
 Reporter:  rajeshcp                             |       Owner:  rajeshcp
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Administration                       |     Version:  3.1
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing has-test-    |     Focuses:
  info                                           |
-------------------------------------------------+-------------------------
Changes (by liaison):

 * keywords:  has-patch needs-testing => has-patch needs-testing has-test-
               info


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65048#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 04:24:41 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 04:24:41 -0000
Subject: [wp-trac] [WordPress Trac] #65052: Nonce check order flaw in
 post-quickdraft-save
In-Reply-To: <052.5cb71bdc8207e81444fff364e3bc4f57@wordpress.org>
References: <052.5cb71bdc8207e81444fff364e3bc4f57@wordpress.org>
Message-ID: <067.a57b115099fc1b281ddcdb607637d8c3@wordpress.org>

#65052: Nonce check order flaw in post-quickdraft-save
-------------------------------------------------+-------------------------
 Reporter:  rajeshcp                             |       Owner:  rajeshcp
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Security                             |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing has-test-    |     Focuses:
  info                                           |
-------------------------------------------------+-------------------------
Changes (by liaison):

 * keywords:  has-patch needs-testing => has-patch needs-testing has-test-
               info


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65052#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 04:25:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 04:25:57 -0000
Subject: [wp-trac] [WordPress Trac] #65044: get_post_custom_values()
 missing array check, inconsistent with get_post_custom_keys()
In-Reply-To: <057.4a59bcc730ee55ef2108915dd95410cb@wordpress.org>
References: <057.4a59bcc730ee55ef2108915dd95410cb@wordpress.org>
Message-ID: <072.17f68da89a3ad12579b4a7e0ae153879@wordpress.org>

#65044: get_post_custom_values() missing array check, inconsistent with
get_post_custom_keys()
-------------------------------------------------+-------------------------
 Reporter:  saratheonline                        |       Owner:
                                                 |  saratheonline
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  7.1
Component:  Posts, Post Types                    |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing needs-unit-  |     Focuses:
  tests has-test-info                            |
-------------------------------------------------+-------------------------
Changes (by liaison):

 * keywords:  has-patch needs-testing needs-unit-tests => has-patch needs-
     testing needs-unit-tests has-test-info


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65044#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 04:27:36 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 04:27:36 -0000
Subject: [wp-trac] [WordPress Trac] #65055: _pad_term_counts() uses
 string-concatenated SQL without prepared statement
In-Reply-To: <052.bca20aa704264c411e9a5a70bff738ad@wordpress.org>
References: <052.bca20aa704264c411e9a5a70bff738ad@wordpress.org>
Message-ID: <067.d3d10c1fc8f5da66897c6d7f2d4e6ce6@wordpress.org>

#65055: _pad_term_counts() uses string-concatenated SQL without prepared statement
-------------------------------------------------+-------------------------
 Reporter:  rajeshcp                             |       Owner:
                                                 |  johnbillion
     Type:  enhancement                          |      Status:  reviewing
 Priority:  normal                               |   Milestone:  7.1
Component:  Taxonomy                             |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests has-test-   |     Focuses:
  info                                           |
-------------------------------------------------+-------------------------
Changes (by liaison):

 * keywords:  has-patch has-unit-tests => has-patch has-unit-tests has-test-
     info


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65055#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 05:09:42 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 05:09:42 -0000
Subject: [wp-trac] [WordPress Trac] #64393: Change how we include
 Gutenberg in Core
In-Reply-To: <055.264b0dba638f7c3f5a9d3208ee755072@wordpress.org>
References: <055.264b0dba638f7c3f5a9d3208ee755072@wordpress.org>
Message-ID: <070.051aa0d7c05a29a66661667b1fb1d3e4@wordpress.org>

#64393: Change how we include Gutenberg in Core
------------------------------+--------------------------
 Reporter:  youknowriad       |       Owner:  youknowriad
     Type:  task (blessed)    |      Status:  closed
 Priority:  high              |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:
 Severity:  blocker           |  Resolution:  fixed
 Keywords:  has-patch         |     Focuses:
------------------------------+--------------------------

Comment (by peterwilsoncc):

 In [changeset:"62258" 62258]:
 {{{
 #!CommitTicketReference repository="" revision="62258"
 Build/Test Tools: Consolidate vendor file copying to ensure `.min.js`
 files are minified.

 Relocates the copying of vendor JavaScript files back to the `grunt copy
 :vendor-js` subtask to ensure the files are in place prior to the `grunt
 uglify` step running to minify the files.

 Props desrosj.
 Fixes #65007.
 See #64393.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64393#comment:256>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 05:09:42 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 05:09:42 -0000
Subject: [wp-trac] [WordPress Trac] #65007: Contents of some `.min.js`
 files are no longer minified
In-Reply-To: <051.ca77996bd759b0598d7de612a42ec74d@wordpress.org>
References: <051.ca77996bd759b0598d7de612a42ec74d@wordpress.org>
Message-ID: <066.c7c6f918cf0ca8896fc3b800c412f68b@wordpress.org>

#65007: Contents of some `.min.js` files are no longer minified
------------------------------+----------------------------
 Reporter:  desrosj           |       Owner:  peterwilsoncc
     Type:  defect (bug)      |      Status:  closed
 Priority:  normal            |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:  trunk
 Severity:  normal            |  Resolution:  fixed
 Keywords:  has-patch         |     Focuses:
------------------------------+----------------------------
Changes (by peterwilsoncc):

 * owner:  (none) => peterwilsoncc
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62258" 62258]:
 {{{
 #!CommitTicketReference repository="" revision="62258"
 Build/Test Tools: Consolidate vendor file copying to ensure `.min.js`
 files are minified.

 Relocates the copying of vendor JavaScript files back to the `grunt copy
 :vendor-js` subtask to ensure the files are in place prior to the `grunt
 uglify` step running to minify the files.

 Props desrosj.
 Fixes #65007.
 See #64393.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65007#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 05:10:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 05:10:44 -0000
Subject: [wp-trac] [WordPress Trac] #65007: Contents of some `.min.js`
 files are no longer minified
In-Reply-To: <051.ca77996bd759b0598d7de612a42ec74d@wordpress.org>
References: <051.ca77996bd759b0598d7de612a42ec74d@wordpress.org>
Message-ID: <066.44cb850519918fc531134fa46cbc00d5@wordpress.org>

#65007: Contents of some `.min.js` files are no longer minified
--------------------------------------+----------------------------
 Reporter:  desrosj                   |       Owner:  peterwilsoncc
     Type:  defect (bug)              |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  dev-feedback fixed-major  |     Focuses:
--------------------------------------+----------------------------
Changes (by peterwilsoncc):

 * keywords:  has-patch => dev-feedback fixed-major
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Reopening for merge to the 7.0 branch pending another committers sign-off.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65007#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 06:52:01 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 06:52:01 -0000
Subject: [wp-trac] [WordPress Trac] #65107: Twenty Sixteen: italics lost
 in 'blockquote cite'
In-Reply-To: <056.76190b8b93b06d61c688feba76f9b9c9@wordpress.org>
References: <056.76190b8b93b06d61c688feba76f9b9c9@wordpress.org>
Message-ID: <071.7feadc296558479a91974ee174860588@wordpress.org>

#65107: Twenty Sixteen: italics lost in 'blockquote cite'
-----------------------------------+------------------------------
 Reporter:  gaelbonithon           |       Owner:  (none)
     Type:  defect (bug)           |      Status:  new
 Priority:  normal                 |   Milestone:  Awaiting Review
Component:  Bundled Theme          |     Version:  4.4
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |     Focuses:  css
-----------------------------------+------------------------------

Comment (by gaelbonithon):

 Replying to [comment:4 sabernhardt]:
 > Hi and welcome to WordPress Core Trac!
 >
 > The theme's initial commit used `font-style: normal` in
 [https://github.com/WordPress/twentysixteen/blob/4d4ba75f181336743c30b9fe09ce24607fb4a30e/style.css#L396-L400
 front-end] and
 [https://github.com/WordPress/twentysixteen/blob/4d4ba75f181336743c30b9fe09ce24607fb4a30e/css
 /editor-style.css#L137-L141 editor styles] to reverse the italics of the
 `blockquote` in `em` and `cite` elements. The default styling should
 remain as it has been for ten years.
 >
 > In 2018, Twenty Sixteen styles for the block editor reinforced the
 normal `font-style` within the [https://github.com/WordPress/wordpress-
 develop/blob/c7c777aab217b577107106f0f56563983e3c5afb/src/wp-
 content/themes/twentysixteen/css/editor-blocks.css#L321-L325 Quote block].
 >
 > The theme probably could add italics again for `em` elements within
 citations.
 > {{{
 > blockquote :where(cite) em {
 >       font-style: italic;
 > }
 > }}}
 >
 > and in `editor-blocks.css`
 > {{{
 > .wp-block-quote__citation em {
 >       font-style: italic;
 > }
 > }}}
 >
 > The additional style would be inappropriate for anyone who made the
 citations italic, but using `:where()` to match the specificity should
 reduce the possibility of unexpected changes.

 Thank you, patch updated.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65107#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 07:09:19 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 07:09:19 -0000
Subject: [wp-trac] [WordPress Trac] #65108: Twenty Sixteen: barely
 visible bold text in 'blockquote'
In-Reply-To: <056.b4f29e9067554142b8542b27cd2c3419@wordpress.org>
References: <056.b4f29e9067554142b8542b27cd2c3419@wordpress.org>
Message-ID: <071.b2f7b49a104977ccf7ddbc9599b378e6@wordpress.org>

#65108: Twenty Sixteen: barely visible bold text in 'blockquote'
-------------------------------------------------+-------------------------
 Reporter:  gaelbonithon                         |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Bundled Theme                        |     Version:  4.4
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-test-info has-         |     Focuses:  css
  screenshots                                    |
-------------------------------------------------+-------------------------

Comment (by gaelbonithon):

 Replying to [comment:5 sabernhardt]:
 > Like the normal `font-style` for `em` (#65107), the normal `font-weight`
 has been part of Twenty Sixteen since
 [https://github.com/WordPress/twentysixteen/blob/4d4ba75f181336743c30b9fe09ce24607fb4a30e/style.css#L402-L405
 initial commit].
 >
 > However, I do not understand the reason for reducing the `font-weight`
 for `strong` elements inside a `blockquote`.
 >
 > If a change is appropriate now, I would prefer removing the ruleset
 instead of editing the value.

 Patch updated. For the editor, I took inspiration from your
 recommendations in #65107: I'm not sure if this is the best way to do it,
 but it works…

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65108#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 07:18:59 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 07:18:59 -0000
Subject: [wp-trac] [WordPress Trac] #65111: Twenty Sixteen: Center text
 in image captions
In-Reply-To: <056.c3ba973b7320165fb70c9efb0d35f5aa@wordpress.org>
References: <056.c3ba973b7320165fb70c9efb0d35f5aa@wordpress.org>
Message-ID: <071.7fde2ddb75f9030847d028d9ad5e9faa@wordpress.org>

#65111: Twenty Sixteen: Center text in image captions
-----------------------------+------------------------------
 Reporter:  gaelbonithon     |       Owner:  (none)
     Type:  enhancement      |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Bundled Theme    |     Version:  4.4
 Severity:  normal           |  Resolution:
 Keywords:  has-patch close  |     Focuses:  css
-----------------------------+------------------------------

Comment (by gaelbonithon):

 Replying to [comment:3 sabernhardt]:
 > The default styling probably should not change after the theme has been
 publicly available (for ten years). In this case, the
 [https://wordpress.org/documentation/article/twenty-sixteen/#customize
 theme documentation] even shows the image caption text aligned to the left
 (in a left-to-right language).
 >
 > The Gutenberg repository has an old issue about adding text alignment
 controls for captions:
 > https://github.com/WordPress/gutenberg/issues/12997

 Yes, I understand, thanks for the pointer. I'll leave it to you to close
 the ticket/PR…

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65111#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 07:42:35 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 07:42:35 -0000
Subject: [wp-trac] [WordPress Trac] #64904: Real time collboration:
 determine approach for opt in setting for users in Settings > Writing
In-Reply-To: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
References: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
Message-ID: <067.dc7083b94a38a922431dc7cc866cdfc4@wordpress.org>

#64904: Real time collboration: determine approach for opt in setting for users in
Settings > Writing
------------------------------------+--------------------------------
 Reporter:  annezazu                |       Owner:  (none)
     Type:  task (blessed)          |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  Administration          |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  needs-design has-patch  |     Focuses:  ui, accessibility
------------------------------------+--------------------------------

Comment (by fcoveram):

 [https://www.figma.com/design/jRwnj51e1OxdDuRhVzIRtc/RTC-in-Settings?node-
 id=0-1&m=dev Here is] the design in Figma in dev mode. But as noted above,
 the styles should be the existing ones.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64904#comment:48>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 07:44:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 07:44:31 -0000
Subject: [wp-trac] [WordPress Trac] #65113: Docs: Fix "objecct" typo in
 WP_Query post-loading comment
In-Reply-To: <056.8e6848da33c5e7e2ecec69a32eb25d52@wordpress.org>
References: <056.8e6848da33c5e7e2ecec69a32eb25d52@wordpress.org>
Message-ID: <071.923f46bfa79af65fddcb25f1b399390d@wordpress.org>

#65113: Docs: Fix "objecct" typo in WP_Query post-loading comment
------------------------------+--------------------------
 Reporter:  parinpanjari      |       Owner:  westonruter
     Type:  defect (bug)      |      Status:  reviewing
 Priority:  lowest            |   Milestone:  7.1
Component:  Query             |     Version:  6.8
 Severity:  normal            |  Resolution:
 Keywords:  has-patch commit  |     Focuses:  docs
------------------------------+--------------------------

Comment (by gaurangsondagar):

 **Patch Testing Report**

 **Patch Tested:**
 https://core.trac.wordpress.org/attachment/ticket/65113/ticket-2-class-wp-
 query-objecct.diff

 **Environment:**
 - WordPress: 7.0 RC2
 - PHP: 8.2
 - OS: Ubuntu
 - Server: Apache
 - Browser: Chrome

 **Testing Steps:**
 - I have manually reviewed the code in the following file using the latest
 7.0 RC2 version.
 {{{
 wp-includes/class-wp-query.php
 }}}
 - Verified the "objecct" typo in WP_Query post-loading comment.


 Please look at the following reference screenshot:
 https://snipboard.io/IipF5U.jpg


 **Result:**
 The patch has been verified and it's correct.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65113#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 08:07:04 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 08:07:04 -0000
Subject: [wp-trac] [WordPress Trac] #65112: Docs: Correct typos in JS
 inline comments and docblocks
In-Reply-To: <056.e43e8e69989dc2ac5bb7184eef947c80@wordpress.org>
References: <056.e43e8e69989dc2ac5bb7184eef947c80@wordpress.org>
Message-ID: <071.a5737b028e65d61ea139de8d48b02afb@wordpress.org>

#65112: Docs: Correct typos in JS inline comments and docblocks
--------------------------+---------------------
 Reporter:  parinpanjari  |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.1
Component:  General       |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  docs
--------------------------+---------------------
Changes (by parinpanjari):

 * Attachment "65112.2.full.diff" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65112>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 08:13:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 08:13:55 -0000
Subject: [wp-trac] [WordPress Trac] #65112: Docs: Correct typos in JS
 inline comments and docblocks
In-Reply-To: <056.e43e8e69989dc2ac5bb7184eef947c80@wordpress.org>
References: <056.e43e8e69989dc2ac5bb7184eef947c80@wordpress.org>
Message-ID: <071.c425047d13b3805aefcae1d452cb9aa2@wordpress.org>

#65112: Docs: Correct typos in JS inline comments and docblocks
--------------------------+---------------------
 Reporter:  parinpanjari  |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.1
Component:  General       |     Version:
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  docs
--------------------------+---------------------

Comment (by parinpanjari):

 @westonruter

 Thanks! Attached an updated patch with the extra are removed. Fully
 understood on the 7.0 freeze, No rush.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65112#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 09:03:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 09:03:33 -0000
Subject: [wp-trac] [WordPress Trac] #52399: Remove widget accessibility
 mode
In-Reply-To: <053.0489bc31f838b1fc281e89857ce5df22@wordpress.org>
References: <053.0489bc31f838b1fc281e89857ce5df22@wordpress.org>
Message-ID: <068.6406e43e944ebf0a94e8611549ce3dc0@wordpress.org>

#52399: Remove widget accessibility mode
-------------------------------------+-------------------------------------
 Reporter:  joedolson                |       Owner:  rcreators
     Type:  enhancement              |      Status:  assigned
 Priority:  normal                   |   Milestone:  Future Release
Component:  Widgets                  |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  needs-patch needs-       |     Focuses:  ui, accessibility,
  design                             |  administration
-------------------------------------+-------------------------------------

Comment (by sanket.parmar):

 I spent some time doing a thorough code audit for this.

 '''How accessibility mode works today (code-level)'''

 The toggle lives in `wp-admin/widgets-form.php`. When `widgets_access =
 'on'` is stored via `set_user_setting()`, it adds the `widgets_access`
 body class and — critically — '''skips enqueuing `admin-widgets`
 entirely''', so drag-and-drop JS is never loaded. The accessible single-
 widget edit experience lives at `widgets.php?editwidget=<id>`, rendered by
 `wp-admin/includes/widgets.php`, and is fully server-side.

 The `.widget-control-edit a` (Edit/Add link) is already rendered in the
 markup for every widget in both modes; it is hidden in standard mode only
 by the `hide-if-js` class on that element.

 '''Proposed approach (phased)'''

 ''Phase 1 — Immediate, low risk:'' Remove `hide-if-js` from `.widget-
 control-edit a` in `wp_widget_control()`. This makes the Edit/Add text
 link permanently visible alongside the JS expand button. Keyboard and AT
 users get a plain-text path to the accessible single-widget edit page
 without needing to enable a mode. No JS changes required.

 ''Phase 2 — Address standard screen a11y gaps:'' Two gaps exist in `admin-
 widgets` JS that accessibility mode currently sidesteps by not loading JS
 at all:
  * No `wp.a11y.speak()` call after AJAX save or delete (only "Add" has
 one, at line ~706 of `widgets.js`).
  * Focus is dropped to `<body>` after widget delete — no focus restore
 logic exists in that code path.

 Both should be fixed before the mode toggle is removed, so the standard
 screen is actually equivalent.

 ''Phase 3 — Remove the toggle:'' Once Phases 1–2 land,
 `wp_widgets_access_body_class()` becomes unused. It should be deprecated
 with `_deprecated_function()` and kept as a no-op for one major version —
 third-party plugins may target that body class in their CSS.

 '''Two smaller issues found along the way'''

 The help tab text reads: ''"Enabling Accessibility Mode, via Screen
 Options"'' — the toggle has never been in Screen Options, it is a link
 under the page heading. Independent doc bug.

 `$_GET['editwidget']` in `widgets-form.php` (~line 228) is used
 unsanitized as an array key. No injection vector today since it only does
 a `$wp_registered_widget_controls[$widget_id]` lookup, but
 `sanitize_key()` would be consistent with how `$_POST['widget-id']` is
 handled elsewhere.

 '''Testing note'''

 Since 5.8 the classic widget screen only appears with the Classic Widgets
 plugin active or `remove_theme_support('widgets-block-editor')`, so any
 test setup needs to account for that.

 Happy to put together a patch starting with Phase 1 if that direction
 looks good to the accessibility team.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/52399#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 09:49:40 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 09:49:40 -0000
Subject: [wp-trac] [WordPress Trac] #65117: Proposal: Hook Permissions Layer
Message-ID: <058.1dbd21cd15065ddb6712c145e34a008f@wordpress.org>

#65117: Proposal: Hook Permissions Layer
-----------------------------+---------------------------------------
 Reporter:  namith.jawahar   |      Owner:  (none)
     Type:  feature request  |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  Plugins          |    Version:
 Severity:  normal           |   Keywords:  has-screenshots has-patch
  Focuses:                   |
-----------------------------+---------------------------------------
 = Proposal: Hook Permissions and Control System in WordPress Core =

 == Summary ==
 This proposal introduces a system to control how plugins and themes use
 WordPress hooks (add_action / add_filter).

 It will:
 * Track which hooks are used
 * Group them in a clear way
 * Let admins allow or block them
 * Show changes when plugins are updated

 == Problem ==
 Right now, WordPress runs all hooks without any control.

 This makes it hard to:
 * Understand what a plugin is doing
 * Stop unwanted behavior
 * Detect changes after updates

 == Proposed Solution ==

 === 1. Track Hook Usage ===
 * Record all hooks being registered
 * Store:
 ** Hook name
 ** Callback
 ** Priority
 ** Source (which plugin or theme added it)

 === 2. Control Execution ===
 * Hooks can still be registered normally
 * Before running a hook:
 ** Check if it is allowed
 ** If not allowed, skip it

 === 3. Permissions System ===
 * Store permissions per plugin/theme:

 {{{
 {
   "plugin-x/plugin.php": {
     "init": true,
     "admin_init": false
   }
 }
 }}}

 * New or unknown hooks are '''blocked by default''' until approved

 === 4. Group Hooks ===
 Show hooks in simple groups:

 * Admin (dashboard related)
 * Frontend (site output)
 * Content (posts, titles, etc.)
 * Database (saving/deleting data)
 * Users (login, registration)
 * System (core lifecycle hooks like init)

 === 5. Scan Plugins/Themes ===
 When a plugin or theme is activated or updated:

 * Scan code to find hooks
 * Also track hooks at runtime (for dynamic cases)

 === 6. Permissions UI ===
 * Show a popup on activation/update
 * List all hooks used
 * Group them clearly
 * Let users enable/disable with checkboxes
 * Show warning: disabling hooks may break functionality

 === 7. Author Notes (permissions.json) ===
 Plugin authors can include a file:

 {{{
 {
   "init": "Used to start the plugin",
   "wp_footer": "Adds script to page"
 }
 }
 }}}

 * This helps users understand why hooks are needed

 === 8. Detect Changes on Update ===
 When a plugin updates:

 * Check for new hooks
 * Block new hooks by default
 * Show admin notice asking for approval


 === 9. Existing Plugins (Backward Compatibility) ===
 To avoid breaking existing sites:

 * All hooks for already-installed plugins/themes are '''allowed by
 default'''
 * These plugins will be marked as '''"Unreviewed"'''
 * Admins can later review and update permissions manually

 When a reviewed plugin is updated:
 * Any new hooks will be treated as '''new permissions'''
 * These new hooks will be blocked until approved

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65117>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 09:50:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 09:50:05 -0000
Subject: [wp-trac] [WordPress Trac] #65117: Proposal: Hook Permissions
 Layer
In-Reply-To: <058.1dbd21cd15065ddb6712c145e34a008f@wordpress.org>
References: <058.1dbd21cd15065ddb6712c145e34a008f@wordpress.org>
Message-ID: <073.5e8d938802eb5c5a2d43f13da3847b6e@wordpress.org>

#65117: Proposal: Hook Permissions Layer
---------------------------------------+------------------------------
 Reporter:  namith.jawahar             |       Owner:  (none)
     Type:  feature request            |      Status:  new
 Priority:  normal                     |   Milestone:  Awaiting Review
Component:  Plugins                    |     Version:
 Severity:  normal                     |  Resolution:
 Keywords:  has-screenshots has-patch  |     Focuses:
---------------------------------------+------------------------------
Changes (by namith.jawahar):

 * Attachment "wp-hook-permissions-0.1.0.zip" added.

 The proposal implemented as an MU Plugin

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65117>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 10:07:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 10:07:12 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.18c6a99d505520b2b872bee1603b2413@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
---------------------------------------+-----------------------
 Reporter:  shatrumyatra               |       Owner:  audrasjb
     Type:  defect (bug)               |      Status:  accepted
 Priority:  normal                     |   Milestone:  7.0
Component:  Administration             |     Version:  trunk
 Severity:  normal                     |  Resolution:
 Keywords:  has-screenshots has-patch  |     Focuses:  ui
---------------------------------------+-----------------------

Comment (by gaurangsondagar):

 **Patch Testing Report**

 **Patch Tested:**
 https://core.trac.wordpress.org/attachment/ticket/65104/patch-65105.diff

 **Environment:**
 - WordPress: 7.0-RC2-62242
 - PHP: 8.2.29
 - Server: Apache
 - Database: MySQL
 - Browser: Chrome 146.0.7680.164
 - OS: Ubuntu 22.04.5 LTS

 **Steps performed:**
 - Navigated to the Posts screen
 - Accessed the Screen Options panel
 - Set the **Number of items per page** to values as 999

 **Result:**
 I was unable to reproduce the issue, and everything appears to be
 functioning as expected.

 Please review attached screenshots as a reference:
 https://snipboard.io/XKfgsP.jpg
 https://snipboard.io/DuzymO.jpg

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 10:54:32 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 10:54:32 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.cad2be9328eef34bb1f9ea865bc90c63@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
---------------------------------------+-----------------------
 Reporter:  shatrumyatra               |       Owner:  audrasjb
     Type:  defect (bug)               |      Status:  accepted
 Priority:  normal                     |   Milestone:  7.0
Component:  Administration             |     Version:  trunk
 Severity:  normal                     |  Resolution:
 Keywords:  has-screenshots has-patch  |     Focuses:  ui
---------------------------------------+-----------------------

Comment (by jigarkahar):

 === Test Report
 ==== Description
 ✅ This report validates that the indicated patch works as expected.

 Patch tested: https://github.com/WordPress/wordpress-develop/pull/11626

 === Environment
 - WordPress: 7.0-RC2
 - PHP: 8.3.30
 - Server: PHP.wasm
 - Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
 - Browser: Chrome 147.0.0.0
 - OS: Windows 10/11
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None activated
 - Plugins:
   * Test Reports 1.2.1

 === Steps to Reproduce
 1. Go to any admin screen that supports Screen Options (for example Posts,
 Pages, Users, Plugins, etc.).
 2. Open Screen Options.
 3. In Number of items per page, enter a 4-digit number such as 1000.
 4. Observe the input field display.

 === Actual Results
 1. ✅ Issue resolved with patch.
 2. The entered value is clearly visible in the input field.
 3. I also tested with a 5-digit value such as 10000, and it remained
 clearly visible without clipping.

 === Supplemental Artifacts
 Before: https://prnt.sc/3jUW29jEl5Qi
 After: https://prnt.sc/PFkDWhzCDq6W

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 11:24:21 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 11:24:21 -0000
Subject: [wp-trac] [WordPress Trac] #65094: AI: Prompt construction
 fails with fatal error when wp_ai_client_default_request_timeout filter
 returns negative number
In-Reply-To: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
References: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
Message-ID: <070.76fd8114ccd94d663ec739e4cec59ca5@wordpress.org>

#65094: AI: Prompt construction fails with fatal error when
wp_ai_client_default_request_timeout filter returns negative number
-------------------------------------------------+-------------------------
 Reporter:  westonruter                          |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  AI                                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests commit      |     Focuses:
  dev-feedback                                   |
-------------------------------------------------+-------------------------

Comment (by khushdoms):

 Performed additional edge-case testing on 7.0 RC2:

 - null → handled safely, no fatal error
 - INF → no crash, request proceeds as expected
 - float (0.5) → accepted and applied correctly
 - invalid string → ignored, fallback applied
 - large value → works without issues

 No regressions observed across all cases.

 The fix is robust and handles unexpected filter inputs gracefully.

 Suggestion:
 It may be helpful to document supported return types for this filter
 (float, null, INF) to improve developer clarity.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65094#comment:27>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 12:51:47 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 12:51:47 -0000
Subject: [wp-trac] [WordPress Trac] #65101: Ensure layout classnames are
 applied to the inner blocks wrapper and not to its siblings
In-Reply-To: <057.09a82a11408fc6a4f4795b8037791d84@wordpress.org>
References: <057.09a82a11408fc6a4f4795b8037791d84@wordpress.org>
Message-ID: <072.246714fe91903a568db118a8f099dee6@wordpress.org>

#65101: Ensure layout classnames are applied to the inner blocks wrapper and not to
its siblings
-------------------------------------------------+-------------------------
 Reporter:  isabel_brison                        |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  7.1
Component:  Editor                               |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  gutenberg-merge has-patch has-unit-  |     Focuses:
  tests                                          |
-------------------------------------------------+-------------------------

Comment (by gaurangsondagar):

 **Patch Testing Report**

 **Tested the patch:** https://github.com/WordPress/gutenberg/pull/77408

 **Environment:**
 - WordPress: 7.0-RC2-62242
 - PHP: 8.2.29
 - Server: Apache
 - Database: MySQL
 - Browser: Chrome 146.0.7680.164
 - OS: Ubuntu 22.04.5 LTS

 **I tested the things as follow:**
 - Implemented the patch provided in this ticket
 - Set up Group blocks using different layout configurations
 - Included both nested and sibling blocks in the structure and validate
 the results

 **Results:**
 The applied patch is working as expected.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65101#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 13:25:20 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 13:25:20 -0000
Subject: [wp-trac] [WordPress Trac] #65117: Proposal: Hook Permissions
 Layer
In-Reply-To: <058.1dbd21cd15065ddb6712c145e34a008f@wordpress.org>
References: <058.1dbd21cd15065ddb6712c145e34a008f@wordpress.org>
Message-ID: <073.d7869d989cd6c052dd7298111a509886@wordpress.org>

#65117: Proposal: Hook Permissions Layer
---------------------------------------+------------------------------
 Reporter:  namith.jawahar             |       Owner:  (none)
     Type:  feature request            |      Status:  new
 Priority:  normal                     |   Milestone:  Awaiting Review
Component:  Plugins                    |     Version:
 Severity:  normal                     |  Resolution:
 Keywords:  has-screenshots has-patch  |     Focuses:
---------------------------------------+------------------------------

Comment (by namith.jawahar):

 Video of how it works
 https://drive.google.com/file/d/1y3G2tPSK0OU9uYFWejvrDg6p9kIaIJH9/view

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65117#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 16:28:36 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 16:28:36 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.ab271a92bb6b3cd3f206fadafe2ada08@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
---------------------------------------+-----------------------
 Reporter:  shatrumyatra               |       Owner:  audrasjb
     Type:  defect (bug)               |      Status:  accepted
 Priority:  normal                     |   Milestone:  7.0
Component:  Administration             |     Version:  trunk
 Severity:  normal                     |  Resolution:
 Keywords:  has-screenshots has-patch  |     Focuses:  ui
---------------------------------------+-----------------------

Comment (by juanmaguitar):

 As per today's bug scrub

 > There was a suggestion by @audrasjb that has been added to the patch.
 There are a Patch Testing Report that verifies the path so I would say the
 ticket is ready to be merged.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 16:33:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 16:33:39 -0000
Subject: [wp-trac] [WordPress Trac] #64596: Abilities API: Allow ability
 names to contain multiple slug fragments (2-4 segments) (was: Abilities
 API: Allow nested namespace ability names (2-4 segments))
In-Reply-To: <060.74f0d53f8f168f6d8e4740aae322ab76@wordpress.org>
References: <060.74f0d53f8f168f6d8e4740aae322ab76@wordpress.org>
Message-ID: <075.8ab58ea34a15dfa188f79304bb8c752b@wordpress.org>

#64596: Abilities API: Allow ability names to contain multiple slug fragments (2-4
segments)
------------------------------------------------+--------------------------
 Reporter:  jorgefilipecosta                    |       Owner:
                                                |  jorgefilipecosta
     Type:  enhancement                         |      Status:  reopened
 Priority:  normal                              |   Milestone:
Component:  Abilities API                       |     Version:  trunk
 Severity:  normal                              |  Resolution:
 Keywords:  abilities has-patch has-unit-tests  |     Focuses:
------------------------------------------------+--------------------------
Changes (by justlevine):

 * status:  closed => reopened
 * resolution:  wontfix =>


Comment:

 @jorgefilipecosta on what basis did you change this to close+wontfix ?
 AFAIK this is still slated for 7.1 inclusion (and ideally `early` to allow
 us to iterate on our slate of core + ai plugin Abilities with their
 intended names).

 As I see no record that a contrary decision was made or any discussions on
 the topic since I last brought it up in Slack and the Contributor call a
 couple weeks ago, I'm assuming this was a triaging mistake and reopening
 🙇

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64596#comment:25>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 17:00:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 17:00:12 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.94f9dd6bc9d04ce3867b6d1de11e9fb3@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
---------------------------------------+-----------------------
 Reporter:  shatrumyatra               |       Owner:  audrasjb
     Type:  defect (bug)               |      Status:  accepted
 Priority:  normal                     |   Milestone:  7.0
Component:  Administration             |     Version:  trunk
 Severity:  normal                     |  Resolution:
 Keywords:  has-screenshots has-patch  |     Focuses:  ui
---------------------------------------+-----------------------

Comment (by shailu25):

 == **Test Report**

 This Report Validates that the indicated patch address the issue.✅

 **Patch Tested:** https://github.com/WordPress/wordpress-
 develop/pull/11626

 === **Environment:**
 WordPress -  7.1-alpha-20260423.153912
 OS - Windows
 Browser - Chrome
 Theme: Twenty Twenty Five
 PHP - 8.2
 Plugin - None

 === **Actual Results:**
 - Issue Resolved with Patch ✅

 === **Supplemental Artifacts**
 - Attached

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 17:00:42 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 17:00:42 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.d4a660f6ef118b3e2a6a4ff631b85305@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
---------------------------------------+-----------------------
 Reporter:  shatrumyatra               |       Owner:  audrasjb
     Type:  defect (bug)               |      Status:  accepted
 Priority:  normal                     |   Milestone:  7.0
Component:  Administration             |     Version:  trunk
 Severity:  normal                     |  Resolution:
 Keywords:  has-screenshots has-patch  |     Focuses:  ui
---------------------------------------+-----------------------
Changes (by shailu25):

 * Attachment "before-patch.png" added.

 Before Patch

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 17:01:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 17:01:06 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.866a32e222650d57382754129e2ffc9c@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
---------------------------------------+-----------------------
 Reporter:  shatrumyatra               |       Owner:  audrasjb
     Type:  defect (bug)               |      Status:  accepted
 Priority:  normal                     |   Milestone:  7.0
Component:  Administration             |     Version:  trunk
 Severity:  normal                     |  Resolution:
 Keywords:  has-screenshots has-patch  |     Focuses:  ui
---------------------------------------+-----------------------
Changes (by shailu25):

 * Attachment "after-patch.png" added.

 After Patch

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 17:34:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 17:34:48 -0000
Subject: [wp-trac] [WordPress Trac] #65118: Docs: Correct WP_Network_Query
 params comments
Message-ID: <062.bc857a5e1fc74eb71c058f3d42270cc9@wordpress.org>

#65118: Docs: Correct WP_Network_Query params comments
---------------------------------------------+-----------------------------
 Reporter:  baikare.sandeep007               |      Owner:  (none)
     Type:  enhancement                      |     Status:  new
 Priority:  normal                           |  Milestone:  Awaiting Review
Component:  Networks and Sites               |    Version:  trunk
 Severity:  normal                           |   Keywords:  has-patch
  Focuses:  docs, administration, multisite  |
---------------------------------------------+-----------------------------
 = This patch improves the inline documentation for the WP_Network_Query
 class: =

 * Clarifies and corrects PHPDoc blocks for class properties, specifying
 types and expected values.
 * Updates the constructor’s parameter documentation to reference the
 accepted arguments and their types.
 * Improves descriptions for complex array properties and return values,
 especially for query variables and results.
 * Enhances code readability and assists developers and IDEs with more
 accurate type information.

 '''These changes are documentation-only and do not affect runtime
 behavior.'''

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65118>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 17:35:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 17:35:30 -0000
Subject: [wp-trac] [WordPress Trac] #65118: Docs: Correct
 WP_Network_Query params comments
In-Reply-To: <062.bc857a5e1fc74eb71c058f3d42270cc9@wordpress.org>
References: <062.bc857a5e1fc74eb71c058f3d42270cc9@wordpress.org>
Message-ID: <077.ec26f770c24d8be89aef9beea3755868@wordpress.org>

#65118: Docs: Correct WP_Network_Query params comments
----------------------------+----------------------------------------------
 Reporter:                  |       Owner:  (none)
  baikare.sandeep007        |
     Type:  enhancement     |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Networks and    |     Version:  trunk
  Sites                     |
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:  docs, administration, multisite
----------------------------+----------------------------------------------
Changes (by baikare.sandeep007):

 * Attachment "network-query.patch" added.

 network query comment documentation improvements

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65118>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 17:47:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 17:47:44 -0000
Subject: [wp-trac] [WordPress Trac] #65116: Feature request: On This Day
 dashboard widget
In-Reply-To: <053.013a3a9617eae6ca499f347ee9f9a63c@wordpress.org>
References: <053.013a3a9617eae6ca499f347ee9f9a63c@wordpress.org>
Message-ID: <068.7307f646da61744f31a5299e1f806509@wordpress.org>

#65116: Feature request: On This Day dashboard widget
-------------------------+-------------------------------------------------
 Reporter:  alshakero    |       Owner:  (none)
     Type:  feature      |      Status:  new
  request                |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Widgets      |     Version:  trunk
 Severity:  minor        |  Resolution:
 Keywords:  has-patch    |     Focuses:  ui, administration, sustainability
-------------------------+-------------------------------------------------

Comment (by eclev91):

 I just don't think "how cool would it be" (Matt's words regarding changes
 to the dashboard) is a good criteria for what should go into core.

 "There was a lot of excitement...it didn't get picked up."

 So not ''that'' much excitement.

 Matt goes on to talk about the low complexity of doing it, which is
 certainly true. But many things are easy without being worthy of doing.

 Maybe I'm missing context. The core committer minutes simply say "Are
 there new widgets that can be added..." with a couple of examples, which
 says to me "We think the dashboard could be more useful. There should be
 discussion around what makes it not useful. What would make it more
 useful?" The minutes don't suggest that conversation happened, but Matt,
 in the video meeting, mentions people "making the dashboard their own",
 which is an actionable goal and maybe even an important one.

 But this widget creates an additional query on the dashboard and loads yet
 another stylesheet, which is far from the experience I want on the
 dashboard if I'm making it my own. If you disable the widget with Screen
 Options, it just hides it with CSS. It doesn't remove the box and improve
 performance related to its inclusion. It's relevant to one subset of users
 and contributing to a noise problem for the rest. Does its default
 inclusion help people "make the dashboard their own", or does this serve
 only a subset of users rather than create a user experience pattern that
 actually serves the stated goal?

 I'm far from well plugged into core development, and the code is already
 written, but can this at least be something you opt into rather than have
 to disable on sites where it's irrelevant?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65116#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 18:13:11 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 18:13:11 -0000
Subject: [wp-trac] [WordPress Trac] #65119: Docs: Correct the
 grammer/spelling in api.js documentation
Message-ID: <062.f5e5b79d8716fc3c1d2728e09f8667ce@wordpress.org>

#65119: Docs: Correct the grammer/spelling in api.js documentation
------------------------------------------------+--------------------------
 Reporter:  baikare.sandeep007                  |      Owner:  (none)
     Type:  enhancement                         |     Status:  new
 Priority:  normal                              |  Milestone:  Awaiting
                                                |  Review
Component:  Text Changes                        |    Version:  trunk
 Severity:  normal                              |   Keywords:
  Focuses:  javascript, docs, coding-standards  |
------------------------------------------------+--------------------------
 During a routine review of `src/js/_enqueues/wp/api.js`, I identified
 several grammatical errors and spelling inconsistencies within the inline
 comments. These issues, while minor, can hinder readability and
 comprehension for developers working with or learning from this code.

 '''Changes Made: '''

 This patch improves the inline documentation by:

 * Correcting spelling mistakes throughout the file's comment blocks
 * Fixing grammatical errors to enhance sentence clarity and flow
 * Maintaining the original technical meaning and intent of all comments
 * Preserving consistent terminology and code comment formatting standards

 '''Impact:'''


 These changes are purely documentation-focused and have no impact on:
 * Code execution or functionality
 * API behavior or public interfaces
 * Performance or backward compatibility

 ''' Testing:'''

 No functional testing is required as these changes only affect inline
 comments. The patch has been verified to contain only whitespace and text
 modifications within comment blocks.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65119>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 18:13:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 18:13:30 -0000
Subject: [wp-trac] [WordPress Trac] #65119: Docs: Correct the
 grammer/spelling in api.js documentation
In-Reply-To: <062.f5e5b79d8716fc3c1d2728e09f8667ce@wordpress.org>
References: <062.f5e5b79d8716fc3c1d2728e09f8667ce@wordpress.org>
Message-ID: <077.a915f3eab63ad94c6e878da5b1da1eb4@wordpress.org>

#65119: Docs: Correct the grammer/spelling in api.js documentation
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  (none)
  baikare.sandeep007     |
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Text         |     Version:  trunk
  Changes                |
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:  javascript, docs, coding-standards
-------------------------+-------------------------------------------------
Changes (by baikare.sandeep007):

 * Attachment "api.js-doc-enhancement.patch" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65119>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 18:14:52 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 18:14:52 -0000
Subject: [wp-trac] [WordPress Trac] #65119: Docs: Correct the
 grammer/spelling in api.js documentation
In-Reply-To: <062.f5e5b79d8716fc3c1d2728e09f8667ce@wordpress.org>
References: <062.f5e5b79d8716fc3c1d2728e09f8667ce@wordpress.org>
Message-ID: <077.eea87ec0202e3419c3b4cad9224d8aaf@wordpress.org>

#65119: Docs: Correct the grammer/spelling in api.js documentation
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  (none)
  baikare.sandeep007     |
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Text         |     Version:  trunk
  Changes                |
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  javascript, docs, coding-standards
-------------------------+-------------------------------------------------
Changes (by baikare.sandeep007):

 * keywords:   => has-patch


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65119#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 18:57:36 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 18:57:36 -0000
Subject: [wp-trac] [WordPress Trac] #65120: Add
 `wp_elements_block_supports_class_name` filter to
 `wp_get_elements_class_name()`
Message-ID: <062.c5c4315f56dd742dd7ff410a88a4ea8d@wordpress.org>

#65120: Add `wp_elements_block_supports_class_name` filter to
`wp_get_elements_class_name()`
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  (none)
  baikare.sandeep007     |
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  Editor       |    Version:  trunk
 Severity:  normal       |   Keywords:  has-patch needs-testing has-test-
  Focuses:  template     |  info
-------------------------+-------------------------------------------------
 == Description

 This patch introduces a new filter,
 `wp_elements_block_supports_class_name`, to the
 `wp_get_elements_class_name()` function. This allows developers to
 customize the generated CSS class name for block elements.

 == Current Behavior

 Currently, the function generates a class name by serializing the entire
 block array and creating an MD5 hash:

 {{{
 $class_name = 'wp-elements-' . md5( serialize( $block ) );
 }}}

 There is no mechanism for developers to modify or override the generated
 class name without hijacking the entire function.

 == Proposed Change

 The patch adds a filter to enable customization:

 {{{
 return apply_filters( 'wp_elements_block_supports_class_name',
 $class_name, $block );
 }}}

 == Use Cases

 This filter is valuable for:

  1. **Performance optimization** – Replace `serialize()` + `md5()` with
 more efficient class name generation for complex blocks.
  2. **Cache-friendly class names** – Generate human-readable names for
 easier debugging.
  3. **Custom hashing logic** – Implement alternative algorithms or naming
 conventions.
  4. **Integration with build tools** – Align class names with external CSS
 processes.

 == Example

 A developer could use the filter to create more readable class names:

 {{{
 add_filter( 'wp_elements_block_supports_class_name', function(
 $class_name, $block ) {
     if ( isset( $block['attrs']['id'] ) ) {
         return 'wp-elements-' . $block['blockName'] . '-' .
 $block['attrs']['id'];
     }
     return $class_name;
 }, 10, 2 );
 }}}

 == Impact

  * **Backward compatibility:** Yes – existing behavior remains unchanged
 when the filter is not used.
  * **Performance overhead:** Negligible – only executes when hooked.
  * **Functional change:** None – additive only.

 == Testing

 Patch verified:
   * Existing functionality unchanged without filter.
   * Filter properly receives both `$class_name` and `$block` parameters.
   * Filter return value properly replaces the default class name.

 == Additional Notes

  * `@since` tag used: `7.1.0`
  * Props: `@baikare.sandeep007`

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65120>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 18:57:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 18:57:48 -0000
Subject: [wp-trac] [WordPress Trac] #65120: Add
 `wp_elements_block_supports_class_name` filter to
 `wp_get_elements_class_name()`
In-Reply-To: <062.c5c4315f56dd742dd7ff410a88a4ea8d@wordpress.org>
References: <062.c5c4315f56dd742dd7ff410a88a4ea8d@wordpress.org>
Message-ID: <077.3eae2876e64ecce122d08170cfa083f4@wordpress.org>

#65120: Add `wp_elements_block_supports_class_name` filter to
`wp_get_elements_class_name()`
-------------------------------------------------+-------------------------
 Reporter:  baikare.sandeep007                   |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Editor                               |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing has-test-    |     Focuses:  template
  info                                           |
-------------------------------------------------+-------------------------
Changes (by baikare.sandeep007):

 * Attachment "wp-elements-block-support-hook.patch" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65120>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 18:59:38 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 18:59:38 -0000
Subject: [wp-trac] [WordPress Trac] #65120: Add
 `wp_elements_block_supports_class_name` filter to
 `wp_get_elements_class_name()`
In-Reply-To: <062.c5c4315f56dd742dd7ff410a88a4ea8d@wordpress.org>
References: <062.c5c4315f56dd742dd7ff410a88a4ea8d@wordpress.org>
Message-ID: <077.c5049703dfe1920058ae96ca91d39e1c@wordpress.org>

#65120: Add `wp_elements_block_supports_class_name` filter to
`wp_get_elements_class_name()`
-------------------------------------+-------------------------------------
 Reporter:  baikare.sandeep007       |       Owner:  (none)
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Editor                   |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  template, performance,
  has-test-info                      |  coding-standards
-------------------------------------+-------------------------------------
Changes (by baikare.sandeep007):

 * focuses:  template => template, performance, coding-standards


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65120#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 19:00:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 19:00:17 -0000
Subject: [wp-trac] [WordPress Trac] #65120: Add
 `wp_elements_block_supports_class_name` filter to
 `wp_get_elements_class_name()`
In-Reply-To: <062.c5c4315f56dd742dd7ff410a88a4ea8d@wordpress.org>
References: <062.c5c4315f56dd742dd7ff410a88a4ea8d@wordpress.org>
Message-ID: <077.a35425d9524ea6074fb1bb3c2aa920ba@wordpress.org>

#65120: Add `wp_elements_block_supports_class_name` filter to
`wp_get_elements_class_name()`
-------------------------------------+-------------------------------------
 Reporter:  baikare.sandeep007       |       Owner:  (none)
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Editor                   |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  template, performance,
  has-test-info needs-docs           |  coding-standards
-------------------------------------+-------------------------------------
Changes (by baikare.sandeep007):

 * keywords:  has-patch needs-testing has-test-info => has-patch needs-
     testing has-test-info needs-docs


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65120#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 19:01:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 19:01:13 -0000
Subject: [wp-trac] [WordPress Trac] #65120: Add
 `wp_elements_block_supports_class_name` filter to
 `wp_get_elements_class_name()`
In-Reply-To: <062.c5c4315f56dd742dd7ff410a88a4ea8d@wordpress.org>
References: <062.c5c4315f56dd742dd7ff410a88a4ea8d@wordpress.org>
Message-ID: <077.597da3392c068fe4e2a505fed58209cb@wordpress.org>

#65120: Add `wp_elements_block_supports_class_name` filter to
`wp_get_elements_class_name()`
-------------------------------------+-------------------------------------
 Reporter:  baikare.sandeep007       |       Owner:  (none)
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Editor                   |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  template, performance,
  has-test-info                      |  coding-standards
-------------------------------------+-------------------------------------
Changes (by baikare.sandeep007):

 * keywords:  has-patch needs-testing has-test-info needs-docs => has-patch
     needs-testing has-test-info


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65120#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 19:47:46 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 19:47:46 -0000
Subject: [wp-trac] [WordPress Trac] #65116: Feature request: On This Day
 dashboard widget
In-Reply-To: <053.013a3a9617eae6ca499f347ee9f9a63c@wordpress.org>
References: <053.013a3a9617eae6ca499f347ee9f9a63c@wordpress.org>
Message-ID: <068.a75039c10839a1320736d46e14ddaa2c@wordpress.org>

#65116: Feature request: On This Day dashboard widget
-------------------------+-------------------------------------------------
 Reporter:  alshakero    |       Owner:  (none)
     Type:  feature      |      Status:  new
  request                |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Widgets      |     Version:  trunk
 Severity:  minor        |  Resolution:
 Keywords:  has-patch    |     Focuses:  ui, administration, sustainability
-------------------------+-------------------------------------------------

Comment (by annezazu):

 >I just don't think "how cool would it be" (Matt's words regarding changes
 to the dashboard) is a good criteria for what should go into core.

 Matt asked what happened to it and wanted to see it in Core. @matt if you
 would like to chime in. I will let what's there speak for itself for now.

 In the same way default dashboard widgets, like site health status, can be
 controlled by screen options, this can also be something that can be
 turned on/off.

 The redesign looks great! Thank you.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65116#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 22:12:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 22:12:57 -0000
Subject: [wp-trac] [WordPress Trac] #64225: Test tool and unit test
 improvements for 7.0
In-Reply-To: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
References: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
Message-ID: <066.77e21cb20b7b5aa7ad4d251a2d0fc10a@wordpress.org>

#64225: Test tool and unit test improvements for 7.0
--------------------------------------+---------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  task (blessed)            |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by SergeyBiryukov):

 In [changeset:"62259" 62259]:
 {{{
 #!CommitTicketReference repository="" revision="62259"
 Tests: Add missing `@covers` tags for `WP_Block_Parser` tests.

 Includes moving the data provider after the corresponding test for
 consistency with the rest of the test suite.

 Follow-up to [43751].

 Props sagardeshmukh.
 See #64225.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64225#comment:72>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 23 23:41:08 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 23 Apr 2026 23:41:08 -0000
Subject: [wp-trac] [WordPress Trac] #59956: author feed having an issue
 on latest WP6.4 version
In-Reply-To: <053.362fb15c9cd9cb0420f21af245fb152f@wordpress.org>
References: <053.362fb15c9cd9cb0420f21af245fb152f@wordpress.org>
Message-ID: <068.bd920acd903c2c8371562616031f2ddd@wordpress.org>

#59956: author feed having an issue on latest WP6.4 version
--------------------------------------+--------------------------
 Reporter:  janareddy                 |       Owner:  westonruter
     Type:  defect (bug)              |      Status:  reviewing
 Priority:  normal                    |   Milestone:  7.1
Component:  Feeds                     |     Version:  6.4
 Severity:  major                     |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+--------------------------
Changes (by westonruter):

 * owner:  (none) => westonruter
 * status:  assigned => reviewing


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59956#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 00:33:19 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 00:33:19 -0000
Subject: [wp-trac] [WordPress Trac] #65116: Feature request: On This Day
 dashboard widget
In-Reply-To: <053.013a3a9617eae6ca499f347ee9f9a63c@wordpress.org>
References: <053.013a3a9617eae6ca499f347ee9f9a63c@wordpress.org>
Message-ID: <068.141634089d12f4dadf64c00e210806b8@wordpress.org>

#65116: Feature request: On This Day dashboard widget
-------------------------+-------------------------------------------------
 Reporter:  alshakero    |       Owner:  (none)
     Type:  feature      |      Status:  new
  request                |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Widgets      |     Version:  trunk
 Severity:  minor        |  Resolution:
 Keywords:  has-patch    |     Focuses:  ui, administration, sustainability
-------------------------+-------------------------------------------------

Comment (by westonruter):

 Replying to [comment:9 annezazu]:
 > In the same way default dashboard widgets, like site health status, can
 be controlled by screen options, this can also be something that can be
 turned on/off.

 Regarding the query performance concern, it seems the issue is that the
 screen options checkboxes just hide/show the dashboard widget.  Ideally
 unchecking a screen options checkbox would omit the widget from being
 rendered in the first place. This would require a page reload to see the
 changes.

 That said, I don't think the additional query would be so expensive so I
 don't think that should be a blocker for adding this. The widgets could
 also be removed programmatically which would prevent them from being
 rendered or appearing in the screen options checkboxes for sites that are
 particularly concerned about this. But for scaling up the dashboard to
 have many more widgets, we should keep an eye on how we can do so
 performantly.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65116#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 00:41:37 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 00:41:37 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.882a3e49fd27c5837d6a8c997218dfbc@wordpress.org>

#65015: Connectors: Several strings are not translated
-------------------------------------------------+-------------------------
 Reporter:  369work                              |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  reviewing
 Priority:  high                                 |   Milestone:  7.0
Component:  I18N                                 |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests connectors  |     Focuses:
  commit dev-feedback needs-dev-note             |
-------------------------------------------------+-------------------------
Changes (by westonruter):

 * keywords:  has-patch has-unit-tests connectors commit dev-feedback =>
     has-patch has-unit-tests connectors commit dev-feedback needs-dev-note


Comment:

 The new translation support for modules seems like it warrants a dev note.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015#comment:27>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 00:44:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 00:44:44 -0000
Subject: [wp-trac] [WordPress Trac] #65112: Docs: Correct typos in JS
 inline comments and docblocks
In-Reply-To: <056.e43e8e69989dc2ac5bb7184eef947c80@wordpress.org>
References: <056.e43e8e69989dc2ac5bb7184eef947c80@wordpress.org>
Message-ID: <071.901c961f51f1dd18b70ddacfd8eedc5b@wordpress.org>

#65112: Docs: Correct typos in JS inline comments and docblocks
------------------------------+--------------------------
 Reporter:  parinpanjari      |       Owner:  westonruter
     Type:  defect (bug)      |      Status:  reviewing
 Priority:  lowest            |   Milestone:  7.1
Component:  General           |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  has-patch commit  |     Focuses:  docs
------------------------------+--------------------------
Changes (by westonruter):

 * keywords:  has-patch => has-patch commit
 * owner:  (none) => westonruter
 * status:  new => reviewing
 * priority:  normal => lowest


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65112#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 01:20:04 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 01:20:04 -0000
Subject: [wp-trac] [WordPress Trac] #65121: Command Palette: Label can be
 incorrect for sites served over a CDN
Message-ID: <057.7e3cb1dd81bd572af308eb2d325d069c@wordpress.org>

#65121: Command Palette: Label can be incorrect for sites served over a CDN
----------------------------+---------------------------
 Reporter:  peterwilsoncc   |      Owner:  peterwilsoncc
     Type:  defect (bug)    |     Status:  assigned
 Priority:  normal          |  Milestone:  7.0
Component:  Administration  |    Version:  trunk
 Severity:  normal          |   Keywords:
  Focuses:                  |
----------------------------+---------------------------
 The Command Pallet shortcut displayed in the admin bar is incorrect for
 macOs users when their site is hosted behind a CDN that removes the User-
 Agent HTTP header from requests passed through to the application server.

 This is a relatively common on CDNs as a way to increase cache hits at the
 edge.

 As Control+K does not trigger the command pallete on macOS, this can lead
 to confusion for users on such a configuration.

 Upstream Report: [https://github.com/WordPress/gutenberg/issues/77636
 GB#77636]

 **Recommended Fix**

 Recheck the User-Agent via JavaScript using `navigator.userAgent` and
 update the string used in the admin bar if it's determined to be macOS.

 **Reproduction Steps**

 1. Buy a macOS computer/use BrowserStack on macOS.
 2. In your `wp-config.php` file, add the code `$_SERVER['HTTP_USER_AGENT']
 = '';` to emulate a site behind a CDN stripping the header
 3. Visit `/wp-admin`
 4. Observe the shortcut displayed is incorrect
 5. Remove the code added to your `wp-config.php` file to avoid confusion
 later.

 See upstream issue for screenshot.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65121>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 02:22:50 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 02:22:50 -0000
Subject: [wp-trac] [WordPress Trac] #65121: Command Palette: Label can
 be incorrect for sites served over a CDN
In-Reply-To: <057.7e3cb1dd81bd572af308eb2d325d069c@wordpress.org>
References: <057.7e3cb1dd81bd572af308eb2d325d069c@wordpress.org>
Message-ID: <072.1545ad6fe6eb75b15b002874919624fe@wordpress.org>

#65121: Command Palette: Label can be incorrect for sites served over a CDN
----------------------------+----------------------------
 Reporter:  peterwilsoncc   |       Owner:  peterwilsoncc
     Type:  defect (bug)    |      Status:  assigned
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+----------------------------

Comment (by westonruter):

 For previous discussions on using JS, see:

 * https://github.com/WordPress/gutenberg/pull/75757#discussion_r2831423545
 * https://github.com/WordPress/wordpress-develop/pull/10985

 cc @bpayton @wildworks

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65121#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 02:57:36 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 02:57:36 -0000
Subject: [wp-trac] [WordPress Trac] #65121: Command Palette: Label can
 be incorrect for sites served over a CDN
In-Reply-To: <057.7e3cb1dd81bd572af308eb2d325d069c@wordpress.org>
References: <057.7e3cb1dd81bd572af308eb2d325d069c@wordpress.org>
Message-ID: <072.78819194a1b4abb18f9f6209e4e4de78@wordpress.org>

#65121: Command Palette: Label can be incorrect for sites served over a CDN
----------------------------+----------------------------
 Reporter:  peterwilsoncc   |       Owner:  peterwilsoncc
     Type:  defect (bug)    |      Status:  assigned
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+----------------------------

Comment (by peterwilsoncc):

 Replying to [comment:2 westonruter]:
 > For previous discussions on using JS, see...

 Thanks for pointing those out.

 The prompt for this ticket was that I noticed my site was displaying
 Ctrl+K despite using a Mac because I run my overengineered site behind
 CloudFront.

 Do you think that the use of both PHP and JS detection mitigates the
 concerns of a
 [https://github.com/WordPress/gutenberg/pull/75757#discussion_r2845450899
 flash of incorrect rendering] by treating the JS test as a last resort in
 case the PHP detection is incorrect? cc @wildworks

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65121#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 03:40:35 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 03:40:35 -0000
Subject: [wp-trac] [WordPress Trac] #65121: Command Palette: Label can
 be incorrect for sites served over a CDN
In-Reply-To: <057.7e3cb1dd81bd572af308eb2d325d069c@wordpress.org>
References: <057.7e3cb1dd81bd572af308eb2d325d069c@wordpress.org>
Message-ID: <072.a0e9c80ff5e822b2a10ed2e18de230b0@wordpress.org>

#65121: Command Palette: Label can be incorrect for sites served over a CDN
----------------------------+----------------------------
 Reporter:  peterwilsoncc   |       Owner:  peterwilsoncc
     Type:  defect (bug)    |      Status:  assigned
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+----------------------------

Comment (by westonruter):

 Replying to [comment:3 peterwilsoncc]:
 > Do you think that the use of both PHP and JS detection mitigates the
 concerns of a
 [https://github.com/WordPress/gutenberg/pull/75757#discussion_r2845450899
 flash of incorrect rendering] by treating the JS test as a last resort in
 case the PHP detection is incorrect? cc @wildworks

 I had forgotten that JS was not being used to render the node actually. I
 had assumed it was because there seems to be an issue with the admin bar
 flickering with view transitions:
 https://core.trac.wordpress.org/ticket/65032#comment:8

 But ultimately it does have `hide-if-no-js` which requires JS to run
 before the node is revealed. But this JS runs in `head` before rendering,
 as I recall, so that is okay. We should just make sure this new inline
 script also runs in the `head`.

 cc @zieladam

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65121#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 03:41:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 03:41:14 -0000
Subject: [wp-trac] [WordPress Trac] #65052: Nonce check order flaw in
 post-quickdraft-save
In-Reply-To: <052.5cb71bdc8207e81444fff364e3bc4f57@wordpress.org>
References: <052.5cb71bdc8207e81444fff364e3bc4f57@wordpress.org>
Message-ID: <067.44531da704528de59d73b81df30acb96@wordpress.org>

#65052: Nonce check order flaw in post-quickdraft-save
-------------------------------------------------+-------------------------
 Reporter:  rajeshcp                             |       Owner:  rajeshcp
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Security                             |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing has-test-    |     Focuses:
  info has-unit-tests                            |
-------------------------------------------------+-------------------------
Changes (by liaison):

 * keywords:  has-patch needs-testing has-test-info => has-patch needs-
     testing has-test-info has-unit-tests


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65052#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 03:52:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 03:52:33 -0000
Subject: [wp-trac] [WordPress Trac] #65121: Command Palette: Label can
 be incorrect for sites served over a CDN
In-Reply-To: <057.7e3cb1dd81bd572af308eb2d325d069c@wordpress.org>
References: <057.7e3cb1dd81bd572af308eb2d325d069c@wordpress.org>
Message-ID: <072.47b430f9dfc72292d0059031b54eb88e@wordpress.org>

#65121: Command Palette: Label can be incorrect for sites served over a CDN
---------------------------+----------------------------
 Reporter:  peterwilsoncc  |       Owner:  peterwilsoncc
     Type:  defect (bug)   |      Status:  assigned
 Priority:  normal         |   Milestone:  7.0
Component:  Toolbar        |     Version:  trunk
 Severity:  normal         |  Resolution:
 Keywords:  has-patch      |     Focuses:
---------------------------+----------------------------
Changes (by sabernhardt):

 * component:  Administration => Toolbar


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65121#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 04:12:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 04:12:55 -0000
Subject: [wp-trac] [WordPress Trac] #65052: Nonce check order flaw in
 post-quickdraft-save
In-Reply-To: <052.5cb71bdc8207e81444fff364e3bc4f57@wordpress.org>
References: <052.5cb71bdc8207e81444fff364e3bc4f57@wordpress.org>
Message-ID: <067.552b1b3a272ca095b7b3f876fd5133da@wordpress.org>

#65052: Nonce check order flaw in post-quickdraft-save
-------------------------------------------------+-------------------------
 Reporter:  rajeshcp                             |       Owner:  rajeshcp
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Security                             |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing has-test-    |     Focuses:
  info has-unit-tests                            |
-------------------------------------------------+-------------------------
Changes (by liaison):

 * Attachment "65052-github-ci-238pass.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65052>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 04:14:45 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 04:14:45 -0000
Subject: [wp-trac] [WordPress Trac] #65122: Accessibility issues in Visual
 History
Message-ID: <053.03187c24c116d522bc1a32795c230733@wordpress.org>

#65122: Accessibility issues in Visual History
---------------------------+-------------------------
 Reporter:  joedolson      |      Owner:  (none)
     Type:  defect (bug)   |     Status:  new
 Priority:  normal         |  Milestone:  7.0
Component:  Revisions      |    Version:
 Severity:  normal         |   Keywords:  needs-patch
  Focuses:  accessibility  |
---------------------------+-------------------------
 Adding this ticket for aid in tracking progress, but the relevant work is
 in the Gutenberg repository.

 See https://github.com/WordPress/gutenberg/issues/77530 for progress and
 sub-issues.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65122>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 04:29:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 04:29:22 -0000
Subject: [wp-trac] [WordPress Trac] #65121: Command Palette: Label can
 be incorrect for sites served over a CDN
In-Reply-To: <057.7e3cb1dd81bd572af308eb2d325d069c@wordpress.org>
References: <057.7e3cb1dd81bd572af308eb2d325d069c@wordpress.org>
Message-ID: <072.775b6bf152b10b5dc0114c94ec2cee72@wordpress.org>

#65121: Command Palette: Label can be incorrect for sites served over a CDN
---------------------------+----------------------------
 Reporter:  peterwilsoncc  |       Owner:  peterwilsoncc
     Type:  defect (bug)   |      Status:  assigned
 Priority:  normal         |   Milestone:  7.0
Component:  Toolbar        |     Version:  trunk
 Severity:  normal         |  Resolution:
 Keywords:  has-patch      |     Focuses:
---------------------------+----------------------------

Comment (by peterwilsoncc):

 As best I can tell there are two options for running the JavaScript
 fallback ASAP:

 * Add the script in `$wp_admin_bar->add_node( meta.html )` -- soonest
 * Add a `wp_print_inline_script_tag()` call to the
 `wp_after_admin_bar_render` action -- very soon after render

 In both cases, this would add a blocking script to the HTML header.

 The JavaScript fallback will be required by a small number of users: Mac
 OS users running their sites over CDNs that strip the User Agent header
 for admin requests.

 I'm inclined to accept the risk of a flash of incorrect content for those
 users and reconsider in 7.0.1 depending on the number of support
 requests/bug reports. It seems better than adding a blocking script the
 the HTML header for an edge case.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65121#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 04:50:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 04:50:06 -0000
Subject: [wp-trac] [WordPress Trac] #65121: Command Palette: Label can
 be incorrect for sites served over a CDN
In-Reply-To: <057.7e3cb1dd81bd572af308eb2d325d069c@wordpress.org>
References: <057.7e3cb1dd81bd572af308eb2d325d069c@wordpress.org>
Message-ID: <072.96857089a17b42f758f111bd7c646001@wordpress.org>

#65121: Command Palette: Label can be incorrect for sites served over a CDN
---------------------------+----------------------------
 Reporter:  peterwilsoncc  |       Owner:  peterwilsoncc
     Type:  defect (bug)   |      Status:  assigned
 Priority:  normal         |   Milestone:  7.0
Component:  Toolbar        |     Version:  trunk
 Severity:  normal         |  Resolution:
 Keywords:  has-patch      |     Focuses:
---------------------------+----------------------------

Comment (by westonruter):

 Since the blocking script is inline, then there is no external HTTP
 request that is contributing to it the blocking. There are already a few
 inline scripts in the `HEAD` in addition to external blocking scripts, so
 I don't think adding a new inline script will have any measurable impact
 on performance.

 I think your `$wp_admin_bar->add_node( meta.html )` solution is the best.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65121#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 05:08:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 05:08:16 -0000
Subject: [wp-trac] [WordPress Trac] #65119: Docs: Correct the
 grammer/spelling in api.js documentation
In-Reply-To: <062.f5e5b79d8716fc3c1d2728e09f8667ce@wordpress.org>
References: <062.f5e5b79d8716fc3c1d2728e09f8667ce@wordpress.org>
Message-ID: <077.b32d2aa956db126b4b74a32de4d3dd62@wordpress.org>

#65119: Docs: Correct the grammer/spelling in api.js documentation
--------------------------------+-------------------------------
 Reporter:  baikare.sandeep007  |       Owner:  (none)
     Type:  enhancement         |      Status:  new
 Priority:  normal              |   Milestone:  7.1
Component:  REST API            |     Version:  trunk
 Severity:  normal              |  Resolution:
 Keywords:  has-patch           |     Focuses:  javascript, docs
--------------------------------+-------------------------------
Changes (by westonruter):

 * focuses:  javascript, docs, coding-standards => javascript, docs
 * component:  Text Changes => REST API
 * milestone:  Awaiting Review => 7.1


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65119#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 05:15:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 05:15:44 -0000
Subject: [wp-trac] [WordPress Trac] #65044: get_post_custom_values()
 missing array check, inconsistent with get_post_custom_keys()
In-Reply-To: <057.4a59bcc730ee55ef2108915dd95410cb@wordpress.org>
References: <057.4a59bcc730ee55ef2108915dd95410cb@wordpress.org>
Message-ID: <072.5f689affc5581a774e24b7d441a67aa4@wordpress.org>

#65044: get_post_custom_values() missing array check, inconsistent with
get_post_custom_keys()
-------------------------------------------------+-------------------------
 Reporter:  saratheonline                        |       Owner:
                                                 |  saratheonline
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  7.1
Component:  Posts, Post Types                    |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing has-test-    |     Focuses:
  info has-unit-tests                            |
-------------------------------------------------+-------------------------
Changes (by liaison):

 * keywords:  has-patch needs-testing needs-unit-tests has-test-info => has-
     patch needs-testing has-test-info has-unit-tests


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65044#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 05:23:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 05:23:03 -0000
Subject: [wp-trac] [WordPress Trac] #63085: "Login details" spam sent by
 from the account registration page
In-Reply-To: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
References: <051.94d2cad914c7ade7cea278be61d78f9d@wordpress.org>
Message-ID: <066.c2f58c6b893d6f809aefac443674422a@wordpress.org>

#63085: "Login details" spam sent by from the account registration page
----------------------------------------------------+---------------------
 Reporter:  cweiske                                 |       Owner:  (none)
     Type:  defect (bug)                            |      Status:  new
 Priority:  normal                                  |   Milestone:  7.0.1
Component:  Login and Registration                  |     Version:
 Severity:  normal                                  |  Resolution:
 Keywords:  has-patch has-unit-tests has-test-info  |     Focuses:
----------------------------------------------------+---------------------

Comment (by cweiske):

 @johnbillion Is the current approach/patch moved to 7.0.1 for
 consideration, or only the topic?
 Would you rather get a patch that removes the username? Would that be more
 qualified for 7.0.0?

 When the username is removed, do you still deem it necessary to reject
 "www." in user names?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63085#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 05:37:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 05:37:23 -0000
Subject: [wp-trac] [WordPress Trac] #65044: get_post_custom_values()
 missing array check, inconsistent with get_post_custom_keys()
In-Reply-To: <057.4a59bcc730ee55ef2108915dd95410cb@wordpress.org>
References: <057.4a59bcc730ee55ef2108915dd95410cb@wordpress.org>
Message-ID: <072.b38fc6398bab5e54af41685bb147b4cb@wordpress.org>

#65044: get_post_custom_values() missing array check, inconsistent with
get_post_custom_keys()
-------------------------------------------------+-------------------------
 Reporter:  saratheonline                        |       Owner:
                                                 |  saratheonline
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  7.1
Component:  Posts, Post Types                    |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing has-test-    |     Focuses:
  info has-unit-tests                            |
-------------------------------------------------+-------------------------
Changes (by liaison):

 * Attachment "65044-github-ci-238pass.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65044>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 06:09:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 06:09:30 -0000
Subject: [wp-trac] [WordPress Trac] #65044: get_post_custom_values()
 missing array check, inconsistent with get_post_custom_keys()
In-Reply-To: <057.4a59bcc730ee55ef2108915dd95410cb@wordpress.org>
References: <057.4a59bcc730ee55ef2108915dd95410cb@wordpress.org>
Message-ID: <072.2bd84182eca14f68a509f5ddc77dd497@wordpress.org>

#65044: get_post_custom_values() missing array check, inconsistent with
get_post_custom_keys()
-------------------------------------------------+-------------------------
 Reporter:  saratheonline                        |       Owner:
                                                 |  saratheonline
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  7.1
Component:  Posts, Post Types                    |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing has-test-    |     Focuses:
  info has-unit-tests                            |
-------------------------------------------------+-------------------------

Comment (by westonruter):

 @liaison You do not need to share such a screenshot. The PR job status is
 shared where the pull requests are listed.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65044#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 06:14:51 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 06:14:51 -0000
Subject: [wp-trac] [WordPress Trac] #65119: Docs: Correct the
 grammer/spelling in api.js documentation
In-Reply-To: <062.f5e5b79d8716fc3c1d2728e09f8667ce@wordpress.org>
References: <062.f5e5b79d8716fc3c1d2728e09f8667ce@wordpress.org>
Message-ID: <077.3902d72caad350aa8f5adc385a73f4d5@wordpress.org>

#65119: Docs: Correct the grammer/spelling in api.js documentation
--------------------------------+-------------------------------
 Reporter:  baikare.sandeep007  |       Owner:  (none)
     Type:  enhancement         |      Status:  new
 Priority:  normal              |   Milestone:  7.1
Component:  REST API            |     Version:  trunk
 Severity:  normal              |  Resolution:
 Keywords:  has-patch           |     Focuses:  javascript, docs
--------------------------------+-------------------------------

Comment (by gaurangsondagar):

 **Patch Testing Report:**

 **Patch Tested:**
 https://core.trac.wordpress.org/attachment/ticket/65119/api.js-doc-
 enhancement.patch

 **Environment:**
 - WordPress: 7.0-RC2-62242
 - PHP: 8.2
 - Server: Apache
 - Browser: Chrome
 - OS: Ubuntu 22.04.5 LTS

 **Test Cases:**
 - I have reviewed and verified all the reported grammer/spelling mistake
 from the below file path.
 {{{
 wp-includes/js/wp-api.js
 }}}

 **Result:**
 I have verified and patch looks correctly applied.

 Please review the attached screenshots for reference:
 https://snipboard.io/zGhc53.jpg
 https://snipboard.io/Xq6k2U.jpg
 https://snipboard.io/envRLd.jpg

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65119#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 06:30:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 06:30:07 -0000
Subject: [wp-trac] [WordPress Trac] #65119: Docs: Correct the
 grammer/spelling in api.js documentation
In-Reply-To: <062.f5e5b79d8716fc3c1d2728e09f8667ce@wordpress.org>
References: <062.f5e5b79d8716fc3c1d2728e09f8667ce@wordpress.org>
Message-ID: <077.0e2e26651bbe56d6f5ac60adfa77ce11@wordpress.org>

#65119: Docs: Correct the grammer/spelling in api.js documentation
--------------------------------+-------------------------------
 Reporter:  baikare.sandeep007  |       Owner:  (none)
     Type:  enhancement         |      Status:  new
 Priority:  normal              |   Milestone:  7.1
Component:  REST API            |     Version:  trunk
 Severity:  normal              |  Resolution:
 Keywords:  has-patch           |     Focuses:  javascript, docs
--------------------------------+-------------------------------

Comment (by westonruter):

 @gaurangsondagar Thank you, but I suggest focusing your efforts on testing
 patches that actually have functionality. Testing reports for coding
 standards and docs updates aren't particularly helpful.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65119#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 06:32:50 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 06:32:50 -0000
Subject: [wp-trac] [WordPress Trac] #65119: Docs: Correct the
 grammer/spelling in api.js documentation
In-Reply-To: <062.f5e5b79d8716fc3c1d2728e09f8667ce@wordpress.org>
References: <062.f5e5b79d8716fc3c1d2728e09f8667ce@wordpress.org>
Message-ID: <077.5e95bb1ad33c338dd73af1d04d43cc2e@wordpress.org>

#65119: Docs: Correct the grammer/spelling in api.js documentation
--------------------------------+-------------------------------
 Reporter:  baikare.sandeep007  |       Owner:  (none)
     Type:  enhancement         |      Status:  new
 Priority:  normal              |   Milestone:  7.1
Component:  REST API            |     Version:  trunk
 Severity:  normal              |  Resolution:
 Keywords:  has-patch           |     Focuses:  javascript, docs
--------------------------------+-------------------------------
Changes (by sabernhardt):

 * Attachment "65119.diff" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65119>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 07:07:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 07:07:03 -0000
Subject: [wp-trac] [WordPress Trac] #65119: Docs: Correct the
 grammar/spelling in api.js documentation (was: Docs: Correct the
 grammer/spelling in api.js documentation)
In-Reply-To: <062.f5e5b79d8716fc3c1d2728e09f8667ce@wordpress.org>
References: <062.f5e5b79d8716fc3c1d2728e09f8667ce@wordpress.org>
Message-ID: <077.6bc0b78dab177dcfe7ae0216701f3e67@wordpress.org>

#65119: Docs: Correct the grammar/spelling in api.js documentation
--------------------------------+-------------------------------
 Reporter:  baikare.sandeep007  |       Owner:  (none)
     Type:  enhancement         |      Status:  new
 Priority:  normal              |   Milestone:  7.1
Component:  REST API            |     Version:  4.7
 Severity:  normal              |  Resolution:
 Keywords:  has-patch           |     Focuses:  javascript, docs
--------------------------------+-------------------------------
Changes (by sabernhardt):

 * version:  trunk => 4.7


Old description:

> During a routine review of `src/js/_enqueues/wp/api.js`, I identified
> several grammatical errors and spelling inconsistencies within the inline
> comments. These issues, while minor, can hinder readability and
> comprehension for developers working with or learning from this code.
>
> '''Changes Made: '''
>
> This patch improves the inline documentation by:
>
> * Correcting spelling mistakes throughout the file's comment blocks
> * Fixing grammatical errors to enhance sentence clarity and flow
> * Maintaining the original technical meaning and intent of all comments
> * Preserving consistent terminology and code comment formatting standards
>
> '''Impact:'''
>

> These changes are purely documentation-focused and have no impact on:
> * Code execution or functionality
> * API behavior or public interfaces
> * Performance or backward compatibility
>
> ''' Testing:'''
>
> No functional testing is required as these changes only affect inline
> comments. The patch has been verified to contain only whitespace and text
> modifications within comment blocks.

New description:

 During a routine review of `src/js/_enqueues/wp/api.js`, I identified
 several grammatical errors and spelling inconsistencies within the inline
 comments. These issues, while minor, can hinder readability and
 comprehension for developers working with or learning from this code.

 '''Changes Made: '''

 This patch improves the inline documentation by:

 * Correcting spelling mistakes throughout the file's comment blocks
 * Fixing grammatical errors to enhance sentence clarity and flow
 * Maintaining the original technical meaning and intent of all comments
 * Preserving consistent terminology and code comment formatting standards

 '''Impact:'''

 These changes are purely documentation-focused and have no impact on:
 * Code execution or functionality
 * API behavior or public interfaces
 * Performance or backward compatibility

 ''' Testing:'''

 No functional testing is required as these changes only affect inline
 comments. The patch has been verified to contain only whitespace and text
 modifications within comment blocks.

--

Comment:

 The three sentences edited in `api.js-doc-enhancement.patch` were all
 included in `api.js` when [38832] introduced the script file.

 - Capitalizing ID is good, but I would capitalize it in another line too.
 - URL, MySQL, and Safari were also lowercase.
 - The word "thru" is used in two lines.

 Special notes about 65119.diff:
 1. `// Attach parent post ID to the collection.` \\
    The script sets 'parent_post' (not 'post_parent'), and I think a space
 fits the documentation instead of the underscore.
 2. `// Go through the parsable date fields. If our model contains any of
 them, it gets the TimeStampedMixin.` \\
    The patch splits this into two sentences.
 3. `// Fail silently, to avoid errors in Safari private mode.` \\
    Failing silently does not //fix// errors.
 4. 65119.diff corrects the typos for "nonce", "route" and "it is" (or
 "it's"). I noticed later that these were reported—and edited—in #65112.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65119#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 07:08:08 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 07:08:08 -0000
Subject: [wp-trac] [WordPress Trac] #47988: Unexpected behaviour when
 draft post has the same page_name as published post
In-Reply-To: <053.d40ce64c8ee1a4458ce7a90ddb09f7aa@wordpress.org>
References: <053.d40ce64c8ee1a4458ce7a90ddb09f7aa@wordpress.org>
Message-ID: <068.5c976a09e02431237871ba9932ad784b@wordpress.org>

#47988: Unexpected behaviour when draft post has the same page_name as published
post
-------------------------------------------------+-------------------------
 Reporter:  ajfleming                            |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Posts, Post Types                    |     Version:  2.8
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-test-info has-    |     Focuses:
  patch has-unit-tests needs-testing             |
-------------------------------------------------+-------------------------

Comment (by coviedo):

 I was able to reproduce the issue described in this ticket.

 In my local environment, I created a published post and a draft post
 sharing the same slug. Since WordPress does not allow duplicate slugs by
 default, I manually modified the slug in the database to match both posts.

 When accessing the URL while logged in, the draft post was displayed
 instead of the published one. In contrast, when accessing the same URL as
 a non-authenticated user, a 404 error was returned.

 This confirms the inconsistent behavior mentioned in the report.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47988#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 07:08:36 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 07:08:36 -0000
Subject: [wp-trac] [WordPress Trac] #65123: Having a malformed post type
 query in $_GET or $_POST yields a critical error
Message-ID: <055.29dc7cdfbf1c0409285d3c1ace563536@wordpress.org>

#65123: Having a malformed post type query in $_GET or $_POST yields a critical
error
--------------------------+-----------------------------
 Reporter:  hheuzebrutc   |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Permalinks    |    Version:  6.9.4
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 Steps to reproduce:
 - Go to a fresh install's homepage
 - Add ?attachment[foo]=bar to the url
 - press enter

 With the "attachment" post type, only the front page will crash, other
 pages will yield a 404. However, doing this with any custom post types the
 site might have can crash any page (as long as the post type is public).

 What's especially annoying for me is it also works with $_POST. If I make
 a form with an input name like public_post_type[sub_array], the site
 crashes upon submission and my form is never processed.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65123>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 08:19:35 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 08:19:35 -0000
Subject: [wp-trac] [WordPress Trac] #65124: Please include additional data
 validation in class-IXR-server.php
Message-ID: <057.4b26f520c07119a980e9344a815d2305@wordpress.org>

#65124: Please include additional data validation in class-IXR-server.php
-------------------------------+-----------------------------
 Reporter:  eeeeeeeeeeeee      |      Owner:  (none)
     Type:  defect (bug)       |     Status:  new
 Priority:  normal             |  Milestone:  Awaiting Review
Component:  General            |    Version:
 Severity:  normal             |   Keywords:
  Focuses:  php-compatibility  |
-------------------------------+-----------------------------
 Line 95 of /wp-includes/IXR/class-IXR-server.php is causing a fatal error,
 because malicious traffic is posting non-countable $args.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65124>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 10:58:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 10:58:07 -0000
Subject: [wp-trac] [WordPress Trac] #65125: On tablet screens,
 the .wrap container uses uneven margins (2px left, 20px right),
 causing cramped and unbalanced content. Using 20px on both sides would
 improve spacing, alignment, and readability.
Message-ID: <057.5f28efb3c8334a382b3675cb463622a4@wordpress.org>

#65125: On tablet screens, the .wrap container uses uneven margins (2px left, 20px
right), causing cramped and unbalanced content. Using 20px on both sides
would improve spacing, alignment, and readability.
-------------------------------------------------+-------------------------
 Reporter:  deeppatel8950                        |      Owner:  (none)
     Type:  defect (bug)                         |     Status:  new
 Priority:  normal                               |  Milestone:  Awaiting
                                                 |  Review
Component:  Administration                       |    Version:  6.9.4
 Severity:  normal                               |   Keywords:
  Focuses:  ui, accessibility, css,              |
  administration                                 |
-------------------------------------------------+-------------------------
 Using the same 20px margin on both left and right sides would provide
 balanced alignment, improve readability, and create a cleaner responsive
 layout on tablet devices.

 The issue is more noticeable on tablet devices where screen width is
 limited and proper spacing is important for usability. Admin pages
 containing headings, forms, labels, tables, and buttons can appear cramped
 due to the reduced left-side margin.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65125>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 10:58:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 10:58:44 -0000
Subject: [wp-trac] [WordPress Trac] #65125: On tablet screens,
 the .wrap container uses uneven margins (2px left, 20px right),
 causing cramped and unbalanced content. Using 20px on both sides would
 improve spacing, alignment, and readability.
In-Reply-To: <057.5f28efb3c8334a382b3675cb463622a4@wordpress.org>
References: <057.5f28efb3c8334a382b3675cb463622a4@wordpress.org>
Message-ID: <072.1da21a04dc958577ad5679ed4fed0737@wordpress.org>

#65125: On tablet screens, the .wrap container uses uneven margins (2px left, 20px
right), causing cramped and unbalanced content. Using 20px on both sides
would improve spacing, alignment, and readability.
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  (none)
  deeppatel8950          |
     Type:  defect       |      Status:  new
  (bug)                  |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:               |     Version:  6.9.4
  Administration         |
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:  ui, accessibility, css,
                         |  administration
-------------------------+-------------------------------------------------
Changes (by deeppatel8950):

 * Attachment "Administration-2.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65125>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 10:59:15 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 10:59:15 -0000
Subject: [wp-trac] [WordPress Trac] #65125: On tablet screens,
 the .wrap container uses uneven margins (2px left, 20px right),
 causing cramped and unbalanced content. Using 20px on both sides would
 improve spacing, alignment, and readability.
In-Reply-To: <057.5f28efb3c8334a382b3675cb463622a4@wordpress.org>
References: <057.5f28efb3c8334a382b3675cb463622a4@wordpress.org>
Message-ID: <072.669bd1abc63726b3643834b94f5abaf0@wordpress.org>

#65125: On tablet screens, the .wrap container uses uneven margins (2px left, 20px
right), causing cramped and unbalanced content. Using 20px on both sides
would improve spacing, alignment, and readability.
-------------------------+-------------------------------------------------
 Reporter:               |       Owner:  (none)
  deeppatel8950          |
     Type:  defect       |      Status:  new
  (bug)                  |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:               |     Version:  6.9.4
  Administration         |
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:  ui, accessibility, css,
                         |  administration
-------------------------+-------------------------------------------------
Changes (by deeppatel8950):

 * Attachment "Administration-1.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65125>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 11:02:41 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 11:02:41 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.b7bd558661313b5ddf28ec2e49ff1747@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
---------------------------------------+-----------------------
 Reporter:  shatrumyatra               |       Owner:  audrasjb
     Type:  defect (bug)               |      Status:  accepted
 Priority:  normal                     |   Milestone:  7.0
Component:  Administration             |     Version:  trunk
 Severity:  normal                     |  Resolution:
 Keywords:  has-screenshots has-patch  |     Focuses:  ui
---------------------------------------+-----------------------

Comment (by darshitrajyaguru97):

 == Test Report ==

 This report validates that the proposed patch successfully addresses the
 reported issue. ✅

 === Patch Tested ===
 https://github.com/WordPress/wordpress-develop/pull/11626

 === Environment ===
 * WordPress: 7.1-alpha-20260423.153912
 * OS: Windows
 * Browser: Chrome
 * Theme: Twenty Twenty-Five
 * PHP: 8.2.29
 * Plugins: None

 === Steps to Test ===
 1. Set up a clean WordPress installation with the above environment.
 2. Reproduce the issue on the unpatched version.
 3. Apply the patch from the PR.
 4. Re-test the same scenario.

 === Actual Results ===
 * The issue is no longer reproducible after applying the patch.
 * No warnings, errors, or regressions observed.

 === Expected Results ===
 * The patch should resolve the issue without introducing new errors. ✅

 === Conclusion ===
 The patch works as expected and successfully resolves the issue. ✅

 === Supplemental Artifacts ===
 * Attached screenshots
 **Before:** https://prnt.sc/0hvbMcbMPCEM
 **After:** https://prnt.sc/JDCVZe_NRqvB

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 11:36:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 11:36:18 -0000
Subject: [wp-trac] [WordPress Trac] #63033: The padding on the right and
 left of the WordPress admin bar (#wpadminbar) is not the same.
In-Reply-To: <057.c93e977110e454b238d592295e290654@wordpress.org>
References: <057.c93e977110e454b238d592295e290654@wordpress.org>
Message-ID: <072.49d869b83a78d9c55da034a1a05d6aa0@wordpress.org>

#63033: The padding on the right and left of the WordPress admin bar (#wpadminbar)
is not the same.
-------------------------------------------------+-------------------------
 Reporter:  deeppatel8950                        |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Administration                       |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  needs-design-feedback has-patch      |     Focuses:  ui, css
  2nd-opinion                                    |
-------------------------------------------------+-------------------------
Changes (by deeppatel8950):

 * keywords:  needs-design-feedback has-patch => needs-design-feedback has-
     patch 2nd-opinion


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/63033#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 12:13:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 12:13:03 -0000
Subject: [wp-trac] [WordPress Trac] #65108: Twenty Sixteen: barely
 visible bold text in 'blockquote'
In-Reply-To: <056.b4f29e9067554142b8542b27cd2c3419@wordpress.org>
References: <056.b4f29e9067554142b8542b27cd2c3419@wordpress.org>
Message-ID: <071.4df3a47cc33988a52eb77e8187ac070f@wordpress.org>

#65108: Twenty Sixteen: barely visible bold text in 'blockquote'
-------------------------------------------------+-------------------------
 Reporter:  gaelbonithon                         |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Bundled Theme                        |     Version:  4.4
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-test-info has-         |     Focuses:  css
  screenshots                                    |
-------------------------------------------------+-------------------------

Comment (by darshitrajyaguru97):

 == Test Report ==

 === Description ===
 This report validates whether the indicated patch works as expected.

 === Patch Tested ===
 https://github.com/WordPress/wordpress-develop/pull/11623

 === Environment ===
 * WordPress: 7.0-RC2-62242
 * PHP: 8.3.30
 * Server: nginx
 * Database: mysqli
 * Browser: Chrome
 * OS: Windows
 * Theme: Twenty Sixteen
 * MU Plugins: None activated
 * Plugins:
   * Test Reports 1.2.1
   * WordPress Beta Tester 4.0.0

 === Steps to Reproduce ===
 1. Install and set up WordPress with the above environment.
 2. Attempt to reproduce the reported issue on the unpatched version.
 3. Apply the patch from the PR.
 4. Re-test the same scenario.

 === Actual Results ===
 * ✅ Issue resolved with patch.
 * No unexpected errors or regressions observed.

 === Expected Results ===
 * The issue should be resolved after applying the patch. ✅

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65108#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 12:50:38 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 12:50:38 -0000
Subject: [wp-trac] [WordPress Trac] #65094: AI: Prompt construction
 fails with fatal error when wp_ai_client_default_request_timeout filter
 returns negative number
In-Reply-To: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
References: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
Message-ID: <070.4a0a18a31056b8dc272c33e7b4261455@wordpress.org>

#65094: AI: Prompt construction fails with fatal error when
wp_ai_client_default_request_timeout filter returns negative number
-------------------------------------------------+-------------------------
 Reporter:  westonruter                          |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  AI                                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests commit      |     Focuses:
  dev-feedback                                   |
-------------------------------------------------+-------------------------

Comment (by dhrumilk):

 I reproduced the issue in a local WordPress development setup and
 documented the findings.

 **Steps performed:**

 * Set up a fresh local WordPress core environment
 * Attempted to apply the `wp_ai_client_default_request_timeout` filter
 * Initially added the filter in `wp-config.php`, which resulted in a fatal
 error since `add_filter()` is not available at that early stage of
 execution
 * Relocated the filter to `functions.php`, where WordPress is fully loaded
 and hooks are accessible

 **Result:**

 * No fatal errors occurred when the filter was implemented in the correct
 location
 * WordPress functioned as expected without any issues

 **Conclusion:**
 The behavior is correct and expected. The filter works properly when used
 within the appropriate context (i.e., after WordPress has fully
 initialized), and the earlier error was due to placing it too early in the
 load sequence.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65094#comment:28>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 12:56:38 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 12:56:38 -0000
Subject: [wp-trac] [WordPress Trac] #65116: Feature request: On This Day
 dashboard widget
In-Reply-To: <053.013a3a9617eae6ca499f347ee9f9a63c@wordpress.org>
References: <053.013a3a9617eae6ca499f347ee9f9a63c@wordpress.org>
Message-ID: <068.ba4cc0d6f99ea4e9253c66e7842eef72@wordpress.org>

#65116: Feature request: On This Day dashboard widget
-------------------------+-------------------------------------------------
 Reporter:  alshakero    |       Owner:  (none)
     Type:  feature      |      Status:  new
  request                |
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Widgets      |     Version:  trunk
 Severity:  minor        |  Resolution:
 Keywords:  has-patch    |     Focuses:  ui, administration, sustainability
-------------------------+-------------------------------------------------

Comment (by alshakero):

 Replying to [comment:7 eclev91]:

 Hi there!

 > So not ''that'' much excitement.

 Well it is picked up now 😄 FWIW, I genuinely think it is cool and useful
 and I proposed it without knowing about the past discussions about it.

 > But this widget creates an additional query on the dashboard and loads
 yet another stylesheet, which is far from the experience I want on the
 dashboard if I'm making it my own.

 I hear you and I really want wp-admin to be fast. That's why the widget
 does one query per day unless you modify your posts. It's heavily cached;
 even the HTML generation is cached for the duration of the day. When it's
 cached, it doesn't do any DB connections at all.

 The CSS is 1.9 KB gzipped and is cached across days. I don't think it will
 move the needle at all.

 > It's relevant to one subset of users and contributing to a noise problem
 for the rest.

 For those who don't want it, I think the only noise is the checkbox in the
 screen options. Is that a lot? This plugin will also only register for
 those who can edit posts.

 >
 > I'm far from well plugged into core development, and the code is already
 written, but can this at least be something you opt into rather than have
 to disable on sites where it's irrelevant?

 > Can this at least be something you opt into rather than have to disable
 on sites where it's irrelevant?

 I'm totally open to both options. I did try to make it opt-in and it seems
 the architecture doesn't support that by default and I would have to do
 some trickery, still open it it nonetheless.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65116#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 13:58:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 13:58:07 -0000
Subject: [wp-trac] [WordPress Trac] #65123: Having a malformed post type
 query in $_GET or $_POST yields a critical error
In-Reply-To: <055.29dc7cdfbf1c0409285d3c1ace563536@wordpress.org>
References: <055.29dc7cdfbf1c0409285d3c1ace563536@wordpress.org>
Message-ID: <070.da77b57bc71e66ac1192078badd4cd8f@wordpress.org>

#65123: Having a malformed post type query in $_GET or $_POST yields a critical
error
--------------------------+------------------------------
 Reporter:  hheuzebrutc   |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Permalinks    |     Version:  6.9.4
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by mindctrl):

 Hi @hheuzebrutc, welcome to Trac and thanks for the report!

 I am able to reproduce the fatal error.


 I'm not sure how common this is, but `attachment` is supposed to be a
 string, as it's used to fetch an attachment by slug/post_name. It looks
 like type validation is handled mostly in `WP_Query::parse_query()`, but
 `attachment` isn't checked properly. We probably need an `is_scalar`
 check, like what is done with `subpost` (which, if provided, gets assigned
 to `attachment`).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65123#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 14:44:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 14:44:26 -0000
Subject: [wp-trac] [WordPress Trac] #65125: On tablet screens,
 the .wrap container uses uneven margins (2px left, 20px right),
 causing cramped and unbalanced content. Using 20px on both sides would
 improve spacing, alignment, and readability.
In-Reply-To: <057.5f28efb3c8334a382b3675cb463622a4@wordpress.org>
References: <057.5f28efb3c8334a382b3675cb463622a4@wordpress.org>
Message-ID: <072.03deb3f28f578faf86f55351d4d3fee2@wordpress.org>

#65125: On tablet screens, the .wrap container uses uneven margins (2px left, 20px
right), causing cramped and unbalanced content. Using 20px on both sides
would improve spacing, alignment, and readability.
----------------------------+--------------------------------------
 Reporter:  deeppatel8950   |       Owner:  (none)
     Type:  defect (bug)    |      Status:  closed
 Priority:  normal          |   Milestone:
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:  duplicate
 Keywords:                  |     Focuses:  ui, css, administration
----------------------------+--------------------------------------
Changes (by sabernhardt):

 * status:  new => closed
 * focuses:  ui, accessibility, css, administration => ui, css,
              administration
 * resolution:   => duplicate
 * version:  6.9.4 =>
 * milestone:  Awaiting Review =>


Comment:

 This was reported on #63306, which is closed as a duplicate of #63305.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65125#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 16:07:35 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 16:07:35 -0000
Subject: [wp-trac] [WordPress Trac] #65126: Implement a lock mechanism for
 Site Editor templates (wp_template,
 wp_template_part) similar to the existing Heartbeat-based post locking
 system.
Message-ID: <052.7f4deca557fb914d62342cfe933d78c1@wordpress.org>

#65126: Implement a lock mechanism for Site Editor templates (wp_template,
wp_template_part) similar to the existing Heartbeat-based post locking
system.
-------------------------------------------------+-------------------------
 Reporter:  sparshie                             |      Owner:  (none)
     Type:  enhancement                          |     Status:  new
 Priority:  normal                               |  Milestone:  Awaiting
                                                 |  Review
Component:  Editor                               |    Version:  6.9.4
 Severity:  normal                               |   Keywords:  needs-patch
  Focuses:  administration, template,            |
  performance                                    |
-------------------------------------------------+-------------------------
 Currently, the WordPress Heartbeat API provides a reliable post locking
 mechanism for standard post types (e.g., post, page, article) where a
 postID is available. This prevents concurrent editing and ensures content
 integrity.

 However, this mechanism does not function correctly for Site Editor
 entities such as wp_template and wp_template_part. Since these are managed
 through the Site Editor and do not follow the traditional post editing
 flow, the default locking behavior fails, leading to potential conflicts
 when multiple users edit the same template simultaneously.

 This creates a gap in collaborative editing workflows, especially for
 teams working extensively with Full Site Editing (FSE).

 A custom solution has been identified to address this limitation by
 introducing a lock mechanism tailored for Site Editor entities. The
 proposed approach ensures:

 Proper identification and locking of wp_template and wp_template_part
 entities
 Prevention of simultaneous edits across multiple users
 Consistent behavior aligned with the existing Heartbeat-based locking
 system

 Further implementation details and validation of the solution can be
 provided.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65126>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 16:08:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 16:08:16 -0000
Subject: [wp-trac] [WordPress Trac] #65126: Implement a lock mechanism
 for Site Editor templates (wp_template,
 wp_template_part) similar to the existing Heartbeat-based post locking
 system.
In-Reply-To: <052.7f4deca557fb914d62342cfe933d78c1@wordpress.org>
References: <052.7f4deca557fb914d62342cfe933d78c1@wordpress.org>
Message-ID: <067.d6ebe9ad7e0b19476742d337194aeb1c@wordpress.org>

#65126: Implement a lock mechanism for Site Editor templates (wp_template,
wp_template_part) similar to the existing Heartbeat-based post locking
system.
-------------------------+-------------------------------------------------
 Reporter:  sparshie     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Editor       |     Version:  6.9.4
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |     Focuses:  administration, template,
                         |  performance
-------------------------+-------------------------------------------------
Changes (by sparshie):

 * Attachment "TEMPLATE_LOCK_MANAGER_DOCS.md" added.

 Docs for the Lock Mechanism

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65126>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 17:25:52 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 17:25:52 -0000
Subject: [wp-trac] [WordPress Trac] #65119: Docs: Correct the
 grammar/spelling in api.js documentation
In-Reply-To: <062.f5e5b79d8716fc3c1d2728e09f8667ce@wordpress.org>
References: <062.f5e5b79d8716fc3c1d2728e09f8667ce@wordpress.org>
Message-ID: <077.a479ce330f24fbdce4cb2f36c2d80764@wordpress.org>

#65119: Docs: Correct the grammar/spelling in api.js documentation
--------------------------------+-------------------------------
 Reporter:  baikare.sandeep007  |       Owner:  westonruter
     Type:  enhancement         |      Status:  reviewing
 Priority:  normal              |   Milestone:  7.1
Component:  REST API            |     Version:  4.7
 Severity:  normal              |  Resolution:
 Keywords:  has-patch           |     Focuses:  javascript, docs
--------------------------------+-------------------------------
Changes (by westonruter):

 * owner:  (none) => westonruter
 * status:  new => reviewing


Comment:

 Self-assigning to move this forward to commit when `trunk` is unfrozen.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65119#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 17:47:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 17:47:05 -0000
Subject: [wp-trac] [WordPress Trac] #65098: get_site_icon_url() returns
 empty string even when fallback is defined,
 breaking wp-embed-site-icon in the_embed_site_title()
In-Reply-To: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
References: <054.abf1d28e7f04d3d8706dcf89620df3d2@wordpress.org>
Message-ID: <069.3a6fef35734bc3285217fc6e4e73d20c@wordpress.org>

#65098: get_site_icon_url() returns empty string even when fallback is defined,
breaking wp-embed-site-icon in the_embed_site_title()
-------------------------------------------------+-------------------------
 Reporter:  pontocinza                           |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  reviewing
 Priority:  normal                               |   Milestone:  7.1
Component:  Embeds                               |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-test-info needs-unit-  |     Focuses:
  tests commit                                   |
-------------------------------------------------+-------------------------
Changes (by westonruter):

 * keywords:  has-patch has-test-info needs-unit-tests => has-patch has-
     test-info needs-unit-tests commit
 * owner:  (none) => westonruter
 * status:  new => reviewing


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65098#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 17:50:47 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 17:50:47 -0000
Subject: [wp-trac] [WordPress Trac] #64714: Inconsistent vertical
 spacing between the headings and their content in the dashboard widgets:
 Site Health Status, Quick Edit, Activity, and WordPress Events and News.
In-Reply-To: <054.fbb91d366b30a9f82b5b0247d068de4a@wordpress.org>
References: <054.fbb91d366b30a9f82b5b0247d068de4a@wordpress.org>
Message-ID: <069.41d54baa4192a9c23d6b8bbf64129238@wordpress.org>

#64714: Inconsistent vertical spacing between the headings and their content in the
dashboard widgets: Site Health Status, Quick Edit, Activity, and WordPress
Events and News.
--------------------------+------------------------------
 Reporter:  adnanhyder    |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Widgets       |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  css
--------------------------+------------------------------
Changes (by abhishekfdd):

 * Attachment "64714.diff" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64714>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 17:52:00 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 17:52:00 -0000
Subject: [wp-trac] [WordPress Trac] #64714: Inconsistent vertical
 spacing between the headings and their content in the dashboard widgets:
 Site Health Status, Quick Edit, Activity, and WordPress Events and News.
In-Reply-To: <054.fbb91d366b30a9f82b5b0247d068de4a@wordpress.org>
References: <054.fbb91d366b30a9f82b5b0247d068de4a@wordpress.org>
Message-ID: <069.613851d472c776dfef3a3640dc8add7c@wordpress.org>

#64714: Inconsistent vertical spacing between the headings and their content in the
dashboard widgets: Site Health Status, Quick Edit, Activity, and WordPress
Events and News.
-------------------------------------+------------------------------
 Reporter:  adnanhyder               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Widgets                  |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  css
-------------------------------------+------------------------------
Changes (by abhishekfdd):

 * keywords:   => has-patch needs-testing


Comment:

 Proposed patch normalizes the heading-to-content gap across Site Health
 Status, At a Glance, Activity, WordPress Events and News, and Quick Draft
 to a uniform 12px, using the existing .hndle padding token. Tested that
 the patch applies cleanly to current trunk.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64714#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 18:09:40 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 18:09:40 -0000
Subject: [wp-trac] [WordPress Trac] #65068: PHP warnings when a
 registered oEmbed provider is malformed
In-Reply-To: <054.c667f79a728d296763b2f67622b647d2@wordpress.org>
References: <054.c667f79a728d296763b2f67622b647d2@wordpress.org>
Message-ID: <069.068745435cb415952d8eeaba28b3af91@wordpress.org>

#65068: PHP warnings when a registered oEmbed provider is malformed
-------------------------------------------------+-------------------------
 Reporter:  bradshawtm                           |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  reviewing
 Priority:  normal                               |   Milestone:  7.1
Component:  Embeds                               |     Version:  4.0
 Severity:  minor                                |  Resolution:
 Keywords:  has-patch has-unit-tests changes-    |     Focuses:
  requested commit                               |
-------------------------------------------------+-------------------------
Changes (by westonruter):

 * keywords:  has-patch has-unit-tests changes-requested => has-patch has-
     unit-tests changes-requested commit
 * owner:  (none) => westonruter
 * version:   => 4.0
 * status:  new => reviewing


Comment:

 Queueing up for commit once `trunk` is unfrozen.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65068#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 18:10:47 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 18:10:47 -0000
Subject: [wp-trac] [WordPress Trac] #64991: New param
 "allow_multiple_terms" in `register_taxonomy` for single term restriction
In-Reply-To: <050.16baf956a8973d154e1f320b42812e72@wordpress.org>
References: <050.16baf956a8973d154e1f320b42812e72@wordpress.org>
Message-ID: <065.0e4d8cfcbfe550f27fd31252683d75be@wordpress.org>

#64991: New param "allow_multiple_terms" in `register_taxonomy` for single term
restriction
-----------------------------+------------------------------
 Reporter:  bastho           |       Owner:  (none)
     Type:  feature request  |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Taxonomy         |     Version:
 Severity:  normal           |  Resolution:
 Keywords:                   |     Focuses:  ui
-----------------------------+------------------------------
Changes (by abhishekfdd):

 * Attachment "64991.diff" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64991>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 18:12:04 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 18:12:04 -0000
Subject: [wp-trac] [WordPress Trac] #64991: New param
 "allow_multiple_terms" in `register_taxonomy` for single term restriction
In-Reply-To: <050.16baf956a8973d154e1f320b42812e72@wordpress.org>
References: <050.16baf956a8973d154e1f320b42812e72@wordpress.org>
Message-ID: <065.ace6b1432ef02f6dffd868f307492506@wordpress.org>

#64991: New param "allow_multiple_terms" in `register_taxonomy` for single term
restriction
-------------------------------------------------+-------------------------
 Reporter:  bastho                               |       Owner:  (none)
     Type:  feature request                      |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Taxonomy                             |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests needs-      |     Focuses:  ui
  testing                                        |
-------------------------------------------------+-------------------------
Changes (by abhishekfdd):

 * keywords:   => has-patch has-unit-tests needs-testing


Comment:

 Thanks for opening this, @bastho. Attaching a first patch (64991.diff)
 that covers the feature end-to-end, along with the reasoning behind a few
 decisions that came up while writing it. Happy to iterate on any of them.
 What the patch changes

 WP_Taxonomy — adds an $allow_multiple_terms property (default true) and
 accepts it in set_props(). When false and no custom meta_box_cb is
 supplied, the default meta box callback is switched to a new
 post_single_term_meta_box() and the sanitize callback to a new
 taxonomy_meta_box_sanitize_cb_single_term().
 register_taxonomy() docblock — documents the new argument and a new @since
 7.1.0 tag for the arg introduction.
 post_single_term_meta_box() (new, in wp-admin/includes/meta-boxes.php) —
 renders radio buttons for hierarchical taxonomies and a <select> (via
 wp_dropdown_categories()) for non-hierarchical ones. A "None" option is
 offered when no default_term is configured.
 taxonomy_meta_box_sanitize_cb_single_term() (new, in wp-
 admin/includes/post.php) — normalizes the submitted array to at most one
 term ID.
 wp_set_object_terms() — enforces the cap at the shared assignment path, so
 REST, WP-CLI, and any direct caller honor the constraint — not just the
 admin UI. When $append is passed for a single-term taxonomy, the append is
 downgraded to a replace to avoid quietly stacking terms.
 Quick Edit (WP_Posts_List_Table) — for hierarchical taxonomies, renders a
 radio list instead of wp_terms_checklist(); for non-hierarchical, renders
 a dropdown instead of the tags <textarea>. Bulk Edit already excludes per-
 taxonomy controls for non-category taxonomies, so the server-side cap in
 (5) is what protects bulk operations.

 Design decisions worth flagging
 Argument name: allow_multiple_terms. I kept the name you proposed.
 single_value reads cleanly as a property but pairs awkwardly with a
 default of true ('single_value' => true to mean "allow many" is a double
 negative). A meta_box_style enum was tempting for extensibility, but it
 conflates UI shape with cardinality — the server-side cap has to happen
 regardless of which UI is used, so a boolean flag that governs both
 defaults matches the semantics better.
 Default is true. Every existing register_taxonomy() call is unaffected.
 Enforcement lives in wp_set_object_terms(), not just the metabox
 sanitizer. This was the biggest design call. The alternative — only
 capping in the sanitize callback — would leave REST (POST /wp/v2/posts
 with a tax array of many IDs), WP-CLI, and any plugin calling
 wp_set_post_terms() free to bypass the constraint. Centralizing it at the
 assignment path matches how default_term and other taxonomy-level
 semantics are enforced, and keeps the contract consistent for API
 consumers.
 "Last value wins" when multiple terms are submitted. This matches post-
 format semantics and means that if a form somehow submits two radio values
 (e.g. a custom client), the most recent one wins. Open to a stricter
 WP_Error instead if that's preferred.
 Custom meta_box_cb precedence. If a caller supplies their own meta_box_cb,
 we don't override it even when allow_multiple_terms => false — the custom
 UI is assumed to know what it's doing. The server-side cap still applies,
 so a misbehaving custom UI can't save multiple terms.
 Gutenberg / block editor. Out of scope for Core Trac — belongs in the
 gutenberg repo. The useEntityProp-backed PostTaxonomies component would
 need to read allow_multiple_terms (ideally exposed via the taxonomies REST
 schema) and render a <RadioControl> / <SelectControl> in place of the
 flat/hierarchical token field. Worth a companion ticket once the Core API
 shape is settled here. Also not yet exposed in the REST taxonomies
 endpoint — I didn't add it to
 WP_REST_Taxonomies_Controller::get_item_schema() in this patch because the
 API surface felt worth agreeing on first, but it's a natural follow-up.
 Bulk Edit. The existing UI already suppresses per-taxonomy controls in
 bulk mode (! $bulk), and the cap in wp_set_object_terms() means bulk-
 updating many posts to a single term still works correctly. No per-row
 bulk UI change needed, though an explicit bulk-edit dropdown for single-
 term taxonomies could be a follow-up enhancement.
 Open questions

 Argument naming — fine as-is, or would committers prefer an alternative?
 REST schema exposure — add allow_multiple_terms to the taxonomies endpoint
 schema in this patch or a follow-up?
 default_term interaction — when allow_multiple_terms => false and a
 default_term is set, I'm suppressing the "None" option so the UI always
 reflects a valid selection. Happy to make that configurable if there's a
 use case for allowing explicit clearing.
 Unit tests — haven't added them in this first pass; will follow up in a
 separate patch once the API shape is agreed, focused on
 wp_set_object_terms() cap behavior (including the $append downgrade), the
 new sanitize callback, and register_taxonomy() defaults wiring.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64991#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 18:34:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 18:34:57 -0000
Subject: [wp-trac] [WordPress Trac] #65126: Implement a lock mechanism
 for Site Editor templates (wp_template,
 wp_template_part) similar to the existing Heartbeat-based post locking
 system.
In-Reply-To: <052.7f4deca557fb914d62342cfe933d78c1@wordpress.org>
References: <052.7f4deca557fb914d62342cfe933d78c1@wordpress.org>
Message-ID: <067.ddd8b468c23b388a9d515478590afec9@wordpress.org>

#65126: Implement a lock mechanism for Site Editor templates (wp_template,
wp_template_part) similar to the existing Heartbeat-based post locking
system.
-------------------------+---------------------------------------
 Reporter:  sparshie     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  7.1
Component:  Editor       |     Version:  5.9
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |     Focuses:  administration, template
-------------------------+---------------------------------------
Changes (by westonruter):

 * focuses:  administration, template, performance => administration,
              template
 * version:  6.9.4 => 5.9
 * milestone:  Awaiting Review => 7.1


Comment:

 And I presume this post locking should not be enforced in favor of real-
 time collaboration (RTC) when that is enabled. See
 https://github.com/WordPress/gutenberg/issues/76985

 Since I also assume this will be part of the next major release, I'm
 milestoning accordingly.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65126#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 18:53:24 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 18:53:24 -0000
Subject: [wp-trac] [WordPress Trac] #64225: Test tool and unit test
 improvements for 7.0
In-Reply-To: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
References: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
Message-ID: <066.a9193dfd24419e9af03841d7f8a727ac@wordpress.org>

#64225: Test tool and unit test improvements for 7.0
--------------------------------------+---------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  task (blessed)            |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by SergeyBiryukov):

 In [changeset:"62260" 62260]:
 {{{
 #!CommitTicketReference repository="" revision="62260"
 Tests: Correct `@covers` tags for `WP_Error` tests.

 Includes removing redundant tags to help clarify the purpose of each
 individual test.

 Follow-up to [42255], [50339].

 See #64225.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64225#comment:73>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 20:00:00 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 20:00:00 -0000
Subject: [wp-trac] [WordPress Trac] #65126: Implement a lock mechanism
 for Site Editor templates (wp_template,
 wp_template_part) similar to the existing Heartbeat-based post locking
 system.
In-Reply-To: <052.7f4deca557fb914d62342cfe933d78c1@wordpress.org>
References: <052.7f4deca557fb914d62342cfe933d78c1@wordpress.org>
Message-ID: <067.819f7ffe9c54de3f77ff72cd86388cba@wordpress.org>

#65126: Implement a lock mechanism for Site Editor templates (wp_template,
wp_template_part) similar to the existing Heartbeat-based post locking
system.
-------------------------+---------------------------------------
 Reporter:  sparshie     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  7.1
Component:  Editor       |     Version:  5.9
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |     Focuses:  administration, template
-------------------------+---------------------------------------

Comment (by sparshie):

 Replying to [comment:1 westonruter]:
 > And I presume this post locking should not be enforced in favor of real-
 time collaboration (RTC) when that is enabled. See
 https://github.com/WordPress/gutenberg/issues/76985
 >
 > Since I also assume this will be part of the next major release, I'm
 milestoning accordingly.

 Thanks for the feedback and for updating the milestone.

 I wanted to provide more context on why this change is needed.

 On our implementation, we transitioned certain editorial workflows from a
 custom post type to `wp_template` (Site Editor). In this setup, the
 existing post locking mechanism does not apply, as it relies on
 traditional `postId`-based locking. As a result, multiple users can edit
 the same template simultaneously without any warning, which has led to
 unintended overwrites and loss of changes.

 To address this, I implemented a lock mechanism similar to the existing
 Heartbeat-based post locking, adapted for entity-based editing used by the
 Site Editor. This ensures:

 * Users are notified when another user is editing the same template
 * A soft-lock experience with options to either take over or exit
 * Prevention of silent overwrites in non-collaborative scenarios

 Regarding real-time collaboration (RTC):
 I agree that locking should not be enforced when RTC is enabled. The
 implementation is designed to be conditional, so locking is disabled when
 collaborative editing is active and only applied as a fallback where RTC
 is not available.

 I’ve attached a patch to this ticket with the proposed approach and would
 appreciate feedback on:

 * Whether this aligns with the intended direction for entity-based editing
 * The approach for detecting and deferring to RTC
 * UX expectations (soft lock vs strict enforcement)

 This solution is currently being validated in production on our end.

 Thanks again for the guidance.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65126#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Fri Apr 24 20:00:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Fri, 24 Apr 2026 20:00:49 -0000
Subject: [wp-trac] [WordPress Trac] #65126: Implement a lock mechanism
 for Site Editor templates (wp_template,
 wp_template_part) similar to the existing Heartbeat-based post locking
 system.
In-Reply-To: <052.7f4deca557fb914d62342cfe933d78c1@wordpress.org>
References: <052.7f4deca557fb914d62342cfe933d78c1@wordpress.org>
Message-ID: <067.666aa512dd53ff0a76fd13e449a1574c@wordpress.org>

#65126: Implement a lock mechanism for Site Editor templates (wp_template,
wp_template_part) similar to the existing Heartbeat-based post locking
system.
-------------------------+---------------------------------------
 Reporter:  sparshie     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  7.1
Component:  Editor       |     Version:  5.9
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |     Focuses:  administration, template
-------------------------+---------------------------------------
Changes (by sparshie):

 * Attachment "editor-lock-no-heartbeat.php" added.

 Adds a lock mechanism for wp_template and wp_template_part in the Site
 Editor, where traditional post locking does not apply. Includes
 conditional disabling when real-time collaboration (RTC) is active.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65126>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 25 04:37:54 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 25 Apr 2026 04:37:54 -0000
Subject: [wp-trac] [WordPress Trac] #65127: Introduce
 'wp_ai_client_cache_group' filter to allow customization of the object
 cache group
Message-ID: <062.fd2f76d3647fc4e3f86be6ca86ff5d9c@wordpress.org>

#65127: Introduce 'wp_ai_client_cache_group' filter to allow customization of the
object cache group
--------------------------------+-----------------------------
 Reporter:  baikare.sandeep007  |      Owner:  (none)
     Type:  enhancement         |     Status:  new
 Priority:  normal              |  Milestone:  Awaiting Review
Component:  AI                  |    Version:  trunk
 Severity:  normal              |   Keywords:  has-patch
  Focuses:  administration      |
--------------------------------+-----------------------------
 = Introduce 'wp_ai_client_cache_group' filter to allow customization of
 the object cache group =

 == Description

 This patch introduces a new filter, `wp_ai_client_cache_group`, to the
 `WP_AI_Client_Cache` class. This allows developers and integrators to
 change the object-cache group under which the AI client stores its keys.

 Previously, the cache group was hardcoded as the class constant
 `self::CACHE_GROUP` (`'wp_ai_client'`). This patch replaces all direct
 references to the constant with a call to a new private method
 `get_cache_group()`, which applies the new filter.

 == Purpose

 The `wp_ai_client_cache_group` filter provides integrators with greater
 control over cache placement and invalidation. Key benefits include:

 === 1. Avoid Key Collisions
 Plugins or themes can choose a distinct group to avoid clashing with other
 code that might use similar cache keys on the same site.

 === 2. Environment-Specific Caches
 On multisite or hosting platforms that namespace caches per-site,
 integrators can map AI client keys into a per-site or per-environment
 group (e.g., include the blog ID or environment name) to prevent cross-
 site data leakage.

 === 3. Backend Constraints / Compatibility
 Some persistent object cache implementations treat groups differently (or
 do not support group flushing). Allowing the group to be replaced lets
 integrators adapt—for example, to use a group the host supports or to fall
 back to transient-based storage.

 === 4. Testing and Isolation
 Unit and integration tests can switch the cache group to an ephemeral one
 (or a mock group) so test runs do not interfere with real cached data.

 === 5. Targeted Invalidation / Performance
 Integrators who want to implement custom invalidation strategies—such as
 namespacing by model/version or sharding keys—can change the group to a
 name that their backend can efficiently flush or monitor.

 == Implementation Notes

 * A new private method `get_cache_group(): string` is introduced. This
 method applies the `wp_ai_client_cache_group` filter to the default
 `self::CACHE_GROUP` constant.
 * All cache operations (`wp_cache_get`, `wp_cache_set`, `wp_cache_delete`,
 etc.) now use `$this->get_cache_group()` instead of the hardcoded
 constant.
 * The filter is expected to return a **string** cache group name. For
 predictable behavior, the returned value is explicitly cast to a string.
 * Two new unit tests are added to `Tests_AI_Client_Cache`:
     1. `test_cache_group_filter_is_respected`: Verifies the filter changes
 the group used for cache operations.
     2. `test_cache_group_filter_returns_non_string`: Confirms non-string
 filter return values are properly cast to strings.

 == Example Usage

 === Basic: Change to a custom group
 {{{#!php
 <?php
 add_filter( 'wp_ai_client_cache_group', function( $group ) {
     return 'my_plugin_ai_cache';
 } );
 }}}
 This stores all AI client cache items under the `'my_plugin_ai_cache'`
 group.

 === Multisite: Per-site isolation
 {{{#!php
 <?php
 add_filter( 'wp_ai_client_cache_group', function( $group ) {
     return $group . '_site_' . get_current_blog_id();
 } );
 }}}
 This appends the current site ID to the cache group, preventing cross-site
 cache sharing.

 === Testing: Use an ephemeral group
 {{{#!php
 <?php
 add_filter( 'wp_ai_client_cache_group', function( $group ) {
     return 'tests_' . uniqid();
 } );
 }}}
 This generates a unique, temporary cache group for the duration of a test
 run.

 == Backward Compatibility

 * **Fully backward compatible** – When the filter is not used, the cache
 group defaults to the original `'wp_ai_client'` constant, preserving
 existing behavior.
 * **No functional changes** to existing code that relies on the hardcoded
 cache group.

 == Impact

 * **Performance:** Negligible overhead – the filter only executes on cache
 operations and the method is lightweight.
 * **Security:** None – this is an additive change that provides more
 control without introducing new attack surfaces.

 == Testing

 The attached patch includes comprehensive unit test coverage:
 1. Verifies that applying the filter changes the cache group used for
 `set()` and `get()` operations.
 2. Ensures that non-string return values (e.g., integers) are gracefully
 cast to strings.

 Manual testing has confirmed that existing cache functionality remains
 unchanged when the filter is not applied.

 == Props

 Props @baikare.sandeep007.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65127>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 25 04:38:58 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 25 Apr 2026 04:38:58 -0000
Subject: [wp-trac] [WordPress Trac] #65127: Introduce
 'wp_ai_client_cache_group' filter to allow customization of the object
 cache group
In-Reply-To: <062.fd2f76d3647fc4e3f86be6ca86ff5d9c@wordpress.org>
References: <062.fd2f76d3647fc4e3f86be6ca86ff5d9c@wordpress.org>
Message-ID: <077.f3284afd2815341134d2945e5634b694@wordpress.org>

#65127: Introduce 'wp_ai_client_cache_group' filter to allow customization of the
object cache group
--------------------------------+------------------------------
 Reporter:  baikare.sandeep007  |       Owner:  (none)
     Type:  enhancement         |      Status:  new
 Priority:  normal              |   Milestone:  Awaiting Review
Component:  AI                  |     Version:  trunk
 Severity:  normal              |  Resolution:
 Keywords:  has-patch           |     Focuses:  administration
--------------------------------+------------------------------
Changes (by baikare.sandeep007):

 * Attachment "65127.diff" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65127>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 25 12:28:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 25 Apr 2026 12:28:07 -0000
Subject: [wp-trac] [WordPress Trac] #65127: Introduce
 'wp_ai_client_cache_group' filter to allow customization of the object
 cache group
In-Reply-To: <062.fd2f76d3647fc4e3f86be6ca86ff5d9c@wordpress.org>
References: <062.fd2f76d3647fc4e3f86be6ca86ff5d9c@wordpress.org>
Message-ID: <077.871580b1daad3ed1a63e2ec00ddb2caa@wordpress.org>

#65127: Introduce 'wp_ai_client_cache_group' filter to allow customization of the
object cache group
--------------------------------+------------------------------
 Reporter:  baikare.sandeep007  |       Owner:  (none)
     Type:  enhancement         |      Status:  new
 Priority:  normal              |   Milestone:  Awaiting Review
Component:  AI                  |     Version:  trunk
 Severity:  normal              |  Resolution:
 Keywords:  has-patch           |     Focuses:  administration
--------------------------------+------------------------------
Changes (by baikare.sandeep007):

 * Attachment "65127.patch" added.

 Updated patch file with ticket umber in tests

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65127>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 25 13:42:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 25 Apr 2026 13:42:06 -0000
Subject: [wp-trac] [WordPress Trac] #65128: Warning on the post page.
Message-ID: <056.36dc6c1c8bcecf8876faea078501974f@wordpress.org>

#65128: Warning on the post page.
----------------------------+-----------------------------
 Reporter:  gautammkgarg    |      Owner:  (none)
     Type:  defect (bug)    |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Administration  |    Version:  trunk
 Severity:  normal          |   Keywords:
  Focuses:                  |
----------------------------+-----------------------------
 getting below warning on the `/wp-admin/post.php` page.


 {{{
 Warning: Attempt to read property "post_type" on null in `public\wp-
 includes\admin-bar.php` on line 816
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65128>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 25 17:07:10 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 25 Apr 2026 17:07:10 -0000
Subject: [wp-trac] [WordPress Trac] #38300: Got a PHP warning:
 class-wp-xmlrpc-server.php L596: array_unshift() ...
In-Reply-To: <049.b4d7d169ee52443daf3554b6645baf4d@wordpress.org>
References: <049.b4d7d169ee52443daf3554b6645baf4d@wordpress.org>
Message-ID: <064.fc41c0527e7a82d5898542687d7c8ec3@wordpress.org>

#38300: Got a PHP warning: class-wp-xmlrpc-server.php L596: array_unshift() ...
--------------------------+------------------------------
 Reporter:  kmvan         |       Owner:  (none)
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  XML-RPC       |     Version:  4.6.1
 Severity:  normal        |  Resolution:
 Keywords:  close         |     Focuses:
--------------------------+------------------------------
Changes (by sabernhardt):

 * keywords:   => close


Comment:

 I think [46148] fixed the function if `$args` is not an array (by editing
 `wp_xmlrpc_server::minimum_args()`).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/38300#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 25 18:44:36 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 25 Apr 2026 18:44:36 -0000
Subject: [wp-trac] [WordPress Trac] #64225: Test tool and unit test
 improvements for 7.0
In-Reply-To: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
References: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
Message-ID: <066.cda410b4f6732c2c0152aed867572c2b@wordpress.org>

#64225: Test tool and unit test improvements for 7.0
--------------------------------------+---------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  task (blessed)            |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by SergeyBiryukov):

 In [changeset:"62261" 62261]:
 {{{
 #!CommitTicketReference repository="" revision="62261"
 Tests: Add missing `@covers` tag for `register_block_type_from_metadata()`
 tests.

 Follow-up to [59132].

 Props sagardeshmukh.
 See #64225.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64225#comment:74>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 25 18:45:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 25 Apr 2026 18:45:39 -0000
Subject: [wp-trac] [WordPress Trac] #65127: Introduce
 'wp_ai_client_cache_group' filter to allow customization of the object
 cache group
In-Reply-To: <062.fd2f76d3647fc4e3f86be6ca86ff5d9c@wordpress.org>
References: <062.fd2f76d3647fc4e3f86be6ca86ff5d9c@wordpress.org>
Message-ID: <077.9aa13640617286453f4fb24d0012e694@wordpress.org>

#65127: Introduce 'wp_ai_client_cache_group' filter to allow customization of the
object cache group
--------------------------------------+------------------------------
 Reporter:  baikare.sandeep007        |       Owner:  (none)
     Type:  enhancement               |      Status:  new
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  AI                        |     Version:  trunk
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  administration
--------------------------------------+------------------------------
Changes (by baikare.sandeep007):

 * Attachment "65127-full.patch" added.

 Updated filter hook comment as per WPCS

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65127>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 25 19:27:00 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 25 Apr 2026 19:27:00 -0000
Subject: [wp-trac] [WordPress Trac] #65129: Improve maintainability of
 DOCTYPE quirks mode detection in `WP_HTML_Doctype_Info` class
Message-ID: <062.4222a143c45d82e1e02b722fdcd453bf@wordpress.org>

#65129: Improve maintainability of DOCTYPE quirks mode detection in
`WP_HTML_Doctype_Info` class
-------------------------------------------+-------------------------------
 Reporter:  baikare.sandeep007             |      Owner:  (none)
     Type:  enhancement                    |     Status:  new
 Priority:  normal                         |  Milestone:  Awaiting Review
Component:  HTML API                       |    Version:  trunk
 Severity:  normal                         |   Keywords:  has-patch needs-
  Focuses:  performance, coding-standards  |  testing
-------------------------------------------+-------------------------------
 = Improve maintainability of DOCTYPE quirks mode detection in
 `WP_HTML_Doctype_Info` class =

 == Description

 This patch refactors the DOCTYPE quirks mode detection logic in
 `WP_HTML_Doctype_Info` by extracting the large list of legacy public
 identifier prefixes into a separate array and using a `foreach` loop
 instead of a monolithic `if` condition with multiple `str_starts_with()`
 calls chained with `||` operators.

 == Current Behavior

 The `determine_quirks_mode_from_public_identifier()` method currently
 contains a single `if` statement with over **70** conditions chained
 together using logical OR operators:

 {{{#!php
 <?php
 if (
     str_starts_with( $public_identifier, '+//silmaril//dtd html pro v0r11
 19970101//' ) ||
     str_starts_with( $public_identifier, '-//as//dtd html 3.0 aswedit +
 extensions//' ) ||
     // ... 70+ more conditions
 ) {
     $this->indicated_compatibility_mode = 'quirks';
     return;
 }
 }}}


 == Issues with Current Approach

 * Poor maintainability – Adding, removing, or modifying prefixes requires
 editing a long, sprawling conditional statement
 * Reduced readability – The logic flow is obscured by the sheer number of
 conditions
 * Difficult to test – Individual prefixes cannot be easily referenced or
 validated in isolation
 * Code duplication – The same pattern of str_starts_with() calls is
 repeated for each prefix

 == Proposed Changes

 This patch replaces the large conditional block with:

 * A single source of truth – All legacy quirks mode prefixes are now
 stored in a dedicated array $quirks_prefixes
 * Clean iteration – A foreach loop checks each prefix using
 str_starts_with()
 * Early return – When a match is found, the compatibility mode is set and
 the method exits immediately

 == Impact
 * No functional changes – The exact same set of public identifiers
 triggers quirks mode
 * Backward compatible – Behavior remains identical for all DOCTYPE
 declarations
 * Performance neutral – The loop iterates through the same number of
 checks as before
 * Improves code quality – Makes the HTML API more maintainable for future
 contributors

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65129>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 25 19:28:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 25 Apr 2026 19:28:03 -0000
Subject: [wp-trac] [WordPress Trac] #65129: Improve maintainability of
 DOCTYPE quirks mode detection in `WP_HTML_Doctype_Info` class
In-Reply-To: <062.4222a143c45d82e1e02b722fdcd453bf@wordpress.org>
References: <062.4222a143c45d82e1e02b722fdcd453bf@wordpress.org>
Message-ID: <077.3bf82dfe837a2ee42aae12d49f32f800@wordpress.org>

#65129: Improve maintainability of DOCTYPE quirks mode detection in
`WP_HTML_Doctype_Info` class
------------------------------+--------------------------------------------
 Reporter:                    |       Owner:  (none)
  baikare.sandeep007          |
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  Awaiting Review
Component:  HTML API          |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch needs-  |     Focuses:  performance, coding-standards
  testing                     |
------------------------------+--------------------------------------------
Changes (by baikare.sandeep007):

 * Attachment "65129.patch" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65129>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 25 19:49:02 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 25 Apr 2026 19:49:02 -0000
Subject: [wp-trac] [WordPress Trac] #65129: Improve maintainability of
 DOCTYPE quirks mode detection in `WP_HTML_Doctype_Info` class
In-Reply-To: <062.4222a143c45d82e1e02b722fdcd453bf@wordpress.org>
References: <062.4222a143c45d82e1e02b722fdcd453bf@wordpress.org>
Message-ID: <077.e073f362554873d59150a09c71a2ed0c@wordpress.org>

#65129: Improve maintainability of DOCTYPE quirks mode detection in
`WP_HTML_Doctype_Info` class
------------------------------+--------------------------------------------
 Reporter:                    |       Owner:  (none)
  baikare.sandeep007          |
     Type:  enhancement       |      Status:  new
 Priority:  normal            |   Milestone:  Awaiting Review
Component:  HTML API          |     Version:  6.7
 Severity:  normal            |  Resolution:
 Keywords:  has-patch needs-  |     Focuses:  performance, coding-standards
  testing                     |
------------------------------+--------------------------------------------
Changes (by sabernhardt):

 * version:  trunk => 6.7


Old description:

> = Improve maintainability of DOCTYPE quirks mode detection in
> `WP_HTML_Doctype_Info` class =
>
> == Description
>
> This patch refactors the DOCTYPE quirks mode detection logic in
> `WP_HTML_Doctype_Info` by extracting the large list of legacy public
> identifier prefixes into a separate array and using a `foreach` loop
> instead of a monolithic `if` condition with multiple `str_starts_with()`
> calls chained with `||` operators.
>
> == Current Behavior
>
> The `determine_quirks_mode_from_public_identifier()` method currently
> contains a single `if` statement with over **70** conditions chained
> together using logical OR operators:
>
> {{{#!php
> <?php
> if (
>     str_starts_with( $public_identifier, '+//silmaril//dtd html pro v0r11
> 19970101//' ) ||
>     str_starts_with( $public_identifier, '-//as//dtd html 3.0 aswedit +
> extensions//' ) ||
>     // ... 70+ more conditions
> ) {
>     $this->indicated_compatibility_mode = 'quirks';
>     return;
> }
> }}}
>

> == Issues with Current Approach
>
> * Poor maintainability – Adding, removing, or modifying prefixes requires
> editing a long, sprawling conditional statement
> * Reduced readability – The logic flow is obscured by the sheer number of
> conditions
> * Difficult to test – Individual prefixes cannot be easily referenced or
> validated in isolation
> * Code duplication – The same pattern of str_starts_with() calls is
> repeated for each prefix
>
> == Proposed Changes
>
> This patch replaces the large conditional block with:
>
> * A single source of truth – All legacy quirks mode prefixes are now
> stored in a dedicated array $quirks_prefixes
> * Clean iteration – A foreach loop checks each prefix using
> str_starts_with()
> * Early return – When a match is found, the compatibility mode is set and
> the method exits immediately
>
> == Impact
> * No functional changes – The exact same set of public identifiers
> triggers quirks mode
> * Backward compatible – Behavior remains identical for all DOCTYPE
> declarations
> * Performance neutral – The loop iterates through the same number of
> checks as before
> * Improves code quality – Makes the HTML API more maintainable for future
> contributors

New description:

 This patch refactors the `DOCTYPE` quirks mode detection logic in
 `WP_HTML_Doctype_Info` by extracting the large list of legacy public
 identifier prefixes into a separate array and using a `foreach` loop
 instead of a monolithic `if` condition with multiple `str_starts_with()`
 calls chained with `||` operators.

 ==== Current Behavior

 The `determine_quirks_mode_from_public_identifier()` method currently
 contains a single `if` statement with over **70** conditions chained
 together using logical OR operators:

 {{{#!php
 <?php
 if (
     str_starts_with( $public_identifier, '+//silmaril//dtd html pro v0r11
 19970101//' ) ||
     str_starts_with( $public_identifier, '-//as//dtd html 3.0 aswedit +
 extensions//' ) ||
     // ... 70+ more conditions
 ) {
     $this->indicated_compatibility_mode = 'quirks';
     return;
 }
 }}}

 ==== Issues with Current Approach

 * Poor maintainability – Adding, removing, or modifying prefixes requires
 editing a long, sprawling conditional statement
 * Reduced readability – The logic flow is obscured by the sheer number of
 conditions
 * Difficult to test – Individual prefixes cannot be easily referenced or
 validated in isolation
 * Code duplication – The same pattern of `str_starts_with()` calls is
 repeated for each prefix

 ==== Proposed Changes

 This patch replaces the large conditional block with:

 * A single source of truth – All legacy quirks mode prefixes are now
 stored in a dedicated array `$quirks_prefixes`
 * Clean iteration – A `foreach` loop checks each prefix using
 `str_starts_with()`
 * Early return – When a match is found, the compatibility mode is set and
 the method exits immediately

 ==== Impact
 * No functional changes – The exact same set of public identifiers
 triggers quirks mode
 * Backward compatible – Behavior remains identical for all `DOCTYPE`
 declarations
 * Performance neutral – The loop iterates through the same number of
 checks as before
 * Improves code quality – Makes the HTML API more maintainable for future
 contributors

--

Comment:

 ([58925] added the `WP_HTML_Doctype_Info` class.)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65129#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sat Apr 25 22:40:45 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sat, 25 Apr 2026 22:40:45 -0000
Subject: [wp-trac] [WordPress Trac] #65128: Warning on the post page.
In-Reply-To: <056.36dc6c1c8bcecf8876faea078501974f@wordpress.org>
References: <056.36dc6c1c8bcecf8876faea078501974f@wordpress.org>
Message-ID: <071.bef7b36b0df679d7a032b986831000b0@wordpress.org>

#65128: Warning on the post page.
-----------------------------------------+------------------------------
 Reporter:  gautammkgarg                 |       Owner:  (none)
     Type:  defect (bug)                 |      Status:  new
 Priority:  normal                       |   Milestone:  Awaiting Review
Component:  Administration               |     Version:  trunk
 Severity:  normal                       |  Resolution:
 Keywords:  has-patch reporter-feedback  |     Focuses:
-----------------------------------------+------------------------------
Changes (by sabernhardt):

 * keywords:  has-patch => has-patch reporter-feedback


Comment:

 How did you access `/wp-admin/post.php`?
 1. If you followed a link, where was it?
 2. Does the URL have a query string after `post.php`?
 3. What can you accomplish on the admin page if `get_post()` returns
 `null`?
 4. Do you have any plugins active, and what is the theme?

 I tried changing a post link to a nonexistent ID (`wp-
 admin/post.php?post=55555&action=edit`), and I got an error:
 > "You attempted to edit an item that does not exist. Perhaps it was
 deleted?"

 When I tried accessing `/wp-admin/post.php` without any query string, it
 redirected me to `/wp-admin/edit.php`.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65128#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 26 03:57:42 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 26 Apr 2026 03:57:42 -0000
Subject: [wp-trac] [WordPress Trac] #65129: Improve maintainability of
 DOCTYPE quirks mode detection in `WP_HTML_Doctype_Info` class
In-Reply-To: <062.4222a143c45d82e1e02b722fdcd453bf@wordpress.org>
References: <062.4222a143c45d82e1e02b722fdcd453bf@wordpress.org>
Message-ID: <077.f590e5d8ae0137d3d14d3487760f73f4@wordpress.org>

#65129: Improve maintainability of DOCTYPE quirks mode detection in
`WP_HTML_Doctype_Info` class
-------------------------------------+-------------------------------
 Reporter:  baikare.sandeep007       |       Owner:  (none)
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  HTML API                 |     Version:  6.7
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  coding-standards
-------------------------------------+-------------------------------
Changes (by westonruter):

 * focuses:  performance, coding-standards => coding-standards


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65129#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 26 05:53:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 26 Apr 2026 05:53:56 -0000
Subject: [wp-trac] [WordPress Trac] #65130: Plugin search (term) in wp-admin
 lacks normalization, causing fragile keyword matching
Message-ID: <051.fabd8d9a751389bbebe628cdcacd4b6b@wordpress.org>

#65130: Plugin search (term) in wp-admin lacks normalization, causing fragile
keyword matching
----------------------------+-----------------------------
 Reporter:  369work         |      Owner:  (none)
     Type:  enhancement     |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Administration  |    Version:  trunk
 Severity:  normal          |   Keywords:  needs-patch
  Focuses:                  |
----------------------------+-----------------------------
 == Problem ==

 The plugin search box in wp-admin (`Plugins > Add New`) produces
 unreliable results when searching by keyword (term). A user searching for
 "WP Multibyte Patch" gets very different results depending on minor
 variations in their query:

 | Query         | Result      |
 |---------------|-------------|
 | `multibyte`   | Found       |
 | `multi byte`  | Not found   |
 | `multi`       | Not found   |
 | `multi patch` | Not found   |

 The root cause is that the search term is passed to the WordPress.org
 Plugin API with no normalization whatsoever.

 == Root cause (confirmed in source) ==

 In `wp-admin/includes/class-wp-plugin-install-list-table.php`, the
 `prepare_items()` method handles the search tab as follows:

 {{{
 // Line 161-169
 $type = isset( $_REQUEST['type'] ) ? wp_unslash( $_REQUEST['type'] ) :
 'term';
 $term = isset( $_REQUEST['s'] )    ? wp_unslash( $_REQUEST['s'] )    : '';

 switch ( $type ) {
     case 'tag':
         $args['tag'] = sanitize_title_with_dashes( $term ); // sanitized
         break;
     case 'term':
         $args['search'] = $term; // ← NO processing at all
         break;
     case 'author':
         $args['author'] = $term; // no processing
         break;
 }
 }}}

 Note the inconsistency: the `tag` type applies
 `sanitize_title_with_dashes()`, which strips spaces and normalizes the
 string, while `term` (keyword search) receives NO processing. This
 asymmetry appears unintentional.

 The raw `$args` is then passed directly to `plugins_api( 'query_plugins',
 $args )`, which forwards the search string as-is to
 `https://api.wordpress.org/plugins/info/1.2/`.

 == Proposed fix ==

 The fix is a single line change in `class-wp-plugin-install-list-
 table.php`:

 {{{
 // Before (line 169):
 $args['search'] = $term;

 // After:
 $args['search'] = preg_replace( '/\s+/', '', $term );
 }}}

 This strips whitespace between words before sending the query to the API,
 so "multi byte" becomes "multibyte" — matching the plugin slug and name as
 indexed by WordPress.org.

 A more robust approach could also apply `sanitize_text_field()` for
 consistency with the `tag` type, and potentially send a secondary query
 with the original term to merge results.

 == Files affected ==

 * `wp-admin/includes/class-wp-plugin-install-list-table.php` — line 169
 (primary fix)
 * `wp-admin/includes/plugin-install.php` — `plugins_api()` (no change
 needed; normalization should happen before this call)

 == Note on server-side improvements ==

 Deeper fuzzy search improvements (stemming, partial matching, relevance
 ranking) would require changes on the Meta/Plugin Directory side
 (`api.wordpress.org`). This ticket focuses solely on the low-risk, one-
 line client-side normalization that can ship independently.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65130>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 26 06:15:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 26 Apr 2026 06:15:16 -0000
Subject: [wp-trac] [WordPress Trac] #65094: AI: Prompt construction
 fails with fatal error when wp_ai_client_default_request_timeout filter
 returns negative number
In-Reply-To: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
References: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
Message-ID: <070.365dbebecc1c6fa212810314600ef005@wordpress.org>

#65094: AI: Prompt construction fails with fatal error when
wp_ai_client_default_request_timeout filter returns negative number
-------------------------------------------------+-------------------------
 Reporter:  westonruter                          |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  AI                                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests commit      |     Focuses:
  dev-feedback                                   |
-------------------------------------------------+-------------------------

Comment (by priyankaadbrains):

 I tested the issue and confirmed that returning a negative value for the ⁠
 wp_ai_client_default_request_timeout ⁠ filter causes a fatal error during
 prompt construction.

 The patch properly handles invalid timeout values and prevents the crash.
 AI requests are now functioning as expected.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65094#comment:29>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 26 07:03:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 26 Apr 2026 07:03:18 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.cc17f67a4dc495a11a722c0207c4703c@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
------------------------------------+--------------------------------------
 Reporter:  piyushpatel123          |       Owner:  audrasjb
     Type:  defect (bug)            |      Status:  closed
 Priority:  normal                  |   Milestone:  7.0
Component:  Administration          |     Version:  trunk
 Severity:  normal                  |  Resolution:  fixed
 Keywords:  has-patch admin-reskin  |     Focuses:  ui, css, administration
------------------------------------+--------------------------------------
Changes (by audrasjb):

 * status:  accepted => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62262" 62262]:
 {{{
 #!CommitTicketReference repository="" revision="62262"
 Administration: Fix misaligned icon in user profile password field.

 This changeset corrects a misalignment issue affecting the show/hide
 button next to the password field.

 Props piyushpatel123, rajdiptank111, ankitkumarshah, andrewssanya,
 jdahir0789, gautammkgarg, gaurangsondagar, gaisma22, ugyensupport,
 abduremon, ankitmaru, darshitrajyaguru97, khushdoms, monzuralam.
 Fixes #65031.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031#comment:23>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 26 07:03:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 26 Apr 2026 07:03:31 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2364988=3A_Enhancement?=
 =?utf-8?q?=3A_Add_support_for_displaying_child_categories_in_Navigation_?=
 =?utf-8?q?=E2=80=9CCategory_Link=E2=80=9D_block_=28dropdown_support=29?=
In-Reply-To: <052.f84d64c777d845b9acf79e0e942f86ff@wordpress.org>
References: <052.f84d64c777d845b9acf79e0e942f86ff@wordpress.org>
Message-ID: <067.1be6e97f8ffd6d79a4a14e1f3f7fe7b7@wordpress.org>

#64988: Enhancement: Add support for displaying child categories in Navigation
“Category Link” block (dropdown support)
-------------------------+------------------------------
 Reporter:  wpsharif     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:  6.9.4
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+------------------------------

Comment (by priyanshuhaldar):

 Please check this PR https://github.com/WordPress/gutenberg/pull/77679 for
 the implementation. Let me know if this fulfils your enhancement request.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64988#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 26 07:03:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 26 Apr 2026 07:03:53 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.748fef6a4f2acb91184b3beded85e8ee@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
-------------------------------------+-------------------------------------
 Reporter:  piyushpatel123           |       Owner:  audrasjb
     Type:  defect (bug)             |      Status:  reopened
 Priority:  normal                   |   Milestone:  7.0
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  admin-reskin dev-        |     Focuses:  ui, css,
  feedback                           |  administration
-------------------------------------+-------------------------------------
Changes (by audrasjb):

 * keywords:  has-patch admin-reskin => admin-reskin dev-feedback
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Reopening for 7.0 backport.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031#comment:24>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 26 07:48:15 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 26 Apr 2026 07:48:15 -0000
Subject: [wp-trac] [WordPress Trac] #65128: Warning on the post page.
In-Reply-To: <056.36dc6c1c8bcecf8876faea078501974f@wordpress.org>
References: <056.36dc6c1c8bcecf8876faea078501974f@wordpress.org>
Message-ID: <071.daecb38b8347617d75bf06411e498215@wordpress.org>

#65128: Warning on the post page.
-----------------------------------------+------------------------------
 Reporter:  gautammkgarg                 |       Owner:  (none)
     Type:  defect (bug)                 |      Status:  new
 Priority:  normal                       |   Milestone:  Awaiting Review
Component:  Administration               |     Version:  trunk
 Severity:  normal                       |  Resolution:
 Keywords:  has-patch reporter-feedback  |     Focuses:
-----------------------------------------+------------------------------

Comment (by gautammkgarg):

 @sabernhardt and @mukeshpanchal27

 I got this warning while working with our Plugin "Knit Pay". I thought if
 this warning is getting triggered in Knit Pay, then it can get triggered
 in other plugins/themes also. That's why I planned to fix it.

 Here are the complete steps I followed, where I got this error.

 1. I installed [Knit Pay](https://wordpress.org/plugins/knit-pay/) plugin.
 2. Created new Configuration. **Knit Pay >> Configurations >> Add new
 Payment Gateway Configuration**.
 3. In Payment Provider, I chose "UPI QR".
 4. In "UPI VPA ID" field, write anything, like "abc".
 5. Publish the configuration.
 6. After page loads, scroll to the bottom of page, and in "Test" box,
 enter any amount, eg. 5 INR.
 7. Click on "Test" button.
 8. On this page, you will get the warning I mentioned.

 I just realized, that I am getting one more Deprecated code message

 {{{#!php
 <?php
 Deprecated: Function print_emoji_styles is deprecated since version 6.4.0!
 Use wp_enqueue_emoji_styles instead. in public\wp-includes\functions.php
 on line 6170
 }}}
 I am not sure if we should fix both these warning and deprecated message
 in same PR or keep 2 separate PR.

 ----
 **Environment I am using.**
 ----
 PHP: 8.1.29 - 8.5.1 (Getting warning on all the PHP versions)
 WordPress: 7.0-RC2
 Web server: nginx/1.26.1

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65128#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 26 10:05:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 26 Apr 2026 10:05:55 -0000
Subject: [wp-trac] [WordPress Trac] #64581: Allow serialized options
 read-only view
In-Reply-To: <058.f1d9275e6fa261c8f0ee15f97bd26266@wordpress.org>
References: <058.f1d9275e6fa261c8f0ee15f97bd26266@wordpress.org>
Message-ID: <073.d752d4f5501a867195b5365f8050d146@wordpress.org>

#64581: Allow serialized options read-only view
---------------------------------------+---------------------------------
 Reporter:  anatolinicolae             |       Owner:  (none)
     Type:  feature request            |      Status:  new
 Priority:  normal                     |   Milestone:  Awaiting Review
Component:  Options, Meta APIs         |     Version:  trunk
 Severity:  trivial                    |  Resolution:
 Keywords:  has-patch has-screenshots  |     Focuses:  ui, administration
---------------------------------------+---------------------------------
Changes (by anatolinicolae):

 * keywords:  has-patch => has-patch has-screenshots


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64581#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 26 11:31:24 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 26 Apr 2026 11:31:24 -0000
Subject: [wp-trac] [WordPress Trac] #65118: Docs: Correct
 WP_Network_Query params comments
In-Reply-To: <062.bc857a5e1fc74eb71c058f3d42270cc9@wordpress.org>
References: <062.bc857a5e1fc74eb71c058f3d42270cc9@wordpress.org>
Message-ID: <077.06baf431c773ed5a29c10757c1e3243e@wordpress.org>

#65118: Docs: Correct WP_Network_Query params comments
----------------------------+----------------------------------------------
 Reporter:                  |       Owner:  (none)
  baikare.sandeep007        |
     Type:  enhancement     |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Networks and    |     Version:  4.6
  Sites                     |
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:  docs, administration, multisite
----------------------------+----------------------------------------------
Changes (by baikare.sandeep007):

 * version:  trunk => 4.6


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65118#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 26 14:56:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 26 Apr 2026 14:56:17 -0000
Subject: [wp-trac] [WordPress Trac] #64363: add MarkDown feeds
In-Reply-To: <051.010476209417b3b671d37ad5ddfefea2@wordpress.org>
References: <051.010476209417b3b671d37ad5ddfefea2@wordpress.org>
Message-ID: <066.0a9fddd0ecf80b11ee4756f6c3d3e298@wordpress.org>

#64363: add MarkDown feeds
-------------------------+------------------------------
 Reporter:  pbearne      |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Feeds        |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:
-------------------------+------------------------------

Comment (by justlevine):

 I'm finally giving the `hmtl-to-md` and the w.org endpoints a review and
 seeing some basics missing.
 [https://github.com/dmsnell/html-to-md/issues/15| This one] felt
 particularly important to crosslink here.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64363#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 26 21:19:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 26 Apr 2026 21:19:06 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.1032cb7878ff71bede9ead072292512c@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
---------------------------------------+-----------------------
 Reporter:  shatrumyatra               |       Owner:  audrasjb
     Type:  defect (bug)               |      Status:  accepted
 Priority:  normal                     |   Milestone:  7.0
Component:  Administration             |     Version:  trunk
 Severity:  normal                     |  Resolution:
 Keywords:  has-screenshots has-patch  |     Focuses:  ui
---------------------------------------+-----------------------

Comment (by yusufmudagal):

 ## Test Report

 Patch tested:
 https://github.com/WordPress/wordpress-develop/pull/11626

 Environment:
 WordPress: trunk
 PHP: 8.x
 Browser: Chrome
 OS: macOS

 Steps tested:
 1. Reproduced the issue before applying the patch.
 2. Confirmed that the per-page input clipped larger values such as 1000.
 3. Applied the GitHub PR patch successfully using:
    npm run grunt patch:https://github.com/WordPress/wordpress-
 develop/pull/11626
 4. Verified the change in:
    src/wp-admin/includes/class-wp-screen.php
 5. Re-tested Screen Options on Posts, Pages, Users, Plugins, and Comments.
 6. Tested values: 99, 999, 1000, and 10000.

 Result:
 Before the patch, larger values were clipped inside the input field.
 After applying the patch, the full values are visible correctly.
 No UI issues observed.

 Conclusion:
 Patch works as expected.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 26 22:31:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 26 Apr 2026 22:31:28 -0000
Subject: [wp-trac] [WordPress Trac] #64982: library should be changed to
 media library in core or needs gettext
In-Reply-To: <052.6ebe4cf636d68ac01de1c591e6c35312@wordpress.org>
References: <052.6ebe4cf636d68ac01de1c591e6c35312@wordpress.org>
Message-ID: <067.fe3efe5521bc87eb19c1f39659b7ace3@wordpress.org>

#64982: library should be changed to media library in core or needs gettext
-------------------------------------------+-----------------------------
 Reporter:  timse201                       |       Owner:  SergeyBiryukov
     Type:  defect (bug)                   |      Status:  reopened
 Priority:  normal                         |   Milestone:  7.0
Component:  I18N                           |     Version:  trunk
 Severity:  normal                         |  Resolution:
 Keywords:  has-patch commit dev-reviewed  |     Focuses:
-------------------------------------------+-----------------------------
Changes (by peterwilsoncc):

 * keywords:  has-patch commit dev-feedback => has-patch commit dev-reviewed


Comment:

 Approved for merging to the 7.0 branch

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64982#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 26 22:49:38 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 26 Apr 2026 22:49:38 -0000
Subject: [wp-trac] [WordPress Trac] #65094: AI: Prompt construction
 fails with fatal error when wp_ai_client_default_request_timeout filter
 returns negative number
In-Reply-To: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
References: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
Message-ID: <070.c72a334fd6f273dfb637509ff38ba32f@wordpress.org>

#65094: AI: Prompt construction fails with fatal error when
wp_ai_client_default_request_timeout filter returns negative number
-------------------------------------------------+-------------------------
 Reporter:  westonruter                          |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  AI                                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests commit      |     Focuses:
  dev-feedback                                   |
-------------------------------------------------+-------------------------

Comment (by westonruter):

 Here's a quick way to test this.

 Add a this as a `try-wp-ai-client-negative-default-request-timeout.php`
 file to the root of a WP install:

 {{{#!php
 <?php

 add_filter(
         'wp_ai_client_default_request_timeout',
         static function () {
                 return -1;
         }
 );

 echo wp_ai_client_prompt( 'When is Christmas?' )->generate_text();

 }}}

 Then invoke with WP-CLI:

 {{{
 npm run env:cli -- eval-file try-wp-ai-client-negative-default-request-
 timeout.php
 }}}

 Before:

 > Fatal error: Uncaught
 WordPress\AiClient\Common\Exception\InvalidArgumentException: Request
 option "timeout" must be greater than or equal to 0. in /var/www/src/wp-
 includes/php-ai-client/src/Providers/Http/DTO/RequestOptions.php:201

 After:

 > Notice: Function `WP_AI_Client_Prompt_Builder::__construct` was called
 '''incorrectly'''. The `wp_ai_client_default_request_timeout` filter must
 return a non-negative number. Please see [https://developer.wordpress.org
 /advanced-administration/debug/debug-wordpress/ Debugging in WordPress]
 for more information. (This message was added in version 7.0.0.) in
 /var/www/src/wp-includes/functions.php on line 6173
 > Christmas is celebrated on **December 25th** each year.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65094#comment:30>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 26 23:04:40 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 26 Apr 2026 23:04:40 -0000
Subject: [wp-trac] [WordPress Trac] #65063: Classic Editor: slug editing
 field is too large
In-Reply-To: <053.e99112fe2c6dd2520e9b55ab9e698a2b@wordpress.org>
References: <053.e99112fe2c6dd2520e9b55ab9e698a2b@wordpress.org>
Message-ID: <068.d14e2a78cc651304415f6b1e0e337a4b@wordpress.org>

#65063: Classic Editor: slug editing field is too large
-------------------------------------------+------------------------
 Reporter:  wildworks                      |       Owner:  joedolson
     Type:  defect (bug)                   |      Status:  closed
 Priority:  normal                         |   Milestone:  7.0
Component:  Administration                 |     Version:  trunk
 Severity:  normal                         |  Resolution:  fixed
 Keywords:  admin-reskin has-patch commit  |     Focuses:
-------------------------------------------+------------------------
Changes (by peterwilsoncc):

 * status:  accepted => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62263" 62263]:
 {{{
 #!CommitTicketReference repository="" revision="62263"
 Administration: Resize classic editor slug field for new theme.

 Reduces the size and improves the alignment of the post slug field
 following the re-design of form elements as part of the new admin theme.

 Props wildworks, sabernhardt, audrasjb, dhruvang21, shailu25, joedolson,
 khushdoms, tusharaddweb.
 Fixes #65063.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65063#comment:19>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 26 23:05:47 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 26 Apr 2026 23:05:47 -0000
Subject: [wp-trac] [WordPress Trac] #65063: Classic Editor: slug editing
 field is too large
In-Reply-To: <053.e99112fe2c6dd2520e9b55ab9e698a2b@wordpress.org>
References: <053.e99112fe2c6dd2520e9b55ab9e698a2b@wordpress.org>
Message-ID: <068.aa03a875cb209f68049a4c9f64822cba@wordpress.org>

#65063: Classic Editor: slug editing field is too large
-------------------------------------------------+-------------------------
 Reporter:  wildworks                            |       Owner:  joedolson
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch commit dev-   |     Focuses:
  feedback fixed-major                           |
-------------------------------------------------+-------------------------
Changes (by peterwilsoncc):

 * keywords:  admin-reskin has-patch commit => admin-reskin has-patch commit
     dev-feedback fixed-major
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Reopening for merge to the 7.0 branch pending another committers sign off.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65063#comment:20>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 26 23:20:02 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 26 Apr 2026 23:20:02 -0000
Subject: [wp-trac] [WordPress Trac] #65094: AI: Prompt construction
 fails with fatal error when wp_ai_client_default_request_timeout filter
 returns negative number
In-Reply-To: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
References: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
Message-ID: <070.393eeb01f5cbee4978f24cf0c6c2c637@wordpress.org>

#65094: AI: Prompt construction fails with fatal error when
wp_ai_client_default_request_timeout filter returns negative number
-------------------------------------------------+-------------------------
 Reporter:  westonruter                          |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  AI                                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests commit      |     Focuses:
  dev-reviewed                                   |
-------------------------------------------------+-------------------------
Changes (by peterwilsoncc):

 * keywords:  has-patch has-unit-tests commit dev-feedback => has-patch has-
     unit-tests commit dev-reviewed


Comment:

 Approved for merge to the 7.0 branch.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65094#comment:31>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 26 23:24:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 26 Apr 2026 23:24:17 -0000
Subject: [wp-trac] [WordPress Trac] #65006: `uglify:moment` task fails
 due to missing source file
In-Reply-To: <051.84601c4d043c890905c0ce65fe4c33fe@wordpress.org>
References: <051.84601c4d043c890905c0ce65fe4c33fe@wordpress.org>
Message-ID: <066.023350fe59b3581cc08e674415fb938b@wordpress.org>

#65006: `uglify:moment` task fails due to missing source file
------------------------------------+----------------------------
 Reporter:  desrosj                 |       Owner:  peterwilsoncc
     Type:  defect (bug)            |      Status:  reopened
 Priority:  normal                  |   Milestone:  7.0
Component:  Build/Test Tools        |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:
------------------------------------+----------------------------
Changes (by peterwilsoncc):

 * keywords:  has-patch => has-patch dev-feedback


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65006#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 26 23:49:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 26 Apr 2026 23:49:22 -0000
Subject: [wp-trac] [WordPress Trac] #64225: Test tool and unit test
 improvements for 7.0
In-Reply-To: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
References: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
Message-ID: <066.d22e234b701856a1f9ec74fb508ac1b3@wordpress.org>

#64225: Test tool and unit test improvements for 7.0
--------------------------------------+---------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  task (blessed)            |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by SergeyBiryukov):

 In [changeset:"62264" 62264]:
 {{{
 #!CommitTicketReference repository="" revision="62264"
 Tests: Move `@covers` tags to the class-level DocBlock in some block-
 related tests.

 See #64225.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64225#comment:75>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 26 23:54:27 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 26 Apr 2026 23:54:27 -0000
Subject: [wp-trac] [WordPress Trac] #64324: Tests: Reduce usage of
 assertEquals for 7.0
In-Reply-To: <058.0c6ac395ada262d47afdbd8f4b684483@wordpress.org>
References: <058.0c6ac395ada262d47afdbd8f4b684483@wordpress.org>
Message-ID: <073.92de143275401a9b1ceb116990204c60@wordpress.org>

#64324: Tests: Reduce usage of assertEquals for 7.0
--------------------------------------+-------------------------------
 Reporter:  SergeyBiryukov            |       Owner:  (none)
     Type:  task (blessed)            |      Status:  closed
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests  |     Focuses:  coding-standards
--------------------------------------+-------------------------------

Comment (by peterwilsoncc):

 I'm going to merge r62248 to the 7.0 branch as it's required to avoid
 conflicts in the backport for r62255.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64324#comment:17>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 26 23:57:42 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 26 Apr 2026 23:57:42 -0000
Subject: [wp-trac] [WordPress Trac] #64324: Tests: Reduce usage of
 assertEquals for 7.0
In-Reply-To: <058.0c6ac395ada262d47afdbd8f4b684483@wordpress.org>
References: <058.0c6ac395ada262d47afdbd8f4b684483@wordpress.org>
Message-ID: <073.7e08bd3b8d8efa26aae1befacc8a37a6@wordpress.org>

#64324: Tests: Reduce usage of assertEquals for 7.0
--------------------------------------+-------------------------------
 Reporter:  SergeyBiryukov            |       Owner:  (none)
     Type:  task (blessed)            |      Status:  closed
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests  |     Focuses:  coding-standards
--------------------------------------+-------------------------------

Comment (by peterwilsoncc):

 In [changeset:"62265" 62265]:
 {{{
 #!CommitTicketReference repository="" revision="62265"
 Tests: Use `assertSame()` in `WP_AI_Client_Prompt_Builder` tests.

 This ensures that not only the return values match the expected results,
 but also that their type is the same.

 Going forward, stricter type checking by using `assertSame()` should
 generally be preferred to `assertEquals()` where appropriate, to make the
 tests more reliable.

 Follow-up to [61700].

 Reviewed by peterwilsoncc.
 Merges r62248 to the 7.0 branch.

 Props sagardeshmukh, SergeyBiryukov.
 See #64324.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64324#comment:18>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Sun Apr 26 23:59:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Sun, 26 Apr 2026 23:59:48 -0000
Subject: [wp-trac] [WordPress Trac] #65094: AI: Prompt construction
 fails with fatal error when wp_ai_client_default_request_timeout filter
 returns negative number
In-Reply-To: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
References: <055.509291ad956b141bc82b251686725e0d@wordpress.org>
Message-ID: <070.95fbb2e47cd61a29ec700b9ed40df4fd@wordpress.org>

#65094: AI: Prompt construction fails with fatal error when
wp_ai_client_default_request_timeout filter returns negative number
-------------------------------------------------+-------------------------
 Reporter:  westonruter                          |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  AI                                   |     Version:
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests commit      |     Focuses:
  dev-reviewed                                   |
-------------------------------------------------+-------------------------
Changes (by peterwilsoncc):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62266" 62266]:
 {{{
 #!CommitTicketReference repository="" revision="62266"
 AI: Validate filtered default request timeout in
 `WP_AI_Client_Prompt_Builder`.

 This checks that the return value of the
 `wp_ai_client_default_request_timeout` filter is a non-negative number
 before passing it to `RequestOptions`. If the filtered value is invalid,
 it is discarded in favor of the original default of `30.0` and a
 `_doing_it_wrong()` notice is issued. Without this check, a fatal error
 would ensue from the exception thrown in
 `\WordPress\AiClient\Providers\Http\DTO\RequestOptions::validateTimeout()`.

 The following static analysis issues are addressed:

 * Use `float` instead of `int` for the
 `wp_ai_client_default_request_timeout` filter parameter.
 * Add missing PHP imports for `Message` and `MessagePart` in the PHPDoc
 for `wp_ai_client_prompt()`.
 * Add PHP return type hints for `wp_ai_client_prompt()` and
 `WP_AI_Client_Cache::getMultiple()`.
 * Use native property type hints in `WP_AI_Client_HTTP_Client`.

 Developed in https://github.com/WordPress/wordpress-develop/pull/11596

 Reviewed by peterwilsoncc.
 Merges r62255 to the 7.0 branch.

 Props westonruter, justlevine, flixos90, khushdoms, darshitrajyaguru97,
 adrmf25, jarodortegaaraya, tusharaddweb, gaurangsondagar.
 Fixes #65094.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65094#comment:32>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 00:03:54 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 00:03:54 -0000
Subject: [wp-trac] [WordPress Trac] #64982: library should be changed to
 media library in core or needs gettext
In-Reply-To: <052.6ebe4cf636d68ac01de1c591e6c35312@wordpress.org>
References: <052.6ebe4cf636d68ac01de1c591e6c35312@wordpress.org>
Message-ID: <067.f5ecf242070ab0566e15c6cd83aa679a@wordpress.org>

#64982: library should be changed to media library in core or needs gettext
-------------------------------------------+-----------------------------
 Reporter:  timse201                       |       Owner:  SergeyBiryukov
     Type:  defect (bug)                   |      Status:  closed
 Priority:  normal                         |   Milestone:  7.0
Component:  I18N                           |     Version:  trunk
 Severity:  normal                         |  Resolution:  fixed
 Keywords:  has-patch commit dev-reviewed  |     Focuses:
-------------------------------------------+-----------------------------
Changes (by peterwilsoncc):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62267" 62267]:
 {{{
 #!CommitTicketReference repository="" revision="62267"
 I18N: Add context for the Library admin menu item.

 Reviewed by peterwilsoncc.
 Merges r62256 to the 7.0 branch.

 Props timse201, sanketparmar, trickster301, audrasjb, jadavsanjay,
 SergeyBiryukov.
 Fixes #64982.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64982#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 01:12:50 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 01:12:50 -0000
Subject: [wp-trac] [WordPress Trac] #65063: Classic Editor: slug editing
 field is too large
In-Reply-To: <053.e99112fe2c6dd2520e9b55ab9e698a2b@wordpress.org>
References: <053.e99112fe2c6dd2520e9b55ab9e698a2b@wordpress.org>
Message-ID: <068.bd8855882f1fb7a9bd46e43372a2e00d@wordpress.org>

#65063: Classic Editor: slug editing field is too large
-------------------------------------------------+-------------------------
 Reporter:  wildworks                            |       Owner:  joedolson
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch fixed-major   |     Focuses:
  dev-reviewed                                   |
-------------------------------------------------+-------------------------
Changes (by wildworks):

 * keywords:  admin-reskin has-patch commit dev-feedback fixed-major =>
     admin-reskin has-patch fixed-major dev-reviewed


Comment:

 Approving [62263] for 7.0 backport.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65063#comment:21>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 02:10:32 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 02:10:32 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.9a4cd5db28258f3055cc3b4196036625@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
---------------------------------------+-----------------------
 Reporter:  shatrumyatra               |       Owner:  audrasjb
     Type:  defect (bug)               |      Status:  closed
 Priority:  normal                     |   Milestone:  7.0
Component:  Administration             |     Version:  trunk
 Severity:  normal                     |  Resolution:  fixed
 Keywords:  has-screenshots has-patch  |     Focuses:  ui
---------------------------------------+-----------------------
Changes (by peterwilsoncc):

 * status:  accepted => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62268" 62268]:
 {{{
 #!CommitTicketReference repository="" revision="62268"
 Administration: Widen screen options number of items field.

 Modifies the Screen Options > Number of items per page field to avoid
 cropping of three digit numbers when setting a list view to display a lot
 of items.

 Props apermo, audrasjb, darshitrajyaguru97, ekla, gaurangsondagar,
 jigarkahar, juanmaguitar, khushdoms, peterwilsoncc, sabernhardt, shailu25,
 shatrumyatra, yusufmudagal.
 Fixes #65104.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104#comment:17>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 02:11:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 02:11:30 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.ad1ddb1253fb8e64b8f84d658070395b@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
-------------------------------------------------+-------------------------
 Reporter:  shatrumyatra                         |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-screenshots has-patch dev-       |     Focuses:  ui
  feedback                                       |
-------------------------------------------------+-------------------------
Changes (by peterwilsoncc):

 * keywords:  has-screenshots has-patch => has-screenshots has-patch dev-
     feedback
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Reopening for merging r62268 to the 7.0 branch pending another committers
 sign-off.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104#comment:18>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 02:16:43 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 02:16:43 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.7844d11e327b398f727edb1f3f9f2b50@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
-------------------------------------------------+-------------------------
 Reporter:  shatrumyatra                         |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-screenshots has-patch dev-       |     Focuses:  ui
  reviewed                                       |
-------------------------------------------------+-------------------------
Changes (by audrasjb):

 * keywords:  has-screenshots has-patch dev-feedback => has-screenshots has-
     patch dev-reviewed


Comment:

 This is a second committer sign off. Let's get this fix backported to
 branch 7.0.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104#comment:20>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 02:19:45 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 02:19:45 -0000
Subject: [wp-trac] [WordPress Trac] #65104: Screen Options "Number of
 items per page" input clips last digit for 3-digit values
In-Reply-To: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
References: <056.390dafa7c78cc4654cd9958065232afa@wordpress.org>
Message-ID: <071.1ecfd466593cb9672552fb8e78ede4b0@wordpress.org>

#65104: Screen Options "Number of items per page" input clips last digit for
3-digit values
-------------------------------------------------+-------------------------
 Reporter:  shatrumyatra                         |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-screenshots has-patch dev-       |     Focuses:  ui
  reviewed                                       |
-------------------------------------------------+-------------------------
Changes (by peterwilsoncc):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62269" 62269]:
 {{{
 #!CommitTicketReference repository="" revision="62269"
 Administration: Widen screen options number of items field.

 Modifies the Screen Options > Number of items per page field to avoid
 cropping of three digit numbers when setting a list view to display a lot
 of items.

 Reviewed by audrasjb.
 Merges r62268 to the 7.0 branch.

 Props apermo, audrasjb, darshitrajyaguru97, ekla, gaurangsondagar,
 jigarkahar, juanmaguitar, khushdoms, peterwilsoncc, sabernhardt, shailu25,
 shatrumyatra, yusufmudagal.
 Fixes #65104.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65104#comment:21>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 02:23:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 02:23:30 -0000
Subject: [wp-trac] [WordPress Trac] #65063: Classic Editor: slug editing
 field is too large
In-Reply-To: <053.e99112fe2c6dd2520e9b55ab9e698a2b@wordpress.org>
References: <053.e99112fe2c6dd2520e9b55ab9e698a2b@wordpress.org>
Message-ID: <068.f2fa5e749d77f4b4751a7b320c2698dc@wordpress.org>

#65063: Classic Editor: slug editing field is too large
-------------------------------------------------+-------------------------
 Reporter:  wildworks                            |       Owner:  joedolson
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  Administration                       |     Version:  trunk
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  admin-reskin has-patch fixed-major   |     Focuses:
  dev-reviewed                                   |
-------------------------------------------------+-------------------------
Changes (by peterwilsoncc):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62270" 62270]:
 {{{
 #!CommitTicketReference repository="" revision="62270"
 Administration: Resize classic editor slug field for new theme.

 Reduces the size and improves the alignment of the post slug field
 following the re-design of form elements as part of the new admin theme.

 Reviewed by wildworks.
 Merges r62263 to the 7.0 branch.

 Props wildworks, sabernhardt, audrasjb, dhruvang21, shailu25, joedolson,
 khushdoms, tusharaddweb.
 Fixes #65063.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65063#comment:22>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 02:31:25 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 02:31:25 -0000
Subject: [wp-trac] [WordPress Trac] #65131: Editor: Spinners are misaligned
Message-ID: <053.8909cf9fe91d2de421593bc947a3a237@wordpress.org>

#65131: Editor: Spinners are misaligned
----------------------------+--------------------------
 Reporter:  wildworks       |      Owner:  (none)
     Type:  defect (bug)    |     Status:  new
 Priority:  normal          |  Milestone:  7.0
Component:  Administration  |    Version:
 Severity:  normal          |   Keywords:  admin-reskin
  Focuses:  ui              |
----------------------------+--------------------------
 Spinners may appear to the left of buttons during certain actions. Many of
 these spinners are aligned with the buttons by applying top margin.
 However, due to a change in button size to 40px in accordance with the new
 design system, the alignment between the buttons and spinners is no longer
 correct.

 Upon investigating the entire UI, misalignment has been observed in at
 least the following locations:

 - Classic Editor > Publish Sidebar > Update or Publish button
 - Classic Widget Editor > Save button
 - Posts > Tags > Add Tag button
 - Menus > Add to Menu button
 - Customize > Menus > Menu > Add Imtes > Custom Links > Add to Menu
 - Media (List view) > Edit > Edit Image button
 - Media (List view) > Edit > Update button
 - Media (List view) > Attach > Search input field


 It seems that the positions of these two locations have been misaligned
 for some time.

 - Theme File Editor > Update File button
 - Plugin File Editor > Update File button


 You can also force the spinner to be displayed by adding the following
 CSS:

 {{{
 .spinner {
   visibility: visible;
 }
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65131>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 02:32:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 02:32:05 -0000
Subject: [wp-trac] [WordPress Trac] #65131: Editor: Spinners are
 misaligned
In-Reply-To: <053.8909cf9fe91d2de421593bc947a3a237@wordpress.org>
References: <053.8909cf9fe91d2de421593bc947a3a237@wordpress.org>
Message-ID: <068.a578df8621385081ddfa27f1d81b7f0e@wordpress.org>

#65131: Editor: Spinners are misaligned
----------------------------+---------------------
 Reporter:  wildworks       |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  admin-reskin    |     Focuses:  ui
----------------------------+---------------------
Changes (by wildworks):

 * Attachment "spinner.png" added.

 Compare the areas where issues are occurring between WP7.0 and 6.9

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65131>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 02:38:59 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 02:38:59 -0000
Subject: [wp-trac] [WordPress Trac] #65131: Administration: Spinners are
 misaligned (was: Editor: Spinners are misaligned)
In-Reply-To: <053.8909cf9fe91d2de421593bc947a3a237@wordpress.org>
References: <053.8909cf9fe91d2de421593bc947a3a237@wordpress.org>
Message-ID: <068.121bf33b8920c297d63198b4005a6bd9@wordpress.org>

#65131: Administration: Spinners are misaligned
----------------------------+---------------------
 Reporter:  wildworks       |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  admin-reskin    |     Focuses:  ui
----------------------------+---------------------

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65131#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 02:43:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 02:43:53 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.1a44d25c43ab7a28f6e34ec81b125b02@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
-------------------------------------+-------------------------------------
 Reporter:  piyushpatel123           |       Owner:  audrasjb
     Type:  defect (bug)             |      Status:  reopened
 Priority:  normal                   |   Milestone:  7.0
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  admin-reskin dev-        |     Focuses:  ui, css,
  feedback                           |  administration
-------------------------------------+-------------------------------------

Comment (by wildworks):

 The issue is fixed in the desktop layout by [62262], but it causes a
 misalignment in the mobile layout. We need to consider an alternative
 approach.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031#comment:25>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 02:44:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 02:44:29 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.025f3e620823224fe77d59a620b2409f@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
-------------------------------------+-------------------------------------
 Reporter:  piyushpatel123           |       Owner:  audrasjb
     Type:  defect (bug)             |      Status:  reopened
 Priority:  normal                   |   Milestone:  7.0
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  admin-reskin dev-        |     Focuses:  ui, css,
  feedback                           |  administration
-------------------------------------+-------------------------------------
Changes (by wildworks):

 * Attachment "password-field-icon.png" added.

 Compare before and after commit r62262

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 02:46:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 02:46:29 -0000
Subject: [wp-trac] [WordPress Trac] #65131: Administration: Spinners are
 misaligned
In-Reply-To: <053.8909cf9fe91d2de421593bc947a3a237@wordpress.org>
References: <053.8909cf9fe91d2de421593bc947a3a237@wordpress.org>
Message-ID: <068.641a0f97c134b86b3d08f6c728faa2c3@wordpress.org>

#65131: Administration: Spinners are misaligned
--------------------------------------+---------------------
 Reporter:  wildworks                 |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Administration            |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  admin-reskin needs-patch  |     Focuses:  ui
--------------------------------------+---------------------
Changes (by wildworks):

 * keywords:  admin-reskin => admin-reskin needs-patch


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65131#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 02:47:00 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 02:47:00 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.9bbcdb535e4feb3b3aa0399d47cd64af@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
-------------------------------------+-------------------------------------
 Reporter:  piyushpatel123           |       Owner:  audrasjb
     Type:  defect (bug)             |      Status:  reopened
 Priority:  normal                   |   Milestone:  7.0
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  admin-reskin needs-      |     Focuses:  ui, css,
  patch                              |  administration
-------------------------------------+-------------------------------------
Changes (by wildworks):

 * keywords:  admin-reskin dev-feedback => admin-reskin needs-patch


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031#comment:26>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 03:39:24 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 03:39:24 -0000
Subject: [wp-trac] [WordPress Trac] #64245: Update bundled root
 certificates for 7.0
In-Reply-To: <051.9329d945b761b17ec3cc2d8d8625c518@wordpress.org>
References: <051.9329d945b761b17ec3cc2d8d8625c518@wordpress.org>
Message-ID: <066.a37380551673fb114a4d39ac0e10f5fc@wordpress.org>

#64245: Update bundled root certificates for 7.0
----------------------------+----------------------
 Reporter:  desrosj         |       Owner:  desrosj
     Type:  task (blessed)  |      Status:  closed
 Priority:  normal          |   Milestone:  7.0
Component:  Security        |     Version:
 Severity:  normal          |  Resolution:  fixed
 Keywords:  has-patch       |     Focuses:
----------------------------+----------------------
Changes (by peterwilsoncc):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62271" 62271]:
 {{{
 #!CommitTicketReference repository="" revision="62271"
 Security: Update `composer/ca-bundle` to version `1.5.11`.

 This update adds 1 certificate to the bundle.

 Props desrosj.
 Fixes #64245.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64245#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 03:41:02 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 03:41:02 -0000
Subject: [wp-trac] [WordPress Trac] #64245: Update bundled root
 certificates for 7.0
In-Reply-To: <051.9329d945b761b17ec3cc2d8d8625c518@wordpress.org>
References: <051.9329d945b761b17ec3cc2d8d8625c518@wordpress.org>
Message-ID: <066.8e765c725d09070bf5d94cec753a5061@wordpress.org>

#64245: Update bundled root certificates for 7.0
------------------------------------+-----------------------
 Reporter:  desrosj                 |       Owner:  desrosj
     Type:  task (blessed)          |      Status:  reopened
 Priority:  normal                  |   Milestone:  7.0
Component:  Security                |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:
------------------------------------+-----------------------
Changes (by peterwilsoncc):

 * keywords:  has-patch => has-patch dev-feedback
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Reopening for merging r62271 to the 7.0 branch pending another committer's
 sign off.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64245#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 04:36:24 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 04:36:24 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.e6acbac0b4e912cae07798f10950f888@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
------------------------------------+--------------------------------------
 Reporter:  piyushpatel123          |       Owner:  audrasjb
     Type:  defect (bug)            |      Status:  closed
 Priority:  normal                  |   Milestone:  7.0
Component:  Administration          |     Version:  trunk
 Severity:  normal                  |  Resolution:  fixed
 Keywords:  admin-reskin has-patch  |     Focuses:  ui, css, administration
------------------------------------+--------------------------------------
Changes (by wildworks):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62272" 62272]:
 {{{
 #!CommitTicketReference repository="" revision="62272"
 Administration: Fix misaligned icon in user profile password field on
 mobile.

 In [62262], the show/hide button next to the password field was aligned
 using `line-height` and `vertical-align`. This approach
 left the icon misaligned on mobile viewports.

 Follow-up to [62262].

 Props mukesh27, wildworks.
 Fixes #65031.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031#comment:28>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 04:38:38 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 04:38:38 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.aed4c8a71dcda7bc77743b3b26abfba4@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
-------------------------------------+-------------------------------------
 Reporter:  piyushpatel123           |       Owner:  audrasjb
     Type:  defect (bug)             |      Status:  closed
 Priority:  normal                   |   Milestone:  7.0
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:  fixed
 Keywords:  admin-reskin has-patch   |     Focuses:  ui, css,
  dev-feedback                       |  administration
-------------------------------------+-------------------------------------
Changes (by wildworks):

 * keywords:  admin-reskin has-patch => admin-reskin has-patch dev-feedback


Comment:

 Reopening #65031 to request backporting **[62262] and [62272]** to 7.0
 branch. Note that backporting the two PRs together will resolve the issue
 without regressions.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031#comment:29>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 04:45:51 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 04:45:51 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.f65d6de12e45dc6b28b64aaeca7aa3fd@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
-------------------------------------+-------------------------------------
 Reporter:  piyushpatel123           |       Owner:  audrasjb
     Type:  defect (bug)             |      Status:  reopened
 Priority:  normal                   |   Milestone:  7.0
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  admin-reskin has-patch   |     Focuses:  ui, css,
  dev-reviewed                       |  administration
-------------------------------------+-------------------------------------
Changes (by peterwilsoncc):

 * keywords:  admin-reskin has-patch dev-feedback => admin-reskin has-patch
     dev-reviewed
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 r62262 and r62272 approved for merge to the 7.0 branch.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031#comment:30>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 05:58:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 05:58:31 -0000
Subject: [wp-trac] [WordPress Trac] #65062: Revisions: buttons are
 misplaced
In-Reply-To: <053.b9ce602729457db6bab38d69686036f5@wordpress.org>
References: <053.b9ce602729457db6bab38d69686036f5@wordpress.org>
Message-ID: <068.06efa7cecb6b874fcbcbe8a5a8d6d38b@wordpress.org>

#65062: Revisions: buttons are misplaced
--------------------------------------------------+------------------------
 Reporter:  wildworks                             |       Owner:  joedolson
     Type:  defect (bug)                          |      Status:  closed
 Priority:  normal                                |   Milestone:  7.0
Component:  Revisions                             |     Version:
 Severity:  normal                                |  Resolution:  fixed
 Keywords:  admin-reskin has-patch has-test-info  |     Focuses:
--------------------------------------------------+------------------------
Changes (by wildworks):

 * status:  accepted => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62273" 62273]:
 {{{
 #!CommitTicketReference repository="" revision="62273"
 Revisions: Fix misplaced buttons in comparison UI.

 Align the Previous, Next, and Restore This Revision buttons consistently
 across viewports on the revisions comparison screen.

 Props audrasjb, mokshasharmila13, peterwilsoncc, presskopp, shailu25,
 wildworks.
 Fixes #65062.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65062#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 06:01:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 06:01:09 -0000
Subject: [wp-trac] [WordPress Trac] #65062: Revisions: buttons are
 misplaced
In-Reply-To: <053.b9ce602729457db6bab38d69686036f5@wordpress.org>
References: <053.b9ce602729457db6bab38d69686036f5@wordpress.org>
Message-ID: <068.506497118f4886a7f06a9c00c066f7ed@wordpress.org>

#65062: Revisions: buttons are misplaced
-------------------------------------------------+-------------------------
 Reporter:  wildworks                            |       Owner:  joedolson
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Revisions                            |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch has-test-     |     Focuses:
  info dev-feedback                              |
-------------------------------------------------+-------------------------
Changes (by wildworks):

 * keywords:  admin-reskin has-patch has-test-info => admin-reskin has-patch
     has-test-info dev-feedback
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Reopening #65062 to request backporting [62273] to 7.0 branch

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65062#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 06:15:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 06:15:23 -0000
Subject: [wp-trac] [WordPress Trac] #65031: User Edit Screen Displays
 Misaligned Password Dashicon in WordPress 7.0-RC2
In-Reply-To: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
References: <058.bb9004e8f58c328985dfd3a09b9bbe95@wordpress.org>
Message-ID: <073.3cc0050d3a3e3caa5cc1780d151f2ac3@wordpress.org>

#65031: User Edit Screen Displays Misaligned Password Dashicon in WordPress 7.0-RC2
-------------------------------------+-------------------------------------
 Reporter:  piyushpatel123           |       Owner:  audrasjb
     Type:  defect (bug)             |      Status:  closed
 Priority:  normal                   |   Milestone:  7.0
Component:  Administration           |     Version:  trunk
 Severity:  normal                   |  Resolution:  fixed
 Keywords:  admin-reskin has-patch   |     Focuses:  ui, css,
  dev-reviewed                       |  administration
-------------------------------------+-------------------------------------
Changes (by wildworks):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 Apologies, I missed including `Fixes #65031` when performing the backport
 commits. However, r62262 and r62272 were indeed backported to the 7.0
 branch.

 [62274]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65031#comment:31>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 06:19:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 06:19:33 -0000
Subject: [wp-trac] [WordPress Trac] #64999: Admin reskin: Form elements
 are not standardized in the mobile viewport.
In-Reply-To: <053.6afa9d79ed563c578a97c68f2ee8cfe3@wordpress.org>
References: <053.6afa9d79ed563c578a97c68f2ee8cfe3@wordpress.org>
Message-ID: <068.41480082b2a7c777048a2bfed745968b@wordpress.org>

#64999: Admin reskin: Form elements are not standardized in the mobile viewport.
------------------------------------+---------------------
 Reporter:  wildworks               |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  admin-reskin has-patch  |     Focuses:
------------------------------------+---------------------
Changes (by wildworks):

 * milestone:  Awaiting Review => 7.0


Comment:

 We may not be able to fix all issues in the 7.0 release, but let's do our
 best to address as many as possible.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64999#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 06:26:41 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 06:26:41 -0000
Subject: [wp-trac] [WordPress Trac] #65128: Warning on the post page.
In-Reply-To: <056.36dc6c1c8bcecf8876faea078501974f@wordpress.org>
References: <056.36dc6c1c8bcecf8876faea078501974f@wordpress.org>
Message-ID: <071.c383aa35df9a0132d9415c50b02dac5f@wordpress.org>

#65128: Warning on the post page.
-----------------------------------------+------------------------------
 Reporter:  gautammkgarg                 |       Owner:  (none)
     Type:  defect (bug)                 |      Status:  new
 Priority:  normal                       |   Milestone:  Awaiting Review
Component:  Administration               |     Version:  trunk
 Severity:  normal                       |  Resolution:
 Keywords:  has-patch reporter-feedback  |     Focuses:
-----------------------------------------+------------------------------

Comment (by gaurangsondagar):

 **Patch Testing Report**

 **Patch Tested:** https://github.com/WordPress/wordpress-
 develop/pull/11644/commits/e4f03cb892735afaab1d7ec207b9ae3046d7f3dc

 **Environment:**
 - PHP: 8.2.29
 - WordPress: 7.0-RC2-62242
 - Web server: Apache
 - Database: MySQL
 - Browser: Chrome
 - OS: Ubuntu 22.04.5 LTS
 - Active Theme: Twenty Twenty-Five

 **Active Plugins:**
 - AI
 - AI Provider for Google
 - AI Provider for OpenAI
 - Knit Pay

 **Steps performed:**
 - Installed the **Knit Pay** plugin from the WordPress repository
 - Navigated to **Knit Pay → Configurations** and created a new payment
 gateway configuration
 - Selected **UPI QR** as the payment provider
 - Entered a sample value (e.g., "xyz") in the **UPI VPA ID** field and
 published the configuration.
 - Published the configuration
 - Once the page reloaded, scrolled down to the **Test** section
 - Entered a test amount.
 - Clicked the **Test** button and the warning appears on the resulting
 page

 **Result:**
 The patch is working as expected for the warning. However, I am also
 encountering a couple of deprecation notices. Please review the attached
 screenshots for reference.

 **Before Applied the patch:** https://snipboard.io/GRBhPD.jpg
 **After Applied the patch:** https://snipboard.io/XicjNZ.jpg

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65128#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 07:07:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 07:07:48 -0000
Subject: [wp-trac] [WordPress Trac] #65128: Warning on the post page.
In-Reply-To: <056.36dc6c1c8bcecf8876faea078501974f@wordpress.org>
References: <056.36dc6c1c8bcecf8876faea078501974f@wordpress.org>
Message-ID: <071.fdc9cee40f50665f1d2c391a58063ea1@wordpress.org>

#65128: Warning on the post page.
-----------------------------------------+------------------------------
 Reporter:  gautammkgarg                 |       Owner:  (none)
     Type:  defect (bug)                 |      Status:  new
 Priority:  normal                       |   Milestone:  Awaiting Review
Component:  Administration               |     Version:  trunk
 Severity:  normal                       |  Resolution:
 Keywords:  has-patch reporter-feedback  |     Focuses:
-----------------------------------------+------------------------------

Comment (by darshitrajyaguru97):

 == **Test Report ==

 === **Description ===
 This report verifies whether the patch correctly displays the warning
 during the Knit Pay UPI QR test flow and checks for any additional issues.

 '''Patch Tested:'''
 https://github.com/WordPress/wordpress-
 develop/pull/11644/commits/e4f03cb892735afaab1d7ec207b9ae3046d7f3dc


 === **Environment ===
 * WordPress: 7.0-RC2-62242
 * PHP: 8.2.29
 * Database: MySQL
 * Browser: Chrome
 * OS: Windows
 * Theme: Twenty Twenty-Five


 === **Active Plugins ===
 * AI
 * AI Provider for Google
 * AI Provider for OpenAI
 * Knit Pay


 === **Steps to Reproduce ===
 # Install and activate the Knit Pay plugin from the WordPress repository.
 # Navigate to '''Knit Pay → Configurations'''.
 # Create a new payment gateway configuration.
 # Select '''UPI QR''' as the payment provider.
 # Enter a sample value (e.g., ''xyz'') in the '''UPI VPA ID''' field.
 # Publish the configuration.
 # After the page reloads, scroll down to the '''Test''' section.
 # Enter a test amount.
 # Click the '''Test''' button.


 === **Expected Results ===
 * A warning message should appear on the resulting page when testing with
 invalid or sample input.


 === **Actual Results ===
 * ✅ The warning message is displayed as expected, confirming the patch is
 functioning correctly.
 * ⚠️ Additional '''deprecation notices''' are also observed during the
 process.


 === **Notes ===
 * The primary functionality introduced by the patch works as intended.
 * The deprecation notices may indicate compatibility issues with the
 current PHP version or related components and should be reviewed
 separately.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65128#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 07:13:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 07:13:09 -0000
Subject: [wp-trac] [WordPress Trac] #65062: Revisions: buttons are
 misplaced
In-Reply-To: <053.b9ce602729457db6bab38d69686036f5@wordpress.org>
References: <053.b9ce602729457db6bab38d69686036f5@wordpress.org>
Message-ID: <068.e5860d50dac2bf58af1bbc351e4e76d9@wordpress.org>

#65062: Revisions: buttons are misplaced
-------------------------------------------------+-------------------------
 Reporter:  wildworks                            |       Owner:  joedolson
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Revisions                            |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch has-test-     |     Focuses:
  info dev-feedback                              |
-------------------------------------------------+-------------------------

Comment (by darshitrajyaguru97):

 == Test Report ==

 === Description ===
 This report verifies whether the patch improves the alignment and layout
 of the Previous/Next buttons on the Revisions screen across different
 screen sizes.

 '''Patch Tested:'''
 https://github.com/WordPress/wordpress-develop/pull/11549


 === Environment ===
 * WordPress: 7.1-alpha (latest)
 * PHP: 8.2.29
 * Browser: Chrome
 * OS: Windows
 * Theme: Twenty Twenty-Five
 * Plugins: None activated


 === Steps to Reproduce ===
 # Open a post or page in the WordPress admin dashboard.
 # Navigate to the '''Revisions''' screen.
 # Check the layout on desktop, tablet, and mobile screen sizes.
 # Apply the patch.
 # Repeat the same steps after applying the patch.


 === Expected Results ===
 * The Previous and Next buttons should be properly aligned.
 * The layout should be consistent across different screen sizes.
 * The Restore button should display correctly.


 === Actual Results ===
 * ✅ The Previous and Next buttons' alignment is improved.
 * ✅ Layout appears consistent across desktop, tablet, and mobile views.
 * ✅ Restore button is displayed correctly.
 * ✅ No functional issues observed.


 === Notes ===
 * On smaller mobile screens, the buttons still appear slightly small and
 could be improved further in future updates.
 * Overall, the patch resolves the main alignment issue effectively.
 * Tested across multiple screen sizes and everything is working as
 expected.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65062#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 07:15:02 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 07:15:02 -0000
Subject: [wp-trac] [WordPress Trac] #65131: Administration: Spinners are
 misaligned
In-Reply-To: <053.8909cf9fe91d2de421593bc947a3a237@wordpress.org>
References: <053.8909cf9fe91d2de421593bc947a3a237@wordpress.org>
Message-ID: <068.3c97c6a133ed79cdbc3667fa511680c9@wordpress.org>

#65131: Administration: Spinners are misaligned
------------------------------------+---------------------
 Reporter:  wildworks               |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  Administration          |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  admin-reskin has-patch  |     Focuses:  ui
------------------------------------+---------------------

Comment (by gaurangsondagar):

 **Patch Testing Report**

 **Patch Tested:** https://core.trac.wordpress.org/ticket/65131

 **Environment:**
 - PHP: 8.2.29
 - WordPress: 7.0-RC2-62242
 - Web server: Apache
 - Database: MySQL
 - Browser: Chrome
 - OS: Ubuntu 22.04.5 LTS

 **Active Plugins:**
 - AI
 - AI Provider for Google
 - AI Provider for OpenAI

 **Steps performed:**
 - Before applying the patch, I tested the admin screens and found that the
 button spinners were misaligned. After applying the patch, I retested and
 confirmed that the button spinners are now correctly aligned in the
 required areas.

 **Result:**
 The patch is working as expected and has resolved the issue of misaligned
 button spinners.

 **Screenshots for reference:**

 **Before Applying the patch:**
 https://snipboard.io/a49jmM.jpg
 https://snipboard.io/IThVWq.jpg
 https://snipboard.io/jBEYCX.jpg
 https://snipboard.io/wj2kgB.jpg
 https://snipboard.io/qPXpmz.jpg

 **After Applying the patch:**
 https://snipboard.io/Z1BVeO.jpg
 https://snipboard.io/0FYWLx.jpg
 https://snipboard.io/YXE8Gn.jpg

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65131#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 07:21:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 07:21:56 -0000
Subject: [wp-trac] [WordPress Trac] #65128: Warning on the post page.
In-Reply-To: <056.36dc6c1c8bcecf8876faea078501974f@wordpress.org>
References: <056.36dc6c1c8bcecf8876faea078501974f@wordpress.org>
Message-ID: <071.9265a6e2cbf6274bed47a7ecaeae52e7@wordpress.org>

#65128: Warning on the post page.
-----------------------------------------+------------------------------
 Reporter:  gautammkgarg                 |       Owner:  (none)
     Type:  defect (bug)                 |      Status:  new
 Priority:  normal                       |   Milestone:  Awaiting Review
Component:  Administration               |     Version:  trunk
 Severity:  normal                       |  Resolution:
 Keywords:  has-patch reporter-feedback  |     Focuses:
-----------------------------------------+------------------------------

Comment (by gautammkgarg):

 @gaurangsondagar and @darshitrajyaguru97

 Thanks for doing patch testing.

 @mukeshpanchal27 and @apermo, what would you suggest, should I raise a
 separate PR for fixing deprecation notices. or these should be fixed
 within same PR?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65128#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 07:55:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 07:55:17 -0000
Subject: [wp-trac] [WordPress Trac] #65132: Incorrect `@since` annotation
 for `wp_get_user_request()`
Message-ID: <054.e80b32b2a02eb7f23f043ea5ac6fc12c@wordpress.org>

#65132: Incorrect `@since` annotation for `wp_get_user_request()`
--------------------------+----------------------------------------
 Reporter:  swissspidy    |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  low           |  Milestone:  Future Release
Component:  Privacy       |    Version:
 Severity:  trivial       |   Keywords:  needs-patch good-first-bug
  Focuses:  docs          |
--------------------------+----------------------------------------
 `wp_get_user_request_data()` was renamed to `wp_get_user_request()` in
 [47245] in WP 5.4.0, and the former deprecated. However, the docblock for
 `wp_get_user_request()`  wasn't updated and wrongly indicates it was
 introduced in 4.9.6, when it was actually 5.4.0

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65132>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 08:28:24 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 08:28:24 -0000
Subject: [wp-trac] [WordPress Trac] #64596: Abilities API: Allow ability
 names to contain multiple slug fragments (2-4 segments)
In-Reply-To: <060.74f0d53f8f168f6d8e4740aae322ab76@wordpress.org>
References: <060.74f0d53f8f168f6d8e4740aae322ab76@wordpress.org>
Message-ID: <075.bebe398ff2fe77594270ab7629ba90b5@wordpress.org>

#64596: Abilities API: Allow ability names to contain multiple slug fragments (2-4
segments)
------------------------------------------------+--------------------------
 Reporter:  jorgefilipecosta                    |       Owner:
                                                |  jorgefilipecosta
     Type:  enhancement                         |      Status:  reopened
 Priority:  normal                              |   Milestone:
Component:  Abilities API                       |     Version:  trunk
 Severity:  normal                              |  Resolution:
 Keywords:  abilities has-patch has-unit-tests  |     Focuses:
------------------------------------------------+--------------------------

Comment (by jorgefilipecosta):

 Replying to [comment:25 justlevine]:
 > @jorgefilipecosta on what basis did you change this to close+wontfix ?
 AFAIK this is still slated for 7.1 inclusion (and ideally `early` to allow
 us to iterate on our slate of core + ai plugin Abilities with their
 intended names).
 >
 > As I see no record that a contrary decision was made or any discussions
 on the topic since I last brought it up in Slack and the Contributor call
 a couple weeks ago, I'm assuming this was a triaging mistake and reopening
 🙇


 Hi @justlevine, I closed it as "won't fix" since I originally created the
 ticket and it's not something I'm able to prioritize for the foreseeable
 future. That said, if this is something you or another contributor would
 like to take ownership of, just let me know and I'd be happy to reopen it
 and update the owner. 😊

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64596#comment:26>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 08:30:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 08:30:44 -0000
Subject: [wp-trac] [WordPress Trac] #65123: Having a malformed post type
 query in $_GET or $_POST yields a critical error
In-Reply-To: <055.29dc7cdfbf1c0409285d3c1ace563536@wordpress.org>
References: <055.29dc7cdfbf1c0409285d3c1ace563536@wordpress.org>
Message-ID: <070.ff8ce336a8414ef4f37689c4ca58d998@wordpress.org>

#65123: Having a malformed post type query in $_GET or $_POST yields a critical
error
--------------------------------------+------------------------------
 Reporter:  hheuzebrutc               |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  Permalinks                |     Version:  6.9.4
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+------------------------------
Changes (by sukhendu2002):

 * keywords:  has-patch => has-patch has-unit-tests


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65123#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 09:30:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 09:30:17 -0000
Subject: [wp-trac] [WordPress Trac] #64999: Admin reskin: Form elements
 are not standardized in the mobile viewport.
In-Reply-To: <053.6afa9d79ed563c578a97c68f2ee8cfe3@wordpress.org>
References: <053.6afa9d79ed563c578a97c68f2ee8cfe3@wordpress.org>
Message-ID: <068.805df5c25e79a2671bfb3283d2dfc04b@wordpress.org>

#64999: Admin reskin: Form elements are not standardized in the mobile viewport.
------------------------------------+---------------------
 Reporter:  wildworks               |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  admin-reskin has-patch  |     Focuses:
------------------------------------+---------------------

Comment (by abcd95):

 Hello!

 Here are the places that I investigated and confirmed no fix needed:**
 - `common.css` line 4244 — `.wp-filter .button.drawer-toggle { height:
 28px }` in tablet media query: This is dead CSS. `min-height: 40px` from
 `buttons.css` mobile base already wins, rendering the element at exactly
 40px. No change required.
 - `list-tables.css` line 1908 — `.view-switch a` at 36px: Parent is
 `display: none` on mobile. Not visible to users.
 - `customize-widgets.css` — `.widget-reorder-nav span`: This is in a
 desktop compact media query (`min-width: 783px and max-width: 1100px`),
 not the mobile breakpoint. Out of scope.

 found soem dead CSS also -
 - `edit.css:1883` — `.post-format-options a div`: No PHP/JS generates this
 markup
 - `edit.css:1976` — `.wp_themeSkin a.mceButton`: Legacy TinyMCE 3.x
 selector; WordPress uses TinyMCE 4.x

 I am not sure regarding this place -
 https://core.trac.wordpress.org/browser/trunk/src/wp-admin/css/customize-
 controls.css#L2890

 Do we need to update this too?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64999#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 10:51:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 10:51:22 -0000
Subject: [wp-trac] [WordPress Trac] #65132: Incorrect `@since`
 annotation for `wp_get_user_request()`
In-Reply-To: <054.e80b32b2a02eb7f23f043ea5ac6fc12c@wordpress.org>
References: <054.e80b32b2a02eb7f23f043ea5ac6fc12c@wordpress.org>
Message-ID: <069.bb2a8355be6ed37819c7f7a8a44913ff@wordpress.org>

#65132: Incorrect `@since` annotation for `wp_get_user_request()`
--------------------------------------+-----------------------------
 Reporter:  swissspidy                |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  low                       |   Milestone:  Future Release
Component:  Privacy                   |     Version:
 Severity:  trivial                   |  Resolution:
 Keywords:  good-first-bug has-patch  |     Focuses:  docs
--------------------------------------+-----------------------------

Comment (by gaurangsondagar):

 **Patch Report Testing**

 **Patch Tested:** https://github.com/WordPress/wordpress-
 develop/pull/11653/commits/23f367fb7cac4861204b7eaf57190e12250e25d7

 **Environment:**
 - PHP: 8.2.29
 - WordPress: 7.0-RC2-62242
 - Web server: Apache
 - Database: MySQL
 - Browser: Chrome
 - OS: Ubuntu 22.04.5 LTS

 **Result:**
 This Patch corrects the **@since** annotation for
 **wp_get_user_request()** in **src/wp-includes/user.php**, updating it
 from **4.9.6 to 5.4.0**.

 **Screenshot for reference:**
 https://snipboard.io/dR1uBN.jpg

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65132#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 12:03:34 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 12:03:34 -0000
Subject: [wp-trac] [WordPress Trac] #65132: Incorrect `@since`
 annotation for `wp_get_user_request()`
In-Reply-To: <054.e80b32b2a02eb7f23f043ea5ac6fc12c@wordpress.org>
References: <054.e80b32b2a02eb7f23f043ea5ac6fc12c@wordpress.org>
Message-ID: <069.e6079b713bd40a921e6e5180e3c5ab22@wordpress.org>

#65132: Incorrect `@since` annotation for `wp_get_user_request()`
-------------------------------------------------+-------------------------
 Reporter:  swissspidy                           |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  low                                  |   Milestone:  Future
                                                 |  Release
Component:  Privacy                              |     Version:
 Severity:  trivial                              |  Resolution:
 Keywords:  good-first-bug has-patch changes-    |     Focuses:  docs
  requested                                      |
-------------------------------------------------+-------------------------
Changes (by nikunj8866):

 * keywords:  good-first-bug has-patch => good-first-bug has-patch changes-
     requested


Comment:

 I've reviewed the PR and left some feedback. Please take a look.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65132#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 12:23:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 12:23:31 -0000
Subject: [wp-trac] [WordPress Trac] #65132: Incorrect `@since`
 annotation for `wp_get_user_request()`
In-Reply-To: <054.e80b32b2a02eb7f23f043ea5ac6fc12c@wordpress.org>
References: <054.e80b32b2a02eb7f23f043ea5ac6fc12c@wordpress.org>
Message-ID: <069.fbf4d0a439bffa2d16e4f4adf06fe721@wordpress.org>

#65132: Incorrect `@since` annotation for `wp_get_user_request()`
--------------------------------------+-----------------------------
 Reporter:  swissspidy                |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  low                       |   Milestone:  Future Release
Component:  Privacy                   |     Version:
 Severity:  trivial                   |  Resolution:
 Keywords:  good-first-bug has-patch  |     Focuses:  docs
--------------------------------------+-----------------------------
Changes (by nikunj8866):

 * keywords:  good-first-bug has-patch changes-requested => good-first-bug
     has-patch


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65132#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 12:46:51 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 12:46:51 -0000
Subject: [wp-trac] [WordPress Trac] #64300: Twenty Twenty-Four and
 Twenty Twenty-Five: Long links overflow content area
In-Reply-To: <054.661c5ffccc3977d1b5ba4ebbf7ab9549@wordpress.org>
References: <054.661c5ffccc3977d1b5ba4ebbf7ab9549@wordpress.org>
Message-ID: <069.70463e63a439bd536cbbf8086e04ac52@wordpress.org>

#64300: Twenty Twenty-Four and Twenty Twenty-Five: Long links overflow content area
---------------------------+-----------------------------
 Reporter:  cagrimmett     |       Owner:  (none)
     Type:  defect (bug)   |      Status:  new
 Priority:  normal         |   Milestone:  Future Release
Component:  Bundled Theme  |     Version:
 Severity:  normal         |  Resolution:
 Keywords:  has-patch      |     Focuses:  css
---------------------------+-----------------------------

Comment (by yashjawale):

 Hey!
 I've attached a PR with the according to suggestions in this ticket with
 the changes.
 For twentytwentyfour, as its `theme.json` uses an older manifest version
 which doesn't appear to allow `css` key for elements, I've added the
 overflow CSS to its global styles key instead.

 If it'll be preferred to modify CSS files instead, let me know!

 == Before the change
 [[Image(https://file.garden/ae9aEwfELjoYT20i/before-overflow-patch.png)]]

 == After the change
 [[Image(https://file.garden/ae9aEwfELjoYT20i/after-overflow-patch.png)]]

 TIA.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64300#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 13:19:35 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 13:19:35 -0000
Subject: [wp-trac] [WordPress Trac] #65124: Please include additional
 data validation in class-IXR-server.php
In-Reply-To: <057.4b26f520c07119a980e9344a815d2305@wordpress.org>
References: <057.4b26f520c07119a980e9344a815d2305@wordpress.org>
Message-ID: <072.a8fe3fae7b3b7e2674a8ca658808350a@wordpress.org>

#65124: Please include additional data validation in class-IXR-server.php
---------------------------+--------------------------------
 Reporter:  eeeeeeeeeeeee  |       Owner:  (none)
     Type:  defect (bug)   |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  General        |     Version:  4.7
 Severity:  normal         |  Resolution:
 Keywords:  needs-patch    |     Focuses:  php-compatibility
---------------------------+--------------------------------
Changes (by mindctrl):

 * keywords:   => needs-patch
 * version:   => 4.7


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65124#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 13:33:34 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 13:33:34 -0000
Subject: [wp-trac] [WordPress Trac] #64762: Frontend admin toolbar not
 using updated admin color scheme
In-Reply-To: <059.0e31afc455ee11847f5a061f732569ee@wordpress.org>
References: <059.0e31afc455ee11847f5a061f732569ee@wordpress.org>
Message-ID: <074.3c69290d47c86b12df30e95c9ee9cb2b@wordpress.org>

#64762: Frontend admin toolbar not using updated admin color scheme
-------------------------------------------------+-------------------------
 Reporter:  huzaifaalmesbah                      |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Toolbar                              |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-screenshots admin-reskin has-    |     Focuses:  ui, css
  patch has-unit-tests                           |
-------------------------------------------------+-------------------------

Comment (by pavanpatil1):

 **Patch Report**
 Patch Tested: https://github.com/WordPress/wordpress-develop/pull/11354

 **Environment**
 WordPress: 7.0-RC1-20260326.042417
 PHP: 7.4.33
 Browser: Chrome
 OS: Mac

 Patch is working fine ✅

 **Expected result**
 The admin toolbar now matches the chosen admin color scheme.


 **Screenshot**:

 -
 https://www.awesomescreenshot.com/image/60076268?key=d9ca295d58cc93a3e57e414ad492c9ba
 -
 https://www.awesomescreenshot.com/image/60076528?key=4c4d17f7e48524011f333b3d01181c51

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64762#comment:46>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 13:43:35 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 13:43:35 -0000
Subject: [wp-trac] [WordPress Trac] #65006: `uglify:moment` task fails
 due to missing source file
In-Reply-To: <051.84601c4d043c890905c0ce65fe4c33fe@wordpress.org>
References: <051.84601c4d043c890905c0ce65fe4c33fe@wordpress.org>
Message-ID: <066.9c0db03b4a9eb0c80876d92c391cb530@wordpress.org>

#65006: `uglify:moment` task fails due to missing source file
-------------------------------------------+----------------------------
 Reporter:  desrosj                        |       Owner:  peterwilsoncc
     Type:  defect (bug)                   |      Status:  reopened
 Priority:  normal                         |   Milestone:  7.0
Component:  Build/Test Tools               |     Version:  trunk
 Severity:  normal                         |  Resolution:
 Keywords:  has-patch dev-feedback commit  |     Focuses:
-------------------------------------------+----------------------------
Changes (by desrosj):

 * keywords:  has-patch dev-feedback => has-patch dev-feedback commit


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65006#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 13:43:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 13:43:55 -0000
Subject: [wp-trac] [WordPress Trac] #65006: `uglify:moment` task fails
 due to missing source file
In-Reply-To: <051.84601c4d043c890905c0ce65fe4c33fe@wordpress.org>
References: <051.84601c4d043c890905c0ce65fe4c33fe@wordpress.org>
Message-ID: <066.5fb7be3aed201a0eb642f7bdac3c73c0@wordpress.org>

#65006: `uglify:moment` task fails due to missing source file
-------------------------------------------------+-------------------------
 Reporter:  desrosj                              |       Owner:
                                                 |  peterwilsoncc
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Build/Test Tools                     |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch dev-feedback commit        |     Focuses:
  fixed-major                                    |
-------------------------------------------------+-------------------------
Changes (by desrosj):

 * keywords:  has-patch dev-feedback commit => has-patch dev-feedback commit
     fixed-major


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65006#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 13:48:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 13:48:49 -0000
Subject: [wp-trac] [WordPress Trac] #64393: Change how we include
 Gutenberg in Core
In-Reply-To: <055.264b0dba638f7c3f5a9d3208ee755072@wordpress.org>
References: <055.264b0dba638f7c3f5a9d3208ee755072@wordpress.org>
Message-ID: <070.00153d5e7042d20fa244ce1bacbe86e5@wordpress.org>

#64393: Change how we include Gutenberg in Core
------------------------------+--------------------------
 Reporter:  youknowriad       |       Owner:  youknowriad
     Type:  task (blessed)    |      Status:  closed
 Priority:  high              |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:
 Severity:  blocker           |  Resolution:  fixed
 Keywords:  has-patch         |     Focuses:
------------------------------+--------------------------

Comment (by desrosj):

 In [changeset:"62275" 62275]:
 {{{
 #!CommitTicketReference repository="" revision="62275"
 Build/Test Tools: Copy vendor scripts earlier in the build.

 Relocates the copy-vendor-scripts to run during the the build:js portion
 of the build script. This ensures the JavaScript files are in place before
 the uglify:all task is run.

 Follow up to r61438.

 Reviewed by desrosj, peterwilsoncc.
 Merges [62189] to the 7.0 branch.

 Props desrosj, peterwilsoncc.
 Fixes #65006. See #64393.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64393#comment:257>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 13:48:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 13:48:49 -0000
Subject: [wp-trac] [WordPress Trac] #65006: `uglify:moment` task fails
 due to missing source file
In-Reply-To: <051.84601c4d043c890905c0ce65fe4c33fe@wordpress.org>
References: <051.84601c4d043c890905c0ce65fe4c33fe@wordpress.org>
Message-ID: <066.5fff752ad1057399ca68442a337664f1@wordpress.org>

#65006: `uglify:moment` task fails due to missing source file
-------------------------------------------------+-------------------------
 Reporter:  desrosj                              |       Owner:
                                                 |  peterwilsoncc
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  Build/Test Tools                     |     Version:  trunk
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch dev-feedback commit        |     Focuses:
  fixed-major                                    |
-------------------------------------------------+-------------------------
Changes (by desrosj):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62275" 62275]:
 {{{
 #!CommitTicketReference repository="" revision="62275"
 Build/Test Tools: Copy vendor scripts earlier in the build.

 Relocates the copy-vendor-scripts to run during the the build:js portion
 of the build script. This ensures the JavaScript files are in place before
 the uglify:all task is run.

 Follow up to r61438.

 Reviewed by desrosj, peterwilsoncc.
 Merges [62189] to the 7.0 branch.

 Props desrosj, peterwilsoncc.
 Fixes #65006. See #64393.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65006#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 13:48:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 13:48:55 -0000
Subject: [wp-trac] [WordPress Trac] #65006: `uglify:moment` task fails
 due to missing source file
In-Reply-To: <051.84601c4d043c890905c0ce65fe4c33fe@wordpress.org>
References: <051.84601c4d043c890905c0ce65fe4c33fe@wordpress.org>
Message-ID: <066.0c541bec02bc41766af0630a6eb227ea@wordpress.org>

#65006: `uglify:moment` task fails due to missing source file
-------------------------------------------------+-------------------------
 Reporter:  desrosj                              |       Owner:
                                                 |  peterwilsoncc
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  Build/Test Tools                     |     Version:  trunk
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch commit fixed-major dev-    |     Focuses:
  reviewed                                       |
-------------------------------------------------+-------------------------
Changes (by desrosj):

 * keywords:  has-patch dev-feedback commit fixed-major => has-patch commit
     fixed-major dev-reviewed


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65006#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 13:51:24 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 13:51:24 -0000
Subject: [wp-trac] [WordPress Trac] #65007: Contents of some `.min.js`
 files are no longer minified
In-Reply-To: <051.ca77996bd759b0598d7de612a42ec74d@wordpress.org>
References: <051.ca77996bd759b0598d7de612a42ec74d@wordpress.org>
Message-ID: <066.d03a41f69c609af2eda34d0f7230b95a@wordpress.org>

#65007: Contents of some `.min.js` files are no longer minified
---------------------------------------------+----------------------------
 Reporter:  desrosj                          |       Owner:  peterwilsoncc
     Type:  defect (bug)                     |      Status:  reopened
 Priority:  normal                           |   Milestone:  7.0
Component:  Build/Test Tools                 |     Version:  trunk
 Severity:  normal                           |  Resolution:
 Keywords:  fixed-major commit dev-reviewed  |     Focuses:
---------------------------------------------+----------------------------
Changes (by desrosj):

 * keywords:  dev-feedback fixed-major => fixed-major commit dev-reviewed


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65007#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 13:51:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 13:51:33 -0000
Subject: [wp-trac] [WordPress Trac] #64393: Change how we include
 Gutenberg in Core
In-Reply-To: <055.264b0dba638f7c3f5a9d3208ee755072@wordpress.org>
References: <055.264b0dba638f7c3f5a9d3208ee755072@wordpress.org>
Message-ID: <070.5c42640a0c3e7d6b2795dfbd8f108d84@wordpress.org>

#64393: Change how we include Gutenberg in Core
------------------------------+--------------------------
 Reporter:  youknowriad       |       Owner:  youknowriad
     Type:  task (blessed)    |      Status:  closed
 Priority:  high              |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:
 Severity:  blocker           |  Resolution:  fixed
 Keywords:  has-patch         |     Focuses:
------------------------------+--------------------------

Comment (by desrosj):

 In [changeset:"62276" 62276]:
 {{{
 #!CommitTicketReference repository="" revision="62276"
 Build/Test Tools: Consolidate vendor file copying to ensure `.min.js`
 files are minified.

 Relocates the copying of vendor JavaScript files back to the `grunt copy
 :vendor-js` subtask to ensure the files are in place prior to the grunt
 uglify step running to minify the files.

 Reviewed by desrosj, peterwilsoncc.
 Merges [62258] to the 7.0 branch.

 Props desrosj, peterwilsoncc.
 Fixes #65007.
 See #64393.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64393#comment:258>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 13:51:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 13:51:33 -0000
Subject: [wp-trac] [WordPress Trac] #65007: Contents of some `.min.js`
 files are no longer minified
In-Reply-To: <051.ca77996bd759b0598d7de612a42ec74d@wordpress.org>
References: <051.ca77996bd759b0598d7de612a42ec74d@wordpress.org>
Message-ID: <066.ad00c50a64f8b9cd174b33578c574c28@wordpress.org>

#65007: Contents of some `.min.js` files are no longer minified
---------------------------------------------+----------------------------
 Reporter:  desrosj                          |       Owner:  peterwilsoncc
     Type:  defect (bug)                     |      Status:  closed
 Priority:  normal                           |   Milestone:  7.0
Component:  Build/Test Tools                 |     Version:  trunk
 Severity:  normal                           |  Resolution:  fixed
 Keywords:  fixed-major commit dev-reviewed  |     Focuses:
---------------------------------------------+----------------------------
Changes (by desrosj):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62276" 62276]:
 {{{
 #!CommitTicketReference repository="" revision="62276"
 Build/Test Tools: Consolidate vendor file copying to ensure `.min.js`
 files are minified.

 Relocates the copying of vendor JavaScript files back to the `grunt copy
 :vendor-js` subtask to ensure the files are in place prior to the grunt
 uglify step running to minify the files.

 Reviewed by desrosj, peterwilsoncc.
 Merges [62258] to the 7.0 branch.

 Props desrosj, peterwilsoncc.
 Fixes #65007.
 See #64393.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65007#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 13:53:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 13:53:48 -0000
Subject: [wp-trac] [WordPress Trac] #64083: Trim the GitHub Actions
 workflows for older branches (and possibly `trunk`)
In-Reply-To: <055.d1f6227d749409a50dba173f85029277@wordpress.org>
References: <055.d1f6227d749409a50dba173f85029277@wordpress.org>
Message-ID: <070.d08a22c057b0673b1dacffcf1e2178d3@wordpress.org>

#64083: Trim the GitHub Actions workflows for older branches (and possibly `trunk`)
------------------------------+--------------------------
 Reporter:  johnbillion       |       Owner:  johnbillion
     Type:  task (blessed)    |      Status:  reopened
 Priority:  normal            |   Milestone:  7.0
Component:  Build/Test Tools  |     Version:
 Severity:  normal            |  Resolution:
 Keywords:  has-patch         |     Focuses:
------------------------------+--------------------------

Comment (by desrosj):

 @johnbillion I believe that this can be closed out now. Am I missing
 anything that has not been completed?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64083#comment:70>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 13:55:11 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 13:55:11 -0000
Subject: [wp-trac] [WordPress Trac] #64245: Update bundled root
 certificates for 7.0
In-Reply-To: <051.9329d945b761b17ec3cc2d8d8625c518@wordpress.org>
References: <051.9329d945b761b17ec3cc2d8d8625c518@wordpress.org>
Message-ID: <066.8846d9e5c7a1792efd2616f80332ef3c@wordpress.org>

#64245: Update bundled root certificates for 7.0
-------------------------------------------------+-------------------------
 Reporter:  desrosj                              |       Owner:  desrosj
     Type:  task (blessed)                       |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Security                             |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch fixed-major commit dev-    |     Focuses:
  reviewed                                       |
-------------------------------------------------+-------------------------
Changes (by desrosj):

 * keywords:  has-patch dev-feedback => has-patch fixed-major commit dev-
     reviewed


Comment:

 Thanks @peterwilsoncc. Going to backport.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64245#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 13:56:37 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 13:56:37 -0000
Subject: [wp-trac] [WordPress Trac] #64245: Update bundled root
 certificates for 7.0
In-Reply-To: <051.9329d945b761b17ec3cc2d8d8625c518@wordpress.org>
References: <051.9329d945b761b17ec3cc2d8d8625c518@wordpress.org>
Message-ID: <066.b73e9e6f0a1318477c531f1079635fed@wordpress.org>

#64245: Update bundled root certificates for 7.0
-------------------------------------------------+-------------------------
 Reporter:  desrosj                              |       Owner:  desrosj
     Type:  task (blessed)                       |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  Security                             |     Version:
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch fixed-major commit dev-    |     Focuses:
  reviewed                                       |
-------------------------------------------------+-------------------------
Changes (by desrosj):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62277" 62277]:
 {{{
 #!CommitTicketReference repository="" revision="62277"
 Security: Update `composer/ca-bundle` to version `1.5.11`.

 This update adds 1 certificate to the bundle.

 Reviewed by desrosj, peterwilsoncc.
 Merges [62271] to the 7.0 branch.

 Props desrosj, peterwilsoncc.
 Fixes #64245.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64245#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 14:01:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 14:01:26 -0000
Subject: [wp-trac] [WordPress Trac] #60234: Script Modules API: Add a
 translations API
In-Reply-To: <055.a00a950967baaec6dbe390b727ba5388@wordpress.org>
References: <055.a00a950967baaec6dbe390b727ba5388@wordpress.org>
Message-ID: <070.13f2685382340c64eb03587947d49e53@wordpress.org>

#60234: Script Modules API: Add a translations API
---------------------------+------------------------------
 Reporter:  luisherranz    |       Owner:  (none)
     Type:  enhancement    |      Status:  new
 Priority:  normal         |   Milestone:  Awaiting Review
Component:  Script Loader  |     Version:
 Severity:  normal         |  Resolution:
 Keywords:                 |     Focuses:  javascript
---------------------------+------------------------------

Comment (by desrosj):

 This came up in #65015 during the 7.0 cycle.

 I'm not going to close this as a duplicate, but there's a lot of work that
 has happened there to solve this because the new connectors screen is not
 fully translated without this solved. It's likely there will be follow up
 tasks for 7.1+.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60234#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 14:01:52 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 14:01:52 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.358f60ea491d43313c6d2c1eef053bbe@wordpress.org>

#65015: Connectors: Several strings are not translated
-------------------------------------------------+-------------------------
 Reporter:  369work                              |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  reviewing
 Priority:  high                                 |   Milestone:  7.0
Component:  I18N                                 |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests connectors  |     Focuses:
  commit dev-feedback needs-dev-note             |
-------------------------------------------------+-------------------------

Comment (by desrosj):

 Related #60234.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015#comment:38>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 14:37:15 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 14:37:15 -0000
Subject: [wp-trac] [WordPress Trac] #64538: memoize wp_normalize_path
In-Reply-To: <055.d0a68ae7d0a278908d25712bd31f710d@wordpress.org>
References: <055.d0a68ae7d0a278908d25712bd31f710d@wordpress.org>
Message-ID: <070.dca8ad1fb940cb92f4886b98d3c20e25@wordpress.org>

#64538: memoize wp_normalize_path
--------------------------------------+--------------------------
 Reporter:  josephscott               |       Owner:  dmsnell
     Type:  defect (bug)              |      Status:  reopened
 Priority:  normal                    |   Milestone:  7.0
Component:  General                   |     Version:  3.9
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:  performance
--------------------------------------+--------------------------

Comment (by desrosj):

 So interestingly, the host who was experiencing this failure is no longer
 reporting an issue.

 It looks like the [https://make.wordpress.org/hosting/test-results/r62207/
 final changeset that reported the problem] was [62207]. Interestingly,
 62207 tested both a MariaDB and MySQL setup. The test reports for [62208]
 only reported MySQL usage.

 While [62208] was a test-related change, it's not immediately clear
 whether it would have influenced the occurrence of this issue. But it
 seems that no other hosts have reported that specific failure and that
 host has been fixed since.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64538#comment:34>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 16:04:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 16:04:13 -0000
Subject: [wp-trac] [WordPress Trac] #64363: add MarkDown feeds
In-Reply-To: <051.010476209417b3b671d37ad5ddfefea2@wordpress.org>
References: <051.010476209417b3b671d37ad5ddfefea2@wordpress.org>
Message-ID: <066.3ba25275753a722b6f5ecbad58662166@wordpress.org>

#64363: add MarkDown feeds
-------------------------+------------------------------
 Reporter:  pbearne      |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Feeds        |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:
-------------------------+------------------------------

Comment (by pbearne):

 We need to talk about the URL pattern

 The WP.org code is us adding ?output_format=md

 When I first coded this, I used the add_feed functions to add the URL
 pattern just a markdown to the end of the URL  domain.tdl/page/markdown to
 my view, this seems to be cleaner and follows the other views (RSS) in
 WordPress

 What do other people feel is the right solution, and what are the
 pro/cons?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64363#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 16:12:27 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 16:12:27 -0000
Subject: [wp-trac] [WordPress Trac] #65014: Site Health: Error icon
 missing due to missing dashicons class
In-Reply-To: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
References: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
Message-ID: <069.3cc170149ce457e697e6c2cb6c958753@wordpress.org>

#65014: Site Health: Error icon missing due to missing dashicons class
-------------------------------------+-------------------------------------
 Reporter:  valani9099               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  7.1
Component:  Site Health              |     Version:  5.3
 Severity:  normal                   |  Resolution:
 Keywords:  has-screenshots has-     |     Focuses:  ui, css,
  patch                              |  administration
-------------------------------------+-------------------------------------

Comment (by valani9099):

 Thank you for the guidance @wildworks! Understood — I will stop merging
 trunk into the PR and leave it as is.

 Just curious — since WordPress 7.0 release seems to be delayed, is there
 any chance this fix could still be included in 7.0, or will it be targeted
 for 7.1 once trunk reopens? Happy to wait and assist with any further
 testing if needed!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65014#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 17:39:38 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 17:39:38 -0000
Subject: [wp-trac] [WordPress Trac] #65133: Classic editor tagchecklist ui
 issue
Message-ID: <056.cddabe8f9de9c7ca3223e92018d86491@wordpress.org>

#65133: Classic editor tagchecklist ui issue
--------------------------+-----------------------------
 Reporter:  umesh.nevase  |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Editor        |    Version:  trunk
 Severity:  normal        |   Keywords:
  Focuses:  ui            |
--------------------------+-----------------------------
 If we select classic editor in writing settings. If we add new tags in tag
 selection. The delete icons showing misaligned to text in tagchecklist.

 [[Image(https://www.awesomescreenshot.com/image/60082413?key=900948b7df3da4c5c8b77d3f65f3a41a)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65133>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 17:40:11 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 17:40:11 -0000
Subject: [wp-trac] [WordPress Trac] #65133: Classic editor tagchecklist
 ui issue
In-Reply-To: <056.cddabe8f9de9c7ca3223e92018d86491@wordpress.org>
References: <056.cddabe8f9de9c7ca3223e92018d86491@wordpress.org>
Message-ID: <071.16df04584fd59d2690f61882502e82b3@wordpress.org>

#65133: Classic editor tagchecklist ui issue
--------------------------+------------------------------
 Reporter:  umesh.nevase  |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  ui
--------------------------+------------------------------
Changes (by umesh.nevase):

 * Attachment "before-fix.png" added.

 screenshot of the issue

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65133>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 17:40:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 17:40:18 -0000
Subject: [wp-trac] [WordPress Trac] #60234: Script Modules API: Add a
 translations API
In-Reply-To: <055.a00a950967baaec6dbe390b727ba5388@wordpress.org>
References: <055.a00a950967baaec6dbe390b727ba5388@wordpress.org>
Message-ID: <070.4578da8f45036e822e2b541975bbdc0f@wordpress.org>

#60234: Script Modules API: Add a translations API
---------------------------+-------------------------
 Reporter:  luisherranz    |       Owner:  (none)
     Type:  enhancement    |      Status:  new
 Priority:  normal         |   Milestone:  7.1
Component:  Script Loader  |     Version:
 Severity:  normal         |  Resolution:
 Keywords:                 |     Focuses:  javascript
---------------------------+-------------------------
Changes (by westonruter):

 * milestone:  Awaiting Review => 7.1


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60234#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 17:45:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 17:45:14 -0000
Subject: [wp-trac] [WordPress Trac] #65134: Unit Tests: Add tests for
 got_mod_rewrite()
Message-ID: <051.c673ba29d7c178607b30b72f09055dc9@wordpress.org>

#65134: Unit Tests: Add tests for got_mod_rewrite()
----------------------------+-----------------------------
 Reporter:  pbearne         |      Owner:  (none)
     Type:  enhancement     |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Administration  |    Version:
 Severity:  normal          |   Keywords:
  Focuses:                  |
----------------------------+-----------------------------
 The function got_mod_rewrite() in src/wp-admin/includes/misc.php currently
 lacks unit tests. This ticket covers the addition of comprehensive unit
 tests for this function, ensuring it correctly detects Apache mod_rewrite
 support and respects the 'got_rewrite' filter.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65134>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 18:05:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 18:05:49 -0000
Subject: [wp-trac] [WordPress Trac] #65135: Unit Tests: Add tests for
 got_url_rewrite()
Message-ID: <051.4c8b3fc36e4e71162453f4678f584074@wordpress.org>

#65135: Unit Tests: Add tests for got_url_rewrite()
----------------------------+-----------------------------
 Reporter:  pbearne         |      Owner:  (none)
     Type:  enhancement     |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Administration  |    Version:
 Severity:  normal          |   Keywords:
  Focuses:                  |
----------------------------+-----------------------------
 The function got_url_rewrite() in src/wp-admin/includes/misc.php currently
 lacks unit tests. This PR adds tests to ensure it correctly identifies URL
 rewriting support across Apache, nginx, IIS, and Caddy, and respects the
 'got_url_rewrite' filter.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65135>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 18:12:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 18:12:13 -0000
Subject: [wp-trac] [WordPress Trac] #65136: Unit Tests: Add tests for
 extract_from_markers()
Message-ID: <051.8e853587131f1961043d2d9400a7594f@wordpress.org>

#65136: Unit Tests: Add tests for extract_from_markers()
----------------------------+-----------------------------
 Reporter:  pbearne         |      Owner:  (none)
     Type:  enhancement     |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Administration  |    Version:
 Severity:  normal          |   Keywords:
  Focuses:                  |
----------------------------+-----------------------------
 The function extract_from_markers() in src/wp-admin/includes/misc.php
 lacks unit tests. This PR adds tests to ensure it correctly extracts
 content between markers in a file, handling missing files, different
 markers, and comments.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65136>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 18:29:34 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 18:29:34 -0000
Subject: [wp-trac] [WordPress Trac] #60597: Script Modules API: Allow
 list of enqueued module data to be exposed
In-Reply-To: <055.3aa66bfe5fd804f2d836bf1cf1b246aa@wordpress.org>
References: <055.3aa66bfe5fd804f2d836bf1cf1b246aa@wordpress.org>
Message-ID: <070.e5db96ff052f45a2b2fe383577e3306c@wordpress.org>

#60597: Script Modules API: Allow list of enqueued module data to be exposed
--------------------------------------+--------------------------
 Reporter:  johnbillion               |       Owner:  westonruter
     Type:  enhancement               |      Status:  assigned
 Priority:  normal                    |   Milestone:  7.1
Component:  Script Loader             |     Version:  6.5
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+--------------------------

Comment (by westonruter):

 In [changeset:"62278" 62278]:
 {{{
 #!CommitTicketReference repository="" revision="62278"
 I18N: Add translation support for script modules.

 Add automatic translation loading for script modules (ES modules), so
 strings using `__()` and friends from `@wordpress/i18n` can be translated
 at runtime. This brings classic script i18n parity to script modules
 registered via `wp_register_script_module()`, which previously had no way
 to load translation data, leaving strings untranslated on screens like
 Connectors and Fonts that are built as script modules.

 At the `admin_print_footer_scripts` and `wp_footer` actions, every
 enqueued script module and its dependencies are walked, the translation
 chunk is loaded for each, and an inline `<script>` calls
 `wp.i18n.setLocaleData()` so translations are available before deferred
 modules execute. Note there is currently a runtime dependency on the `wp-
 i18n` classic script, which is printed just-in-time if not already
 enqueued. This coupling is to be removed in a future release.

 Public API:

 * `WP_Script_Modules::set_translations()` stores the text domain (and
 optional path) per registered module to override the text domain and path.
 A global `wp_set_script_module_translations()` function is added as a
 wrapper around `wp_script_modules()->set_translations()`.
 * `WP_Script_Modules::get_registered()` obtains a registered module's
 data. See #60597.
 * `WP_Script_Modules::print_script_module_translations()` emits inline
 `wp.i18n.setLocaleData()` calls after classic scripts load but before
 modules execute.
 * `load_script_module_textdomain()` loads the translation data for a given
 script module ID and text domain.
 * The existing `load_script_textdomain_relative_path` filter gains a third
 `$is_module` parameter so callers can distinguish classic-script and
 script-module lookups when resolving translation paths.

 PHPStan types are also added in `WP_Script_Modules`. See #64238.

 Developed in https://github.com/WordPress/wordpress-develop/pull/11543

 Props manzoorwanijk, westonruter, jsnajdr, jonsurrell, mukesh27,
 peterwilsoncc, 369work, desrosj, sabernhardt, nilambar, jorgefilipecosta,
 malayladu.
 See #64238, #60597.
 Fixes #65015.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60597#comment:26>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 18:29:35 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 18:29:35 -0000
Subject: [wp-trac] [WordPress Trac] #64238: PHPStan code quality
 improvements for 7.0
In-Reply-To: <058.3d898e5edbfd206122933e3b070d763b@wordpress.org>
References: <058.3d898e5edbfd206122933e3b070d763b@wordpress.org>
Message-ID: <073.36972d108390a85c783d1eae9366035b@wordpress.org>

#64238: PHPStan code quality improvements for 7.0
--------------------------------------+-------------------------------
 Reporter:  SergeyBiryukov            |       Owner:  (none)
     Type:  task (blessed)            |      Status:  closed
 Priority:  normal                    |   Milestone:  7.0
Component:  General                   |     Version:
 Severity:  normal                    |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests  |     Focuses:  coding-standards
--------------------------------------+-------------------------------

Comment (by westonruter):

 In [changeset:"62278" 62278]:
 {{{
 #!CommitTicketReference repository="" revision="62278"
 I18N: Add translation support for script modules.

 Add automatic translation loading for script modules (ES modules), so
 strings using `__()` and friends from `@wordpress/i18n` can be translated
 at runtime. This brings classic script i18n parity to script modules
 registered via `wp_register_script_module()`, which previously had no way
 to load translation data, leaving strings untranslated on screens like
 Connectors and Fonts that are built as script modules.

 At the `admin_print_footer_scripts` and `wp_footer` actions, every
 enqueued script module and its dependencies are walked, the translation
 chunk is loaded for each, and an inline `<script>` calls
 `wp.i18n.setLocaleData()` so translations are available before deferred
 modules execute. Note there is currently a runtime dependency on the `wp-
 i18n` classic script, which is printed just-in-time if not already
 enqueued. This coupling is to be removed in a future release.

 Public API:

 * `WP_Script_Modules::set_translations()` stores the text domain (and
 optional path) per registered module to override the text domain and path.
 A global `wp_set_script_module_translations()` function is added as a
 wrapper around `wp_script_modules()->set_translations()`.
 * `WP_Script_Modules::get_registered()` obtains a registered module's
 data. See #60597.
 * `WP_Script_Modules::print_script_module_translations()` emits inline
 `wp.i18n.setLocaleData()` calls after classic scripts load but before
 modules execute.
 * `load_script_module_textdomain()` loads the translation data for a given
 script module ID and text domain.
 * The existing `load_script_textdomain_relative_path` filter gains a third
 `$is_module` parameter so callers can distinguish classic-script and
 script-module lookups when resolving translation paths.

 PHPStan types are also added in `WP_Script_Modules`. See #64238.

 Developed in https://github.com/WordPress/wordpress-develop/pull/11543

 Props manzoorwanijk, westonruter, jsnajdr, jonsurrell, mukesh27,
 peterwilsoncc, 369work, desrosj, sabernhardt, nilambar, jorgefilipecosta,
 malayladu.
 See #64238, #60597.
 Fixes #65015.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64238#comment:123>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 18:29:35 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 18:29:35 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.a98684ec3504efb9d7bc948f06d34c86@wordpress.org>

#65015: Connectors: Several strings are not translated
-------------------------------------------------+-------------------------
 Reporter:  369work                              |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  closed
 Priority:  high                                 |   Milestone:  7.0
Component:  I18N                                 |     Version:
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests connectors  |     Focuses:
  commit dev-feedback needs-dev-note             |
-------------------------------------------------+-------------------------
Changes (by westonruter):

 * status:  reviewing => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62278" 62278]:
 {{{
 #!CommitTicketReference repository="" revision="62278"
 I18N: Add translation support for script modules.

 Add automatic translation loading for script modules (ES modules), so
 strings using `__()` and friends from `@wordpress/i18n` can be translated
 at runtime. This brings classic script i18n parity to script modules
 registered via `wp_register_script_module()`, which previously had no way
 to load translation data, leaving strings untranslated on screens like
 Connectors and Fonts that are built as script modules.

 At the `admin_print_footer_scripts` and `wp_footer` actions, every
 enqueued script module and its dependencies are walked, the translation
 chunk is loaded for each, and an inline `<script>` calls
 `wp.i18n.setLocaleData()` so translations are available before deferred
 modules execute. Note there is currently a runtime dependency on the `wp-
 i18n` classic script, which is printed just-in-time if not already
 enqueued. This coupling is to be removed in a future release.

 Public API:

 * `WP_Script_Modules::set_translations()` stores the text domain (and
 optional path) per registered module to override the text domain and path.
 A global `wp_set_script_module_translations()` function is added as a
 wrapper around `wp_script_modules()->set_translations()`.
 * `WP_Script_Modules::get_registered()` obtains a registered module's
 data. See #60597.
 * `WP_Script_Modules::print_script_module_translations()` emits inline
 `wp.i18n.setLocaleData()` calls after classic scripts load but before
 modules execute.
 * `load_script_module_textdomain()` loads the translation data for a given
 script module ID and text domain.
 * The existing `load_script_textdomain_relative_path` filter gains a third
 `$is_module` parameter so callers can distinguish classic-script and
 script-module lookups when resolving translation paths.

 PHPStan types are also added in `WP_Script_Modules`. See #64238.

 Developed in https://github.com/WordPress/wordpress-develop/pull/11543

 Props manzoorwanijk, westonruter, jsnajdr, jonsurrell, mukesh27,
 peterwilsoncc, 369work, desrosj, sabernhardt, nilambar, jorgefilipecosta,
 malayladu.
 See #64238, #60597.
 Fixes #65015.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015#comment:40>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 18:32:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 18:32:33 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.ba5e6f9b2aeeabe0dbb223b7c857cb03@wordpress.org>

#65015: Connectors: Several strings are not translated
-------------------------------------------------+-------------------------
 Reporter:  369work                              |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  high                                 |   Milestone:  7.0
Component:  I18N                                 |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests connectors  |     Focuses:
  commit dev-feedback needs-dev-note fixed-      |
  major                                          |
-------------------------------------------------+-------------------------
Changes (by westonruter):

 * keywords:  has-patch has-unit-tests connectors commit dev-feedback needs-
     dev-note =>
     has-patch has-unit-tests connectors commit dev-feedback needs-dev-note
     fixed-major
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Re-opening for 7.0 backport.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015#comment:41>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 18:59:41 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 18:59:41 -0000
Subject: [wp-trac] [WordPress Trac] #65133: Classic editor tagchecklist
 ui issue
In-Reply-To: <056.cddabe8f9de9c7ca3223e92018d86491@wordpress.org>
References: <056.cddabe8f9de9c7ca3223e92018d86491@wordpress.org>
Message-ID: <071.66c10bab27c4eff46018728b3fc9964a@wordpress.org>

#65133: Classic editor tagchecklist ui issue
------------------------------------+----------------------
 Reporter:  umesh.nevase            |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  Editor                  |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch admin-reskin  |     Focuses:  ui, css
------------------------------------+----------------------
Changes (by sabernhardt):

 * keywords:  has-patch => has-patch admin-reskin
 * focuses:  ui => ui, css
 * milestone:  Awaiting Review => 7.0


Comment:

 The 1.28 `line-height` added in [38880] does not seem appropriate since
 the `font-size` increased to 20 pixels. I think that rule and
 [https://github.com/WordPress/wordpress-
 develop/blob/8270db8c06e89784c63350dff374c4cd237cf924/src/wp-
 admin/css/common.css#L831-L832 its comment] can be removed now instead of
 editing the `line-height` for list items.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65133#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 19:30:45 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 19:30:45 -0000
Subject: [wp-trac] [WordPress Trac] #65136: Unit Tests: Add tests for
 extract_from_markers() and stop empty values being returned (was: Unit
 Tests: Add tests for extract_from_markers())
In-Reply-To: <051.8e853587131f1961043d2d9400a7594f@wordpress.org>
References: <051.8e853587131f1961043d2d9400a7594f@wordpress.org>
Message-ID: <066.445242f42dcaaf157cfab4f5d9f93698@wordpress.org>

#65136: Unit Tests: Add tests for extract_from_markers() and stop empty values
being returned
----------------------------+------------------------------
 Reporter:  pbearne         |       Owner:  (none)
     Type:  enhancement     |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:
----------------------------+------------------------------
Changes (by pbearne):

 * keywords:  has-patch has-unit-tests =>


Comment:

 In testing, I found that empty lines where beeing return in the array of
 values

 Add code to stop this

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65136#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 19:31:24 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 19:31:24 -0000
Subject: [wp-trac] [WordPress Trac] #65136: Unit Tests: Add tests for
 extract_from_markers() and stop empty values being returned
In-Reply-To: <051.8e853587131f1961043d2d9400a7594f@wordpress.org>
References: <051.8e853587131f1961043d2d9400a7594f@wordpress.org>
Message-ID: <066.77d992f0cefc20b4f4a86292f04c9538@wordpress.org>

#65136: Unit Tests: Add tests for extract_from_markers() and stop empty values
being returned
--------------------------------------+------------------------------
 Reporter:  pbearne                   |       Owner:  (none)
     Type:  enhancement               |      Status:  new
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  Administration            |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+------------------------------
Changes (by pbearne):

 * keywords:   => has-patch has-unit-tests


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65136#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 20:09:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 20:09:33 -0000
Subject: [wp-trac] [WordPress Trac] #65137: Unit Tests: Add tests for
 insert_with_markers()
Message-ID: <051.35fe86a97b94d0c3362af89adc84f898@wordpress.org>

#65137: Unit Tests: Add tests for insert_with_markers()
----------------------------+-----------------------------
 Reporter:  pbearne         |      Owner:  (none)
     Type:  enhancement     |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Administration  |    Version:
 Severity:  normal          |   Keywords:
  Focuses:                  |
----------------------------+-----------------------------
 The function insert_with_markers() in src/wp-admin/includes/misc.php lacks
 unit tests. This PR adds tests to ensure it correctly inserts or replaces
 content between markers in a file, handles file creation, permissions, and
 respects existing content outside markers.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65137>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 21:04:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 21:04:28 -0000
Subject: [wp-trac] [WordPress Trac] #65128: Warning on the post page.
In-Reply-To: <056.36dc6c1c8bcecf8876faea078501974f@wordpress.org>
References: <056.36dc6c1c8bcecf8876faea078501974f@wordpress.org>
Message-ID: <071.555b715bcd2e9427cb06f1e674ed9e64@wordpress.org>

#65128: Warning on the post page.
-----------------------------------+------------------------------
 Reporter:  gautammkgarg           |       Owner:  (none)
     Type:  defect (bug)           |      Status:  new
 Priority:  normal                 |   Milestone:  Awaiting Review
Component:  Administration         |     Version:
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |     Focuses:
-----------------------------------+------------------------------
Changes (by sabernhardt):

 * keywords:  has-patch reporter-feedback => has-patch 2nd-opinion
 * version:  trunk =>


Comment:

 WordPress added the `print_emoji_styles` and `wp_admin_bar_styles`
 deprecation notices in [56682] for plugin and theme authors to update
 their code. The new enqueuing functions remove deprecated functions from
 the `admin_head` hook within the admin, or `wp_head` on the front end.
 [56682] did not account for anyone using `wp_head()` in the admin area.

 Knit Pay calls both `wp_head()` and `wp_footer()`, which are front-end
 functions that echo output, within the `<body>` of
 [https://plugins.trac.wordpress.org/browser/knit-pay/tags/9.3.3.0/views
 /redirect-via-html-with-message.php?marks=56#L56 redirect-via-html-with-
 message.php]. The only purpose I found for this is to enqueue `jquery` and
 `knit-pay-easy-qrcode` (in [https://plugins.trac.wordpress.org/browser
 /knit-
 pay/tags/9.3.3.0/gateways/UpiQR/Gateway.php?rev=3516547&marks=50,107-108,115,205#L115
 UpiQR/Gateway.php]). However, it enqueues all the front-end styles and
 scripts, plus `<meta>` and `<link>` tags, in addition to those two
 scripts. Theoretically the plugin could use `wp_print_scripts()` instead
 of `wp_enqueue_script()`, with `knit-pay-easy-qrcode` registered in the
 `wp_print_scripts` action, but I am not sure I should recommend that.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65128#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 21:49:32 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 21:49:32 -0000
Subject: [wp-trac] [WordPress Trac] #65138: RTC: Real-time collaboration bug
 sprint for 7.0
Message-ID: <051.909ebea669937619aa3dbdcbd67aaafc@wordpress.org>

#65138: RTC: Real-time collaboration bug sprint for 7.0
-------------------------------+--------------------
 Reporter:  dmsnell            |      Owner:  (none)
     Type:  defect (bug)       |     Status:  new
 Priority:  normal             |  Milestone:  7.0
Component:  Posts, Post Types  |    Version:  trunk
 Severity:  normal             |   Keywords:
  Focuses:  tests              |
-------------------------------+--------------------
 As part of a project to uncover latent bugs using an AI-assisted fuzzer,
 this ticket is tracking work to find and address bugs in the version of
 real-time collaborative editing in WordPress 7.0.

 Work in this ticket should be addressing existing bugs and propose only
 fixes to those bugs for the 7.0 release.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65138>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 23:47:45 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 23:47:45 -0000
Subject: [wp-trac] [WordPress Trac] #65133: Classic editor tagchecklist
 ui issue
In-Reply-To: <056.cddabe8f9de9c7ca3223e92018d86491@wordpress.org>
References: <056.cddabe8f9de9c7ca3223e92018d86491@wordpress.org>
Message-ID: <071.18a28b6e957c7e182dbc9e4001a7fb8b@wordpress.org>

#65133: Classic editor tagchecklist ui issue
------------------------------------+-----------------------------
 Reporter:  umesh.nevase            |       Owner:  SergeyBiryukov
     Type:  defect (bug)            |      Status:  closed
 Priority:  normal                  |   Milestone:  7.0
Component:  Editor                  |     Version:  trunk
 Severity:  normal                  |  Resolution:  fixed
 Keywords:  has-patch admin-reskin  |     Focuses:  ui, css
------------------------------------+-----------------------------
Changes (by SergeyBiryukov):

 * owner:  (none) => SergeyBiryukov
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62279" 62279]:
 {{{
 #!CommitTicketReference repository="" revision="62279"
 Editor: Correct alignment for “Remove tag” icon in classic editor.

 Follow-up to [38880], [61645].

 Props umesh.nevase, sabernhardt, SergeyBiryukov.
 Fixes #65133.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65133#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Mon Apr 27 23:50:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Mon, 27 Apr 2026 23:50:29 -0000
Subject: [wp-trac] [WordPress Trac] #65133: Classic editor tagchecklist
 ui issue
In-Reply-To: <056.cddabe8f9de9c7ca3223e92018d86491@wordpress.org>
References: <056.cddabe8f9de9c7ca3223e92018d86491@wordpress.org>
Message-ID: <071.af8c9d39998558c10cd929e973b652ef@wordpress.org>

#65133: Classic editor tagchecklist ui issue
-------------------------------------------------+-------------------------
 Reporter:  umesh.nevase                         |       Owner:
                                                 |  SergeyBiryukov
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Editor                               |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch admin-reskin commit dev-   |     Focuses:  ui, css
  feedback                                       |
-------------------------------------------------+-------------------------
Changes (by SergeyBiryukov):

 * keywords:  has-patch admin-reskin => has-patch admin-reskin commit dev-
     feedback
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Replying to [comment:2 sabernhardt]:
 > I think that rule and [https://github.com/WordPress/wordpress-
 develop/blob/8270db8c06e89784c63350dff374c4cd237cf924/src/wp-
 admin/css/common.css#L831-L832 its comment] can be removed now instead of
 editing the `line-height` for list items.

 Thanks! In my testing, I got slightly better results by adjusting that
 rule to `line-height: 1.1`, so [62279] tries that.

 Reopening for 7.0 consideration.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65133#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 03:56:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 03:56:48 -0000
Subject: [wp-trac] [WordPress Trac] #65133: Classic editor tagchecklist
 ui issue
In-Reply-To: <056.cddabe8f9de9c7ca3223e92018d86491@wordpress.org>
References: <056.cddabe8f9de9c7ca3223e92018d86491@wordpress.org>
Message-ID: <071.03809dcb07f5a056af5079f95713a3af@wordpress.org>

#65133: Classic editor tagchecklist ui issue
-------------------------------------------------+-------------------------
 Reporter:  umesh.nevase                         |       Owner:
                                                 |  SergeyBiryukov
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Editor                               |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch admin-reskin commit dev-   |     Focuses:  ui, css
  reviewed                                       |
-------------------------------------------------+-------------------------
Changes (by peterwilsoncc):

 * keywords:  has-patch admin-reskin commit dev-feedback => has-patch admin-
     reskin commit dev-reviewed


Comment:

 r62279 approved for merge to 7.0.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65133#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 04:02:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 04:02:14 -0000
Subject: [wp-trac] [WordPress Trac] #65062: Revisions: buttons are
 misplaced
In-Reply-To: <053.b9ce602729457db6bab38d69686036f5@wordpress.org>
References: <053.b9ce602729457db6bab38d69686036f5@wordpress.org>
Message-ID: <068.b98ea935e2faee8154186632d1841ca5@wordpress.org>

#65062: Revisions: buttons are misplaced
-------------------------------------------------+-------------------------
 Reporter:  wildworks                            |       Owner:  joedolson
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Revisions                            |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch has-test-     |     Focuses:
  info dev-reviewed                              |
-------------------------------------------------+-------------------------
Changes (by peterwilsoncc):

 * keywords:  admin-reskin has-patch has-test-info dev-feedback => admin-
     reskin has-patch has-test-info dev-reviewed


Comment:

 r62273 approved for merge to the 7.0 branch.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65062#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 04:10:46 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 04:10:46 -0000
Subject: [wp-trac] [WordPress Trac] #64789: Security audit for API key
 storage on the Connectors screen
In-Reply-To: <050.2dc2adeded3d033a30689e22ac0c9ef2@wordpress.org>
References: <050.2dc2adeded3d033a30689e22ac0c9ef2@wordpress.org>
Message-ID: <065.c7096130958406e3d59e50cfc6f6297c@wordpress.org>

#64789: Security audit for API key storage on the Connectors screen
-------------------------+-------------------------------------------------
 Reporter:  gziolo       |       Owner:  (none)
     Type:  task         |      Status:  new
  (blessed)              |
 Priority:  normal       |   Milestone:  7.0
Component:  Security     |     Version:  trunk
 Severity:  normal       |  Resolution:
 Keywords:  2nd-opinion  |     Focuses:  ui, administration, rest-api,
                         |  privacy
-------------------------+-------------------------------------------------
Changes (by peterwilsoncc):

 * keywords:  2nd-opinion dev-feedback => 2nd-opinion


Comment:

 Keyword management (@dpknauss you weren't to know this but the committers
 team uses dev-feedback keyword to indicate a ticket contains a commit to
 be reviewed for backport... I know, it's confusing)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64789#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 04:13:40 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 04:13:40 -0000
Subject: [wp-trac] [WordPress Trac] #65073: Connectors: reference to AI
 plugin uses old `ai` slug instead of correct `ai-wp-admin` slug
In-Reply-To: <052.ad97c034b09747ca93f06d7293e387ff@wordpress.org>
References: <052.ad97c034b09747ca93f06d7293e387ff@wordpress.org>
Message-ID: <067.e44ae2504a358b68b9e4e1aa47375976@wordpress.org>

#65073: Connectors: reference to AI plugin uses old `ai` slug instead of correct
`ai-wp-admin` slug
------------------------------+-----------------------
 Reporter:  JeffPaul          |       Owner:  dkotter
     Type:  defect (bug)      |      Status:  assigned
 Priority:  normal            |   Milestone:  7.0
Component:  AI                |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  connectors close  |     Focuses:
------------------------------+-----------------------
Changes (by peterwilsoncc):

 * keywords:  connectors has-patch close => connectors close


Comment:

 Keyword management for workflow report.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65073#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 04:21:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 04:21:14 -0000
Subject: [wp-trac] [WordPress Trac] #64904: Real time collboration:
 determine approach for opt in setting for users in Settings > Writing
In-Reply-To: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
References: <052.0bbda23d420073a23acb5985c10fd47e@wordpress.org>
Message-ID: <067.60a3a2db20679bc5cf655aee5abb8b88@wordpress.org>

#64904: Real time collboration: determine approach for opt in setting for users in
Settings > Writing
----------------------------+--------------------------------
 Reporter:  annezazu        |       Owner:  (none)
     Type:  task (blessed)  |      Status:  new
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  needs-patch     |     Focuses:  ui, accessibility
----------------------------+--------------------------------
Changes (by peterwilsoncc):

 * keywords:  needs-design has-patch => needs-patch


Comment:

 Keyword management for workflow report: needs a new patch for the new
 design.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64904#comment:49>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 04:48:08 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 04:48:08 -0000
Subject: [wp-trac] [WordPress Trac] #65003: next/prev for enlarged image
 needs context
In-Reply-To: <052.b63525ba9b3238159791aa05ff965555@wordpress.org>
References: <052.b63525ba9b3238159791aa05ff965555@wordpress.org>
Message-ID: <067.0341fdf425e4f7953cdaad16861e45c6@wordpress.org>

#65003: next/prev for enlarged image needs context
--------------------------+---------------------
 Reporter:  timse201      |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  I18N          |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  close         |     Focuses:
--------------------------+---------------------
Changes (by peterwilsoncc):

 * keywords:  needs-patch => close


Comment:

 The upstream pull request
 [https://github.com/WordPress/gutenberg/pull/76967
 WordPress/Gutenberg#76967] has been merged to the 7.0 branch and will be
 included when the Gutenberg version included in WordPress-Develop is
 updated. Marking this ticket for close pending the GB update.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65003#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 04:50:41 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 04:50:41 -0000
Subject: [wp-trac] [WordPress Trac] #65118: Docs: Correct
 WP_Network_Query params comments
In-Reply-To: <062.bc857a5e1fc74eb71c058f3d42270cc9@wordpress.org>
References: <062.bc857a5e1fc74eb71c058f3d42270cc9@wordpress.org>
Message-ID: <077.9c34077c40beb7a4202263a04152ded1@wordpress.org>

#65118: Docs: Correct WP_Network_Query params comments
----------------------------+----------------------------------------------
 Reporter:                  |       Owner:  (none)
  baikare.sandeep007        |
     Type:  enhancement     |      Status:  new
 Priority:  normal          |   Milestone:  7.1
Component:  Networks and    |     Version:  4.6
  Sites                     |
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:  docs, administration, multisite
----------------------------+----------------------------------------------
Changes (by westonruter):

 * milestone:  Awaiting Review => 7.1


Comment:

 @baikaresandeep007 Thanks for the ticket. Would you please submit the
 patch as a pull request instead? This will facilitate review.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65118#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 04:56:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 04:56:49 -0000
Subject: [wp-trac] [WordPress Trac] #65120: Add
 `wp_elements_block_supports_class_name` filter to
 `wp_get_elements_class_name()`
In-Reply-To: <062.c5c4315f56dd742dd7ff410a88a4ea8d@wordpress.org>
References: <062.c5c4315f56dd742dd7ff410a88a4ea8d@wordpress.org>
Message-ID: <077.40204e320ff56526ad75307208acc01d@wordpress.org>

#65120: Add `wp_elements_block_supports_class_name` filter to
`wp_get_elements_class_name()`
-------------------------------------+-------------------------------------
 Reporter:  baikare.sandeep007       |       Owner:  (none)
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Editor                   |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  template, performance,
  has-test-info 2nd-opinion          |  coding-standards
-------------------------------------+-------------------------------------
Changes (by westonruter):

 * keywords:  has-patch needs-testing has-test-info => has-patch needs-
     testing has-test-info 2nd-opinion


Comment:

 I'm not sure this is a good idea. I don't see a clear need for it. Note
 where the return value of the funtion is used:

 https://github.com/WordPress/wordpress-
 develop/blob/acebfd0ac218c455d25ae9e06879bc42da18b9c9/src/wp-includes
 /block-supports/elements.php#L160-L220

 By allowing the class name to be filtered, I worry this would introduce
 breakages.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65120#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 05:24:36 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 05:24:36 -0000
Subject: [wp-trac] [WordPress Trac] #65123: Having a malformed post type
 query in $_GET or $_POST yields a critical error
In-Reply-To: <055.29dc7cdfbf1c0409285d3c1ace563536@wordpress.org>
References: <055.29dc7cdfbf1c0409285d3c1ace563536@wordpress.org>
Message-ID: <070.e200b0379bcd26b34806b32756ea92d9@wordpress.org>

#65123: Having a malformed post type query in $_GET or $_POST yields a critical
error
--------------------------------------+------------------------------
 Reporter:  hheuzebrutc               |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  Permalinks                |     Version:  6.9.4
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+------------------------------

Comment (by westonruter):

 Replying to [ticket:65123 hheuzebrutc]:
 > - Add ?attachment[foo]=bar to the url

 How did you come to add this to the URL?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65123#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 06:27:02 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 06:27:02 -0000
Subject: [wp-trac] [WordPress Trac] #64789: Security audit for API key
 storage on the Connectors screen
In-Reply-To: <050.2dc2adeded3d033a30689e22ac0c9ef2@wordpress.org>
References: <050.2dc2adeded3d033a30689e22ac0c9ef2@wordpress.org>
Message-ID: <065.9d9d3bb5f4f3e02e05ff2405f6025b30@wordpress.org>

#64789: Security audit for API key storage on the Connectors screen
-------------------------+-------------------------------------------------
 Reporter:  gziolo       |       Owner:  (none)
     Type:  task         |      Status:  new
  (blessed)              |
 Priority:  normal       |   Milestone:  7.0
Component:  Security     |     Version:  trunk
 Severity:  normal       |  Resolution:
 Keywords:  2nd-opinion  |     Focuses:  ui, administration, rest-api,
                         |  privacy
-------------------------+-------------------------------------------------

Comment (by dpknauss):

 Ah, sorry about that.

 Replying to [comment:13 peterwilsoncc]:
 > Keyword management (@dpknauss you weren't to know this but the
 committers team uses dev-feedback keyword to indicate a ticket contains a
 commit to be reviewed for backport... I know, it's confusing)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64789#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 06:43:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 06:43:49 -0000
Subject: [wp-trac] [WordPress Trac] #64948: Media Modal: Can no longer
 set attachment filters
In-Reply-To: <059.043db9fa3e3bcd837140db59ad9266de@wordpress.org>
References: <059.043db9fa3e3bcd837140db59ad9266de@wordpress.org>
Message-ID: <074.f1f1dcbd516eaec6aa034988dcde42ab@wordpress.org>

#64948: Media Modal: Can no longer set attachment filters
-----------------------------+-------------------------
 Reporter:  Bernhard Reiter  |       Owner:  joedolson
     Type:  defect (bug)     |      Status:  accepted
 Priority:  normal           |   Milestone:  7.0
Component:  Media            |     Version:  trunk
 Severity:  normal           |  Resolution:
 Keywords:  has-patch        |     Focuses:  javascript
-----------------------------+-------------------------

Comment (by darshitrajyaguru97):

 == Patch Testing Report ==

 **Patch Tested:** https://github.com/WordPress/wordpress-
 develop/pull/11415

 === Environment ===
 * WordPress: 7.1-alpha-62161-src
 * PHP: 8.2.29
 * Server: nginx/1.29.4
 * Database: MySQL
 * Browser: Chrome
 * OS: Windows
 * Theme: Twenty Twenty-Five
 * Plugins:
  1. Code Snippets 3.9.5 **
  2. Test Reports 1.2.1
 * MU Plugins: None

 === Steps to Reproduce (Before Patch) ===
 1. Add the following snippet to `functions.php` or via Code Snippets:

 {{{
 add_action( 'admin_footer', function () {
     if ( ! did_action( 'wp_enqueue_media' ) ) {
         return;
     }
     ?>
     <script>
     jQuery( document ).ready( function ( $ ) {
         if ( ! wp || ! wp.media || ! wp.media.view || !
 wp.media.view.AttachmentsBrowser ) {
             return;
         }

         var OrigBrowser = wp.media.view.AttachmentsBrowser;

         wp.media.view.AttachmentsBrowser = OrigBrowser.extend( {
             createToolbar: function () {
                 OrigBrowser.prototype.createToolbar.apply( this, arguments
 );

                 var toolbar = this.toolbar;
                 var filters = toolbar.get( 'filters' );

                 console.log( '[Ticket 64948] toolbar.get("filters"):',
 filters );
                 console.log( '[Ticket 64948] filters.filters:', filters &&
 filters.filters );

                 if ( filters && typeof filters.filters !== 'undefined' ) {
                     console.info( '[Ticket 64948] PASS: filters.filters is
 accessible.' );
                 } else {
                     console.error( '[Ticket 64948] FAIL: filters.filters
 is undefined.' );
                 }
             }
         } );
     } );
     </script>
     <?php
 } );
 }}}

 2. Open any post/page editor or Media Library
 3. Click "Add Media"
 4. Check the browser console

 === Actual Result (Before Patch) ===
 * `toolbar.get('filters')` returns an object
 * `filters.filters` is **undefined**
 * Console output:
 {{{
 FAIL: filters.filters is undefined
 }}}

 === Steps After Applying Patch ===
 1. Apply the patch from PR #11415
 2. Repeat the steps above

 === Result (After Patch) ===
 * `toolbar.get('filters')` is accessible
 * `filters.filters` is properly defined
 * Console output:
 {{{
 PASS: filters.filters is accessible
 }}}

 === Expected Result ===
 Plugins relying on `toolbar.get('filters')` should be able to access
 `filters.filters` without encountering `undefined`, ensuring backward
 compatibility for media library customizations.

 === Conclusion ===
 * ✅ Patch successfully resolves the issue
 * ✅ Restores expected behavior for plugin integrations
 * ✅ No regressions observed during testing

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64948#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 06:50:20 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 06:50:20 -0000
Subject: [wp-trac] [WordPress Trac] #65123: Having a malformed post type
 query in $_GET or $_POST yields a critical error
In-Reply-To: <055.29dc7cdfbf1c0409285d3c1ace563536@wordpress.org>
References: <055.29dc7cdfbf1c0409285d3c1ace563536@wordpress.org>
Message-ID: <070.fda2ca5dd1ae00f8324d0990861cd176@wordpress.org>

#65123: Having a malformed post type query in $_GET or $_POST yields a critical
error
--------------------------------------+------------------------------
 Reporter:  hheuzebrutc               |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  Awaiting Review
Component:  Permalinks                |     Version:  6.9.4
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+------------------------------

Comment (by hheuzebrutc):

 Well at first I wasn't touching the URL at all, as mentioned above I was
 making a custom form as a shortcode, with several input fields grouped
 together in an array that happened to have the same name as one of my
 custom post types, something like post_type[input_name]. And no matter
 what I did, WordPress Core always crashed before my form had a chance to
 be processed. I figured it was something to do with query vars and tried
 it with the URL as well. I chose attachments in my example because as far
 as I can tell, it's the only public post type that's guaranteed to do this
 on every WordPress site.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65123#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 08:19:42 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 08:19:42 -0000
Subject: [wp-trac] [WordPress Trac] #64596: Abilities API: Allow ability
 names to contain multiple slug fragments (2-4 segments)
In-Reply-To: <060.74f0d53f8f168f6d8e4740aae322ab76@wordpress.org>
References: <060.74f0d53f8f168f6d8e4740aae322ab76@wordpress.org>
Message-ID: <075.3261450849f86aff549fd7686142b776@wordpress.org>

#64596: Abilities API: Allow ability names to contain multiple slug fragments (2-4
segments)
------------------------------------------------+--------------------------
 Reporter:  jorgefilipecosta                    |       Owner:
                                                |  jorgefilipecosta
     Type:  enhancement                         |      Status:  reopened
 Priority:  normal                              |   Milestone:
Component:  Abilities API                       |     Version:  trunk
 Severity:  normal                              |  Resolution:
 Keywords:  abilities has-patch has-unit-tests  |     Focuses:
------------------------------------------------+--------------------------

Comment (by justlevine):

 @jorgefilipecosta yes please, I don't have the permissions to assign it
 myself 🙏

 Same if there's any other Abilities API tickets you no longer have time
 for and need to drop, just unassign yourself and either reassign it to me
 or leave it blank and we'll retriage and reassign it. 🙇‍♂️

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64596#comment:27>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 08:39:52 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 08:39:52 -0000
Subject: [wp-trac] [WordPress Trac] #65138: RTC: Real-time collaboration
 bug sprint for 7.0
In-Reply-To: <051.909ebea669937619aa3dbdcbd67aaafc@wordpress.org>
References: <051.909ebea669937619aa3dbdcbd67aaafc@wordpress.org>
Message-ID: <066.36f0ceb7051d5965cadc220339c179c3@wordpress.org>

#65138: RTC: Real-time collaboration bug sprint for 7.0
-------------------------------------------------+-------------------------
 Reporter:  dmsnell                              |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  7.0
Component:  Posts, Post Types                    |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests gutenberg-  |     Focuses:  tests
  merge                                          |
-------------------------------------------------+-------------------------
Changes (by wildworks):

 * keywords:  has-patch has-unit-tests => has-patch has-unit-tests
     gutenberg-merge


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65138#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 09:02:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 09:02:49 -0000
Subject: [wp-trac] [WordPress Trac] #65129: Improve maintainability of
 DOCTYPE quirks mode detection in `WP_HTML_Doctype_Info` class
In-Reply-To: <062.4222a143c45d82e1e02b722fdcd453bf@wordpress.org>
References: <062.4222a143c45d82e1e02b722fdcd453bf@wordpress.org>
Message-ID: <077.66597e18f3f683bc7785fece06a679c1@wordpress.org>

#65129: Improve maintainability of DOCTYPE quirks mode detection in
`WP_HTML_Doctype_Info` class
-------------------------------------------+-------------------------------
 Reporter:  baikare.sandeep007             |       Owner:  (none)
     Type:  enhancement                    |      Status:  new
 Priority:  normal                         |   Milestone:  Awaiting Review
Component:  HTML API                       |     Version:  6.7
 Severity:  normal                         |  Resolution:
 Keywords:  has-patch needs-testing close  |     Focuses:  coding-standards
-------------------------------------------+-------------------------------
Changes (by jonsurrell):

 * keywords:  has-patch needs-testing => has-patch needs-testing close


Comment:

 Hi @baikaresandeep007, thanks for your interest in the HTML API and this
 contribution!

 These seems to be a refactor with no intentional behavior changes. The
 arguments in favor of this refactor are fairly subjective and I don't
 think change meets the
 [https://make.wordpress.org/core/handbook/contribute/code-refactoring/
 guidelines around refactoring]. The performance impact is unclear and the
 PR notes that this is unlikely to be a hotspot. The impact on
 maintainability of this block also seems highly subjective.

 I'll recommend this for closure but leave it open for feedback or other
 opinions.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65129#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 09:04:15 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 09:04:15 -0000
Subject: [wp-trac] [WordPress Trac] #65117: Proposal: Hook Permissions
 Layer
In-Reply-To: <058.1dbd21cd15065ddb6712c145e34a008f@wordpress.org>
References: <058.1dbd21cd15065ddb6712c145e34a008f@wordpress.org>
Message-ID: <073.b9a39f4c2d6d7b81ced1184ff42199c4@wordpress.org>

#65117: Proposal: Hook Permissions Layer
---------------------------------------+------------------------------
 Reporter:  namith.jawahar             |       Owner:  (none)
     Type:  feature request            |      Status:  new
 Priority:  normal                     |   Milestone:  Awaiting Review
Component:  Plugins                    |     Version:
 Severity:  normal                     |  Resolution:
 Keywords:  has-screenshots has-patch  |     Focuses:
---------------------------------------+------------------------------

Comment (by aravindajith):

 This is an interesting and well thought out proposal. The problem is real,
 especially for teams using WordPress as an application platform.

 That said, the scope feels quite large for core. It combines tracking,
 scanning, permissions, UI, and update-time checks into a single system.

 A few concerns:

 * The main value seems to be in controlled environments (SaaS,
 enterprise). For typical sites, unrestricted hooks are often a feature.
 * Blocking new hooks on plugin updates could lead to unexpected breakages
 that are hard to debug.
 * Static scanning may miss dynamic hooks, while runtime tracking adds
 overhead.
 * The UI and concept of “disabling hooks” may be difficult for non-
 technical users to reason about.

 It might be worth exploring a more incremental approach, starting with
 better visibility into hook usage and lighter, opt-in controls for
 sensitive hooks.

 Overall, this feels like a strong direction, but possibly better
 introduced in smaller steps.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65117#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 09:15:20 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 09:15:20 -0000
Subject: [wp-trac] [WordPress Trac] #65014: Site Health: Error icon
 missing due to missing dashicons class
In-Reply-To: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
References: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
Message-ID: <069.c17c8d3590fd1b3322d79b75c0fedaa3@wordpress.org>

#65014: Site Health: Error icon missing due to missing dashicons class
-------------------------------------+-------------------------------------
 Reporter:  valani9099               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  7.1
Component:  Site Health              |     Version:  5.3
 Severity:  normal                   |  Resolution:
 Keywords:  has-screenshots has-     |     Focuses:  ui, css,
  patch                              |  administration
-------------------------------------+-------------------------------------

Comment (by wildworks):

 Replying to [comment:11 valani9099]:


 > Just curious — since WordPress 7.0 release seems to be delayed, is there
 any chance this fix could still be included in 7.0, or will it be targeted
 for 7.1 once trunk reopens? Happy to wait and assist with any further
 testing if needed!

 This bug is not new to 7.0, so it probably doesn't need to be included.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65014#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 09:56:20 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 09:56:20 -0000
Subject: [wp-trac] [WordPress Trac] #65086: Add action hooks to media
 modal attachment details templates for field extensibility
In-Reply-To: <054.7fabfdfcb46f5e6537471a8076c5d178@wordpress.org>
References: <054.7fabfdfcb46f5e6537471a8076c5d178@wordpress.org>
Message-ID: <069.a5bb0eaefc95f2c1e8ac97bf13c01d70@wordpress.org>

#65086: Add action hooks to media modal attachment details templates for field
extensibility
-------------------------+------------------------------
 Reporter:  kaavyaiyer   |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Media        |     Version:
 Severity:  normal       |  Resolution:
 Keywords:               |     Focuses:
-------------------------+------------------------------

Comment (by darshitrajyaguru97):

 This is a great initiative and clearly needed, especially with AI-powered
 features like alt text generation.

 One important consideration: since the attachment details UI is rendered
 via Backbone templates (`media-template.php`), traditional PHP action
 hooks (`do_action`) won’t be effective inside `<script type="text/html">`
 blocks.

 A more robust approach could be introducing JavaScript-based extensibility
 points using `wp.hooks`, for example:

 {{{
 wp.hooks.doAction(
   'media_attachment_field_after',
   'alt',
   view,
   model
 );
 }}}

 Additionally, field-specific hooks (e.g.,
 `media_attachment_field_after_alt`,
 `media_attachment_field_before_caption`) would provide more granular
 control and avoid reliance on DOM querying.

 As an alternative or fallback, Core could introduce dedicated placeholder
 containers within templates (e.g., `.media-field-hook-alt`) to allow safe
 UI injection without fragile DOM manipulation.

 This approach would:

 * Avoid performance overhead from runtime DOM mutations
 * Provide a stable API for plugins
 * Align well with AI-driven enhancements like alt text, caption, and title
 generation

 Starting with the media modal makes sense, and this pattern could later
 extend to other admin UI areas where contextual field-level extensibility
 is needed.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65086#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 10:10:50 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 10:10:50 -0000
Subject: [wp-trac] [WordPress Trac] #64581: Allow serialized options
 read-only view
In-Reply-To: <058.f1d9275e6fa261c8f0ee15f97bd26266@wordpress.org>
References: <058.f1d9275e6fa261c8f0ee15f97bd26266@wordpress.org>
Message-ID: <073.a5f6e8228a15fa55b3b6b448c9659ca3@wordpress.org>

#64581: Allow serialized options read-only view
-------------------------------------------------+-------------------------
 Reporter:  anatolinicolae                       |       Owner:  (none)
     Type:  feature request                      |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Options, Meta APIs                   |     Version:  trunk
 Severity:  trivial                              |  Resolution:
 Keywords:  has-patch has-screenshots needs-     |     Focuses:  ui,
  testing                                        |  administration
-------------------------------------------------+-------------------------
Changes (by anatolinicolae):

 * keywords:  has-patch has-screenshots => has-patch has-screenshots needs-
     testing


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64581#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 10:26:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 10:26:06 -0000
Subject: [wp-trac] [WordPress Trac] #65139: Image Box widget link applies
 only to image, not entire content
Message-ID: <058.4bd12143707d4138be836b24f5e8d9eb@wordpress.org>

#65139: Image Box widget link applies only to image, not entire content
----------------------------+-----------------------------
 Reporter:  dharmikpatel97  |      Owner:  (none)
     Type:  defect (bug)    |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Widgets         |    Version:
 Severity:  normal          |   Keywords:
  Focuses:                  |
----------------------------+-----------------------------
 When using the Image Box widget in Elementor, adding a link only wraps the
 image element (<img>), while the title and description remain outside the
 anchor tag.

 As a result, only the image/icon is clickable, while the associated text
 content (title and description) is not. This leads to inconsistent user
 experience and reduced usability, especially in cases where the entire
 element is expected to function as a single clickable block (e.g., contact
 information such as email or phone).

 This behavior can be confusing for users, as the visual design suggests
 that the full component is interactive, but only a small portion (the
 image) actually responds to clicks.

 [[Image(https://olpadcomics.com/wp-content/uploads/2026/04/image-1.png)]]
 [[Image(https://olpadcomics.com/wp-content/uploads/2026/04/image-2.png)]]
 [[Image(https://olpadcomics.com/wp-content/uploads/2026/04/image-3.png)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65139>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 10:28:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 10:28:28 -0000
Subject: [wp-trac] [WordPress Trac] #65139: Image Box widget link
 applies only to image, not entire content
In-Reply-To: <058.4bd12143707d4138be836b24f5e8d9eb@wordpress.org>
References: <058.4bd12143707d4138be836b24f5e8d9eb@wordpress.org>
Message-ID: <073.79a3c5c75251daeff4eb8dfd0303292b@wordpress.org>

#65139: Image Box widget link applies only to image, not entire content
----------------------------+------------------------------
 Reporter:  dharmikpatel97  |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Widgets         |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:
----------------------------+------------------------------
Changes (by dharmikpatel97):

 * Attachment "New Project.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65139>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 10:57:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 10:57:16 -0000
Subject: [wp-trac] [WordPress Trac] #65140: Toolbar: Icon color is
 inncorrect in mobile layout
Message-ID: <053.6248a4acdfd28154e0622c885840600c@wordpress.org>

#65140: Toolbar: Icon color is inncorrect in mobile layout
--------------------------+-----------------------------
 Reporter:  wildworks     |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Toolbar       |    Version:  4.3
 Severity:  normal        |   Keywords:
  Focuses:  ui            |
--------------------------+-----------------------------
 Props to @peterwilsoncc, who first noticed this problem.


 On mobile layouts, the toolbar icon colors appear to be incorrect.

 This change was made by [33284], but it seems to me that the default and
 hover colors were inverted and committed by mistake.

 This issue occurs with any color scheme other than the legacy default
 (Fresh). It might be worth fixing in the 7.0 release, as it will be more
 noticeable in WordPress 7.0, where the modern color becomes the default.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65140>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 11:11:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 11:11:31 -0000
Subject: [wp-trac] [WordPress Trac] #65141: Fix alignment for sortable
 metabox on post and page edit screen with classic editor
Message-ID: <056.a2041e2c35d0005f2c335a081657df6e@wordpress.org>

#65141: Fix alignment for sortable metabox on post and page edit screen with
classic editor
--------------------------+-----------------------------
 Reporter:  umesh.nevase  |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Editor        |    Version:  trunk
 Severity:  normal        |   Keywords:
  Focuses:  ui            |
--------------------------+-----------------------------
 When the Classic Editor is selected as the default editor in the Writing
 Settings, the sortable metabox container on the post/page edit screen
 includes an extra 4px of padding. This results in a 4px misalignment of
 the metabox container with Classic Editor and other UI elements on the
 page.
 Debugging confirms that this padding is only applied when the Classic
 Editor is active. Since it serves no identifiable purpose other than for
 these metaboxes, it can be safely removed to restore alignment. This
 change was originally introduced in Changeset
 [https://core.trac.wordpress.org/changeset/61646].

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65141>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 11:12:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 11:12:26 -0000
Subject: [wp-trac] [WordPress Trac] #65141: Fix alignment for sortable
 metabox on post and page edit screen with classic editor
In-Reply-To: <056.a2041e2c35d0005f2c335a081657df6e@wordpress.org>
References: <056.a2041e2c35d0005f2c335a081657df6e@wordpress.org>
Message-ID: <071.10e42d0afb81ae865b4a9136867ab2c6@wordpress.org>

#65141: Fix alignment for sortable metabox on post and page edit screen with
classic editor
--------------------------+------------------------------
 Reporter:  umesh.nevase  |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  ui
--------------------------+------------------------------
Changes (by umesh.nevase):

 * Attachment "post-screen-alignemnt2.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65141>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 11:12:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 11:12:31 -0000
Subject: [wp-trac] [WordPress Trac] #65141: Fix alignment for sortable
 metabox on post and page edit screen with classic editor
In-Reply-To: <056.a2041e2c35d0005f2c335a081657df6e@wordpress.org>
References: <056.a2041e2c35d0005f2c335a081657df6e@wordpress.org>
Message-ID: <071.0001718c301cefbbe1e8281e181ae72a@wordpress.org>

#65141: Fix alignment for sortable metabox on post and page edit screen with
classic editor
--------------------------+------------------------------
 Reporter:  umesh.nevase  |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  ui
--------------------------+------------------------------
Changes (by umesh.nevase):

 * Attachment "post-screen-alignemnt2.2.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65141>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 11:19:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 11:19:22 -0000
Subject: [wp-trac] [WordPress Trac] #65141: Fix alignment for sortable
 metabox on post and page edit screen with classic editor
In-Reply-To: <056.a2041e2c35d0005f2c335a081657df6e@wordpress.org>
References: <056.a2041e2c35d0005f2c335a081657df6e@wordpress.org>
Message-ID: <071.5356a6233db5a23a8c7fd6abd6c997d9@wordpress.org>

#65141: Fix alignment for sortable metabox on post and page edit screen with
classic editor
--------------------------+------------------------------
 Reporter:  umesh.nevase  |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Editor        |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  ui
--------------------------+------------------------------
Changes (by umesh.nevase):

 * Attachment "post-screen-alignemnt3.png" added.

 screenshot for extra padding and misalignment

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65141>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 11:22:46 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 11:22:46 -0000
Subject: [wp-trac] [WordPress Trac] #65062: Revisions: buttons are
 misplaced
In-Reply-To: <053.b9ce602729457db6bab38d69686036f5@wordpress.org>
References: <053.b9ce602729457db6bab38d69686036f5@wordpress.org>
Message-ID: <068.47b1c7c30e8d33880e7c47153209ce21@wordpress.org>

#65062: Revisions: buttons are misplaced
-------------------------------------------------+-------------------------
 Reporter:  wildworks                            |       Owner:  joedolson
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  Revisions                            |     Version:
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  admin-reskin has-patch has-test-     |     Focuses:
  info dev-reviewed                              |
-------------------------------------------------+-------------------------
Changes (by wildworks):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62280" 62280]:
 {{{
 #!CommitTicketReference repository="" revision="62280"
 Revisions: Fix misplaced buttons in comparison UI.

 Align the Previous, Next, and Restore This Revision buttons consistently
 across viewports on the revisions comparison screen.

 Reviewed by peterwilsoncc.
 Merges [62273] to the 7.0 branch.

 Props audrasjb, mokshasharmila13, peterwilsoncc, presskopp, shailu25,
 wildworks.
 Fixes #65062.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65062#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 11:35:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 11:35:13 -0000
Subject: [wp-trac] [WordPress Trac] #65131: Administration: Spinners are
 misaligned
In-Reply-To: <053.8909cf9fe91d2de421593bc947a3a237@wordpress.org>
References: <053.8909cf9fe91d2de421593bc947a3a237@wordpress.org>
Message-ID: <068.9feda5e9cec1f23273d9f753272770a4@wordpress.org>

#65131: Administration: Spinners are misaligned
------------------------------------+---------------------
 Reporter:  wildworks               |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  Administration          |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  admin-reskin has-patch  |     Focuses:  ui
------------------------------------+---------------------

Comment (by darshitrajyaguru97):

 == Patch Testing Report ==

 * Patch Tested: https://github.com/WordPress/wordpress-develop/pull/11649

 === **Environment ===
 * WordPress: 7.0-RC2
 * PHP: 8.2.29
 * Web server: Apache
 * Database: MySQL
 * Browser: Chrome
 * OS: Windows

 === **Active Plugins ===
 * AI
 * AI Provider for Google
 * AI Provider for OpenAI

 === **Steps to Reproduce ===
 # Before applying the patch, tested the admin screens.
 # Observed that the button spinners were misaligned.
 # Applied the patch.
 # Retested the same admin screens.

 === **Results ===
 * Button spinners are now correctly aligned in the required areas after
 applying the patch.

 === **Conclusion ===
 * The patch works as expected and successfully resolves the issue of
 misaligned button spinners.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65131#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 11:44:12 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 11:44:12 -0000
Subject: [wp-trac] [WordPress Trac] #65032: View transition admin bar
 quirks
In-Reply-To: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
References: <052.d3976b04de79bffe571991b0af018a96@wordpress.org>
Message-ID: <067.86fe7467462f6829330d8205995142db@wordpress.org>

#65032: View transition admin bar quirks
----------------------------+------------------------
 Reporter:  zieladam        |       Owner:  audrasjb
     Type:  defect (bug)    |      Status:  reviewing
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:  ui
----------------------------+------------------------

Comment (by darshitrajyaguru97):

 == Test Report ==

 === Description ===
 ✅ This report validates that the indicated patch works as expected in a
 different PHP environment.

 * Patch tested: https://github.com/WordPress/wordpress-develop/pull/11582

 === Environment ===
 * WordPress: 7.1-alpha-20260416.035027
 * PHP: 7.4.33
 * Server: Apache
 * Database: MySQL
 * Browser: Chrome
 * OS: Windows
 * Theme: Twenty Twenty-Five
 * MU Plugins: None activated

 === Steps to Test ===
 # Applied the patch
 # Navigated between admin pages with similar sidebars (Dashboard → Posts →
 Pages)
 # Observed the sidebar during navigation transitions

 === Actual Results ===
 ✅ Issue resolved with the patch.
 * The admin sidebar remains visually stable during navigation.

 === Expected Results ===
 * The admin sidebar should remain visually stable during navigation.

 === Conclusion ===
 * The patch works as expected on PHP 8.2
 * Confirms compatibility beyond the originally tested PHP 7.4 environment

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65032#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 11:55:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 11:55:17 -0000
Subject: [wp-trac] [WordPress Trac] #64762: Frontend admin toolbar not
 using updated admin color scheme
In-Reply-To: <059.0e31afc455ee11847f5a061f732569ee@wordpress.org>
References: <059.0e31afc455ee11847f5a061f732569ee@wordpress.org>
Message-ID: <074.137f04df0be7a4b5386cf716ed1c97df@wordpress.org>

#64762: Frontend admin toolbar not using updated admin color scheme
-------------------------------------------------+-------------------------
 Reporter:  huzaifaalmesbah                      |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Toolbar                              |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-screenshots admin-reskin has-    |     Focuses:  ui, css
  patch has-unit-tests                           |
-------------------------------------------------+-------------------------

Comment (by darshitrajyaguru97):

 == Patch Testing Report ==

 * Patch Tested: https://github.com/WordPress/wordpress-develop/pull/11354

 === **Description ===
 Tested the fix for the admin toolbar color scheme not applying correctly
 on the frontend.

 === **Environment ===
 * WordPress: 7.1-alpha-20260416.035027
 * PHP: 8.2.29
 * Server: Apache
 * Database: MySQL
 * Browser: Chrome
 * OS: Windows
 * Theme: Twenty Twenty-Five
 * MU Plugins: None activated

 === **Steps to Test ===
 # Set a custom admin color scheme from user profile
 # Visit the frontend of the site while logged in
 # Observe the admin toolbar styling

 === **Results ===
 ✅ Patch is working as expected
 * Admin toolbar correctly reflects the selected admin color scheme on the
 frontend
 * No visual inconsistencies observed

 === **Expected Result ===
 * Frontend admin toolbar should match the selected admin color scheme

 === **Conclusion ===
 * Patch successfully resolves the issue
 * Verified working on PHP 8.2 environment as well

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64762#comment:47>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 12:59:15 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 12:59:15 -0000
Subject: [wp-trac] [WordPress Trac] #65084: Update error message for
 disallowed username characters
In-Reply-To: <049.08ea48590412276562d442dabf255033@wordpress.org>
References: <049.08ea48590412276562d442dabf255033@wordpress.org>
Message-ID: <064.72df83e98bccc71215a41c9e91ddef41@wordpress.org>

#65084: Update error message for disallowed username characters
-------------------------------------------------+-------------------------
 Reporter:  Marc4                                |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  General                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch reporter-feedback has-     |     Focuses:  ui-copy
  unit-tests                                     |
-------------------------------------------------+-------------------------

Comment (by shreyasikhar26):

 Created another PR here: https://github.com/WordPress/wordpress-
 develop/pull/11668

 Since earlier PR was missing some cases, my PR will be covering it.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65084#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 13:00:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 13:00:07 -0000
Subject: [wp-trac] [WordPress Trac] #65084: Update error message for
 disallowed username characters
In-Reply-To: <049.08ea48590412276562d442dabf255033@wordpress.org>
References: <049.08ea48590412276562d442dabf255033@wordpress.org>
Message-ID: <064.442dc3786bb2ae95c1e241e678e948ad@wordpress.org>

#65084: Update error message for disallowed username characters
-------------------------------------------------+-------------------------
 Reporter:  Marc4                                |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  General                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch reporter-feedback has-     |     Focuses:  ui-copy
  unit-tests needs-refresh                       |
-------------------------------------------------+-------------------------
Changes (by shreyasikhar26):

 * keywords:  has-patch reporter-feedback has-unit-tests => has-patch
     reporter-feedback has-unit-tests needs-refresh


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65084#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 15:00:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 15:00:17 -0000
Subject: [wp-trac] [WordPress Trac] #65139: Image Box widget link
 applies only to image, not entire content
In-Reply-To: <058.4bd12143707d4138be836b24f5e8d9eb@wordpress.org>
References: <058.4bd12143707d4138be836b24f5e8d9eb@wordpress.org>
Message-ID: <073.3de3bc92094706f6f6f498c688f32391@wordpress.org>

#65139: Image Box widget link applies only to image, not entire content
----------------------------+----------------------
 Reporter:  dharmikpatel97  |       Owner:  (none)
     Type:  defect (bug)    |      Status:  closed
 Priority:  normal          |   Milestone:
Component:  Widgets         |     Version:
 Severity:  normal          |  Resolution:  invalid
 Keywords:                  |     Focuses:
----------------------------+----------------------
Changes (by sabernhardt):

 * status:  new => closed
 * resolution:   => invalid
 * milestone:  Awaiting Review =>


Comment:

 Hi and welcome to WordPress Core Trac!

 Elementor had a feature request for linking the full Image Box widget:
 https://github.com/elementor/elementor/issues/5650

 I'll close this as invalid because it does not relate to WordPress Core.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65139#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 15:06:58 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 15:06:58 -0000
Subject: [wp-trac] [WordPress Trac] #65123: Having a malformed post type
 query in $_GET or $_POST yields a critical error
In-Reply-To: <055.29dc7cdfbf1c0409285d3c1ace563536@wordpress.org>
References: <055.29dc7cdfbf1c0409285d3c1ace563536@wordpress.org>
Message-ID: <070.eb33e88a5e6a0e4e16592fdbbd0f8a65@wordpress.org>

#65123: Having a malformed post type query in $_GET or $_POST yields a critical
error
--------------------------------------+---------------------
 Reporter:  hheuzebrutc               |       Owner:  (none)
     Type:  defect (bug)              |      Status:  new
 Priority:  normal                    |   Milestone:  7.1
Component:  Permalinks                |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------
Changes (by westonruter):

 * version:  6.9.4 =>
 * milestone:  Awaiting Review => 7.1


Comment:

 It is worth hardening what is passed from input vars.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65123#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 15:09:19 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 15:09:19 -0000
Subject: [wp-trac] [WordPress Trac] #65142: Round editor `.postbox`
 containers to match WP 7.0 dashboard widgets
Message-ID: <049.9f0e828134d257593d129261312e2acb@wordpress.org>

#65142: Round editor `.postbox` containers to match WP 7.0 dashboard widgets
----------------------------+-----------------------------
 Reporter:  jillq           |      Owner:  (none)
     Type:  enhancement     |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Administration  |    Version:
 Severity:  normal          |   Keywords:
  Focuses:  ui, css         |
----------------------------+-----------------------------
 == Background ==

 WordPress 7.0's admin visual reskin (#64308) introduced an 8px {{{border-
 radius}}} ({{{$radius-l}}}) on dashboard widgets via {{{#dashboard-widgets
 .postbox}}} (see #64549). This modernized the dashboard's appearance
 alongside the rest of the 7.0 reskin — the new Modern color scheme as
 default, taller form elements, 2px radii on buttons and inputs, and so on.

 However, the same {{{.postbox}}} class is used extensively outside the
 dashboard: editor screens for Posts, Pages, Media, Users, custom post
 types, plus every plugin that adds meta boxes (WooCommerce, Yoast,
 Jetpack, ACF, etc.). These retained their square corners.

 The result is a split-personality admin:

  * '''Dashboard:''' rounded, modern-feeling
  * '''Every editor screen, including Edit Media:''' square, dated-feeling

 This is especially visible for plugin authors: a plugin-added meta box on
 an edit screen looks markedly different from a core dashboard widget, even
 though both use {{{.postbox}}}.

 == Problem ==

 Plugins and themes that want to align with WP 7.0's modernized visual
 language currently have three suboptimal choices when it comes to meta
 boxes:

  1. '''Hardcode the values in plugin CSS''' — brittle, silently drifts
 when Core updates the token values, and creates visible inconsistency with
 neighbouring Core screens.
  2. '''Scope the override to plugin-owned screens only''' — fixes the
 plugin's screens but ''widens'' the inconsistency (plugin-screen meta
 boxes look different from core-screen meta boxes using the same class).
  3. '''Don't align''' — fragments the admin visual experience.

 == Proposal ==

 Round editor {{{.postbox}}} containers to 8px, matching the dashboard
 widget pattern already shipped in 7.0. In {{{src/wp-
 admin/css/common.css}}}:

 {{{
 #!css
 .postbox {
     border-radius: $radius-l; /* 8px — matches #dashboard-widgets .postbox
 */
     overflow: hidden; /* clip internal full-width elements (tab sidebars,
 action bars) */
 }
 }}}

 Sites that already rely on the token system introduced in
 {{{_tokens.scss}}} can reference {{{$radius-l}}} directly. Plugins like
 WooCommerce can then remove their scoped bridge styles.

 == Scope considerations ==

  * Some {{{.postbox}}} instances contain full-width children (tab sidebars
 in WP-admin like the product data panel, the {{{#major-publishing-
 actions}}} action bar at the bottom of the publish meta box) that extend
 to the container edge. Adding {{{overflow: hidden}}} to {{{.postbox}}}
 clips these cleanly to the rounded corners. This pattern was verified in
 production via [https://github.com/woocommerce/woocommerce/pull/64191
 woocommerce/woocommerce#64191] (merged commit
 [https://github.com/woocommerce/woocommerce/commit/19868f14bfc659213cb6bedd7e1f37b139a84841
 19868f1]).
  * Inner collapsible panels (e.g. WooCommerce's attributes/variations
 panels using {{{.wc-metabox.postbox}}}) should remain square. Plugins
 handle this on their side since it's plugin-specific markup.
  * The historical #17284 ({{{#major-publishing-actions}}} missing
 {{{border-radius}}}, from 2011) and #18657 ({{{.postbox .hndle}}} in
 backend needs {{{border-radius}}}, also from 2011) flagged related
 clipping issues back when admin postboxes had a 3px radius. The
 {{{overflow: hidden}}} approach proposed here resolves that whole class of
 problem in one place.

 == Benefits ==

  * '''Consistency''' — one visual language across dashboard and editor
 screens.
  * '''Plugins align for free''' — no scoped overrides, no drift when Core
 updates the token.
  * '''Low risk''' — CSS-only, additive, extends a pattern already shipped
 in 7.0.
  * '''Reduces plugin-side maintenance''' — WooCommerce, Yoast, and any
 other plugin shipping scoped fixes can remove them.

 == Prior art ==

  * #64308 — WP 7.0 admin reskin (introduced the radius on dashboard
 widgets).
  * #64549 — Card and container styles, which added the 8px radius to
 dashboard widgets specifically.
  * #65085 — proposal to expose admin design tokens as CSS custom
 properties. If both land, the bridge-style CSS in plugin codebases becomes
 unnecessary.
  * #17284, #18657 — older tickets that surfaced clipping behaviour at the
 postbox edge.

 == Related ==

 WooCommerce shipped [https://github.com/woocommerce/woocommerce/pull/64191
 woocommerce/woocommerce#64191] (merged April 27, 2026 — commit
 [https://github.com/woocommerce/woocommerce/commit/19868f14bfc659213cb6bedd7e1f37b139a84841
 19868f1]) as a scoped bridge — it rounds meta boxes on WooCommerce-owned
 editor screens only ({{{post-type-product}}}, {{{post-type-shop_order}}},
 {{{post-type-shop_coupon}}}, {{{woocommerce_page_wc-orders}}}), with a
 {{{TODO}}} comment tying back to this ticket. If this lands, that bridge
 CSS can be removed in its entirety, and editor meta boxes will be visually
 consistent across core and every plugin.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65142>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 15:27:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 15:27:06 -0000
Subject: [wp-trac] [WordPress Trac] #65143: Add polyfill for PHP 8.6's
 clamp() function
Message-ID: <049.bfe1585db563ebd1d079384363f22ec8@wordpress.org>

#65143: Add polyfill for PHP 8.6's clamp() function
-------------------------------+-----------------------------
 Reporter:  Soean              |      Owner:  (none)
     Type:  enhancement        |     Status:  new
 Priority:  normal             |  Milestone:  Awaiting Review
Component:  General            |    Version:
 Severity:  normal             |   Keywords:
  Focuses:  php-compatibility  |
-------------------------------+-----------------------------
 PHP 8.6 introduces a new built-in `clamp()` function
 ([https://wiki.php.net/rfc/clamp RFC]) that clamps a value within a given
 range. If the value is within bounds, it is returned as-is; otherwise, the
 nearest bound is returned.

 Since WordPress supports PHP 7.4 and above a polyfill is needed so
 WordPress and plugins can safely use `clamp()` without checking the PHP
 version.

 === Proposed Behavior ===

  * If `$value` is within `[$min, $max]`, returns `$value`.
  * If `$value > $max`, returns `$max`.
  * If `$value < $min`, returns `$min`.
  * Throws `ValueError` (PHP >= 8.0) or `InvalidArgumentException` (PHP
 7.x) if `$min > $max` or if `$min`/`$max` is `NAN`.

 The polyfill relies on a new private helper `_wp_throw_value_error()`,
 which conditionally throws `ValueError` on PHP >= 8.0 and falls back to
 `InvalidArgumentException` on PHP 7.x — consistent with how
 [https://github.com/symfony/polyfill-php86 Symfony] handles the same
 compatibility problem.

 === Usage Examples ===

 {{{
 clamp( 5, 0, 100 );   // 5
 clamp( -5, 0, 100 );  // 0
 clamp( 105, 0, 100 ); // 100

 clamp( 3.14, 0, 20 );  // 3.14
 clamp( 3.14, 10, 20 ); // 10

 clamp( 'P', 'A', 'Z' ); // "P"
 clamp( 'P', 'X', 'Z' ); // "X"

 clamp( new DateTimeImmutable('2026-01-08'), new
 DateTimeImmutable('2026-01-01'), new DateTimeImmutable('2026-12-31') );
 // DateTimeImmutable('2026-01-08')

 clamp( 4, NAN, 6 ); // ValueError: clamp(): Argument #2 ($min) cannot be
 NAN
 clamp( 4, 8, 6 );   // ValueError: clamp(): Argument #2 ($min) must be
 smaller than or equal to argument #3 ($max)
 }}}

 === Changes ===

  * `src/wp-includes/compat.php`: Add `_wp_throw_value_error()` helper and
 `clamp()` polyfill.

 === References ===

  * PHP RFC: https://wiki.php.net/rfc/clamp
  * PHP implementation PR: https://github.com/php/php-src/pull/19434
  * Symfony polyfill reference: https://github.com/symfony/polyfill-php86

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65143>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 15:55:42 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 15:55:42 -0000
Subject: [wp-trac] [WordPress Trac] #62819: Twenty Fourteen: Latest
 Comments block font-size does not change with user settings
In-Reply-To: <060.7d514c752ccbbc429a7452cb86525dfe@wordpress.org>
References: <060.7d514c752ccbbc429a7452cb86525dfe@wordpress.org>
Message-ID: <075.590072af01bcdddb4c59001ca9d1626c@wordpress.org>

#62819: Twenty Fourteen: Latest Comments block font-size does not change with user
settings
--------------------------------------------------+---------------------
 Reporter:  nidhidhandhukiya                      |       Owner:  (none)
     Type:  defect (bug)                          |      Status:  new
 Priority:  normal                                |   Milestone:  7.1
Component:  Bundled Theme                         |     Version:
 Severity:  normal                                |  Resolution:
 Keywords:  has-patch dev-feedback needs-testing  |     Focuses:  css
--------------------------------------------------+---------------------
Changes (by ozgursar):

 * Attachment "before.jpg" added.

 Before patch

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62819>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 15:56:02 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 15:56:02 -0000
Subject: [wp-trac] [WordPress Trac] #62819: Twenty Fourteen: Latest
 Comments block font-size does not change with user settings
In-Reply-To: <060.7d514c752ccbbc429a7452cb86525dfe@wordpress.org>
References: <060.7d514c752ccbbc429a7452cb86525dfe@wordpress.org>
Message-ID: <075.ebde1af2556dd424cc96ca96b580cd84@wordpress.org>

#62819: Twenty Fourteen: Latest Comments block font-size does not change with user
settings
--------------------------------------------------+---------------------
 Reporter:  nidhidhandhukiya                      |       Owner:  (none)
     Type:  defect (bug)                          |      Status:  new
 Priority:  normal                                |   Milestone:  7.1
Component:  Bundled Theme                         |     Version:
 Severity:  normal                                |  Resolution:
 Keywords:  has-patch dev-feedback needs-testing  |     Focuses:  css
--------------------------------------------------+---------------------
Changes (by ozgursar):

 * Attachment "after.jpg" added.

 After patch

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62819>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 15:59:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 15:59:17 -0000
Subject: [wp-trac] [WordPress Trac] #62819: Twenty Fourteen: Latest
 Comments block font-size does not change with user settings
In-Reply-To: <060.7d514c752ccbbc429a7452cb86525dfe@wordpress.org>
References: <060.7d514c752ccbbc429a7452cb86525dfe@wordpress.org>
Message-ID: <075.6155e47de9ee1e89045a1afd2e774855@wordpress.org>

#62819: Twenty Fourteen: Latest Comments block font-size does not change with user
settings
------------------------------------+---------------------
 Reporter:  nidhidhandhukiya        |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  7.1
Component:  Bundled Theme           |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:  css
------------------------------------+---------------------
Changes (by ozgursar):

 * keywords:  has-patch dev-feedback needs-testing => has-patch dev-feedback


Comment:

 == Patch Testing Report

 Patch Tested:
 https://core.trac.wordpress.org/attachment/ticket/62819/62819.2.patch

 === Environment
 - WordPress: 7.1-alpha-62161-src
 - PHP: 8.2.29
 - Server: nginx/1.29.4
 - Database: mysqli (Server: 8.4.7 / Client: mysqlnd 8.2.29)
 - Browser: Opera
 - OS: macOS
 - Theme: Twenty Fourteen 4.4
 - MU Plugins: None activated
 - Plugins:
   * Test Reports 1.2.1

 === Steps taken
 1. Create a new post
 2. Add `Latest Comments` block
 3. Try changing font size
 4. Observe that both in the editor and at the frontend font sizes fail to
 change.
 5. Apply the patch
 6. Repeat steps 3-4 and observe that both editor and frontend displays the
 selected font size
 7. ✅ Patch is solving the problem

 === Expected result
 - Font size changes should be displayed properly in editor and the
 frontend.

 === Screenshots/Screencast with results
 Before
 [[Image(https://core.trac.wordpress.org/raw-
 attachment/ticket/62819/before.jpg)]]

 After
 [[Image(https://core.trac.wordpress.org/raw-
 attachment/ticket/62819/after.jpg)]]

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/62819#comment:22>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 16:02:20 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 16:02:20 -0000
Subject: [wp-trac] [WordPress Trac] #65014: Site Health: Error icon
 missing due to missing dashicons class
In-Reply-To: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
References: <054.a98383f6bf5540bd886fd14c7bf8b7a2@wordpress.org>
Message-ID: <069.4f027e0d0fe180bebec636f0a1318064@wordpress.org>

#65014: Site Health: Error icon missing due to missing dashicons class
-------------------------------------+-------------------------------------
 Reporter:  valani9099               |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  7.1
Component:  Site Health              |     Version:  5.3
 Severity:  normal                   |  Resolution:
 Keywords:  has-screenshots has-     |     Focuses:  ui, css,
  patch                              |  administration
-------------------------------------+-------------------------------------

Comment (by valani9099):

 Thank you for the clarification @wildworks!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65014#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 17:33:35 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 17:33:35 -0000
Subject: [wp-trac] [WordPress Trac] #65116: Feature request: On This Day
 dashboard widget
In-Reply-To: <053.013a3a9617eae6ca499f347ee9f9a63c@wordpress.org>
References: <053.013a3a9617eae6ca499f347ee9f9a63c@wordpress.org>
Message-ID: <068.72b12755b41550a6a5279c1d34ca8990@wordpress.org>

#65116: Feature request: On This Day dashboard widget
-------------------------+-------------------------------------------------
 Reporter:  alshakero    |       Owner:  (none)
     Type:  feature      |      Status:  new
  request                |
 Priority:  normal       |   Milestone:  7.1
Component:  Widgets      |     Version:  trunk
 Severity:  minor        |  Resolution:
 Keywords:  has-patch    |     Focuses:  ui, administration, sustainability
-------------------------+-------------------------------------------------
Changes (by annezazu):

 * milestone:  Awaiting Review => 7.1


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65116#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 18:11:34 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 18:11:34 -0000
Subject: [wp-trac] [WordPress Trac] #65120: Add
 `wp_elements_block_supports_class_name` filter to
 `wp_get_elements_class_name()`
In-Reply-To: <062.c5c4315f56dd742dd7ff410a88a4ea8d@wordpress.org>
References: <062.c5c4315f56dd742dd7ff410a88a4ea8d@wordpress.org>
Message-ID: <077.9115904cb9cb6ae676c0e97c78be726b@wordpress.org>

#65120: Add `wp_elements_block_supports_class_name` filter to
`wp_get_elements_class_name()`
-------------------------------------+-------------------------------------
 Reporter:  baikare.sandeep007       |       Owner:  (none)
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Editor                   |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  template, performance,
  has-test-info 2nd-opinion          |  coding-standards
-------------------------------------+-------------------------------------

Comment (by baikare.sandeep007):

 I thought the class names starting with `wp-elements-*` would be defined
 in a CSS file, but it turns out they’re generated dynamically within the
 same `elements.php` file. Because of that, I don’t think it will break the
 UI. However, it would definitely give developers more flexibility to use
 user-friendly class names.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65120#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 18:23:41 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 18:23:41 -0000
Subject: [wp-trac] [WordPress Trac] #64999: Admin reskin: Form elements
 are not standardized in the mobile viewport.
In-Reply-To: <053.6afa9d79ed563c578a97c68f2ee8cfe3@wordpress.org>
References: <053.6afa9d79ed563c578a97c68f2ee8cfe3@wordpress.org>
Message-ID: <068.a03350985ab3da918e5d10d45fb59ae8@wordpress.org>

#64999: Admin reskin: Form elements are not standardized in the mobile viewport.
------------------------------------+---------------------
 Reporter:  wildworks               |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  General                 |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  admin-reskin has-patch  |     Focuses:
------------------------------------+---------------------

Comment (by mosescursor):

 Upon inspection, I actually agree more with @abcd95. This fix is actually
 not needed. I have not seen the consistency in bug behavior


 === Environment
 - WordPress: 7.1-alpha-20260427.062049
 - PHP: 7.4.33
 - Server: PHP.wasm
 - Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
 - Browser: Brave 1.88.136 (Official Build) (arm64)
 - OS: macOS
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None activated
 - Plugins:
   * Test Reports 1.2.1

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64999#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 18:37:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 18:37:22 -0000
Subject: [wp-trac] [WordPress Trac] #65144: Passwords: trim() asymmetry
 between wp_hash_password() and wp_check_password() introduced in 6.8
Message-ID: <055.d4a4047f036fcce65d14783e8d81d2c2@wordpress.org>

#65144: Passwords: trim() asymmetry between wp_hash_password() and
wp_check_password() introduced in 6.8
--------------------------+-----------------------------
 Reporter:  mkultraware   |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  General       |    Version:  6.8
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 wp_hash_password() and wp_check_password() handle whitespace
 inconsistently in the bcrypt path introduced in 6.8.

 wp_hash_password() (pluggable.php line 2809):
 hash_hmac('sha384', trim($password), 'wp-sha384', true)

 wp_check_password() (pluggable.php line 2858):
 hash_hmac('sha384', $password, 'wp-sha384', true)

 The hashing function trims leading and trailing whitespace before
 hashing. The verification function does not. This means a password
 set with leading or trailing whitespace will hash as the trimmed
 value but verify against the untrimmed value, producing a mismatch
 and locking the user out.

 The default login path (wp_authenticate) trims upstream, so normal
 logins are not affected. However any code that calls wp_check_password()
 directly without prior trimming is broken — this includes plugins,
 REST API handlers, and custom authentication flows.

 A similar issue was fixed in ticket #34889 but did not carry forward
 to the new bcrypt code path added in 6.8.

 Expected behavior: wp_check_password() should trim the password before
 hashing for verification, mirroring wp_hash_password().

 Suggested fix: change line 2858 in pluggable.php from:
 hash_hmac('sha384', $password, 'wp-sha384', true)
 to:
 hash_hmac('sha384', trim($password), 'wp-sha384', true)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65144>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 20:14:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 20:14:33 -0000
Subject: [wp-trac] [WordPress Trac] #65141: Fix alignment for sortable
 metabox on post and page edit screen with classic editor
In-Reply-To: <056.a2041e2c35d0005f2c335a081657df6e@wordpress.org>
References: <056.a2041e2c35d0005f2c335a081657df6e@wordpress.org>
Message-ID: <071.71231c228ce1174abdbfbdba6e08f3e5@wordpress.org>

#65141: Fix alignment for sortable metabox on post and page edit screen with
classic editor
------------------------------------+----------------------
 Reporter:  umesh.nevase            |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  Editor                  |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch admin-reskin  |     Focuses:  ui, css
------------------------------------+----------------------
Changes (by sabernhardt):

 * keywords:  has-patch => has-patch admin-reskin
 * focuses:  ui => ui, css
 * milestone:  Awaiting Review => 7.0


Old description:

> When the Classic Editor is selected as the default editor in the Writing
> Settings, the sortable metabox container on the post/page edit screen
> includes an extra 4px of padding. This results in a 4px misalignment of
> the metabox container with Classic Editor and other UI elements on the
> page.
> Debugging confirms that this padding is only applied when the Classic
> Editor is active. Since it serves no identifiable purpose other than for
> these metaboxes, it can be safely removed to restore alignment. This
> change was originally introduced in Changeset
> [https://core.trac.wordpress.org/changeset/61646].

New description:

 When the Classic Editor is selected as the default editor in the Writing
 Settings, the sortable metabox container on the post/page edit screen
 includes an extra 4px of padding. This results in a 4px misalignment of
 the metabox container with Classic Editor and other UI elements on the
 page.

 Debugging confirms that this padding is only applied when the Classic
 Editor is active. Since it serves no identifiable purpose other than for
 these metaboxes, it can be safely removed to restore alignment. This
 change was originally introduced in Changeset [61646].

--

Comment:

 [61646] added the 4-pixel padding to sortable metaboxes in the dashboard,
 classic post editor, and media editor.

 Then [61759] set the dashboard widgets' padding to 0, which does not seem
 necessary if the padding is removed from all of them.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65141#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 20:35:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 20:35:26 -0000
Subject: [wp-trac] [WordPress Trac] #65145: Plugins: Display plugin
 slug/identifier in Installed Plugins row meta
Message-ID: <052.c963c996c75cb96bcb429195e4caec32@wordpress.org>

#65145: Plugins: Display plugin slug/identifier in Installed Plugins row meta
----------------------------+-----------------------------
 Reporter:  crweiner        |      Owner:  (none)
     Type:  enhancement     |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Plugins         |    Version:  6.9.4
 Severity:  normal          |   Keywords:
  Focuses:  administration  |
----------------------------+-----------------------------
 On the Installed Plugins screen (`/wp-admin/plugins.php`), the row meta
 currently shows the metadata, such as the plugin version, author, and
 either “View details” or “Visit plugin site”, as well as whatever else a
 plugin author manually defines.

 It would be helpful to also display the plugin's slug / identifier as
 well.

 This would make it easier to match plugins shown in WP Admin with WP-CLI
 output, where all of the `wp plugin` commands like `wp plugin list`
 identify plugins by slug/name rather than the human-readable plugin title.

 Suggested behavior:

 - If `$plugin_data['slug']` is available, display that value.
 - Otherwise, fall back to an identifier derived from `$plugin_file`:
   - directory-based plugins: directory name
   - single-file plugins: filename without `.php`

 Example:

 Current:
 Version 2.11.2 | By Activity Log Team | View details

 Proposed:
 Version 2.11.2 | By Activity Log Team | Slug: activity-log | View details

 I am not tied to having the slug be after the author name specifically,
 just an idea!

 `WP_Plugins_List_Table::single_row()` already uses `$plugin_data['slug']`
 for the “View details” link when available to pull up a WP.org card, so
 this appears to be available for many installed plugins already.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65145>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 21:06:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 21:06:05 -0000
Subject: [wp-trac] [WordPress Trac] #65140: Toolbar: Icon color is
 inncorrect in mobile layout
In-Reply-To: <053.6248a4acdfd28154e0622c885840600c@wordpress.org>
References: <053.6248a4acdfd28154e0622c885840600c@wordpress.org>
Message-ID: <068.ea47c1917a3df7b12e4512040009857c@wordpress.org>

#65140: Toolbar: Icon color is inncorrect in mobile layout
--------------------------+---------------------
 Reporter:  wildworks     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  Toolbar       |     Version:  4.3
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  ui
--------------------------+---------------------
Changes (by sabernhardt):

 * milestone:  Awaiting Review => 7.0


Comment:

 Adding to the 7.0 milestone for consideration, but I would prefer to
 complete #64762 first. Both PR 11267 and PR 11354 move these rules to a
 new `_admin-bar.scss` file.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65140#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 21:09:37 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 21:09:37 -0000
Subject: [wp-trac] [WordPress Trac] #65140: Toolbar: Icon color is
 inncorrect in mobile layout
In-Reply-To: <053.6248a4acdfd28154e0622c885840600c@wordpress.org>
References: <053.6248a4acdfd28154e0622c885840600c@wordpress.org>
Message-ID: <068.3417878be82338d8bb2706eb797e4281@wordpress.org>

#65140: Toolbar: Icon color is inncorrect in mobile layout
--------------------------+---------------------
 Reporter:  wildworks     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  Toolbar       |     Version:  4.3
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  ui
--------------------------+---------------------

Comment (by sabernhardt):

 Note: these colors involve having the `.mobile` class on the `#wpadminbar`
 element. A desktop browser's responsive mode would not show them.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65140#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 21:10:35 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 21:10:35 -0000
Subject: [wp-trac] [WordPress Trac] #65142: Round editor `.postbox`
 containers to match WP 7.0 dashboard widgets
In-Reply-To: <049.9f0e828134d257593d129261312e2acb@wordpress.org>
References: <049.9f0e828134d257593d129261312e2acb@wordpress.org>
Message-ID: <064.ba863bb0991a9d1a16111b2724381c4e@wordpress.org>

#65142: Round editor `.postbox` containers to match WP 7.0 dashboard widgets
----------------------------+------------------------------
 Reporter:  jillq           |       Owner:  (none)
     Type:  enhancement     |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  admin-reskin    |     Focuses:  ui, css
----------------------------+------------------------------
Changes (by sabernhardt):

 * keywords:   => admin-reskin
 * version:   => trunk


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65142#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 21:35:02 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 21:35:02 -0000
Subject: [wp-trac] [WordPress Trac] #65146: Unit Tests: Add tests for
 save_mod_rewrite_rules()
Message-ID: <051.a5f5daba082c56a45a6efbe9d9a84eec@wordpress.org>

#65146: Unit Tests: Add tests for save_mod_rewrite_rules()
----------------------------+-----------------------------
 Reporter:  pbearne         |      Owner:  (none)
     Type:  enhancement     |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Administration  |    Version:
 Severity:  normal          |   Keywords:
  Focuses:                  |
----------------------------+-----------------------------
 The function save_mod_rewrite_rules() in src/wp-admin/includes/misc.php
 currently lacks unit tests. This ticket covers the addition of
 comprehensive unit tests for this function, ensuring it correctly manages
 the .htaccess file based on multisite status, server support, and rewrite
 rules provided by the WP_Rewrite component.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65146>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 21:51:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 21:51:06 -0000
Subject: [wp-trac] [WordPress Trac] #65147: Unit Tests: Add tests for
 iis7_save_url_rewrite_rules()
Message-ID: <051.a666cddd7d8607814da6211838ea333b@wordpress.org>

#65147: Unit Tests: Add tests for iis7_save_url_rewrite_rules()
----------------------------+-----------------------------
 Reporter:  pbearne         |      Owner:  (none)
     Type:  enhancement     |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Administration  |    Version:
 Severity:  normal          |   Keywords:
  Focuses:                  |
----------------------------+-----------------------------
 The function iis7_save_url_rewrite_rules() in src/wp-
 admin/includes/misc.php currently lacks unit tests. This ticket covers the
 addition of tests to ensure it correctly manages the web.config file on
 IIS7+ servers, handles multisite status, and correctly adds or deletes
 rules based on the current permalink structure.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65147>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 22:04:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 22:04:13 -0000
Subject: [wp-trac] [WordPress Trac] #65148: Unit Tests: Add tests for
 iis7_rewrite_rule_exists()
Message-ID: <051.4a866b48f30e805c5580a0b9033ba9b4@wordpress.org>

#65148: Unit Tests: Add tests for iis7_rewrite_rule_exists()
----------------------------+-----------------------------
 Reporter:  pbearne         |      Owner:  (none)
     Type:  enhancement     |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Administration  |    Version:
 Severity:  normal          |   Keywords:
  Focuses:                  |
----------------------------+-----------------------------
 The function iis7_rewrite_rule_exists() in src/wp-admin/includes/misc.php
 lacks unit tests. This ticket covers adding tests to ensure it correctly
 detects the presence of WordPress rewrite rules within an IIS web.config
 file using XPath.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65148>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 22:32:45 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 22:32:45 -0000
Subject: [wp-trac] [WordPress Trac] #65140: Toolbar: Icon color is
 inncorrect in mobile layout
In-Reply-To: <053.6248a4acdfd28154e0622c885840600c@wordpress.org>
References: <053.6248a4acdfd28154e0622c885840600c@wordpress.org>
Message-ID: <068.49c1563758f8991f8f04ea44d65057f8@wordpress.org>

#65140: Toolbar: Icon color is inncorrect in mobile layout
--------------------------+---------------------
 Reporter:  wildworks     |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  7.0
Component:  Toolbar       |     Version:  4.3
 Severity:  normal        |  Resolution:
 Keywords:  has-patch     |     Focuses:  ui
--------------------------+---------------------

Comment (by peterwilsoncc):

 I've approved the [https://github.com/WordPress/wordpress-
 develop/pull/11665#pullrequestreview-4192917227 linked pull request]. The
 code looks good and tests well.

 @wildworks @sabernhardt I'll leave it up to you to decide on the order of
 commit for this ticket and #64762.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65140#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 22:59:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 22:59:13 -0000
Subject: [wp-trac] [WordPress Trac] #64225: Test tool and unit test
 improvements for 7.0
In-Reply-To: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
References: <051.28fbf0171a541ddf5270c1ae9d69b8e7@wordpress.org>
Message-ID: <066.0a346ba845267795b1a4f75039700b29@wordpress.org>

#64225: Test tool and unit test improvements for 7.0
--------------------------------------+---------------------
 Reporter:  desrosj                   |       Owner:  (none)
     Type:  task (blessed)            |      Status:  new
 Priority:  normal                    |   Milestone:  7.0
Component:  Build/Test Tools          |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+---------------------

Comment (by SergeyBiryukov):

 In [changeset:"62281" 62281]:
 {{{
 #!CommitTicketReference repository="" revision="62281"
 Tests: Correct `@covers` tag for `resolve_pattern_blocks()` tests.

 Follow-up to [58303].

 See #64225.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64225#comment:76>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Tue Apr 28 23:57:54 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Tue, 28 Apr 2026 23:57:54 -0000
Subject: [wp-trac] [WordPress Trac] #65121: Command Palette: Label can
 be incorrect for sites served over a CDN
In-Reply-To: <057.7e3cb1dd81bd572af308eb2d325d069c@wordpress.org>
References: <057.7e3cb1dd81bd572af308eb2d325d069c@wordpress.org>
Message-ID: <072.b7ccc9a4f2df452802675ae94a8214cc@wordpress.org>

#65121: Command Palette: Label can be incorrect for sites served over a CDN
---------------------------+----------------------------
 Reporter:  peterwilsoncc  |       Owner:  peterwilsoncc
     Type:  defect (bug)   |      Status:  closed
 Priority:  normal         |   Milestone:  7.0
Component:  Toolbar        |     Version:  trunk
 Severity:  normal         |  Resolution:  fixed
 Keywords:  has-patch      |     Focuses:
---------------------------+----------------------------
Changes (by peterwilsoncc):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62282" 62282]:
 {{{
 #!CommitTicketReference repository="" revision="62282"
 Toolbar: Add JavaScript fallback for determining command palette icon.

 Introduces a JavaScript fallback for determining whether the command
 palette icon in the toolbar should display ⌘Kfor Apple devices.

 This is to account for sites behind a CDN as it's common for the User-
 Agent header to be stripped from the request sent to the application
 server in order to increase cache hits on the edge.

 Props peterwilsoncc, westonruter, mukesh27, ramonopoly.
 Fixes #65121.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65121#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 00:00:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 00:00:39 -0000
Subject: [wp-trac] [WordPress Trac] #65121: Command Palette: Label can
 be incorrect for sites served over a CDN
In-Reply-To: <057.7e3cb1dd81bd572af308eb2d325d069c@wordpress.org>
References: <057.7e3cb1dd81bd572af308eb2d325d069c@wordpress.org>
Message-ID: <072.f209228a2ae57ccacd6258d9eb42f003@wordpress.org>

#65121: Command Palette: Label can be incorrect for sites served over a CDN
------------------------------------+----------------------------
 Reporter:  peterwilsoncc           |       Owner:  peterwilsoncc
     Type:  defect (bug)            |      Status:  reopened
 Priority:  normal                  |   Milestone:  7.0
Component:  Toolbar                 |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |     Focuses:
------------------------------------+----------------------------
Changes (by peterwilsoncc):

 * keywords:  has-patch => has-patch dev-feedback
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Reopening for merging [62282] to the 7.0 branch pending another
 committer's sign off.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65121#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 03:31:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 03:31:03 -0000
Subject: [wp-trac] [WordPress Trac] #65131: Administration: Spinners are
 misaligned
In-Reply-To: <053.8909cf9fe91d2de421593bc947a3a237@wordpress.org>
References: <053.8909cf9fe91d2de421593bc947a3a237@wordpress.org>
Message-ID: <068.d354ae444c2d45705b3c300a016acfda@wordpress.org>

#65131: Administration: Spinners are misaligned
------------------------------------+---------------------
 Reporter:  wildworks               |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  Administration          |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  admin-reskin has-patch  |     Focuses:  ui
------------------------------------+---------------------

Comment (by jadavsanjay):

 == Reproduction Report
 === Description
 This report validates whether the issue can be reproduced.

 Patch tested: https://core.trac.wordpress.org/ticket/65131

 === Environment
 - WordPress: 7.1-alpha-20260427.042324
 - PHP: 7.4.33
 - Server: PHP.wasm
 - Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
 - Browser: Chrome 147.0.0.0
 - OS: Windows 10/11
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None activated
 - Plugins:
   * Classic Editor and Classic Widgets 1.5.1
   * Test Reports 1.2.1

 === Actual Results
 1.  ✅ Issue resolved with patch.

 === Additional Notes
 - Button spinners are now correctly aligned in the required areas after
 applying the patch.

 === Supplemental Artifacts
 https://i.postimg.cc/2SmBK20j/1.png
 https://i.postimg.cc/htg75p2h/2.png
 https://i.postimg.cc/P5h8R2SC/3.png
 https://i.postimg.cc/W1nJLgy1/4.png

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65131#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 03:47:08 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 03:47:08 -0000
Subject: [wp-trac] [WordPress Trac] #65149: Media upload from the post edit
 screen shows an inaccurate number when uploading multiple media files -
 first time
Message-ID: <055.e999e0ec8100b5476bac2da5955cc7d2@wordpress.org>

#65149: Media upload from the post edit screen shows an inaccurate number when
uploading multiple media files - first time
----------------------------+-----------------------------
 Reporter:  jadavsanjay     |      Owner:  (none)
     Type:  defect (bug)    |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Upload          |    Version:
 Severity:  normal          |   Keywords:
  Focuses:  ui, javascript  |
----------------------------+-----------------------------
 Issue facing while first time on load
 When uploading multiple media files from the Edit Post screen via “Set
 featured image”, it displays incorrect numbers.

 Steps to reproduce:

 Create a new post.
 Click on "Set featured image."
 Go to "Upload files" and upload multiple files.
 Notice that the numbers are inaccurate (you may need to repeat step 2
 multiple times to reproduce the issue).

 https://postimg.cc/phJzhGt5

 Video

 https://drive.google.com/file/d/1g3MeCH_iLkB6hzdl5Q2svmmWrsnMrjdx/view?usp=sharing

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65149>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 03:47:37 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 03:47:37 -0000
Subject: [wp-trac] [WordPress Trac] #65149: Media upload from the post
 edit screen shows an inaccurate number when uploading multiple media files
 - first time
In-Reply-To: <055.e999e0ec8100b5476bac2da5955cc7d2@wordpress.org>
References: <055.e999e0ec8100b5476bac2da5955cc7d2@wordpress.org>
Message-ID: <070.5be1b2a8f20b99393f1b5ab61d0a39b3@wordpress.org>

#65149: Media upload from the post edit screen shows an inaccurate number when
uploading multiple media files - first time
--------------------------+------------------------------
 Reporter:  jadavsanjay   |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Upload        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  ui, javascript
--------------------------+------------------------------
Changes (by jadavsanjay):

 * Attachment "wordpress.webm" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65149>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 03:47:45 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 03:47:45 -0000
Subject: [wp-trac] [WordPress Trac] #65149: Media upload from the post
 edit screen shows an inaccurate number when uploading multiple media files
 - first time
In-Reply-To: <055.e999e0ec8100b5476bac2da5955cc7d2@wordpress.org>
References: <055.e999e0ec8100b5476bac2da5955cc7d2@wordpress.org>
Message-ID: <070.8e474d4bd4a8f94afb94414c985fce1b@wordpress.org>

#65149: Media upload from the post edit screen shows an inaccurate number when
uploading multiple media files - first time
--------------------------+------------------------------
 Reporter:  jadavsanjay   |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Upload        |     Version:
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:  ui, javascript
--------------------------+------------------------------
Changes (by jadavsanjay):

 * Attachment "new-1.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65149>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 04:15:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 04:15:57 -0000
Subject: [wp-trac] [WordPress Trac] #65149: Media upload from the post
 edit screen shows an inaccurate number when uploading multiple media files
 - first time
In-Reply-To: <055.e999e0ec8100b5476bac2da5955cc7d2@wordpress.org>
References: <055.e999e0ec8100b5476bac2da5955cc7d2@wordpress.org>
Message-ID: <070.518e5e079a62920af5e6a11f21c3063e@wordpress.org>

#65149: Media upload from the post edit screen shows an inaccurate number when
uploading multiple media files - first time
--------------------------+-----------------------------
 Reporter:  jadavsanjay   |       Owner:  (none)
     Type:  defect (bug)  |      Status:  closed
 Priority:  normal        |   Milestone:
Component:  Upload        |     Version:
 Severity:  normal        |  Resolution:  duplicate
 Keywords:                |     Focuses:  ui, javascript
--------------------------+-----------------------------
Changes (by wildworks):

 * status:  new => closed
 * resolution:   => duplicate
 * milestone:  Awaiting Review =>


Comment:

 Duplicate of #65053.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65149#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 04:58:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 04:58:26 -0000
Subject: [wp-trac] [WordPress Trac] #65054: $_GET['pagenow'] and
 $_GET['widget'] unsanitized in dashboard AJAX handler
In-Reply-To: <052.a75882c45098b4077208ace43f305612@wordpress.org>
References: <052.a75882c45098b4077208ace43f305612@wordpress.org>
Message-ID: <067.1adcafaf4aa8d570570a0c5f660c3fbd@wordpress.org>

#65054: $_GET['pagenow'] and $_GET['widget'] unsanitized in dashboard AJAX handler
-------------------------------------------------+-------------------------
 Reporter:  rajeshcp                             |       Owner:  rajeshcp
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Security                             |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing has-test-    |     Focuses:
  info has-unit-tests                            |
-------------------------------------------------+-------------------------
Changes (by liaison):

 * keywords:  has-patch needs-testing has-test-info => has-patch needs-
     testing has-test-info has-unit-tests


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65054#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 05:18:45 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 05:18:45 -0000
Subject: [wp-trac] [WordPress Trac] #65051: $_REQUEST['term'] used
 unsanitized in user search query
In-Reply-To: <052.48e93b7172e09acbd378dc6d127d732f@wordpress.org>
References: <052.48e93b7172e09acbd378dc6d127d732f@wordpress.org>
Message-ID: <067.53368896c2405363293e4cbf2ed12288@wordpress.org>

#65051: $_REQUEST['term'] used unsanitized in user search query
-------------------------------------+-------------------------------------
 Reporter:  rajeshcp                 |       Owner:  rajeshcp
     Type:  defect (bug)             |      Status:  assigned
 Priority:  normal                   |   Milestone:  7.1
Component:  Networks and Sites       |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  multisite, coding-
  has-test-info has-unit-tests       |  standards
-------------------------------------+-------------------------------------
Changes (by liaison):

 * keywords:  has-patch needs-testing has-test-info => has-patch needs-
     testing has-test-info has-unit-tests


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65051#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 06:03:45 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 06:03:45 -0000
Subject: [wp-trac] [WordPress Trac] #65143: Add polyfill for PHP 8.6's
 clamp() function
In-Reply-To: <049.bfe1585db563ebd1d079384363f22ec8@wordpress.org>
References: <049.bfe1585db563ebd1d079384363f22ec8@wordpress.org>
Message-ID: <064.07c1ccf606b92c218a89f1a26354d9f8@wordpress.org>

#65143: Add polyfill for PHP 8.6's clamp() function
-------------------------+--------------------------------
 Reporter:  Soean        |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  php-compatibility
-------------------------+--------------------------------

Comment (by Soean):

 This is the correct RFC: https://wiki.php.net/rfc/clamp_v2

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65143#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 06:19:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 06:19:06 -0000
Subject: [wp-trac] [WordPress Trac] #65145: Plugins: Display plugin
 slug/identifier in Installed Plugins row meta
In-Reply-To: <052.c963c996c75cb96bcb429195e4caec32@wordpress.org>
References: <052.c963c996c75cb96bcb429195e4caec32@wordpress.org>
Message-ID: <067.4f1aeb1626bd9c03cdb12623aa60f2ef@wordpress.org>

#65145: Plugins: Display plugin slug/identifier in Installed Plugins row meta
-------------------------+------------------------------
 Reporter:  crweiner     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Plugins      |     Version:  6.9.4
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  administration
-------------------------+------------------------------

Comment (by hbhalodia):

 Hi @crweiner, I agree with the same. It would be beneficial when we
 compare the results with the CLI command which shows slug and with the
 plugin UI page.

 Let's wait for a review from the Core Team to check the usecase more
 broadly and the placement of the slug. I have already raised the PR in
 case the issue is accepted to work on.

 The enhancement is not such big, as you already pointed, `$plugin_slug` is
 being used in `WP_Plugins_List_Table::single_row()`, So my PR uses the
 same variable to add it after the author.

 Thanks,

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65145#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 06:42:47 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 06:42:47 -0000
Subject: [wp-trac] [WordPress Trac] #65144: Passwords: trim() asymmetry
 between wp_hash_password() and wp_check_password() introduced in 6.8
In-Reply-To: <055.d4a4047f036fcce65d14783e8d81d2c2@wordpress.org>
References: <055.d4a4047f036fcce65d14783e8d81d2c2@wordpress.org>
Message-ID: <070.8669453999a4d98614a074558f2cfebe@wordpress.org>

#65144: Passwords: trim() asymmetry between wp_hash_password() and
wp_check_password() introduced in 6.8
--------------------------+------------------------------
 Reporter:  mkultraware   |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:  6.8
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by hbhalodia):

 Hi @mkultraware, Thanks for the ticket. I can verify indeed it's an issue.

 For a quick check for the usecase, we can use the below snipped as a
 plugin and test it out.

 {{{

 add_action( 'init', function() {
         $hashed   = wp_hash_password( '     password-to-hash.    ' );
         $to_check = wp_check_password( '     password-to-hash.    ',
 $hashed );

         var_dump( $to_check );
         wp_die();
 });

 }}}

 The output would be `bool(false)`, instead it should be `bool(true)`. This
 is because, `wp_check_password` is not handling the leading/trailing
 spaces as how `wp_hash_password` does while hashing the password.

 To handle is properly for all the usecases, Instead of just adding trim to
 line `2858`, we should add the trim to all passwords IMO, but since
 `wp_hash_password` adds a unique prefix, then wp_check_password will
 satisfy the condition on line, `2856: elseif ( str_starts_with( $hash,
 '$wp' ) ) {`, So for adding a patch currently, I am adding it specifically
 for the if condition, but we can handle that in PR review and update as
 needed.

 Thanks,

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65144#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 07:18:52 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 07:18:52 -0000
Subject: [wp-trac] [WordPress Trac] #64990: Abilities API: Add filtering
 support to `wp_get_abilities()`
In-Reply-To: <050.67b80823ffe0d9abf16db57a510556ca@wordpress.org>
References: <050.67b80823ffe0d9abf16db57a510556ca@wordpress.org>
Message-ID: <065.87ac052a712e96ad44cc4ed2b8a779c7@wordpress.org>

#64990: Abilities API: Add filtering support to `wp_get_abilities()`
-------------------------------------------------+-------------------------
 Reporter:  gziolo                               |       Owner:  gziolo
     Type:  enhancement                          |      Status:  assigned
 Priority:  normal                               |   Milestone:  7.1
Component:  Abilities API                        |     Version:  6.9
 Severity:  normal                               |  Resolution:
 Keywords:  abilities 2nd-opinion has-patch      |     Focuses:
  has-unit-tests                                 |
-------------------------------------------------+-------------------------
Changes (by gziolo):

 * keywords:  abilities 2nd-opinion has-patch => abilities 2nd-opinion has-
     patch has-unit-tests
 * milestone:  Future Release => 7.1


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64990#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 08:23:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 08:23:18 -0000
Subject: [wp-trac] [WordPress Trac] #65128: Warning on the post page.
In-Reply-To: <056.36dc6c1c8bcecf8876faea078501974f@wordpress.org>
References: <056.36dc6c1c8bcecf8876faea078501974f@wordpress.org>
Message-ID: <071.65d8810cb1b23569a67b8c85ef07bd12@wordpress.org>

#65128: Warning on the post page.
-----------------------------------+------------------------------
 Reporter:  gautammkgarg           |       Owner:  (none)
     Type:  defect (bug)           |      Status:  new
 Priority:  normal                 |   Milestone:  Awaiting Review
Component:  Administration         |     Version:
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |     Focuses:
-----------------------------------+------------------------------

Comment (by gautammkgarg):

 Thanks for your suggestion, charges are implemented and will be released
 with next update on Knit Pay. These changes will fix the
 print_emoji_styles and wp_admin_bar_styles deprecation notices. as proper
 information was missing in the deprecation notice, it was little difficult
 to understand that these notices are due to use of wp_head() and
 wp_footer() functions. But now it's fixed.

 Could you please review the PR also? It will fix the warning also.

 Replying to [comment:9 sabernhardt]:
 > WordPress added the `print_emoji_styles` and `wp_admin_bar_styles`
 deprecation notices in [56682] for plugin and theme authors to update
 their code. The new enqueuing functions remove deprecated functions from
 the `admin_head` hook within the admin, or `wp_head` on the front end.
 [56682] did not account for anyone using `wp_head()` in the admin area.
 >
 > Knit Pay calls both `wp_head()` and `wp_footer()`, which are front-end
 functions that echo output, within the `<body>` of
 [https://plugins.trac.wordpress.org/browser/knit-pay/tags/9.3.3.0/views
 /redirect-via-html-with-message.php?marks=56#L56 redirect-via-html-with-
 message.php]. The only purpose I found for this is to enqueue `jquery` and
 `knit-pay-easy-qrcode` (in [https://plugins.trac.wordpress.org/browser
 /knit-
 pay/tags/9.3.3.0/gateways/UpiQR/Gateway.php?rev=3516547&marks=50,107-108,115,205#L115
 UpiQR/Gateway.php]). However, it enqueues all the front-end styles and
 scripts, plus `<meta>` and `<link>` tags, in addition to those two
 scripts. Theoretically the plugin could use `wp_print_scripts()` instead
 of `wp_enqueue_script()`, with `knit-pay-easy-qrcode` registered in the
 `wp_print_scripts` action, but I am not sure I should recommend that.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65128#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 08:30:43 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 08:30:43 -0000
Subject: [wp-trac] [WordPress Trac] #65150: Issue with copy_dir() function t
 does not skips folders.
Message-ID: <051.3ea19f390e67542b3753efde0bd26330@wordpress.org>

#65150: Issue with copy_dir() function  t does not skips folders.
----------------------------+-----------------------------
 Reporter:  neo2k23         |      Owner:  (none)
     Type:  defect (bug)    |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Filesystem API  |    Version:  trunk
 Severity:  normal          |   Keywords:
  Focuses:                  |
----------------------------+-----------------------------
 I have a issue with the copy_dir() function.  If i want to skip a folder
 called 'languages' it does not skip it and the files within that folder
 are still copied.

 $skip_list = array('languages');
 $result = copy_dir($from, $to, $skip_list);

 However if i revert copy_dir to the version which was in WordPress 3.2.1
 it works just fine. Below is the code from WordPress version 3.2.1. The
 languages and its content folder is skipped.


 {{{
         function copy_dir($from, $to, $skip_list = array() ) {
                 global $wp_filesystem;

                 $dirlist = $wp_filesystem->dirlist($from);

                 $from = trailingslashit($from);
                 $to = trailingslashit($to);

                 $skip_regex = '';
                 foreach ( (array)$skip_list as $key => $skip_file )
                         $skip_regex .= preg_quote($skip_file, '!') . '|';

                 if ( !empty($skip_regex) )
                         $skip_regex = '!(' . rtrim($skip_regex, '|') .
 ')$!i';

                 foreach ( (array) $dirlist as $filename => $fileinfo ) {
                         if ( !empty($skip_regex) )
                                 if ( preg_match($skip_regex, $from .
 $filename) )
                                         continue;

                         if ( 'f' == $fileinfo['type'] ) {
                                 if ( ! $wp_filesystem->copy($from .
 $filename, $to . $filename, true, FS_CHMOD_FILE) ) {
                                         // If copy failed, chmod file to
 0644 and try again.
                                         $wp_filesystem->chmod($to .
 $filename, 0644);
                                         if ( ! $wp_filesystem->copy($from
 . $filename, $to . $filename, true, FS_CHMOD_FILE) )
                                                 return new
 WP_Error('copy_failed', __('Could not copy file.'), $to . $filename);
                                 }
                         } elseif ( 'd' == $fileinfo['type'] ) {
                                 if ( !$wp_filesystem->is_dir($to .
 $filename) ) {
                                         if ( !$wp_filesystem->mkdir($to .
 $filename, FS_CHMOD_DIR) )
                                                 return new
 WP_Error('mkdir_failed', __('Could not create directory.'), $to .
 $filename);
                                 }
                                 $result = copy_dir($from . $filename, $to
 . $filename, $skip_list);
                                 if ( is_wp_error($result) )
                                         return $result;
                         }
                 }
                 return true;
         }
 }}}


 The current dir_copy() function does not skip folders and its content.

 Can you please provide a fix for this as the description of dir_copy
 states it skips files/folders by the skip list.

 Or am i doing something wrong?  Do i have to provide the complete path to
 the languages folder?  In v3.2.1 we did not have todo this.

 Please advice

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65150>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 08:39:02 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 08:39:02 -0000
Subject: [wp-trac] [WordPress Trac] #65150: Issue with copy_dir()
 function t does not skips folders.
In-Reply-To: <051.3ea19f390e67542b3753efde0bd26330@wordpress.org>
References: <051.3ea19f390e67542b3753efde0bd26330@wordpress.org>
Message-ID: <066.34e7ff089bc0ab70a8c0dfa130a779ee@wordpress.org>

#65150: Issue with copy_dir() function  t does not skips folders.
----------------------------+------------------------------
 Reporter:  neo2k23         |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Filesystem API  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:
----------------------------+------------------------------

Comment (by neo2k23):

 This code does not skip folders whic is part of the current copy_dir()
 function.


 {{{
         foreach ( (array) $dirlist as $filename => $fileinfo ) {
                 if ( in_array( $filename, $skip_list, true ) ) {
                         continue;
                 }
 }}}


 if i change it to this it works again


 {{{
         $skip_regex = '';
         foreach ( (array)$skip_list as $key => $skip_file )
                 $skip_regex .= preg_quote($skip_file, '!') . '|';

         if ( !empty($skip_regex) )
                 $skip_regex = '!(' . rtrim($skip_regex, '|') . ')$!i';

         foreach ( (array) $dirlist as $filename => $fileinfo ) {
                 if ( !empty($skip_regex) )
                         if ( preg_match($skip_regex, $from . $filename) )
                                 continue;
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65150#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 09:09:47 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 09:09:47 -0000
Subject: [wp-trac] [WordPress Trac] #64927: .media-upload-form
 .media-item min-height is causing a visual glitch
In-Reply-To: <053.5c06c7f70bc7b6efbbefc59207e6c811@wordpress.org>
References: <053.5c06c7f70bc7b6efbbefc59207e6c811@wordpress.org>
Message-ID: <068.2083b8fb315f6e9ec4930659674a73e0@wordpress.org>

#64927: .media-upload-form .media-item min-height is causing a visual glitch
-----------------------------+------------------------------
 Reporter:  Presskopp        |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Media            |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  has-screenshots  |     Focuses:  ui
-----------------------------+------------------------------

Comment (by shreyasikhar26):

 I am not able to reproduce this issue, can you please check once again.

 If you are still able to reproduce it, can you please mention the exact
 steps. Also, please make sure to use default theme and no plugins active
 while reproducing the issue.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64927#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 09:23:26 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 09:23:26 -0000
Subject: [wp-trac] [WordPress Trac] #64986: preview needs gettext
In-Reply-To: <052.86455e444a3819f06c00aef779dc6226@wordpress.org>
References: <052.86455e444a3819f06c00aef779dc6226@wordpress.org>
Message-ID: <067.2e149c7c93b83b6ea6ca08b76b3b0f7f@wordpress.org>

#64986: preview needs gettext
-------------------------------------------------+-------------------------
 Reporter:  timse201                             |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  7.0
Component:  I18N                                 |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  good-first-bug has-patch changes-    |     Focuses:
  requested                                      |  accessibility
-------------------------------------------------+-------------------------
Changes (by audrasjb):

 * keywords:  good-first-bug has-patch => good-first-bug has-patch changes-
     requested


Comment:

 As per today's bug scrub.
 Thanks for the patch.
 However I think the initial request was only to distinguish verbs from
 nouns. We could avoid having 4 different strings by just having `_x(
 'Preview', 'noun' )` and `_x( 'Preview', 'verb' )`.

 At the very least, I think we could have the same string (`button`
 context, or even better `verb`) for both `src/wp-admin/includes/meta-
 boxes.php` and `wp-includes/class-wp-editor.php`.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64986#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 09:25:54 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 09:25:54 -0000
Subject: [wp-trac] [WordPress Trac] #64984: reply needs gettext
In-Reply-To: <052.8e2371a87eccd18086892c909f989418@wordpress.org>
References: <052.8e2371a87eccd18086892c909f989418@wordpress.org>
Message-ID: <067.2e838e7ec36ceaeeefa90d481029c50e@wordpress.org>

#64984: reply needs gettext
------------------------------+-----------------------
 Reporter:  timse201          |       Owner:  audrasjb
     Type:  defect (bug)      |      Status:  accepted
 Priority:  normal            |   Milestone:  7.0
Component:  I18N              |     Version:  trunk
 Severity:  normal            |  Resolution:
 Keywords:  has-patch commit  |     Focuses:
------------------------------+-----------------------
Changes (by audrasjb):

 * keywords:  has-patch changes-requested => has-patch commit


Comment:

 As per today's bug scrub: This needs to be fixed on Gutenberg side too,
 but we can always commit this patch in Core, and open a GB PR in parallel.
 Re-adding `commit` keyword.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64984#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 09:31:59 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 09:31:59 -0000
Subject: [wp-trac] [WordPress Trac] #64983: Scale needs gettext
In-Reply-To: <052.e53f02387eb408cdbc6651e425f128e1@wordpress.org>
References: <052.e53f02387eb408cdbc6651e425f128e1@wordpress.org>
Message-ID: <067.7c08e813c4b660d59be7c5ba406173c3@wordpress.org>

#64983: Scale needs gettext
-------------------------------------------+-----------------------
 Reporter:  timse201                       |       Owner:  audrasjb
     Type:  defect (bug)                   |      Status:  accepted
 Priority:  normal                         |   Milestone:  7.0
Component:  I18N                           |     Version:  trunk
 Severity:  normal                         |  Resolution:
 Keywords:  changes-requested needs-patch  |     Focuses:
-------------------------------------------+-----------------------
Changes (by audrasjb):

 * keywords:  changes-requested has-patch => changes-requested needs-patch


Comment:

 We need a new PR with updated context: verb  or noun (or button for
 example) is enough, translators don't need more details.

 New (or updated) patch welcome :)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64983#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 09:40:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 09:40:28 -0000
Subject: [wp-trac] [WordPress Trac] #65099: Fix: Only auto register
 settings if the plugin the connector references is installed and active
In-Reply-To: <060.0b8a8e3426646ee12db1e6e829f3d840@wordpress.org>
References: <060.0b8a8e3426646ee12db1e6e829f3d840@wordpress.org>
Message-ID: <075.19c515fbe2ed2e4d0dca8b3c9724b8e8@wordpress.org>

#65099: Fix: Only auto register settings if the plugin the connector references is
installed and active
-------------------------------------------------+-------------------------
 Reporter:  jorgefilipecosta                     |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  7.0
Component:  General                              |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests changes-    |     Focuses:
  requested                                      |
-------------------------------------------------+-------------------------
Changes (by audrasjb):

 * keywords:  has-patch has-unit-tests => has-patch has-unit-tests changes-
     requested


Comment:

 As per today's bug scrub: @peterwilsoncc left a good point in
 [https://github.com/WordPress/wordpress-
 develop/pull/11564#pullrequestreview-4178079643 this comment]. Waiting for
 @jorgefilipecosta to update his PR.
 Otherwise the changeset looks good to me.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65099#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 09:45:58 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 09:45:58 -0000
Subject: [wp-trac] [WordPress Trac] #64927: .media-upload-form
 .media-item min-height is causing a visual glitch
In-Reply-To: <053.5c06c7f70bc7b6efbbefc59207e6c811@wordpress.org>
References: <053.5c06c7f70bc7b6efbbefc59207e6c811@wordpress.org>
Message-ID: <068.e39e26b998a12b86c512b0e18ed51c0d@wordpress.org>

#64927: .media-upload-form .media-item min-height is causing a visual glitch
-----------------------------+------------------------------
 Reporter:  Presskopp        |       Owner:  (none)
     Type:  defect (bug)     |      Status:  new
 Priority:  normal           |   Milestone:  Awaiting Review
Component:  Media            |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  has-screenshots  |     Focuses:  ui
-----------------------------+------------------------------

Comment (by Presskopp):

 Hi @shreyasikhar26 , I'm using 7.0-RC2-62242 ♪, PHP 8.5.1 and it's easy to
 reproduce there

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64927#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 09:48:25 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 09:48:25 -0000
Subject: [wp-trac] [WordPress Trac] #64771: Existing block level custom
 CSS in a post breaks when the post is edited by user without
 unfiltered_html
In-Reply-To: <056.6cde4cb4d3674a3ab453a19d1888b21e@wordpress.org>
References: <056.6cde4cb4d3674a3ab453a19d1888b21e@wordpress.org>
Message-ID: <071.e7f400ba33adc87f4981f5fece5b6352@wordpress.org>

#64771: Existing block level custom CSS in a post breaks when the post is edited by
user without unfiltered_html
-------------------------------------------------+-------------------------
 Reporter:  glendaviesnz                         |       Owner:  ramonopoly
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  high                                 |   Milestone:  7.0
Component:  Editor                               |     Version:  trunk
 Severity:  critical                             |  Resolution:
 Keywords:  has-patch has-unit-tests dev-        |     Focuses:
  feedback                                       |
-------------------------------------------------+-------------------------
Changes (by audrasjb):

 * keywords:  has-patch has-unit-tests 2nd-opinion dev-feedback => has-patch
     has-unit-tests dev-feedback


Comment:

 As per today's bug scrub:

 @ramonopoly I think the first docblock of the changeset is not 100%
 correct:
 > Strips `style.css` attributes from all blocks in post content.
 Should be:
 > Strips custom CSS attributes from all blocks in post content.

 What do you think?
 Otherwise the rest of this changeset looks good to me.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64771#comment:65>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 09:53:03 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 09:53:03 -0000
Subject: [wp-trac] [WordPress Trac] #64685: Bulk Edit dropdown height
 increased compared to previous version
In-Reply-To: <052.53b49d25a3b1c1e2b2913b40d78297d6@wordpress.org>
References: <052.53b49d25a3b1c1e2b2913b40d78297d6@wordpress.org>
Message-ID: <067.5f9c7cadbbd1bfea8dbfa73cee44848e@wordpress.org>

#64685: Bulk Edit dropdown height increased compared to previous version
-------------------------------------------+------------------------
 Reporter:  mohitbsf                       |       Owner:  joedolson
     Type:  defect (bug)                   |      Status:  reopened
 Priority:  normal                         |   Milestone:  7.0
Component:  Quick/Bulk Edit                |     Version:  trunk
 Severity:  minor                          |  Resolution:
 Keywords:  admin-reskin has-patch commit  |     Focuses:  css
-------------------------------------------+------------------------
Changes (by audrasjb):

 * keywords:  admin-reskin has-patch => admin-reskin has-patch commit


Comment:

 As per today's bug scrub:
 This was committed but @wildworks  mentioned that the patch introduces a
 regression, and added a new PR to fix the issue. It looks good on my side.
 Pinging @joedolson as ticket owner :)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64685#comment:30>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 09:57:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 09:57:13 -0000
Subject: [wp-trac] [WordPress Trac] #65012: Fix: Register Akismet
 Anti-Spam as a connector
In-Reply-To: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
References: <060.46689c302968272609f7f5709dd06b43@wordpress.org>
Message-ID: <075.2b19d5ff68d06ece74bb3082afcaedaa@wordpress.org>

#65012: Fix: Register Akismet Anti-Spam as a connector
---------------------------------------------+-----------------------------
 Reporter:  jorgefilipecosta                 |       Owner:
                                             |  jorgefilipecosta
     Type:  feature request                  |      Status:  reopened
 Priority:  normal                           |   Milestone:  7.0
Component:  Plugins                          |     Version:
 Severity:  normal                           |  Resolution:
 Keywords:  has-patch has-unit-tests commit  |     Focuses:
---------------------------------------------+-----------------------------
Changes (by audrasjb):

 * keywords:  has-patch has-unit-tests => has-patch has-unit-tests commit


Comment:

 As per today's bug scrub:
 A decision was made and we now need this to be re-committed and backported
 to 7.0.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65012#comment:54>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 10:00:59 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 10:00:59 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.85c181f30e735afe3710e07943b0451d@wordpress.org>

#65015: Connectors: Several strings are not translated
-------------------------------------------------+-------------------------
 Reporter:  369work                              |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  high                                 |   Milestone:  7.0
Component:  I18N                                 |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests connectors  |     Focuses:
  commit needs-dev-note fixed-major dev-         |
  reviewed                                       |
-------------------------------------------------+-------------------------
Changes (by audrasjb):

 * keywords:
     has-patch has-unit-tests connectors commit dev-feedback needs-dev-note
     fixed-major
     =>
     has-patch has-unit-tests connectors commit needs-dev-note fixed-major
     dev-reviewed


Comment:

 2nd committer sign-off: let's get this backported before the next RC.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015#comment:44>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 10:09:07 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 10:09:07 -0000
Subject: [wp-trac] [WordPress Trac] #65151: Dashboard Widgets not draggable
Message-ID: <053.4ebfa4149ba2f1d9f36f7cdbdf8c4670@wordpress.org>

#65151: Dashboard Widgets not draggable
----------------------------+-----------------------------
 Reporter:  Presskopp       |      Owner:  (none)
     Type:  defect (bug)    |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  Administration  |    Version:
 Severity:  normal          |   Keywords:  admin-reskin
  Focuses:  ui, css         |
----------------------------+-----------------------------
 The issue is a bit hard to explain, please watch the video. Sometimes it's
 impossible to drag a widget to the desired space, sometimes the 'drop
 zone' has the size of the dragged widget, sometimes not, etc.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65151>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 10:09:30 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 10:09:30 -0000
Subject: [wp-trac] [WordPress Trac] #65151: Dashboard Widgets not
 draggable
In-Reply-To: <053.4ebfa4149ba2f1d9f36f7cdbdf8c4670@wordpress.org>
References: <053.4ebfa4149ba2f1d9f36f7cdbdf8c4670@wordpress.org>
Message-ID: <068.a0583e358221359a3a8357efbb71ba75@wordpress.org>

#65151: Dashboard Widgets not draggable
----------------------------+------------------------------
 Reporter:  Presskopp       |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  admin-reskin    |     Focuses:  ui, css
----------------------------+------------------------------
Changes (by Presskopp):

 * Attachment "dashboard-widgets-drag-and-drop-issue.mp4" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65151>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 10:11:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 10:11:14 -0000
Subject: [wp-trac] [WordPress Trac] #65151: Dashboard Widgets not
 draggable
In-Reply-To: <053.4ebfa4149ba2f1d9f36f7cdbdf8c4670@wordpress.org>
References: <053.4ebfa4149ba2f1d9f36f7cdbdf8c4670@wordpress.org>
Message-ID: <068.f863c261b6f0f1d73c493265a9ea9d79@wordpress.org>

#65151: Dashboard Widgets not draggable
----------------------------+----------------------
 Reporter:  Presskopp       |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  admin-reskin    |     Focuses:  ui, css
----------------------------+----------------------
Changes (by audrasjb):

 * version:   => trunk
 * milestone:  Awaiting Review => 7.0


Comment:

 Thanks for the ticket, I'm moving it to 7.0 as it looks like a regression
 with the admin reskin.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65151#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 10:25:51 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 10:25:51 -0000
Subject: [wp-trac] [WordPress Trac] #54484: REST API returns (empty)
 array for Meta but Schema has type object
In-Reply-To: <052.25c3a5e735603f677b046a936606e1e9@wordpress.org>
References: <052.25c3a5e735603f677b046a936606e1e9@wordpress.org>
Message-ID: <067.bb5deea075627fba656fe4f0782f119e@wordpress.org>

#54484: REST API returns (empty) array for Meta but Schema has type object
-----------------------------------------+-----------------------
 Reporter:  dtrunk90                     |       Owner:  flixos90
     Type:  defect (bug)                 |      Status:  assigned
 Priority:  normal                       |   Milestone:  7.1
Component:  REST API                     |     Version:  4.7
 Severity:  normal                       |  Resolution:
 Keywords:  has-patch changes-requested  |     Focuses:
-----------------------------------------+-----------------------

Comment (by liaison):

 I’ve refactored the patch to use a more concise approach by casting
 $data['meta'] to an array for value extraction. This eliminates the
 redundant if/elseif blocks while safely handling both object and array
 structures.

 Improvements:

 Reduced Complexity: Replaced explicit structure checks with the null
 coalescing operator (??) for cleaner logic.

 Unified Extraction: By temporarily casting meta to an array, we extract
 wp_pattern_sync_status in a single line regardless of the input type.

 Code Density: Combined unset() calls and removed unnecessary branching,
 making the function more maintainable without changing the functional
 outcome.
 {{{#!php
 <?php
 public function filter_response_by_context( $data, $context ) {
     unset( $data['title']['rendered'], $data['content']['rendered'] );

     $meta = (array) $data['meta'];
     $data['wp_pattern_sync_status'] = $meta['wp_pattern_sync_status'] ??
 '';

      if ( is_object( $data['meta'] ) ) {
         unset( $data['meta']->wp_pattern_sync_status );
     } else {
         unset( $data['meta']['wp_pattern_sync_status'] );
     }

     return $data;
 }
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/54484#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 10:32:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 10:32:18 -0000
Subject: [wp-trac] [WordPress Trac] #64987: Admin Reskin: Add more
 margin below the plugin card header
In-Reply-To: <053.b1d5d7c143cf639af6b45eb03cf6d81a@wordpress.org>
References: <053.b1d5d7c143cf639af6b45eb03cf6d81a@wordpress.org>
Message-ID: <068.23dc979d462313054020b3aa2904b9ee@wordpress.org>

#64987: Admin Reskin: Add more margin below the plugin card header
------------------------------------+---------------------
 Reporter:  wildworks               |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  Plugins                 |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  admin-reskin has-patch  |     Focuses:
------------------------------------+---------------------
Changes (by wildworks):

 * milestone:  Awaiting Review => 7.0


Comment:

 This is not strictly a bug, but it might be worth fixing in the 7.0
 release.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64987#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 10:49:17 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 10:49:17 -0000
Subject: [wp-trac] [WordPress Trac] #64987: Admin Reskin: Add more
 margin below the plugin card header
In-Reply-To: <053.b1d5d7c143cf639af6b45eb03cf6d81a@wordpress.org>
References: <053.b1d5d7c143cf639af6b45eb03cf6d81a@wordpress.org>
Message-ID: <068.41713289ecb9595d1cc300048578c512@wordpress.org>

#64987: Admin Reskin: Add more margin below the plugin card header
------------------------------------+---------------------
 Reporter:  wildworks               |       Owner:  (none)
     Type:  defect (bug)            |      Status:  new
 Priority:  normal                  |   Milestone:  7.0
Component:  Plugins                 |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  admin-reskin has-patch  |     Focuses:
------------------------------------+---------------------

Comment (by darshitrajyaguru97):

 == Test Report ==

 '''Patch tested:''' https://github.com/WordPress/wordpress-
 develop/pull/11395

 === Environment ===
 * WordPress: 7.1-alpha-20260330.093642
 * PHP: 8.2.29
 * Database: MySQL
 * Browser: Chrome
 * OS: Windows
 * Theme: Twenty Twenty-Five
 * MU Plugins: None activated

 === Steps to Test ===
 # Apply the patch from the PR
 # Follow the steps mentioned in the ticket to reproduce the issue
 # Verify the behavior after applying the patch

 === Actual Results ===
 ✅ The issue is resolved after applying the patch.
 No regressions were observed during testing.

 === Additional Notes ===
 The patch works as expected in the tested environment.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64987#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 11:03:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 11:03:14 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2364689=3A_Customizer_?=
 =?utf-8?q?=E2=80=9CPublish=E2=80=9D_button_size_appears_larger_in_7=2E0_c?=
 =?utf-8?q?ompared_to_6=2E9=2E1?=
In-Reply-To: <052.73b260729ea404b08fe598cc7f376a7e@wordpress.org>
References: <052.73b260729ea404b08fe598cc7f376a7e@wordpress.org>
Message-ID: <067.c3bf14173f96bbd2e9b71cc1b1078fc5@wordpress.org>

#64689: Customizer “Publish” button size appears larger in 7.0 compared to 6.9.1
--------------------------------+---------------------
 Reporter:  mohitbsf            |       Owner:  (none)
     Type:  defect (bug)        |      Status:  new
 Priority:  normal              |   Milestone:  7.0
Component:  Customize           |     Version:  trunk
 Severity:  normal              |  Resolution:
 Keywords:  close admin-reskin  |     Focuses:  css
--------------------------------+---------------------
Changes (by wildworks):

 * milestone:  Awaiting Review => 7.0


Comment:

 This issue might be worth fixing in the 7.0 release.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64689#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 11:11:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 11:11:57 -0000
Subject: [wp-trac] [WordPress Trac] #65150: Issue with copy_dir()
 function t does not skips folders.
In-Reply-To: <051.3ea19f390e67542b3753efde0bd26330@wordpress.org>
References: <051.3ea19f390e67542b3753efde0bd26330@wordpress.org>
Message-ID: <066.f0a5d22395f2bfff19e3c14068562441@wordpress.org>

#65150: Issue with copy_dir() function  t does not skips folders.
----------------------------+------------------------------
 Reporter:  neo2k23         |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Filesystem API  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:
----------------------------+------------------------------

Comment (by hbhalodia):

 Hi @neo2k23, Thanks for the ticket. I can verify the issue.

 The issue is only with the nested subfolders if that contain the name, but
 within same level it is getting skipped. But we also need to remove for
 nested subfolders. In earlier version, the regex based matching was used,
 which captured from nested subfolders as well, hence it was working. While
 when doing conversion to array based matching, the nested folders scenario
 was not handled.

 == AI Usage

 - GH Copilot
 - Claude 4.6 Opus
 - Asked AI to review the issue with current copy_dir function and was used
 in version 3.2.1. Sharing below the detailed summary.


 == Root Cause

 === Background

 In WordPress ≤ 3.2.1, `copy_dir()` used a **regex-based** skip mechanism.
 It built a pattern from the `$skip_list` and matched it against the **full
 path** (`$from . $filename`) using a `$` anchor. The **entire
 `$skip_list`** was passed unchanged to every recursive call:

 {{{
 // WP 3.2.1 — old behavior
 $skip_regex = '!(' . rtrim($skip_regex, '|') . ')$!i';

 // Matched against full path at every depth
 if ( preg_match( $skip_regex, $from . $filename ) )
     continue;

 // Full skip_list passed to recursive calls
 $result = copy_dir( $from . $filename, $to . $filename, $skip_list );
 }}}

 This meant a bare folder name like `'wp-content'` in the skip list would
 match at **any** nesting depth because the regex anchored to the end of
 the full path.

 === What Changed (Post-3.2.1)

 The function was refactored to use `in_array()` for matching and a
 decomposed `$sub_skip_list` for recursive calls:

 {{{
 // Current code — only top-level match works
 if ( in_array( $filename, $skip_list, true ) ) {
     continue;
 }

 // Only path-prefixed items are propagated
 $sub_skip_list = array();
 foreach ( $skip_list as $skip_item ) {
     if ( str_starts_with( $skip_item, $filename . '/' ) ) {
         $sub_skip_list[] = preg_replace( '!^' . preg_quote( $filename, '!'
 ) . '/!i', '', $skip_item );
     }
 }
 $result = copy_dir( $from . $filename, $to . $filename, $sub_skip_list );
 }}}

 The `$sub_skip_list` generation **only keeps items prefixed with
 `$filename . '/'`** and strips the prefix. Bare names (without `/`) are
 **silently dropped**, so they never reach deeper recursion levels.

 === Example

 Given this structure and `$skip_list = array( 'skip-me' )`:

 {{{
 source/
 ├── skip-me/               ← Skipped ✅ (top-level match via in_array)
 ├── folderA/
 │   └── skip-me/           ← NOT skipped ❌ (dropped from sub_skip_list)
 └── folderB/
     └── folderC/
         └── skip-me/       ← NOT skipped ❌ (dropped from sub_skip_list)
 }}}

 When recursing into `folderA`, the loop checks `str_starts_with( 'skip-
 me', 'folderA/' )` → `false`, so `'skip-me'` is excluded from
 `$sub_skip_list`. The nested `skip-me/` folder is then copied when it
 shouldn't be.

 == Fix

 Added an `elseif` branch that propagates **bare names** (those without
 `/`) into the `$sub_skip_list`:

 {{{
  foreach ( $skip_list as $skip_item ) {
      if ( str_starts_with( $skip_item, $filename . '/' ) ) {
          $sub_skip_list[] = preg_replace( '!^' . preg_quote( $filename,
 '!' ) . '/!i', '', $skip_item );
 +    } elseif ( ! str_contains( $skip_item, '/' ) ) {
 +        $sub_skip_list[] = $skip_item;
      }
  }
 }}}

 === Why This Works

 - **Path-based items** (e.g. `'wp-admin/about.php'`) continue to be
 decomposed as before — only `'about.php'` is passed when recursing into
 `wp-admin/`.
 - **Bare names** (e.g. `'wp-content'`, `'skip-me'`) are now passed through
 to **all** subdirectory levels, restoring the pre-3.2.1 behavior where
 they are matched at every depth.
 - Items containing `/` that **don't** match the current directory prefix
 are correctly excluded (they belong to a different subtree).


 Thanks,

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65150#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 11:24:52 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 11:24:52 -0000
Subject: [wp-trac] [WordPress Trac] #65150: Issue with copy_dir()
 function t does not skips folders.
In-Reply-To: <051.3ea19f390e67542b3753efde0bd26330@wordpress.org>
References: <051.3ea19f390e67542b3753efde0bd26330@wordpress.org>
Message-ID: <066.102683435675d404b7a179299f0c4cd9@wordpress.org>

#65150: Issue with copy_dir() function  t does not skips folders.
----------------------------+------------------------------
 Reporter:  neo2k23         |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Filesystem API  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+------------------------------

Comment (by neo2k23):

 Hi @hbhalodia

 That is the issue. The deeper subfolders with the name in the skiplist
 array are not skipped.


 {{{
 themefolder/
 ├── languages/               ← Skipped ✅ (top-level match via in_array)
 ├── folderA/
 │   └── languages/           ← NOT skipped ❌ (dropped from sub_skip_list)
 └── folderB/
     └── folderC/
         └── languages/       ← NOT skipped ❌ (dropped from sub_skip_list)
 }}}


 Thank you for your investigation.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65150#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 12:07:47 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 12:07:47 -0000
Subject: [wp-trac] [WordPress Trac] #64873: WP AI Client: Add JavaScript
 client (`wp-ai-client`)
In-Reply-To: <050.ab1b0ff8a0f489f01aafd95f74dab14c@wordpress.org>
References: <050.ab1b0ff8a0f489f01aafd95f74dab14c@wordpress.org>
Message-ID: <065.8b8a25df746cb278c09fb331dc46a06a@wordpress.org>

#64873: WP AI Client: Add JavaScript client (`wp-ai-client`)
---------------------------------------------+-------------------------
 Reporter:  gziolo                           |       Owner:  (none)
     Type:  enhancement                      |      Status:  new
 Priority:  normal                           |   Milestone:  7.1
Component:  AI                               |     Version:  trunk
 Severity:  normal                           |  Resolution:
 Keywords:  ai-client has-patch 2nd-opinion  |     Focuses:  javascript
---------------------------------------------+-------------------------

Comment (by mikinc860):

 After reviewing both #64872 and #64873, the separation between the REST
 layer and the JavaScript client seems like the right approach and should
 help keep the architecture easier to evolve over time.

 One thing that may help while landing `wp-ai-client` into Core is defining
 a stable normalization layer between the package and the `wp-ai/v1`
 responses. That would allow the REST implementation in #64872 to evolve
 internally without creating breaking changes for Gutenberg or third-party
 consumers relying on the JS package.

 A few additional considerations that may improve long-term
 maintainability:

 * middleware/interceptor support similar to `apiFetch`,
 * first-class TypeScript typings,
 * transport-agnostic internals for future streaming support,
 * and maintaining consistent request/response structures with the PHP
 client where practical.

 Since this package will likely become the primary integration point for
 editor/admin AI experiences, having a predictable abstraction layer early
 should help future Core and plugin integrations.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64873#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 12:09:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 12:09:29 -0000
Subject: [wp-trac] 
 =?utf-8?q?=5BWordPress_Trac=5D_=2364689=3A_Customizer_?=
 =?utf-8?q?=E2=80=9CPublish=E2=80=9D_button_size_appears_larger_in_7=2E0_c?=
 =?utf-8?q?ompared_to_6=2E9=2E1?=
In-Reply-To: <052.73b260729ea404b08fe598cc7f376a7e@wordpress.org>
References: <052.73b260729ea404b08fe598cc7f376a7e@wordpress.org>
Message-ID: <067.da92aa42c59be83f841731bc125423f2@wordpress.org>

#64689: Customizer “Publish” button size appears larger in 7.0 compared to 6.9.1
--------------------------------+---------------------
 Reporter:  mohitbsf            |       Owner:  (none)
     Type:  defect (bug)        |      Status:  new
 Priority:  normal              |   Milestone:  7.0
Component:  Customize           |     Version:  trunk
 Severity:  normal              |  Resolution:
 Keywords:  close admin-reskin  |     Focuses:  css
--------------------------------+---------------------

Comment (by wildworks):

 Please note that [https://github.com/WordPress/wordpress-
 develop/pull/11497 PR 11497] has been submitted to change the theme
 installation button size to 32px, similar to this ticket.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64689#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 12:12:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 12:12:31 -0000
Subject: [wp-trac] [WordPress Trac] #64872: WP AI Client: Add AI REST
 API Endpoints (`wp-ai/v1`)
In-Reply-To: <050.632db09585bed6c19d723e601c3f6ab6@wordpress.org>
References: <050.632db09585bed6c19d723e601c3f6ab6@wordpress.org>
Message-ID: <065.553a465ee865aebc56164b4cb0f52d6e@wordpress.org>

#64872: WP AI Client: Add AI REST API Endpoints (`wp-ai/v1`)
-------------------------------------------------+-------------------------
 Reporter:  gziolo                               |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  7.1
Component:  AI                                   |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  ai-client has-patch has-unit-tests   |     Focuses:  rest-api
  2nd-opinion                                    |
-------------------------------------------------+-------------------------

Comment (by dhrumilk):

 The REST API endpoints look well-structured and consistent with
 wp_ai_client_prompt(), which is great for keeping parity across PHP and
 REST usage. Also agree with the earlier suggestion in the PR to keep REST
 and JS client as separate concerns for easier review.

 On capabilities, manage_options for prompt_ai feels a bit broad given
 potential cost implications. A more restrictive or opt-in approach might
 be safer. Also, separating list_ai_providers and list_ai_models seems
 unnecessary and could be simplified.

 Using map_meta_cap instead of user_has_cap would also align better with
 Core standards.

 Overall, this is a solid foundation and worth continuing to iterate on for
 Core inclusion.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64872#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 12:16:50 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 12:16:50 -0000
Subject: [wp-trac] [WordPress Trac] #65145: Plugins: Display plugin
 slug/identifier in Installed Plugins row meta
In-Reply-To: <052.c963c996c75cb96bcb429195e4caec32@wordpress.org>
References: <052.c963c996c75cb96bcb429195e4caec32@wordpress.org>
Message-ID: <067.c6df28af0cad193b816f7173f52574e5@wordpress.org>

#65145: Plugins: Display plugin slug/identifier in Installed Plugins row meta
-------------------------+------------------------------
 Reporter:  crweiner     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Plugins      |     Version:  6.9.4
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  administration
-------------------------+------------------------------

Comment (by wildworks):

 Thanks for the suggestion.

 > It would be helpful to also display the plugin's slug / identifier as
 well.

 This feature might be useful for developers, but it's meaningless for most
 users. Personally, I don't think this feature should be introduced into
 the core.

 Instead, I recommend using the CLI to retrieve the title and identifier.

 {{{
 wp plugin list --fields=name,title
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65145#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 12:25:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 12:25:23 -0000
Subject: [wp-trac] [WordPress Trac] #64890: Harden
 `WP_HTTP_Polling_Sync_Server` endpoint
In-Reply-To: <051.0abc1ef2f98aca960470eea117eafa49@wordpress.org>
References: <051.0abc1ef2f98aca960470eea117eafa49@wordpress.org>
Message-ID: <066.fc46b204ebafdde4e843e5e76d3b7530@wordpress.org>

#64890: Harden `WP_HTTP_Polling_Sync_Server` endpoint
------------------------------------+----------------------------
 Reporter:  czarate                 |       Owner:  peterwilsoncc
     Type:  defect (bug)            |      Status:  reopened
 Priority:  normal                  |   Milestone:  7.0
Component:  REST API                |     Version:  trunk
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-reviewed  |     Focuses:
------------------------------------+----------------------------
Changes (by audrasjb):

 * keywords:  has-patch dev-feedback => has-patch dev-reviewed


Comment:

 Second committer sign-off: This looks good to go.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64890#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 12:27:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 12:27:13 -0000
Subject: [wp-trac] [WordPress Trac] #64890: Harden
 `WP_HTTP_Polling_Sync_Server` endpoint
In-Reply-To: <051.0abc1ef2f98aca960470eea117eafa49@wordpress.org>
References: <051.0abc1ef2f98aca960470eea117eafa49@wordpress.org>
Message-ID: <066.aa225d1bf08e6449e066f7b89e2a3ff6@wordpress.org>

#64890: Harden `WP_HTTP_Polling_Sync_Server` endpoint
------------------------------------+----------------------------
 Reporter:  czarate                 |       Owner:  peterwilsoncc
     Type:  defect (bug)            |      Status:  closed
 Priority:  normal                  |   Milestone:  7.0
Component:  REST API                |     Version:  trunk
 Severity:  normal                  |  Resolution:  fixed
 Keywords:  has-patch dev-reviewed  |     Focuses:
------------------------------------+----------------------------
Changes (by audrasjb):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62283" 62283]:
 {{{
 #!CommitTicketReference repository="" revision="62283"
 REST API: Harden Real Time Collaboration endpoint.

 Adds additional validation and permission checks the the Real Time
 Collaboration endpoint to ensure only input in the expected format is
 supported.

 Reviewed by peterwilsoncc, audrasjb.
 Merges [62198] to the 7.0 branch.
 Props czarate, westonruter, joefusco, peterwilsoncc.
 Fixes #64890.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64890#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 12:38:57 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 12:38:57 -0000
Subject: [wp-trac] [WordPress Trac] #64911: Incorrectly documented hooks
In-Reply-To: <052.47f3887ddf4cdbb7e6ade9f3f26b6bf5@wordpress.org>
References: <052.47f3887ddf4cdbb7e6ade9f3f26b6bf5@wordpress.org>
Message-ID: <067.423bda5537cda2dabbc39ed58a2a7f8d@wordpress.org>

#64911: Incorrectly documented hooks
--------------------------+------------------------------
 Reporter:  kkmuffme      |       Owner:  johnbillion
     Type:  defect (bug)  |      Status:  assigned
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  General       |     Version:
 Severity:  trivial       |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by shreyasikhar26):

 Might be related to this https://core.trac.wordpress.org/ticket/64896

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64911#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 15:07:11 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 15:07:11 -0000
Subject: [wp-trac] [WordPress Trac] #65143: Add polyfill for PHP 8.6's
 clamp() function
In-Reply-To: <049.bfe1585db563ebd1d079384363f22ec8@wordpress.org>
References: <049.bfe1585db563ebd1d079384363f22ec8@wordpress.org>
Message-ID: <064.cb087095ea60646b7219b3055439617f@wordpress.org>

#65143: Add polyfill for PHP 8.6's clamp() function
-------------------------+--------------------------------
 Reporter:  Soean        |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  php-compatibility
-------------------------+--------------------------------

Comment (by westonruter):

 Are there places where `clamp()` should be used in core? I think generally
 a polyfill would be added if it is actually used.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65143#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 15:08:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 15:08:53 -0000
Subject: [wp-trac] [WordPress Trac] #65145: Plugins: Display plugin
 slug/identifier in Installed Plugins row meta
In-Reply-To: <052.c963c996c75cb96bcb429195e4caec32@wordpress.org>
References: <052.c963c996c75cb96bcb429195e4caec32@wordpress.org>
Message-ID: <067.762504bd727bcbfc53ea1715ff398bb7@wordpress.org>

#65145: Plugins: Display plugin slug/identifier in Installed Plugins row meta
-------------------------+------------------------------
 Reporter:  crweiner     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Plugins      |     Version:  6.9.4
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  administration
-------------------------+------------------------------

Comment (by westonruter):

 I often look at the row action links to figure out what the slug is. Not
 ideal, but it works.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65145#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 17:06:41 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 17:06:41 -0000
Subject: [wp-trac] [WordPress Trac] #64983: Scale needs gettext
In-Reply-To: <052.e53f02387eb408cdbc6651e425f128e1@wordpress.org>
References: <052.e53f02387eb408cdbc6651e425f128e1@wordpress.org>
Message-ID: <067.754e6f1189625094a9f139a0784b33c5@wordpress.org>

#64983: Scale needs gettext
-----------------------------------------+-----------------------
 Reporter:  timse201                     |       Owner:  audrasjb
     Type:  defect (bug)                 |      Status:  accepted
 Priority:  normal                       |   Milestone:  7.0
Component:  I18N                         |     Version:  trunk
 Severity:  normal                       |  Resolution:
 Keywords:  changes-requested has-patch  |     Focuses:
-----------------------------------------+-----------------------

Comment (by shailu25):

 Created New PR [https://github.com/WordPress/wordpress-develop/pull/11679
 11679] to add context for `Scale`.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64983#comment:14>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 17:43:38 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 17:43:38 -0000
Subject: [wp-trac] [WordPress Trac] #65150: Issue with copy_dir()
 function t does not skips folders.
In-Reply-To: <051.3ea19f390e67542b3753efde0bd26330@wordpress.org>
References: <051.3ea19f390e67542b3753efde0bd26330@wordpress.org>
Message-ID: <066.44cbf760b2c562858f0e1d9a16c12ff7@wordpress.org>

#65150: Issue with copy_dir() function  t does not skips folders.
----------------------------+------------------------------
 Reporter:  neo2k23         |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Filesystem API  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+------------------------------

Comment (by neo2k23):

 Btw instead of this


 {{{
  foreach ( $skip_list as $skip_item ) {
      if ( str_starts_with( $skip_item, $filename . '/' ) ) {
          $sub_skip_list[] = preg_replace( '!^' . preg_quote( $filename,
 '!' ) . '/!i', '', $skip_item );
 +    } elseif ( ! str_contains( $skip_item, '/' ) ) {
 +        $sub_skip_list[] = $skip_item;
      }
  }
 }}}


 You just could use this


 {{{
  foreach ( $skip_list as $skip_item ) {
   if ( ! str_contains( $skip_item, '/' ) ) {
          $sub_skip_list[] = $skip_item;
      }
  }
 }}}

 It will work just as well.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65150#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 17:56:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 17:56:09 -0000
Subject: [wp-trac] [WordPress Trac] #59139: Marketing / "fairness" :
 Change "Classic Themes" to "Template Themes"
In-Reply-To: <053.2610be41c5648f3fa4661172e8effd14@wordpress.org>
References: <053.2610be41c5648f3fa4661172e8effd14@wordpress.org>
Message-ID: <068.5c43a4b3c75359aa6f64b72ae7da8f68@wordpress.org>

#59139: Marketing / "fairness" : Change "Classic Themes" to "Template Themes"
-------------------------+----------------------
 Reporter:  ridesirat    |       Owner:  (none)
     Type:  enhancement  |      Status:  closed
 Priority:  normal       |   Milestone:
Component:  Themes       |     Version:
 Severity:  normal       |  Resolution:  wontfix
 Keywords:               |     Focuses:
-------------------------+----------------------
Changes (by sabernhardt):

 * keywords:  close =>
 * status:  new => closed
 * resolution:   => wontfix
 * milestone:  Awaiting Review =>


Comment:

 'Classic' is well established as a term for the editor and then themes.

 'Classic' can have good connotations, too, related to familiarity and
 reliability.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59139#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 19:13:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 19:13:53 -0000
Subject: [wp-trac] [WordPress Trac] #65152: UI: Inconsistent left padding
 between buttons and select dropdowns in media views
Message-ID: <062.43aca36459a6ec1c9017fa2bd5c37113@wordpress.org>

#65152: UI: Inconsistent left padding between buttons and select dropdowns in media
views
-------------------------------------+-----------------------------
 Reporter:  baikare.sandeep007       |      Owner:  (none)
     Type:  enhancement              |     Status:  new
 Priority:  normal                   |  Milestone:  Awaiting Review
Component:  Media                    |    Version:  trunk
 Severity:  normal                   |   Keywords:  has-patch
  Focuses:  ui, css, administration  |
-------------------------------------+-----------------------------
 In the media frame (e.g., when clicking "Add Media" in the editor), there
 is an inconsistency in the left padding between buttons (e.g., "Add Media
 File", "Bulk select") and the select dropdowns (e.g., "All media items",
 "All dates").

 Current padding values:

 - Buttons: `padding-left: 10px`
 - Select dropdowns: `padding-left: 8px`

 This creates a visually misaligned UI where the text inside dropdowns sits
 `2px` closer to the left edge compared to buttons.

 === Expected Behavior ===
 Both buttons and select dropdowns should have consistent left padding for
 better visual alignment.

 === Actual Behavior ===
 The select dropdown has `8px` left padding while buttons have `10px` left
 padding, causing text misalignment when these elements appear side by
 side.

 === Screenshots ===
 [[Image(https://postimg.cc/gallery/Cxrh1Nh)]]

 === Proposed Solution ===
 Update the left padding of the select dropdown in `media-views.css` from
 `8px` to `10px` to match the button padding.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65152>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 19:14:45 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 19:14:45 -0000
Subject: [wp-trac] [WordPress Trac] #65152: UI: Inconsistent left
 padding between buttons and select dropdowns in media views
In-Reply-To: <062.43aca36459a6ec1c9017fa2bd5c37113@wordpress.org>
References: <062.43aca36459a6ec1c9017fa2bd5c37113@wordpress.org>
Message-ID: <077.230b14f94e26de1e6607f726940c7b26@wordpress.org>

#65152: UI: Inconsistent left padding between buttons and select dropdowns in media
views
--------------------------------+--------------------------------------
 Reporter:  baikare.sandeep007  |       Owner:  (none)
     Type:  enhancement         |      Status:  new
 Priority:  normal              |   Milestone:  Awaiting Review
Component:  Media               |     Version:  trunk
 Severity:  normal              |  Resolution:
 Keywords:  has-patch           |     Focuses:  ui, css, administration
--------------------------------+--------------------------------------
Changes (by baikare.sandeep007):

 * Attachment "65152.patch" added.

 media button UI padding fixes

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65152>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 19:26:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 19:26:33 -0000
Subject: [wp-trac] [WordPress Trac] #65152: UI: Inconsistent left
 padding between buttons and select dropdowns in media views
In-Reply-To: <062.43aca36459a6ec1c9017fa2bd5c37113@wordpress.org>
References: <062.43aca36459a6ec1c9017fa2bd5c37113@wordpress.org>
Message-ID: <077.7d9f4fdd244cf649ad2b9fa1b4d3f830@wordpress.org>

#65152: UI: Inconsistent left padding between buttons and select dropdowns in media
views
-------------------------------------+-------------------------------------
 Reporter:  baikare.sandeep007       |       Owner:  (none)
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Media                    |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch reporter-      |     Focuses:  ui, css,
  feedback                           |  administration
-------------------------------------+-------------------------------------
Changes (by audrasjb):

 * keywords:  has-patch => has-patch reporter-feedback
 * version:  trunk =>


Comment:

 Hello and thanks for the ticket.
 Please note that many parts of the interface have changed in WP 7.0.
 Would you please check the incoming version to see if the problem is still
 occurring?
 You can try 7.0 using
 [https://playground.wordpress.net/?php=8.3&wp=beta&networking=yes&language=&multisite=no&random=35c5qxxq80v#ewogICJwbHVnaW5zIjogW10sCiAgInN0ZXBzIjogW10sCiAgInByZWZlcnJlZFZlcnNpb25zIjogewogICAgInBocCI6ICI4LjMiLAogICAgIndwIjogImJldGEiCiAgfSwKICAiZmVhdHVyZXMiOiB7fSwKICAibG9naW4iOiB0cnVlCn0=
 this Playground link] if you want.
 Thank you

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65152#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 19:35:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 19:35:55 -0000
Subject: [wp-trac] [WordPress Trac] #65152: UI: Inconsistent left
 padding between buttons and select dropdowns in media views
In-Reply-To: <062.43aca36459a6ec1c9017fa2bd5c37113@wordpress.org>
References: <062.43aca36459a6ec1c9017fa2bd5c37113@wordpress.org>
Message-ID: <077.b881f5d2ba42c8c6c47c0718a0aca9b6@wordpress.org>

#65152: UI: Inconsistent left padding between buttons and select dropdowns in media
views
-------------------------------------+-------------------------------------
 Reporter:  baikare.sandeep007       |       Owner:  (none)
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Media                    |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch reporter-      |     Focuses:  ui, css,
  feedback                           |  administration
-------------------------------------+-------------------------------------

Comment (by baikare.sandeep007):

 Hi @audrasjb
 Thanks for playground link, I can confirm that the issue still persists on
 the new UI as well as all the listing pages.

 Addition to that in new UI button left padding is increased to `12px` and
 for select it is `8px`

 [Screenshot](https://postimg.cc/kRgN4RwY)
 [Post listing page Screenshot](https://postimg.cc/mzt2gbCf)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65152#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 20:40:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 20:40:48 -0000
Subject: [wp-trac] [WordPress Trac] #65153: Identify selected buttons
 (.active in button groups) in Windows High Contrast Mode
Message-ID: <055.31a39574f4a6e19d1248494470c837e6@wordpress.org>

#65153: Identify selected buttons (.active in button groups) in Windows High
Contrast Mode
--------------------------------+-----------------------------
 Reporter:  sabernhardt         |      Owner:  (none)
     Type:  defect (bug)        |     Status:  new
 Priority:  normal              |  Milestone:  Awaiting Review
Component:  Administration      |    Version:
 Severity:  normal              |   Keywords:
  Focuses:  accessibility, css  |
--------------------------------+-----------------------------
 Buttons within groups do not distinguish which buttons are selected in
 Windows High Contrast Mode.

 This includes:
 - custom options in Permalink Settings
 - alignment options in the Image details dialog (when replacing an image
 within a post in classic editor)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65153>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 22:57:24 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 22:57:24 -0000
Subject: [wp-trac] [WordPress Trac] #64771: Existing block level custom
 CSS in a post breaks when the post is edited by user without
 unfiltered_html
In-Reply-To: <056.6cde4cb4d3674a3ab453a19d1888b21e@wordpress.org>
References: <056.6cde4cb4d3674a3ab453a19d1888b21e@wordpress.org>
Message-ID: <071.562569f9fce51ab6a184627fccafa5f3@wordpress.org>

#64771: Existing block level custom CSS in a post breaks when the post is edited by
user without unfiltered_html
-------------------------------------------------+-------------------------
 Reporter:  glendaviesnz                         |       Owner:  ramonopoly
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  high                                 |   Milestone:  7.0
Component:  Editor                               |     Version:  trunk
 Severity:  critical                             |  Resolution:
 Keywords:  has-patch has-unit-tests dev-        |     Focuses:
  feedback                                       |
-------------------------------------------------+-------------------------

Comment (by ramonopoly):

 @audrasjb Thanks for double checking.

 `styles.css` is technically correct, but it doesn't explain the "why" in
 plain language I'd agree there.

 I can get a quick changeset up to update the comment for trunk if that
 helps. My instinct is to leave it for 7.0 though as a non-blocker.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64771#comment:66>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 23:40:44 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 23:40:44 -0000
Subject: [wp-trac] [WordPress Trac] #65141: Fix alignment for sortable
 metabox on post and page edit screen with classic editor
In-Reply-To: <056.a2041e2c35d0005f2c335a081657df6e@wordpress.org>
References: <056.a2041e2c35d0005f2c335a081657df6e@wordpress.org>
Message-ID: <071.7a9055adea611bf0b1310cda1ac513e0@wordpress.org>

#65141: Fix alignment for sortable metabox on post and page edit screen with
classic editor
------------------------------------+-----------------------------
 Reporter:  umesh.nevase            |       Owner:  SergeyBiryukov
     Type:  defect (bug)            |      Status:  closed
 Priority:  normal                  |   Milestone:  7.0
Component:  Editor                  |     Version:  trunk
 Severity:  normal                  |  Resolution:  fixed
 Keywords:  has-patch admin-reskin  |     Focuses:  ui, css
------------------------------------+-----------------------------
Changes (by SergeyBiryukov):

 * owner:  (none) => SergeyBiryukov
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62284" 62284]:
 {{{
 #!CommitTicketReference repository="" revision="62284"
 Administration: Correct alignment of meta boxes on the Edit screen with
 classic editor.

 Follow-up to [61646], [61759].

 Props umeshnevase, sabernhardt, SergeyBiryukov.
 Fixes #65141.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65141#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Wed Apr 29 23:42:06 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Wed, 29 Apr 2026 23:42:06 -0000
Subject: [wp-trac] [WordPress Trac] #65141: Fix alignment for sortable
 metabox on post and page edit screen with classic editor
In-Reply-To: <056.a2041e2c35d0005f2c335a081657df6e@wordpress.org>
References: <056.a2041e2c35d0005f2c335a081657df6e@wordpress.org>
Message-ID: <071.78efc88a1b2d982dfbde8cbeddc82b89@wordpress.org>

#65141: Fix alignment for sortable metabox on post and page edit screen with
classic editor
-------------------------------------------------+-------------------------
 Reporter:  umesh.nevase                         |       Owner:
                                                 |  SergeyBiryukov
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Editor                               |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch admin-reskin commit dev-   |     Focuses:  ui, css
  feedback                                       |
-------------------------------------------------+-------------------------
Changes (by SergeyBiryukov):

 * keywords:  has-patch admin-reskin => has-patch admin-reskin commit dev-
     feedback
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Reopening for 7.0 consideration.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65141#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 03:53:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 03:53:09 -0000
Subject: [wp-trac] [WordPress Trac] #65153: Identify selected buttons
 (.active in button groups) in Windows High Contrast Mode
In-Reply-To: <055.31a39574f4a6e19d1248494470c837e6@wordpress.org>
References: <055.31a39574f4a6e19d1248494470c837e6@wordpress.org>
Message-ID: <070.9757377c50b2bf175e90609688c8d4b0@wordpress.org>

#65153: Identify selected buttons (.active in button groups) in Windows High
Contrast Mode
----------------------------+---------------------------------
 Reporter:  sabernhardt     |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:  accessibility, css
----------------------------+---------------------------------
Changes (by sabernhardt):

 * Attachment "Align-None-selected-without-focus.png" added.

 Before patch: alignment options in the Image details dialog do not show
 that 'None' is selected

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65153>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 03:55:47 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 03:55:47 -0000
Subject: [wp-trac] [WordPress Trac] #65153: Identify selected buttons
 (.active in button groups) in Windows High Contrast Mode
In-Reply-To: <055.31a39574f4a6e19d1248494470c837e6@wordpress.org>
References: <055.31a39574f4a6e19d1248494470c837e6@wordpress.org>
Message-ID: <070.85907f0cea4b43a4f104b600e1e3196b@wordpress.org>

#65153: Identify selected buttons (.active in button groups) in Windows High
Contrast Mode
----------------------------+---------------------------------
 Reporter:  sabernhardt     |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:  accessibility, css
----------------------------+---------------------------------
Description changed by sabernhardt:

Old description:

> Buttons within groups do not distinguish which buttons are selected in
> Windows High Contrast Mode.
>
> This includes:
> - custom options in Permalink Settings
> - alignment options in the Image details dialog (when replacing an image
> within a post in classic editor)

New description:

 Buttons within groups do not distinguish which buttons are selected in
 Windows High Contrast Mode.

 This includes:
 - custom options in Permalink Settings
 - alignment options in the Image details dialog (when replacing an image
 within a post in classic editor)

 [[Image(https://core.trac.wordpress.org/raw-attachment/ticket/65153/Align-
 None-selected-without-focus.png, alt="Before patch: alignment options in
 the Image details dialog do not show that 'None' is selected", title="")]]

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65153#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 04:48:09 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 04:48:09 -0000
Subject: [wp-trac] [WordPress Trac] #65150: Issue with copy_dir()
 function t does not skips folders.
In-Reply-To: <051.3ea19f390e67542b3753efde0bd26330@wordpress.org>
References: <051.3ea19f390e67542b3753efde0bd26330@wordpress.org>
Message-ID: <066.725fd9f265abbcefe2aa08963df1d56f@wordpress.org>

#65150: Issue with copy_dir() function  t does not skips folders.
----------------------------+------------------------------
 Reporter:  neo2k23         |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Filesystem API  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+------------------------------

Comment (by hbhalodia):

 Hi @neo2k23, Thanks for pointing it out.

 {{{
 str_contains( $skip_item, '/' )
 }}}

 It is not the actual place where the `copy_dir` function checks to skip
 the file/folder or whether to include it.

 The current update which I have shared only determines, whether the item
 which we need to skip is a `bare-name` (without '/' eg: 'abcd') or a
 `path-based-item` (with '/' eg: 'xyz/abcd.txt', so that we know whether to
 propogate it downward or not. As you see in next line we have a recursion,
 that again calls `copy_dir` with new parameters to check.

 The case you are saying for file check all happens here, line `2033` as
 shown below.

 {{{
 if ( in_array( $filename, $skip_list, true ) ) {
         continue;
 }
 }}}

 Also the above line is a strict match comparision, that is,

 {{{
 in_array( 'skip-me', array('skip-me'), true ) → true → skipped ✅
 in_array( 'abcd-skip-me', array('skip-me'), true ) → false → NOT skipped
 ✅
 in_array( 'skip-me-abcd', array('skip-me'), true ) → false → NOT skipped
 ✅
 }}}

 The line added is only for the propogation, to pass the `file` down to
 child diretories unchanged.

 So a folder, `folderB/folderC/abcd-skip-me/ would never be skipped because
 'abcd-skip-me' !== 'skip-me'`.

 Also you can test the PR attached with multiple edge cases and let me know
 if there is anything is failing. I would be happy to fix that.

 Thanks,

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65150#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 04:48:27 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 04:48:27 -0000
Subject: [wp-trac] [WordPress Trac] #65141: Fix alignment for sortable
 metabox on post and page edit screen with classic editor
In-Reply-To: <056.a2041e2c35d0005f2c335a081657df6e@wordpress.org>
References: <056.a2041e2c35d0005f2c335a081657df6e@wordpress.org>
Message-ID: <071.103dd0e2463016b258a478f1b4b4f138@wordpress.org>

#65141: Fix alignment for sortable metabox on post and page edit screen with
classic editor
-------------------------------------------------+-------------------------
 Reporter:  umesh.nevase                         |       Owner:
                                                 |  SergeyBiryukov
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Editor                               |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch admin-reskin commit dev-   |     Focuses:  ui, css
  reviewed                                       |
-------------------------------------------------+-------------------------
Changes (by peterwilsoncc):

 * keywords:  has-patch admin-reskin commit dev-feedback => has-patch admin-
     reskin commit dev-reviewed


Comment:

 r62284 approved for merging to the 7.0 branch.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65141#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 04:54:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 04:54:13 -0000
Subject: [wp-trac] [WordPress Trac] #65141: Fix alignment for sortable
 metabox on post and page edit screen with classic editor
In-Reply-To: <056.a2041e2c35d0005f2c335a081657df6e@wordpress.org>
References: <056.a2041e2c35d0005f2c335a081657df6e@wordpress.org>
Message-ID: <071.7f69f14f7d28ff7c8bf8376b211bd80d@wordpress.org>

#65141: Fix alignment for sortable metabox on post and page edit screen with
classic editor
-------------------------------------------------+-------------------------
 Reporter:  umesh.nevase                         |       Owner:
                                                 |  SergeyBiryukov
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  Editor                               |     Version:  trunk
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch admin-reskin commit dev-   |     Focuses:  ui, css
  reviewed                                       |
-------------------------------------------------+-------------------------
Changes (by peterwilsoncc):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62285" 62285]:
 {{{
 #!CommitTicketReference repository="" revision="62285"
 Administration: Correct alignment of meta boxes on the Edit screen with
 classic editor.

 Follow-up to [61646], [61759].

 Reviewed by peterwilsoncc.
 Merges r62284 to the 7.0 branch.

 Props umeshnevase, sabernhardt, SergeyBiryukov.
 Fixes #65141.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65141#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 04:59:00 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 04:59:00 -0000
Subject: [wp-trac] [WordPress Trac] #60597: Script Modules API: Allow
 list of enqueued module data to be exposed
In-Reply-To: <055.3aa66bfe5fd804f2d836bf1cf1b246aa@wordpress.org>
References: <055.3aa66bfe5fd804f2d836bf1cf1b246aa@wordpress.org>
Message-ID: <070.5c974d91e980417ac1470d1601356a0e@wordpress.org>

#60597: Script Modules API: Allow list of enqueued module data to be exposed
--------------------------------------+--------------------------
 Reporter:  johnbillion               |       Owner:  westonruter
     Type:  enhancement               |      Status:  assigned
 Priority:  normal                    |   Milestone:  7.1
Component:  Script Loader             |     Version:  6.5
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+--------------------------

Comment (by peterwilsoncc):

 In [changeset:"62286" 62286]:
 {{{
 #!CommitTicketReference repository="" revision="62286"
 I18N: Add translation support for script modules.

 Add automatic translation loading for script modules (ES modules), so
 strings using `__()` and friends from `@wordpress/i18n` can be translated
 at runtime. This brings classic script i18n parity to script modules
 registered via `wp_register_script_module()`, which previously had no way
 to load translation data, leaving strings untranslated on screens like
 Connectors and Fonts that are built as script modules.

 At the `admin_print_footer_scripts` and `wp_footer` actions, every
 enqueued script module and its dependencies are walked, the translation
 chunk is loaded for each, and an inline `<script>` calls
 `wp.i18n.setLocaleData()` so translations are available before deferred
 modules execute. Note there is currently a runtime dependency on the `wp-
 i18n` classic script, which is printed just-in-time if not already
 enqueued. This coupling is to be removed in a future release.

 Public API:

 * `WP_Script_Modules::set_translations()` stores the text domain (and
 optional path) per registered module to override the text domain and path.
 A global `wp_set_script_module_translations()` function is added as a
 wrapper around `wp_script_modules()->set_translations()`.
 * `WP_Script_Modules::get_registered()` obtains a registered module's
 data. See #60597.
 * `WP_Script_Modules::print_script_module_translations()` emits inline
 `wp.i18n.setLocaleData()` calls after classic scripts load but before
 modules execute.
 * `load_script_module_textdomain()` loads the translation data for a given
 script module ID and text domain.
 * The existing `load_script_textdomain_relative_path` filter gains a third
 `$is_module` parameter so callers can distinguish classic-script and
 script-module lookups when resolving translation paths.

 PHPStan types are also added in `WP_Script_Modules`. See #64238.

 Developed in https://github.com/WordPress/wordpress-develop/pull/11543

 Reviewed by audrasjb.
 Merges r62278 to the 7.0 branch.

 Props manzoorwanijk, westonruter, jsnajdr, jonsurrell, mukesh27,
 peterwilsoncc, 369work, desrosj, sabernhardt, nilambar, jorgefilipecosta,
 malayladu.
 See #64238, #60597.
 Fixes #65015.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60597#comment:27>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 04:59:00 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 04:59:00 -0000
Subject: [wp-trac] [WordPress Trac] #64238: PHPStan code quality
 improvements for 7.0
In-Reply-To: <058.3d898e5edbfd206122933e3b070d763b@wordpress.org>
References: <058.3d898e5edbfd206122933e3b070d763b@wordpress.org>
Message-ID: <073.84014ed49d2e9f542fc45cceae7c6285@wordpress.org>

#64238: PHPStan code quality improvements for 7.0
--------------------------------------+-------------------------------
 Reporter:  SergeyBiryukov            |       Owner:  (none)
     Type:  task (blessed)            |      Status:  closed
 Priority:  normal                    |   Milestone:  7.0
Component:  General                   |     Version:
 Severity:  normal                    |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests  |     Focuses:  coding-standards
--------------------------------------+-------------------------------

Comment (by peterwilsoncc):

 In [changeset:"62286" 62286]:
 {{{
 #!CommitTicketReference repository="" revision="62286"
 I18N: Add translation support for script modules.

 Add automatic translation loading for script modules (ES modules), so
 strings using `__()` and friends from `@wordpress/i18n` can be translated
 at runtime. This brings classic script i18n parity to script modules
 registered via `wp_register_script_module()`, which previously had no way
 to load translation data, leaving strings untranslated on screens like
 Connectors and Fonts that are built as script modules.

 At the `admin_print_footer_scripts` and `wp_footer` actions, every
 enqueued script module and its dependencies are walked, the translation
 chunk is loaded for each, and an inline `<script>` calls
 `wp.i18n.setLocaleData()` so translations are available before deferred
 modules execute. Note there is currently a runtime dependency on the `wp-
 i18n` classic script, which is printed just-in-time if not already
 enqueued. This coupling is to be removed in a future release.

 Public API:

 * `WP_Script_Modules::set_translations()` stores the text domain (and
 optional path) per registered module to override the text domain and path.
 A global `wp_set_script_module_translations()` function is added as a
 wrapper around `wp_script_modules()->set_translations()`.
 * `WP_Script_Modules::get_registered()` obtains a registered module's
 data. See #60597.
 * `WP_Script_Modules::print_script_module_translations()` emits inline
 `wp.i18n.setLocaleData()` calls after classic scripts load but before
 modules execute.
 * `load_script_module_textdomain()` loads the translation data for a given
 script module ID and text domain.
 * The existing `load_script_textdomain_relative_path` filter gains a third
 `$is_module` parameter so callers can distinguish classic-script and
 script-module lookups when resolving translation paths.

 PHPStan types are also added in `WP_Script_Modules`. See #64238.

 Developed in https://github.com/WordPress/wordpress-develop/pull/11543

 Reviewed by audrasjb.
 Merges r62278 to the 7.0 branch.

 Props manzoorwanijk, westonruter, jsnajdr, jonsurrell, mukesh27,
 peterwilsoncc, 369work, desrosj, sabernhardt, nilambar, jorgefilipecosta,
 malayladu.
 See #64238, #60597.
 Fixes #65015.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64238#comment:124>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 04:59:00 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 04:59:00 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.1ca817f444661b3e6794e9c99d5f7c8a@wordpress.org>

#65015: Connectors: Several strings are not translated
-------------------------------------------------+-------------------------
 Reporter:  369work                              |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  closed
 Priority:  high                                 |   Milestone:  7.0
Component:  I18N                                 |     Version:
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests connectors  |     Focuses:
  commit needs-dev-note fixed-major dev-         |
  reviewed                                       |
-------------------------------------------------+-------------------------
Changes (by peterwilsoncc):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62286" 62286]:
 {{{
 #!CommitTicketReference repository="" revision="62286"
 I18N: Add translation support for script modules.

 Add automatic translation loading for script modules (ES modules), so
 strings using `__()` and friends from `@wordpress/i18n` can be translated
 at runtime. This brings classic script i18n parity to script modules
 registered via `wp_register_script_module()`, which previously had no way
 to load translation data, leaving strings untranslated on screens like
 Connectors and Fonts that are built as script modules.

 At the `admin_print_footer_scripts` and `wp_footer` actions, every
 enqueued script module and its dependencies are walked, the translation
 chunk is loaded for each, and an inline `<script>` calls
 `wp.i18n.setLocaleData()` so translations are available before deferred
 modules execute. Note there is currently a runtime dependency on the `wp-
 i18n` classic script, which is printed just-in-time if not already
 enqueued. This coupling is to be removed in a future release.

 Public API:

 * `WP_Script_Modules::set_translations()` stores the text domain (and
 optional path) per registered module to override the text domain and path.
 A global `wp_set_script_module_translations()` function is added as a
 wrapper around `wp_script_modules()->set_translations()`.
 * `WP_Script_Modules::get_registered()` obtains a registered module's
 data. See #60597.
 * `WP_Script_Modules::print_script_module_translations()` emits inline
 `wp.i18n.setLocaleData()` calls after classic scripts load but before
 modules execute.
 * `load_script_module_textdomain()` loads the translation data for a given
 script module ID and text domain.
 * The existing `load_script_textdomain_relative_path` filter gains a third
 `$is_module` parameter so callers can distinguish classic-script and
 script-module lookups when resolving translation paths.

 PHPStan types are also added in `WP_Script_Modules`. See #64238.

 Developed in https://github.com/WordPress/wordpress-develop/pull/11543

 Reviewed by audrasjb.
 Merges r62278 to the 7.0 branch.

 Props manzoorwanijk, westonruter, jsnajdr, jonsurrell, mukesh27,
 peterwilsoncc, 369work, desrosj, sabernhardt, nilambar, jorgefilipecosta,
 malayladu.
 See #64238, #60597.
 Fixes #65015.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015#comment:45>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 05:00:39 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 05:00:39 -0000
Subject: [wp-trac] [WordPress Trac] #65133: Classic editor tagchecklist
 ui issue
In-Reply-To: <056.cddabe8f9de9c7ca3223e92018d86491@wordpress.org>
References: <056.cddabe8f9de9c7ca3223e92018d86491@wordpress.org>
Message-ID: <071.d7aca9a7527aee8b28842a5ea16c5359@wordpress.org>

#65133: Classic editor tagchecklist ui issue
-------------------------------------------------+-------------------------
 Reporter:  umesh.nevase                         |       Owner:
                                                 |  SergeyBiryukov
     Type:  defect (bug)                         |      Status:  closed
 Priority:  normal                               |   Milestone:  7.0
Component:  Editor                               |     Version:  trunk
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch admin-reskin commit dev-   |     Focuses:  ui, css
  reviewed                                       |
-------------------------------------------------+-------------------------
Changes (by peterwilsoncc):

 * status:  reopened => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62287" 62287]:
 {{{
 #!CommitTicketReference repository="" revision="62287"
 Editor: Correct alignment for “Remove tag” icon in classic editor.

 Follow-up to [38880], [61645].

 Reviewed by peterwilsoncc.
 Merges r62279 to the 7.0 branch.

 Props umesh.nevase, sabernhardt, SergeyBiryukov.
 Fixes #65133.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65133#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 05:09:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 05:09:13 -0000
Subject: [wp-trac] [WordPress Trac] #65152: UI: Inconsistent left
 padding between buttons and select dropdowns in media views
In-Reply-To: <062.43aca36459a6ec1c9017fa2bd5c37113@wordpress.org>
References: <062.43aca36459a6ec1c9017fa2bd5c37113@wordpress.org>
Message-ID: <077.fccc0c426ace0bc0e2ded16427c169e8@wordpress.org>

#65152: UI: Inconsistent left padding between buttons and select dropdowns in media
views
-------------------------------------+-------------------------------------
 Reporter:  baikare.sandeep007       |       Owner:  (none)
     Type:  enhancement              |      Status:  new
 Priority:  normal                   |   Milestone:  Awaiting Review
Component:  Media                    |     Version:
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch reporter-      |     Focuses:  ui, css,
  feedback                           |  administration
-------------------------------------+-------------------------------------
Changes (by baikare.sandeep007):

 * Attachment "65152-final.patch" added.

 Updated patch css according to the refresh UI in 7.0

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65152>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 05:36:22 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 05:36:22 -0000
Subject: [wp-trac] [WordPress Trac] #65145: Plugins: Display plugin
 slug/identifier in Installed Plugins row meta
In-Reply-To: <052.c963c996c75cb96bcb429195e4caec32@wordpress.org>
References: <052.c963c996c75cb96bcb429195e4caec32@wordpress.org>
Message-ID: <067.73ffbe7f6c750e8cc6d64826824b58cc@wordpress.org>

#65145: Plugins: Display plugin slug/identifier in Installed Plugins row meta
-------------------------+------------------------------
 Reporter:  crweiner     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Plugins      |     Version:  6.9.4
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  administration
-------------------------+------------------------------

Comment (by hbhalodia):

 +1 to @westonruter. I’ve also noticed that retrieving the slug from the
 plugin UI list page can be useful in many cases.

 Adding this information to the UI is unlikely to impact regular users.
 While it may not be particularly meaningful to them, it wouldn’t clutter
 the plugin list page significantly and can be easily ignored.

 For developers, however, it provides clear value by eliminating the need
 to run CLI commands. In many scenarios, accessing the server via SSH and
 executing commands involves multiple steps, so having this information
 readily available in the UI would be a more straightforward IMO.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65145#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 05:53:25 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 05:53:25 -0000
Subject: [wp-trac] [WordPress Trac] #65145: Plugins: Display plugin
 slug/identifier in Installed Plugins row meta
In-Reply-To: <052.c963c996c75cb96bcb429195e4caec32@wordpress.org>
References: <052.c963c996c75cb96bcb429195e4caec32@wordpress.org>
Message-ID: <067.6caa0bd3a56bd1cbe87c7ff0e95ce938@wordpress.org>

#65145: Plugins: Display plugin slug/identifier in Installed Plugins row meta
-------------------------+------------------------------
 Reporter:  crweiner     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Plugins      |     Version:  6.9.4
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  administration
-------------------------+------------------------------

Comment (by westonruter):

 A possibility is to add a Slug column but which is hidden by default. A
 developer could then go up to Screen Options to enable showing the Slug
 column. Other users would not see it unless they opt in as well.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65145#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 06:28:41 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 06:28:41 -0000
Subject: [wp-trac] [WordPress Trac] #65145: Plugins: Display plugin
 slug/identifier in Installed Plugins row meta
In-Reply-To: <052.c963c996c75cb96bcb429195e4caec32@wordpress.org>
References: <052.c963c996c75cb96bcb429195e4caec32@wordpress.org>
Message-ID: <067.7baecbde71b23df8aeb20a113592e9c7@wordpress.org>

#65145: Plugins: Display plugin slug/identifier in Installed Plugins row meta
-------------------------+------------------------------
 Reporter:  crweiner     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Plugins      |     Version:  6.9.4
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  administration
-------------------------+------------------------------

Comment (by westonruter):

 Something else to note: "Slug" is not always sufficient to identify a
 plugin. To be entirely accurate, it should  be "File" (e.g.
 `directory/file.php`). A plugin directory can actually contain multiple
 plugin files, although this is not common (and probably isn't allowed in
 the plugin directory).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65145#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 06:28:49 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 06:28:49 -0000
Subject: [wp-trac] [WordPress Trac] #65145: Plugins: Display plugin
 slug/identifier in Installed Plugins row meta
In-Reply-To: <052.c963c996c75cb96bcb429195e4caec32@wordpress.org>
References: <052.c963c996c75cb96bcb429195e4caec32@wordpress.org>
Message-ID: <067.27997d8c92e0c4fa04385bcb1553b0e4@wordpress.org>

#65145: Plugins: Display plugin slug/identifier in Installed Plugins row meta
-------------------------+------------------------------
 Reporter:  crweiner     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Plugins      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  administration
-------------------------+------------------------------
Changes (by westonruter):

 * version:  6.9.4 =>


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65145#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 06:36:50 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 06:36:50 -0000
Subject: [wp-trac] [WordPress Trac] #64863: Eliminate switch_to_blog()
 from get_blog_option(), update_blog_option(), WP_Site::get_details(),
 and get_blog_post() using $wpdb->get_blog_prefix()
In-Reply-To: <048.0ef7ca6adc3207801ef5032e49bb54d6@wordpress.org>
References: <048.0ef7ca6adc3207801ef5032e49bb54d6@wordpress.org>
Message-ID: <063.b51fafe4da8762ab3c81f6996345ba3d@wordpress.org>

#64863: Eliminate switch_to_blog() from get_blog_option(), update_blog_option(),
WP_Site::get_details(), and get_blog_post() using $wpdb->get_blog_prefix()
-------------------------------------------------+-------------------------
 Reporter:  PerS                                 |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  Networks and Sites                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing has-unit-    |     Focuses:  multisite,
  tests                                          |  performance
-------------------------------------------------+-------------------------

Comment (by PerS):

 Benchmark is available at
 https://gist.github.com/soderlind/4c621915e170762ae863135dfed11c47

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64863#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 06:41:50 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 06:41:50 -0000
Subject: [wp-trac] [WordPress Trac] #64927: .media-upload-form
 .media-item min-height is causing a visual glitch
In-Reply-To: <053.5c06c7f70bc7b6efbbefc59207e6c811@wordpress.org>
References: <053.5c06c7f70bc7b6efbbefc59207e6c811@wordpress.org>
Message-ID: <068.4858e58514737f39a7b1c8ee2804c5df@wordpress.org>

#64927: .media-upload-form .media-item min-height is causing a visual glitch
---------------------------------------+------------------------------
 Reporter:  Presskopp                  |       Owner:  (none)
     Type:  defect (bug)               |      Status:  new
 Priority:  normal                     |   Milestone:  Awaiting Review
Component:  Media                      |     Version:
 Severity:  normal                     |  Resolution:
 Keywords:  has-screenshots has-patch  |     Focuses:  ui
---------------------------------------+------------------------------

Comment (by hbhalodia):

 Hi @Presskopp @shreyasikhar26, I am able to reproduce the issue. There is
 a min-height added to the `.media-upload-form .media-item` class and seems
 to be redundant. The message will take the height as expected instead of
 setting it a fix value.

 I have raised the PR to fix the same remove the extra spacing.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64927#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 06:50:50 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 06:50:50 -0000
Subject: [wp-trac] [WordPress Trac] #65154: Dashboard widgets empty
 container alignment issue
Message-ID: <056.4629fd86807e4b7c45b98b75c87dfba5@wordpress.org>

#65154: Dashboard widgets empty container alignment issue
--------------------------------+-----------------------------
 Reporter:  umesh.nevase        |      Owner:  (none)
     Type:  defect (bug)        |     Status:  new
 Priority:  normal              |  Milestone:  Awaiting Review
Component:  Administration      |    Version:  trunk
 Severity:  normal              |   Keywords:
  Focuses:  ui, administration  |
--------------------------------+-----------------------------
 The empty container for drag and drop dashboard widget having extra
 margin. which is making mis alignment for 4px with other widgets and
 spacing from the right. If we remove extra margin then the alignment
 showing correct.

 This issue is introduced in https://core.trac.wordpress.org/ticket/64743.
 There are some issues also fixed for spacing and alignment on dashboard
 widgets in https://core.trac.wordpress.org/ticket/64739.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65154>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 06:51:31 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 06:51:31 -0000
Subject: [wp-trac] [WordPress Trac] #65154: Dashboard widgets empty
 container alignment issue
In-Reply-To: <056.4629fd86807e4b7c45b98b75c87dfba5@wordpress.org>
References: <056.4629fd86807e4b7c45b98b75c87dfba5@wordpress.org>
Message-ID: <071.5bda8793856a713b0c04f7a10365de69@wordpress.org>

#65154: Dashboard widgets empty container alignment issue
----------------------------+---------------------------------
 Reporter:  umesh.nevase    |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:  ui, administration
----------------------------+---------------------------------
Changes (by umesh.nevase):

 * Attachment "before.png" added.


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65154>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 06:52:13 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 06:52:13 -0000
Subject: [wp-trac] [WordPress Trac] #65154: Dashboard widgets empty
 container alignment issue
In-Reply-To: <056.4629fd86807e4b7c45b98b75c87dfba5@wordpress.org>
References: <056.4629fd86807e4b7c45b98b75c87dfba5@wordpress.org>
Message-ID: <071.513ae15015397f420d5fd37deac91111@wordpress.org>

#65154: Dashboard widgets empty container alignment issue
----------------------------+---------------------------------
 Reporter:  umesh.nevase    |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:  ui, administration
----------------------------+---------------------------------
Changes (by umesh.nevase):

 * Attachment "after.png" added.

 The alignment of empty container after removed margin and applied fix

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65154>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 06:52:18 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 06:52:18 -0000
Subject: [wp-trac] [WordPress Trac] #65154: Dashboard widgets empty
 container alignment issue
In-Reply-To: <056.4629fd86807e4b7c45b98b75c87dfba5@wordpress.org>
References: <056.4629fd86807e4b7c45b98b75c87dfba5@wordpress.org>
Message-ID: <071.d9eb741a4471be99f653bab44ff53e46@wordpress.org>

#65154: Dashboard widgets empty container alignment issue
----------------------------+---------------------------------
 Reporter:  umesh.nevase    |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:  ui, administration
----------------------------+---------------------------------
Changes (by umesh.nevase):

 * Attachment "after.2.png" added.

 The alignment of empty container after removed margin and applied fix

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65154>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 07:00:23 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 07:00:23 -0000
Subject: [wp-trac] [WordPress Trac] #65145: Plugins: Display plugin
 slug/identifier in Installed Plugins row meta
In-Reply-To: <052.c963c996c75cb96bcb429195e4caec32@wordpress.org>
References: <052.c963c996c75cb96bcb429195e4caec32@wordpress.org>
Message-ID: <067.b3487812503e3bf989f8410bc39d5f9e@wordpress.org>

#65145: Plugins: Display plugin slug/identifier in Installed Plugins row meta
-------------------------+------------------------------
 Reporter:  crweiner     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Plugins      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  administration
-------------------------+------------------------------

Comment (by hbhalodia):

 That approach makes sense. I support the idea of adding this option under
 **Screen Options**, allowing users to enable or disable it similar to how
 **Description** and **Automatic Updates** are handled.

 Developers or advanced users could opt in to display it as a standalone
 column (positioned after the plugin name and before the description),
 while keeping it disabled by default.

 This would be a more suitable solution, as it preserves the existing
 plugin metadata and layout, ensuring no disruption to the default
 experience for regular users while still providing additional
 functionality for those who need it.

 Before proceeding and updating the PR, I would like more of the users to
 check the viable option and then we can decide to provide a support or
 not.

 Thanks,

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65145#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 08:05:40 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 08:05:40 -0000
Subject: [wp-trac] [WordPress Trac] #65145: Plugins: Display plugin
 slug/identifier in Installed Plugins row meta
In-Reply-To: <052.c963c996c75cb96bcb429195e4caec32@wordpress.org>
References: <052.c963c996c75cb96bcb429195e4caec32@wordpress.org>
Message-ID: <067.90bc2e321fd80a4f6594fe8225a69c1b@wordpress.org>

#65145: Plugins: Display plugin slug/identifier in Installed Plugins row meta
-------------------------+------------------------------
 Reporter:  crweiner     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Plugins      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  administration
-------------------------+------------------------------

Comment (by wildworks):

 > A possibility is to add a Slug column but which is hidden by default.

 Yes, this approach might be good.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65145#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 08:15:05 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 08:15:05 -0000
Subject: [wp-trac] [WordPress Trac] #65143: Add polyfill for PHP 8.6's
 clamp() function
In-Reply-To: <049.bfe1585db563ebd1d079384363f22ec8@wordpress.org>
References: <049.bfe1585db563ebd1d079384363f22ec8@wordpress.org>
Message-ID: <064.641e39e47d9e22f349413171c27af2dd@wordpress.org>

#65143: Add polyfill for PHP 8.6's clamp() function
-------------------------+--------------------------------
 Reporter:  Soean        |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  php-compatibility
-------------------------+--------------------------------

Comment (by Soean):

 @westonruter I added two places to the PR, where we can use it in Core.

 Providing a polyfill in WordPress Core ensures that plugin and theme
 developers can use it consistently across all supported PHP versions
 without needing to implement their own.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65143#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 08:41:35 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 08:41:35 -0000
Subject: [wp-trac] [WordPress Trac] #65150: Issue with copy_dir()
 function t does not skips folders.
In-Reply-To: <051.3ea19f390e67542b3753efde0bd26330@wordpress.org>
References: <051.3ea19f390e67542b3753efde0bd26330@wordpress.org>
Message-ID: <066.608f8e40a3a0d6616804948f7b8ea474@wordpress.org>

#65150: Issue with copy_dir() function  t does not skips folders.
----------------------------+------------------------------
 Reporter:  neo2k23         |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Filesystem API  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+------------------------------

Comment (by neo2k23):

 Hi @hbhalodia

 Thank you for explaining this.  It is really appreciated.  I can confirm
 that all is working now with the change made to the copy_dir function.

 I did various test and all went ok.

 Have a great day & thank you!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65150#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 08:48:53 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 08:48:53 -0000
Subject: [wp-trac] [WordPress Trac] #64762: Frontend admin toolbar not
 using updated admin color scheme
In-Reply-To: <059.0e31afc455ee11847f5a061f732569ee@wordpress.org>
References: <059.0e31afc455ee11847f5a061f732569ee@wordpress.org>
Message-ID: <074.84ea2e6c3831ffb0d528d216c93efb5d@wordpress.org>

#64762: Frontend admin toolbar not using updated admin color scheme
-------------------------------------------------+-------------------------
 Reporter:  huzaifaalmesbah                      |       Owner:  audrasjb
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Toolbar                              |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-screenshots admin-reskin has-    |     Focuses:  ui, css
  patch has-unit-tests                           |
-------------------------------------------------+-------------------------

Comment (by wildworks):

 For the 7.0 release, it might be better to ship
 [https://github.com/WordPress/wordpress-develop/pull/11354/ PR 11354],
 which has a minimal approach.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64762#comment:47>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 08:54:25 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 08:54:25 -0000
Subject: [wp-trac] [WordPress Trac] #53995: Application Passwords
 Expiration
In-Reply-To: <051.9000bbf0c2d52a1c7073a68962010120@wordpress.org>
References: <051.9000bbf0c2d52a1c7073a68962010120@wordpress.org>
Message-ID: <066.3433b3f44d7346f6a79f06506a454222@wordpress.org>

#53995: Application Passwords Expiration
-------------------------------------------------+-------------------------
 Reporter:  mboynes                              |       Owner:  (none)
     Type:  feature request                      |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  Application Passwords                |     Version:  5.6
 Severity:  normal                               |  Resolution:
 Keywords:  needs-design needs-docs has-patch    |     Focuses:  rest-api
  has-unit-tests                                 |
-------------------------------------------------+-------------------------
Changes (by lakshyajeet):

 * Attachment "application_password_expiry.mp4" added.

 Application password expiry UI

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/53995>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 10:02:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 10:02:16 -0000
Subject: [wp-trac] [WordPress Trac] #65150: Issue with copy_dir()
 function t does not skips folders.
In-Reply-To: <051.3ea19f390e67542b3753efde0bd26330@wordpress.org>
References: <051.3ea19f390e67542b3753efde0bd26330@wordpress.org>
Message-ID: <066.dcf9d94865b7e0aaee244e9f31a197d3@wordpress.org>

#65150: Issue with copy_dir() function  t does not skips folders.
----------------------------+------------------------------
 Reporter:  neo2k23         |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Filesystem API  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+------------------------------

Comment (by hbhalodia):

 Replying to [comment:7 neo2k23]:
 > Hi @hbhalodia
 >
 > Thank you for explaining this.  It is really appreciated.  I can confirm
 that all is working now with the change made to the copy_dir function.
 >
 > I did various test and all went ok.
 >
 > Have a great day & thank you!
 >

 Thanks @neo2k23

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65150#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 10:41:52 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 10:41:52 -0000
Subject: [wp-trac] [WordPress Trac] #65151: Dashboard Widgets not
 draggable
In-Reply-To: <053.4ebfa4149ba2f1d9f36f7cdbdf8c4670@wordpress.org>
References: <053.4ebfa4149ba2f1d9f36f7cdbdf8c4670@wordpress.org>
Message-ID: <068.e9a4c470e80d331221ca4446119365b9@wordpress.org>

#65151: Dashboard Widgets not draggable
----------------------------+----------------------
 Reporter:  Presskopp       |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  7.0
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  admin-reskin    |     Focuses:  ui, css
----------------------------+----------------------
Changes (by ozgursar):

 * Attachment "widget-drag-issue.mp4" added.

 Widget drag drop

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65151>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 10:46:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 10:46:14 -0000
Subject: [wp-trac] [WordPress Trac] #65151: Dashboard Widgets not
 draggable
In-Reply-To: <053.4ebfa4149ba2f1d9f36f7cdbdf8c4670@wordpress.org>
References: <053.4ebfa4149ba2f1d9f36f7cdbdf8c4670@wordpress.org>
Message-ID: <068.29e08f72c77ffaa10fdd0b05b38df406@wordpress.org>

#65151: Dashboard Widgets not draggable
------------------------------------------+----------------------
 Reporter:  Presskopp                     |       Owner:  (none)
     Type:  defect (bug)                  |      Status:  new
 Priority:  normal                        |   Milestone:  7.0
Component:  Administration                |     Version:  trunk
 Severity:  normal                        |  Resolution:
 Keywords:  admin-reskin has-screenshots  |     Focuses:  ui, css
------------------------------------------+----------------------
Changes (by ozgursar):

 * keywords:  admin-reskin => admin-reskin has-screenshots


Comment:

 == Reproduction Report

 === Environment
 - WordPress: 7.1-alpha-62284
 - PHP: 8.3.30
 - Server: PHP.wasm
 - Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.51.0)
 - Browser: Opera
 - OS: macOS
 - Theme: Twenty Twenty-Five 1.4
 - MU Plugins: None activated
 - Plugins:
   * Test Reports 1.2.1

 === Steps taken
 1. Randomly drag and drop widgets on admin dashboard
 2. Observe that if the drag requires `scroll`, widget may not be dropped
 to the desired position
 3. 🐞 Bug occurs

 === Expected behavior
 - Even the browser height is not enough, scrolling should not affect drag
 behavior.

 === Additional Notes
 - I found that if the browser height is enough, widget can be dropped
 easily. If the drag involves scrolling at the same time, widget (probably
 depending on its own height) may not be dragged if its new position is
 below certain level.

 === Screenshots/Screencast with results
 https://core.trac.wordpress.org/attachment/ticket/65151/widget-drag-
 issue.mp4

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65151#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 10:47:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 10:47:56 -0000
Subject: [wp-trac] [WordPress Trac] #65150: Issue with copy_dir()
 function t does not skips folders.
In-Reply-To: <051.3ea19f390e67542b3753efde0bd26330@wordpress.org>
References: <051.3ea19f390e67542b3753efde0bd26330@wordpress.org>
Message-ID: <066.4839150ff75d5ae3ee485ada716887bb@wordpress.org>

#65150: Issue with copy_dir() function  t does not skips folders.
----------------------------+------------------------------
 Reporter:  neo2k23         |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Filesystem API  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+------------------------------

Comment (by neo2k23):

 @hbhalodia

 I am flabbergasted that this bug exists since wp 3.7.0 (october 24 2013)
 and nobody ever noticed this.By accident I stumbled across this, because
 the theme activated was using a renamed _theme_copy_dir function in its
 code to copy files and I wanted to get rid of it by calling the default wp
 code.

 I am glad it will be resolved soon in a WordPress update.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65150#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 11:59:24 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 11:59:24 -0000
Subject: [wp-trac] [WordPress Trac] #65084: Update error message for
 disallowed username characters
In-Reply-To: <049.08ea48590412276562d442dabf255033@wordpress.org>
References: <049.08ea48590412276562d442dabf255033@wordpress.org>
Message-ID: <064.edf3c00f1f8940f58a085cd29577877e@wordpress.org>

#65084: Update error message for disallowed username characters
-------------------------------------------------+-------------------------
 Reporter:  Marc4                                |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  General                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch reporter-feedback has-     |     Focuses:  ui-copy
  unit-tests needs-refresh                       |
-------------------------------------------------+-------------------------

Comment (by shreyasikhar26):

 Thanks @dhruvang21, I have updated the same PR by replacing `unallowed`
 with `disallowed`.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65084#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 11:59:51 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 11:59:51 -0000
Subject: [wp-trac] [WordPress Trac] #65020: Connectors: Support custom
 plugin is_active callback in connector registry and plugin status output
In-Reply-To: <055.d405075069acea8d9ef2197fb71ff599@wordpress.org>
References: <055.d405075069acea8d9ef2197fb71ff599@wordpress.org>
Message-ID: <070.0980553bf5bf3a9a5b291efcf7945007@wordpress.org>

#65020: Connectors: Support custom plugin is_active callback in connector registry
and plugin status output
-----------------------------------------+------------------------------
 Reporter:  iamadisingh                  |       Owner:  (none)
     Type:  defect (bug)                 |      Status:  new
 Priority:  normal                       |   Milestone:  Awaiting Review
Component:  AI                           |     Version:  trunk
 Severity:  normal                       |  Resolution:
 Keywords:  connectors has-patch commit  |     Focuses:
-----------------------------------------+------------------------------
Changes (by gziolo):

 * keywords:  connectors dev-feedback has-patch => connectors has-patch
               commit


Comment:

 All good on my end. I verified the changes. You can proceed further.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65020#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 12:02:04 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 12:02:04 -0000
Subject: [wp-trac] [WordPress Trac] #47552: post_name when inserting is
 not guaranteed to be unique
In-Reply-To: <051.6f54941eff5b5114d27ceb56fc2a08ec@wordpress.org>
References: <051.6f54941eff5b5114d27ceb56fc2a08ec@wordpress.org>
Message-ID: <066.880e8124c58c4f33b400195008ad673d@wordpress.org>

#47552: post_name when inserting is not guaranteed to be unique
--------------------------------------------+-----------------------------
 Reporter:  domslee                         |       Owner:  (none)
     Type:  defect (bug)                    |      Status:  new
 Priority:  normal                          |   Milestone:  Future Release
Component:  Posts, Post Types               |     Version:
 Severity:  normal                          |  Resolution:
 Keywords:  has-test-info needs-unit-tests  |     Focuses:
--------------------------------------------+-----------------------------
Changes (by sukhendu2002):

 * keywords:  has-test-info needs-unit-tests has-patch => has-test-info
     needs-unit-tests


-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/47552#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 12:16:36 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 12:16:36 -0000
Subject: [wp-trac] [WordPress Trac] #65020: Connectors: Support custom
 plugin is_active callback in connector registry and plugin status output
In-Reply-To: <055.d405075069acea8d9ef2197fb71ff599@wordpress.org>
References: <055.d405075069acea8d9ef2197fb71ff599@wordpress.org>
Message-ID: <070.f4468aed9e6363b432ef98b18413f22e@wordpress.org>

#65020: Connectors: Support custom plugin is_active callback in connector registry
and plugin status output
-----------------------------------------+-------------------------------
 Reporter:  iamadisingh                  |       Owner:  jorgefilipecosta
     Type:  defect (bug)                 |      Status:  closed
 Priority:  normal                       |   Milestone:  Awaiting Review
Component:  AI                           |     Version:  trunk
 Severity:  normal                       |  Resolution:  fixed
 Keywords:  connectors has-patch commit  |     Focuses:
-----------------------------------------+-------------------------------
Changes (by jorgefilipecosta):

 * owner:  (none) => jorgefilipecosta
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62288" 62288]:
 {{{
 #!CommitTicketReference repository="" revision="62288"
 Connectors: Add `is_active` callback support to plugin registration.

 Adds an optional `is_active` callable to the `plugin` definition accepted
 by
 `WP_Connector_Registry::register()`. The callback receives no arguments,
 must
 return a boolean, and is used by the Connectors screen to decide whether a
 connector's backing plugin is currently active. When omitted, it defaults
 to
 `__return_true`; when provided but not callable, registration fails with a
 `_doing_it_wrong()` notice.

 Developed in: https://github.com/WordPress/wordpress-develop/pull/11565

 Props iamadisingh, jorgefilipecosta, mukesh27, gziolo.
 Fixes #65020.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65020#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 12:18:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 12:18:33 -0000
Subject: [wp-trac] [WordPress Trac] #65141: Fix alignment for sortable
 metabox on post and page edit screen with classic editor
In-Reply-To: <056.a2041e2c35d0005f2c335a081657df6e@wordpress.org>
References: <056.a2041e2c35d0005f2c335a081657df6e@wordpress.org>
Message-ID: <071.3e0f669b312b138ede882856951ae384@wordpress.org>

#65141: Fix alignment for sortable metabox on post and page edit screen with
classic editor
-------------------------------------------------+-------------------------
 Reporter:  umesh.nevase                         |       Owner:
                                                 |  SergeyBiryukov
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Editor                               |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch admin-reskin commit dev-   |     Focuses:  ui, css
  reviewed                                       |
-------------------------------------------------+-------------------------
Changes (by TobiasBg):

 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Replying to [comment:2 sabernhardt]:
 > [61646] added the 4-pixel padding to sortable metaboxes in the
 dashboard, classic post editor, and media editor.

 So, the padding was now removed again, but [61646] also added a negative
 `-4px` margin on `#poststuff #post-body`. I think this should be reverted
 as well, as it otherwise pulls the editor to the left a bit (with Classic
 Editor).

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65141#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 13:29:45 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 13:29:45 -0000
Subject: [wp-trac] [WordPress Trac] #65155: wrong aspect-ratio of pictures
 in the galerie with Firefox 150
Message-ID: <055.c1ffb70f6e1daf63ab16bc4a2d4c08f5@wordpress.org>

#65155: wrong aspect-ratio of pictures in the galerie with Firefox 150
--------------------------+-----------------------------
 Reporter:  fotodrachen   |      Owner:  (none)
     Type:  defect (bug)  |     Status:  assigned
 Priority:  normal        |  Milestone:  Awaiting Review
Component:  Gallery       |    Version:  6.9.4
 Severity:  normal        |   Keywords:
  Focuses:                |
--------------------------+-----------------------------
 WordPress 6.9.4.
 Element "**Galerie**" (in addition "Simple Lightbox" 2.9.5).
 More than one row of pictures on a page.
 Galerie-configuration:
  - NO crop of the pictures.
  - Aspect-Ratio original.

 The first row of pictures in the first galerie on the page is Okay. Each
 picture has its individual aspect-ratio.
 In the following rows the **pictures have a unique size**. They are
 **streched** to 2:1 to fit this size.

 This happens only with the latest Firefox-Browser 150.0.1 on Linux or
 Windows.
 The error NOT occurs in Brave, Edge or Chrome.

 The following change fixed the error for me:

 File "/wp/wp-includes/blocks/gallery/style.css"

 OLD
 {{{
 .wp-block-gallery.has-nested-images figure.wp-block-image img {
   display: block;
   height: auto;
   max-width: 100% !important;
   width: auto;
 }
 }}}

 NEW
 {{{
 .wp-block-gallery.has-nested-images figure.wp-block-image img {
   display: block;
   width: 100%;
   height: auto;
   object-fit: cover;
 }
 }}}

 Minimize to /wp/wp-includes/blocks/gallery/style.min.css

 See also:

 https://wpde.org/thread/203056-verzerrte-bilder-in-der-gallerie-in-
 firefox/
 Some say the css is wrong, others say it's a bug in Firefox.

 https://bugzilla.mozilla.org/show_bug.cgi?id=2034897

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65155>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 13:33:55 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 13:33:55 -0000
Subject: [wp-trac] [WordPress Trac] #65155: wrong aspect-ratio of
 pictures in the galerie with Firefox 150
In-Reply-To: <055.c1ffb70f6e1daf63ab16bc4a2d4c08f5@wordpress.org>
References: <055.c1ffb70f6e1daf63ab16bc4a2d4c08f5@wordpress.org>
Message-ID: <070.3605592e9579a20074d13fd382fd13cd@wordpress.org>

#65155: wrong aspect-ratio of pictures in the galerie with Firefox 150
--------------------------+------------------------------
 Reporter:  fotodrachen   |       Owner:  (none)
     Type:  defect (bug)  |      Status:  assigned
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Gallery       |     Version:  6.9.4
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+------------------------------

Comment (by fotodrachen):

 Screenshots in the linked discussion on wpde.org

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65155#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 13:58:16 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 13:58:16 -0000
Subject: [wp-trac] [WordPress Trac] #65099: Fix: Only auto register
 settings if the plugin the connector references is installed and active
In-Reply-To: <060.0b8a8e3426646ee12db1e6e829f3d840@wordpress.org>
References: <060.0b8a8e3426646ee12db1e6e829f3d840@wordpress.org>
Message-ID: <075.c8e2883d1b85ab91d3f5b6cb36ba7680@wordpress.org>

#65099: Fix: Only auto register settings if the plugin the connector references is
installed and active
---------------------------------------------+---------------------
 Reporter:  jorgefilipecosta                 |       Owner:  (none)
     Type:  defect (bug)                     |      Status:  new
 Priority:  normal                           |   Milestone:  7.0
Component:  General                          |     Version:  trunk
 Severity:  normal                           |  Resolution:
 Keywords:  has-patch has-unit-tests commit  |     Focuses:
---------------------------------------------+---------------------
Changes (by gziolo):

 * keywords:  has-patch has-unit-tests changes-requested => has-patch has-
     unit-tests commit


Comment:

 It's looking solid after the round of feedback applied.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65099#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 14:05:20 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 14:05:20 -0000
Subject: [wp-trac] [WordPress Trac] #65099: Fix: Only auto register
 settings if the plugin the connector references is installed and active
In-Reply-To: <060.0b8a8e3426646ee12db1e6e829f3d840@wordpress.org>
References: <060.0b8a8e3426646ee12db1e6e829f3d840@wordpress.org>
Message-ID: <075.0d6deaff2c9530931a749980921042a4@wordpress.org>

#65099: Fix: Only auto register settings if the plugin the connector references is
installed and active
---------------------------------------------+-----------------------------
 Reporter:  jorgefilipecosta                 |       Owner:
                                             |  jorgefilipecosta
     Type:  defect (bug)                     |      Status:  closed
 Priority:  normal                           |   Milestone:  7.0
Component:  General                          |     Version:  trunk
 Severity:  normal                           |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests commit  |     Focuses:
---------------------------------------------+-----------------------------
Changes (by jorgefilipecosta):

 * owner:  (none) => jorgefilipecosta
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62289" 62289]:
 {{{
 #!CommitTicketReference repository="" revision="62289"
 Connectors: Gate default setting auto-registration on `is_active`.

 Update `_wp_register_default_connector_settings()` to register a
 connector's
 default API key setting only when the connector's `plugin.is_active`
 callback
 returns `true`.
 Add tests covering the gate's branches: setting skipped when `is_active`
 returns `false`, setting registered when it returns `true`.

 Props jorgefilipecosta, gziolo, peterwilsoncc.
 Fixes #65099.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65099#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 15:27:15 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 15:27:15 -0000
Subject: [wp-trac] [WordPress Trac] #37938: Make existing HTML parsing
 functionality from REST API and Press This reusable
In-Reply-To: <052.2218588b352b1536e3a7b035fc4e03f7@wordpress.org>
References: <052.2218588b352b1536e3a7b035fc4e03f7@wordpress.org>
Message-ID: <067.5f89dbdb6777668c31239675f2bb6ac8@wordpress.org>

#37938: Make existing HTML parsing functionality from REST API and Press This
reusable
-------------------------------+-----------------------------
 Reporter:  dshanske           |       Owner:  kraftbj
     Type:  enhancement        |      Status:  closed
 Priority:  low                |   Milestone:  Future Release
Component:  HTML API           |     Version:  4.2
 Severity:  minor              |  Resolution:  fixed
 Keywords:  2nd-opinion close  |     Focuses:
-------------------------------+-----------------------------
Changes (by jonsurrell):

 * status:  accepted => closed
 * resolution:   => fixed


Comment:

 Since there has been no opposition, I'll close this. The HTML API can be
 used for general HTML parsing.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/37938#comment:13>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 15:30:28 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 15:30:28 -0000
Subject: [wp-trac] [WordPress Trac] #50867: An API which encourages
 automatic escaping of HTML
In-Reply-To: <054.c2c4be12d3b282e664a3ec46964ce574@wordpress.org>
References: <054.c2c4be12d3b282e664a3ec46964ce574@wordpress.org>
Message-ID: <069.b9b21500eb9b713d5cd5af4d4c880d51@wordpress.org>

#50867: An API which encourages automatic escaping of HTML
-------------------------------------------------+-------------------------
 Reporter:  noisysocks                           |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
                                                 |  Review
Component:  HTML API                             |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-unit-tests needs-    |     Focuses:
  docs dev-feedback 2nd-opinion                  |
-------------------------------------------------+-------------------------

Comment (by jonsurrell):

 This is closely related to #60229 and HTML Templating is one possible
 solution.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/50867#comment:22>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 15:50:56 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 15:50:56 -0000
Subject: [wp-trac] [WordPress Trac] #65145: Plugins: Display plugin
 slug/identifier in Installed Plugins row meta
In-Reply-To: <052.c963c996c75cb96bcb429195e4caec32@wordpress.org>
References: <052.c963c996c75cb96bcb429195e4caec32@wordpress.org>
Message-ID: <067.7a1074098e4528f3c6681bcdd28e6651@wordpress.org>

#65145: Plugins: Display plugin slug/identifier in Installed Plugins row meta
-------------------------+------------------------------
 Reporter:  crweiner     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Plugins      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  administration
-------------------------+------------------------------

Comment (by crweiner):

 Replying to [comment:6 westonruter]:
 > A possibility is to add a Slug column but which is hidden by default. A
 developer could then go up to Screen Options to enable showing the Slug
 column. Other users would not see it unless they opt in as well.

 I think that's a great idea to make the slug selectable in Screen Options!
 It'll be out of the way, but still accessible for the devs who need it.

 Replying to [comment:7 westonruter]:
 > Something else to note: "Slug" is not always sufficient to identify a
 plugin. To be entirely accurate, it should be "File" (e.g.
 `directory/file.php`). A plugin directory can actually contain multiple
 plugin files, although this is not common (and probably isn't allowed in
 the plugin directory).

 I took a look at how the WP-CLI works with slugs, as this was my whole
 inspiration for the enhancement ticket in the first place. It seems to use
 three different ways of processing a slug, depending on the command. **Do
 note, I am not a PHP or WP-CLI expert and would highly, highly, suggest
 double checking my assumptions below.**
 * For `wp plugin list`, it uses `php/utils-wp.php` and `get_plugin_name` -
 https://github.com/wp-cli/wp-cli/blob/main/php/utils-wp.php . If I
 understand it correctly, I think it functions like this:
    * If the plugin basename has no slash, use the filename without `.php`
    * Otherwise, it uses the directory name

 * Commands like `wp plugin activate <slug>`, `wp plugin update <slug>`,
 and similar commands use `src/WP_CLI/Fetchers/Plugin.php` and
 `get_plugins` - https://github.com/wp-cli/extension-
 command/blob/main/src/WP_CLI/Fetchers/Plugin.php . I think it tries to
 match the plugin slug you type via one of three ways:
    * Exact plugin file: `directory/file.php`
    * Bare file name: `name` matches `name.php`
    * Directory name: `directory` matches `directory/file.php`

 * Installing via `wp plugin install <slug>` is different, as that uses
 `src/WP_CLI/CommandWithUpgrade.php` and `install` - https://github.com/wp-
 cli/extension-command/blob/main/src/WP_CLI/CommandWithUpgrade.php#L188
    * This first checks if it is a remote URL, local ZIP file, remote or
 local PHP file, a WP.org directory URL, then lastly a WP.org slug

 So, all of that is to say, I agree with @westonruter and it looks like a
 directory or filename-based slug column is probably the best, as that will
 match with what `wp plugin list` does (if I am understanding the code
 correctly). To have pairity with the WP-CLI, I think the slug logic would
 look like this:

 * Derive the slug from the installed plugin file:
    * `dirname( $plugin_file )` for directory plugins
    * `basename( $plugin_file, '.php' )` for single-file plugins
 * If duplicates exist (because of two plugins in the same directory), fall
 back to the plugin file without `.php`
 * We could also maybe use the exact plugin file location, like
 `directory/file.php`, if that's simpler? As long as the slug is findable
 on the page with CTRL (or CMD) + F, that would probably be good enough for
 most people.

 Would love to know everyone's thoughts!

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65145#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 16:10:29 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 16:10:29 -0000
Subject: [wp-trac] [WordPress Trac] #65145: Plugins: Display plugin
 slug/identifier in Installed Plugins row meta
In-Reply-To: <052.c963c996c75cb96bcb429195e4caec32@wordpress.org>
References: <052.c963c996c75cb96bcb429195e4caec32@wordpress.org>
Message-ID: <067.e4993e420c0f8af10deb960e7645aa9d@wordpress.org>

#65145: Plugins: Display plugin slug/identifier in Installed Plugins row meta
-------------------------+------------------------------
 Reporter:  crweiner     |       Owner:  (none)
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Plugins      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  administration
-------------------------+------------------------------

Comment (by crweiner):

 Another thought that just came to mind: I am not sure if this will work
 well for multiste installs or for people who run a non-standard WP install
 with a different directory structure than the default, such as Bedrock -
 https://roots.io/bedrock/ , or use simlinked plugins, like on WP.com. I
 don't want to cause an issue (like PHP fatals) for these kinds of sites if
 a "Slug" column is enabled in Screen Options if the code is searching for
 plugins in a folder that doesn't exist.

 We would need to not assume that plugins are always in `wp-
 content/plugins` and instead check where it is:
 https://developer.wordpress.org/apis/wp-config-php/#moving-plugin-folder .
 So, maybe showing the `plugin_basename` would be better (or at least a
 first option, before trying the directory or dropping `.php` for single-
 file plugins)?
 https://developer.wordpress.org/reference/functions/plugin_basename/

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65145#comment:12>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 16:15:33 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 16:15:33 -0000
Subject: [wp-trac] [WordPress Trac] #65154: Dashboard widgets empty
 container alignment issue
In-Reply-To: <056.4629fd86807e4b7c45b98b75c87dfba5@wordpress.org>
References: <056.4629fd86807e4b7c45b98b75c87dfba5@wordpress.org>
Message-ID: <071.9af1be986d699cc6be63d60cf3d7fabd@wordpress.org>

#65154: Dashboard widgets empty container alignment issue
----------------------------+---------------------------------
 Reporter:  umesh.nevase    |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:  ui, administration
----------------------------+---------------------------------

Comment (by abcd95):

 Looks somewhat related to #65151

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65154#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 18:35:38 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 18:35:38 -0000
Subject: [wp-trac] [WordPress Trac] #65141: Fix alignment for sortable
 metabox on post and page edit screen with classic editor
In-Reply-To: <056.a2041e2c35d0005f2c335a081657df6e@wordpress.org>
References: <056.a2041e2c35d0005f2c335a081657df6e@wordpress.org>
Message-ID: <071.41ddd939a60699135e091d35b4ab2a56@wordpress.org>

#65141: Fix alignment for sortable metabox on post and page edit screen with
classic editor
-------------------------------------------------+-------------------------
 Reporter:  umesh.nevase                         |       Owner:
                                                 |  SergeyBiryukov
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Editor                               |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch admin-reskin commit dev-   |     Focuses:  ui, css
  reviewed                                       |
-------------------------------------------------+-------------------------

Comment (by umesh.nevase):

 Yes, we can revert negative -4px margin on #poststuff #post-body which is
 not required. [PR]https://github.com/WordPress/wordpress-
 develop/pull/11689

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65141#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 18:42:36 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 18:42:36 -0000
Subject: [wp-trac] [WordPress Trac] #65154: Dashboard widgets empty
 container alignment issue
In-Reply-To: <056.4629fd86807e4b7c45b98b75c87dfba5@wordpress.org>
References: <056.4629fd86807e4b7c45b98b75c87dfba5@wordpress.org>
Message-ID: <071.105a9ddc1f3090baf5f3177cce06a3ec@wordpress.org>

#65154: Dashboard widgets empty container alignment issue
----------------------------+---------------------------------
 Reporter:  umesh.nevase    |       Owner:  (none)
     Type:  defect (bug)    |      Status:  new
 Priority:  normal          |   Milestone:  Awaiting Review
Component:  Administration  |     Version:  trunk
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:  ui, administration
----------------------------+---------------------------------

Comment (by umesh.nevase):

 Replying to [comment:2 abcd95]:
 > Looks somewhat related to #65151

 This issue concerns alignment and spacing, while
 [https://core.trac.wordpress.org/ticket/65151 #65151] addresses drag-and-
 drop behavior.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65154#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 18:49:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 18:49:48 -0000
Subject: [wp-trac] [WordPress Trac] #64987: Admin Reskin: Add more
 margin below the plugin card header
In-Reply-To: <053.b1d5d7c143cf639af6b45eb03cf6d81a@wordpress.org>
References: <053.b1d5d7c143cf639af6b45eb03cf6d81a@wordpress.org>
Message-ID: <068.ca4ac7ffcb5aa2f45525fe29c1fec881@wordpress.org>

#64987: Admin Reskin: Add more margin below the plugin card header
------------------------------------+-----------------------------
 Reporter:  wildworks               |       Owner:  SergeyBiryukov
     Type:  defect (bug)            |      Status:  closed
 Priority:  normal                  |   Milestone:  7.0
Component:  Plugins                 |     Version:
 Severity:  normal                  |  Resolution:  fixed
 Keywords:  admin-reskin has-patch  |     Focuses:
------------------------------------+-----------------------------
Changes (by SergeyBiryukov):

 * owner:  (none) => SergeyBiryukov
 * status:  new => closed
 * resolution:   => fixed


Comment:

 In [changeset:"62290" 62290]:
 {{{
 #!CommitTicketReference repository="" revision="62290"
 Admin Reskin: Add more spacing below the plugin card header.

 Follow-up to [61646].

 Props wildworks, mukesh27, shailu25, noruzzaman, darshitrajyaguru97,
 SergeyBiryukov.
 Fixes #64987.
 }}}

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64987#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 18:52:51 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 18:52:51 -0000
Subject: [wp-trac] [WordPress Trac] #64987: Admin Reskin: Add more
 margin below the plugin card header
In-Reply-To: <053.b1d5d7c143cf639af6b45eb03cf6d81a@wordpress.org>
References: <053.b1d5d7c143cf639af6b45eb03cf6d81a@wordpress.org>
Message-ID: <068.a55a9e6d50078df96aa91298fc084c96@wordpress.org>

#64987: Admin Reskin: Add more margin below the plugin card header
-------------------------------------------------+-------------------------
 Reporter:  wildworks                            |       Owner:
                                                 |  SergeyBiryukov
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  7.0
Component:  Plugins                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  admin-reskin has-patch commit dev-   |     Focuses:
  feedback                                       |
-------------------------------------------------+-------------------------
Changes (by SergeyBiryukov):

 * keywords:  admin-reskin has-patch => admin-reskin has-patch commit dev-
     feedback
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 Reopening for 7.0 consideration.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64987#comment:11>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 19:27:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 19:27:14 -0000
Subject: [wp-trac] [WordPress Trac] #65015: Connectors: Several strings
 are not translated
In-Reply-To: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
References: <051.2cae6bb1ea9ab32f5657833b0f9263d3@wordpress.org>
Message-ID: <066.55c7c19d37682fdeb330b2919cc7ced4@wordpress.org>

#65015: Connectors: Several strings are not translated
-------------------------------------------------+-------------------------
 Reporter:  369work                              |       Owner:
                                                 |  westonruter
     Type:  defect (bug)                         |      Status:  closed
 Priority:  high                                 |   Milestone:  7.0
Component:  I18N                                 |     Version:
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests connectors  |     Focuses:
  commit needs-dev-note fixed-major dev-         |
  reviewed                                       |
-------------------------------------------------+-------------------------

Comment (by westonruter):

 I found a minor issue with [62278]. Once it landed, it started causing
 test failures in the Performance Lab plugin
 ([https://github.com/WordPress/performance/pull/2463 PR]):

 {{{
 1) Test_Audit_Enqueued_Assets::test_perflab_aea_audit_enqueued_scripts
 Undefined array key "path"

 …/wp-includes/l10n.php:1242
 …/wp-includes/l10n.php:1185
 …/wp-includes/class-wp-script-modules.php:399
 …/wp-includes/class-wp-hook.php:341
 …/wp-includes/class-wp-hook.php:365
 …/wp-includes/plugin.php:522
 …/wp-includes/general-template.php:3224
 …/wordpress-phpunit/includes/utils.php:437
 …/wp-content/plugins/performance/plugins/performance-lab/tests/data/class-
 audit-assets-mock-assets.php:94
 …/wp-content/plugins/performance/plugins/performance-lab/tests/data/class-
 audit-assets-mock-assets.php:142
 …/wp-content/plugins/performance/plugins/performance-lab/tests/includes
 /site-health/audit-enqueued-assets/test-audit-enqueued-assets.php:107
 }}}

 At issue is that the unit test in the plugin
 [https://github.com/WordPress/performance/blob/5e1903cc771cff9e6af85b14938ce6639e49ba39/plugins
 /performance-lab/tests/includes/site-health/audit-enqueued-assets/test-
 audit-enqueued-assets.php#L61 was doing] this:

 {{{#!php
 <?php
 wp_enqueue_script_module( 'module1', 'https://module1.example.com',
 array(), null );
 }}}

 Note the lack of a path on the URL. This is causing the usage on
 [https://github.com/WordPress/wordpress-
 develop/blob/75b41314907d43bb111e22e305ba048bd4b90ec2/src/wp-
 includes/l10n.php#L1242 two] [https://github.com/WordPress/wordpress-
 develop/blob/75b41314907d43bb111e22e305ba048bd4b90ec2/src/wp-
 includes/l10n.php#L1268 lines] of `_load_script_textdomain_from_src()` to
 fail when it accesses `$src_url['path']`.

 Now, it is extremely unlikely for URLs to be provided to a registered
 script module that lack a path. So this is why it is minor. Nevertheless,
 this is an opportunity for hardening.

 Here's an easy way to reproduce this issue. Put the following code into a
 PHP file like `try-script-module-index-undefined-issue.php`:

 {{{#!php
 <?php
 wp_enqueue_script_module( 'module1', 'https://module1.example.com',
 array(), null );
 wp_script_modules()->print_script_module_translations();
 }}}


 The result is:

 {{{
 npm run env:cli -- eval-file try-script-module-index-undefined-issue.php

 > WordPress at 7.1.0 env:cli
 > node ./tools/local-env/scripts/docker.js exec --user wp_php cli wp eval-
 file try-script-module-index-undefined-issue.php

 Warning: Undefined array key "path" in /var/www/src/wp-includes/l10n.php
 on line 1242
 Deprecated: str_starts_with(): Passing null to parameter #1 ($haystack) of
 type string is deprecated in /var/www/src/wp-includes/l10n.php on line
 1242
 Warning: Undefined array key "path" in /var/www/src/wp-includes/l10n.php
 on line 1268
 Deprecated: str_starts_with(): Passing null to parameter #1 ($haystack) of
 type string is deprecated in /var/www/src/wp-includes/l10n.php on line
 1268
 }}}

 There are quite a lot of PHPStan issues being reported with
 `_load_script_textdomain_from_src()` which pre-exist 7.0 when the logic
 was originally located in `load_script_textdomain()`:

 ||= Line =||= Error =||
 || 1214 || Cannot call method `get()` on `mixed`. ||
 || 1217 || Parameter !#1 `$value` of function `untrailingslashit` expects
 `string`, `mixed` given. ||
 || 1242 || Cannot access offset `'path'` on `mixed`. (×2) ||
 || 1242 || Parameter !#1 `$haystack` of `str_starts_with` expects
 `string`, `mixed` given. ||
 || 1242 || Parameter !#2 `$needle` of `str_starts_with` expects `string`,
 `mixed` given. ||
 || 1243 || Cannot access offset `'host'` on `mixed`. (×2) ||
 || 1246 || Cannot access offset `'path'` on `mixed`. ||
 || 1247 || Cannot access offset `'path'` on `mixed`. ||
 || 1247 || Parameter !#1 `$string` of `strlen` expects `string`, `mixed`
 given. ||
 || 1247 || Parameter !#1 `$string` of `substr` expects `string`, `mixed`
 given. ||
 || 1249 || Cannot access offset `'path'` on `mixed`. ||
 || 1251 || Parameter !#1 `$str` of `trim` expects `string`, `mixed` given.
 ||
 || 1268 || Cannot access offset `'path'` on `mixed`. (×2) ||
 || 1268 || Parameter !#1 `$haystack` of `str_starts_with` expects
 `string`, `mixed` given. ||
 || 1268 || Parameter !#2 `$needle` of `str_starts_with` expects `string`,
 `mixed` given. ||
 || 1269 || Cannot access offset `'host'` on `mixed`. (×2) ||
 || 1272 || Cannot access offset `'path'` on `mixed`. ||
 || 1273 || Cannot access offset `'path'` on `mixed`. ||
 || 1273 || Parameter !#1 `$string` of `strlen` expects `string`, `mixed`
 given. ||
 || 1273 || Parameter !#1 `$string` of `substr` expects `string`, `mixed`
 given. ||
 || 1275 || Cannot access offset `'path'` on `mixed`. ||
 || 1277 || Parameter !#1 `$str` of `trim` expects `string`, `mixed` given.
 ||
 || 1284 || Cannot access offset `'host'` on `mixed`. (×2) ||
 || 1285 || Cannot access offset `'path'` on `mixed`. ||
 || 1286 || Cannot access offset `'path'` on `mixed`. ||
 || 1286 || Parameter !#1 `$str` of `trim` expects `string`, `mixed` given.
 ||
 || 1287 || Cannot access offset `'path'` on `mixed`. ||
 || 1287 || Parameter !#1 `$haystack` of `str_starts_with` expects
 `string`, `mixed` given. ||
 || 1287 || Parameter !#1 `$value` of `trailingslashit` expects `string`,
 `mixed` given. ||
 || 1289 || Cannot access offset `'path'` on `mixed`. ||
 || 1289 || Parameter !#1 `$string` of `strlen` expects `string`, `mixed`
 given. ||
 || 1289 || Parameter !#1 `$string` of `substr` expects `string`, `mixed`
 given. ||
 || 1312 || Parameter !#1 `$haystack` of `str_ends_with` expects `string`,
 `mixed` given. ||
 || 1313 || Parameter !#1 `$string` of `substr` expects `string`, `mixed`
 given. ||
 || 1316 || Parameter !#1 `$str` of `md5` expects `string`, `mixed` given.
 ||

 I've opened a [https://github.com/WordPress/wordpress-develop/pull/11690
 pull request] to fix the undefined index error, as well as to fix the
 remaining PHPStan at level 10, which primarily involves a few fixes to
 `_load_script_textdomain_from_src()` but primarily it involves adding a
 conditional return type for `wp_parse_url()`.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65015#comment:47>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 20:14:01 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 20:14:01 -0000
Subject: [wp-trac] [WordPress Trac] #60229: HTML API: Introduce HTML
 Templating
In-Reply-To: <051.9295818134ca7d080730c7110cf61b81@wordpress.org>
References: <051.9295818134ca7d080730c7110cf61b81@wordpress.org>
Message-ID: <066.e7199c95110409b79364e27dd7c816e4@wordpress.org>

#60229: HTML API: Introduce HTML Templating
-------------------------------------------------+-------------------------
 Reporter:  dmsnell                              |       Owner:  (none)
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  7.1
Component:  HTML API                             |     Version:  6.5
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests needs-dev-  |     Focuses:
  note dev-feedback                              |
-------------------------------------------------+-------------------------
Description changed by westonruter:

Old description:

> 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
> <?php
> echo WP_HTML_Template::render(
>         <<<HTML
> <a href="</%url>">
>         <img src="</%url>">
>         </%url>
> </a>
> HTML,
>         array( 'url' =>
> 'https://s.wp.com/i/atat.png?w=640&h=480&alt="atat>atst"' ),
> );
> }}}
>
> outputs
>
> {{{
> <a
> href="https://s.wp.com/i/atat.png?w=640&amp;h=480&amp;alt=&quot;atat&gt;atst&quot;">
> <img
> src="https://s.wp.com/i/atat.png?w=640&amp;h=480&amp;alt=&quot;atat&gt;atst&quot;">
> https://s.wp.com/i/atat.png?w=640&amp;h=480&amp;alt=&quot;atat&gt;atst&quot;
> </a>
> }}}
>
> 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.
>
> == Related work
>
>  - #50867 An API which encourages automatic escaping of HTML
>  - [https://github.com/WordPress/wordpress-develop/pull/5884 PR #5884]
> Introduce WP_HTML::tag() for safely creating HTML

New description:

 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
 <?php
 echo WP_HTML_Template::render(
         <<<HTML
         <a href="</%url>">
                 <img src="</%url>">
                 </%url>
         </a>
         HTML,
         array( 'url' =>
 'https://s.wp.com/i/atat.png?w=640&h=480&alt="atat>atst"' ),
 );
 }}}

 outputs

 {{{
 <a
 href="https://s.wp.com/i/atat.png?w=640&amp;h=480&amp;alt=&quot;atat&gt;atst&quot;">
 <img
 src="https://s.wp.com/i/atat.png?w=640&amp;h=480&amp;alt=&quot;atat&gt;atst&quot;">
 https://s.wp.com/i/atat.png?w=640&amp;h=480&amp;alt=&quot;atat&gt;atst&quot;
 </a>
 }}}

 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.

 == Related work

  - #50867 An API which encourages automatic escaping of HTML
  - [https://github.com/WordPress/wordpress-develop/pull/5884 PR #5884]
 Introduce WP_HTML::tag() for safely creating HTML

--

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/60229#comment:23>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 20:17:14 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 20:17:14 -0000
Subject: [wp-trac] [WordPress Trac] #65143: Add polyfill for PHP 8.6's
 clamp() function
In-Reply-To: <049.bfe1585db563ebd1d079384363f22ec8@wordpress.org>
References: <049.bfe1585db563ebd1d079384363f22ec8@wordpress.org>
Message-ID: <064.2c9747e3ef22f1378c775160297da8af@wordpress.org>

#65143: Add polyfill for PHP 8.6's clamp() function
-------------------------+--------------------------------
 Reporter:  Soean        |       Owner:  westonruter
     Type:  enhancement  |      Status:  reviewing
 Priority:  normal       |   Milestone:  7.1
Component:  General      |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  has-patch    |     Focuses:  php-compatibility
-------------------------+--------------------------------
Changes (by westonruter):

 * owner:  (none) => westonruter
 * status:  new => reviewing
 * milestone:  Awaiting Review => 7.1


Comment:

 Great. Let's get this in the queue for 7.1.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65143#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 23:31:48 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 23:31:48 -0000
Subject: [wp-trac] [WordPress Trac] #65156: Create Card
Message-ID: <058.894ad8afe4e7d458380ec5aa1ab13fb5@wordpress.org>

#65156: Create Card
----------------------------+-----------------------------
 Reporter:  theresareddish  |      Owner:  (none)
     Type:  defect (bug)    |     Status:  new
 Priority:  normal          |  Milestone:  Awaiting Review
Component:  General         |    Version:
 Severity:  normal          |   Keywords:
  Focuses:                  |
----------------------------+-----------------------------
 Create Card is not showing drop down options for Author, Category, Cuisine
 etc. And when we enter them in manually they do not stay there.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65156>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

From noreply at wordpress.org  Thu Apr 30 23:55:15 2026
From: noreply at wordpress.org (WordPress Trac)
Date: Thu, 30 Apr 2026 23:55:15 -0000
Subject: [wp-trac] [WordPress Trac] #65156: Create Card
In-Reply-To: <058.894ad8afe4e7d458380ec5aa1ab13fb5@wordpress.org>
References: <058.894ad8afe4e7d458380ec5aa1ab13fb5@wordpress.org>
Message-ID: <073.0e3f8c1b021657d1e340310c29dfb17f@wordpress.org>

#65156: Create Card
----------------------------+----------------------
 Reporter:  theresareddish  |       Owner:  (none)
     Type:  defect (bug)    |      Status:  closed
 Priority:  normal          |   Milestone:
Component:  General         |     Version:
 Severity:  normal          |  Resolution:  invalid
 Keywords:                  |     Focuses:
----------------------------+----------------------
Changes (by westonruter):

 * status:  new => closed
 * resolution:   => invalid
 * milestone:  Awaiting Review =>


Comment:

 Sorry you're having trouble. However, you seem to be reporting an issue
 for a theme or plugin. WordPress core does not have "Cards". Please report
 the issue to the extension that adds cards to WordPress.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/65156#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform

