` tags into the content are now affecting shortcodes and we are seeing text being automatically wrapped in `
` tags and carriage returns replaced with `
` tags.
Rather than revert to the insecure v6.2.1 we are going through shortcodes to remove any carriage returns.
Please advise.
Oliver",domainsupport,70
30017,Many automated tests are unnecessarily slow,wonderboymusic,,Build/Test Tools,,normal,normal,Future Release,task (blessed),assigned,2014-10-17T02:07:19Z,2021-03-24T14:47:08Z,"Our test suite is getting bigger (that's good!). But many of our tests are, of necessity, integration and functional tests that require lots of setup: creating factory data, resetting globals, etc. This process can be slow (that's bad!).
Poking around in the tests, it looks like some of the worst offenders are those who create lots of database content in the `setUp()` method. Creating more dummy data than is absolutely necessary to test an assertion is - at best - wasteful. At worst, it actually introduces unnecessary variables into what is supposed to be a narrowly defined test. (Fake but illustrative example: if you create 25 posts to test some default value in `WP_Query`, you now have to worry about pagination in addition to whatever value you're testing.)
Changing existing tests is a tedious and potentially dangerous task - you don't want to introduce regressions into our regression-preventing tests. But if we can shave 10-20% off of the execution time of our suite (which I think is a pretty conservative estimate), it'd be a huge step toward getting more people to actually run the dang things, as well as things like continuous integration.
Opening this ticket for discussion and/or patches.",boonebgorges,69
13429,Updating Link URL on image within Admin with Gallery,,dev-feedback,Gallery,2.9.2,normal,normal,Future Release,defect (bug),new,2010-05-18T01:43:42Z,2023-08-24T19:53:27Z,"Image insertion no longer allows url to off site resource within Gallery.
When inserting a gallery you are unable to specify the Link URL. It keep reverting back to the default.",vshoward,69
41305,Add lazily evaluated translations,timothyblynjacobs,dev-feedback,I18N,4.8,normal,normal,Future Release,enhancement,assigned,2017-07-13T11:16:56Z,2023-05-12T12:14:20Z,"In the context of #40988, I did a few performance tests and experimented with adding a lazily evaluated translation object.
The general principle is this:
Instead of returning the resulting string of a translation, return an object for which the `__toString()` and `jsonSerialize()` methods will fetch the resulting string instead.
I tested by having the `__()` method return such a proxy object, instead of the actual translated string.
From a quick profiling run on `wptrunk.dev/wp-json/wp/v2/posts`, I got the following results:
Returning a `translate()` from `__()`:
{{{
Wall Time 162ms
CPU Time 157ms
I/O Time 5.48ms
Memory 16.5MB
Network n/a n/a n/a
SQL 4.41ms 13rq
}}}
Returning a `TranslationProxy` from `__()`:
{{{
Wall Time 144ms -19ms -14.9%
CPU Time 138ms -18ms -15.4%
I/O Time 5.33ms -154µs -3.0%
Memory 16.6MB +81.6KB n/s
Network n/a n/a n/a
SQL 4.33ms 13rq
}}}
As you can see, this shaved off almost 15% from this simple request.
It saved 2255 calls to `translate()`, 2157 calls to `get_translations_for_domain()` and, more importantly still, 2156 calls to `apply_filters()` (which could involve a lot of additional processing in some cases).
The main problem with this approach is that WordPress does not contain real type-hinting, so BC is broken wherever the proxy is not echoed, but used directly.
As we cannot possibly foresee how plugins might use their localized strings, I suggest adding new lazy variations of the translation functions. To mirror the ""echo"" variations that prefix the translation functions with an `e`, I'd suggest using the `l` prefix for these variations:
{{{#!php
// Lazily retrieve the translation of $text.
_l( $text , $domain = 'default' );
// Lazily retrieve the translation of $text and escape it for safe use in an attribute.
esc_attr_l( $text, $domain = 'default' );
// Lazily retrieve the translation of $text and escape it for safe use in HTML output.
esc_html_l( $text, $domain = 'default' );
// Lazily retrieve translated string with gettext context.
_lx( $text, $context, $domain = 'default' );
// Lazily translate string with gettext context, and escape it for safe use in an attribute.
esc_attr_lx( $text, $context, $domain = 'default' );
// Lazily translate string with gettext context, and escape it for safe use in HTML output.
esc_html_lx( $text, $context, $domain = 'default' );
}}}
Arbitrary testing has shown that using such lazily evaluated translations strategically can improve the performance by 10-30% for certain scenarios.
Implementing them in this BC fashion allows us to fine-tune Core usage and make it available to plugins, while playing it safe with existing code.",schlessera,69
18909,Bundled jQuery UI should have CSS,,close,External Libraries,3.3,normal,normal,Future Release,enhancement,assigned,2011-10-11T18:53:57Z,2022-10-04T06:37:42Z,"Now that all of jQuery UI is in core, matching CSS should also be included for use in the admin in both color schemes.
Related: #17952",helen,67
48222,"""Show password"" button overlaps with the LastPass icon",,has-patch,Login and Registration,5.3,normal,normal,Future Release,enhancement,assigned,2019-10-05T14:29:48Z,2022-09-15T20:51:47Z,"The new ""Show password"" button added to login screen in [46256] overlaps with the LastPass extension icon. Tested with Google Chrome 77 on Windows 10.
This only happens on Log In and Reset Password screens. The Edit User screen is OK, as the button there is separate from the input.",SergeyBiryukov,67
41445,post_parent can prevent media from embedding correctly,adamsilverstein,needs-unit-tests,Media,4.9.4,normal,normal,Future Release,defect (bug),reopened,2017-07-26T06:29:28Z,2024-01-26T07:46:47Z,"If media is uploaded for a post, then used as a featured image on another post, and the original parent is not accessible via the REST API (e.g. because it's in the trash, not published etc), then it cannot be embedded on the post that ''is'' accessible.
To reproduce
* make a new post with a featured image
* trash the post
* make a new post, using the first image as the featured image
* request the second post over the rest API with media embedding enabled
The media will not be embedded, instead a forbidden result will be embedded error
{{{#!json
{
""wp:featuredmedia"":[
{
""code"":""rest_forbidden"",
""message"":""You don't have permission to do this."",
""data"":{
""status"":403
}
}
]
}
}}}
See https://github.com/WP-API/WP-API/issues/2596 for the original issue. Also related is https://core.trac.wordpress.org/ticket/30691.
",loboyle,67
55603,PHP 8.2: address deprecation of the utf8_encode() and utf8_decode() functions,hellofromTonya,dev-feedback,General,6.0,normal,normal,6.6,task (blessed),assigned,2022-04-21T19:24:21Z,2024-03-06T17:40:19Z,"== Context
The [https://wiki.php.net/rfc/remove_utf8_decode_and_utf8_encode PHP RFC to remove the `utf8_encode()` and `utf8_decode()` functions] from PHP in PHP 9.0 has recently been accepted.
This means in effect that as of PHP 8.2, those functions will be deprecated and a deprecation notice will be thrown whenever they are called.
The reasoning behind the deprecation and removal is that these functions are confusing and rarely used correctly.
See the [https://wiki.php.net/rfc/remove_utf8_decode_and_utf8_encode#usage Usage section] of the RFC for an analysis of the various (mostly incorrect) uses of the functions.
== The Problem
The [https://wiki.php.net/rfc/remove_utf8_decode_and_utf8_encode#alternatives_to_removed_functionality typical replacements for these functions] are using the [https://www.php.net/manual/en/book.mbstring.php MBString extension] and/or the [https://www.php.net/manual/en/book.iconv.php Iconv extension].
As these extensions are both ''optional'' extensions in PHP, they cannot be relied on to be available in an open source context.
WordPress uses the `utf8_encode()` function a few times in the codebase:
* 1 x `utf8_encode()` in `src/wp-admin/includes/export.php`
* 2 x `utf8_encode()` in `src/wp-admin/includes/image.php`
* 1 x `utf8_encode()` in `tests/phpunit/tests/kses/php`
Aside from that the external dependency [https://github.com/JamesHeinrich/getID3 GetID3] also uses both these functions a number of times.
A search of the plugin and theme directory shows more worrying results with a plenitude of matches:
* [https://wpdirectory.net/search/01G16P0SWHB37G2965MP8R4ZYK 11247 matches in 3315 plugins], including 15 plugins with over a million installs.
* [https://wpdirectory.net/search/01G16P2K39TQ538M9KRTVXT4CA 40 matches in 22 themes].
== Options
So, what are the options we have ?
In my opinion, especially seeing how these functions are used so often in plugins, there are only two realistic options:
=== 1. We could polyfill these functions.
While some functions which may not be available are polyfilled by WP, this is generally only done to have access to ''new'' PHP functionality or to allow for using functions which require certain optional extensions to be enabled.
As far as I know, no PHP native function has ever been polyfilled due to it being removed from PHP.
**Pro**:
Relatively simple solution and everything keeps working (deprecation notices will still show when running on PHP 8.x, though these could silenced).
**Con**:
As most uses of these functions are likely to be incorrect usage (especially in plugins), these ""bugs"" will remain and not be reviewed or addressed, undercutting the improvement PHP is trying to make.
=== 2. We could make the MbString (or the Iconv) extension a requirement
At this moment, [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/class-wp-site-health.php#L876 both the MbString as well as the Iconv extension are recommended, but not required by WP].
A couple of MbString functions are also polyfilled in WP, so now might be a good time to make the MbString extension a requirement for WP.
**Pro**:
MbString being available will allow for fixing the deprecations in a forward-compatible manner. It will also allow for other code improvements to be made to improve WPs support for languages using non-latin based scripts.
**Con**:
A new requirement would be added to WP which should not be taken lightly. At the same time, it should be noted that MbString is generally enabled already anyway, so this will impact only a small percentage of users.
==== Why MbString instead of Iconv ?
While both are included (though not enabled) by default with PHP, Iconv [https://www.php.net/manual/en/iconv.requirements.php requires the `libiconv` library], which may not be available, while MbString has [https://www.php.net/manual/en/mbstring.requirements.php no external dependencies].
MbString is [https://www.php.net/manual/en/mbstring.installation.php not enabled by default in PHP], but generally ''is'' enabled in practice.
[https://www.php.net/manual/en/mbstring.installation.php Iconv is enabled by default] in PHP, but can be disabled.
Having said that, MbString offers much more functionality than the limited functionality offered by Iconv and - as indicated by a number of functions being polyfilled - is already in use in WP.
Still, it would be helpful if someone with access to the underlying statistics data collected by WP could add figures to this issue showing how often either extension is enabled on systems running WP.
== Recommendation
I'd strongly recommend option 2, but would like to hear the opinions of additional Core devs.
== Action lists
=== General
- [ ] Report the issue to GetID3
=== Action list for option 1
- [ ] Polyfill the functions.
- [ ] Review the uses of the functions in WP Core anyhow to see if those could/should be removed/the code using them should be refactored.
- [ ] Add a note about the polyfills in a dev-note with a recommendation for plugin/theme authors to review their use of these functions anyhow.
=== Action list for option 2
- [ ] Make the MbString a requirement for installing WP/in the WP bootstrapping.
- [ ] Change the MbString extension from optional to required in the Site Health component.
- [ ] Remove the current MbString related polyfills from the `compat.php` file.
- [ ] Review the uses of the functions in WP Core and replace with more appropriate alternatives.
- [ ] Add a note about the deprecation in the PHP 8.2 dev-note with a recommendation for plugin/theme authors to review their use of these functions and noting that the MbString extension can be relied upon to be available (as of WP 6.1).
",jrf,66
19859,"""Bulk Edit"" Missing The Ability To Edit Tags",oglekler,,Quick/Bulk Edit,,normal,normal,Future Release,enhancement,reopened,2012-01-20T02:56:24Z,2024-02-12T09:21:55Z,"Though I can add, remove and edit ""categories,"" I cannot do such actions to ""tags"" inside of /wp-admin/edit.php
So basically, I'm interested in a ""bulk tag editing"" GUI for the WordPress admin.
===
I was hoping to find out the status of this feature (planned, not planned, etc) but it appears that no one has spoken about this feature on the WordPress Trac.
Is there any interest in adding this feature? And could the respondent please provide any details on why or why not?
Thank you for your time.",ademos,66
37616,Replace `is_super_admin()` calls with real capability checks,,,Role/Capability,,normal,normal,Future Release,task (blessed),reviewing,2016-08-09T18:18:57Z,2017-05-08T17:18:40Z,"As discussed in Multisite office hours (https://wordpress.slack.com/archives/core-multisite/p1470762377000454), there are plans to improve capability handling in WordPress, to also support network-wide (and possibly global) capabilities. The current `is_super_admin()` check system is no actual role- and capability-based system which makes it impractical to refine roles and capabilities on this level.
While a super admin should have access to all capabilities, we should get rid of all `is_super_admin()` checks that happen outside of `WP_User` and the `map_meta_cap()` function and replace those calls with dedicated capabilities. There might be a few other occurrences where `is_super_admin()` is actually the right choice, but generally it shouldn't be used in other locations anymore. This will open up new possibilities to think about how we can implement a true role- and capability-based system beyond the scope of a site.
The hardest part of this ticket will probably be finding names for the new capabilities. The good thing is that we most likely won't need to touch any roles or adjust `map_meta_cap()` since the new capabilities should only be granted to the super admin for now anyway.
We should probably create a list of occurrences and think about names for the capabilities (or whether we can use existing capabilities) first.",flixos90,66
49151,Show a warning for plugins in WP admin that haven't received updates in a long time,audrasjb*,dev-feedback,Site Health,,normal,normal,Future Release,feature request,accepted,2020-01-08T10:09:36Z,2024-02-23T13:13:08Z,When upgrading plugins in WordPress admin users are very likely to miss plugins that aren't receiving regular updates from their authors. The same warning (or similar) that's displayed on WordPress.org plugin repo should be displayed in the same manner as available plugin updates on the WordPress admin plugin page.,vincenthasselgard,66
38922,Use REST API for ajax tag search,,,Taxonomy,,normal,normal,Future Release,defect (bug),reviewing,2016-11-23T23:40:24Z,2020-10-25T04:56:30Z,"Proof of concept. Probably can't be done because you lose the context on the filter -- we will continue to see this for ''existing'' ajax actions, but this will be super nice for newer things.
Similar: #38920.",nacin,65
47012,Proposal: Simplify WordPress Admin Navigation,,dev-feedback,Administration,,normal,normal,Future Release,enhancement,new,2019-04-22T15:40:53Z,2022-02-08T07:56:17Z,"About 3 months ago [https://wordpress.slack.com/archives/C02S78ZAL/p1548265528434800?thread_ts=1548092047.364700&cid=C02S78ZAL joen shared some rough mockups] in Slack for proposed changes to the left sidebar navigation in core.
My goal below (with Joen’s blessing) is to resurface those mockups a little more publicly to see if we can gather some more feedback and potentially gain a little more momentum with this project.
=== Summary
The current sidebar has served us well for a long time. But with a few improvements, we can improve accessibility and usability, and allow it to better scale to extensions.
=== Challenges with the current design
* The hover/flyout menus are difficult to make accessible, and they do not scale well to mobile interfaces.
* There are a lot of top-level menu items that are rarely if ever used, contributing to cognitive weight by still being permanently visible.
* Given the additional menu items that plugin add, people are likely to end up with many menu items, despite a large number of them perhaps not being used that often.
=== Mockup
**Important disclaimer:** this is just an initial concept, it is subject to feedback and discussion and iterations:
[[Image(menu-mockup.png)]]
Props to joen for coming up with this v1 concept.
=== Major Changes
* Flyout menus are replaced with accordion behavior. This scales all the way from mobile to desktop, and affords better accessibility.
* Menu is made 80px wider (240px vs. 160), affording a 14px minimum font size for all items, perhaps bigger icons in the future, more relaxed spacing, enhancing usability and accessibility.
* Sidebar is grouped in major sections, “Site”, “Design”, “Tools” and “Manage”.
* “Updates” are moved to a subsection of “Manage”, making Home a single item.
* Items related to content on your site (such as “Posts” and “Pages”) are moved under “Site”.
* Clicking major menu items just opens or closes the accordion, as opposed to go directly to the first subsection. This unifies the mobile and desktop behavior. You can keep the accordion open if you use it all the time (each click will save state, so you’ll see the same open/closed sections upon page refresh).
* All “Settings” subsections are moved under “Manage”, along with “Plugins & Blocks” and “Users”.
* Separators group major categories, like “Site” and “Design” together
* Dashboard is renamed “Home”, because all of WordPress is a Dashboard, and “Home” is where you can get an overview at a glance.
=== Custom Post Types & Taxonomies
* Custom Post Types show up below Pages (top item) and Posts (2nd item).
* A separator cordons these off from Media & Comments, which show content from all.
* Categories & Tags, and even custom taxonomies, are accessible from each section, as opposed to having a permanent presence in the sidebar. For example if you have a taxonomy called “Ingredients” tied to “Recipes”, you first click “Recipes”, and on the archive page you can manage existing Ingredients under a tab. The argument for putting them under this page is that taxonomies are usually added in the editor itself, and only managed on the archive pages.
* When you have custom post types, an additional, short, separator shows up below the post types.
=== Where's the ""Add New"" menu item?
One idea would be to make this permanently visible in the top toolbar.
[[Image(add-button.png)]]
Clicking this button produces a dropdown. By moving it there, you have a single destination to create new content, and we reduce the amount of tab-stops in the navigation menu, especially for sites with a lot of custom post types.
=== Related
Helen opened [https://core.trac.wordpress.org/ticket/32678 this ticket] over 4 years ago. There are a number of different ideas and threads in that ticket. If someone decides that these two tickets should be merged, that is fine.
=== Feedback
Please keep in mind that this is just a ''very early, exploratory concept''. Nothing here is set in stone. The goal of this exercise would be to improve the overall usability and accessibility of the left nav.
What thoughts, concerns, questions, and feedback do you have?",lessbloat,64
29792,Grunt: Add a stylelint precommit task to check for CSS syntax errors,netweb,,Build/Test Tools,,normal,normal,Future Release,enhancement,assigned,2014-09-29T13:07:40Z,2021-11-11T21:59:32Z,"We need to do a better job of catching sad syntax errors and problems in our CSS before commit - things like parse errors, empty rules, units on zero values, and possibly duplicate properties (when alone, not as a part of a group). There may also be a thing or two that we could enforce per our own standards, such as requiring a comment to follow any declaration with `!important`.
CSSLint seems to do most of these, provided we turn off the majority of its checks. Many of those checks (vendor prefixes, selector specificity, etc.) either are not relevant to our set up (due to Autoprefixer, for example) or are just not feasible given our current CSS and possibly not desirable for this project.
Interested to know if there are any other tools out there that perhaps fit the job better, and defining the parameters of what we would like to check.",helen,63
57271,Cron unschedule / reschedule event errors,audrasjb,needs-unit-tests,Cron API,6.0,normal,normal,Awaiting Review,defect (bug),assigned,2022-12-04T09:55:55Z,2024-03-07T01:04:44Z,"Multiple users have reported errors since v6.0 across installs with completely different themes and plugins ...
{{{
[09-Nov-2022 11:28:28 UTC] Cron unschedule event error for hook: do_pings, Error code: could_not_set, Error message: The cron event list could not be saved., Data: {“schedule”:false,”args”:[]}
[09-Nov-2022 18:05:03 UTC] Cron unschedule event error for hook: wordfence_processAttackData, Error code: could_not_set, Error message: The cron event list could not be saved., Data: {“schedule”:false,”args”:[]}
[21-Nov-2022 07:53:04 UTC] Cron reschedule event error for hook: wf_scan_monitor, Error code: could_not_set, Error message: The cron event list could not be saved., Data: {“schedule”:”wf_scan_monitor_interval”,”args”:[],”interval”:60}
[21-Nov-2022 07:53:04 UTC] Cron unschedule event error for hook: wf_scan_monitor, Error code: could_not_set, Error message: The cron event list could not be saved., Data: {“schedule”:”wf_scan_monitor_interval”,”args”:[],”interval”:60}
}}}
There are many more examples on the support thread https://wordpress.org/support/topic/cron-unschedule-event-error-for-hook/
I have so far been unable to find a way to manually re-produce this issue but this is what I have discovered so far ...
So this error happens when `wp_unschedule_event()` and `wp_reschedule_event()` fails.
`could_not_set` error is presented by` _set_cron_array()` which is the return function for `wp_unschedule_event()` and `wp_schedule_event()`.
`could_not_set` error is returned by `_set_cron_array()` when the updating of the cron table fails with `update_option( 'cron', $cron );`.
`update_option()` fails when …
1) The `$option` parameter is empty
This should never happen
2) The old option value is the same as the new option value
This suggests the cron job is running more than once but may not be the only reason ... ?
3) The database insert query `$wpdb->update()` fails
This is a bit worrying but shouldn’t be the case as surely there should be an accompanying database error?
I think we can rule out (1) seeing as the `$option` parameter is never empty.
We can maybe rule out (2) because from the thread above, this happens on high traffic sites as well as low traffic sites and on sites using the default wp-cron firing as well as cron fired by the system … ?
The leaves (3) being the most likely cause of the ""bug"".
I have tried to assign to @audrasjb (I hope that's OK to do?) because they added the commit on the 20th September that started to highlight the issue https://github.com/WordPress/WordPress/commit/84d19848666a81584e0007a6ab7f7ad3c990d71a
I realise that this is not going to be easy to diagnose until the issue can be manually replicated but I think it should be looked into.
Oliver
",domainsupport,63
60303,About Page for 6.5 Release,,has-patch,Help/About,,normal,normal,6.5,task (blessed),new,2024-01-19T19:17:45Z,2024-03-12T15:00:41Z,"This ticket will serve as a hub for the discussion, planning, design, and other related work for creating the WordPress 6.5 About page.
Anyone involved in the release is invited to follow this ticket as part of their release-related duties and offer their input. ",laurlittle,63
15317,My Sites limited to 23 sites on Admin Bar,morganestes,,Toolbar,3.1,normal,normal,Future Release,enhancement,assigned,2010-11-04T13:35:21Z,2023-03-12T00:01:26Z,"I have a test site with 25 sites. I can only access 23 from the My Sites tab on the admin bar.
(This is a minor bug, but I hadn't seen it mentioned.)
Ron
I'm using latest trunk.",ronbme,63
56034,PHP 8.2: proposal for handling unknown dynamic properties deprecations,hellofromTonya*,,General,,normal,normal,6.6,task (blessed),accepted,2022-06-22T04:19:45Z,2024-02-26T10:21:38Z,"Dynamic (non-explicitly declared) properties are deprecated as of PHP 8.2 and are expected to become a fatal error in PHP 9.0, though this last part is not 100% certain yet.
RFC: https://wiki.php.net/rfc/deprecate_dynamic_properties
**This ticket is only intended for situations 3 and 4 (see below) where fixing a typo or explicitly declaring the property is not possible.**
== The problem
=== What is a dynamic property ?
{{{#!php
id = $id;
// This is a dynamically created property as the property
// is not declared on the class.
$this->field_name = $field_name;
}
}
}}}
Dynamic properties can both be created from inside a class, like in the above example, as well as from outside the class (see the below example), which makes these issues very tricky to find via static analysis.
{{{#!php
type = 'something';
}}}
=== When is something not a dynamic property ?
1. When the property is explicitly declared on the class.
2. When the property is explicitly declared on the (grand)parent class.
=== When are dynamic properties not problematic ?
1. When the class, or one of its parents, has a magic `__set()` method which assigns the property to a declared property.
{{{#!php
field_name = $field_name; // Not problematic.
}
public function __set( $name, $value ) {
$this->fields[ $name ] = $value;
}
}
}}}
2. When the class, or its parent, extends the PHP native `stdClass`, which has highly optimized versions of the `__set()` magic method available.
== Mitigation
The solution needed depends on the specific situation and each instance where a deprecation is thrown needs to be individually evaluated.
We can basically categorize dynamic properties into four base situations:
|| ||= Situation =||= Solution =||
|| 1. || Typo in property name || Fix the typo, either in the property as declared or where the property assignment happens ||
|| 2. || Known, named, dynamic property || Declare the property on the (parent) class ||
|| 3. || Known use of unknown dynamic properties || Declare the full set of magic methods on a class (preferred) or let the class extend `stdClass` (discouraged) ||
|| 4. || Unknown use of unknown dynamic properties || Use the `#[AllowDynamicProperties]` attribute on the (parent) class and/or declare the full set of magic methods on a class and/or let the class extend `stdClass` ||
Note: the `#[AllowDynamicProperties]` attribute is expected to be a temporary solution and it is expected that support for the attribute will be removed at some point in the future.
== The larger problem
=== Intended future roadmap for PHP
The deprecation of dynamic properties in PHP is only step 1 in a larger plan to remove support for dynamic properties completely.
No impact analysis was done for the RFC, as even PHP Core realized that identifying all uses of dynamic properties via static analysis is neigh impossible.
With that in mind, the `#[AllowDynamicProperties]` attribute was introduced to allow for doing an actual impact analysis for the next step of the plan, i.e. removing support for dynamic properties altogether.
**Note**: ''when support for dynamic properties would be removed altogether, correctly set up magic `__set()` methods will still continue to work, including those in the `stdClass`.''
At this time it is unclear when the removal of support for dynamic properties will land, but it is ''expected'' to be either in PHP 9.0 or 10.0.
Once it lands, the attribute is expected to no longer be respected.
=== WordPress infrastructure
Due to the extendable nature of WordPress and its large plugin and theme infrastructure, the problem facing WordPress is exponential as every single class in WordPress ''may'' be used and/or extended from within plugins and themes and these plugins/themes ''may'' be setting dynamic properties on the WordPress Core classes.
Now, while WP Core at least has tests for a small part of its codebase and runs those diligently, which allows for finding (a subset of the) dynamic properties via the deprecation notices, the majority of plugins/themes do not have any tests.
As noted previously, finding dynamic properties via static analysis is hard, so these plugin/themes would have to largely rely on error logging/user reporting of the PHP 8.2 deprecation notices to fix things and that is still providing the plugin/theme is actively maintained, while a large number of plugins/themes are not.
Also note that the PHP 8.x uptake under WordPress users is low (due to WP Core not being fully compatible) and the number of users logging errors is also low, so user reporting is not a reliable method to allow plugins/themes to get ready for this change.
Altogether, this means that end-users run a significant risk of their sites going down once PHP removes support for dynamic properties and the user upgrades to that PHP version, with little advance notice.
== Proposal
Taking all of the above into account, I would like to propose the following:
1. Introduce two traits into WP Core: `trait DeprecateDynamicProperties` and `trait ForbidDynamicProperties`.
* The `DeprecateDynamicProperties` trait would contain a full set of the magic methods (`__isset()`, `__get()`, `__set()`, `__unset()` and will throw a deprecation notice whenever any of those methods are called. Properties will still be set via the magic methods. This trait is intended to be a temporary stop-gap solution and will not fall under the WordPress BC promise. When PHP removes support for dynamic properties, this trait should be removed from WordPress as well.
* The `ForbidDynamicProperties` trait would contain a full set of the magic methods (`__isset()`, `__get()`, `__set()`, `__unset()` and will throw a fatal error whenever the `__set()` method is called. Properties will **not** be set via the magic methods, `__isset()` will always return `false`, `__get()` will always result in an undefined property warning.
2. Evaluate every single class in WP Core `src` directory:
* If the class - or one of its parents - already has a full set of properly implemented magic methods in place, no action is needed.
* If the class - or one of its parents - already extends `stdClass`, no action is needed.
* If the class really **''should''** support dynamic properties, the magic methods should be implemented on the class itself (or its parent).
* For every single class which does not fall into the above categories, the `DeprecateDynamicProperties` trait should be added, as well as the `#[AllowDynamicProperties]` attribute (to allow the class to be recognized for the PHP Core scan for the next RFC).
3. Every new class introduced to WP Core ''after'' the initial change from step 2, would be **required** to either have a full set of the magic methods or to add the `ForbidDynamicProperties` trait. New classes should not be allowed to have the attribute.
If the above proposal is accepted, it would effectively ''backport'' the PHP 8.2 deprecation all the way back to PHP 5.6, making it far more likely that users discover any dynamic property related issues in their site.
This will give end-users plenty of time to either contact the plugin/theme owner to mitigate the issue and/or to switch to other plugins/themes if the plugin/theme is no longer actively maintained.
It will also give plugin and theme authors plenty of time to notify WP Core of Core classes which use the `DeprecateDynamicProperties` trait, but should, in all reality, fully support dynamic properties.
For those cases, after evaluating the merit of the specific use-case and finding it valid, the full set of magic methods could then be added to the WP Core class and the use of the trait and the attribute removed.
Altogether, this should greatly diminish the dramatic impact of PHP removing support for dynamic properties altogether in a future release.
=== Practical
I'm perfectly happy to prepare the patch for this together with some people. However, as the proposed patch comes down to a huge amount of work, I want to see some second opinions supporting this proposal first before starting the work on this.
----
Related: #56009
Trac ticket #56033 is open for addressing dynamic properties in category 1 and 2.",jrf,62
30377,wp_check_filetype is broken when checking urls with parameters,audrasjb,,Media,4.0,normal,normal,Future Release,enhancement,reopened,2014-11-18T05:05:03Z,2022-04-08T04:24:45Z,"The function in ./wp-includes/media.php named wp_check_filetype has a bug.
It works properly when checking a url such as http://example.org/coolfile.mp4 but as soon as you add parameters to it (a common practice when attempting to embed un-cached or amazon pre-signed urls) like so: http://example.org/coolfile.mp4?extra=true¶ms=true ... it fails to return the extension / content type.
The fix for this should be *very* easy. The preg_match in this function that looks like this currently:
{{{
$ext_preg = '!\.(' . $ext_preg . ')$!i';
}}}
could be adjusted to ignore the query string (if there is one) and just return the true extension like so:
{{{
$ext_preg = '!\.(' . $ext_preg . ')(\?.*)?$!i';
}}}
I've tested this change in my local environment and it works great.
",supercleanse,62
42441,Disable autoload for large options,pbearne,has-patch,"Options, Meta APIs",,normal,normal,6.6,enhancement,assigned,2017-11-06T02:20:50Z,2024-03-13T15:09:12Z,"A frequent issue I encounter with WordPress sites is extreme slowdown due to a huge option that is being autoloaded. Sometimes this is some sort of cache option that a careless plugin has let be autoloaded, and has grown to tens of megabytes.
Having an option this large be autoloaded not only slows downs the options loading query (when that option may not be required on every load), but on sites with object caching, it causes a lot of wear and tear on the alloptions cache. Combine a large option with a frequently updated option and you have a recipe for a very sluggish site.
We should consider preventing options from being autoloaded if they grow to a certain size. Off the top of my head, 100kb sounds like a reasonable upper bounds. We could monitor option settings/updates and peek at the size of the option going in. If it's above a certain (filterable) bounds, we can force autoload to be off.",markjaquith,62
16413,Settings page needs HTML refactoring and UI improvements,joedolson*,,Administration,3.1,normal,normal,Future Release,enhancement,accepted,2011-01-30T20:22:09Z,2023-11-10T16:20:51Z,"The settings pages haven't had much attention or improvement in a while.
We need to refactor the HTML on the settings pages, as they are still using tables instead of divs.
We also want to make some minor UI improvements including:
- clearer differentiation between option groupings
- using consistent text styles for descriptions and links (including the time zone/date format comment)
- restructure for better readability
Comment if you have any other",chexee,61
24766,Title attributes galore. They serve no useful purpose.,sabernhardt*,,Administration,,normal,normal,Future Release,task (blessed),accepted,2013-07-16T00:29:25Z,2024-02-14T19:05:13Z,"This is a full list of methods, including what files they're from, where HTML title attributes are in use.
The title attribute provides a tooltip on certain browsers. Other than that, it is essentially useless. As provided in WordPress, the title attribute is both redundant and useless, because in most cases, it is a complete duplicate of the link's text. Therefore the tooltip provided is of no value whatsoever.
For users of assistive technologies, the title attribute is useless at best and sometimes an annoyance. Users of text-to-speech software who have configured their software to do so will hear the title attribute twice.
Essentially the extensive use of title attributes throughout WordPress Core amounts to unnecessary code bloat.
I recommend eliminating the title attributes from all of the methods below:
{{{
// user.php
wp_authenticate_username_password()
// post-template.php
wp_page_menu()
wp_get_attachment_link()
// media.php
get_image_tag()
// media-template.php
wp_print_media_templates()
// link-template.php
edit_term_link()
edit_post_link()
edit_comment_link()
edit_bookmark_link()
get_adjacent_post_rel_link()
the_shortlink()
// default-widgets.php
widget()
// comment-template.php
comments_popup_link()
comment_form()
// class-wp-theme.php
markup_header()
// class-wp-editor.php
wp_fullscreen_html(). There is one title attribute here on what I think is a TinyMCE button. If that looks like a button, it should actually be a button.
// class-wp-customize-section.php
render()
// category-template.php
get_category_parents()
get_the_category_list()
wp_generate_tag_cloud()
start_el()
// bookmark-template.php
_walk_bookmarks()
// author-template.php
get_the_author_link()
the_author_posts_link()
wp_list_authors()
// rss.php
wp_rss()
get_rss()
// general-template.php
get_calendar()
// class-wp-admin-bar.php
_render_item()
}}}
* Note:
Ignored: All Third party classes
",karlgroves,61
36308,get_attached_file() destroys file paths on Windows,,,Media,4.4.2,normal,normal,Future Release,defect (bug),assigned,2016-03-23T15:45:03Z,2023-05-31T15:30:19Z,"While working on ticket #36273 I noticed that ''get_attached_file()'' from ''wp-includes/post.php'' will destroy paths normalized by ''wp_normalize_path()'' on Windows:
For example the function starts with
{{{#!php
$file = get_post_meta( $attachment_id, '_wp_attached_file', true );
// $file = 'C:/WWW/Sites/demo/htdocs/wordpress/wp-content/uploads/2016/03/example.jpg'
}}}
However this will become
{{{#!php
$file = 'C:\WWW\Sites\demo\htdocs\wordpress/wp-content/uploads/C:/WWW/Sites/demo/htdocs/wordpress/wp-content/uploads/2016/03/example.jpg'
}}}
due to
{{{#!php
if ( $file && 0 !== strpos($file, '/') && !preg_match('|^.:\\\|', $file) && ( ($uploads = wp_upload_dir()) && false === $uploads['error'] ) )
$file = $uploads['basedir'] . ""/$file"";
}}}
This is similar to ticket #24824 however we are dealing will full qualified paths here, not URLs (well, both are URIs...).
PS: Yes, `$uploads['basedir']` contains mixed directory separators. That's another thing.",Whissi,61
28197,Fallback Languages,swissspidy,,I18N,4.0,normal,normal,Future Release,enhancement,assigned,2014-05-09T20:53:44Z,2024-02-28T14:38:59Z,"We should do a better job of loading translation files in the user's language if they are available.
For instance, if a Spanish speaker has their locale set as es_MX (Spanish Mexico) it would be preferable to load any available Spanish translations files (es_ES, es_CO, etc) before returning the default (generally English).
I wrote up a quick patch, tester plugin, and plugin that demonstrate this idea. If a $mofile is not available in the user's current locale, it will search for and return the first available translation that is also in the same language.
A better option might be to create a filterable stack rank of locales for WordPress to search for within the language before returning the default. Other suggestions are also welcome.
This idea was also discussed in an ""ideas"" thread:
http://wordpress.org/ideas/topic/fallback-to-generic-language-file-when-specific-locale-file-absent",downstairsdev,60
10249,Page slug in cyrillic = Error 404 - Not Found!,westi,needs-unit-tests,Permalinks,4.9.5,normal,normal,Future Release,defect (bug),reopened,2009-06-23T19:44:34Z,2022-06-22T01:20:33Z,"When I create a page with page slug for example ""киро""
then when I try to open domain/киро - Error 404 - Not Found
The permalinks are %postname%
Post slug with this slug is working just fine, the same BUG exists in 2.7, 2.7.1 and 2.8",kalifi,60
44176,Un-map Privacy Capabilities,xkon,has-patch,Privacy,4.9.6,normal,normal,Future Release,defect (bug),reopened,2018-05-21T14:31:43Z,2020-10-24T03:28:47Z,"Three new capabilities were added in WordPress 4.9.6 to allow granular control over the new privacy features:
- `erase_others_personal_data`
- `export_others_personal_data `
- `manage_privacy_options `
If a site activates a role management plugin (such as [https://wordpress.org/plugins/members/ Members]), the capability is not listed under the Administrator role (which receives these capabilities by default), and is not available to be assigned to other roles. Adding this role as a custom capability does nothing because the capabilities are mapped to `manage_options` and `manage_network`.
A site could create a custom role specifically for someone to manage privacy requests that should not have access to other `manage_options` related functionality.
Related: #44079, ticket:44055#comment:5.",desrosj,60
44133,Should the Data Export indicate when we have no information on the user,xkon,dev-feedback,Privacy,4.9.6,normal,normal,Future Release,enhancement,assigned,2018-05-17T20:45:33Z,2021-11-08T00:27:04Z,"Hello,
If a data export is done for a non-existent user should we indicate in the .html file provided that we have no information on the subject? Currently the file is provided and just the initial table provided. If there's nothing else should a message be there to indicate that we currently have nothing stored on them?
Thanks",garrett-eclipse,60
26937,get_adjacent_post() should use WP_Query rather than build its own SQL query,nacin,,Query,3.7,normal,normal,Future Release,enhancement,reopened,2014-01-25T18:51:47Z,2018-01-31T20:33:04Z,"With the introduction of the `WP_Date_Query` through r25139, `get_adjacent_post()` no longer needs to build its own SQL to retrieve adjacent posts. By switching to `WP_Query`, we gain the benefit of its performance improvements, including native caching.
The trickiest part of this change is maintaining support for the `get_{$adjacent}_post_join` and `get_{$adjacent}_post_where` filters currently applied to the SQL built in `get_adjacent_post()`.",ethitter,60
55974,Bundled theme: Add support for border options,,has-patch,Bundled Theme,6.0,normal,normal,Future Release,defect (bug),new,2022-06-14T11:42:12Z,2024-03-02T08:22:01Z,"In Twenty Twenty Theme, when we add Pullquote block in editor side and add any border style after that choose border color, We can see that border color is seen in editor side. But when we see the same Pullquote block at front side, border color is not reflected.
Steps to replicate:
1: Activate the Twenty Twenty Theme
2: Add Pullquote block
3: Add border style
4: choose border color
5: Save Page/Post
6: View the page/post at front side
For better understanding I provide video attachment link.
Video URL : https://share.cleanshot.com/bqZzSHG6AGVy2hslSIqc
Thanks",kajalgohel,59
40432,Customizer: Should we stop contextually hiding features?,,,Customize,4.0,normal,normal,Awaiting Review,enhancement,new,2017-04-12T22:20:48Z,2018-09-12T17:52:10Z,"This is a continuation of the conversation in #39087.
If something doesn't appear on a page you're previewing, it gets hidden in the Customizer panel. For example, if your archive pages have a sidebar, but your static pages do not, you will not be able to edit your archive sidebar. It will be hidden until you go to an archive page.
The same goes for contextual theme options. For example, you can't assign sections to your homepage in Twenty Seventeen unless you're on your homepage.
This is often very confusing for folks new to WordPress, as evident in the previous ticket linked above. I think we should change this behavior, and I'm interested in hearing what others think.",melchoyce,59
47280,SQL_CALC_FOUND_ROWS is deprecated as of MySQL 8.0.17,johnbillion,has-patch,Database,,normal,normal,Future Release,enhancement,reviewing,2019-05-15T14:34:03Z,2024-02-22T07:49:16Z,"Per https://dev.mysql.com/doc/refman/8.0/en/information-functions.html#function_found-rows
> The SQL_CALC_FOUND_ROWS query modifier and accompanying FOUND_ROWS() function are deprecated as of MySQL 8.0.17 and will be removed in a future MySQL version. As a replacement, considering executing your query with LIMIT, and then a second query with COUNT(*) and without LIMIT to determine whether there are additional rows.
This is not yet immediately important because most hosts are on 5.5, or 5.6, rarely 5.7, but given the speed with which trac tickets move that impact very core functionalities, I thought it best to open this ticket to get the work started.
This impacts all the 6 places where it's being used, though one of them is in the WP_Query definition.",javorszky,59
56780,shortcode block in block-based template part in a classic theme does not get expanded,costdev,has-patch,Editor,6.1,high,normal,6.6,defect (bug),assigned,2022-10-10T14:03:01Z,2024-02-23T13:12:44Z,"While testing the new feature in 6.1 (w/ 6.1-beta3) for a classic theme to include block-based template parts, I discovered that shortcode blocks in such template parts are not expanded (their render callbacks are not called).
The details are in my [https://make.wordpress.org/core/2022/10/04/block-based-template-parts-in-traditional-themes/#comment-43901 comment on the Dev Note] announcing this new feature.
Note: creating the ticket here in Trac, rather than the GB GitHub, because that's where @mamaduka asked me to open in",pbiron,59
15448,wp_mail() sets Content-Type header twice for multipart emails,SergeyBiryukov,has-patch,Mail,,normal,normal,Future Release,enhancement,reviewing,2010-11-17T12:15:04Z,2020-09-17T00:43:40Z,"When trying to send emails via `wp_mail()` with a Content-Type of multipart/alternative, the Content-Type header will be set with `$phpmailer->ContentType`, and again with `$phpmailer->AddCustomHeader()`, which causes two Content-Type headers in the email:
{{{
Content-Type: multipart/alternative;
boundary=""example_boundary""
Content-Type: multipart/alternative; charset=""""
}}}
This appears to cause errors in Outlook, as there is no boundary on the latter.
The cause of this is `PHPMailer::GetMailMIME()`, as it does not know that the email is a multipart email. The easiest way to achieve this appears to be to simply allow the user to set the AltBody via `wp_mail()`. In order to achieve backwards compatibility, `wp_mail()` should work out which part is the text/plain one and which is the text/html one based on the boundary.
I'll be working on a patch for this.",rmccue,59
15134,WordPress should not try to remove themes or plugins recursively if the directory is a symlink,pbiron*,dev-feedback,Upgrade/Install,,normal,normal,Future Release,defect (bug),accepted,2010-10-16T11:46:29Z,2023-07-05T18:13:59Z,"Consider the situation: there is a server with multiple WordPress blogs hosted in it. Some plugins are common for all/many blogs and to save several (hundreds in our case) megs of the disk space, shared plugins are stored somehwere else (say, /var/www/wp-plugins) and there are symbolic links to /var/www/wp-plugins/
Get Flash 9.0 to see this player.
}}}
So, two/three issues:
- wpautop should also ignore double object tags, and html comments
- wptexturize should ignore html comments",Denis-de-Bernardy,10
52886,Update esc_url to allow for specifying an https:// as default protocol,,has-patch,Formatting,,normal,normal,Future Release,enhancement,new,2021-03-22T18:00:37Z,2022-07-05T14:51:36Z,"
If no protocol is specified for esc_url the function will automatically prepend the http:// protocol. This is likely now the wrong assumption, but potentially can break backwards compatibility if changed, since developers may rely on this.
So this change proposes an additional parameter to the function to specify a default protocol, keeping the old default but now allowing for one to ask for https://
This came up in this ticket: https://github.com/WordPress/gutenberg/pull/30100
The usage could then be:
{{{
esc_url( $url, null, 'display', 'https://' );
}}}",mkaz,10
55962,Upgrade `sanitize_hex_color()` to CSS Color Level 4,pbearne,dev-feedback,Formatting,,normal,normal,Future Release,enhancement,assigned,2022-06-11T04:57:08Z,2024-01-17T00:09:09Z,"I’ve noticed that the `sanitize_hex_color()` function unsupports the CSS Color Level 4 with the alpha channel and can therefore not be used. As users are given the ability to provide settings by configuration filters in a mini-plugin or in their theme’s `functions.php`, they may wish to configure opacity alongside.
The fix is to extend the validation condition of `sanitize_hex_color()` from:
`if ( preg_match( '|^#([A-Fa-f0-9]{3}){1,2}$|', $color ) )`
to
`if ( preg_match( '|^#([A-Fa-f0-9]{3,4}){1,2}$|', $color ) )`",anrghg,10
53229,"""Alt Text"" label misaligned in French",audrasjb*,has-patch,Gallery,,normal,normal,Future Release,defect (bug),accepted,2021-05-19T07:50:05Z,2021-06-08T17:11:12Z,"Hello,
In French, in a post edit when adding an image or a gallery block, the ""Alt Text"" label is misaligned with the input field.
We can see this behaviour on Ubuntu20.04/Firefox88.0.1 and Chrome 90.0.4430.212.
**Step to reproduce**
- be sure to have French as language in your profile
- in a post add an ""Image block""
- click on ""mediathèque"" to add an existing image
- Check an image and see the sidebar
",sebastienserre,10
57213,Coding standards : Use Strict Comparison except Loose Comparison wp-includes/class-wp-hook.php,,has-patch,General,4.7,normal,normal,Future Release,enhancement,new,2022-11-27T05:55:40Z,2023-02-06T19:50:50Z,It's help for coding standardization when get the Integers data type then use Strict Comparison except Loose Comparison,rockonshajib,10
31387,New core API for adding Meta tags to the header,,dev-feedback,General,,normal,normal,Awaiting Review,enhancement,assigned,2015-02-19T19:08:23Z,2021-08-11T15:56:09Z,"There is often a conflict between one or more plugins about registering meta tags in the header. Meta tags that shouldn't be duplicated, it's difficult to know which one should 'win'. A lightweight framework in core that multiple plugins could use to register meta tags seems like it would be useful.
It would need to handle several different attributes for all use cases -- `name` `property` `http-equiv` `charset` -- possibly generic `data-*` attributes? Uncertain.
Twitter discussion: https://twitter.com/nacin/status/562109983069061120 (up and down the thread)
My first swing at it:
https://gist.github.com/georgestephanis/0f0cca2c5f1a6cd4aab2",georgestephanis,10
32979,Password UI: Regenerate PW after clearing field,,,General,4.3,normal,normal,Future Release,enhancement,new,2015-07-13T17:49:23Z,2017-12-11T13:25:02Z,"Based on https://core.trac.wordpress.org/ticket/32589#comment:20.
I think this needs some discussion and focus in it's own ticket.
In the new UI a PW gets generated for you. You have to take an action ""Show password"" or ""Generate new password"" to make the field show. Then you can edit that if you would like. At that point you decide you would rather generate one again. There is no clear way to do so.
A few things worth noting
On user profile you can click ""Generate new password"" again and it will.
On new user you can click ""Show password"" and it will regenerate a pw again. (This is not great and where the change needs to happen)
Perhaps the easy solution is to change the wording on the button when the field is shown to ""Generate new password"".
A small issue that can be taken care of at the same time is the ""Show password"" button shows above the PW field while the ""Generate new password"" button shows below. The button below looks better.
",MikeHansenMe,10
43328,Add support for Web App Manifests,westonruter*,,General,,normal,normal,Future Release,feature request,accepted,2018-02-15T09:33:11Z,2019-03-01T13:44:17Z,"Per [https://developer.mozilla.org/en-US/docs/Web/Manifest MDN]:
> The web app manifest provides information about an application (such as name, author, icon, and description) in a JSON text file. The purpose of the manifest is to install web applications to the homescreen of a device, providing users with quicker access and a richer experience.
>
> Web app manifests are part of a collection of web technologies called progressive web apps, which are web applications that can be installed to the homescreen of a device without needing the user to go through an app store, along with other capabilities such as being available offline and receiving push notifications.
For populating the manifest:
* `description` can be pulled from the `blogdescription`
* `name` can be pulled from `blogname`.
* `background_color` can be pulled from the `custom-background` theme support.
* `lang` can be pulled from the site locale.
* `icons` can be pulled from site icons.
A filter can be present for themes and plugins to augment the manifest.
See also #36995 for adding service worker support to core.",westonruter,10
38419,Make beta testing an opt-in feature in core,,,General,4.7,normal,normal,Awaiting Review,feature request,new,2016-10-20T19:27:42Z,2021-10-05T01:11:32Z,"Currently beta testing of WordPress core (and feature plugins) is something you have to be aware of to take part in. This limits the reach of beta testing feedback to those who are intimately engaged in the day-to-day development of WordPress core and results in feedback that skews heavily in the direction of those who build WordPress as opposed to those who use WordPress.
To increase participation in end-user testing of WordPress core and feature plugins, active participation in such programs should be surfaced more visibly, either through settings during install, a modal pop-up, or an alert.
To be clear, I'm not talking about testing of bleeding edge nightlies here, but specific features and feature plugins in Beta or RC state.
A simple admin alert saying ""WordPress 4.7 beta is available. Would you like to test it?"" would be a huge improvement. Similar can be done with select feature plugins, especially if the alert is tied to the feature they change/improve (so for a new media feature, the alert would appear when the media functionality is engaged: ""We are working on a new and improved media panel. Would you like to test it?"").
This would of course have to be done sparingly to avoid alert overload.
== Simplified feedback procedure ==
Along with the surfacing of beta testing, there should be a way to provide feedback on features directly from within WordPress admin. Asking for feedback to be posted in a Trac ticket or even a Make blog post limits the number of possible responses significantly. An in-app feedback feature activated only for testers would greatly simplify the process and most likely increase the volume of feedback data significantly. Whether this data is mapped to Trac tickets or something else needs to be addressed.",mor10,10
52264,Rename `$array` when used in `@param` tags,,has-patch,General,,normal,normal,Future Release,task (blessed),new,2021-01-08T22:38:56Z,2022-02-25T18:55:08Z,"Related: #52243
Several functions, filters and actions pass `$array` as a parameter.
Usage of `$array` in `@param` tags for actions and filters should be replaced with a more appropriate (and descriptive) variable name.
Example:
In `class-requests.php`
{{{
/**
* Convert a key => value array to a 'key: value' array for headers
*
* @param array $array Dictionary of header values
* @return string[] List of headers
*/
public static function flatten($array) {
}}}
Could be replaced with:
{{{
/**
* Convert a key => value array to a 'key: value' array for headers
*
* @param array $headers Dictionary of header values
* @return string[] List of headers
*/
public static function flatten( $headers ) {
}}}",audrasjb,10
37705,Remove unnecessary parts of WP_HTTP which remain,,has-patch,HTTP API,,normal,normal,,defect (bug),new,2016-08-18T04:07:10Z,2019-06-04T20:01:04Z,"After Requests was merged in WordPress 4.6, WP_HTTP now wraps it with a few of the previous classes remaining for compatibility.
Some of these have significant code left in them which is no longer used, and we've still got the entire cURL and Streams WP_HTTP request classes in core.
We should be able to remove a large percentage of these without too much issue.
There's a chance that some developers have been using these classes directly, especially as a number of items were marked as public (due to how it was developed).
I'd like to take the hardline approach and rip everything not needed out early, and restore compatibility shims where needed if it turns out developers were using things directly (incorrectly).",dd32,10
24567,Add help to media modals,,dev-feedback,Help/About,3.5,normal,normal,Awaiting Review,enhancement,new,2013-06-12T08:06:29Z,2023-03-12T18:17:27Z,They are far from simple screens but there is no help available for them.,mark-k,10
52696,Add a way to determine whether a translation exists,,,I18N,,normal,minor,Future Release,enhancement,new,2021-03-02T20:34:53Z,2024-03-13T20:09:06Z,"Currently `__()` wraps `pomo/translations.php::translate_entry()̀` in such a way:
{{{#!php
$singular,
'context' => $context,
)
);
$translated = $this->translate_entry( $entry );
return ( $translated && ! empty( $translated->translations ) ) ? $translated->translations[0] : $singular;
}
}}}
If no translation exist, the original is returned which is the more frequently desirable behavior.
But in some cases, the user may want to know whether the string obtained from `__()` is actually the translation or the original.
**Use-case**: I'm inserting programmatically taxonomy terms translated using a 3rd-party service. I'm iterating over `[__(""t1""), __(""t2""), ...]` and I would like to only insert those actually translated, ignoring the others.
Currently, I've no way to discriminate between the original and the translation (which may or may not be identical btw).
I'd like a function providing me this ability like. One such example
`__i18n_exists($term, $context = null);`",drzraf,10
40769,Translators' note required for singular/plural strings where both strings are in the singular form,,,I18N,4.8,normal,normal,Awaiting Review,enhancement,new,2017-05-15T14:33:18Z,2021-11-23T11:44:53Z,"There is some confusion for translators in GlotPress over WordPress 4.8.x as some of the singular/plural strings are singular in the originals. For example:
Singular: Audio Widget (%d)
Plural: Audio Widget (%d)
A translators' note would be handy here to explain why the plural is not Audio Widget'''s''' in this case.
This currently relates to four strings:
[https://translate.wordpress.org/projects/wp/dev/en-gb/default?filters%5Bstatus%5D=either&filters%5Boriginal_id%5D=4483096&filters%5Btranslation_id%5D=49716087/ Audio Widget]
[https://translate.wordpress.org/projects/wp/dev/en-gb/default?filters%5Bstatus%5D=either&filters%5Boriginal_id%5D=4483106&filters%5Btranslation_id%5D=49716079/ Image Widget]
[https://translate.wordpress.org/projects/wp/dev/en-gb/default?filters%5Bstatus%5D=either&filters%5Boriginal_id%5D=4483125&filters%5Btranslation_id%5D=49716063/ Media Widget]
[https://translate.wordpress.org/projects/wp/dev/en-gb/default?filters%5Bstatus%5D=either&filters%5Boriginal_id%5D=4483114&filters%5Btranslation_id%5D=49716070/ Video Widget]",pidengmor,10
16445,Fix incompatibilities with IDs greater than 2^31,,,Import,3.1,normal,normal,,defect (bug),new,2011-02-03T01:03:24Z,2019-06-04T20:02:33Z,"For various reasons, things go bad when you get a post ID greater than 2^31^. When we're importing content and there's an existing ID, I suggest we ignore it if possible if it's too big.
Tumblr2WordPress for example maintains the Tumblr IDs and causes problems in WordPress.",Viper007Bond,10
16147,"MT Importer truncates double vertical spaces, munging paragraphs together",,,Import,3.2.1,normal,normal,,defect (bug),reopened,2011-01-07T22:25:47Z,2019-06-04T20:02:27Z,"Movable Type 3.x-era exports don't use '''
''' tags. Like TinyMCE (and WordPress), a '''
''' in final rendered code is represented by two '''\n'''s in a row. The importer strips out double '''\n'''s and replaces with a single '''\n'''. This causes paragraphs to lose their distinction upon import. It does this because the '''$line''' variable was created by '''$line = $this->fgets($handle)''' (line 339). Then '''$line = trim($line)''' (line 340) strips out several characters, including '''\n'''. Lines 455 and 456 add back the '''\n''' ''except'' on blank lines: {{{ if( !empty($line) ) $line .= ""\n""; }}} So if a '''$line''' was nothing but a '''\n''', it's stripped by the '''trim''' function and becomes a 0 character line. Then the '''if( !empty($line) )''' declines to add back a '''\n'''. Somehow this needs to be altered so that successive '''\n'''s aren't stripped. Otherwise paragraphs get vertically munged together.",novasource,10 43536,Network registration page,sabernhardt*,has-patch,Login and Registration,,normal,normal,Future Release,defect (bug),accepted,2018-03-13T10:23:17Z,2022-09-27T23:04:14Z,"Hi, The registration page for the WordPress Multisite version, has, inside its body, the class page-id-xxx where xxx is the id of the page_on_front. This is in my opinion a bug, and makes impossible to customize this page via CSS because every rule will be also referred to the page_on_front. Then it should be useful to have a custom css on the body of the network registration page, something like network-registration-page. Thanks.",SGr33n,10 16482,Visibility: password-protected breaks with redirected domains,,dev-feedback,Login and Registration,3.0.4,normal,normal,,defect (bug),new,2011-02-07T18:58:45Z,2019-06-04T20:02:37Z,"Pre-requisite to reproduce: domain.com must redirect to www.domain.com (haven't tested with other subdomains than www, but I'm sure it would be the same). 1. password protect a page 2. visit domain.com/protected (which redirects to www.domain.com/protected) 3. enter password 4. something about the redirect OR the way the password is stored/checked is broken; you are redirected to the wp-admin (WordPress login) page. Sanity check: 1. password protect a page 2. visit www.domain.com/protected (requiring no subdomain redirect) 3. enter password 4. successful log-in ",monkeyhouse,10 51786,Accessibility issue with the logo on the login page,,,Login and Registration,,normal,normal,Future Release,enhancement,new,2020-11-16T13:36:38Z,2020-12-11T08:27:46Z,"Currently, the login page (wp-login.php) contains a logo, that is created using the following HTML markup: {{{
Text Widget Content
' . __( 'You cannot install a network of sites with your server address.' ) . '
' . __( 'The network could not be created.' ) . '
'; }}} These ""all bold"" admin notices should be adjusted to remove the all-bold effect. Worth also reminding the CSS class `class=""error""` is legacy and should be replaced with `class=""notice notice-error""`. ",afercia,9 43095,Audit the usage of `aria-haspopup` in the admin menu,joedolson*,,Administration,,normal,normal,6.6,defect (bug),accepted,2018-01-15T20:18:01Z,2024-02-20T15:15:16Z,"In the admin menu (the one in the left sidebar, not the toolbar one) items that have a sub-menu have an `aria-haspopup` attribute. While the intent is good, I'm not sure this is a 100% appropriate usage. We've discussed this during today's accessibility team meeting and agreed it's worth investigating. In the previous ARIA 1.0 recommendation it was clearly stated that `aria-haspopup` is meant to be used on controls that require user activation to reveal additional content. Then, in the new [https://www.w3.org/TR/wai-aria/#aria-haspopup ARIA 1.1] recommendation, the sentence ""This means that activation renders conditional content"" [https://www.w3.org/2016/04/28-aria-minutes.html#item03 was removed]. Regardless, this doesn't necessarily change things and the new values for `aria-haspopup` don't seem to suggest the current usage in WordPress is 100% correct. What does ""user activation"" means? The `aria-haspopup` makes perfectly sense when users of assistive technologies land on an interactive item and need to be informed that activating the item reveals additional content. That's not the case with the admin menu. Both when tabbing or arrowing when using a screen reader, all the menu items including the sub-menu items get revealed without requiring any special user action. In this case, the information provided by `aria-haspopup` seems pointless, if not confusing. Only in the responsive view, the admin menu works differently and the top level items do require user activation to reveal the sub menus. Seems `aria-haspopup` should be used only in the responsive view. We should further investigate this issue and test with assistive technologies, not only screen readers but also, for example, speech recognition software. For reference, the major screen readers announce `aria-haspopup` this way, as of January 2018: {{{ NVDA ""sub menu"" JAWS ""has pop-up"" VoiceOver ""Menu pop-up"" }}} ",afercia,9 45910,Improve and extend focus styles for Windows High Contrast mode,joedolson*,,Administration,,normal,normal,6.6,defect (bug),accepted,2019-01-10T16:54:41Z,2024-02-20T15:18:52Z,"See [44544] and #41286. [44544] introduced new focus styles for the Windows High Contrast mode only for the main user interface elements like buttons, links, media views elements. In order to cover all the controls in the admin, there's the need to explore the admin parts that make use of uncommon styles or don't inherit the relevant CSS, for example the Customizer, the themes browser, etc. Some thorough testing on Windows would be greatly appreciated. ",afercia,9 42468,"Iron out the usage of 'homepage', 'home page', 'front page'",,,Administration,,normal,normal,Awaiting Review,defect (bug),new,2017-11-08T14:41:43Z,2020-02-06T19:30:25Z,"As discussed in #41828, I think we need clarification of the usage of 'Homepage' vs. 'Home Page' or 'Front Page'. In german we used to differ the homepage from a 'start page', see screenshot. Can I assume it' all the same, like the french do? Quoting @fxbenard: We made the choice to always translate it the same way in FR, no more consistency issues",Presskopp,9 50139,Add WordPress.tv latest videos dashboard widget,psykro,,Administration,,normal,normal,Awaiting Review,enhancement,assigned,2020-05-10T13:27:50Z,2022-09-07T07:12:30Z,"WordPress.tv is a great resource for WordPress content, specifically for training and learning new ways to use and build with WordPress. This patch adds a dashboard widget to the WordPress dashboard, integrating the WordPress.tv feed to the dashboard. This is a small addition that could eventually pave the way for having curated content (by language or feature) added to the WordPress.tv widget. ",psykro,9 26691,Admin Color Schemes: generic classes for colors,,,Administration,3.8,normal,normal,Future Release,enhancement,new,2013-12-20T15:59:01Z,2020-09-19T06:53:21Z,"Our team is trying to adapt our plugin to the new admin color schemes. It would be great if we could have generic CSS class declarations that allow us to apply the current scheme's background/text colors to our elements. Something like .admin-color-flat .sidebar-background-color{ background-color: #.... } .admin-color-vineyard .sidebar-background-color{ background-color: #.... } This would allow plugin developers to leverage those schemes without having to reinvent the wheel every time, and would make their plugins adapt to any third-party color scheme people may be using on their site. WordPress already adds the current color schema class to the body tag. But then I don't see anything in the CSS that I could use to recycle, let's say, the admin sidebar current background color and use it as the background color for my metabox headers. Yes, I could do this in jQuery, but I was hoping for a pure CSS approach. ",coolmann,9 48641,Discussion: links that look like buttons (and vice versa),,dev-feedback,Administration,,normal,normal,Future Release,enhancement,new,2019-11-14T17:23:30Z,2021-03-04T21:51:54Z,"''This issue has been moved from GitHub to Trac to increase visibility.'' Original GitHub discussion: https://github.com/WordPress/gutenberg/issues/7534#issuecomment-549980093 == Summary Sometimes, `` elements are made to look like visual buttons to users, even though they are not actually using the `This is some text that the image will float around.
}}} The `` inherits our max-width styles, and prevents the image from extending beyond the content column. In order to have the image extend beyond the paragraph's width, we'd need to pull it out via negative margins or relative positioning of some sort. The markup would be very different from the markup we're currently using for all other cases though — I'm not personally sure it's worth sorting out for this single use case, but leaving the issue here in case anyone comes across a simple solution. ",kjellr,9
59924,Twenty Nineteen: The navigation block submenu button is unreadable,,has-patch,Bundled Theme,,normal,normal,Future Release,defect (bug),new,2023-11-17T15:42:25Z,2024-02-13T09:06:12Z,"The navigation block has an option called ""Open on click"" that is available when there is a submenu.
When the option is enabled, the parent menu item is a {{{ paragraph
paragraph
paragraph test
italic
paragraph
paragraph
paragraph
paragraph
paragraph
paragraph
paragraph
paragraph
paragraph elements) are automatically added when you display the web page (in the front view). In this field, they are not.
For accessibility reason, paragraphs need to be HTML paragraphs ([https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html WCAG Success Criterion 1.3.1: Info and Relationships (level A)]).
I've tried to modify the code in the core to add TinyMCE that is explicitly deactivated and this is fixing the problem.
It's in wp-admin/includes/media.php, on line 3261 where you can just change ""false"" to ""true"" for ""tinymce"":
{{{#!php
'strong,em,link,block,del,ins,img,ul,ol,li,code,close' );
$editor_args = array(
'textarea_name' => 'content',
'textarea_rows' => 5,
'media_buttons' => false,
'tinymce' => false,
'quicktags' => $quicktags_settings,
);
}}}
So, is it possible to activate TinyMCE for this field? Why is it deactivated?
Or, if it's not possible, is it possible to make this option hookable?
Thank you
",juliemoynat,5
48194,"Unregistered image sizes used for IMG tag ""srcset""",,,Media,,normal,normal,Awaiting Review,defect (bug),new,2019-10-02T02:16:24Z,2020-07-21T06:25:14Z,"Following design changes, previously-generated thumbnails remain on the site, along with matching post meta entries linked to the respective attachment. WordPress then uses those to produce IMG tags.
In fact, these thumbnails are referenced even when the files don't exist on the site anymore, following a cleanup.
I think WordPress should only use thumbnail URLs for registered image sizes.
For bonus points, there can be a way to remove unregistered size references from attachment meta, perhaps in a Media > Audit admin page, which lets the user decide what to remove and what to keep.
For context, I've just cleaned images on a site and found a lot of legacy references to thumbnails of previously registered sizes in IMG tags. Media management and cleanup plugins I used could only detect the redundant meta data when I re-registered the old sizes temporarily.",galbaras,5
49900,Updates to Image Processing in WordPress 5.3 - Broken Intrinsic Sizing?,,reporter-feedback,Media,5.3,normal,normal,Awaiting Review,defect (bug),new,2020-04-13T23:24:20Z,2020-05-14T22:46:41Z,"Hello WordPress Wizards,
I am a bit late to learning about this Update - I am currently on the Latest Version of WordPress however: [https://make.wordpress.org/core/2019/10/11/updates-to-image-processing-in-wordpress-5-3/]
For months I have been talking to support teams and Developers before finding this article above. - Unfortunately I have had no luck with any ideas or information from them until finding this Post.
Since November 2019 (The first content I have added since the 5.3 Update) I have had an issue with Uploading Images.
For example I will upload an image at 250x250 pixels. However when it is displayed on the page the ""Intrinsic Sizing"" will be 624x468.
Inside of the Media Library it still says the dimensions are ""250x250"" however Right Clicking the Image > Open Image In New Tab - Displays the image at 624 x 468. - Its creating different sizings and now choosing the wrong one (e.g - not picking Original Dimensions)
I want to note. T**his is only for images uploaded SINCE this 5.3 Update**.
I can still insert previously uploaded images that are stored in the Media Library and they are the correct Dimensions on the page.
Attached Image Below showing:
[[Image(https://gmm-downloads.s3.amazonaws.com/WordPress+5.3+Intrinsic+Sizing.JPG)]]
I have disabled Themes and Plugins and the Issue still occurs.
**Note:** ''I am having this issue only on my LIVE site. My Development site with the same themes and Plugins does not get this error - so it was potentially a problem on Installing the update?''
From the timing and what the 5.3 Update included, I feel as though it is related to this 5.3 update.
Thanks!
Alex
**P.S** This is my first WordPress.org post - So I apologize if I am in the wrong area for posting this kind of question. Have a great day :)",techgmm,5
48988,WordPress Does Not Generate JPG Sizes After 5.3.1,,reporter-feedback,Media,5.3.1,normal,normal,Awaiting Review,defect (bug),new,2019-12-15T12:23:16Z,2020-03-12T15:32:41Z,"I have a strange problem on all my wordpress sites after upgrading to 5.3.1
When uploading an image to the site, it does not create any additional size nor the thumb 375x175 it should create ... I've tried using plugins that generate image sizes and they didn't work either ...
The strange thing is that if the image is PNG it does create the other sizes, the error happens only with JPG images. Even if I rename a JPG image to PNG the process doesn't work ...
Remembering that wordpress uploads the image normally, it just doesn't generate the extra JPG sizes, absolutely no additional sizes.
",kevinbkt10,5
24815,get_the_post_thumbnail() fetches full sized image if 'post-thumbnail' custom size not defined in theme,,has-patch,Media,2.9,normal,normal,,defect (bug),new,2013-07-22T09:43:42Z,2019-06-04T20:05:46Z,"In wp-includes/post-thumbnail-template.php the $size default value is set as 'post-thumbnail' in the following function:
- get_the_post_thumbnail()
'''Expected behaviour'''
Expected behaviour would be to return the image at 'post-thumbnail' dimensions - however, if this is not set in the theme via:
- set_post_thumbnail_size() function
- add_image_size() function
it returns the full sized sized image begin displayed. I'd expect this to return the image at standard 'thumbnail' size, as some people will just add add_theme_support( 'post-thumbnails' ) and not set (or even need) custom dimensions.
'''Proposal and patch'''
$size default value should default back to 'thumbnail' for normal expected function behaviour if 'post-thumbnail' specific dimensions have not been set.
I'm not sure if it would be more efficient to test against the global variable that holds these values, or use get_intermediate_image_sizes() as I've used in the patch attached - 2nd opinion please?",Jonnyauk,5
54205,jqxhr is undefined inside of deferred.done() when using wp.media to add a custom image upload,,,Media,5.8.1,normal,major,Awaiting Review,defect (bug),new,2021-09-30T20:55:42Z,2022-05-31T14:33:33Z,"I have done all the usual trouble shooting and found this is being cause by a new block of code added to wp-util.js in 5.8.1. Specifically lines 121-134.
The jqXHR property does not exist inside of the done() object and therefor always errors out. This is removing a key functionality of a clients admin that makes it where no new products can be added without a horrible workaround.",metawebdevelopment,5
49601,layout width bugfix for img_caption_shortcode(),,dev-feedback,Media,5.4,normal,normal,,defect (bug),reopened,2020-03-08T19:00:36Z,2022-10-13T21:01:21Z,"`img_caption_shortcode()` in `wp-includes/media.php` is hardcoding an inline `style=""width:""` attribute on the outer `
normal
Honor
this whitespace
';
}
}
$id = wp_update_nav_menu_item( $menu_id, $menu_item_db_id, $args );
}}}",WraithKenny,5
23275,WordPress Importer: line-ending mismatch corrupts serialized meta,,has-patch,Import,,normal,normal,,defect (bug),new,2013-01-23T16:56:04Z,2019-06-04T20:04:44Z,"A possible solution:
{{{
if ( $key ) {
// export gets meta straight from the DB so could have a serialized string
if ( ! $value )
$value = maybe_unserialize( $meta['value'] );
// Occationally, line-endings break unserialize()
if ( empty( $value ) ) // Try normalizing...
$value = maybe_unserialize( str_replace( array(""\r\n"", ""\r"", ""\n""), ""\r\n"", $meta['value'] ) );
if ( empty( $value ) ) // Adjust string length if needed
$value = maybe_unserialize(
preg_replace( // e flag deprecated in PHP 5.5.0 I think
'!s:(\d+):""(.*?)"";!se',
""'s:'.strlen('$2').':\""$2\"";'"",
$meta['value']
)
);
add_post_meta( $post_id, $key, $value );
do_action( 'import_post_meta', $post_id, $key, $value );
// if the post has a featured image, take note of this in case of remap
if ( '_thumbnail_id' == $key )
$this->featured_images[$post_id] = (int) $value;
}
}}}",WraithKenny,5
6393,Export & import blogroll with categories,,,Import,,normal,normal,Future Release,enhancement,new,2008-03-26T17:01:38Z,2019-03-15T00:36:00Z,"I have attached a patch which will export Blogroll OPML file having a category attribute in it. It is valid to have a category attribute in outline tag. Generated OPML file by wp-links-opml.php has been validated by http://validator.opml.org/.
I have also updated link-import.php and link-parse-opml.php files in wp-admin to parse category attribute and create link_category in database if it does not exist and assign link to that category.
This enhancement will automatically export and import link-categories with links.",jayminkapish,5
22976,Remove reference to category to tag converter from the tools page,,,Import,,normal,normal,,enhancement,new,2012-12-17T16:02:00Z,2019-06-04T20:04:32Z,"It has been such a long time since version 2.3, does anybody really need a reminder for the existence of this tool on that relatively high profile page?",mark-k,5
36098,"Install: ""Repeat Password"" is not required when browser js is disabled",,close,Login and Registration,,normal,normal,,defect (bug),new,2016-03-05T00:57:39Z,2020-02-16T21:35:57Z,"Recreate:
1. Turn off browser JS.
2. Install WordPress.
3. Go to step 2.
The ""'''Repeat Password'''"" field is marked as '''required'''. It's not.
----
Recreate this step by step:
Leave all fields empty and press the install button.
You will see an error saying: `Please provide a valid username.`
Enter invalid username (use spaces).
You will see an error saying: `The username you provided has invalid characters.`
Enter valid username.
You will see an error saying: `You must provide an email address.`
Enter some text (not an email).
You will see this error message: `Sorry, that isn’t a valid email address. Email addresses look like username@example.com.`
If you provide a valid email, it will install WordPress. ''' Password is not required! '''",ramiy,5
27086,Make auth-check logins work with 1Password,,,Login and Registration,,normal,normal,,defect (bug),new,2014-02-10T15:51:22Z,2019-06-04T20:06:45Z,"After some conversation on Twitter, I've been testing 1Password's browser extensions against WordPress. It works fine when logging in normally, but when you get logged out and need to log in from an iframe, it fails pretty hard.
Specifically, 1Password decides to fill *every* text input — even those that are hidden, that have content, or that aren't in the same form — with the login name. This is despite the web form fields being configured, present, and matching up perfectly.
(By hidden I'm referring to type=""text"" that is visually hidden, not type=""hidden"".)
Basic steps to trigger the issue:
* Have a login saved from wp-login.php (making sure that your web form details are for ""log"", ""pwd"" and optionally ""rememberme"").
* Edit a post.
* Hit the 1Password global shortcut, ⌘\. It will fill in every text input, including the title, the tags meta box input, the slug meta box input, etc. It's a mess.
Steps to reproduce with a real login form:
* Have a login saved from wp-login.php, etc.
* Edit a post.
* Delete your login cookies. Wait three minutes, or speed things up by calling `wp.heartbeat.connectNow()` in your console.
* An iframe should pop up (assuming you're not cross-domain, at least). Log in using ⌘\.
* It'll log into the iframe and submit it, which closes it.
* Note that the title field and all other text fields.
Steps to reproduce to comedic results:
* Have a login saved from wp-login.php, etc.
* Visit Settings > General.
* Delete your login cookies. Wait three minutes, or speed things up by calling `wp.heartbeat.connectNow()` in your console.
* An iframe should pop up (assuming you're not cross-domain, at least). Log in using ⌘\.
* It'll log into the iframe and submit it, which closes it.
* Note that every single settings field is filled with your login.
Here's a dead-simple HTML page to try that involves two different forms. Doesn't matter where the focus is when ⌘\ is invoked. Doesn't matter if it's one form, multiple forms, an iframe, whether the other inputs are even wrapped by form.
{{{