__group__,ticket,summary,owner,component,_version,priority,severity,milestone,type,_status,workflow,_created,modified,_description,_reporter
Future Releases,18525,"zlib.output_compression ""on"" in server conflicts with autoupdate",,Bootstrap/Load,3.2.1,normal,normal,Awaiting Review,defect (bug),reopened,dev-feedback,2011-08-26T20:11:45Z,2024-02-07T18:30:58Z,"If zlib.output_compression is ""on"" in server (my vps server), then auto-update works, but without verbose output or any indication that install has succeeded.
This error is consistent for all auto-updates WordPress Application and all plugins.
It is NOT a plugin conflict. Occurs on different servers.
Testing has confirmed that when zlib.output_compression is returned to ""off"", then updates work as expected.
In my opinion this is a minor bug and probably a note in the readme file will suffice.
Thank You,
Neil Miller
zx@avidre.net",avidre
Future Releases,24142,Zero value for posts_per_page value in wp_query custom instance and for 'Blog pages show at most' option,SergeyBiryukov,Query,,normal,normal,Future Release,defect (bug),reviewing,dev-feedback,2013-04-20T09:04:16Z,2024-02-18T16:12:32Z,"To show no posts if the posts_per_page value is 0.
Currently for custom instances of wp_query, if the value is 0 then this is changed with the value from posts_per_page option from the database. ""get_options( 'posts_per_page' )""
For home page if we set value 0 on the settings page, in wp-admin/options-reading.php, after the saves are changed, this value is changed to 1.
I think for both cases if the posts per page value is 0 then no posts should not display.
",alexvorn2
Future Releases,49599,Wrong PHPDoc wp_get_active_and_valid_plugins,,Plugins,5.3.2,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2020-03-08T14:08:07Z,2022-02-13T17:22:28Z,"I found a misleading error in the documentation of wp_get_active_and_valid_plugins (in wp-includes/load.php):
{{{#!php
Privacy.
2. Keep 'Change your Privacy Policy page' dropdown unselected.
3. Save settings by clicking on 'Use This Page' button.
**Expected Result:**
As there is no page selected in dropdown, it should not show the notice that page has been updated.
[[Image(https://ibb.co/3hyK6BY)]]
**Environment Details:**
WordPress version: 6.3.1
Browser: Chrome Version 116.0.5845.111
OS version: Windows 10
PHP version: 7.4.33
Server: Apache/2.4.57
Active Theme: Twenty Twenty-Three
Active Plugins: None
",anveshika
Future Releases,42637,Wrong button text for plugin installation failed!,,Plugins,,normal,normal,Awaiting Review,defect (bug),new,close,2017-11-20T07:42:07Z,2022-02-10T01:08:13Z,"Button text should be `Installation Failed!` instead of `Update Failed!` if plugin installation failed.
Check below gif:
Latest version: http://bsf.io/yola3
After applied patch: http://bsf.io/rblas",Mahesh901122
Future Releases,20019,wpmu_validate_blog_signup(): Allow '.' and '-' in blog names,,Login and Registration,3.0,normal,normal,,enhancement,reopened,dev-feedback,2012-02-10T23:04:29Z,2019-06-04T20:03:10Z,"Canonical uses Wordpress 3.x multisite as part of voices.canonical.com, for employees who do not have or wish to list their personal blog. The code is stock, except for one patch we maintain, which allows blog names (currently in WP as lowercase alphanumeric only) to also include '.' and '-'. This matches our global username format.
Attached is a patch extending wpmu_validate_blog_signup() to allow '.' and '-', with a tweak for the error text. We have been running the patch for awhile, and have not run across any problems with the rest of the code accepting this.",fo0bar
Future Releases,31166,wpmu_signup_user_notification filter is incorrect,,Login and Registration,3.0,normal,normal,,defect (bug),new,dev-feedback,2015-01-28T20:30:03Z,2019-06-04T20:10:50Z,"Simple ticket here,
The wpmu_signup_user_notification filter seems to be filtering the wrong option
{{{
if ( ! apply_filters( 'wpmu_signup_user_notification', $user, $user_email, $key, $meta ) )
return false;
}}}
If I'm thinking correctly, the filter should be filtering a boolean. If two filters are added to this and the first returns false, there is no way for the second filter to recover the $user variable.
This is how I see it working
WP4.1, /wp-includes/ms-functions.php line 919
{{{
if ( ! apply_filters( 'wpmu_signup_user_notification', true, $user, $user_email, $key, $meta ) )
return false;
}}}",johnrom
Future Releases,12756,WPMU does not handle files with two or more dots in the filename,wpmuguru,Upload,2.9.2,normal,minor,Future Release,defect (bug),reopened,close,2010-03-29T07:23:50Z,2022-10-14T18:47:54Z,"* WPMU does download images that have two or more dots in the file name
> E.g., One..jpg One...jpg One....jpg
rewrites do work (checked)
* this is clearly a WP issue:
> /wp-content/blogs.php
...
$file = BLOGUPLOADDIR . str_replace( '..', '', $_GET[ 'file' ] );
if ( !is_file( $file ) ) {
status_header( 404 );
die('404 — File not found.');
}
...
> WPMU removes two dots!!!
> workaround:
$file = BLOGUPLOADDIR . $_GET[ 'file' ]; // name.ly: workaround for files with two or more dots
tested and works fine
",Namely
Future Releases,28530,WPMU Creating new user does not use welcome notification template,,Networks and Sites,,normal,normal,,defect (bug),reopened,dev-feedback,2014-06-13T16:36:27Z,2019-06-04T20:08:14Z,"In a multisite setting adding a new user to the network should send a welcome notification to the user with a template defined in '''Settings > 'Welcome User Email''''. But the template is not used.
When creating a new user via {{{/network/user-new.php}}} the method {{{wp_new_user_notification}}} gets called. Instead {{{wpmu_welcome_user_notification}}} should get called.",jokr
Future Releases,12257,wpdb Scales Badly Due to Unnecessary Copies of All Query Results,,Database,,normal,critical,,defect (bug),assigned,dev-feedback,2010-02-17T03:08:06Z,2019-06-04T19:21:45Z,"While working on #11726, I encountered a reproducible crash in wpdb::query()
The following code causes memory exhaustion on large result sets:
{{{
while ( $row = @mysql_fetch_object($this->result) ) {
$this->last_result[$num_rows] = $row;
$num_rows++;
}
}}}
The memory exhaustion message is error-controlled, causing a white screen of death even in debug mode.
I searched wp-db.php for references to $this->last_result, and I found no justification for these object reference copies. $this->last_result '''should''' be maintained as a MySQL resource and properly optimized using the MySQL client layer instead of this PHP nonsense.
Tagging for dev-feedback to discuss which Milestone is appropriate.",miqrogroove
Future Releases,11678,wpautop() fails on uppercase closing tags,,Formatting,2.9,normal,normal,,defect (bug),new,dev-feedback,2009-12-31T11:26:11Z,2019-06-04T19:42:47Z,"To reproduce, in a post enter:
{{{
Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!
}}}
View the post (source) and you get:
{{{
Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!
}}}
Because I (incorrectly) entered an uppercase closing tag, wpautop() thinks there is no closing tag so adds a , which then often renders as a double tag. Close if this is not a bug, though I thought it may be good to do some sanitizing or something on uppercase tags.
",joehoyle
Future Releases,2833,wpautop breaks style and script tags,,Formatting,2.0.3,low,normal,Future Release,defect (bug),reopened,dev-feedback,2006-06-17T20:36:00Z,2022-03-29T01:38:54Z,"When I create a post in which I want to include Javascript or some styles, WordPress 'breaks'when showing those posts, because all newlines in the SCRIPT and STYLE tag are converted into BR tags.
Example:
{{{
}}}
Becomes:
{{{
}}}
And:
{{{
}}}
Becomes
{{{
}}}
This happens because wpautop adds those BR tags to the post. (As it should, just not within STYLE or SCRIPT tags.)
I've made a (temporary?) workaround for this by creating a pre and post event for wpautop, which substitute the necessary newlines by a temporary value in the pre event and placing them back in the post event. Although I think this should be incorporated in wpautop itself.
See also: http://wordpress.org/support/topic/76433 and http://wordpress.org/support/topic/76297
While searching trac I also found ticket #2346, which is about the same problem, but which was for 2.0 and self-closed by the submitter?
P.S. I have TinyMCE turned of.",Nazgul
Future Releases,40676,"wpautop adds opening & closing p tags around the opening a tag and around the closing a tag when the link contains certain flow content elements like div, h1, h2...",,Formatting,4.8,normal,normal,Awaiting Review,defect (bug),new,needs-unit-tests,2017-05-05T10:55:47Z,2017-07-21T11:02:23Z,"Hi,
== Description ==
wpautop leaves {{{}}} (opening tag of the link) in between {{{
}}} tags and {{{ }}} (closing tag of the link) in between {{{
}}} tags when the link contains certain flow content elements like div, h1, h2...
== Example 1 ==
If I add this to the HTML editor:
{{{
DIV inside link
}}}
The output source code is:
{{{
DIV inside link
}}}
----
== Example 2 ==
If I add this to the HTML editor:
{{{
H1 inside link
}}}
The output source code is:
{{{
H1 inside link
}}}
----
== Note 1 ==
I would like to point out that html '''''flow content'' elements such as {{{}}} or headings ({{{
, , }}} ,...) belong to the category of permitted content for the {{{}}} element'''. References:
[https://html.spec.whatwg.org/multipage/semantics.html#the-a-element WHATWG HTML Living Standard |The definition of a]
[http://www.w3.org/TR/html5/text-level-semantics.html#the-a-element HTML5 | The definition of a]
[https://developer.mozilla.org/en/docs/Web/HTML/Element/a MDN | The definition of a.]
----
== Note 2 ==
This issue might be related to ticket #34722",diegocanal
Future Releases,56025,"wp_validate_boolean() not doing what it describes, causes issues with [video] shortcode",,General,6.0,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2022-06-21T08:51:00Z,2022-06-22T13:52:45Z,"
== The function in question:
{{{
/**
* Filter/validate a variable as a boolean.
*
* Alternative to `filter_var( $var, FILTER_VALIDATE_BOOLEAN )`.
*
* @since 4.0.0
*
* @param mixed $var Boolean value to validate.
* @return bool Whether the value is validated.
*/
function wp_validate_boolean( $var ) {
if ( is_bool( $var ) ) {
return $var;
}
if ( is_string( $var ) && 'false' === strtolower( $var ) ) {
return false;
}
return (bool) $var;
}
}}}
== Steps to recreate the issue:
Add the following shortcodes to a page:
{{{
[video src=""YOUR-SOURCE-HERE""]
[video src=""YOUR-SOURCE-HERE"" loop=""off""]
[video src=""YOUR-SOURCE-HERE"" loop=""0""]
[video src=""YOUR-SOURCE-HERE"" loop=""false""]
}}}
- The first shortcode works as intended, rendering a video on the frontend without the loop attribute.
- The second shortcode's element will have the attribute {{{loop=""1""}}} despite the loop attribute being set to off.
- The third and fourth shortcode's elements will **not** have the loop attribute set.
== Description:
wp_validate_boolean() says it 's an alternative to {{{ filter_var( $var, FILTER_VALIDATE_BOOLEAN ) }}}, however
{{{filter_var( $var, FILTER_VALIDATE_BOOLEAN )}}} will return **FALSE** when you pass the string ""off"" whereas {{{wp_validate_boolean()}}} will return **TRUE** in this case.
(See this for the documentation for filter_validate_boolean: [https://www.w3schools.com/php/filter_validate_boolean.asp]).
Currently, {{{wp_validate_boolean()}}} only returns **FALSE** if the $var is a string and if it is === ""false"", or if the $var passed is the int 0.
This causes unexpected behaviour in the [video] shortcode. The documentation of the video shortcode ([https://wordpress.org/support/article/video-shortcode/]) mentions that the loop attribute needs to be either ""on""/""off"". Because they are strings {{{wp_validate_boolean()}}} will return **TRUE**, causing the loop attribute to always be added with a value of ""1"" unless you change the value of the attribute to be specifically the string ""false"", the int 0, or leave it completely empty.
The parsing of the attributes of the [video] shortcode happens here: ([https://github.com/WordPress/wordpress-develop/blob/6.0/src/wp-includes/media.php#L3322-L3344]).
As you can see on line 3340 it uses {{{wp_validate_boolean()}}} to get filter value of the loop attribute. Passing ""off"" here returns true, causing the loop attribute to always be added to the eventual HTML output later down the line with a value of ""1"".
== Potential fix:
- Change the working of {{{wp_validate_boolean()}}} to do as it says in its description. Make it smarter, and thus also return **FALSE** when the strings ""off"",""OFF"",""no"",""NO"", etc. are passed just like {{{filter_var( $var, FILTER_VALIDATE_BOOLEAN )}}} does (See this documentation link: [https://www.php.net/manual/en/function.filter-var.php#121263]).
- Change how the parsing of attributes happens in the [video] shortcode so that it also works as the documentation says: not adding certain attributes when they are set to ""off"". However there may be other instances where {{{wp_validate_boolean()}}} is used that I'm currently not aware of, so this would be more like a band-aid fix and similar issues may arise in the future.
",arnodeleeuw
Future Releases,53199,WP_User::add_role() runs even if the added role is already set,,Users,2.0,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2021-05-13T11:27:05Z,2021-05-13T15:46:07Z,"When adding a role using `WP_User::add_role()` the function is run even though the role is already set for the given user. Hence, the also action `add_user_role` is fired when it should not.
This behavior is different from `WP_User::remove_role()` that exits the function if the role is not currently set, and hence the action `remove_user_role` does not fire - as one would expect.
An easy fix would be to add `in_array( $role, $this->roles, true )` to the test in [[https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-wp-user.php#L540|class-wp-user.php on Line 540]] resulting in the following:
{{{
if ( empty( $role ) || in_array( $role, $this->roles, true ) ) {
}}}
Not sure if there are any backward-compatibility issues with this solution, as the action would not be called anymore in situations where previously it was called. A solution could be to run the action nonetheless, which would, however, kinda obsolete the fix. Another solution could be to introduce a new action, e.g. `add_user_role_requested`:
{{{
if ( empty( $role ) ) {
return;
}
/**
* Fires immediately after the user has been given a new role.
*
* @since x.x.x
*
* @param int $user_id The user ID.
* @param string $role The new role.
*/
do_action( 'add_user_role_requested', $this->ID, $role );
if ( in_array( $role, $this->roles, true ) ) {
return;
}
}}}
This filter uses the same syntax, than the existing `add_user_role`. I personally would prefer to pass the user object (`$this`) rather than the user ID. Maybe the user object could be passed as a third argument to both actions.
",bhujagendra
Future Releases,26626,WP_Upgrader::unpack_package() can overflow path name length limits,,Upgrade/Install,2.7,normal,normal,,defect (bug),new,dev-feedback,2013-12-14T17:16:10Z,2021-05-18T17:50:48Z,"I had no idea that in 2013, there were still operating systems with pathname length limits of only 256 characters. But, apparently there are - I've had 3 reports of it in the last week (which came after I included an SDK in one of my plugins that had a lot of sub-directories).
Two of the victims got hit when unpacking the plugin through a normal update. To prevent this in future, I restructured my plugin.
The other victim was running Bitnami WAMP, with PHP 5.4.22 (Windows NT AFLAPTOP 6.1 build 7601 (Windows 7 Business Edition Service Pack 1) i586), and he was accessing WP_Upgrader::unpack_package() via a restore operation in UpdraftPlus Backup/Restore (http://wordpress.org/plugins/updraftplus), which uses this method to unpack zip files.
See http://wordpress.org/support/topic/restore-fails-could-not-create-directory for more information on that. Basically, it boiled down to ""WP_Upgrader::unpack_package() uses the basename of the zip file to create a directory in WP_CONTENT_DIR/upgrade/"". So, if the zip file name is very long, then a meaningful amount of the potential 256-character limit can be lost.
The guy running Bitnami lost 80 characters to reach his upgrade folder: `C:\Program Files\BitNami WAMP Stack\apps\wordpresslucid\htdocs\wp-content/upgrade`. That leaves 176 characters.
The plugin he was unpacking needed 98 characters for its longest pathname: `/plugins//opencloud/symed/Symfony/Component/EventDispatcher/EventDispatcherInterface.php`. That leaves 78 characters to spare. Should be plenty... except for WP_Upgrader::unpack_package() wanting to use basename($zipfile) to create a directory for unpacking into. The zipfile did indeed have a filename of over 78 characters long. Boom!
To prevent other scenarios in which someone might get hit by this, we can just change this line:
{{{
$working_dir = $upgrade_folder . basename($package, '.zip');
}}}
to:
{{{
$working_dir = $upgrade_folder . substr(md5(basename($package, '.zip')), 0, 8);
}}}
The use of md5() to prevent collisions might be over-cautious (especially given that WP_Upgrader::unpack_package() already tries to empty out the upgrades directory), but it's also harmless.",DavidAnderson
Future Releases,42183,wp_update_user() conditional compares a plain-text password to the hashed old,SergeyBiryukov,Users,4.5.2,normal,normal,Future Release,defect (bug),reviewing,needs-unit-tests,2017-10-11T14:20:02Z,2019-01-16T03:25:00Z,"In file wp-includes/user.php, function [https://developer.wordpress.org/reference/functions/wp_update_user/ wp_update_user()]
On line 1767:
{{{
if ( ! empty( $userdata['user_pass'] ) && $userdata['user_pass'] !== $user_obj->user_pass)
}}}
The second conditional is comparing a plain-text password to a hashed version of password, so this would almost always evaluate to true except for the case where the new password itself matches the old hashed password. This block will then evaluate to false and therefore password itself won't be updated. It's a rare case but the logic here is incorrect. And obviously this code block would run when passwords are the same since it's comparing plain-text to the hashed version.",yudge
Future Releases,20275,wp_update_nav_menu hook is not fired when nav menu item is auto-added,,Menus,,normal,normal,,defect (bug),new,dev-feedback,2012-03-21T19:30:59Z,2019-06-04T20:03:18Z,"WP calls the action hook 'wp_update_nav_menu' when a navigation menu is updated. For example, go to Site Design -> Custom Menus -> Click the ""Save Menu"" button on a menu.
Next to the Menu title, the Custom Menus provide the user to ""Automatically add new top-level pages"". When this option is checked, and a new top-level page is created, the 'wp_update_nav_menu' hook is not fired. So the attached nav-menu-hooks.diff patch fixes that.
I would also suggest that we do not use the same hook 'wp_update_nav_menu' twice (as it is currently being done) with different amount of arguments, because this causes a PHP Warning
{{{
PHP Warning: Missing argument 2 for x_save_footer() in /var/www/branches/x.trunk/wp-content/themes/x/functions.php on line 815, referer: http://x.com/x/wp-admin/nav-menus.php
}}}
for code:
{{{
add_action('wp_update_nav_menu', 'x_save_footer', 10, 2);
}}}
So, the hook call at nav-menu.php:255 has 2 parameters and the call at nav-menus.php:383 has 1 parameter.
As a fix, the action hook in nav-menu.php should be named something else, like 'wp_update_nav_menu_object' (because it is updating the object), as done in the attached nav-menu-hooks.diff patch. This will also prevent the same hook from being fired twice when updating the nav menus.",inderpreet99
Future Releases,55999,wp_suspend_cache_addition should also disable cache setting?,,Cache API,,normal,normal,Future Release,defect (bug),new,dev-feedback,2022-06-17T09:30:15Z,2024-02-07T19:31:56Z,"Right now wp_suspend_cache_addition is only checked when ""add"" to cache.
However most plugins/developers only use wp_cache_set for updating/adding to the cache.
This means in most plugins/cases, wp_suspend_cache_addition has no use, in fact it's rather unexpected behavior that only some functions can add to cache (namely: set, incr, decr)
I propose we also check wp_suspend_cache_addition before setting the cache.
This would also be in line with its function description:
>Stops more data being added to the cache, but still allows cache retrieval.
As ""set"" also ""adds"" (or at least modifies if already exists therefore adds/subtracts) data in cache.",malthert
Future Releases,41522,wp_set_password() doesn't trigger a changed password notification,,Users,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2017-08-01T20:30:59Z,2017-08-02T13:53:31Z,"If {{{wp_update_user()}}} is used to update a user's password, a notification is sent to the user telling them their password has changed.
However, the same doesn't happen if {{{wp_set_password()}}} is used to update a user's password.",henry.wright
Future Releases,52448,wp_scheduled_delete WP-Cron Job Cannot Be Unscheduled,,Administration,4.9,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2021-02-04T16:06:36Z,2021-02-05T15:20:49Z,"My organization has disabled automatic trash deletion to preserve history on a large multisite network we host. We have done this via the following method:
{{{#!php
roles[$role]['name'];
}}}
",garrett-eclipse
Future Releases,53262,"wp_robots() (via wp_die) triggers a ""doing_it_wrong_trigger_error"", but should not.",,General,5.7,normal,minor,Awaiting Review,defect (bug),new,dev-feedback,2021-05-23T21:43:29Z,2022-08-03T15:31:55Z,"Hello there.
In my plugin, I need to die early, like, right after the plugins are loaded, imagine this for a shortcut:
`add_action( 'plugins_loaded', 'wp_die' );`
This is the output:
''Notice: is_embed was called incorrectly. Conditional query tags do not work before the query is run. Before then, they always return false. Please see Debugging in WordPress for more information. (This message was added in version 3.1.0.) in /wp-includes/functions.php on line 5313''
{{{
# Time Memory Function Location
1 0.0002 369912 {main}( ) .../admin.php:0
2 0.0003 370552 require_once( '/wp-load.php' ) .../admin.php:34
3 0.0003 370960 require_once( '/wp-config.php' ) .../wp-load.php:37
4 0.0003 375568 require_once( '/wp-settings.php' ) .../wp-config.php:88
5 0.0410 1735152 do_action( ) .../wp-settings.php:423
6 0.0411 1735528 WP_Hook->do_action( ) .../plugin.php:484
7 0.0411 1735528 WP_Hook->apply_filters( ) .../class-wp-hook.php:316
8 0.0882 3856336 wp_die( ) .../class-wp-hook.php:292
9 0.0882 3874480 _default_wp_die_handler( ) .../common.php:275
10 0.0884 3876304 wp_robots( ) .../functions.php:3497
11 0.0884 3876304 apply_filters( ) .../robots-template.php:32
12 0.0884 3876712 WP_Hook->apply_filters( ) .../plugin.php:212
13 0.0884 3878216 wp_robots_noindex_embeds( ) .../class-wp-hook.php:292
14 0.0884 3878216 is_embed( ) .../robots-template.php:93
15 0.0884 3878216 _doing_it_wrong( ) .../query.php:881
16 0.0885 3879304 trigger_error ( ) .../functions.php:5313
}}}
another notice will be trigger, same thing but line 13 will be `wp_robots_noindex_search`.
Since WP 5.7 the `wp_robots()` function is called in a `wp_die()`, but `wp_die()` can be called before the query is done, this is not too soon to die ''(for once, got it?)''.
A possible patch is to delay these default filters a bit later ''(wp-includes/default-filters.php)'' instead of adding them right away:
{{{
add_action( 'wp', 'wp_late_robots_check' );
function wp_late_robots_check() {
add_filter( 'wp_robots', 'wp_robots_noindex_embeds' );
add_filter( 'wp_robots', 'wp_robots_noindex_search' );
}
}}}
Thanks for your attention.",juliobox
Future Releases,34466,"wp_register_form, wp_lost_password_form function",,Login and Registration,4.4,normal,normal,Awaiting Review,feature request,new,dev-feedback,2015-10-27T14:48:11Z,2017-02-22T09:57:13Z,"Hi,
We currently have a wp_login_form function to display the login form, however, we do not currently have an opposite for the registration form.
'''Should look into:'''
wp_register_form
wp_lost_password_form
",atomicjack
Future Releases,39945,WP_Query::get_posts fails to correctly sanitize 'posts_per_page',,Query,4.7.2,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2017-02-22T21:34:01Z,2020-03-03T22:32:24Z,"WP_Query::get_posts fails to correctly sanitize the 'posts_per_page' argument when a negative value in range (-2, -1) is supplied.
== Example ==
The following get_posts query causes an exception:
{{{
get_posts(array('posts_per_page' => '-1.5'));
}}}
Exception: WordPress database error You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '-1' at line 1 for query SELECT wp_posts.ID FROM wp_posts WHERE 1=1 AND wp_posts.post_type = 'post' AND ((wp_posts.post_status = 'publish')) ORDER BY wp_posts.post_date DESC LIMIT 0, -1 made by get_posts, WP_Query->query, WP_Query->get_posts
== Cause ==
Incomplete sanitization in WP_Query::get_posts(), line 1775 - 1779:
{{{
$q['posts_per_page'] = (int) $q['posts_per_page'];
if ( $q['posts_per_page'] < -1 )
$q['posts_per_page'] = abs($q['posts_per_page']);
elseif ( $q['posts_per_page'] == 0 )
$q['posts_per_page'] = 1;
}}}
== Impact ==
Some plugins (e.g. Woocommerce) initialize the posts_per_page argument with user supplied values and may suffer from an information disclosure vulnerability, depending on the webserver configuration.
Confirmed on the latest Wordpress version 4.7.2.
First reported at 19.02.2017 to security[at]wordpress.org without response (not nice!), so I assume you do not consider this security relevant in accordance with e.g. https://make.wordpress.org/core/handbook/testing/reporting-security-vulnerabilities/#why-are-there-path-disclosures-when-directly-loading-certain-files",biisent
Future Releases,51094,WP_Query.query with invalid post_status will return all,metalandcoffee*,Query,3.9,normal,critical,Future Release,defect (bug),accepted,needs-unit-tests,2020-08-21T12:18:59Z,2022-06-14T20:01:36Z,"Hello, I noticed an issue with WooCommerce method {{{ wc_get_products }}} and dove into the issue.
The problem was {{{ wc_get_products(array('status' => 'published')); }}} would return **ALL** posts, even trashed ones because of the ""published"" status is not a valid post status.
I believe that behavior is unexpected that it should return **NO** posts.
The issue appears to be this portion of {{{WP_Query.get_posts}}} that only known post statuses are added to the query:
{{{#!php
posts}.post_status = '$status'"";
} else {
$r_status[] = ""{$wpdb->posts}.post_status = '$status'"";
}
}
}
}}}
I believe it would best if this method checks for any unrequested post status supplied in the query and either applies them to the query or produces an error. I would imagine this is a pretty major change.",carsonreinke
Future Releases,20289,wp_nav_menu container is not set when menu isn't defined,,Menus,3.3,normal,normal,,defect (bug),new,dev-feedback,2012-03-23T10:27:03Z,2019-06-04T20:03:19Z,"When you use wp_nav_menu in your theme, but the actual menu isn't set via the backend menu interface, the container provided in the args is ignored and falls back to 'div'.
Attached diff always uses container provided in args, if 'div' or 'nav' is provided. If no container arg is provided, falls back to using 'div'.
{{{
wp_nav_menu(
array(
'theme_location' => 'main_menu',
'container' => 'nav',
'menu_class' => 'main-menu-navigation',
)
);
}}}
To test this: Use this function in your theme, without assigning a menu to this theme_location.",dannydehaan
Future Releases,33341,WP_Meta_Query IN operator with empty array does not return expected result,,Query,3.2,normal,critical,Awaiting Review,defect (bug),reopened,dev-feedback,2015-08-11T18:32:26Z,2023-10-17T19:18:10Z,"When using the `IN` compare mode in a `WP_Meta_Query` where the value is an empty array, this query is evaluated with an unexpected behavior.
For example, I have some posts with a meta field called `'some-textfield'`:
{{{
$posts = get_posts( array(
'posts_per_page' => -1,
'post_type' => 'post',
'post_status' => 'publish',
'meta_query' => array(
array(
'key' => 'some-textfield',
'value' => array(),
'compare' => 'IN',
),
),
) );
}}}
This code returns all posts although I would rather expect it to return no posts at all since the value of `'some-textfield'` (whatever it may be) is not ''in'' those provided in the `value` field.
I discovered it when I needed to perform a meta query where the value was an array that was returned by a previous operation. It is obviously a minor issue since we can simply check if the array is empty (and in that case do not make the query at all) - but I thought it's not really the expected result of such a query.
The solution would be to:
* ignore this condition if the `relation` is set to `OR` and there are other conditions available
* evaluate this condition to false otherwise (and thus return no results)",flixos90
Future Releases,49687,wp_mail() - Why is no envelope sender defined?,,Mail,5.4,normal,minor,Awaiting Review,enhancement,new,dev-feedback,2020-03-23T23:15:14Z,2022-11-17T08:47:39Z,"As just figured out, some (mail) servers require the envelope sender to be set in order to accept outgoing emails.
For the PHP built-in mail() function (https://www.php.net/manual/en/function.mail.php) this can be done using the additional parameter (e.g. ""-fwebmaster@example.com) as explained in example 4 of the PHP manual page.
In order to use that option and set the envelope sender in PHPmailer either the sender attribute of the phpmailer object needs to be set ($phpmailer->Sender = ""sender@example.com"") or when using the setFrom() method of PHPmailer, the 3rd parameter needs to be set to true (=default).
Unfortunately, the current implementation of wp_mail() explicitly sets that 3rd parameter to false, which prevents the envelope sender from being set (see https://core.trac.wordpress.org/browser/trunk/src/wp-includes/pluggable.php?rev=47494#L358).
Is there any reason for doing so and could we change L358 to
$phpmailer->setFrom( $from_email, $from_name, true );
?",vbbp
Future Releases,56425,wp_localize_script assign to const and freeze instead of var to avoid reassignments,,Script Loader,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2022-08-23T23:59:48Z,2022-11-08T07:36:06Z,"wp_localize_script adds elements as ""var"".
To avoid accidental, silent overwrites by other plugins or malicious code, it would be better if we used a const and freeze the object, to disable reassignments.
",malthert
Future Releases,57200,WP_List_Table::pagination use singular and plural,,Administration,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2022-11-24T23:33:23Z,2022-12-03T11:23:40Z,"WP_List_Table::pagination() currently hardcodes the number of records display as ""1 item""/""XX items"". It would be nice if it used the singular and plural set in the constructor, defaulting to item/items if none are set.",RoscoHead
Future Releases,15386,WP_List_Table::get_columns does not work for plugins,scribu,Administration,3.1,high,major,Future Release,defect (bug),reopened,close,2010-11-11T14:42:28Z,2023-02-16T20:06:44Z,"Creating a new table based on the WP_List_Table class does not work as the get_columns method is not being called.
The problem is when WP_List_Table::get_column_info() calls get_column_headers() instead of $this->get_columns() where all the column data is stored.
Moving the filter manage_*_columns from get_column_headers() into WP_List_Table::get_column_info() along with passing $this->get_columns() fixes this issue.",ptahdunbar
Future Releases,54720,WP_List_Table Inside Metabox With Bulk Actions Not Working on Submit,,"Posts, Post Types",5.8.2,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2022-01-03T11:40:53Z,2022-01-03T11:40:53Z,"I'm trying to display a WP_List_table inside a metabox. The metabox is for questions which are from assessment_question custom post type.The metabox is being displayed on an other custom post type 'cs_questionnaire'. The table columns display some data taken from questions. Also I am using bulk actions to link questions to a questionnaire.
What's happening is that it all looks fine until I click the Publish/Update button on the custom post type edit screen. If the WP_List_Table has bulk actions it will redirect back to the /wp-admin/edit.php page, if I remove the bulk actions then it Works fine. And in both cases, the nonce stays the same and no extra nonce is created.
I've whole code below. I have already overridden the display_tablenav function by commenting the nonce generating code. It stops working when I provide bulk actions else it works fine with the following code.
{{{#!php
data
/** Class constructor */
public function __construct() {
parent::__construct(
array(
'singular' => __( 'Question', 'conditional-shortcode' ), // singular name of the listed records
'plural' => __( 'Questions', 'conditional-shortcode' ), // plural name of the listed records
'ajax' => false, // does this table support ajax?
)
);
}
/**
* Function to filter data based on order , order_by & searched items
*
* @param string $orderby
* @param string $order
* @param string $search_term
* @return array $users_array()
*/
public function list_table_data_fun( $orderby = '', $order = '', $search_term = '' ) {
$args = array();
$questions_array = array();
$questions = '';
$flag = false;
if ( ! empty( $search_term ) ) {
$args = array(
'fields' => 'ids',
'orderby' => $orderby,
'order' => $order,
'search' => intval( sanitize_text_field( $_REQUEST['s'] ) ),
'post_type' => 'assessment_question',
'posts_per_page' => -1,
);
} else {
if ( $order == 'asc' && $orderby == 'id' ) {
$args = array(
'orderby' => 'ID',
'order' => 'ASC',
'fields' => 'ids',
'post_type' => 'assessment_question',
'posts_per_page' => -1,
);
} elseif ( $order == 'desc' && $orderby == 'id' ) {
$args = array(
'orderby' => 'ID',
'order' => 'DESC',
'fields' => 'ids',
'post_type' => 'assessment_question',
'posts_per_page' => -1,
);
} elseif ( $order == 'desc' && $orderby == 'title' ) {
$args = array(
'orderby' => 'name',
'order' => 'DESC',
'fields' => 'ids',
'post_type' => 'assessment_question',
'posts_per_page' => -1,
);
} elseif ( $order == 'asc' && $orderby == 'title' ) {
$args = array(
'orderby' => 'name',
'order' => 'ASC',
'fields' => 'ids',
'post_type' => 'assessment_question',
'posts_per_page' => -1,
);
} else {
$args = array(
'orderby' => 'ID',
'order' => 'DESC',
'fields' => 'ids',
'post_type' => 'assessment_question',
'posts_per_page' => -1,
);
$flag = true;
}
}
$questions = get_transient( 'pd_questions' );
if ( $flag == false ) {
$questions = get_posts( $args );
} elseif ( $flag == true && ! $questions ) {
$questions = get_posts( $args );
set_transient( 'pd_questions', $questions, 1 * DAY_IN_SECONDS );
}
if ( count( $questions ) > 0 ) {
foreach ( $questions as $question_id ) {
$question = get_post_meta( $question_id ?? 0, CONDITIONAL_SHORTCODE_ASSESSMENT_QUESTION_META, true )['question'] ?? 'NA';
$questions_array[] = array(
'id' => $question_id,
'title' => '' . get_the_title( $question_id ) . ' ',
'question' => $question,
);
}
}
return $questions_array;
}
// prepare_items
public function prepare_items() {
$orderby = sanitize_text_field( isset( $_GET['orderby'] ) ? trim( $_GET['orderby'] ) : '' );
$order = sanitize_text_field( isset( $_GET['order'] ) ? trim( $_GET['order'] ) : '' );
$search_term = sanitize_text_field( isset( $_POST['s'] ) ? trim( $_POST['s'] ) : '' );
if ( $search_term == '' ) {
$search_term = sanitize_text_field( isset( $_GET['s'] ) ? trim( $_GET['s'] ) : '' );
}
$datas = $this->list_table_data_fun( $orderby, $order, $search_term );
$per_page = 30;
$current_page = $this->get_pagenum();
$total_items = count( $datas );
$this->set_pagination_args(
array(
'total_items' => $total_items,
'per_page' => $per_page,
)
);
$this->items = array_slice( $datas, ( ( $current_page - 1 ) * $per_page ), $per_page );
$columns = $this->get_columns();
$hidden = $this->get_hidden_columns();
$sortable = $this->get_sortable_columns();
$this->_column_headers = array( $columns, $hidden, $sortable );
$this->process_bulk_action();
}
public function get_bulk_actions() {
return array(
'add_questions' => __( 'Add Questions', 'conditional-shortcode' ),
'remove_questions' => __( 'Remove Questions', 'conditional-shortcode' ),
);
}
// get_columns
public function get_columns() {
$columns = array(
'cb' => ' ',
'id' => __( 'ID', 'conditional-shortcode' ),
'title' => __( 'Title', 'conditional-shortcode' ),
'question' => __( 'Questions', 'conditional-shortcode' ),
'action' => __( 'Action', 'conditional-shortcode' ),
);
return $columns;
}
public function get_hidden_columns() {
return array( '' );
}
public function get_sortable_columns() {
return array(
'title' => array( 'title', true ),
'id' => array( 'id', true ),
);
}
/**
* Generate the table navigation above or below the table.
*
* @since 3.1.0
* @access protected
*
* @param string $which
*/
protected function display_tablenav( $which ) {
// REMOVED NONCE -- INTERFERING WITH SAVING POSTS ON METABOXES
// Add better detection if this class is used on meta box or not.
/*
if ( 'top' == $which ) {
wp_nonce_field( 'bulk-' . $this->_args['plural'] );
}
*/
?>
"">
bulk_actions( $which ); ?>
extra_tablenav( $which );
$this->pagination( $which );
?>
Add Question ';
default:
return 'no value';
}
}
public function column_title( $item ) {
$post_id = get_the_ID();
$action = array(
'edit' => sprintf( 'Add Question ', $post_id, 'edit', 'add_question', $item['id'], $post_id ),
);
return sprintf( '%1$s %2$s', $item['title'], $this->row_actions( $action ) );
}
function column_cb( $item ) {
return sprintf(
' ',
$item['id']
);
}
function no_items() {
esc_html_e( 'No Questions Found.', 'conditional-shortcode' );
}
public function process_bulk_action() {
// security check!
if ( isset( $_POST['_wpnonce'] ) && ! empty( $_POST['_wpnonce'] ) ) {
$nonce = filter_input( INPUT_POST, '_wpnonce', FILTER_SANITIZE_STRING );
$action = 'bulk-' . $this->_args['plural'];
if ( ! wp_verify_nonce( $nonce, $action ) ) {
wp_die( 'Nope! Security check failed!' );
}
}
$action = $this->current_action();
switch ( $action ) {
case 'delete_questions':
wp_die( 'Delete something' );
break;
case 'add_questions':
wp_die( 'Save something' );
break;
default:
// do nothing or something else
return;
break;
}
wp_redirect( esc_url( add_query_arg() ) );
exit;
return;
}
}
/**
* Shows the List table for all questions.
*
* @return void
*/
function conditional_shortcode_questions_list_table_layout() {
$table = new Class_Conditional_Shortcode_Questions_Listing();
printf( '
%s ', __( '', 'conditional-shortcode' ) );
echo '';
echo '';
}
conditional_shortcode_questions_list_table_layout();
}}}
I was able to resolve this issue by changing the value of name attribute of bulk actions select field. Like from name to names. What I think the issue could be is when here the name=""action"" for this select and it has some value xyz on the other side WordPress save post looks for action to be equal to edit.
Can we provide a way of changing this name attributes value either by providing a filter or by changing it. But I think changing name attribute would require a lot of other code changes so its better to provide a filter for custom use. Or add a comment on top so someone else using WP LIST Table in a metabox must override this function with custom value to name attribute.
For clarity I changed
This echo '\n"";
To this echo '\n"";
Thanks!
",muhammadfaizanhaidar
Future Releases,41714,"wp_list_pages() - horrible performance due to eventual ""SELECT *""",,"Posts, Post Types",4.9,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2017-08-23T16:15:00Z,2023-07-06T14:29:05Z,"I'm investigating awful performance (MySQL slow queries logged constantly) a site which uses a plugin to display a page list.
The plugin calls wp_list_pages(). wp_list_pages() in turn calls get_posts(). And get_posts() ends up making the slow query:
{{{
SELECT * FROM wp_posts WHERE (post_type = ‘page’ AND post_status = ‘publish’) ORDER BY wp_posts.post_date ASC;
}}}
So, all the post_content fields (along with everything else) are being requested, just for the purposes of constructing a page list. (The site has ~ 1200 pages - and the above call returns 34MB from the MySQL server).
It looks like either get_posts() needs some more flexibility so that it has an option to return only specified fields.",DavidAnderson
Future Releases,41760,wp_list_comments callback params,,Comments,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2017-08-30T18:44:15Z,2017-08-31T09:05:53Z,"In `wp-includes/class-walker-comment.php`, methods `comment()` and `html5_comment()` have following order of @params: `$comment, $depth, $args`.
However, when you try to modify comment markup using `callback` argument for `wp_list_comments()`, order of params is `$comment, $args, $depth`.
Is it possible to make the same order of params?",milana_cap
Future Releases,23498,wp_list_authors ignores 'exclude_admin' arg when admin account has a display_name other then 'admin',SergeyBiryukov,Users,3.1,normal,normal,Future Release,defect (bug),reviewing,dev-feedback,2013-02-18T09:37:59Z,2023-12-15T00:50:09Z,"Line 293 of author-template.php should be changed from:
{{{
if ( $exclude_admin && 'admin' == $author->display_name )
}}}
to:
{{{
if ( $exclude_admin && 'admin' == $author->user_login )
}}}
Thanks.",raphaabreu
Future Releases,39787,wp_list_authors can be optimize,,Users,4.8,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2017-02-05T01:52:55Z,2024-01-26T07:47:14Z,"May be i don't understand but look at this line
https://core.trac.wordpress.org/browser/tags/4.7/src/wp-includes/author-template.php#L392
{{{#!php
392 $author = get_userdata( $author_id );
}}}
Why we should call `get_userdata()`? At top we call `$authors = get_users( $query_args );` and can return display_name and user_nicename in next foreach section without `get_userdata()`.
And will be nice add filter by role. Because wp_list_authors means authors not subscribers or editors.
",alexufo
Future Releases,24705,wp_link_pages() does not showing active current element,,"Posts, Post Types",2.2,normal,major,Awaiting Review,enhancement,new,dev-feedback,2013-07-07T22:19:44Z,2018-12-09T22:00:39Z,"By full analogy of all wp functions, wp_link_pages must generate active class element too.
{{{
1
2
3
4
}}}
but should be
{{{
1
2
3
4
}}}
",Alexufo
Future Releases,27683,wp_insert_post_empty_content filter issues with auto-drafts and/or fix auto-draft duplicates,,"Posts, Post Types",3.5.1,normal,normal,,defect (bug),new,dev-feedback,2014-04-05T07:15:22Z,2019-06-04T20:46:27Z,"I have explained the issue at http://wordpress.stackexchange.com/a/140326/31794
The 'wp_insert_post_empty_content' filter can have adverse effects on getting the draft for New Posts (new-post.php)
resulting in numerous PHP Noticesand failure to get the auto-draft record properly.
My suggestion for an intermediate fix would be to replace:
{{{
if ( apply_filters( 'wp_insert_post_empty_content', $maybe_empty, $postarr ) ) {
if ( $wp_error )
return new WP_Error( 'empty_content', __( 'Content, title, and excerpt are empty.' ) );
else
return 0;
}
}}}
with:
{{{
if ( $id = apply_filters( 'wp_insert_post_empty_content', $maybe_empty, $postarr ) ) {
if ( $wp_error )
return new WP_Error( 'empty_content', __( 'Content, title, and excerpt are empty.' ) );
else
return $id;
}
}}}
That way we can use the filter to prevent duplicates instead of having to resort to extending the db class.
Though ideally a native method to prevent auto-draft duplicates (along the same lines of my code) in wp_insert_post seems best.
I don't know who came up with the cleanup later idea, but it's far from an ideal practice, and as per previous tickets, doesn't always work.",hexalys
Future Releases,44595,wp_insert_post() inserts wrong GUID (adds http:// prefix),,General,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2018-07-17T14:07:48Z,2018-07-17T19:36:41Z,"I manually set a GUID to e.g. `abc123` before calling `wp_insert_post()` and it was inserted as `http://abc123` to the database.
Expected: `abc123`",Looimaster
Future Releases,23424,WP_Image class for handling images from the media library,,Media,3.5,normal,normal,,enhancement,new,dev-feedback,2013-02-08T15:41:24Z,2019-06-04T20:04:57Z,"Since 3.5 we have the class WP_Image_Editor. This needs a file path to be able to manipulate an image. Currently you would have to use something like wp_get_image_editor( _load_image_to_edit_path( $post_id ) ). What is wrong since you are using a ""private"" function.
Currently I'm working on this idea and you can find the code here https://github.com/markoheijnen/WP_Image/blob/master/wp-image.php. What it does now is getting the filepath, be able to get the image editor, add an image size on the fly and getting/updating the metadata.
We really miss something like a WP_Image class in WordPress. However I'm not sure what kind of functionality is needed for it. I like the current class mainly because it gives you the power to create an image size for a specific media image and stores it in the sizes array. When a user removes the media image then also the custom sizes will be removed.",markoheijnen
Future Releases,38481,wp_handle_upload_prefilter not used before deriving attachment title,,Upload,4.6.1,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2016-10-25T08:30:18Z,2019-03-26T21:28:44Z,"I created a module that modifies upload behavior. I use the wp_handle_upload_prefilter to alter the $_FILES data - specifically the 'name' property of the uploaded file.
This works well for changing the name of the file being stored in the file system, but the title of the attachment post still accesses the $_FILES['async-upload']['name'] on line 281 of media.php.
To be able to override the title, I had to hook into the 'sanitize_title' filter on line 293 of media.php - and doing that is, in my book, a hack.
This sanitize_title filter should specify a context.",frodeborli
Future Releases,39926,wp_get_object_terms should return WP_Error on wrong fields argument or use a sane default,,Taxonomy,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2017-02-21T13:40:52Z,2017-04-14T09:44:53Z,"wp_get_object_terms( $object_ids, $taxonomies, $args ) accepts object_ids, taxonomies and as last option extra arguments as an array. One of the extra arguments in the $args array is the fields option.
I used the field value 'term_id' (erroneously) assuming this would return the term_ids. However this did not work. wp_get_object_terms returned an empty array and in my error log I noticed this SQL error message:
{{{
WordPress database error You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'FROM wp_terms AS t INNER JOIN wp_term_taxonomy AS tt ON t.term_id = tt.term_id ' at line 1 for query SELECT FROM wp_terms AS t INNER JOIN wp_term_taxonomy AS tt ON t.term_id = tt.term_id INNER JOIN wp_term_relationships AS tr ON tr.term_taxonomy_id = tt.term_taxonomy_id WHERE tt.taxonomy IN ('product') AND tr.object_id IN (449, 427) ORDER BY t.name ASC
}}}
After consulting the source of the wp_get_object_terms I noticed that 'term_id' is not a valid fields value. However I would have expected wp_get_object_terms() to return a WP_Error object instead of creating erroneous SQL code.
The following are valid field option values:
* all - Default : all matching term's objects will be returned
* ids : term's ids will be returned
* names : term's names will be returned
* slugs : term's slugs will be returned
* all_with_object_id : all matching term's objects will be returned
* tt_ids : term's taxonomy's ids will be returned
[https://codex.wordpress.org/Function_Reference/wp_get_object_terms See wp_get_object_terms() docs on the Codex]
=== Proposed solution
Due to [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-wp-term-query.php#L581 this switch statement] invalid or an empty fields value will result in an empty SELECT SQL query in this [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-wp-term-query.php#L650 codeblock]
My proposal is to add a default clause to the [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-wp-term-query.php#L581 switch statement] which defaults to using the 'all' case value.
This seems to adhere to the functionality as well as the spirit of the rest of the WP_Term_Query class code. As far as I know it should be backwards compatible as well. ",BjornW
Future Releases,38906,wp_get_attachment_image_src() sometimes gives incorrect width and height values,,Media,,normal,normal,Future Release,defect (bug),reopened,dev-feedback,2016-11-22T18:57:34Z,2022-12-21T20:11:42Z,"The following is an example of a problem that happens to me regularly across multiple sites.
I have an image size registered as follows:
{{{#!php
add_image_size( 'featured-home', 1600, 600, true ); // width, height, crop
}}}
When I run wp_get_attachment_image_src() as follows:
{{{#!php
$image = wp_get_attachment_image_src( $post_id, 'featured-home' );
}}}
...and then print_r() the result, I get this:
{{{#!php
Array
(
[0] => http://localhost:8080/lacoastalservices/wp-content/uploads/2016/09/wetlands-1600x600.jpg
[1] => 1080
[2] => 405
[3] => 1
)
}}}
The image itself is actually 1600 by 600 pixels wide, but for some reason the width and height values given in the array are ""scaled down"" to the width of the next largest image size on the site (1080px), and the corresponding image height if it were actually that wide (405px).
Note that WordPress's ""large"" default image size is still at its default of 1024px, so I don't think that's the problem.
You can hopefully reproduce this by running the ""Display All Image Sizes"" plugin on a few sites and looking for images whose larger image sizes have a mismatch between their identified dimensions and their actual urls. ""Display All Image Sizes"" is using wp_get_attachment_image_src() to generate the text strings that describe image sizes, which is how I became aware of this bug.",pressupinc
Future Releases,54488,wp_filter_nohtml_kses does not remove HTML comments,audrasjb,Formatting,2.1,normal,normal,Future Release,defect (bug),assigned,changes-requested,2021-11-22T09:42:10Z,2023-10-12T06:51:06Z,"The documentation states that `wp_filter_nohtml_kses()`
""Strips all HTML from a text string.""
However, in reality, HTML comments are preserved. This seems to be an explicit choice (wp_kses_split2() - L1083 of wp-includes/kses.php but seems at odds with the documentation, and also with the expectations of a function named ""nohtml"".
Expected behaviour
{{{
wp> wp_filter_nohtml_kses('This is not a comment');
=> string(21) ""This is not a comment""
}}}
Actual behaviour
{{{
wp> wp_filter_nohtml_kses('This is not a comment');
=> string(37) ""This is not a comment""
}}}
",leewillis77
Future Releases,58541,WP_Filesystem_SSH2:put_contents (and others) does not check for $sftp_link to be up,,Filesystem API,,normal,major,Future Release,defect (bug),new,changes-requested,2023-06-15T06:47:39Z,2023-10-27T14:18:47Z,"This is a bit long, as I need to explain the reason why it is a problem not to check for the link '$sftp_link' to be up.
In short: WordPress allows choosing between various FS_METHODS (wp-config.php), e.g. 'direct' or 'ssh2'. While neither choice will affect WordPress updating itself at all, it has implications when some plugins updating files writing content to a file (htaccess, css etc) via
{{{
$wp_filesystem->put_contents($file, $content);
}}}
The function put_contents should check whether the link is up.
There is a big difference how one needs to setup the '$wp_filesystem' instance if you use 'direct' or 'ssh2' - the first one does not need to connect, the second needs to setup a connection before being able to write.
For FS_METHODS 'direct':
{{{
global $wp_filesystem;
if(empty($wp_filesystem))
{
require_once ABSPATH . '/wp-admin/includes/file.php';
WP_Filesystem();
}
$wp_filesystem->put_contents($file, $content);
}}}
For FS_METHODS 'ssh2':
{{{
global $wp_filesystem;
if(empty($wp_filesystem))
{
require_once ABSPATH . '/wp-admin/includes/file.php';
WP_Filesystem();
// this is the ONLY difference to 'direct'
$wp_filesystem->connect();
}
$wp_filesystem->put_contents($file, $content);
}}}
In the file ABSPATH/wp-admin/includes/file.php (around line 2051) the function WP_Filesystem() simply sets up an instance of the class defined by FS_METHOD, but does NOT connect if FS_METHOD is set to 'ssh2'.
Now many plugins that need to write a file (css,htacess,etc) simply assume that FS_METHOD is set to 'direct' or even assume WP_Filesystem() will connect as well.
I have three plugins (there are more, but these are the ones I am 100% sure) that have problems writing
- Ultimate Addons for Elementor
- Astra Addons
- Sensei
Now I could tell those developers to do it properly.
However I think the function $wp_filesystem->put_contents() should CHECK whether the link is up and if NOT, call a function within the class and setup the link to the server, after all I would consider this is proper coding pratice.
{{{
public function put_contents( $file, $contents, $mode = false ) {
// so this is for people who come from the outside
// just setting up the class and dont care whether
// a call to ""connect"" is required.
error_log(""class-wp-filesystem-ssh2.php -> put_contents -> $file "");
if(!$this->sftp_link)
{
error_log(""class-wp-filesystem-ssh2.php link is null, connecting ...."");
// this function is similar to connect
$rc = $this->build_options_connect();
}
// put the contents
$ret = file_put_contents( $this->sftp_path( $file ), $contents );
if ( strlen( $contents ) !== $ret ) {
return false;
}
$this->chmod( $file, $mode );
return true;
}
}}}
The function $this->build_options_connect() sets up the required data structure similar to the function ""request_filesystem_credentials()"" in file ABSPATH/wp-admin/includes/file.php (around line 2250) and then sets up the connection similar to the function $wp_filesystem->connect() in file ABSPATH/wp-admin/includes/class-wp-filesystem-ssh2.php (around line 120).
I have done this on all of my servers for a few weeks now.
Message like this one example (of many) below have completely disappeared.
{{{
[10-Jun-2023 18:25:12 UTC] PHP Warning: file_put_contents(ssh2.sftp:///HIDDEN/htdocs/wp-content/uploads/uael_uploads/.htaccess): failed to open stream: operation failed in /HIDDEN/htdocs/wp-admin/includes/class-wp-filesystem-ssh2.php on line 283
}}}
While I stated 'has patch' (I do), let's first see what people say about this.",jobst
Future Releases,17857,WP_Embed - Split shortcode() function into two for increased flexibility,,Media,2.9,normal,normal,,enhancement,new,dev-feedback,2011-06-21T01:52:41Z,2019-06-04T20:02:44Z,"Currently, the WP_Embed class is restricted to posts; it takes a post ID as a parameter and checks the post meta table.
What I'd like to propose is to apply a filter to the post ID and split WP_Embed::shortcode() into two functions (at http://core.trac.wordpress.org/browser/trunk/wp-includes/media.php#L1177).
In a nutshell, let the link parsing be one function and if the link is oEmbed-worthy send it to the second function for parsing. The second function could then be easily extended for usage in 3rd-party plugins not using WP posts (like BuddyPress).
Also, the patch checks the URL against each registered WP oEmbed provider's URL scheme if oEmbed discovery is false. This is designed to prevent unnecessary external pinging of an oEmbed provider and avertible meta caching for failed attempts. Andy Peatling primarily wrote this part of the code, which he sent to me awhile ago.
Attached patch is against r18324.",r-a-y
Future Releases,38618,wp_description() and description-tag,,General,,normal,normal,Awaiting Review,feature request,new,dev-feedback,2016-11-02T10:00:21Z,2019-04-05T11:03:42Z,"The `wp_title()` function is used by the `title-tag` theme feature to output specific page titles.
Ref https://developer.wordpress.org/reference/functions/wp_title/
What are your thoughts on having something like this for the meta description?",henry.wright
Future Releases,43672,wp_delete_post() function ignores `$force_delete` parameter for custom post types,,"Posts, Post Types",,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2018-04-02T05:23:01Z,2023-07-05T15:55:14Z,"The `wp_delete_post()` function has a second optional parameter called `$force_delete` (default false) that decides whether to send the post to trash or delete it permanently.
But when the function is invoked with a post id that belongs to a custom post type, this parameter is ignored and the post is always deleted permanently and never sent to trash.
Here is the relevant code inside that function that does this.
{{{
if ( ! $force_delete && ( 'post' === $post->post_type || 'page' === $post->post_type ) && 'trash' !== get_post_status( $postid ) && EMPTY_TRASH_DAYS ) {
return wp_trash_post( $postid );
}
}}}
I think the post types check in the above condition should not be made, but I am not sure why it is there and what are the implications of it.
Steps to replicate this issue.
- Create a post in a custom post type and note the post id.
- Make the call to the function. Assuming 42 is the post id, the call will be `wp_delete_post( 42, false)`
- Since the `$force_delete` parameter is set to `false`, the expectation is that the post should be sent to trash
- But the post will be permanently deleted
If it is agreed that it is a bug, then I can submit a patch to remove the post type check.
",sudar
Future Releases,47868,"wp_delete_attachment returning successfully, deleting all DB data, but NOT deleting files, and NOT returning false",,Media,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2019-08-13T12:03:06Z,2019-08-20T04:16:29Z,"from
https://wordpress.stackexchange.com/questions/344976/wp-delete-attachment-returning-successfully-deleting-all-db-data-but-not-delet?noredirect=1#comment505976_344976
I digged into wp_delete_attachment here https://core.trac.wordpress.org/browser/tags/5.2.1/src/wp-includes/post.php#L5450 , it calls wp_delete_attachment_files
wp_delete_attachment_files returns false on failure, but this is ignored! in wp_delete_attachment. Now I'm not gonna go on a rant how bad that 'design' is. My question is, how can I make sure that the files DO get deleted?
I'm calling
{{{
$attachments = get_attached_media('', $post->ID);
foreach ($attachments as $attachment) {
wp_delete_attachment($attachment->ID, true);
wp_delete_attachment never returns falsy.
}}}
How can I figure out and fix wp_delete_attachment ?
in my case it seems that some post_meta might be damaged, as the file location sometimes can be lost for some reason. This should return false or better throw and error",Jossnaz
Future Releases,55635,"wp_convert_hr_to_bytes() report correct byte sizes for php.ini ""shorthand"" values",,Upload,,normal,normal,Awaiting Review,defect (bug),new,changes-requested,2022-04-27T21:43:16Z,2022-09-14T23:16:00Z,"Resolves #17725
When `wp_convert_hr_to_bytes()` was introduced in [4388] it provided a simplified mechanism to parse the values returned by functions like `ini_get()` which represent byte sizes. The over-simplified approach has led to issues in that function reporting the wrong byte sizes for various php.ini directives, leading to confusing problems such as uploading files that are rejected improperly or accepted improperly.
In this patch we're porting the parser from PHP's own source (which has remained stable for decades and probably can't change without major breakage) in order to more accurately reflect the values it uses when it reads those configurations.
Unfortunately PHP doesn't offer a mechanism to read its own internal value for these fields and a 100% port is extremely cumbersome (at best) due to the different ways that PHP and C handle signed integer overflow. These differences should only appear when supplying discouraged/invalid values to the system anyway, and PHP warns that in these situations things are likely to break anyway.
Over the years this function has been modified a couple of times in ways that this patch reverts:
- [38013] introduced a `PHP_INT_MAX` limit in a way that coerces hexadecimal and octal integer representations to decimal.
- [35325] replaced the hard-coded byte size with overwritable constants but if there were any occasion for someone to change those constants in `wp-config.php` then we would actually want to preserve the hard-coded values in `wp_convert_hr_to_bytes()` since that function refers to code inside of PHP, not inside of WordPress.
- The original code from [4388] looks for the presence of the suffixes //anywhere// within the value string and prioritizes `g` over `m` over `k` whereas PHP only looks at the last character in the input string (this is something that [https://core.trac.wordpress.org/attachment/ticket/17725/17725.3.diff 17725.3.diff] got right). This can cause unexpected parses, such as with `14gmk` when WordPress interprets it as 14GiB but PHP interprets it as 14KiB.
Further we do acknowledge the mismatch between PHP's definition of ""gigabyte""/""megabyte""/""kilobyte"" being factors of 1024 apart from each other and the standard of being 1000. WordPress follows PHP's convention so this is simply noted in the function and preserved.
This patch introduces new behaviors which might seem unexpected or wrong. It's important to consider that this function exists because PHP doesn't expose the values it parses from the php.ini directives. Therefore it's job in WordPress can be considered to do as best as it can to represent what's really happening inside of PHP; this may not match our intuition about what PHP should be doing. To that end the over-simplified code for the past 16 years has misreported many plausible-looking values like `100MB` (which PHP interprets as 100 bytes but WordPress thinks is 100 MiB).
**Testing**
In order to fully verify the updated code we have to understand PHP's interpretation of the php.ini directive values. One way to do this is to set a value, `upload_max_size` for instance, in any number of the possible configurable places and then make repeated uploads to see if it's rightfully accepted or rejected. This is cumbersome.
An alternative approach is to compile PHP locally with added instrumentation; this is the approach taken in preparing this PR. The following patch will report three values every time a ""Long"" value is parsed from a php.ini directive: the shorthand value being parsed, the bound `long` value before applying the magnitude suffix, and the possibly-overflowed value derived from applying the possible `g`, `m`, and `k` suffixes.
{{{#!diff
diff --git a/Zend/zend_operators.c b/Zend/zend_operators.c
index 8a0cc813..362cef76 100644
--- a/Zend/zend_operators.c
+++ b/Zend/zend_operators.c
@@ -164,6 +164,9 @@ ZEND_API zend_long ZEND_FASTCALL zend_atol(const char *str, size_t str_len) /* {
break;
}
}
+
+ printf(""zend_atol( \""%s\"" ) = %lld : %lld\n"", str, ZEND_STRTOL(str, NULL, 0), retval);
+
return (zend_long) retval;
}
/* }}} */
}}}
For example, a sampling of values run through PHP produces this output.
{{{#!bash
zend_atol( ""0"" ) = 0 : 0
zend_atol( ""0g"" ) = 0 : 0
zend_atol( ""1g"" ) = 1 : 1073741824
zend_atol( ""3G"" ) = 3 : 3221225472
zend_atol( ""3mg"" ) = 3 : 3221225472
zend_atol( ""3km"" ) = 3 : 3145728
zend_atol( ""boat"" ) = 0 : 0
zend_atol( ""-14k"" ) = -14 : -14336
zend_atol( ""-14chairsg"" ) = -14 : -15032385536
zend_atol( ""9223372036854775807"" ) = 9223372036854775807 : 9223372036854775807
zend_atol( ""9223372036854775807g"" ) = 9223372036854775807 : -1073741824
zend_atol( ""9223372036854775808"" ) = 9223372036854775807 : 9223372036854775807
zend_atol( ""0xt"" ) = 0 : 0
zend_atol( ""0x5teak_and_egg"" ) = 5 : 5368709120
}}}",dmsnell
Future Releases,50538,WP_Comments_List_Table should not show views that have a count of 0,pbiron,Comments,,normal,normal,Awaiting Review,enhancement,assigned,dev-feedback,2020-07-02T17:14:28Z,2021-03-12T11:00:37Z,"Other core list tables that have a get_views() method do not output a view if the count for that view is 0, e.g., `WP_Posts_List_Table` doesn't output ""Pending (0)"" if there are no posts with $post_status === 'pending').
However, `WP_Comments_List_Table` does output ""Pending (0)"" if there are no pending comments.
For consistency's sake, I think `WP_Comments_List_Table` should skip views with count of 0.
Related: #47495",pbiron
Future Releases,29717,"wp_check_invalid_utf8 - pcre tricks and failsafes, +mb_convert_encoding, iconv fix, performance",,Formatting,,normal,normal,Awaiting Review,enhancement,new,needs-unit-tests,2014-09-20T17:18:13Z,2019-05-18T07:49:17Z,"Used in core in these 4 functions.
* esc_attr()
* esc_js()
* esc_html()
* sanitize_text_field()
It's the first function to execute for all 4, and especially for sanitize_text_field it gets called quite a bit and is pretty important.
It's purpose is to check a string for invalid utf. It utilizes preg_match with the '/u' modifier to parse both the pattern and subject for utf. PCRE automatically checks both the pattern and subject for invalid utf, upon which it will exit with an error code/constant.
The changes here: Normally pcre is compiled with utf support. It can also be compiled to disallow utf support, and it can be compiled without utf support. If utf is compiled and enabled the '/u' modifier for preg_match is available which turns on the automatic utf validation.
For older dists or those with utf support turned off at compile, there is a trick to enable the same functionality as the '/u' provides.
http://www.pcre.org/pcre.txt
In order process UTF-8 strings, you must build PCRE to include UTF-8
support in the code, and, in addition, you must call pcre_compile()
with the PCRE_UTF8 option flag, or the pattern must start with the
sequence (*UTF8). When either of these is the case, both the pattern
and any subject strings that are matched against it are treated as
UTF-8 strings instead of strings of 1-byte characters.
So the first change to this function was to allow a fallback to that pattern option trick in case '/u' wasnt supported.
1. `@preg_match( '//u', '' ) !== false`
2. `@preg_match( '/(*UTF8)/', '' ) !== false`
3. Fallback to a regex that doesn't require UTF support, instead of using pcre utf validation it searches for it
I also wanted it to have better performance, especially due to its use in those 4 core functions I use often. I benchmarked it pretty thoroughly to try and gain more speed. This patch is about 10-20% faster.
Many gains were from refactoring the logic and control structures, chaining within if statements using bools, and utilizing the static variables to the fullest. This is especially crucial since this function gets called repeatedly. I also gained some cycles by replacing an in_array() check with a `stripos`.
One of the bigger gains came from replacing the `strlen( $string ) == 0` that ran on every run with. Since the $string variable was already casted to a string, that should always work and keep things a little cheaper.
{{{
$string = (string) $string;
// if string length is 0 (faster than strlen) return empty
if ( ! isset( $string[0] ) )
return '';
}}}
The final change was to the 2nd parameters $strip, which if true is supposed to strip the invalid utf out of the string and return the valid. In core nowhere is that parameter being used (yet), which explains the deprecated looking iconv. Also added a fallback to use mb_convert_encoding in case iconv is missing.
{{{
// try to use iconv if exists
if ( function_exists( 'iconv' ) )
return @iconv( 'utf-8', 'utf-8//ignore', $string );
// otherwise try to use mb_convert_encoding, setting the substitue_character to none to mimic strip
if ( function_exists( 'mb_convert_encoding' ) ) {
@ini_set( 'mbstring.substitute_character', 'none' );
return @mb_convert_encoding( $string, 'utf-8', 'utf-8' );
}
}}}
Here are some of the test strings I used, I also used the utf-8-test file at http://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-test.txt. I did testing on 4.0 using php 5.6, 5.4, 5.3, and 5.4. I verified the output and the strip feature as well. For all tests I had php error_reporting set to the max:
{{{
ini_set( 'error_reporting', 2147483647 );
}}}
{{{
$valid_utf = array(
""\xc3\xb1"", // 'Valid 2 Octet Sequence'
""\xe2\x82\xa1"", // 'Valid 3 Octet Sequence' =>
""\xf0\x90\x8c\xbc"", // 'Valid 4 Octet Sequence' =>
""\xf8\xa1\xa1\xa1\xa1"", //'Valid 5 Octet Sequence (but not Unicode!)' =>
""\xfc\xa1\xa1\xa1\xa1\xa1"", //'Valid 6 Octet Sequence (but not Unicode!)' =>
""Iñtërnâtiônàlizætiøn\xf0\x90\x8c\xbcIñtërnâtiônàlizætiøn"", // valid four octet id
'Iñtërnâtiônàlizætiøn', // valid UTF-8 string
""\xc3\xb1"", // valid two octet id
""Iñtërnâtiônàlizætiøn\xe2\x82\xa1Iñtërnâtiônàlizætiøn"", // valid three octet id
);
$invalid_utf = array(
""\xc3\x28"", //'Invalid 2 Octet Sequence' =>
""\xa0\xa1"", //'Invalid Sequence Identifier' =>
""\xe2\x28\xa1"", //'Invalid 3 Octet Sequence (in 2nd Octet)' =>
""\xe2\x82\x28"", //'Invalid 3 Octet Sequence (in 3rd Octet)' =>
""\xf0\x28\x8c\xbc"", //'Invalid 4 Octet Sequence (in 2nd Octet)' =>
""\xf0\x90\x28\xbc"", // 'Invalid 4 Octet Sequence (in 3rd Octet)' =>
""\xf0\x28\x8c\x28"", //'Invalid 4 Octet Sequence (in 4th Octet)' =>
chr(0xE3) . chr(0x80) . chr(0x22), // Invalid malformed because 0x22 is not a valid second trailing byte following the leading byte 0xE3. http://www.unicode.org/reports/tr36/
chr(0xF8) . chr(0x80) . chr(0x80) . chr(0x80) . chr(0x80), // Invalid UTF-8, overlong 5 byte encoding.
chr(0xD0) . chr(0x01), // High code-point without trailing characters.
chr(0xC0) . chr(0x80), // Overlong encoding of code point 0
chr(0xF8) . chr(0x80) . chr(0x80) . chr(0x80) . chr(0x80), // Overlong encoding of 5 byte encoding
chr(0xFC) . chr(0x80) . chr(0x80) . chr(0x80) . chr(0x80) . chr(0x80), // Overlong encoding of 6 byte encoding
chr(0xD0) . chr(0x01), // High code-point without trailing characters
""Iñtërnâtiôn\xe9àlizætiøn"", // invalid UTF-8 string
""Iñtërnâtiônàlizætiøn\xfc\xa1\xa1\xa1\xa1\xa1Iñtërnâtiônàlizætiøn"", // invalid six octet sequence
""Iñtërnâtiônàlizætiøn\xf0\x28\x8c\xbcIñtërnâtiônàlizætiøn"", // invalid four octet sequence
""Iñtërnâtiônàlizætiøn \xc3\x28 Iñtërnâtiônàlizætiøn"", // invalid two octet sequence
""this is an invalid char '\xe9' here"", // invalid ASCII string
""Iñtërnâtiônàlizætiøn\xa0\xa1Iñtërnâtiônàlizætiøn"", // invalid id between two and three
""Iñtërnâtiônàlizætiøn\xf8\xa1\xa1\xa1\xa1Iñtërnâtiônàlizætiøn"", // invalid five octet sequence
""Iñtërnâtiônàlizætiøn\xe2\x82\x28Iñtërnâtiônàlizætiøn"", // invalid three octet sequence third
""Iñtërnâtiônàlizætiøn\xe2\x28\xa1Iñtërnâtiônàlizætiøn"", // invalid three octet sequence second
);
}}}
----
Notes and more info:
{{{
In order process UTF-8 strings, you must build PCRE to include UTF-8
support in the code, and, in addition, you must call pcre_compile()
with the PCRE_UTF8 option flag, or the pattern must start with the
sequence (*UTF8). When either of these is the case, both the pattern
and any subject strings that are matched against it are treated as
UTF-8 strings instead of strings of 1-byte characters.
UTF-8 was devised in September 1992 by Ken Thompson, guided by design
criteria specified by Rob Pike, with the objective of defining a UCS
transformation format usable in the Plan9 operating system in a non-
disruptive manner.
Char. number range | UTF-8 octet sequence
(hexadecimal) | (binary)
--------------------+---------------------------------------------
0000 0000-0000 007F | 0xxxxxxx
0000 0080-0000 07FF | 110xxxxx 10xxxxxx
0000 0800-0000 FFFF | 1110xxxx 10xxxxxx 10xxxxxx
0001 0000-0010 FFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
A UTF-8 string is a sequence of octets representing a sequence of UCS
characters. An octet sequence is valid UTF-8 only if it matches the
following syntax, which is derived from the rules for encoding UTF-8
and is expressed in the ABNF of [RFC2234].
UTF8-octets = *( UTF8-char )
UTF8-char = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
UTF8-1 = %x00-7F
UTF8-2 = %xC2-DF UTF8-tail
UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2( UTF8-tail ) /
%xED %x80-9F UTF8-tail / %xEE-EF 2( UTF8-tail )
UTF8-4 = %xF0 %x90-BF 2( UTF8-tail ) / %xF1-F3 3( UTF8-tail ) /
%xF4 %x80-8F 2( UTF8-tail )
UTF8-tail = %x80-BF
}}}
* http://www.pcre.org/pcre.txt
* http://us1.php.net/manual/en/pcre.constants.php
* http://www.cl.cam.ac.uk/~mgk25/unicode.html#utf-8
* http://en.wikipedia.org/wiki/Unicode
* http://unicode.org/faq/utf_bom.html
* http://www.unicode.org/versions/Unicode6.1.0/ch03.pdf
* http://www.pcre.org/pcre.txt
* http://tools.ietf.org/rfc/rfc3629.txt
* http://www.unicode.org/faq/utf_bom.html
* http://www.unicode.org/versions/Unicode5.2.0/ch03.pdf
* http://www.unicode.org/reports/tr36/
* http://tools.ietf.org/rfc/rfc3629.txt
Related Tickets:
* https://core.trac.wordpress.org/ticket/11175
* https://core.trac.wordpress.org/ticket/28786
",askapache
Future Releases,50944,wp_calculate_image_srcset can unintentionally include unscaled original image,,Media,4.4,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2020-08-12T14:08:33Z,2020-08-24T21:33:22Z,"In `wp-includes/media.php`, `wp_calculate_image_srcset` seems to add the original image to the srcset string if the width is smaller than `$max_srcset_image_width` and if the image isn't a GIF. This isn't desirable since the original image is uncompressed and I don't even think it's intentional.
This behavior seems to have been introduced in this patch: https://core.trac.wordpress.org/changeset/35561. From what I can tell, the if statement should read like this:
{{{#!php
if ( ! isset( $image_sizes['thumbnail']['mime-type'] ) || 'image/gif' === $image_sizes['thumbnail']['mime-type'] ) {
}}}
The current code will include the original image whenever the thumbnail IS NOT a GIF. This seems to be opposite to the desired behavior?
",fredrikll
Future Releases,44445,wp_cache_init() and WP_Object_Cache constructor has a memory leak,,Cache API,2.2,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2018-06-24T05:00:47Z,2019-05-03T17:45:12Z,"When calling `wp_cache_init()` repeated in unit testing the WP_Object_Cache::__contruct() repeatedly registers '__destruct' as a shutdown function, and each time it does it leaks memory.
There is a @todo comment above the `register_shutdown_hook()` that says the following so I would assume that this is no longer needed and we could just delete the line with the register_shutdown_hook()?
''This should be moved to the PHP4 style constructor, PHP5 already calls __destruct()''
I will upload a patch to delete the list, and a different patch to only call `register_shutdown_hook()` once, depending on what is appropriate.",MikeSchinkel
Future Releases,52582,wp_cache_* duplicate/redundant storage and insufficient clearing of cache,,Comments,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2021-02-21T14:32:09Z,2021-02-21T16:07:12Z,"This is something I'm currently encountering, but have not been able to fully investigate myself (yet).
**Summarized backstory; **
Using Redis, sometimes maxes memory > needs flush. Started investigating whats taking up soo much memory (relatively simple sites).
~42,000/67,000 records stored are for `get_comment_child_ids` and `get_comments`.
(By far not that many comments on my sites)
Looking for a single specific comment ID it is repeated between 30-50 times, while in theory it should be just once (unless using it in different contexts? (->query_vars))
**Possible cause; **
For the methods `get_comments` and `fill_descendants` the `wp_cache_get_last_changed( 'comment' );` is used to create a cache key for the comments / childs.
https://core.trac.wordpress.org/browser/tags/5.6.1/src/wp-includes/class-wp-comment-query.php#L432
https://core.trac.wordpress.org/browser/tags/5.6.1/src/wp-includes/class-wp-comment-query.php#L998
When a new comment is inserted for example, there is a attempt to delete the comment cache by calling `clean_comment_cache()`, but it seems this is based on the comment ID, which is not the same as the key / doesn't target the childs.
The 'last_changed' is however changed at the same time in that function;
https://core.trac.wordpress.org/browser/tags/5.6.1/src/wp-includes/comment.php#L3195
Which I think makes it impossible for the prior cached data to be found because it uses that in the key.
This causes it to store the same data over and over (redundant), even when it hasn't changed for those comments, with new cache keys without clearing the old ones (duplicate).
Could be I'm completely off, but wanted to get another pair of eyes on it. If whats described is actually happening it looks pretty major for caching efficiency. ",sormano
Future Releases,57797,WP_Block_Type_Registry::register issues incorrect error message when block.json folder doesn't exist,,General,6.1.1,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2023-02-23T16:19:42Z,2023-03-07T16:18:54Z,"I called
{{{#!php
register( $block_type, $args );
}
}}}
I see ->register is still called even though the call to file_exists() fails
",Tonygirling
Future Releases,46794,wp_authenticate_email_password fails due to incorrect evaluation of $user object,,Users,5.1,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2019-04-04T11:16:40Z,2019-04-05T14:00:12Z,"While testing an authentication method that uses wp_authenticate where I was passing in a correct email address and password combination that was failing, I traced the code through to the wp_authenticate_email_password method in wp_includes/user.php in wp 5.1.1.
Line 251 executes wp_check_password with $password, $user->user_pass and $user->ID, however $user->user_pass does not exist in $user, rather it exists in $user->data->user_pass.
See attachments for Xdebug code and local variables.
",Csassaf
Future Releases,41990,wp_add_inline_script() does not print if the handler has already processed,,Script Loader,4.5,normal,normal,Future Release,defect (bug),new,dev-feedback,2017-09-26T06:05:37Z,2023-04-12T04:51:08Z,"If the wp_add_inline_script() function (with 'after' position set) is called after the head scripts have already been printed and the handler specified on wp_add_inline_script() is part of the head printed scripts, the code is not added later in the footer.
Probably it should. Example a plugin which implements a shortcode needs to add some jquery inline statement only when the shortcode is executed (to add the js code only on relevant pages). It enqueues jquery to be added in the footer and a piece of inline script.
But another plugin or the theme enqueues jquery in the header (as many do): the above inline code is not printed but it actually does not need to be exactly after the jquery inclusion.
Stefano.",satollo
Future Releases,23020,wp.getPageList should act like wp.getPages,,XML-RPC,2.2,normal,normal,,defect (bug),new,dev-feedback,2012-12-20T13:47:13Z,2019-06-05T06:39:01Z,"I know that wp.getPageList is obsolete, but I think it should act like wp.getPages At the moment wp.getPageList returns even the trashed pages and doesn't return the status of the page.
The weird behavior i've seen with wp.getPageList on a third-party client is shown below:
- Refresh the pages list.
- The Page 'A' is in the list.
- Select the page 'A' and delete it.
- Refresh the pages list and the page is still there. Doh!",daniloercoli
Future Releases,44991,wp-login.php postpass no redirect,,"Posts, Post Types",4.9.8,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2018-09-25T14:52:12Z,2018-09-26T17:47:34Z,"I'm running wordpress 4.9.8 on an Archlinux host. Whenever I try to password protect a post, the redirection after entering the correct password fails. Going back to the post using the browser history works, and the post is unlocked, but only a blank page is visible to the user after entering the password.
I suspect
{{{
wp_get_referer();
}}}
to be the root of the problem. I've added some debug output to the code:
{{{
$referer = wp_get_referer();
if ( $referer ) {
$secure = ( 'https' === parse_url( $referer, PHP_URL_SCHEME ) );
print ""True"";
} else {
$secure = false;
print ""False"";
}
}}}
and it prints ""False"" on that formerly blank white page after entering the password. Also adding
{{{
print $referer;
print $_SERVER['HTTP_REFERER'];
}}}
to the code prints nothing.
I've tested different up-to-date browsers: Firefox, Chromium on Linux, Firefox, Opera on Windows 8.1, Firefox Klar, Safari on iOS, to no avail. Only Internet Explorer on Windows 8.1 works as expected, the redirect occurs immediately.
Any ideas what could cause this problem, or how to further debug this?",lukelr
Future Releases,36239,wp-embed image size is using the smallest image or it sometimes uses the one for featured images,,Embeds,4.4.2,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2016-03-14T19:48:48Z,2020-09-25T19:44:53Z,"When using the wp-embed in my custom post types the image size is correct, a bit big, but it's not blurry. In regular posts, the image size is the thumbnail size created for the media library thumbnail (not the one in the media settings) because that happens to be the smallest one. I noticed that for posts, whatever is the smallest image is being used, whether set in the functions file or by WordPress.",carasmo
Future Releases,55607,wp-config overrides of WP_HOME and WP_SITEURL are forgotten when installing MultiSite.,,Networks and Sites,3.0,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2022-04-22T18:37:42Z,2022-12-03T20:03:10Z,"The chain of events I encountered when playing with WordPress on my home server.
1. Installed WP successfully.
2. I changed the two URL settings to the wrong value by accident.
3. Tried logging back into the admin panel, but I kept being redirected to the wrong place, the one I had mis-typed.
4. Google'd for a fix that would avoid my having to reinstall from scratch and found you can override these two settings in wp-config. I added the correct values for WP_HOME and WP_SITEURL.
5. Finding access to my website restored, I forgot about the two settings editable on the setting panel.
6. I switched on Multi-Site by setting WP_ALLOW_MULTISITE in wp-config.
7. I followed the Network-Setup panel, opting for subfolders. (The sample code to paste into wp-config had the correct name for DOMAIN_CURRENT_SITE.)
8. I followed the instructions to update both wp-config and .htaccess.
9. I went to the login page and saw the page layout was all messed up. Investigating, I found the CSS etc links were all to the mistyped URL I had typed back in step 2.
Note, after restoring the htaccess and wp-config (but keeping my WP_HOME and WP_SITEURL changes) I found I could not update the wrong settings in the DB, as both text boxes were greyed out.
WP multi-site appears to have some reference one of the two URL settings in the database. This should defer to the replacement settings in wp-config.",billpg
Future Releases,44429,WP-CLI incompatibility with wp_redirect( https://... ),,General,,normal,major,Awaiting Review,defect (bug),new,dev-feedback,2018-06-21T20:43:31Z,2018-07-24T12:28:57Z,"Hello,
My wordpress wouldn't update and I see errors below,
I also trying to update my site URL to include www to it but I can't change it due update failure.
{{{
Warning: The system could not load some of this WordPress installation’s data. Certain sections of this interface may not function correctly.
(XID nw85up) The system failed to run the wp-cli batch commands with the following issues: Warning: Some code is trying to do a URL redirect.
Backtrace:
#0 WP_CLI\Utils\wp_redirect_handler(https://)
#1 call_user_func_array(WP_CLI\Utils\wp_redirect_handler, Array ([0] => https://)) called at [/home/rsed43dqsw/public_html/wp-includes/class-wp-hook.php:288]
#2 WP_Hook->apply_filters(https://, Array ([0] => https://,[1] => 301)) called at [/home/rsed43dqsw/public_html/wp-includes/plugin.php:203]
#3 apply_filters(wp_redirect, https://, 301) called at [/home/rsed43dqsw/public_html/wp-includes/pluggable.php:1196]
#4 wp_redirect(https://, 301) called at [/home/rsed43dqsw/public_html/wp-content/plugins/force-https-littlebizzy/core/redirect.php:91]
#5 FHTTPS_Core_Redirect->redirect() called at [/home/rsed43dqsw/public_html/wp-content/plugins/force-https-littlebizzy/core/redirect.php:68]
#6 FHTTPS_Core_Redirect->start()
#7 call_user_func_array(Array ([0] => FHTTPS_Core_Redirect Object (),[1] => start), Array ([0] => )) called at [/home/rsed43dqsw/public_html/wp-includes/class-wp-hook.php:286]
#8 WP_Hook->apply_filters(, Array ([0] => )) called at [/home/rsed43dqsw/public_html/wp-includes/class-wp-hook.php:310]
#9 WP_Hook->do_action(Array ([0] => )) called at [/home/rsed43dqsw/public_html/wp-includes/plugin.php:453]
#10 do_action(plugins_loaded) called at [/home/rsed43dqsw/public_html/wp-settings.php:327]
#11 require(/home/rsed43dqsw/public_html/wp-settings.php) called at [phar:///usr/local/cpanel/3rdparty/share/wp-cli/wp-cli.phar/php/WP_CLI/Runner.php:1174]
#12 WP_CLI\Runner->load_wordpress() called at [phar:///usr/local/cpanel/3rdparty/share/wp-cli/wp-cli.phar/php/WP_CLI/Runner.php:1100]
#13 WP_CLI\Runner->start() called at [phar:///usr/local/cpanel/3rdparty/share/wp-cli/wp-cli.phar/php/WP_CLI/Bootstrap/LaunchRunner.php:23]
#14 WP_CLI\Bootstrap\LaunchRunner->process(WP_CLI\Bootstrap\BootstrapState Object ([] => Array ())) called at [phar:///usr/local/cpanel/3rdparty/share/wp-cli/wp-cli.phar/php/bootstrap.php:75]
#15 WP_CLI\bootstrap() called at [phar:///usr/local/cpanel/3rdparty/share/wp-cli/wp-cli.phar/php/wp-cli.php:23]
#16 include(phar:///usr/local/cpanel/3rdparty/share/wp-cli/wp-cli.phar/php/wp-cli.php) called at [phar:///usr/local/cpanel/3rdparty/share/wp-cli/wp-cli.phar/php/boot-phar.php:8]
#17 include(phar:///usr/local/cpanel/3rdparty/share/wp-cli/wp-cli.phar/php/boot-phar.php) called at [/usr/local/cpanel/3rdparty/share/wp-cli/wp-cli.phar:4]",ecahost7
Future Releases,10631,"wp-admin/users.php does not show pages under ""posts"" column",,Users,2.8.4,normal,normal,Awaiting Review,defect (bug),reopened,dev-feedback,2009-08-16T18:51:20Z,2022-05-13T22:07:25Z,"For some reason, the SQL query in '''wp-includes/user.php''' that gets the count of a user's posts excludes pages, so '''/wp-admin/users.php''' will not show an accurate picture of a user's contributions. This makes no sense at all: 1. posts and pages are first-class content types in WordPress and 2. they are both stored in the same table.
Proposed solution: remove
{{{
AND post_type = 'post'
}}}
from '''function get_usernumposts''' in '''wp-includes/user.php'''.
This defect could result in incorrect interpretation of user activity, so marked as major severity.",novasource
Future Releases,60407,WP Starter Page is a source for HACKERS,,Build/Test Tools,6.4.3,normal,critical,Awaiting Review,feature request,new,dev-feedback,2024-01-31T21:40:44Z,2024-01-31T21:40:44Z,"I am convinced that the WP starter page, with the BOLG option is the source for all and any hacker to hack a site. Prove me wrong: Example, I have had my website online for 20 years, I have used several different website dev. Apps. I have never been hacked.
After setting up WP on my sites; 3 to be exact, I soon started to get spam emails from the comment section of the blog.
I am not a website programmer, btw, I had no idea where these comments. were being submit, I looked at the pages on my dashboard and there was nothing there. I kept looking, granted not a lot because it didn't concern me. But the SPAM was annoying and often inappropriate. Eventually when my site(s) were hacked and shut down, I found the hidden blog page, and deleted it. Because my sites were shut down this was a challenge. I still continued to get SPAM even after shutting down the blog comment page. My other 2 sites were still getting comments. It took a bit of sleuthing to find this hidden blog page on each site, You cant edit it either, WP has embedded the comment section. Eventually I deleted them all, but I still had 3 hacked sites. recently I deleted one of the site and reinstalled WP. And guess what, even though I though I deleted the WP Blog page, I started to immediately get SPAM and the site was hacked. OK point being SHUT DOWN THE AUTOMATICALLY AND HIDDEN BLOG PAGE, SHUT DOWN THE COMMENTS UNLESS YOUR POINT IS FOR US TO GET HACKED!!! I AM CONVINCED THIS IS A SERIOUS PROBLEM THAT YOU HAVE TO FIX. Your welcome to drop me an email, that hopefully isnt spam, to let me know you are fixing this gateway for hackers. Thanks Jimmy",dpmatlosz
Future Releases,40352,"WP REST API, Comments Not Triggering 'comment_post'",,Comments,4.7,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2017-04-04T06:50:37Z,2019-11-26T14:44:32Z,"Hello,
I’ve noticed that when comments are created using the WP API that notification emails are not sent out to the author of the post or moderators. (When testing, If I add the comment via the admin interface, it works as expected).
On debugging, I noticed that the filter ‘comment_post’ is not being called when inserted via the API. For now, I used the following workaround:
{{{#!php
function mytheme_comment_inserted($comment_id, $comment_object) {
wp_notify_postauthor( $comment_id );
}
add_action('wp_insert_comment','mytheme_comment_inserted');
}}}
I already posted on the support forum here: https://wordpress.org/support/topic/wp-api-comments-not-sending-notifications/#post-8987973 and it was suggested this could be intentional behaviour but that this also could, in fact, be reported as a bug?
Thanks!
Chris",stickypixel
Future Releases,45052,WP Oembed in multisite fail when the permalink structure is not default,SergeyBiryukov,Embeds,,normal,normal,Future Release,defect (bug),reviewing,dev-feedback,2018-10-05T05:36:34Z,2019-04-11T17:37:07Z,"This is a follow up of #40673
In case blogs are using pretty urls (which should be the most common case), when you try to embed a post from the main site into a sub site, the embedded URL is not interpreted and we keep that simple URL.
Thats because the main site is using a reserved blog prefix {{{/blog}}} we need to remove before using {{{get_sites()}}}. I've added a unit test to illustrate the bug.",imath
Future Releases,22837,"WP Needs to Set ""Sender"" and ""Reply-To"" or DKIM/DMARC will not work using wp-mail (via PHPMailer)",,Mail,3.4.2,high,major,Awaiting Review,defect (bug),new,close,2012-12-09T17:23:48Z,2023-11-28T19:33:30Z,"I notice that for DKIM to function (while using DMARC) correctly for outgoing mail the PHPMailer object needs to make sure the Sender and Reply-To fields match the ""From"" field otherwise the ""Return-Path"" header uses the server it is sending from causing a mismatch. When this happens DKIM fails authentication on the receiver side because it is not added to outgoing mail.
I tried adding the reply-to and sender header manually to wp_mail() but it did not work. One had to do the following:
Right now i have to manually modify the /wp-includes/pluggable.php file in the wp_mail() function to include:
{{{
if (strlen($phpmailer->Sender)==0)
{
$phpmailer->Sender = $phpmailer->From;
$phpmailer->AddReplyTo($phpmailer->From);
}
}}}
This resolves the problem and DKIM works again.
",kellogg9
Future Releases,54006,"Wp Multisite Get, Add, Update and Delete Site Meta Issue.",,"Options, Meta APIs",5.8,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2021-08-25T16:26:30Z,2021-08-27T14:21:30Z,"Just working on some code to help with WP Multisite integration...
I have noticed that the `add_site_meta` function is currently not working.
I had a look through the functions in wp-includes/ms-site.php and found that the first parameter in the 'add_metadata' function called by add_site_meta (line 1012) is 'blog'.
I figured since you changed the blogmeta table to sitemeta that something might be amiss. If the metadata is added thus:
add_metadata( 'site', 1, 'test_site_feta', 'cheese', false );
All appears to work okay, however this does not;
add_metadata( 'blog', 1, 'test_site_feta', 'cheese', false );
Think its a bug...until I had a closer look I had to use MySQL queries to add the site meta.
",leeml
Future Releases,55206,wp core api memory leaks,,Database,,normal,normal,Awaiting Review,defect (bug),assigned,dev-feedback,2022-02-20T05:37:43Z,2022-04-29T04:44:55Z,"I've experienced the following two memory leaks in WP core. One involves $wpdb when `SAVEQUERIES` is defined truthy, and the other involves `$wp_object_cache` growing as a consequence of calling core api functions that themselves save to the object cache. Both have happened for me in cases where I'm doing large batch processing involving thousands or tens of thousands of posts. I've had memory usage exceed 512MB and cause crashes.
I'm including unit tests here showing each memory leak and also the fix that I've used to prevent the memory leak and keep my batch jobs running.
{{{#!php
queries particularly has a tendency to blow up.
*/
class WP_Memory_Leak_Tests extends WP_UnitTestCase {
/**
* This tests a condition which exposes a memory leak in the WPDB class.
* If 'SAVEQUERIES' is defined as truthy, then the $wpdb->queries property
* can grow indefinitely.
*/
public function test_WPDB_Memory_Leak() {
// Once a constant is defined, it can't be undefined, it's often defined in dev or staging environments.
define( 'SAVEQUERIES', true );
// I'll just start my cron job to read the import file I've got. It's
// got a decent number of records.
$number_of_records = 1000;
global $wpdb;
$memory = memory_get_usage( true );
$peak = memory_get_peak_usage( true );
foreach ( [ 'first', 'second' ] as $pass ) {
// first pass through, we'll apply a fix for this memory leak.
// second pass through, we'll bypass the fix and the tests will fail.
for ( $i = 1; $i <= $number_of_records; $i ++ ) {
if ( 'first' === $pass ) {
$wpdb->queries = [];
}
// for this test, we'll do direct calls to $wpdb
$wpdb->query( $wpdb->prepare( ""SELECT * FROM $wpdb->posts WHERE ID = %d"", $i ) );
}
$this->assertEquals( $memory, memory_get_usage( true ), ""$pass pass"" );
$this->assertEquals( $peak, memory_get_peak_usage( true ), ""$pass pass"" );
}
}
/**
* This tests a condition which exposes a memory leak in wp cache API. If
* a large batch job attempts to do a lot of something that ends up caching
* things ( like, for example, get_post or wp_insert_post ), then unless
* the cache is flushed regularly, the memory usage grows indefinitely.
*/
public function test_WP_Cache_Memory_Leak() {
// I'll just start my cron job to read the import file I've got. It's
// got a decent number of records.
$number_of_records = 1000;
global $wpdb;
$memory = memory_get_usage( true );
$peak = memory_get_peak_usage( true );
foreach ( [ 'first', 'second' ] as $pass ) {
// first pass through, we'll apply a fix for this memory leak.
// second pass through, we'll bypass the fix and the tests will fail.
for ( $i = 1; $i <= $number_of_records; $i ++ ) {
if ( 'first' === $pass ) {
wp_cache_flush();
}
// Because our last test defined 'SAVEQUERIES', we need to
// always apply this fix, otherwise that memory leak manifests.
// With us doing a core API function `wp_insert_post`, the number
// of queries is quite large and memory __really__ grows.
$wpdb->queries = [];
// let's say we're inserting posts, maybe from an excel file.
// this caches some things, so $wp_object_cache grows.
wp_insert_post([
'post_type' => 'post',
'post_title' => ""post $i"",
'post_content' => ""pass $pass""
]);
}
$this->assertEquals( $memory, memory_get_usage( true ), ""$pass pass"" );
$this->assertEquals( $peak, memory_get_peak_usage( true ), ""$pass pass"" );
}
}
}
}}}
",sllimrovert
Future Releases,44347,WP allows creating username that is already used email address,,Users,,normal,normal,Awaiting Review,enhancement,new,needs-unit-tests,2018-06-10T22:43:02Z,2019-03-02T02:03:26Z,"As reported in Support Forum (https://wordpress.org/support/topic/wp-allows-creating-username-that-is-already-used-email-address/) it seems I can create a user with wp_create_user where the user's ""username"" is set as a value that is an existing Email Address for another user in the WordPress system.
(I have not submitted a bug here before, so let me know if more info is needed on this and what to do next).",phillipburger
Future Releases,41288,wp admin bar WordPress about and updates icon can't show in Smartphone.,,Toolbar,4.9,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2017-07-11T09:26:39Z,2024-02-29T20:42:30Z,WordPress admin side WordPress about and Updates can't show in smartphone it should be display none in Very narrow screens.that can be helpfully for smartphone user.,mp518
Future Releases,57366,WP 6.1 - Performance Regression,,Cache API,6.1.1,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2022-12-21T12:45:49Z,2023-04-20T13:25:04Z,"Hi team,
I am experiencing some significant performance regression when I upgrade from 6.0 to 6.1 (and 6.1.1). Page load time roughly triples across the site.
I do not have a profiler running but using Query Monitor I can see a significant increases in object cache hits (14k to 110k). I understand this is partially expected due to the caching improvements.
I am running a fairly large (170k posts) site with Woocommerce and a number of plugins.
I am happy to provide more detailed analysis but not sure what is the best profiling tool or method to understand where the regression is coming from. If you can provide some guidance I will try to collect more data.
Thanks,
Jason",galapogos01
Future Releases,35517,Work around PHP7 php-ssh2 breakage,,Filesystem API,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2016-01-18T20:46:22Z,2023-06-27T06:41:29Z,"There is an updated php-ssh2 package available for PHP7, but it currently breaks the WordPress updater functionality for `class-wp-filesystem-ssh2.php`. The root cause seems to be that it has not correctly implemented the PHP stream wrappers for the `stat()` call, and any dependent functions such as `is_file()`, `is_dir()`, `file_exists()`, etc.
However, the `ssh2_sftp_stat()` function does work, and we can deduce the other information from it.
I've filed a bug against the php-ssh2 extension (https://bugs.php.net/bug.php?id=71376), but I wondered if using `ssh2_sftp_stat()` might be better, in general, than depending on the PHP stream wrapper functionality.
",dougal
Future Releases,23866,WordPress xmlrpc wp_getPosts filter for slug,,XML-RPC,3.4,normal,normal,,enhancement,new,dev-feedback,2013-03-26T20:09:31Z,2019-06-05T06:39:12Z,"When using the Wordpress xmlrpc, it is sometimes very useful to get posts based off of slugs rather than post id.
A use case for this would be synchronizing or migrating two Wordpress sites with the same posts, but with different databases and post ID's.
",SunWaves
Future Releases,42381,Wordpress update does not check if database structure/scheme on existing site is equal to how it would be on a new install,,Database,4.8.2,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2017-10-30T18:19:44Z,2017-11-11T18:19:31Z,"'''Description of bug'''
When trying to add a category I receive the error:
WordPress database error: [Duplicate entry ‘test’ for key ‘slug’] INSERT INTO wp_terms (name, slug, term_group) VALUES (‘Test’, ‘test’, 0)
'''What seems to be the cause of the problem?'''
My install does not allow a category (test) with the same slug as an existing tag (test). WordPress should allow this.
On further investigation: in wp_terms table, the field slug has a UNIQUE constraint. This was changed in WordPress 4.1 [https://core.trac.wordpress.org/ticket/22023/ three years ago].
Duplicates are now prevented in WordPress code instead of in the database, but it seems like my site has skipped one or more database core updates.
'''In short'''
My install is up to date. But my database core structure/scheme is not up to date. wp_repair, wp_optimize etc. do not flag this.
Also setting WP_ALLOW_REPAIR in wp-config.php does not flag this as an issue.
I was able to fix this but potentially my database still has other undetected differences.
Questions
- Should WordPress check on update if a existing database structure/scheme matches how it should be if it were new install?
- Should WordPress offer (after backup disclaimer etc.) offer to repair/update the database structure to the latest version?
I submit this as a bug and not as a feature since I feel WP_ALLOW_REPAIR should detect if a WordPress table is setup correctly.",mike_vl
Future Releases,47452,WordPress taking time to login and throwing time-out error on upgrading,,Upgrade/Install,5.2.1,normal,critical,Awaiting Review,defect (bug),new,dev-feedback,2019-06-01T07:08:56Z,2022-11-15T18:21:31Z,"**Description**: When new updates are available, I upgraded to the new version but after the upgrade successful, I still see the upgrade version and after that WordPress started working very slow. Any operation performed on the platform will take more time to load and sometimes it comes up with ""connection time out"" error too.
**Steps to reproduce**
1. Check for update
2. update your WordPress version from your site to version 5.2.1
3. Route to the dashboard, where you will see update button to version 5.2.1
4. Perform any operation like (user info, plugin page, widget page) it takes time to load and sometimes it throws ""connection time out"".
**System Info:**
System: Windows, Linux
Browser: Chrome 74.0.3729.131 (Official Build) (64-bit)
",kevintran094
Future Releases,16612,WordPress should return nocache headers for requests with comment cookies,,Comments,,normal,normal,,enhancement,new,dev-feedback,2011-02-21T22:45:21Z,2019-06-04T19:22:17Z,"Most themes, when displaying the comment form, change the HTML to pre-fill username, email address, and website when comment cookies are received in the HTTP request. Since the response does not have explicit nocache headers, per RFC2616 (http://www.ietf.org/rfc/rfc2616.txt) intermediate caches can use heuristics to determine the cache TTL for the response. Since there is 0 freshness data in the response, it is not really possible to perform good heuristics, but in practice, caches will assign a default TTL to this type of response. The result is that private information input by user A when submitting a comment can be returned to user B when making a request for the same URL.
To protect ourselves against this, we should call nocache_headers() when comment cookies are sent and the comment form is being displayed. Alternatively, we can send nocache headers for all requests with comment cookies regardless of the comment form being displayed or not (probably easier and maybe safer).
http://humboldtherald.wordpress.com/2011/01/27/gremlins/ is a story likely caused by an aggressive cache and the lack of nocache headers.",barry
Future Releases,15134,WordPress should not try to remove themes or plugins recursively if the directory is a symlink,pbiron*,Upgrade/Install,,normal,normal,Future Release,defect (bug),accepted,dev-feedback,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/ from /home//wp-content/plugins/.
The onwer of the blog (user1) may not know these details and wants to update one of the plugins (plugin1) using automatic update feature. WordPress will then try to remove /home/user1/wp-content/plugins/plugin1/ recursively although /home/user1/wp-content/plugins/plugin1 is a symlink to /var/www/wp-plugins/plugin1.
The obvious solution is to add a check to the filesystem classes that checks if the file is a symlink and if so, remove symlink with unlink() instead of trying to follow it and remove everything it sees.
The advantage of this approach is that if the user symlinks a plugin to other user's data, those data will not be removed by WordPress (this can be very good for those hosts where all users are served by the same Apache user etc).
",vladimir_kolesnikov
Future Releases,56120,"WordPress should add a space character on every possible ""wrap point"" in a post title when building ""html title"", ""og:title"" and so on",,Formatting,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2022-07-01T05:13:27Z,2022-07-05T05:23:50Z,"In WordPress it is possible to use html tags inside posts title. This is very nice: for example, it allows to use italics, and to make posts titles wrap where one wants. When the latter is the case, though, the titles get displayed good in the post, but not in the browser's window title (that usually the browser builds after the `Foobar ` html entity), and not in the link previews that one can get by linking a post into a social network post (that usually have their title based on the ` ` entity).
For example, a post title like `First line second line third line` will result in a `First linesecond linethird line ` entity and in a ` ` entity, that will result in ugly and difficult to read browser window and link previews titles.
This could be avoided by changing WordPress code so that it added a space character on every possible ""wrap point"" (` `, ``, ` ` and so on) in a post title when building ""html titles"", ""og:title""s and the likes.",pezcurrel
Future Releases,43484,WordPress Notification Center proposal,,Users,,normal,normal,Awaiting Review,feature request,assigned,dev-feedback,2018-03-07T11:48:10Z,2024-03-14T13:06:35Z,"For a long time people have been suggesting / daydreaming / [https://twitter.com/Ipstenu/status/966411791134699520 wishing for] a unified notification center in WordPress. People expect it, the notification center has become a staple of almost all apps/sites that have a lot to keep track of - and WordPress definitely fits in that lineup. So there’s no reason not to add one to WordPress core too.
This ticket aims to explore the details of such an implementation. I think clear limitations, a good backwards compatibility strategy and a strong UX are key to make this work for everyone.
Key features:
- One location for all notifications.
- Easy to hook into, should work out of the box.
- Flexible enough to be useful, limited enough to not get a circus.
- Accessible from anywhere.
- Accessible in the a11y sense.
Here’s my first basic idea for notification properties, feel free to chime in:
- A text field, limited to 280 characters, the length of a tweet. Probably wouldn’t want one notification to get so long that it fills up the whole visible sidebar. Links can be added to the text to trigger actions or visit pages, same as now basically.
- A timestamp.
- An icon. Could be the plugin icon, author avatar, or something like a category/message type, like info, warning, question, error, update, stuff like that, to visually distinguish notifications quickly.
- A status, meaning read or unread basically.
- Persist/show as toast. A suggestion by Joen Asmussen. Shows the notification outside the notification center for a set amount of time in a floating div. Similar to what Android/MacOS/Windows does when a notification comes in. Maybe only WordPress itself can throw notices like that. Probably not for MVP anyway.
I created a quick interactive proof-of-concept in Sketch that you can view here.
Desktop: https://sketch.cloud/s/AZz0M/all/notification-center/desktop/play
Mobile: https://sketch.cloud/s/AZz0M/all/notification-center/iphone-8-plus/play
Riad Benguella got excited by this idea and built a basic plugin to test it in your own WordPress install. https://github.com/youknowriad/newtify, and also a previous exploration at https://wordpress.org/plugins/wp-notification-center/. Developing this as a plugin is a great way to explore the best implementation, and any help is more than welcome.
Some discussion points to get this started:
- Can we agree on a set of notification properties that provide a consistent experience and that plugin authors can be happy with?
- Which notification categories can we define, and should it only ever be possible to assign a category, or are plugin authors allowed to supply icons for their own notifications too?
- How best to approach the backwards compatibility so we don’t break (all) existing admin notices? Can some type of conversion be made?
- Is it enough to only show the notifications in the sidebar, or should there be a separate notifications page, maybe with filtering? (Probably not for MVP at least)
- Are there any essential features missing from the list?
",hedgefield
Future Releases,58732,WordPress Gallery Block: Column Count Issue Results in Unbalanced Item Widths,,Editor,5.0,normal,normal,Awaiting Review,enhancement,new,close,2023-07-06T13:13:40Z,2023-07-06T14:12:58Z,"== Enhancement
=== Description
The WordPress gallery block is currently experiencing an issue when users select a specific column count. The problem arises when attempting to achieve a balanced layout, as the items within the gallery block are not receiving a common width. This results in inconsistent and unbalanced item widths. Currently, there is an option to keep all the items in the same width.
=== Environment
- WordPress: 6.3-beta3-56143
- PHP: 7.4.33
- Server: TasteWP-S1 Official/3.0.0
- Database: mysqli (Server: 8.0.32-0ubuntu0.20.04.2 / Client: mysqlnd 7.4.33)
- Browser: Chrome 112.0.0.0 (macOS)
- Theme: Twenty Twenty-Three 1.1
- MU-Plugins: None activated
- Plugins:
* WordPress Beta Tester 3.5.0
=== Steps to Reproduce
1. Add a gallery block
2. Add a few images to the gallery
3. Change the number of columns option
=== Expected Results
1. Same column size for all gallery items
=== Actual Results
1. If there are 6 gallery items and the column count is 4 the last 2 items are showing as 2 columns instead of 4.",sarath.ar
Future Releases,22279,WordPress Export/Import deletes carriage returns,,Export,3.4.2,normal,normal,,defect (bug),new,dev-feedback,2012-10-25T20:02:42Z,2019-06-04T19:44:09Z,"WordPress export does not translate or escape bare CR characters in a CR/LF pair. They show up unfiltered in the WXR export file. I see this both in post_content and in strings that were serialized into a post_meta field. The CR characters are in the WXR file, unfiltered.
Then, WordPress import loses these CR characters. They are simply erased. It may be because SimpleXMLParser can't or won't open the XML file in binary mode, so line ending translation can & does happen. That's just a theory, but if it's true then this behavior might *not* happen on all platforms or with all PHP versions. (I'm seeing this on OS X 10.6.8, PHP 5.4.4.)
In the worse case -- mine -- the munged string is a small component of a complex datastructure that is serialized in a postmeta record. In this case, the entire meta_value field is deleted on import, because the data won't unserialize, because its length has changed.
It seems to me that WP Export should escape any character that might be threatened in transit. I'm no XML lawyer, but some sources claim that unescaped CR characters are invalid XML.
To reproduce:
* store a carriage return in a post.
* export it to a WXR file.
* examine the WXR file for the raw carriage return (`^M`).
* import that file.
* search for the carriage return.",mykle
Future Releases,34657,WordPress doesn't set object terms for menu items so pending items not working,,Menus,4.3.1,normal,normal,,defect (bug),new,dev-feedback,2015-11-11T11:23:11Z,2019-06-04T20:17:50Z,"
When I create menu items and refresh admin page without saving menu, wordpress can not show pending menu items.
At line 1127 of 'wp-admin/includes/ajax-functions.php' file there is wp_save_nav_menu_items function, the first argument for this function '''is always zero''', so At line 441 of 'wp-includes/nav-menu.php' file wp_set_object_terms function doesn't work.
I add my menu id to
{{{
$item_ids = wp_save_nav_menu_items( 97, $menu_items_data );
}}}
function, and it working for me. :)",rss_samuel
Future Releases,46582,WordPress Core Updates: 'Last updated' date not showing correctly,,Upgrade/Install,5.1,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2019-03-21T06:44:12Z,2019-03-21T10:33:52Z,"For the WordPress Core Updates the date for last search is constantly showing January 1st 1970.
My WordPress version is 5.1.1 in Development Mode.",markustippner
Future Releases,44965,WordPress Core strips $_GET['error'] occasionally,SergeyBiryukov*,Query,,normal,normal,Future Release,defect (bug),accepted,dev-feedback,2018-09-19T13:30:20Z,2022-09-21T09:08:29Z,"I have a plugin that is an OAuth2 consumer for integrating with Stripe Connect.
I created a new custom endpoint by adding a query var, and a rewrite rule, so everything that lands on `/stripe_connect` will get dealt with by my plugin's code.
If user denies the connection request at Stripe, they are redirected back to my site with roughly the following URL params in tow:
`/stripe_connect?state=3__5e4e4d4c9df8e6948a33fdfb44f75c0f&error=access_denied&error_description=The+user+denied+your+request`
* `state` is a custom param I set that gets replayed to me
* `error` is `access_denied`, which is the standard that Stripe will do in this case, see https://stripe.com/docs/connect/oauth-reference#get-authorize-errors
* `error_description` is a human readable problem
However in `parse_request`, a variable by the name of `$error` gets set to `404` at the beginning, and as it matches the rules, if it's still 404 (ie no other error popped up, it will then unset `$_GET['error']`.
Link to code: https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-wp.php#L260
Which is something I'd actually need to deal with.
Currently the way to get around it is to use `$_REQUEST` instead of `$_GET`, however `$_REQUEST` also has POST variables in it, so I can't make sure that the `error` I'm getting is actually due to a query param.
I also haven't found a ticket that had this listed as a problem.
What was the reasoning for unsetting that $_GET var?
I see that they were added originally in [1570] (14 years ago), however is that still a valid reason?",javorszky
Future Releases,60558,WordPress Core CSS produces error in NU HTML Checker,,Editor,6.4.3,normal,normal,Awaiting Review,defect (bug),new,close,2024-02-16T08:19:09Z,2024-02-16T10:12:52Z,"The WordPress Default Block Library file Produces these types of errors in NU HTML Checker.
File Path:
/wp-includes/css/dist/block-library/style.min.css
I am attaching the screenshot for you to look over.
Screenshot URL:
https://share.cleanshot.com/XTb38NMBGlQPPwCGTqYS",umang7
Future Releases,46243,WordPress Comments Core Query,,Comments,5.0.3,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2019-02-13T03:48:45Z,2021-03-26T16:16:24Z,"Hello,
**Issue:** We have over 400K+ posts and I saw this slow query on any WordPress area on each page.
We had 2M+ comments.
**Question:** This Query is working on all pages on Dashboard or Settings, Plugin section and any sections why does it? It should works on only all Posts list?
**Solution:** I have noticed that Header Bar has Comments Icon and that has displayed the Pending Comments count. I have tried to disable it via custom Filter for following.
{{{
function admin_bar_remove_comments(){
global $wp_admin_bar;
$wp_admin_bar->remove_menu('comments');
}
add_action( 'wp_before_admin_bar_render', 'admin_bar_remove_comments' );
}}}
**Slow Query:**
{{{
SELECT comment_approved, COUNT( * ) AS total
FROM wp_comments
GROUP BY comment_approved
}}}
**Environment Information:**
WP Version 5.0.3 (also tested 4.9.8)
Theme: Twenty Seventeen (other themes)
Plugins: Query Monitor
Thanks.",Uranbold
Future Releases,42455,WordPress Class methods and Single Responsibility (recent posts widgets),,Widgets,4.9.8,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2017-11-07T13:24:34Z,2022-09-22T09:16:05Z,"WordPress uses PHP Classes a lot and this is great for extending and improving. The problem is, many class methods does a lot of things at once and this doesn't help extending at all.
For instance, I'm trying to extend the Recent Posts Widget (`WP_Widget_Recent_Posts`).
The plugin has it's internal settings and logic, query posts and apply filters.
I want to change it's render method, but just that. Don't want to mess with the plugin logic.
The problem is, the render method (`widget` method) does a lot of things instead of focusing only on rendering. This forces me to copy every logical actions and reproduce them on my extending class.
This could be solved by just splitting the plugin logic and rendering in separated functions (an function to get the posts and filters, separated from the `widget` function).
This would improve a lot the WordPress extending by plugins and themes. If we apply the single responsibility principle on WordPress classes and functions, plugins wouldn't need to have much more code.
Another point: this enhancement wouldn't impact old plugins/themes if the functions signatures keep the same.",viewup
Future Releases,35774,WordPress admin structure,SergeyBiryukov,Administration,,normal,normal,Future Release,enhancement,assigned,dev-feedback,2016-02-08T13:29:06Z,2019-09-23T01:38:27Z,"Currently the admin titles has a wired structure. Few examples:
* **Dashboard ‹ Site Name — WordPress**
* **Posts ‹ Site Name — WordPress**
* **Writing Settings ‹ Site Name — WordPress**
Same structure applies for plugin setting pages.
* `page-title ‹ site-name — WordPress`
The problem with this structure:
* Why are we using `‹` character? why not `›`.
* We should add RTL support for the separator.
* The `Site Name` and the `WordPress`, they look like bad combination.
Few suggestions:
* We need to replace the `‹` character with `›`.
* We can add RTL support. See ticket #35737 and changeset [36487].
* And we need to think about the combination of `WordPress` and `Site Name`.",ramiy
Future Releases,53973,WordPress <= 5.8 - Authenticated Persistent XSS (User role name),,Security,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2021-08-21T01:03:21Z,2022-12-23T12:29:58Z,"Hi there,
First of all, I need to mention this (as requested by @ehtis / H1):
>When creating the ticket, please mention in it that the security team has evaluated this and asked you to open a public ticket for discussion.
\\
== Intro:
In versions of WordPress, including the latest v5.8, it's possible to inject malicious JavaScript code in the name (`$display_name`, `$details['name']`) of any user role.
This vulnerability could be used to infect a website with malicious code or to keep a backdoor for future exploitations. Not all security plugins will detect such injections, cause adding or editing any user role is a legitimate process and all data is stored in the DB.
Important to note that the functionality of adding custom roles is available in many plugins and themes, some of which aren't properly protected from CSRF attacks. Given this vulnerability, such attack vectors can be combined to successfully compromise a website.
\\
== Impact:
Malicious JavaScript code injections, the ability to combine attack vectors against the targeted system, which can lead to a complete compromise of the resource.
\\
== Steps To Reproduce:
1. Use attached PoC plugin (this is the fastest way to reproduce the JS injection) or use this code in any PHP file on your WordPress website:
{{{
#!php
add_role( 'hacker', __( 'Hacker' ), array( 'read' => true, 'edit_posts' => true ) );
}}}
2. Activate the plugin (you can turn it off right away cause we don't need it anymore - our custom user role will be already injected). Our new role will appear in the database like this:
{{{
s:5:""hacker"";a:2:{s:4:""name"";s:37:""Hacker"";s:12:""capabilities"";a:2:{s:4:""read"";b:1;s:10:""edit_posts"";b:1;}}
}}}
3. After that injected payload will be triggered on many pages inside the dashboard, f.e.: /wp-admin/users.php | /wp-admin/profile.php | /wp-admin/options-general.php etc. In my PoC plugin there will be a simple alert window.
\\
== Additional Information:
Another way to add custom user role is by using plugin, f.e. '''uListing''' [https://ru.wordpress.org/plugins/ulisting/ulisting.2.0.4.1.zip v2.0.4.1] (CSRF scenario):
{{{
POST /wp-admin/admin-ajax.php HTTP/2
Host: example.com
Cookie: [admin cookies]
User-Agent: Mozilla/5.0
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 925
action=stm_save_user_roles&roles%5B0%5D%5Bis_delete%5D=0&roles%5B0%5D%5Bname%5D=Visse%3Cscript%3Ealert(%2FVisse%2F)%3B%3C%2Fscript%3E&roles%5B0%5D%5Bslug%5D=visse&roles%5B0%5D%5Bcapabilities%5D%5Bdefault%5D=1&roles%5B0%5D%5Bcapabilities%5D%5Blisting_limit%5D=1553&roles%5B0%5D%5Bcapabilities%5D%5Blisting_moderation%5D=1&roles%5B0%5D%5Bcapabilities%5D%5Bstm_listing_role%5D=1&roles%5B0%5D%5Bcapabilities%5D%5Ballow_delete_listings%5D=0&roles%5B0%5D%5Bcapabilities%5D%5Bcomment%5D=1&roles%5B1%5D%5Bis_delete%5D=0&roles%5B1%5D%5Bname%5D=Hacker%3Cscript%3Ealert(%2FHacker%2F)%3B%3C%2Fscript%3E&roles%5B1%5D%5Bslug%5D=hacker&roles%5B1%5D%5Bcapabilities%5D%5Bdefault%5D=1&roles%5B1%5D%5Bcapabilities%5D%5Blisting_limit%5D=1337&roles%5B1%5D%5Bcapabilities%5D%5Bcomment%5D=1&roles%5B1%5D%5Bcapabilities%5D%5Blisting_moderation%5D=0&roles%5B1%5D%5Bcapabilities%5D%5Bstm_listing_role%5D=1&roles%5B1%5D%5Bcapabilities%5D%5Bis_open%5D=1
}}}
\\
== Possible solution:
File: /wp-includes/class-wp-roles.php, line 162:
`'name' => $display_name,` change to `'name' => strip_tags( $display_name ),`.
\\",visse
Future Releases,50909,WordPress 5.5 update adds height and width attributes to images,,Media,5.5,normal,normal,Awaiting Review,defect (bug),new,close,2020-08-11T22:02:56Z,2020-10-30T14:33:28Z,"It appears that some images added with the gutenberg editor (no updates since June) now have height and width attributes being dynamically added following the new loading attribute.
I updated locally only so far.
This is the previous img element being displayed in the browser:
{{{
}}}
This is it now:
{{{
}}}
These are the new attributes being added:
{{{
loading=""lazy"" width=""1000"" height=""448""
}}}
",jeslen
Future Releases,51158,"With ACF Blocks in 5.5, ""enqueue_assets"" causes fatal error",,Editor,5.5,normal,blocker,Awaiting Review,defect (bug),new,dev-feedback,2020-08-27T15:20:27Z,2020-09-03T00:49:09Z,"This is related to ACF Pro, but didn't happen until the upgrade to WP 5.5. I downgraded to 5.4.2 to make sure and I can verify it's a WordPress issue, likely related to REACT or the Rest API. I don't know enough about the Gutenberg editor to know if it's specific to that, so I'm posting here with ""second-opinion"" Workflow Keyword.
I have several custom blocks created using ACF Pro. One of them requires multiple javascript files and uses the ""enqueue_assets"" attribute to enqueue them.
When I try to edit any post, I get a popup error that covers the entire screen saying ""The editor has encountered an unexpected error."" and has 3 buttons: ""Attempt Recovery"", ""Copy Post Text"", ""Copy Error"". None of the buttons work.
In the console, I get these errors:
{{{
react-dom.min.js?ver=16.9.0:103
TypeError: First argument must be a String, HTMLElement, HTMLCollection, or NodeList
at t.exports (compose.min.js?ver=c4775e2aa9288586791e26a980eff851:9)
at e.value (compose.min.js?ver=c4775e2aa9288586791e26a980eff851:9)
at new e (compose.min.js?ver=c4775e2aa9288586791e26a980eff851:9)
at compose.min.js?ver=c4775e2aa9288586791e26a980eff851:9
at Vb (react-dom.min.js?ver=16.9.0:104)
at Xi (react-dom.min.js?ver=16.9.0:151)
at unstable_runWithPriority (react.min.js?ver=16.9.0:26)
at Ma (react-dom.min.js?ver=16.9.0:52)
at Yb (react-dom.min.js?ver=16.9.0:150)
at O (react-dom.min.js?ver=16.9.0:120)
components-1480.js:24
Uncaught TypeError: Cannot read property 'clientHeight' of null
at G.hasOverflowedContent (components-1480.js:24)
at G.fitTitle (components-1480.js:24)
at components-1480.js:24
}}}
After the second error, the first error repeats and keeps getting hit every few milliseconds, telling me it has thousands of times within a minute.
I'll post this with ACF Pro, too, but wanted to mention here in case it's a WordPress bug. I don't know how many people use ACF blocks in the Block Editor, but it completely prevents people from editing posts if they have some.
Thanks!",bronsonoquinn
Future Releases,33180,Widgets not preserved after switching theme and deactivate plugins,,Widgets,2.8,normal,normal,,defect (bug),new,dev-feedback,2015-07-29T17:59:40Z,2019-06-05T06:41:16Z,"Steps to reproduce:
- Activate any plugin with available widget.
- Use this widget in sidebar of actual theme.
- Deactivate all plugins.
- Switch theme (for example Twenty Fifteen).
Note: These steps are frequently used for debugging problems.
- Switch back to previous theme.
- Activate all plugins.
Expected result: Widget is still active and visible.
Current result: Widget is missing. When used together with any core widget, then this widget is preserved during workflow above.",pavelevap
Future Releases,29790,Widgets don't know the widget area context they're in,,Widgets,,normal,normal,,enhancement,new,dev-feedback,2014-09-29T12:44:45Z,2019-06-05T06:40:16Z,"If you have a widget in a widget area (both on the admin side and front-end side) it does not know in which widget area it is in.
Use cases for this would be:
- custom filtering and/or styling on the front-end of a widget based on its location.
- having some editor options turned on/off based on widget-area.",ruud@…
Future Releases,18446,Widget removes fields w/ default HTML on initial save in IE8 and 9,,Widgets,3.2.1,normal,normal,,defect (bug),new,dev-feedback,2011-08-16T15:51:02Z,2019-06-05T06:38:17Z,"Weird problem, testd in IE8/9, Chrome, and Firefox. If you have a widget, with HTML in the default value, IE8/9 will remove the field entirely. However, if you then paste the HTML back into the field and save, it works fine. This ONLY happens after the initial drag/drop then save of the widget. It even happens if you drag/drop the widget, change the field and click save.
Example Plugin: http://wordpress.org/extend/plugins/ft-calendar/
Widget: Upcoming Events Widget
The Event Template (event_template) is set by default to:
{{{
%TITLE%
}}}
The event_template source for the Available Widget is:
{{{
}}}
The event_template source for the widget after it is dragged to a widget area is:
{{{
}}}
The source for the widget after it is first saved is:
{{{
}}}
I setup a test to output $new_instance and $old_instance during the ""update"" process.
Step 1: Moving widget from Available Widgets to Widget Area (in IE):
{{{
NEW INSTANCE:
Array
(
[title] =>
[date] =>
[number_of] => 1
[date_types] => Month
[limit] => 0
[timeformat] => g:i a
[dateformat] => jS
[date_template] => %DATE%
[monthformat] => F Y
[month_template] => %MONTH%
)
OLD INSTANCE:
Array
(
)
}}}
Step 2: Saving widget in Widget Area:
{{{
NEW INSTANCE:
Array
(
[title] =>
[date] =>
[number_of] => 1
[date_types] => Month
[limit] => 0
[timeformat] => g:i a
[dateformat] => jS
[date_template] => %DATE%
[monthformat] => F Y
[month_template] => %MONTH%
)
OLD INSTANCE:
Array
(
[title] =>
[show_rss_feed] => off
[show_ical_feed] => off
[date] =>
[span] => +1 Month
[number_of] => 1
[date_types] => Month
[calendars] =>
[limit] => 0
[dateformat] => jS
[timeformat] => g:i a
[monthformat] => F Y
[event_template] =>
[date_template] => %DATE%
[month_template] => %MONTH%
[hide_duplicates] =>
)
}}}
Step 3: Pasting HTML code back into Event Template and saving Widget:
{{{
NEW INSTANCE:
Array
(
[title] =>
[date] =>
[number_of] => 1
[date_types] => Month
[limit] => 0
[timeformat] => g:i a
[dateformat] => jS
[date_template] => %DATE%
[monthformat] => F Y
[month_template] => %MONTH%
[event_template] => %TITLE% (%TIME%)
)
OLD INSTANCE:
Array
(
[title] =>
[show_rss_feed] => off
[show_ical_feed] => off
[date] =>
[span] => +1 Month
[number_of] => 1
[date_types] => Month
[calendars] =>
[limit] => 0
[dateformat] => jS
[timeformat] => g:i a
[monthformat] => F Y
[event_template] =>
[date_template] => %DATE%
[month_template] => %MONTH%
[hide_duplicates] =>
)
}}}
Here is a screenr showing the problem not working in IE9 and working in Chrome: http://www.screenr.com/mkhs
",layotte
Future Releases,45054,"Widget deletion: Add an ""Are you sure you want to delete?"" popup before it gets deleted",,Widgets,4.9.8,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2018-10-05T10:24:33Z,2020-05-25T18:16:56Z,"For the widgets the ""Delete"" and ""Done"" buttons are close to each other, and if you accidentally click Delete, there is no obvious option to restore the widget. Not great if you have added lots of html code... I would have liked to see here a ""Are you sure you want to delete this widget?"". ",Vibeque
Future Releases,46082,Why returning $menu_array[x] instead of $title,,Administration,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2019-01-23T16:02:40Z,2021-12-08T12:38:49Z,"
{{{
File: wp-admin/includes/plugin.php
Function: get_admin_page_title()
}}}
In lines `1613, 1616, 1637, 1645 and 1660` the following pattern of assignments and return the value are used:
{{{
$title = $menu_array[x];
return $menu_array[x];
}}}
where `$tile` is `global`.
What is the difference between the following returning patterns
{{{
$title = $menu_array[x];
return $menu_array[x];
}}}
AND
{{{
$title = $menu_array[x];
return $title;
}}}
Since we are already updating the the global variable `$title` with that of `$menu_array[x]`, why can't we just return `$title` instead of `$menu_array[x]`? For every single request `global $title` will receive a new value.
In `line 1620` the return pattern is usual:
{{{
$title = $menu_array[0];
return $title;
}}}
",subrataemfluence
Future Releases,49059,Whitespace inside p element in wp-signup.php should be removed,,Networks and Sites,3.0,normal,normal,Future Release,enhancement,assigned,dev-feedback,2019-12-21T14:49:34Z,2020-02-11T15:32:03Z,"In wp-signup.php there is a paragraph of text with a lot of left and right whitespace.
{{{
Welcome back, Peter. By filling out the form below, you can add another site to your account . There is no limit to the number of sites you can have, so create to your heart's content, but write responsibly!.
}}}
We should remove the whitespace because it isn't necessary.",henry.wright
Future Releases,58497,"when the content of a page is structured into two columns, it causes the menu bar background to change unexpectedly.",,Bundled Theme,6.2.2,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2023-06-08T23:27:10Z,2024-02-01T09:31:25Z,"Not sure how to put this one in to words.
1. I have a nav bar at the top of twenty twenty three. Background color is set works fine.
2. yesterday I tried out adding a two column block in a page content area on edit page. (Still learning the new flow. getting better at it but still a learning curve).
3. about half of the nav bar on these pages with columns in the content area turns white. Not all of the nave bar, but half.
4. Confused me and looked for css solution before realizing it was the same template working fine on other pages and then realized it was the column.
5. Removing the column from the page content area fixes the issue.
",noelhefele
Future Releases,50871,"When exact is true and orderby set to relevance, there is a DB error on search results page",,Query,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2020-08-06T20:21:56Z,2020-08-07T16:18:15Z,"In search query, when `exact` is set to `true` and `orderby` set to `relevance` there is DB error
WordPress database error: [You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near 'DESC, wp_posts.post_date DESC LIMIT 0, 10' at line 1]
`SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND (((wp_posts.post_title LIKE 'hello') OR (wp_posts.post_excerpt LIKE 'hello') OR (wp_posts.post_content LIKE 'hello'))) AND wp_posts.post_type IN ('post', 'page', 'attachment') AND (wp_posts.post_status = 'publish' OR wp_posts.post_author = 1 AND wp_posts.post_status = 'private') ORDER BY DESC, wp_posts.post_date DESC LIMIT 0, 10`
It is clear that both options together has no meaning. But it is compatibility issue between [https://wordpress.org/plugins/wp-extended-search/ WP Extended Search] and [https://wordpress.org/plugins/woocommerce/ WooCommerce]
WP Extended search has a feature to match exact sentence so it sets `exact` to `true` and later WooCommerce adds `orderby => relevance` causing this SQL error.
=== How to reproduce with just WP
* Add this code to theme or plugin
{{{#!php
set( 'exact', true );
$query->set( 'orderby', 'relevance' );
$query->set( 'order', 'DESC' );
});
}}}
* Go to front-end and make a search, you will see the error.
=== Proposed fix
Here https://core.trac.wordpress.org/browser/tags/5.4.2/src/wp-includes/class-wp-query.php#L2357
We checking if `! empty( $q['search_orderby_title'] )` is not empty but we allow to call `parse_search_order()` when `'relevance' === $q['orderby']` causing `ORDER BY DESC` in SQL query without column name.
IMHO, we should not call `parse_search_order()` when `search_orderby_title` is empty regardless of `orderby`.",5um17
Future Releases,15953,"when category slug is changed, old uri also should redirect to new, as post uris do",SergeyBiryukov,Permalinks,,normal,normal,Future Release,feature request,reviewing,dev-feedback,2010-12-22T18:51:10Z,2023-05-25T14:45:21Z,"when category slug is changed, old uri also should redirect to new, as post uris do",qdinar
Future Releases,44596,Welcome page text is repetitive,,Upgrade/Install,,normal,normal,Future Release,defect (bug),new,dev-feedback,2018-07-17T14:15:03Z,2019-02-01T16:29:25Z,"Right now, the WordPress ""Welcome"" page/tab currently repeats nearly the same text 7 times in a row.
The pattern is basically:
`Version %number% addressed %number% bugs. For more information, see %link%.`
The repetition is exacerbated by there being 7 minor releases in the 4.9 major branch, but considering this page is the first thing people see after upgrading, I think this can be communicated better.
Screenshot imminent.",johnjamesjacoby
Future Releases,59027,Weekly wp_get_archives has invalid link (link for month instead of year),,"Posts, Post Types",0.71,normal,normal,6.6,defect (bug),new,needs-unit-tests,2023-08-09T13:43:54Z,2024-02-05T20:34:38Z,"If you call `wp_get_archives` function with `type` set to weekly, the resulted link contains two parameters: m => year, w => week.
This results in unwanted behaviour, as you get a month like `2023` which is invalid.
The link should contain ?y={year}&w={week}.
",filipac
Future Releases,33837,We should avoid Superglobals when possible,wonderboymusic,General,,normal,normal,,enhancement,assigned,dev-feedback,2015-09-11T19:53:44Z,2019-06-04T19:51:22Z,"We can probably add some helper functions that complete common tasks around Superglobal access
Examples of accessing here:
https://codeclimate.com/github/WordPress/WordPress/wp-admin/edit-comments.php
Something like `wp_verify_action( $action )` could replace the many instances of things like:
`isset( $_REQUEST['action'] ) && 'upload-attachment' == $_REQUEST['action']`
Without having to architect something like `Symfony/HttpFoundation`, we can make accessing them more rare.",wonderboymusic
Future Releases,16443,We need a way to programmatically tell if we are in a sidebar,,Widgets,2.2,normal,normal,Awaiting Review,feature request,new,dev-feedback,2011-02-02T20:10:28Z,2022-07-15T16:12:27Z,There is currently no way to tell if you are in_a_sidebar or doing a widget which makes me a sad stallman lookalike.,jorbin
Future Releases,51702,Warn of potentially poor/insecure password generation,,Site Health,,normal,normal,Awaiting Review,feature request,new,dev-feedback,2020-11-03T20:28:34Z,2021-06-01T13:48:56Z,"`wp_generate_password()` is responsible for generating random strings for many things in core. To name a few, [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-wp-application-passwords.php?rev=49490#L49 Application Passwords], [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/setup-config.php?rev=49490#L324 Core salts] (as a fallback), [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/privacy-tools.php?rev=49490#L335 random file names] (Privacy), default user passwords, and more. Each scenario passes the length of the desired generated string, and whether to include 2 different sets of special characters.
In addition to being fully pluggable, there is a `random_password` filter within `wp_generate_password()` that can alter the result of the generated password. The `$length` field should always be respected and `wp_generate_password()` should never return a string shorter than requested. If this does happen, the user should be made aware that potentially insecure strings are being generated so that they can attempt to fix this.",desrosj
Future Releases,28801,Walker::walk makes an incorrect assumption if $top_level_elements is empty.,,General,3.8,normal,normal,,defect (bug),new,needs-unit-tests,2014-07-09T16:02:56Z,2019-06-04T19:46:05Z,"A colleague of mine was generating a sidebar sub-navigation for one of his projects. The subnavigation contained second-level and third-level navigation elements.
The problem my colleague was having was that occasionally third-level elements would not be nested underneath their parent element (also in the list of elements) on some pages.
My colleague was calling wp_list_pages with an array of page IDs that he wanted to render in the sub-navigation, wp_list_pages then turned the list of page IDs into a list of Page objects, and it sorted the page objects by their 'menu_order' attribute; the third-level navigational elements all had their 'menu_order' set to 0, whereas the second-level navigational elements all had 'menu_order' set to something more than 0 - causing the third-level elements to be the first elements in the list.
wp_list_pages later made a call to Walker::walk, passing along that list of pages. Here is a relevant code snippet from Walker::walk:
{{{
/*
* When none of the elements is top level.
* Assume the first one must be root of the sub elements.
*/
if ( empty($top_level_elements) ) {
$first = array_slice( $elements, 0, 1 );
$root = $first[0];
$top_level_elements = array();
$children_elements = array();
foreach ( $elements as $e) {
if ( $root->$parent_field == $e->$parent_field )
$top_level_elements[] = $e;
else
$children_elements[ $e->$parent_field ][] = $e;
}
}
}}}
'''The bug is this code's assumption that the first item in $elements is a suitable root-element for the entire list''' (sentence emboldened for anybody not wanting to read the wall of text). wp_list_pages ordered our list by 'menu_order' which put our 3rd-level elements at the top of the list - causing a 3rd-level element to be treated as the navigation's root.
I wrote up a quick fix for this (I'm not sure if it's the best fix, I'm not overly experienced in Wordpress), and for our project we'll use wp_list_pages with a custom walker class that implements my fix.
Here is the patch of my fix:
{{{
Index: public_html/wp-includes/class-wp-walker.php
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- public_html/wp-includes/class-wp-walker.php (date 1404915904000)
+++ public_html/wp-includes/class-wp-walker.php (revision )
@@ -217,12 +217,34 @@
/*
* When none of the elements is top level.
- * Assume the first one must be root of the sub elements.
+ * ~~Assume the first one must be root of the sub elements.~~ Disregard - RJ CGIT 2014-07-09
+ *
+ * ----------
+ *
+ * Modified by Rob Jackson, Castlegate IT; 2014-07-09:
+ * Do not assume the first element is root, instead loop through the elements
+ * until we find one whose parent is _not_ in the list of elements. If that fails,
+ * just fall back to the default behaviour of using the first element.
*/
if ( empty($top_level_elements) ) {
+ $root = false;
+ $element_ids = array_map(function($element){ return $element->ID; }, $elements);
+ foreach($elements as $element)
+ {
+ if (!in_array($element->post_parent, $element_ids))
+ {
+ $root = $element;
+ break;
+ }
+ }
+ unset($element);
+
+ if ($root === false)
+ {
- $first = array_slice( $elements, 0, 1 );
- $root = $first[0];
+ $first = array_slice( $elements, 0, 1 );
+ $root = $first[0];
+ }
$top_level_elements = array();
$children_elements = array();
}}}
Kind regards,
Rob
",rob-castlegate
Future Releases,58502,Visiting /wp-admin/options-permalink.php causing Fatal Error,,Permalinks,6.2.2,normal,normal,Awaiting Review,defect (bug),new,close,2023-06-09T10:05:47Z,2023-06-28T15:48:07Z,"I'm using WordPress 6.2.2 on PHP 8.1.x
`Fatal error: Uncaught ValueError: Unknown format specifier ""<"" in /wp-admin/options-permalink.php:38 Stack trace: #0 /wp-admin/options-permalink.php(38): sprintf() #1 {main} thrown in /wp-admin/options-permalink.php on line 38`
Here is the WordPress Health Status:
{{{
### wp-core ###
version: 6.2.2
site_language: bn_BD
user_language: bn_BD
timezone: Asia/Dhaka
permalink: /%postname%/
https_status: true
multisite: false
user_registration: 0
blog_public: 1
default_comment_status: open
environment_type: production
user_count: 1
dotorg_communication: true
### wp-paths-sizes ###
wordpress_path: /home/PATHTRUNCATED
wordpress_size: 685.79 MB (719102256 bytes)
uploads_path: /home/PATHTRUNCATED/wp-content/uploads
uploads_size: 584.80 MB (613205338 bytes)
themes_path: /home/PATHTRUNCATED/wp-content/themes
themes_size: 7.46 মেগাবাইট (7824982 bytes)
plugins_path: /home/PATHTRUNCATED/wp-content/plugins
plugins_size: 121.31 MB (127206397 bytes)
database_size: 25.04 MB (26253129 bytes)
total_size: 1.39 GB (1493592102 bytes)
### wp-dropins (1) ###
maintenance.php: true
### wp-active-theme ###
name: Twenty Fifteen (twentyfifteen)
version: 3.4
author: ওয়ার্ডপ্রেস টিম
author_website: https://wordpress.org/%20
parent_theme: none
theme_features: core-block-patterns, widgets-block-editor, automatic-feed-links, title-tag, post-thumbnails, menus, html5, post-formats, custom-logo, custom-background, editor-style, editor-styles, wp-block-styles, responsive-embeds, editor-color-palette, editor-gradient-presets, customize-selective-refresh-widgets, custom-header, widgets
theme_path: /home/PATHTRUNCATED/wp-content/themes/twentyfifteen
auto_update: off
### wp-themes-inactive (1) ###
Twenty Twenty-Three: version: 1.1, author: the WordPress team, automated updates is turned off
### wp-mu-plugins (1) ###
InfiniteWP - Client Loader: version: 1.0.1, author: Revmakx
### wp-plugins-active (1) ###
Maintenano: version: 0.0.1, author: nanodesigns, automated updates is turned off
### wp-media ###
image_editor: WP_Image_Editor_GD
imagick_module_version: not found
imagemagick_version: not found
imagick_version: not found
file_uploads: File uploads is turned off
post_max_size: 8M
upload_max_filesize: 2M
max_effective_size: 2 মেগাবাইট
max_file_uploads: 20
gd_version: 2.3.3
gd_formats: GIF, JPEG, PNG, WebP, BMP, AVIF, XPM
ghostscript_version: 9.25
### wp-server ###
server_architecture: Linux 4.18.0-348.20.1.lve.1.el7h.x86_64 x86_64
httpd_software: LiteSpeed
php_version: 8.1.18 64bit
php_sapi: litespeed
max_input_variables: 1000
time_limit: 180
memory_limit: 128M
admin_memory_limit: 256M
max_input_time: 60
upload_max_filesize: 2M
php_post_max_size: 8M
curl_version: 7.87.0 OpenSSL/1.1.1p
suhosin: false
imagick_availability: false
pretty_permalinks: true
htaccess_extra_rules: true
### wp-database ###
extension: mysqli
server_version: 10.3.39-MariaDB
client_version: mysqlnd 8.1.18
max_allowed_packet: 268435456
max_connections: 151
### wp-constants ###
WP_HOME: undefined
WP_SITEURL: undefined
WP_CONTENT_DIR: /home/PATHTRUNCATED/wp-content
WP_PLUGIN_DIR: /home/PATHTRUNCATED/wp-content/plugins
WP_MEMORY_LIMIT: 40M
WP_MAX_MEMORY_LIMIT: 256M
WP_DEBUG: true
WP_DEBUG_DISPLAY: true
WP_DEBUG_LOG: false
SCRIPT_DEBUG: false
WP_CACHE: false
CONCATENATE_SCRIPTS: undefined
COMPRESS_SCRIPTS: undefined
COMPRESS_CSS: undefined
WP_ENVIRONMENT_TYPE: undefined
DB_CHARSET: utf8mb4
DB_COLLATE: undefined
### wp-filesystem ###
wordpress: writable
wp-content: writable
uploads: writable
plugins: writable
themes: writable
mu-plugins: writable
}}}",wzislam
Future Releases,16483,Visibility: password-protected exposes multiple pages,,Security,3.0.4,normal,normal,Future Release,defect (bug),new,dev-feedback,2011-02-07T19:02:15Z,2022-01-30T16:40:27Z,"1. password protect a page ('protected') with a password
2. password protect another page ('thistoo') with the SAME password
3. visit 'protected' and enter the password. Page is visible
4. visit 'thistoo'; expected: prompt for password. What happens: Page is visible
Regardless of whether someone with a password has the right to try it in as many pages as they want (and would therefore successfully see the page if the passwords were the same), the user should still be prompted on a page-by-page basis. Global authentication to multiple pages is possible with user accounts and roles. It should not be possible with visibility: password-protected pages.",monkeyhouse
Future Releases,16482,Visibility: password-protected breaks with redirected domains,,Login and Registration,3.0.4,normal,normal,,defect (bug),new,dev-feedback,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
Future Releases,31419,Vimeo and YouTube video cannot be inserted into a playlist,,Media,,normal,normal,,enhancement,new,dev-feedback,2015-02-23T09:22:58Z,2019-06-04T20:11:41Z,"Now that the video playlist feature is working well in core, it could be great to think about supporting Vimeo and YouTube videos inside playlist.
For the record, YouTube videos can be played with the MediaElementJS player with this shortcode :
{{{
[video src=""http://youtu.be/_YbVJoMYwJ0""]
}}}
I would like to introduce the possibility to play this video inside a playlist:
{{{
[playlist type=""video"" srcs=""http://youtu.be/_YbVJoMYwJ0,http://youtu.be/Fn1iMmSvvhQ""]
}}}
Now, there are some challenges :
1. Playlist are managed by selecting attachment form the Media library, along with their meta data (title, poster, ...). How to provide meta data for external videos ?
2. MediaElementJS does not build the player in the same way when a YouTube video is embeded, so switching between videos does not rely on the same API, and switching between YouTube and mp4 videos is not possible
The first concern could be addressed by registering an attachment post in the database that links to a YouTube URL instead of a video located in the uploads folder.",Fab1en
Future Releases,58311,Validate Username for not to be a email and strip everything after @,,Login and Registration,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2023-05-14T18:09:52Z,2023-08-15T12:07:25Z,"Right now it is possible to register user and place full email as Username and username is not supposed to be changed after. When site administrator is adding someone manually, it can be done easily as a mistake and reviling author's email for everyone to see and can be picked up from authors archive as well. Display name can be changed after, but it needs to be done manually, by default Username, Nickname and the Display name are equal.
If some people already have @ in their usernames (and I think I've seen that somewhere), the only thing which can be done about this is to filter the Display name before output and strip the @ and everything after.",oglekler
Future Releases,40393,Using remove_action within an action callback skips over execution of other callbacks with lower priority,,Plugins,,normal,major,Awaiting Review,defect (bug),new,dev-feedback,2017-04-07T16:01:05Z,2020-07-07T14:23:02Z,"Description:
When remove_action is used by an action callback to remove itself from the list of callbacks, this results in all callbacks hooked with the immediately lower priority to be skipped by apply_filters.
Here is simple code to demonstrate:
{{{#!php
First Run';
echo '';
do_action('custom_action');
echo ' ';
echo 'Second Run ';
echo '';
do_action('custom_action');
echo ' ';
}
public function callback_1()
{
echo ""Callback 1\n"";
}
public function callback_2()
{
echo ""Callback 2\n"";
remove_action('custom_action', array($this, 'callback_2'));
}
public function callback_3()
{
echo ""Callback 3 - Priority 20\n"";
}
}
$runner = new Sample;
$runner->test();
}}}
The output is:
First Run
Callback 1
Callback 2
Second Run
Callback 1
Callback 3 - Priority 20
The expected output should be:
First Run
Callback 1
Callback 2
Callback 3 - Priority 20
Second Run
Callback 1
Callback 3 - Priority 20
The net effect of this issue is that a plugin using remove_action in that way will break another, totally unrelated plugin, if they both add actions on same tag, with different prorities.
WooCommerce is using this method, it uses remove_action inside a pre_get_posts action callback. This broke our Accelerated Mobile Pages plugin when doing AMP pages for WooCommerce.
This was reported to [https://github.com/woocommerce/woocommerce/issues/14092 WooCommerce here], but it was then suggested it was a core issue.
'''Additional notes''':
- all callbacks must '''object methods'''. The problem does not occur if callbacks are functions.
- the callback using remove_action must be the only registered callback for that priority level
{{{#!php
'name',
'value' => 'Pierre',
]
];
do_action( 'hook_name', $var );
}}}
Any function hooked to `hook_name` receives this first argument:
{{{#!php
stdClass Object
(
[key] => name
[value] => Pierre
)
}}}
…instead of an array containing this object.
I've found that this is because of some **PHP4** backward compatibility in the `do_action()` function:
{{{#!php
} elseif ( is_array( $arg[0] ) && 1 === count( $arg[0] ) && isset( $arg[0][0] ) && is_object( $arg[0][0] ) ) {
// Backward compatibility for PHP4-style passing of `array( &$this )` as action `$arg`.
$arg[0] = $arg[0][0];
}
}}}
This is a weird and unexpected behavior, could we add an additional condition in this `elseif` in order to check for the PHP version to apply this hack?",pskli
Future Releases,37917,Users without the edit_private_posts capability can still create private posts,,"Posts, Post Types",2.1,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2016-09-01T21:32:26Z,2019-04-19T13:20:11Z,"Currently, users without the ""edit_private_posts"" capability, can still view the ""Private"" radio button under ""Visibility"". They can also save / publish the post (depending on their capabilities) with no issue. The same goes for pages as well with the ""edit_private_pages"" capability. I think it's reasonable enough to assume that users that don't have the ""edit_private_{post_type}"" capability, shouldn't be able to create posts with a visibility of private.",ryan.kanner
Future Releases,14757,users with no posts are not exported,,Export,3.1,normal,normal,Future Release,enhancement,reopened,dev-feedback,2010-09-01T18:14:31Z,2020-07-06T14:48:39Z,"I just exported a large standalone site and imported into a multisite setup, and I discovered that a number of users who hadn't yet posted anything didn't get moved to the new site.",sillybean
Future Releases,42957,Usernames ending in a period generate invalid reset password links in certain email clients,hellofromTonya,Users,,normal,normal,Future Release,defect (bug),assigned,dev-feedback,2017-12-21T16:51:13Z,2022-04-29T05:59:01Z,"Password reset links contain the username appended to the end of the URL. If the user name ends in a period the email client has to decide if the period is part of the URL or part of the punctuation of the sentence. For example:
Gmail generates a clickable link that stops short of the final period. Outlook successfully links the entire URL.",paulcline
Future Releases,44690,Username should not accept space,,Users,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2018-08-01T11:19:00Z,2021-02-27T16:17:02Z,"The `username` field accepts `space`, not leading or trailing ones though. Space is usually not in the list of accepted characters.
I am not sure if it is there in purpose. Ideally it should not accept this character.
`Username` also accepts `@`, which is not an issue. But the problem starts when the username looks like an email address! When sending verification requests for Export and Erase private data the issue can be noticed.
However, if `username` has to accept `@`, WordPress should first check whether it is validating email address pattern. If it does, I think that should be reported rather than allowing it to get saved.
I explained the above issue in #44683.",subrataemfluence
Future Releases,34927,user_url and user_email length too short,,Users,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2015-12-09T06:26:38Z,2018-05-14T19:32:04Z,"I have been adding users to my client's site with no issues, until I got to a user with a .edu email address. I add the user details as normal. Click the Add New User button and get the message ""New user created"". No error message at all. But the user has not been created. I tried 3 times, same result. I have turned off all plugins and changed to the wordpress default theme (2015). Same issue.
What I expect to happen: When I add a user I expect them to be added to the Users list.
What happens: when I add a user with a .edu email address, there is no error message, I get message ""New user created"", but the user is not in the user's list. These users should also appear in the Author drop down in posts (because they are added with Author role), but the new user does not appear in the Author dropdown eiither.
Using Firefox 42.0 on Mac OS X Yosemite.
Same issue happens with Safari 9.0.1 on Mac OS X Yosemite. ",DonnaMiller
Future Releases,22895,user_can_admin_menu() is Type-Insensitive for Users who Can't Create Pages,johnbillion*,Role/Capability,3.5,normal,normal,Future Release,defect (bug),accepted,dev-feedback,2012-12-12T18:32:53Z,2023-02-19T01:20:07Z,"Utilization of the new separation edit_posts /create_posts capability separation reveals a flaw in admin menu privilege checking.
The issue occurs when:
1. For any post type other the ""post"", the user has $type->cap->edit_posts but not $type->cap->create_posts
2. User also does not have a manage_terms capability for any associated taxonomies
In that situation, access to ""edit.php?post_type=whatever"" fails unless the user has the ""edit_posts"" cap for the ""post"" type.
This occurs because:
1. '''wp-admin/includes/menu.php''' removes solitary submenus that have the same destination as the parent
2. '''get_admin_page_parent()''' returns nullstring if there is no $submenu item
3. '''user_can_access_admin_page()''' performs a type-sensitive capability check only if get_admin_page_parent() returns an existing $submenu key.
For now, my plugin workaround is to hook into 'admin_menu' and add a dummy submenu with nullstring caption. ",kevinB
Future Releases,44814,"User table same schema, single and multisite",,Networks and Sites,3.3,normal,normal,Future Release,enhancement,new,dev-feedback,2018-08-19T16:16:33Z,2019-01-25T17:28:07Z,"Currently, there is a difference between the users table database schema between single and multisite. I think this is problematic, as it is an unnecessary difference between single and multisite. It means conditional logic that is unnecessary and could make issues for developers querying the users table.",spacedmonkey
Future Releases,34316,User status inconsistent between single-site & multisite,,Users,1.5,normal,normal,Awaiting Review,enhancement,new,needs-unit-tests,2015-10-15T19:00:15Z,2017-09-27T15:30:10Z,"The way a user's status is defined in WordPress differs between single-site and multisite:
* In single-site, the `user_status` column is used
* In multisite, there are two additional columns for `spam` and `deleted`
Not only this, but the `update_user_status()` function is multisite only, and the `user_status` column is an integer without an API to help announce what values equate to what results.
On the plus side, user statuses aren't really ever used in core. Marking users as spammers in multisite installations is the only real benefit of this feature as it exists today. I'd like to propose the following:
* Stop creating the the `spam` and `deleted` columns in `wp_users` on new installations
* ALTER the `user_status` column from `INT(11)` to `VARCHAR(20)` ala `wp_posts`
* A bevy of `wp_register_user_status()` like functions to introduce bonafide support for them
* A database upgrade routine to move user status `0` to `active` and `1` to `spammer`
* A new index on the `wp_users` table for the updated `user_status` column type. We may need a few, based on how users are commonly queried in core, BuddyPress, etc...
* Update the `WP_User` and `WP_User_Query` classes to suss out any `user_status` inconsistencies
A few considerations worth noting:
* Large installations would need to manually perform these DB upgrades. I'm embarrassed to say I've personally frozen WordPress.org for several minutes years ago by missing a `DO_NOT_UPGRADE_GLOBAL_TABLES` check on the `wp_users` table
* Several plugins use their own values in the `users_status` column, assuming their numeric ID is unique and special. The authors of these plugins would need notifying, and their code updating to support the above ideas
* This work *could* parlay into the Post Status API that's on infinite back-burner. There are some really excellent ideas floating around about how `post_status` could work that would translate nicely to users, too",johnjamesjacoby
Future Releases,57398,"User roles are reset to ""All"" tabs when performing bulk actions on certain user roles.",,General,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2022-12-29T14:11:19Z,2023-02-17T08:41:22Z,"Whenever bulk actions are performed on certain roles and applied, the page reloads back to the ""All"" roles. This makes performing Bulk Actions on certain roles tedious if we have to do it multiple times as we need to switch to the role again.
Issue Video Link => [https://share.cleanshot.com/wSHt0nxqtGWkFlPgsq8h]
",aezazshekh
Future Releases,33542,User preferences API idea,,Users,,normal,normal,Future Release,feature request,new,dev-feedback,2015-08-25T15:39:53Z,2017-02-05T22:49:03Z,"When setting up a new site, many site Settings seem at first like user preferences even though they aren't. For sites with 1 user blogging out to the world, this makes sense, but for more robust installations a single set of site settings does not satisfy all users.
I'd like to propose a user preferences API be invented. This API would consist of a series of functions that connect usermeta to site & network options, and when invoked, will traverse the user/site/network hierarchy and use the first available setting. Something like:
{{{
$language = wp_get_user_preference( $user_id, 'WPLANG' );
}}}
Imagine then, that `wp_get_user_preference()` would first look in `wp_usermeta`, then in `wp_options` and then in `wp_sitemeta` if multisite. This is obviously a fuzzy example, and there are less obvious caveats (like what to do when usermeta keys do not match option keys, etc...) which can all be conditionally addressed as we poke holes in the idea.
----
Here are a few settings that could be candidates, taken from their verbiage in various administration screens:
General
* Timezone
* Date format
* Time format
* Start of week
* Language
Writing
* Formatting
* Default Post Category
* Default Post Format
Reading
* Blog pages show at most
* Syndication feeds show the most recent
Discussion
* Default article settings
* Email me whenever
* Avatar Display",johnjamesjacoby
Future Releases,59324,User list,,Users,5.2.2,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2023-09-11T11:22:54Z,2023-09-13T03:40:28Z,"Hello,
I have the site and operates well. But suddenly, the Users menu from dashboard, I can not see the users list even I've loggined as a admin.
[[Image(https://imgur.com/a/NxdJG85)]]
From the back-end, it seems there are the data in there, but seems the front-end is not displaying the list.
Is there any similar case reported?
So far, I deactivated all plug-in, but no sucess. I have checked the wp-admin/users.php file but no problem.
Please let me know where I can look for. Thanks.
",kylechoi
Future Releases,56689,Use WP_Query in get_page_by_path,spacedmonkey,Query,,normal,normal,Future Release,enhancement,reopened,dev-feedback,2022-09-29T10:35:58Z,2023-02-07T04:15:36Z,"Use `WP_Query` in `get_page_by_path`, this this correctly primes caches and is cached itself. ",spacedmonkey
Future Releases,45839,Use site meta for blog details,,Networks and Sites,4.6,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2019-01-05T06:32:13Z,2020-03-29T18:18:06Z,"Currently details about each site is received from each site's options. This means, that every time a WP_Site object is loaded, it may end up calling switch_to_blog. This is expensive and wasteful. This fields should be cached in site meta, which will improve load times and makes it easier to manage.",spacedmonkey
Future Releases,42883,Use sargable queries for date-based lookups for posts,,Query,3.7,normal,normal,Future Release,enhancement,new,dev-feedback,2017-12-12T16:17:14Z,2022-06-14T11:57:10Z,"Related to #41054 but a very specific and actionable, high-impact instance is the fact that the WordPress lookup for permalinks involving dates is not sargable.
For a bog-standard permalink structure %year%/%slug%/, WP generates the following query:
{{{
SELECT wp_posts.*
FROM wp_posts
WHERE 1=1
AND ( YEAR( wp_posts.post_date ) = 2017 )
AND wp_posts.post_name = 'tahoma-vs-verdana'
AND wp_posts.post_type = 'post'
ORDER BY wp_posts.post_date DESC
}}}
This runs (as a cold query) in ~0.075 seconds on a dedicated (and overpowered) MariaDB 10 instance on a pretty small WordPress DB. While indexes exist for all the fields matched against in the query, the use of {{{AND ( YEAR( wp_posts.post_date ) = 2017 )}}} cannot be matched against the database because MySQL/MariaDB is not intelligent enough to optimize that constraint.
The ""same"" query adjusted to make the match against {{{post_date}}} sargable does the same in ~0.034 seconds (half the time):
{{{
SELECT wp_posts.*
FROM wp_posts
WHERE 1=1
AND wp_posts.post_date >= DATE(""2017-01-01"")
AND wp_posts.post_date < DATE(""2018-01-01"")
AND wp_posts.post_name = 'tahoma-vs-verdana'
AND wp_posts.post_type = 'post'
ORDER BY wp_posts.post_date DESC
}}}
The same would apply for permalinks that reference the month and day, of course.",ComputerGuru
Future Releases,40748,Use REST API for Community Events,,REST API,4.8,normal,normal,Future Release,enhancement,new,needs-unit-tests,2017-05-12T17:39:23Z,2020-10-25T03:56:50Z,"#40702 introduced new Community Events to the News widget on the Dashboard screen, but it uses admin-AJAX.
Converting to the REST API is a good opportunity to lay some groundwork for migration the rest of wp-admin in the future.
The work for this was started in #40702, but it'll be easier to keep track of with a new ticket.
I'm working on an updated version of `40702.11.diff` and will upload it soon.",iandunn
Future Releases,57725,Use of rand() function instead of wp_rand(),,Filesystem API,,normal,normal,Awaiting Review,enhancement,new,changes-requested,2023-02-15T11:14:13Z,2023-06-21T11:00:43Z,"Filesystem API function {{{wp_edit_theme_plugin_file}}} using PHP {{{rand()}}} function rather than WP's {{{wp_rand()}}}. Can we enhance this as {{{rand()}}} is discouraged?
File path: wp-admin/includes/file.php
Line: 524 and 526
",haritpanchal
Future Releases,53998,Use network_home_url() instead of $_SERVER['HTTP_HOST'] for added safety.,,General,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2021-08-24T23:29:09Z,2022-08-07T18:04:12Z,"Would it not be safer from XSS if uses of **$_SERVER[''HTTP_HOST'']** were replaced with **network_home_url()**? It looks to me like **network_home_url()** reads the server host name from the site settings instead of relying on a possibly manipulated **$_SERVER[''HTTP_HOST'']** value.
For example, I came across this code in /wp-admin/includes/class-wp-list-table.php...
{{{#!php
array(
array(
'key' => 'likes',
'value' => 10,
'compare' => '>='
)
)
) );
}}}
the query will return the post with 2 likes. This is because the SQL is doing a string comparison, as both the column value and the compared-to value are strings.
The fix for the developer is to supply a `type` parameter like `NUMERIC` in the meta query clause which coerces a numeric MySQL comparison.
We could use the meta_value's type to decide the type format the value takes in the SQL clause, so that a query like this works as expected without the `type` parameter.
This was [https://core.trac.wordpress.org/ticket/27272#comment:13 suggested] by @boone in #27272.",ericlewis
Future Releases,48816,Use get_bloginfo in the REST API index,,REST API,4.4,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2019-11-27T19:35:39Z,2019-11-29T18:39:35Z,"The REST API provides data in the site ""index"" when making a request to `https://example.org/wp-json`. This describes the site and the APIs available. In particular it returns the name of the website, and the tagline. These values are retrieved using `get_option` directly instead of `get_bloginfo`.
Because this data would be used presentationally, it seems like it'd be more useful if it returned the ""presentation"" version of these strings.
As far as I could tell, the index has more or less worked the same since the GSOC version of the REST API, so I wasn't able to find any description of why it was built that way.
I opened this because of [https://github.com/WordPress/gutenberg/pull/18760 a Gutenberg PR] which would display the site title.",TimothyBlynJacobs
Future Releases,21022,Use bcrypt for password hashing; updating old hashes,,Security,3.4,normal,major,Future Release,enhancement,new,dev-feedback,2012-06-20T01:34:26Z,2023-05-08T14:34:44Z,"Hi,
following recent discussions on password security and how to best prevent any hackers can leverage password table they might have got I looked into the phpass used for WordPress.
While I in principle understand why WordPress uses the compatibility mode of it, I would like to see some flexibility for those who don't need the compatibility.
Thus I would propose to change in wp-includes/pluggable.php all occurances of
{{{
$wp_hasher = new PasswordHash(8, true);
}}}
to
{{{
$wp_hasher = new PasswordHash(8, apply_filters('phpass_compatibility_mode', true));
}}}
This would allow users to easily change via plugin from the ""not so secure"" compatibility mode (only salted MD5) of phpass to a more secure setting (bcrypt) in case no compatibility with other applications is required.
The plugin changing the encryption methog could then as easy as
{{{
function phpass_bcrypt() {
return false;
}
add_filter('phpass_compatibility_mode', 'phpass_bcrypt');
}}}",th23
Future Releases,56070,Use a consistent order of annotations in the test suite,,Build/Test Tools,,normal,normal,Future Release,task (blessed),new,dev-feedback,2022-06-24T22:18:01Z,2023-10-17T00:41:32Z,"WordPress core has an [https://developer.wordpress.org/coding-standards/inline-documentation-standards/php/#docblock-formatting established DocBlock format] for inline documentation:
{{{
/**
* Summary.
*
* Description.
*
* @since x.x.x
*
* @see Function/method/class relied on
* @link URL
*
* @global type $varname Description.
* @global type $varname Description.
*
* @param type $var Description.
* @param type $var Optional. Description. Default.
* @return type Description.
*/
}}}
This is more or less consistently applied in core, which is helpful for reusing this template for newly added functions without the guesswork of where to put each particular tag.
Unit tests also use some of these tags:
* `@since`
* `@see`
* `@global`
* `@param`
* `@return` (for tests with dependencies)
as well as some [https://make.wordpress.org/core/handbook/testing/automated-testing/writing-phpunit-tests/#annotations test-specific annotations]:
* [https://phpunit.readthedocs.io/en/9.5/annotations.html#ticket `@ticket`]
* [https://phpunit.readthedocs.io/en/9.5/annotations.html#group `@group`]
* [https://phpunit.readthedocs.io/en/9.5/annotations.html#covers `@covers`]
* [https://phpunit.readthedocs.io/en/9.5/annotations.html#depends `@depends`]
* [https://phpunit.readthedocs.io/en/9.5/annotations.html#requires `@requires`]
* [https://phpunit.readthedocs.io/en/9.5/annotations.html#dataprovider `@dataProvider`]
* `@expectedDeprecated`
* `@expectedIncorrectUsage`
However, the order of these annotations differs in various test classes and can be almost random even in test methods of the same class. These inconsistencies increase cognitive load when writing new tests or reviewing test PRs to bring them in line with existing tests.
I would like to propose a DocBlock template that can be consistently applied across the test suite. Something like:
{{{
/**
* Summary.
*
* Description.
*
* @since x.x.x
* @ticket 12345
*
* @group group_name_1
* @group group_name_2
*
* @covers function_name_1
* @covers function_name_2
*
* @requires function function_name
*
* @expectedDeprecated
* @expectedIncorrectUsage
*
* @see Function/method/class relied on
* @link URL
*
* @depends test_name
* @dataProvider data_provider_name
*
* @global type $varname Description.
* @global type $varname Description.
*
* @param type $var Description.
* @param type $var Optional. Description. Default.
* @return type Description.
*/
}}}
Notes:
* All of these annotations are optional and may not be present on a particular test, so most of the time the DocBlock would be much shorter. But if they are present, the order should be consistent across the test suite.
* `@since` and `@ticket` are grouped together because they are both related to when a test was introduced.
* `@group` and `@covers` are separated into their own sections for better readability when a test belongs to multiple groups and/or covers multiple functions.
* `@depends` and `@dataProvider` are grouped together and moved closer to globals and parameters, because they are both related to passing data to the test. When reviewing the current usage of `@depends` in the test suite, I found some instances that don't pass any data but seem to (incorrectly) assume that this annotation defines the order in which the tests are executed. That can be addressed separately.
Any thoughts on using this DocBlock format or any suggestions for improving it are welcome.",SergeyBiryukov
Future Releases,16830,url_to_postid() doesn't resolve attachments when rewrite rules are disabled,,Rewrite Rules,1.2,normal,normal,,enhancement,reopened,needs-unit-tests,2011-03-11T01:09:14Z,2019-06-04T21:06:33Z,"The code of {{{url_to_postid()}}} is pretty clear in the case of disabled rewrite rules: all URLs not using the {{{p=N}}}, {{{page_id=N}}} or {{{attachment_id=N}}} forms are not parsed and the function return 0. That make sense.
Now there is a special case for attachments. Attachments can be saved under a the {{{/wp-content/uploads/year/month/}}} folder structure while rewrite rules are disabled at the same time.
This means there is a missed opportunity for {{{url_to_postid()}}} to resolve attachment's URLs of the long-form when rewrite rules are disabled.
This was tested and reproduced on WordPress 3.1.",anonymized_154007
Future Releases,17771,URL-encoded comment_author_url gets broken by MySQL varchar 200 length limit,SergeyBiryukov,Comments,3.2,normal,normal,Future Release,defect (bug),reviewing,dev-feedback,2011-06-12T03:46:44Z,2017-03-18T17:38:56Z,"!WordPress sometimes pings back with long permalinks that exceed comment_author_url column length limit of 200, which results in generating unusable broken links to the post.
It easily reaches to the limit, especially if the permalink contains url-encoded multibyte title as postname. (e.g. 23 characters of UTF-8 Japanese become a 207 characters long url-encoded string. Incomplete url-encoded string may trigger 400 Bad Request too.)
'''Solution:'''
In pingback(), use shortlink instead of regular permalink if the URL is longer than 200 characters.
It seems to work ok with wp.me shortlinks.",tenpura
Future Releases,11856,URL for 1st comments page is not canonical,markjaquith,Canonical,3.0,normal,normal,Future Release,defect (bug),new,dev-feedback,2010-01-10T19:17:42Z,2023-10-19T20:04:59Z,"When WP generates URL for comments, it always includes comments page number. It should not do this when URL is for 1st comments page - in this case post URL is sufficient.
WP should also redirect to canonical URL version when someone will try to load URL like site.com/some-post/comment-page-1.",sirzooro
Future Releases,49664,Uppercase Greek letters are getting accents on iPhone mobile devices,,General,,normal,normal,Awaiting Review,defect (bug),reopened,dev-feedback,2020-03-18T09:41:28Z,2020-03-18T11:01:33Z,"Hi,
On my client's under development e-shop made with WP & WooCommerce, all of the uppercase letters appeared at various purchase steps via ""text-transform: uppercase;"" are getting accents. The shop is in Greek language and uppercase letters shouldn't have accents because this is wrong in Greek grammar.
Is there maybe a way to fix this?
The issue appears only at iPhone mobile devices and not at the rest.
Please check my screenshots below to better understand the issue:
[https://imgur.com/JxwrGaF]
[https://imgur.com/4FmMiur]
[https://imgur.com/rTiyiz4]
[https://imgur.com/T5KVrSb]
[https://imgur.com/XLisjrg]
I would like to inform you that I have found a relevant plugin on wordpress.org which seems to fix the issue with the uppercase accents on Greek letters:
[https://wordpress.org/plugins/remove-uppercase-accents/#description]
In addition, I have found a conversation on [https://stackoverflow.com/] regarding the issue:
[https://stackoverflow.com/questions/28783259/how-do-i-make-text-transformuppercase-work-properly-with-greek]
I would prefer to avoid adding an extra plugin for fixing the issue. WooCommerce official support also recommended me to report the issue here as the fix should be implemented in WordPress core itself (as it affects WordPress users as well).
The problem here seems to be related with the text-transform: uppercase; CSS code. As you may read above, this is a limitation with CSS code that does not remove the accents when switched to uppercase on Greek Language (I am not sure if it happens to other languages as well).
Waiting for your further advice on this.
Kind Regards,
Dimitris",d.chatzimanolis
Future Releases,47726,Uploading new media to existing posts/pages backdates file location,,Media,2.7,normal,normal,Future Release,enhancement,reopened,dev-feedback,2019-07-17T18:13:57Z,2022-05-23T18:29:08Z,"This is a follow-up to #10752.
Hello,
I just want to know, who thought this was a great idea? This causes so many media managing problems.. Why can't we just simply get to the July folder to get our images uploaded in July?
And about the [41964] : Good fix and at the same time it's bad, it only fixes it for pages! And it's not like pages are that different from posts or custom posts, they can serve the same purpose, so why would it be different?
Hoping to get a fix soon!",gaelgwp
Future Releases,18043,Uploaded images disappear after loading if using compression w/Apache,,Upload,3.2.1,normal,major,Future Release,defect (bug),new,dev-feedback,2011-07-08T22:49:15Z,2019-05-15T21:02:03Z,"I have found an issue between WordPress (Multisite) + Google Chrome (Mac) which I think appeared on my sever when I enabled compression a few months ago, but could never reproduce because it only happens with images managed by a Multisite WordPress install, not static images.
With images that are static Apache sends the file and calculates the Content-Length its self so these images work fine but if you access a file uploaded to WordPress it uses the .htaccess redirect so the image requests are sent via ms-files.php for what ever reason.
The problem is that WordPress decides to calculate its own Content-Length header in the HTTP Response which means that security conscious browsers like Google Chrome freak out when the data they receive is less than they we're told by Apache and they resultantly disable the image.
The Content-Length calculation comes on line 43 of ms-files.php I don't know why its needed because Apache seems to sort it out automatically if you don't send your own header, in fact most of the file seems like an unnessisary load of processing, perhaps it needs reviewing but this is a major issue as it is a growing browser, on a growing platform.
Here is a great video of it in action: http://www.screencast.com/t/cUYKSegW0N
This issue has been repeatedly reported on the forum:
http://wordpress.org/support/topic/disappearing-images
http://wordpress.org/support/topic/multisite-images-broken
http://wordpress.org/support/topic/image-not-show-in-google-chrome-timthumbphp
Please fix this asap!",ctsttom
Future Releases,16191,Uploaded files with quote marks in the filename are undisplayable in MS,,Upload,,normal,normal,Future Release,defect (bug),reopened,dev-feedback,2011-01-11T19:28:49Z,2019-11-03T18:40:43Z,"If you upload a file with quote marks in the filename, e.g. `""Test"".jpg`, WordPress records the filename as `%22test%22.jpg` but the file is called `""Test"".jpg` (on 'nix-like systems anyway) so is undisplayable.
I'm unsure about the implications (security and otherwise) of my suggested patch (attached), so please give feedback. (I guess the other approach would be to retain the url-encoded characters and ensure that the file is named with the URL encoded version of the filename.)",simonwheatley
Future Releases,32318,"Upload fails, wp_insert_attachment returned 0",,Upload,4.1.5,normal,normal,Awaiting Review,defect (bug),new,close,2015-05-08T22:34:11Z,2022-10-19T15:47:53Z,"One specific mp3 file was failing to attach, and it seems wp_insert_attachment is breaking with 0 returned, breaking update-attachment-metadata:
wp-admin/includes/media.php, line 360:
{{{
// Save the data
$id = wp_insert_attachment($attachment, $file, $post_id);
if ( !is_wp_error($id) ) {
wp_update_attachment_metadata( $id, wp_generate_attachment_metadata( $id, $file ) );
}
}}}
id = 0, caused by these lines in wp-includes/post.php, around line 3351:
{{{
if ( false === $wpdb->insert( $wpdb->posts, $data ) ) {
if ( $wp_error ) {
return new WP_Error('db_insert_error', __('Could not insert post into the database'), $wpdb->last_error);
} else {
return 0;
}
}
}}}
In this case the documentation is wrong, it didn't return the post id.",programmin
Future Releases,54739,Upgrade PHPMailer to 5.2.27 for WordPress < 5.3 (and to 6.5.3 for above 5.4),,External Libraries,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2022-01-04T16:59:56Z,2022-01-19T13:18:43Z,"In WordPress 5.3 the PHP Mailer library was updated to the latest version from the 5.2-branch. See #40472
In WordPress 5.5 the PHP Mailer library was updated to the new version 6. See #41750
As background updates are available from 3.7 on we could update the PHP mailer library down to version 3.7 to protect those installations from being abused for spamming.
I checked https://wordpress.org/about/stats/ and WordPress installations with version smaller than 5.3. These sum up to 24.15 %.
We only can background update from 3.7, so we need to look at WordPress 3.7 to 5.2 which shows us 18,52 % of all installation which are unprotected.
This would at least close two from those three known security problems with this version:
https://www.cybersecurity-help.cz/vdb/phpmailer_sourceforge_net/phpmailer/5.2.22/
Quoted from https://github.com/PHPMailer/PHPMailer/releases/tag/v5.2.27:
> Note that the 5.2 branch is deprecated and will not receive security updates after 31st December 2018.
The same goes for WP 5.5 to 5.8
-> WordPress 5.5 (PHP Mailer 6.1.6)
-> WordPress 5.6 (PHP Mailer 6.2)
-> WordPress 5.7 (PHP Mailer 6.3)
-> WordPress 5.7.2 (PHP Mailer 6.4)
-> WordPress 5.7.3 (PHP Mailer 6.5.0)
WordPress 5.9 will contain PHP Mailer 6.5.3 as the latest version.
As version 6.4.1 and 6.5 are security releases this could be relevant too:
https://github.com/PHPMailer/PHPMailer/releases?q=security&expanded=true
Although this is related to security it seems that the other tickets about updating this library are handled in public so I created this one here too.",zodiac1978
Future Releases,55962,Upgrade `sanitize_hex_color()` to CSS Color Level 4,pbearne,Formatting,,normal,normal,Future Release,enhancement,assigned,dev-feedback,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
Future Releases,39273,Updating to 4.7 can break serialized data because $wpdb->determine_charset now forces utf8 when DB_CHARSET is set to utf8mb4,,Database,4.7,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2016-12-14T05:05:58Z,2019-03-15T02:23:09Z,"I've seen this happen several times now. `DB_CHARSET` is defined as `utf8mb4` and the columns in the database are set to `utf8mb4_unicode_ci`. However, the changes in 38581 are now forcing `utf8` causing the serialized array lengths to change when the data is queried and breaking them because the charsets don't match.
I can't say for certain because I'm debugging this issue on a site that isn't mine, but I don't think anyone explicitly set `DB_CHARSET` to `utf8mb4` in `wp-config.php`. It appears that at one point, WordPress set that define and created (or updated) those tables to `utf8mb4_unicode_ci`.
Deleting the `DB_CHARSET` define fixes the issue but that doesn't seem like an ideal solution for users who update and end up with a broken site.
I'll admit this is a bit over my head, so I'm hoping someone smarter than me might be able to chime in with some more info :) I'm definitely available to keep the conversation going. Thanks! ",justinbusa
Future Releases,36462,Updating or publishing a (custom) post that hasn't loaded completely closes comments,,"Posts, Post Types",4.4.2,normal,normal,Future Release,defect (bug),new,dev-feedback,2016-04-10T14:44:28Z,2017-02-20T22:19:57Z,"I am using a custom post type, but I assume this happens to the default post type as well. On the edit post screen (post.php?post=1&action=edit) I have several custom meta boxes. Some of these have content that is quite slow to load. You can reproduce this behavior by adding a sleep(5) statement somewhere in the code that loads the content for a custom meta box. Now in the document's DOM, the sidebar is loaded before the custom meta boxes. This introduces a situation where it is possible to update or publish a post before all the meta boxes have completely loaded. In most cases this isn't a huge problem - I myself check to see if the $_POST fields are there and if they are not then I don't act upon them.
Unfortunately this does not happen for the included ""Discussion"" meta box. This box has a checkbox named ""Allow Comments"" which gets switched off when you update the post before this meta box has loaded into the DOM.
The culprit is the code in wp-admin/includes/post.php on line 133 in the _wp_translate_postdata() function:
{{{#!php
if (!isset( $post_data['comment_status'] ))
$post_data['comment_status'] = 'closed';
}}}
Since the comment_status field is not in the post data, it is automatically assumed it needs to be closed.
Of course there are two ""workarounds"" I can think of that would improve my current situation. One is for me to optimize the meta boxes so the page loads quicker, the other is to move the Discussion metabox to the top of the page, so it loads first.
Is this expected behavior? I would much rather see the current comment_status be preserved - don't touch it if I didn't intend to modify it. Of course there might be a reason for this implementation that I don't know about.
This post data is then finally presented to wp_insert_post in wp-includes/post.php which actually updates the post's comment_status to become closed, which finally answers my boss' question why comments kept getting disabled automatically.",SeBsZ
Future Releases,13429,Updating Link URL on image within Admin with Gallery,,Gallery,2.9.2,normal,normal,Future Release,defect (bug),new,dev-feedback,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
Future Releases,41901,Updating fails for themes with style.css in sub directory.,williampatton,Themes,,normal,normal,Awaiting Review,defect (bug),assigned,dev-feedback,2017-09-17T04:54:03Z,2019-03-18T12:54:28Z,"https://github.com/WordPress/WordPress/blob/4.8-branch/wp-includes/theme.php#L466-L513
I saw this part and decided to put style.css in /themes/my-theme/subdir/
And in fact it worked. But, there was one problem. That's about updating the theme. ( I update this theme from GitHub instead of WP.org. )
In /wp-admin/update-core.php, Updating is success. At this time in site_transient_update_themes, There was a value of `my-theme/subdir` as a slug.
In /wp-admin/themes.php, Updating is failed. An error message was displayed `The theme is at the latest version.`. At that time, the response of ajax was as follows.
{{{
{
""success"":false,
""data"": {
""update"":""theme"",
""slug"":""my-themesubdir"",
....
}
}}}
That is, the slash has disappeared. When I looked it up, it was `wp_unslash()` when updating here.
I think that it is better to unify processing for slashes on either page.
",inc2734
Future Releases,53439,Updating failed. The response is not a valid JSON response.,,Editor,5.7.2,normal,major,Awaiting Review,defect (bug),new,dev-feedback,2021-06-17T10:57:16Z,2021-06-24T23:44:00Z,"Hi, There seems to be a issue where when one tries to save a page you get the error ""Updating failed. The response is not a valid JSON response."" The only thing that seems to work is to set the permalink setting to plain.
I believe the issue has something to do with paths. I am running PHP 7.0.27
I have installed a fresh install of WP in wwwroot on a hosted service Hostek. Updated to 5.7.2. The only plugin I have is gutenberg using 2021 Theme. Set the permalink to Post Name. No problems with this setup.
Then I installed a test WP installation into wwwroot/_test/abc. Updated to 5.7.2. This only has gutenberg and 2021. Set the permalink to Post name. - WP throws the error and refuses to save the page - I do get offered to restore the backup so some sort of saving takes place. Following online guidance, I change the permalink to plain and then WP will save the page.
It seems that the issue has something to do with json not liking that WP is not installed at the root of the server. Possibly json is testing the slug and erroring out due to path conflict.
error site would be abc.com/_test/abc/slug.
good site is abc.com/slug
Kind Regards
Richard
",lupussolaris
Future Releases,33147,"Updated message on install.php, Username can't be change directly after installation",,Upgrade/Install,,normal,normal,,defect (bug),new,dev-feedback,2015-07-27T20:03:53Z,2020-01-21T15:25:53Z,"On install.php page, Text is wrong, Usernames cannot be changed.
",Ankit K Gupta
Future Releases,21989,update_option() calls sanitize_option() twice when option does not exist,,"Options, Meta APIs",,normal,normal,Future Release,defect (bug),new,dev-feedback,2012-09-25T05:04:34Z,2024-02-22T06:16:56Z,"
I just spent several hours tracking down an issue when using the Settings API where `sanitize_option()` is called twice which is unnecessary execution especially if sanitization includes calling an external API for username/password authorization ''(this was how another developer set it up for a plugin I was debugging.)''
What happens is that a call to `update_option()` will call `sanitize_option()` and then if the option wasn't previously in the options table `update_option()` will delegate to `add_option()` which calls `santize_option()` a second time. This would normally be easy to workaround by first calling `get_option()` and testing for `false` and calling `add_option()` instead of `update_option()` if `false`, but not when the Settings API chooses how to call it.
I've looked at the problem and can envision several different ways to solve it such but don't know which the core developers would choose ''(or if they'd choose yet another option I haven't envisioned)'' so I didn't submit a patch:
- Adding a 3rd parameter `$mode` to `sanitize_option()` that identifies the mode ''('add', 'edit', default = 'unknown')'' and thus allow the hook to ignore one of the options ''(this would be more backward compatible but would put the onus on the developer to know to do this)'',
- Adding a 5th parameter `$bypass_sanitize` to `add_option()` defaulted to `false` that is only passed as `true` in `update_option()` allowing `update_option()` to disable the call to `sanitize_option()` found in `add_option()` ''(this would be less backward compatible and hacky, but seemless to the developer)''
- Adding a 3rd parameter `$bypass_sanitize` to `update_option()` defaulted to `false` that is only passed as `true` from `/wp-admin/options.php` allowing `update_option()` to bypass the call to `sanitize_option()` if an `add_option()` will happen ''(this would be less backward compatible and hacky, but seemless to the developer)''
- Have `/wp-admin/options.php` test for no pre-existing option and then call `add_option()` or `update_option()`, respectively ''(this would be seemless to the developer but less backward compatible and not hacky, and it wouldn't handle the general case.)''
So is this worth fixing to save other users and developers debugging time, and to reduce the chance of subtle errors in new code? If yes, how best to approach?",MikeSchinkel
Future Releases,49545,update_meta_cache issue while getting record from user meta table in multi site,,Users,5.3.2,normal,blocker,Awaiting Review,defect (bug),new,dev-feedback,2020-02-28T13:11:22Z,2023-04-24T13:16:25Z,"
Hi All,
I am facing a strange wp problem. I have a multisite setup and around 10K sites are running over it. Lots of sites are created with superuser i.e. user_id=1
every time when site hit in the browser then following query executed:
Filename: wp-includes/meta.php
Method: update_meta_cache
Line No: #825
My Application Traffic: 50million/day
SELECT user_id, meta_key, meta_value FROM wp_usermeta WHERE user_id IN (1) ORDER BY umeta_id ASC;
Problem:
if suppose 5k sites created with user_id=1 and then whenever traffic come over my application then it will fetch all rows against this user_id =1 from user meta table and as now around 20k ROWS_EXAMINED and ROWS_SENT in every query but I, in reality, it will require only 4-5 rows based on current blog id (site id).
There should be a check for blog id (site id) inside this function because other returning row is useless and due to this my query going slow.
I have tried the following things:
1. Change usermeta table engine. MyISAM to InnoDB but its not work There is no possibility of row-level locking, relational integrity in MyISAM but with InnoDB this is possible. MyISAM has table-level locking [Not worked]
2. Try table engine MyISAM to Memory but it's also not working because usermeta contain meta_value and whose data type blob but unfortunate Memory engine will not work with blob so can't able to change the engine to Memory [Not worked]
3. Can I comment this function call or add return null [Not try as of now because this is wp core file and whenever I will update wp version it will show conflict and also not a good approach to change wp core file]
4. Can I some other cache inside here? [not tested because again it's wp core file]
5. Can I add current blog ID check inside this function and retrieve only those records whose belong to this site only [but again this check need to put inside wp core file ie. wp-includes/meta.php]
6. is there any hooks or something which I can use over here?
",classicalrehan
Future Releases,55553,update_blog_option should accept autoload parameter,,"Options, Meta APIs",5.9.3,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2022-04-10T21:22:46Z,2024-01-31T21:27:10Z,"The function update_blog_option doesn't accept any autoload parameter, even though it calls the function update_option that accepts an autoload parameter.",giuse
Future Releases,16156,update-core is oblivious to api.wp.org being unreachable,,Upgrade/Install,,normal,normal,,defect (bug),new,dev-feedback,2011-01-08T09:51:38Z,2020-09-17T18:31:46Z,"A server running 3.0.4 had trouble reaching *.wordpress.org for some unknown reason. (This wasn't during the brief api.wp.org outage, and it worked otherwise.)
Problem is, update-core was completely oblivious to this. It's even worse when running 3.1, because the 'Check Again' button will refresh the page and tell you we last checked for updates *just now*.
Try Again or Check Again should reflect that the API is unreachable when this can be determined. Claiming that we checked for updates is also really lame, so we should see if the transient tells us how long it's been since the last one.
Side note, the plugin install et al. HTTP error messages are rather cryptic, and we should also make those more user friendly.",nacin
Future Releases,47218,Update TinyMCE to 5.X.X or 6.X.X,,TinyMCE,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2019-05-10T17:41:21Z,2023-09-08T21:08:30Z,"TinyMCE Version 5.0.5 has been released on May 9, 2019, see:
https://www.tiny.cloud/docs/release-notes/release-notes50/
https://www.tiny.cloud/docs/changelog/
Don't we want to keep it up to date?
It ''could'' break things, though, see :
https://www.tiny.cloud/docs/migration-from-4x/
related: #47205",Presskopp
Future Releases,55688,Update size function in WP_Filesystem_Direct,,Filesystem API,2.5,normal,normal,Awaiting Review,defect (bug),new,close,2022-05-06T04:48:11Z,2022-05-06T19:21:54Z,"Related: #55678
Replying to [comment:8 costdev]:
>
> [https://github.com/WordPress/wordpress-develop/pull/2677 PR2677] was discussed in the scrub. The PR patches a different function and this should be handled in a different ticket.
",mukesh27
Future Releases,55604,Update SimplePie to version 1.7.0,,External Libraries,6.0,normal,normal,Future Release,task (blessed),new,needs-unit-tests,2022-04-21T20:05:26Z,2024-02-05T20:11:34Z,"A new version of SimplePie has just been released.
This version contains a few enhancements and some bug fixes.
The most notable change, however, is that this release contains a ''forward-compatibility'' layer for the change to PSR-4 namespaced classes which is targetted for SimplePie 2.0.0.
With some similarity to Requests - the namespaced versions of the classes are in a different base directory (`src`) from the original versions (`library`).
As WP currently only includes the files in the `library` directory, I would like to suggest to continue doing so for now.
This still makes the ''forward-compatibility'' layer available as all files in the `library` directory now create a ''class alias'' to their namespaced version.
Once 2.0.0 has been released, the files included in WP, should be switched to the files from the `src` directory (which is currently in place mostly to allow for Composer autoloading) and should start using the namespaced names for the SimplePie classes.
I'd recommend for this update to be mentioned in a dev-note, so plugins/themes directly using SimplePie can decide for themselves when they want to change to using the namespaced names for SimplePie classes.
Refs:
* https://github.com/simplepie/simplepie/releases/tag/1.6.0
* https://github.com/simplepie/simplepie/blob/1.6.0/CHANGELOG.md#160---2022-04-21
* https://github.com/simplepie/simplepie/compare/1.5.8...1.6.0
I've done a cursory check of the changes and they look sane to me, but would very much like to invite a second opinion and I'd recommend testing this change (more thoroughly than usually done for upgrades like these).
I'd also like to recommend for a few cursory tests to be added to the WP test suite to ensure that both the PSR-0 as well as the PSR-4 class names load correctly when only including the `library` directory in WP.
I'd recommend for this update to be applied in WP 6.1 **early**.
Previous: #36669, #51521, #54659",jrf
Future Releases,51278,Update return types to reflect the real return types. Remove mixed.,,General,,normal,major,Future Release,enhancement,reviewing,dev-feedback,2020-09-09T16:10:51Z,2021-05-31T23:59:17Z,"In the DocBlocks, we document return values with `mixed` only.
That is no good practice as it does not show the real available and possible return types.
A better approach is to declare and document explicitly return values separated by a pipe character like this `@return bool|string`
That is much clearer because developers do not need to check the return values by reading the entire docBlock, reading the whole code of a method, or reading the (lengthy) function description under developer.wordpress.org.
A simple`mixed` is outdated and makes it hard for every severe developer to start with coding for WordPress as he has to continually check the expected return values when there is a `mixed`.
As a bonus, the documentation under developer.wordpress.org will be updated as well by this change automatically. It will help developers getting know the correct return values immediately from the docs without reading all the extra special explanations that we added to our docs whenever we use `mixed`.
That is a huge time saver and makes it much faster for every developer to write solid and better code faster.
If this is accepted for core, I will offer to work on this on all other methods as well.
That will be a long-lasting process due to the number of functions, but it's definitely worth the effort. We should make this change to all methods where we use`mixed` and make it to our daily little take-care moment when we add new methods to WordPress.
Sample Patch by using `get_option()` as an example for all methods that use `mixed`:
https://github.com/WordPress/wordpress-develop/pull/523
`get_option()` is a special case, though as it automatically unserializes. So it supports all non-scalar types. Most other methods in WordPress uses `mixed` with only two return types like `bool|string` representation, which makes the updates easier.
",ReneHermi
Future Releases,29999,update post overwrites slug if current_user is contributor,,"Posts, Post Types",4.0,normal,minor,Awaiting Review,defect (bug),new,dev-feedback,2014-10-16T08:09:04Z,2024-03-07T21:30:46Z,"The [http://codex.wordpress.org/Function_Reference/wp_update_post/ wp_update_post] function calls [http://codex.wordpress.org/Function_Reference/wp_insert_post/ wp_insert_post] which is located in [https://core.trac.wordpress.org/browser/tags/4.0/src/wp-includes/post.php#L3068/ wp-includes/post.php] in posts.php at lines 3168 - 3171 there is this code:
{{{
// Don't allow contributors to set the post slug for pending review posts.
if ( 'pending' == $post_status && !current_user_can( 'publish_posts' ) ) {
$post_name = '';
}
}}}
this will remove post_name if the current user is a contributor without any message or notification. This creates an issue because scripts/plugins that uses wp_upadate_post usually don't handle this case (the documentation doesn't cover this also - I would update the documentation but I'm wondering if there's no other solution).
I don't see the issues that a contributor changing the slug would create (a contributor vs an editor) anybody does?",jnhghy
Future Releases,54034,Update jQuery UI Touch Punch to the latest version,Hareesh Pillai,External Libraries,,normal,normal,Future Release,enhancement,assigned,changes-requested,2021-08-28T19:39:10Z,2023-03-23T17:20:07Z,"A new version of jQuery UI Touch Punch is available ([https://github.com/furf/jquery-ui-touch-punch/blob/master/jquery.ui.touch-punch.min.js v 0.2.3]). However, this version was released 7 years ago and might have issues while updating.",Hareesh Pillai
Future Releases,47563,Update get_template_part() function,,Themes,,normal,normal,,feature request,reopened,dev-feedback,2019-06-19T12:31:29Z,2021-03-21T18:49:44Z,"I think it would be good to add the ability to programmatically override the output of posts in the loop without interfering with the theme files ( for example, archive.php and others ). This will allow you to change the display of posts through plugins.
**For example.** To adapt the theme to work with Woocommerce, you need to edit the theme code. For users, this is sometimes very difficult.
My code:
{{{#!php
'Updates', and optionally against 'Plugins') should change to reflect the outstanding number of Updates available as Updates are Applied, whether they are applied individually on the Plugin Screen, or in bulk through the Updates Screen.
This is not a high priority issue at all, but an extremely minor cosmetic change. I suspect that Javascript could be used to change the value as an Update completes successfully in any scenario.
",Lucanos
Future Releases,10653,Update comment_author when display_name changes,SergeyBiryukov,Comments,5.1,normal,normal,Future Release,enhancement,reviewing,dev-feedback,2009-08-19T19:43:29Z,2021-04-05T12:31:54Z,One thing that has bothered me recently is the fact that your previous comments doesn't get updated when your display_name is being updated. Which could cause some confusion. I wrote a function (see attached file for further reference) that takes care of this but I would love to see a similiar feature in the WordPress core.,mptre
Future Releases,55260,Update Codex Page to Include Password Visibility Button and Language Switcher,,Login and Registration,5.9.1,normal,normal,Awaiting Review,enhancement,new,needs-docs,2022-02-25T16:43:24Z,2022-02-25T16:43:24Z,"The Codex page, [https://codex.wordpress.org/Customizing_the_Login_Form /Customizing the Login Form], needs to be updated to include the [https://ibb.co/1dZ23W1 /login form password visibility button and the language switcher].
To assist, the following can be added to the updated page for the benefit of all WordPress users:
**Code to Disable the Password Visibility Button:**
{{{
function remove_wp_hide_pw_button() {
?>
post_type ) {
return false;
}
$caption = $post->post_excerpt;
/**
* Filters the attachment caption.
*
* @since 4.6.0
*
* @param string $caption Caption for the given attachment.
* @param WP_Post $post Attachment object.
*/
return apply_filters( 'wp_get_attachment_caption', $caption, $post );
}
}}}
The get_the_post_thumbnail_caption that use the wp_get_attachment_caption accept the $post object.
Also, instead of passing the $post->ID to the wp_get_attachment_caption, use the $post object, so we can work directly with the object instead of calling again the get_post function to retrieve it.",wido
Future Releases,34913,Unscheduling cron jobs fails when original arguments were not an array.,,Cron API,3.0,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2015-12-08T13:31:40Z,2021-09-02T05:39:24Z,"The Cron API does not check whether the cron job arguments passed are an array when scheduling a cron job. This inadvertently allows for scheduling cron jobs with string, integer or other arguments.
However when unscheduling the cron job using `wp_clear_scheduled_hook()`, the arguments are ''always'' cast to an array which leads to cron jobs which '''*can*''' be scheduled, but can't be '''''*un*'''''scheduled using `wp_clear_scheduled_hook()`.
The `wp_clear_scheduled_hook()` does throw a `deprecated` notices when non-array arguments are passed in, but this will most of the time go unnoticed as this function is most often used in a plugin deactivation routine.
The patch which I'm submitting makes sure that cron job arguments are always cast to an array.
The patch is backward compatible in that it:
* will not break the `schedule_event` filter for plugins (which are ''doing it wrong'') which expect their original non-array argument to test against.
* will schedule all newly schedule events with array arguments independently of how the arguments were passed.
* will upgrade the cron array to ensure that all arguments are arrays.
The patch includes unit tests proving the existence of the bug and the fixing of it by this patch.
As far as I can see, this bug was introduced by the changes in https://core.trac.wordpress.org/changeset/12462 and has been in WP since 3.0.
The patching of this bug also brought to my attention *another* (ancient) bug where in the cron option upgrade routine `_upgrade_cron_array()` the array structure wasn't respected properly leading to `Undefined index: args` notices and the inadvertent removal of cron events which were scheduled on the same hook for the same timestamp with different arguments.
That bug has also been fixed in this patch.",jrf
Future Releases,35993,Unit tests: XML-RPC Request routines,,XML-RPC,0.71,normal,normal,Future Release,enhancement,new,dev-feedback,2016-02-29T01:07:36Z,2022-01-20T13:01:43Z,"I wrote unit tests for the 3 methods regards to XML-RPC request in functions.php, the aim is improve de code coverage, theses methods are:
* xmlrpc_getposttitle()
* xmlrpc_getpostcategory()
* xmlrpc_removepostdata()
This patch cover 100% of coverage related to theses methods above.
Only one thing to consider, I didn't found any XML-RPC format on the WordPress doc with title and category, so I've created a simple XML format with both, following the methods the behaviour is the same.",borgesbruno
Future Releases,37096,Unit tests for xmlrpc_getposttitle() and xmlrpc_getpostcategory() along with patch to trim and unique returned values,SergeyBiryukov,XML-RPC,0.71,low,minor,Future Release,enhancement,reviewing,dev-feedback,2016-06-14T00:24:25Z,2022-01-20T13:01:43Z,In tonight's Contrib 2 core we created this unit test for xmlrpc_getposttitle() function,pbearne
Future Releases,55192,unit tests for _wp_check_existing_file_names,hellofromTonya,Build/Test Tools,,normal,normal,Future Release,defect (bug),assigned,dev-feedback,2022-02-17T23:25:24Z,2022-11-16T22:04:53Z,,pbearne
Future Releases,43663,Unit Test test_theme_file_uri_returns_valid_uri fails on directories with spaces,,Build/Test Tools,4.9.5,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2018-03-29T22:15:47Z,2018-03-30T20:56:09Z,"Setting up PHPUnit and running the unit tests for the first time produced some failures because I was running from a directory with spaces in the name (WordPress Unit Tests).
4 assertions in total failed, but all 4 of them reference the same function, here is one of the examples:
{{{
1) Test_Theme_File::test_theme_file_uri_returns_valid_uri with data set #0 ('parent-only.php', 'theme-file-parent', array('theme-file-parent'))
Failed asserting that two strings are identical.
--- Expected
+++ Actual
@@ @@
-'/Users/mattkeys/Desktop/W/WordPress%20Unit%20Tests/tests/phpunit/includes/../data/themedir1/default/parent-only.php'
+'/Users/mattkeys/Desktop/W/WordPress Unit Tests/tests/phpunit/includes/../data/themedir1/default/parent-only.php'
}}}
Looking at this test, it makes use of esc_url_raw() which encodes the spaces as %20, then compares them against the original URI which has does not have the spaces encoded, so they are not the same.
If this is something that we want to fix, an easy way would be to str_replace spaces > %20 before running the assertion. Patch attached.",mattkeys
Future Releases,42058,Unit test for _autop_newline_preservation_helper(),,Formatting,4.9,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2017-10-01T18:49:35Z,2017-12-11T17:29:20Z,just a unit test,pbearne
Future Releases,39158,Unify site deactivation process,,Networks and Sites,,normal,normal,Future Release,defect (bug),new,dev-feedback,2016-12-07T19:20:38Z,2017-08-14T17:16:24Z,"Currently there are three cases of ""deleting"" a site on a multisite setup:
* deleting a site entirely (for example via Sites list table's ""Delete"" link)
* deactivating a site from the network admin (for example via Sites list table's ""Deactivate"" link)
* deactivating a site from the site admin (admin can click ""Delete Site"" in Tools menu)
Note that deactivating a site does not wipe out the site, but rather sets the ""Deleted"" flag for that site (strange legacy naming, can be ignored here).
What this ticket should solve is that the latter two processes work differently although they should be doing the same thing: While deactivating a site from the network admin simply sets the site to ""Deleted"", deactivating the current site from the site admin also removes all users from the site (via `wpmu_delete_blog()`). That means if an admin deactivates their site and later asks support (i.e. the network administrator) to restore it, all users will be gone.
I'm not sure why this happens, but I certainly don't think the two actions should have a different behavior. My proposal is to move the part of that function where users are removed into the `if ( $drop )` clause to make sure users are only removed when the site is actually being deleted.",flixos90
Future Releases,17451,Unify plugin update notices and include changelog data,nacin*,Upgrade/Install,,normal,normal,,enhancement,accepted,dev-feedback,2011-05-16T09:23:25Z,2019-06-04T21:07:00Z,"Currently the after_plugin_row hook is only used on plugins.php which is used by the Changelogger plugin to show plugin changelogs inline.
If the hook is also added to the bottom of list_plugin_updates in update_core.php then changelogs could also be displayed on that page too.
It's only a single line change so not sure how/if it's worth me attaching a patch for this?",dempsey
Future Releases,41791,Unicode + add_permastruct breaks rewrite rules,,Rewrite Rules,4.9,normal,normal,Awaiting Review,defect (bug),new,needs-unit-tests,2017-09-04T11:15:57Z,2017-09-15T13:14:58Z,"This was reported here https://github.com/woocommerce/woocommerce/issues/16673
To recreate the issue, create a taxonomy with a cyrillic name such as Сертификат. View the taxonomy archive. You'll see no results; it will go to the homepage rather than an archive.
In WooCommerce you can recreate this by creating an attribute (Product > Attributes) with a cyrillic name, and enabling the 'archive', assigning a term from this taxonomy to a product, and trying to view products by that term.
I managed to trace it back to the `add_permastruct`. The `struct` is added with unicode % encoded characters. When the rewrite rules are processed, it thinks these are placeholders so the `matches` variables do not align. See this screenshot for clarity:
https://www.dropbox.com/s/5vztnfm6895488a/query%20is%20wrong.png?dl=0
Notice all the $matches? Compare to a working taxonomy:
https://www.dropbox.com/s/24zyr5v7taw7b60/correct.png?dl=0
This can be fixed by using `urldecode` when adding the permastruct. I don't know if this has side effects but it worked in testing.
Patch to follow.
",mikejolley
Future Releases,43578,Unexpected MYSQL data format,,Database,4.9.4,normal,normal,Future Release,defect (bug),new,dev-feedback,2018-03-19T19:36:00Z,2020-02-03T18:01:45Z,"When I use field `user_id` in `$wpdb->insert` it set value to Integer, but the table I add data into has `user_id` text field.
It works normally only if `format` parameter specified.
Example:
{{{#!php
query(""CREATE TABLE {$wpdb->prefix}_test (`id` INT, `user_id` VARCHAR(16))"");
$wpdb->insert(""{$wpdb->prefix}_test"", ['id' => 1, 'user_id' => 'stringKey']);
print_r($wpdb->get_row(""SELECT * FROM {$wpdb->prefix}_test WHERE id = 1""));
}}}
Result: `stdClass Object ( [id] => 1 [user_id] => 0 )`",loranrendel
Future Releases,54078,Underscore appended to media file on upload,,Upload,5.8,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2021-09-06T14:02:07Z,2021-09-07T14:35:04Z,"I noticed that a random underscore is appended to media files, when uploading them in an article. Im using the Classic Editor.
The original file name was:
**AB-LET.2018.133.AXH1.jpg**
Once uploaded, it became:
**AB-LET.2018.133.AXH1_.jpg**
There was no prior file uploaded with that name (at least the media gallery does not find any).",spielautomat4
Future Releases,47733,Undefined index HTTP_HOST in wp-includes/ms-settings.php on line 57,SergeyBiryukov,Bootstrap/Load,5.2.2,normal,minor,Future Release,defect (bug),reviewing,dev-feedback,2019-07-18T17:10:16Z,2024-02-21T14:31:47Z,"We get requests on our server of the form
{{{
175.143.12.??? - - [30/Jun/2019:10:22:45 +0200] ""GET / HTTP/1.0"" 500 73873 ""-"" ""-"" (dinse.eu)
}}}
This request uses HTTP/1.0 and results in a status code 500. The related entry in the PHP error log is
{{{
[30-Jun-2019 08:22:45 UTC] PHP Notice: Undefined index: HTTP_HOST in /usr/www/xxxx/wp-includes/ms-settings.php on line 57
}}}
1. In ms-settings.php on line 57 it is not checked if
{{{
$_SERVER['HTTP_HOST']
}}}
is set.
2. Also I've found that in the case of this specific request
{{{
$_SERVER['SERVER_NAME']
}}}
is defined and not empty and can be used as a replacement.
My suggestion is to first check if
{{{
$_SERVER['HTTP_HOST']
}}}
is set else check if
{{{
$_SERVER['SERVER_NAME']
}}}
is set and if both are not set to implement a graceful error handling.
This may be related to #34353.
WP 5.2.2
PHP 5.6.40
Server: Apache/2.4.25 (Debian)
WP_DEBUG = true
",JochenT
Future Releases,55548,"Unchecked ""Uncategorized"" checkbox re-checks itself upon publish or update of a post",,Editor,5.9.3,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2022-04-08T21:02:10Z,2022-04-08T21:02:10Z,"A WordPress-based news website's editorial team has problems with the ""Uncategorized"" category.
1. They create a post and check the desired category and uncheck the default ""Uncategorized"" category.
2. Then they click ""Publish"".
3. At the last second during the Publish operation, the Block Editor unchecks the user-selected category and re-checks ""Uncategorized"".
4. Then they have to go back into the post and attempt to uncheck ""Uncategorized"" and recheck the desired category.
They have to do step 4 three or four times to get the result they want. Or they just use ""Quick Edit"" to change it in the post list.
It doesn't happen every time and is sometimes difficult to reproduce. But it happens often enough to be a problem. I cannot find a way to consistently reproduce it. Nor can I find any indication that this is a known issue with WordPress. It will happen with or without plugins enabled.
If there's no easy way to investigate or fix this in core, is there a way to add a script somewhere in the theme's functions.php or a jQuery script somewhere to ensure that ""Uncategorized"" *never* gets checked and that the originally-intended category remains checked? All the searches I do on Google for this topic ironically just reveal a bunch of posts on peoples' blogs that are set to ""Uncategorized"".",rcwatson
Future Releases,45725,Unable to use the UPLOADS constant with WordPress in a different directory,,Upload,,normal,normal,Awaiting Review,enhancement,new,needs-docs,2018-12-20T13:07:46Z,2019-01-16T06:50:09Z,"=== The problem ===
When WordPress is installed in a different directory (you can achieve that by following [[https://codex.wordpress.org/Giving_WordPress_Its_Own_Directory|these instructions]]), the **UPLOADS** constant is unable to function correctly in some cases according to the **wp_upload_dir()**'s output. Occasionally the constant accepts a relative path what will be appended to the **ABSPATH** constant to determine the **basedir** and to the **site_url()** function to determine the **baseurl** for the uploads location.
Although WordPress does let you move the CMS (it actually can be anywhere on the filesystem), however the uploads directory will always be relative to the CMS directory (**ABSPATH** constant) when using the **UPLOADS** constant.
=== The use case ===
There are multiple use cases which will be affected by this but let's consider the next few parameters:
* Website URL: example.com
* Website DIR: /foo/bar
* WordPress URL: example.com/wordpress
* WordPress DIR: /foo/bar/wordpress
Our goal is to store uploads at:
* Uploads URL: example.com/uploads
* Uploads DIR: /foo/bar/uploads
However when we defining the UPLOADS constant as 'uploads', will result in the following:
* Uploads URL: example.com/wordpress/uploads
* Uploads DIR: /foo/bar/wordpress/uploads
You might wonder what will happen when we use an absolute value for the constant instead, in this case '/foo/bar/uploads' is used:
* Uploads URL: example.com/wordpress//foo/bar/uploads
* Uploads DIR: /foo/bar/wordpress//foo/bar/uploads
=== The solution ===
Possible solutions where I could came up with are, the two following:
* Add another constant like **ABSPATH** to the index.php, this could be tricky for some people to update but the benefits of it are very useful. It will allow you to use one WordPress installation for all your WordPress websites. How you might wonder? [[https://stackoverflow.com/a/39195424/3157038|This is how]], I've been using this already for years!
* Another solution could be to introduce a new constant specifically for the uploads directory path and only use the current **UPLOADS** constant for the url.
Both of these solutions require to be implemented into the **_wp_upload_dir()** function [[https://core.trac.wordpress.org/browser/tags/5.0/src/wp-includes/functions.php#L1972|on line 1972 in wp-includes/functions.php]]
Have a look at the patch attached to this ticket, with the patch WordPress will introduce both the **UPLOADS_DIR** and **INDEX_ABSPATH** constant. According to some tests I did it should also be backward compatible.",Fleuv
Future Releases,44358,Unable to search a user if username is an email address,,Users,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2018-06-13T14:43:41Z,2019-01-16T06:50:09Z,"If a user has an email address in his username, that user is not searched in admin user list page.
Steps to reproduce:
- Create a new user and use an email address as the username, e.g. `abc@gmail.com`
- Make sure no user on the system has an email address which contains `abc@` in it
- Search a user with `abc@` keyword. No user will be returned.
I think since WordPress does not restrict the character `@` in username, the search should include username field even when there is `@` in search keyword.
Does this make any sense?
",subrataemfluence
Future Releases,31615,UI bug using Quick Edit,,Quick/Bulk Edit,4.1.1,normal,normal,,defect (bug),new,dev-feedback,2015-03-12T20:13:47Z,2019-06-04T21:14:25Z,"After changing the parent attribute for a page using Quick Edit, the page title is prepended with the child hyphen but the table structure does not change. Refreshing the page fixes the issue.
Using latest 4.1.1 with no plugins installed and default theme.
'''Steps to replicate:'''
1. Change the parent of a page or post using quick edit
'''Browser'''
Chrome: 41.0.2272.76 (64-bit) OS X Yosemite 10.10.2.
",justingreerbbi
Future Releases,60070,Typo in wp-includes/class-json.php,,General,,normal,trivial,Awaiting Review,defect (bug),new,dev-feedback,2023-12-14T10:25:56Z,2024-01-27T21:12:45Z,"If we go through wp-includes/class-json.php on line number 186 we can see it is mentioned: ""multibye"". It should be ""multibyte"".",jayadevankbh
Future Releases,37882,Typo in the tests/qunit/wp-admin/js/customize-header.js,,Customize,3.9,normal,normal,Future Release,defect (bug),new,dev-feedback,2016-08-30T13:56:49Z,2019-04-18T19:02:19Z,Fix test header in the 'Custom Header: HeaderImage shouldBeCropped()' module,tymvie
Future Releases,58986,TypeError: Unsupported operand types: string * int *,,Date/Time,6.2.2,normal,normal,Future Release,defect (bug),reopened,dev-feedback,2023-08-05T17:08:48Z,2024-03-18T17:57:31Z,"Path: `/wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php`
File: `class-wp-rest-posts-controller.php`
Line: 1833
**Expression Error:** `get_option('gmt_offset') * HOUR_IN_SECONDS`
**Rais Exception:** `TypeError: Unsupported operand types: string * int`
Suggested Fix: `intval(get_option('gmt_offset')) * HOUR_IN_SECONDS`
Thanks
",nurielmeni
Future Releases,60669,Twenty-Twenty-Two: The search block does not look the same same in the editor and the front.,,Bundled Theme,6.4.3,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2024-03-01T10:34:22Z,2024-03-01T15:42:09Z,"Hello,
I have reviewed and found that the ""Search Block"" border does not appear in front end.
Here, I have attached its screenshots.
Environment info
Device: Macbook M1
OS: 14.3.1 (23D60)
Browser: Google Chrome
Version 121.0.6167.184 (Official Build) (arm64)
WordPress version: 6.5-beta2 running, Gutenberg 17.8.0, Theme active: Twenty-Twenty-Two.
Thanks,",viralsampat
Future Releases,55815,Twenty-Twenty-Two: Post Format Gallery,,Bundled Theme,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2022-05-25T06:01:35Z,2022-06-17T18:52:44Z,"Twenty-Twenty-Two does not include gallery columns classes for the frontend. Another default theme has this class and it working fine for them.
{{{
.gallery-columns-2 .gallery-item {
max-width: 50%;
}
.gallery-columns-3 .gallery-item {
max-width: 33.33%;
}
.gallery-columns-4 .gallery-item {
max-width: 25%;
}
.gallery-columns-5 .gallery-item {
max-width: 20%;
}
.gallery-columns-6 .gallery-item {
max-width: 16.66%;
}
.gallery-columns-7 .gallery-item {
max-width: 14.28%;
}
.gallery-columns-8 .gallery-item {
max-width: 12.5%;
}
.gallery-columns-9 .gallery-item {
max-width: 11.11%;
}
}}}
",mukesh27
Future Releases,49030,Twenty Twenty: video resize functionality also impacts other elements on the page,,Bundled Theme,5.3,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2019-12-18T17:34:13Z,2020-05-14T15:37:38Z,"Twenty Twenty bundles a functionality named ""Intrinsic Ratio Embeds"", allowing videos ({{{iframe}}}, {{{object}}}, {{{video}}}) to be automatically resized on demand.
This is practical, but can be problematic for some elements on the page that may not behave like a video, or that may not be in the post content at all.
While plugins can use the {{{.intrinsic-ignore}}} CSS class to avoid being impacted by this, I wonder if we could be a bit more specific within the theme, and only target videos inside the post content. This would avoid conflicting with plugins adding iFrames and / or videos outside of the post content, like in widgets.
",jeherve
Future Releases,57978,Twenty Twenty: Separator block does not work well with gradients,,Bundled Theme,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2023-03-24T10:31:49Z,2023-06-10T06:53:38Z,"Steps to reproduce the issue :-
1. Download WordPress version beta version.
2. Choose Twenty Twenty theme.
3. Choose separator block.
4. Apply background color to separator block.
5. Now you can able to see that background color overlaps.
Because of that design not looks as per requirements.
I have attached video for better understanding.
Video URL :- WordPress version beta version.
https://share.cleanshot.com/Y9t7PKCBmJSB8dBW1hH4",nidhidhandhukiya
Future Releases,59706,Twenty Twenty: Latest Posts block colors and padding,,Bundled Theme,6.3.2,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2023-10-23T11:59:17Z,2023-10-25T22:19:11Z,"Hello Team,
I have worked on the **""Twenty Twenty""** theme and found that the ""Twenty Twenty"" theme contains an issue for the **""Latest Post""** block. The text color does not change when we try to select text color from block settings.
Also, When we select the background color, the padding is added in admin, But in the front end, the post text displays a sticky, The padding is not added for the front end.
Here, I have provided the issue video:
Issue: [https://share.cleanshot.com/5mkR0sVQ25VYM6xp434Y]
Thanks,",viralsampat
Future Releases,50418,Twenty Twenty: Inline Images displaying as block,,Bundled Theme,5.4.2,normal,normal,Future Release,defect (bug),new,dev-feedback,2020-06-17T23:51:12Z,2023-06-06T22:43:17Z,"Inline images (those added inside a paragraph block) will display on top of each other (as blocks) instead of next to each other (inline or inline-block).
https://d.pr/i/13DtBl
This will not happen in the editor, only on the public page/post:
https://d.pr/i/vkV9vC
I tried to reproduce this with several themes such as Rockwell, Brandsbury and Coutoire, but they all seem to work fine.",mrfoxtalbot
Future Releases,50026,Twenty Twenty: Full height with short content,,Bundled Theme,,normal,trivial,Awaiting Review,enhancement,new,dev-feedback,2020-04-28T22:35:16Z,2023-06-21T23:01:09Z,"With the `twentytwenty` theme, when the height of the content in a page does not fill up the entire viewport, the page ends up with extra trailing whitespace.
If we treat the `` as a flex box the page will always be filled:
{{{
body {
display: flex;
flex-direction: column;
min-height: 100vh;
}
main#site-content {
flex: 1
}
}}}
",beaucollins
Future Releases,48779,Twenty Twenty: Copyright and WordPress as text widget,,Bundled Theme,5.3,normal,normal,Awaiting Review,feature request,new,dev-feedback,2019-11-24T11:46:32Z,2022-07-08T16:08:09Z,"I would request to have all content elements easily editable. The only elements I couldn't change from the wp-admin interface were the footer copyright and wordpress text. I would like to change the Copyright to make it linkable and add creative commons to it. Now I had to do it a technical way by child theming, but not everyone is that technical.
Custom HTML (copyright) & Text widgets (wordpress link) with a third footer or so could be a solution? Only disadvantage is that WordPress doesn't support PHP by default for security reasons so you can't add the actual site name by code. But a lot of sites doesn't use their company name as site name so it can also be some lorum ipsum text.
e.g. © My Company
",jurjendevries
Future Releases,48800,Twenty Twenty: Conditional loading of language/locale specific css and php files,,Bundled Theme,5.3,normal,normal,Awaiting Review,feature request,new,dev-feedback,2019-11-26T20:52:30Z,2019-11-26T22:01:42Z,"First reported on GitHub by @nukaga
https://github.com/WordPress/twentytwenty/issues/970
In the current site design, the title is too large in Japanese and Chinese.
The center alignment is also extraordinary.
https://github.com/WordPress/twentytwenty/issues/118#issuecomment-541292567
https://github.com/WordPress/twentytwenty/issues/118#issuecomment-538964579
Solution
Is it possible to separate the title and body CSS in several languages?",ianbelanger
Future Releases,56205,Twenty Twenty: background color of column can affect the inner content color,,Bundled Theme,6.0,low,normal,Awaiting Review,enhancement,new,close,2022-07-12T13:52:54Z,2022-07-15T09:45:19Z,"Steps to reproduce :-
1. Activate Twenty Twenty theme.
2. Choose Columns block.
3. Give background-colour Accent colour from the options.
4. In inner column give a white background.
all the text under that column block is not visible because it is by default taking white colour.
For better understanding please refer to this video.
Video URL:- [https://share.cleanshot.com/vskbRyILtP0XkAq8aid4]",nidhidhandhukiya
Future Releases,48804,Twenty Twenty: Attach template parts with actions instead of directly including,,Bundled Theme,5.3,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2019-11-26T21:42:41Z,2019-11-26T21:54:34Z,"Originally requested on GitHub by @thomasplevy
https://github.com/WordPress/twentytwenty/issues/947
**The Problem**
Not all custom post types are created equal. Some custom post types are like blog posts where meta information, post author information, and navigation between post types makes sense. Other custom post types behave more like native pages where navigation between pages is undesirable.
This is a pretty generic and blanket statement and it's not always true. Custom post types are custom and the requirement differ greatly depending on the developer creating them.
I am working to add Twenty Twenty theme support for my plugin [LifterLMS](https://github.com/gocodebox/lifterlms) and I have several custom post types which I'd like to be able to remove author and custom post type navigation for.
Given the fact that custom post types utilize template at `template-parts/content.php` it is currently only possible for me to remove the navigation and author information by using custom CSS.
The meta information I am able to disable using the filter `twentytwenty_disallowed_post_types_for_meta_output`.
**Proposed Solution**
I'd like to modify the template in question to either be wrapped in a filter which allow the inclusion of `template-parts/entry-author-bio.php` and `template-parts/navigation.php` to be disabled via a filter.
For example:
https://github.com/WordPress/twentytwenty/blob/dea9290e7ca3d38b7067c3b7107787db6554249a/template-parts/content.php#L68-L72
{{{
if ( is_single() ) {
get_template_part( 'template-parts/navigation' );
}
}}}
Could become:
{{{
if ( is_single() && apply_filters( 'twentytwenty_display_single_navigation', true ) ) {
get_template_part( 'template-parts/navigation' );
}
}}}
If this does seem like an acceptable addition I'd be more than happy to write and submit the PR but I didn't want to spend time without a blessing from a core contrib or maintainer first.
Thank you for considering this!",ianbelanger
Future Releases,56496,Twenty Twenty-Two: Update comment block markup,,Bundled Theme,,normal,normal,Future Release,defect (bug),new,dev-feedback,2022-09-02T09:37:52Z,2024-01-19T11:13:34Z,"The comment block markup in Twenty Twenty-Two is using an outdated version of the block: ``
In the Site Editor, the block shows the following notice: You're currently using this block in legacy mode.
This should be updated to use the latest version of the comments block, e.g. wrapped in the `` tag.",mikachan
Future Releases,58107,Twenty Twenty-Two :- PullQuote block Letter case is not working in citation text,,Bundled Theme,6.2,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2023-04-09T16:40:12Z,2024-01-28T23:38:22Z,"**Steps to reproduce the issue : **
- Activate Twenty Twenty-Two theme.
- Go to Posts / Pages > Add New Post / Page
- Choose Pullquote block.
- Add some text in Quote & citation.
- Apply Letter Case in Pullquote
You can able to see that Letter Case is not working in the citation text.
I have attached video for better understanding.
**Video URL** :- https://drive.google.com/file/d/1-ypweKmaHmNCmq38naNi5TV0LEldojCQ/view",shailu25
Future Releases,56949,Twenty Twenty-Three: Screenshot of the new default theme,,Bundled Theme,6.1,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2022-11-02T04:02:28Z,2023-03-20T16:54:17Z,"The screenshot of the new default theme TT3 is showing the backend editor, not the front view of it. Our theme guideline is,
* The screenshot must not look like an advertisement. The reviewer can subjectively ask you to change screenshots if they find that it is not appropriate.
https://make.wordpress.org/themes/handbook/review/required/
It seems that showing Global Styles in the screenshot is like an advertisement of the feature. I'm wondering if other themes can also update the screenshot showing Global Styles or Editor. ",kafleg
Future Releases,57167,Twenty Twenty-Three: Replace base and contrast color names with ref values,,Bundled Theme,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2022-11-21T18:20:55Z,2022-12-07T15:26:33Z,"There have been previous discussions around the use of ""base"" and ""contrast"" as color names in the Twenty Twenty-Three color palette, here: https://github.com/WordPress/twentytwentythree/issues/36
I'd like to propose another idea that may help solve the naming issues, especially around these two colors. We could define these two colors in `styles.color.background` and `styles.color.text` instead of defining them separately in the color palette. We could then use `ref` values to reference them elsewhere in the theme.json files.
The colors can still be defined in the color palette, but perhaps under a descriptive name, e.g. ""dark purple"". This means that the names of these two colors in the color palette would not need to match their purpose (e.g. background, foreground, base, contrast).
I've created a PR to demonstrate the idea.",mikachan
Future Releases,57024,Twenty Twenty-Three: Randomly apply a style variation on activation,,Bundled Theme,6.1,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2022-11-07T19:28:49Z,2022-11-17T19:20:23Z,"In addition to the default base styling, Twenty Twenty-Three comes with 10 additional style variations.
When activating for the first time, an interesting way to showcase what the theme has to offer would be to randomly apply one of the 11 style variations.",desrosj
Future Releases,60778,Twenty Twenty-Three Theme: The Quote block style is not working as expected.,,Bundled Theme,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2024-03-15T07:13:01Z,2024-03-15T10:06:33Z,"Hello,
I have reviewed and found that the ""**Quote**"" block style is not working as expected into the **Twenty Twenty-Three** theme.
Here, I have attached video:
Issue: [https://share.cleanshot.com/78X9q3xkwy0kkT5HvHFL]
Thanks,",viralsampat
Future Releases,54368,Twenty Twenty-One: Visibility issue on Input field of search widget in dark mode,,Bundled Theme,,normal,normal,Future Release,defect (bug),new,dev-feedback,2021-11-03T12:50:08Z,2023-03-25T17:44:38Z,"When the dark mode is on, the search input field is not that visible on the twenty twenty-one theme. https://imgur.com/a/bEEjM09",amin7
Future Releases,54173,Twenty Twenty-One: Social icons,,Bundled Theme,,normal,normal,Awaiting Review,feature request,new,dev-feedback,2021-09-23T19:34:24Z,2021-10-05T16:44:29Z,"twentytwentyone/classes/class-twenty-twenty-one-svg-icons.php
in that beautiful theme
mail is take into account and
and mailto: links are shown with an envelope icon
shouldn't be the same with a
tel: link ? (a phone icon)
IMHO yes",marco.milone
Future Releases,56748,Twenty Twenty-One: Image stuck to text in responsive sizes,,Bundled Theme,5.6,normal,normal,Future Release,defect (bug),assigned,dev-feedback,2022-10-06T14:54:03Z,2023-03-25T15:21:22Z,"In responsive after 481px screen size image got stuck to text.
https://share.cleanshot.com/Ewl5TgZMdla8HDxLeERf",sagarladani
Future Releases,52683,"Twenty Twenty-One: Block ""more"" text in link can't be changed",audrasjb,Bundled Theme,5.6.2,normal,normal,Future Release,defect (bug),reviewing,dev-feedback,2021-03-01T14:03:56Z,2022-04-12T16:51:13Z,"Hi team,
Hope you are well.
I am on basic theme 5.6.2
Quick TT about the block ""more"" that we can add in article to have the link read more on the home page.
When I add this block I can change the text of the link but for some reason it doesn't show up on home page. Doesn't matter what I change I have always ""Poursuivre la lecture de"" as a link on my home page. I am on french version.
I didn't find any fix on your doc.
Regards",neokendev
Future Releases,52185,Twenty Twenty-One: background image does not work with dark mode,,Bundled Theme,5.6,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2020-12-28T23:29:48Z,2020-12-29T00:58:24Z,"I noticed that if I add a background image by going to Appearance > Customize > Background Image > Add image and turn on the dark mode the website changes the text to white but it does not have a dark background. Instead, it shows that background image which is hard to read white text on.
I was trying to find a workaround where if it is in dark mode then make the background image either disappear or darken.
I do not see anywhere to attach a file so it may not be with this ticket.
Michael",WebsThatRock
Future Releases,59934,Twenty Twenty-Four: PHPCS: Empty line required before block comment,,Bundled Theme,6.4,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2023-11-20T07:56:34Z,2023-11-24T22:42:14Z,I have fixed Empty line required before block the comment PHPCS issue on the twenty-twentyfour theme's function file.,pratikharadava
Future Releases,56601,Twenty Ten: overlap issue in Button block,,Bundled Theme,6.0.2,normal,normal,Awaiting Review,defect (bug),new,close,2022-09-19T12:09:07Z,2023-06-05T04:39:33Z,"In Twenty Ten Theme, when we add Button block in editor side and change alignment as ""Align left"" or ""Align right"". After that we add paragraph block or any other block then we can see that the Button block is overlapping with the newly added block.
Steps to replicate:
1: Activate the Twenty Ten Theme
2: Add Button block
3: Choose ""Align right"" or ""Align left"" from Align option
4: Add paragraph Block
5: View the page/post at editor side
For better understanding I provide video attachment link.
Video link: https://share.cleanshot.com/XuFtIRCURbgfcSSNxf41
Thanks",kajalgohel
Future Releases,60012,Twenty Sixteen: Pullquote block Appearance setting is not working properly,,Bundled Theme,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2023-12-05T09:37:35Z,2024-01-02T20:32:03Z,"The appearance of PullQuote blocks is not working correctly in Twenty-Sixteen. Though there are many options like semi-bold, medium, italic, etc. it seems only two things get applied no matter what I choose. It's either normal, bold or extra bold. And the extra bold is just as same as Black. No changes with any kind of italic.
Steps to reproduce the issue:-
1. Activate Twenty Sixteen theme.
1. Choose Pullquote block.
1. Write something in Citation
1. Change the appearance
To understand properly, here's the video: https://monosnap.com/file/kMF24nu84Y0Uj17dSOl11XSbNCslpy",ashikur698
Future Releases,60374,Twenty Sixteen: Navigation block inherits colors from button styles,,Bundled Theme,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2024-01-30T08:25:25Z,2024-02-26T20:11:23Z,"Similar to https://core.trac.wordpress.org/ticket/59924
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 element.
On the front of the website, this button inherits the background styles from the themes button CSS:
{{{
button:hover, button:focus, input[type=""button""]:hover, input[type=""button""]:focus, input[type=""reset""]:hover, input[type=""reset""]:focus, input[type=""submit""]:hover, input[type=""submit""]:focus {
background: #007acc;
}
}}}
When the menu item is focused, activated or hovered over, the background color changes to blue.
== Testing instructions:
Activate Twenty Sixteen
Make sure that your WordPress installation has some content that you can place in the navigation block, because you will need to create a submenu.
Create a new post or page.
Add a navigation block. In the block, select the inserter and add a link: this will be your parent menu item. Click on the link and select the option ""Add submenu"". Add a link.
Save.
Go to the front of the website.
Locate the navigation and hover over or move focus to the item that has the submenu.
Confirm that the background color of the menu item changes.
(You may also notice that if you set a background color on the submenu item in the block settings, this color only works in the editor, not the front, and this is a separate issue.)
",poena
Future Releases,51858,Twenty Sixteen: Add Telegram and Whatsapp support to Social Media Menu,,Bundled Theme,,normal,normal,Awaiting Review,feature request,new,dev-feedback,2020-11-24T02:29:03Z,2021-10-25T17:50:26Z,"This is a follow-up to #43999.
Please, add Telegram and Whatsapp support to Social Media Menu on Twenty Sixteen bundled theme. Support for these icons were added to Twenty Seventeen and Twenty Twenty. Can it be added to Twenty Sixteen as well?
Thanks!",Valery Kondakoff
Future Releases,40292,Twenty Seventeen: Use echo file_get_contents() instead of require_once() to pull in SVG file contents,,Bundled Theme,4.7.3,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2017-03-29T04:16:12Z,2023-10-06T13:27:34Z,"Using require_once() to pull in the contents of SVG files can result in the PHP parser throwing a
{{{
PHP Parse error: syntax error, unexpected version (T_STRING)
}}}
error if any of the SVG files begin with
{{{
}}}
The proposed solution is to use echo file_get_contents() instead.
A few recommendations for using that method are here:
https://css-tricks.com/using-svg/#article-header-id-7
http://sheelahb.com/blog/how-to-get-php-to-play-nicely-with-svg-files/
It could be argued that using require_once() is fine in Twenty Seventeen, since we know that none of the SVGs in /assets/images/svg-icons.svg contain the problematic tag. However, there are of course many developers who fork Twenty Seventeen, or copy its code into their own themes, so it seems wise to me to pull in SVG file contents using a method that won't throw errors in the event that tags are present in any SVG files.",kellenmace
Future Releases,42358,Twenty Seventeen: Social Links menu items in footer get hidden when used as child,,Bundled Theme,4.9,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2017-10-27T13:44:04Z,2021-08-21T23:30:57Z,"Inside customizer if I reorder Social Menu Items as Children while they are on footer, child items are not visible any more and no way to access them! But they come up as dropdown sub menu item(s) when placed in Top menu. Screenshot attached.
I think when Footer menu is checked menu option to create a parent-child kind of ordering should not be available. However, if both options (Header and Footer) are checked, parent-child ordering needs to be there, but it should only in header menu only and leaving all footer menu items visible.",subrataemfluence
Future Releases,39253,Twenty Seventeen: Head Image Quality Issue,,Bundled Theme,4.8,normal,normal,Future Release,defect (bug),new,dev-feedback,2016-12-12T20:51:19Z,2020-02-24T19:15:48Z,"A question about the Twenty Seventeen Theme's Head Image, it is really cool but the image is not in the best position on iOS Safari and image quality drops too...
[[Image(https://holywhite.com/wp-content/uploads/2016/12/Evernote-Camera-Roll-00281213-053634.png)]]
But if I turn the phone around...
[[Image(https://holywhite.com/wp-content/uploads/2016/12/Evernote-Camera-Roll-00281213-053635.png)]]
Looking much better, refresh it and rotate again?
[[Image(https://holywhite.com/wp-content/uploads/2016/12/Evernote-Camera-Roll-00281213-053636.png)]]
Wow the shiny picture comes back...
P.S. Is it possible to set the align of Head Image on mobile? So I can choose which part of the picture I mostly wanna show.",richardevs
Future Releases,60667,Twenty Seventeen: Cover block font-size does not apply to headings,,Bundled Theme,6.4.3,normal,normal,Awaiting Review,defect (bug),new,close,2024-03-01T09:30:26Z,2024-03-02T22:43:44Z,"Steps to reproduce the issue :-
1. Activate Twenty Seventeen theme.
2. Choose Cover Block.
3. Add Paragraph and Heading block inside cover block.
4. Now give font-size from cover block settings.
You can able to see that whatever font-size is choosen directly from the Cover block that is not applied on Heading block.
I have attached video for better understanding.
Video URL :- https://share.cleanshot.com/dqrXphrT236ZJ5xP0mFh
",nidhidhandhukiya
Future Releases,55180,Twenty Seventeen: Comments not showing up on the frontpage,,Bundled Theme,5.9,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2022-02-16T20:13:32Z,2023-06-07T17:56:39Z,"Hi there,
I'm not able to find any further information on this, but it looks like the comments aren't showing up on a static homepage with Twenty Seventeen.
I have tested this with the latest update of WordPress(5.9) and the last version of the theme.
**Steps to reproduce**
1. Switch theme to twenty seventeen
2. Enable ""Allow comments"" within the discussion tab on the sidebar on the homepage.
3. Check the page and search for the comments area.
Original request: https://github.com/Automattic/themes/issues/5545
If this is intended, I found this as a potential workaround: https://wordpress.stackexchange.com/questions/268305/display-comments-on-homepage-of-twenty-seventeen-theme",robertghetau
Future Releases,58547,Twenty Seventeen: Calendar block header cells should be centered,,Bundled Theme,6.2.2,normal,trivial,Awaiting Review,defect (bug),new,dev-feedback,2023-06-15T17:51:49Z,2023-06-15T19:01:32Z,"The th elements in the Calendar block are not centered like the rest of the text in the Calendar which looks odd.
",nkeller15
Future Releases,58474,Twenty Seventeen: Box shadow on Site Logo block looks odd,,Bundled Theme,6.2.2,normal,minor,Awaiting Review,defect (bug),new,dev-feedback,2023-06-07T15:26:43Z,2023-06-09T22:08:13Z,"Steps to reproduce:
1. Activate the Twenty Seventeen theme
2. Add the Site Logo block to any page or post and add an image
3. Make sure link to home setting is toggled on
4. Save and view on front end
",nkeller15
Future Releases,39740,"Twenty Seventeen: Allow child themes to use front-page.php when front page is set to ""Your Latest Posts""",,Bundled Theme,4.7,normal,normal,Awaiting Review,defect (bug),reopened,dev-feedback,2017-01-30T19:54:05Z,2023-04-18T09:41:50Z,"== What's Happening: ==
If a child theme of Twenty Seventeen has a `front-page.php` file, and the Reading settings are set to have ""Your Latest Posts"" as the front page, Twenty Seventeen's `twentyseventeen_front_page_template()` function, called on the `frontpage_template` filter, sets the template to an empty string instead of the child theme's `front-page.php`, so `index.php` gets used.
== What I expect: ==
I expect the child theme's `front-page.php` to be used if present, no matter what the Reading settings are for the front page, as [https://developer.wordpress.org/themes/basics/template-hierarchy/#front-page-display described in the codex]. This is the default behaviour.
== Relevant Code: ==
Here's TwentySeventeen's `twentyseventeen_front_page_template()` function, for reference:
{{{
/**
* Use front-page.php when Front page displays is set to a static page.
*
* @since Twenty Seventeen 1.0
*
* @param string $template front-page.php.
*
* @return string The template to be used: blank if is_home() is true (defaults to index.php), else $template.
*/
function twentyseventeen_front_page_template( $template ) {
return is_home() ? '' : $template;
}
add_filter( 'frontpage_template', 'twentyseventeen_front_page_template' );
}}}
Link to [https://core.trac.wordpress.org/browser/trunk/src/wp-content/themes/twentyseventeen/functions.php?rev=40024#L530 location in code viewer].
",johnnyb
Future Releases,39893,Twenty Seventeen Header Media: YouTube Embed Does Not Fill Screen,,Bundled Theme,4.7.2,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2017-02-16T18:47:31Z,2023-04-17T10:32:24Z,"Hi.
I was really excited to see 2017 in action and thought a great deal of the video header feature, but my expectations were dashed when I realised that the promise of anamorphic images and videos automatically stretching to full screen in the header just did not materialise, despite using all the precautions, guidelines and recommendations suggested in the theme: 2000x1200 as per image, .mp4, etc. It seems that no matter what video link from YT I tried the image will stretch, but the video will not.
Is there a solution to this or is it just me?
You can see a brand new installation with no extra plugins, scripts or other potentially interfering code in the way, here: http://2ud.biz/dev/
Thanks in advance
",cingrosso
Future Releases,49931,Twenty Nineteen: Group color styles prevent custom colors,poena,Bundled Theme,,normal,normal,Future Release,defect (bug),assigned,dev-feedback,2020-04-17T09:42:10Z,2024-02-13T11:46:31Z,"When TwentyNineteen was created, the ability to colorize various blocks was not as full-featured as it is today. You could easily choose text and background colors in a block, that would have no contrast at all.
However this is less of an issue today, where the contrast checker will help inform you whether the text is sufficiently legible or not.
In addition to this, the rules that colorize text according to what background color you applied to a group means that custom colors don't work at all, which will be more of an issue as global styles let you colorize more aspects.
This was originally reported in https://github.com/WordPress/gutenberg/issues/21672.",Joen
Future Releases,45955,Twenty Nineteen: get_the_archive_title filter issues,,Bundled Theme,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2019-01-12T05:36:49Z,2019-01-12T06:37:21Z,"I was testing the theme with a plugin that adds a custom post type and allows to set a custom title for the custom post type archive view using the following filter:
{{{
add_filter( 'get_the_archive_title', 'slug_set_the_archive_title' );
}}}
While this filter works fine in the previous WordPress themes, such as Twenty Seventeen, Twenty Sixteen and Twenty Fifteen, it does not work in Twenty Nineteen.
It's possible to fix it by setting a priority parameter in the filter. For example:
{{{
add_filter( 'get_the_archive_title', 'slug_set_the_archive_title', 99 );
}}}
The problem is that it breaks a header style, meaning the title will have the style of the archive view prefix text (grey color and serif font style).
Any idea what is the better way to use this filter in the
Twenty Nineteen theme?",taskotr
Future Releases,45945,Twenty Nineteen: Consider adding a filter for the featured image color filter functionality.,,Bundled Theme,5.0.3,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2019-01-11T19:35:36Z,2023-06-21T23:03:26Z,"Originally raised by @hvianna and @grapplerulrich in this GitHub thread:
https://github.com/WordPress/twentynineteen/issues/722
To make it easier for child themes to disable the featured image filter built into Twenty Nineteen, it might be helpful to add a filter for that functionality. Something along the lines of:
{{{
function twentynineteen_image_filters_enabled() {
return apply_filters( 'twentynineteen_image_filters_enabled', 0 !== get_theme_mod( 'image_filter', 1 ) );
}
}}}",kjellr
Future Releases,45473,Twenty Nineteen: Avoid html code in translatable strings,,Bundled Theme,,normal,normal,Future Release,defect (bug),new,dev-feedback,2018-12-03T14:20:45Z,2023-04-28T04:05:03Z,"As always only the translatable part should appear for translators to avoid issues.
I came across this one:
{{{#!php
Published in %title
}}}
",Presskopp
Future Releases,45911,Twenty Nineteen: Add archive descriptions,,Bundled Theme,5.0.2,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2019-01-10T16:56:53Z,2023-04-17T11:02:28Z,"Originally reported by @dannycooper in Twenty Nineteen's GitHub repo:
Archive descriptions weren't originally included in the theme's design, but it's been suggested they be added now.
@kjellr created a mockup of what they should look like.
Original issue here: https://github.com/WordPress/twentynineteen/issues/256",laurelfulford
Future Releases,60079,Twenty Fifteen: Separator block is too thick in the iframe editor,,Bundled Theme,6.3,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2023-12-15T04:35:20Z,2023-12-18T08:42:47Z,"Steps to reproduce the issue :-
1. Activate Twenty Fifteen theme.
2. Choose separator block.
3. Now see editor and front side.
You can able to see both the side block looks different.
I have attached video for better understanding.
Video URL :- https://share.cleanshot.com/nLtGwVmQWnDrHBvCZPV3",nidhidhandhukiya
Future Releases,54120,Twenty Fifteen: Fixed table layout,,Bundled Theme,,normal,minor,Awaiting Review,defect (bug),new,dev-feedback,2021-09-14T10:44:27Z,2022-07-08T17:16:46Z,"The CSS for Twenty Fifteen contains a line forcing fixed layout for tables:
{{{
table {
border-collapse: separate;
border-spacing: 0;
border-width: 1px 0 0 1px;
margin: 0 0 1.6em;
table-layout: fixed; /* Prevents HTML tables from becoming too wide */
width: 100%;
}
}}}
This causes unexpected behavior since you in Gutenberg have the option to select between a fixed or dynamic layout for table blocks, but this has no effect.",Roenbaeck
Future Releases,56554,Twenty Eleven: Width issue in Button block,,Bundled Theme,6.0.2,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2022-09-12T08:14:21Z,2023-03-22T00:07:02Z,"In Twenty Eleven Theme, when we add Button block in editor side and change the Width settings of Button, we can see that the Width is not reflected in editor side.
Steps to replicate:
1: Activate the Twenty Eleven Theme
2: Add Button block
3: Choose Width from Width settings
4: View the page/post at editor side
5: Save Page/Post
6: View the page/post at front side
For better understanding I provide video attachment link.
Video link: https://share.cleanshot.com/SPJat9VXVPA8lMQUfZlD
Thanks",kajalgohel
Future Releases,46771,Twenty Eleven: Negative values for padding,,Bundled Theme,4.9.8,normal,minor,Awaiting Review,defect (bug),new,dev-feedback,2019-04-02T12:27:37Z,2023-11-08T09:50:29Z,"Line 2799
#ie7 article.intro Value Error : padding-left -7.6% negative values are not allowed : -7.6%
Line 2800
#ie7 article.intro Value Error : padding-right -7.6% negative values are not allowed : -7.6% ",Malae
Future Releases,56525,"Twenty Eleven: Font-style issue of ""Add Citation"" text in Pullquote Block",,Bundled Theme,6.0,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2022-09-07T08:18:14Z,2022-09-08T13:26:13Z,"In Twenty Eleven Theme, when we add Pullquote block in editor side, We can see that the font-style of ""Add citation"" text is Italic. But when we see the same Pullquote block at front side, font-style for ""Add citation"" text is not reflected, It is display normal.
Steps to replicate:
1: Activate the Twenty Eleven Theme
2: Add Pullquote block
3: Enter some Text for ""Add quote""
4: Enter some Text for ""Add citation""
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/yoxXVomU1svauo5FmF9G
Thanks",kajalgohel
Future Releases,58127,Twenty Eleven: Add escaping as per the WordPress VIP standards,,Bundled Theme,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2023-04-13T14:48:47Z,2023-06-09T17:37:15Z,"In the Twenty Eleven theme folder, the file named search.php has improper escaping on line number 21 as per the VIP standard.
Issue screenshot:
[https://share.cleanshot.com/3rPjnj33GHPcFfyL0rKh]
The present line of code
{{{
printf( __( 'Search Results for: %s', 'twentyeleven' ), '' . get_search_query() . ' ' );
}}}
Improve line of code:
{{{
printf( esc_html__( 'Search Results for: %s', 'twentyeleven' ), '' . esc_html( get_search_query() ) . ' ' );
}}}",himshekhar07
Future Releases,58375,Turn comments off by default for attachment pages (or make is easier to do so without code),,Comments,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2023-05-22T14:49:42Z,2023-05-25T07:09:59Z,"If a new user is installing WordPress the first time, it lasts some time until the first spam comment appears. Typically, they now disable comments on **Settings -> Discussion**.
First problem: this is just disabling the comments for ''future'' posts.
Now they learn about bulk editing posts, which works fine.
But the website is now online for some time and more media is uploaded, and now the spam comes to the next open comment form: **on attachment pages**.
Not sure if attachment pages follow the setting from the discussion page, but there will be many media items with open comments.
Now we have the second problem: On the grid view, there is no way to disable the comments at all (you need to follow a link to get to the single media edit page).
On this page you need to customize the screen options to enable the meta box, and now you can disable the comments for ''this'' media item. This has to done manually for every media item with open comments (but there is no way to see if the comments are open - so you need to edit every media item).
This could be a real pain for websites with many media items.
**I would recommend changing the behavior and have comments on attachment pages turned off by default.**
I think it will be easier to educate theme developers to turn them on again if the theme uses them (e.g. photography themes) as documented here:
https://make.wordpress.org/core/2015/07/06/comments-are-now-turned-off-on-pages-by-default/
This is already discussed in the comments on this post.
Related tickets: #12991 and #21391
Another way could be to use the idea of this comment:
https://core.trac.wordpress.org/ticket/12991#comment:22
If turning the default to off is not possible, we could use the bulk edit to enable/disable the comment/pingback/trackback feature.
The need for such a feature could be seen in the plugin directory, as there are more than one plugin for disabling comments on attachment pages (and more):
https://wordpress.org/plugins/disable-comments/
https://wordpress.org/plugins/smart-attachment-page-remove/
https://wordpress.org/plugins/disable-comments-rb/
https://wordpress.org/plugins/comments-plus/
https://wordpress.org/plugins/disable-comments-on-attachments/
https://wordpress.org/plugins/disable-comments-by-click5/
https://wordpress.org/plugins/no-page-comment/
https://wordpress.org/plugins/stop-media-comment-spamming/
https://wordpress.org/plugins/disable-comments-wpz/
https://wordpress.org/plugins/disable-post-comments/
https://wordpress.org/plugins/close-comments-on-media-attachment/
These add up to more than a million active installations.",zodiac1978
Future Releases,36956,Trigger event when taxonomy term is added with ajax,,Taxonomy,,normal,normal,,enhancement,new,dev-feedback,2016-05-26T22:33:28Z,2019-06-04T21:23:34Z,"When adding a taxonomy term via ajax, it would be nice if some JavaScript event was triggered, maybe on `.wp-list-table.tags` or the newly added row itself.
This would give taxonomy term plugins some event to listen for and take action on.
Something akin to:
{{{
this.trigger( 'term-added' );
}}}
Maybe `tag-added` is more appropriate, since all of those form elements seem to use `tag` for everything, regardless of the taxonomy.",johnjamesjacoby
Future Releases,45389,trackback_url_list() trackback excerpt for multibyte correspondence,SergeyBiryukov,Pings/Trackbacks,,normal,normal,Future Release,defect (bug),reviewing,needs-unit-tests,2018-11-21T08:15:18Z,2019-01-16T02:57:17Z,"In the case of multibyte, the last letter of the trackback excerpt may be garbled.",ishitaka
Future Releases,53252,Track WP-CLI version in Site Health,wpscholar,Site Health,5.8,normal,trivial,Awaiting Review,enhancement,assigned,dev-feedback,2021-05-21T18:32:45Z,2022-09-05T21:20:07Z,"Currently, there is no data about WP-CLI in Site Health. Assuming that WP-CLI is present, we should display the version number in the Site Health info tab.",wpscholar
Future Releases,53184,Toolbar Enhancements: turn off labels / disable plugins / auto-hiding,,Toolbar,,normal,normal,Awaiting Review,feature request,new,dev-feedback,2021-05-11T16:48:44Z,2021-07-14T00:10:19Z,"Something that can get pretty crowded quickly is the Toolbar. I have three suggestions for improving this:
- The option to turn on/off text labels next to the icons
- The option to disable / enable certain plugins to add things to the toolbar
- The option to enable / disable auto-hiding, where the toolbar hides until you move your mouse up (similar to what lots of people use with their Mac's dock)
I'd love to hear your thoughts.",tomjdevisser
Future Releases,45062,tinyMCE editor breaks captions with HTML,,Editor,4.9.8,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2018-10-06T23:13:04Z,2019-12-19T14:27:07Z,"This looks similar to ticket #18311
If I enter HTML into an image caption (eg. , and then in tinyMCE I switch from Text to Visual, my caption breaks; sometimes it is reformmatted, sometimes the caption shortcode is removed.
Test caption:[[br]]
[[br]]
Label Description [[br]]
Text More text [[br]]
",iantresman
Future Releases,10660,Time zone suggester based on nascent WordPress.org API call,rmccue,Date/Time,2.8.4,normal,normal,Future Release,feature request,assigned,dev-feedback,2009-08-20T05:59:42Z,2019-09-02T06:45:02Z,"The attached patch uses a new API call to http://api.wordpress.org/core/ip-to-zoneinfo/1.0/ to retrieve a suggested time zone based on client (not server) IP address.
A button is added next to the existing dropdown list of time zones providing the option to ""Suggest a time zone"". This calls the API using an AJAX/JSONP request which then auto-selects a time zone for the user from the dropdown.
Visual feedback is via a spinner when fetching and then a text response.
Additionally the Date and Time settings have been split out to a new settings page.
Related ticket: #10324",sambauers
Future Releases,46846,Tight comparisons and use of Yoda conditions are not consistent,,Formatting,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2019-04-09T11:30:29Z,2019-04-09T11:30:29Z,"In `wp-includes/formatting.php`, as I have seen comparisons and use of Yoda conditions are not consistent through out the file. I have made some changes and uploading a proposed patch here. Let me know if this helps!",subrataemfluence
Future Releases,23060,Throw 404 if URL Rewriting is Used With Default Permalinks,,Permalinks,3.5,normal,normal,Awaiting Review,enhancement,reopened,dev-feedback,2012-12-26T20:54:55Z,2019-04-19T15:21:06Z,"Suddenly I discovered that my blog is not returning error 404 page. My blog permalink is set as default style http://test.onetarek.com/?p=123
Now I am trying to create 404 error by using this url http://test.onetarek.com/adsfjkasjdd , it showing home page. Then I tested http://test.onetarek.com/?p=123654 now it shows 404 page.
Then I tried to load a not existing image http://test.onetarek.com/wp-content/themes/twentyeleven/images/headers/not-image.jpg it shows my home page instead of 404 page.
I changed my permalink settings to ""Day and name"" then it show 404 page.
I tested this problem in my another blog, this blog is return 404 page but that is not generated by wordpress. Wordpress 404 theme page is not being loaded. A blank page is being loaded with a message by Apache Server ""Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request....""
So what is the problem with permalink settings and 404 page.",onetarek
Future Releases,43360,Third parameter for get_option function to return default value instead of empty string,,"Options, Meta APIs",4.9.4,normal,normal,Awaiting Review,enhancement,new,close,2018-02-19T21:47:16Z,2022-05-26T10:20:04Z,"`get_option($option, $default = false)` function returns empty string if the required field exist but doesn't contain any value e.g. NULL or empty string.
For example, there is an option field 'test' exist in the option table but without any value(NULL or empty). Now `get_option('test', 'Hello World')` function will return an empty string as it is; from the database but developer may be expecting ""Hello World"" in return.
To avoid this situation third parameter may be introduced for `get_option()` function which will decide to return NULL/empty-string or default value. Here is my proposed solution
`get_option( $option, $default = false, $return_null = true)`
Now calling `get_option('test', 'Hello World', false)` function for above problem will return default value which is '''Hello World'''.
wp-includes\options.php file requires little changes to address the above enhancement.",farhan.noor
Future Releases,13816,There should be built-in index pages for taxonomies,,Taxonomy,,normal,normal,Future Release,feature request,new,dev-feedback,2010-06-10T12:20:29Z,2023-01-31T20:36:11Z,"By default, if you enable 'pretty' permalinks, you get URLs like this for categories and tags: /category/slug, /tag/slug. The same pattern is used when adding custom taxonomy types.
These URLs often suggest to people that it should be possible to go 'up' one level, and access index pages at /category and /tag which list all of the available categories or tags (or maybe just the top x most popular ones for tags).
I'd suggest that we add a new template type of is_archive_index() which uses, in order of preference, taxononmyname-index.php (eg category-index.php), archive-index.php.
Within these templates, the 'loop' should return taxonomy items rather than posts.
This is all possible already using custom templates and get_terms(), but it'd be handy if it was built-in.
",frankieroberto
Future Releases,29009,"There should be a capability for ""publish private posts""",,Role/Capability,3.9.1,normal,normal,,enhancement,reopened,dev-feedback,2014-07-23T15:48:00Z,2019-06-04T21:12:02Z,"I've been working on a simple membership site with only two membership levels: logged in and logged out, which is a situation that theoretically could be easily managed in WP without any plugins. However, logged in members should not be able o post publicly, while they are allowed to post whatever they want inside the membership walls, so the review system doesn't help in this situation either.
Currently, I have to use a custom post type and force the status to private on publishing with a plugin to achieve the intended scenario.
But I think the most parsimonious solution would be to include a capability that would allow people to ""publish_private_posts"" yet not ""publish_posts"".",t.schwarz
Future Releases,49429,There seems to be no way to check query value for NULL,,Query,5.3.2,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2020-02-14T04:56:53Z,2020-02-14T12:29:13Z,"NOT EXISTS and EXISTS both don't do what I want
I want to check `WHERE meta_value IS NOT NULL`
exists does this, applied to meta field
related_post_id2:
`
""where"" ""mt5.meta_key = 'related_post_id2'""
""join"" "" INNER JOIN wp_2_postmeta AS mt5 ON ( wp_2_posts.ID = mt5.post_id )""
`
that is not what I want
NOT EXISTS does:
`
""where"" ""mt5.post_id IS NULL""
""join"" "" LEFT JOIN wp_2_postmeta AS mt5 ON (wp_2_posts.ID = mt5.post_id AND mt5.meta_key = 'related_post_id2' )""
`
well, thats not what I want either, because now it checks ""if there is a row with related_post_id2"".
I want
""A row where the meta_value is not null""
in reality what I want is
Any entry, that has:
No value for related_post_id2
empty string for related_post_id2
or
null for related_post_id2
does that make sense?
",Jossnaz
Future Releases,26695,Themes: add support for multiple screenshots in themes,,Themes,3.8,normal,normal,Future Release,enhancement,new,dev-feedback,2013-12-20T20:08:43Z,2020-08-14T05:06:12Z,"We left this out from the THX merge due to priorities. Let's bring them back.
Previously: #20546.
* Method to get an array with all the screenshots with a maximum of 5.
* Pass this data to {{{wp_prepare_themes_for_js}}}.
* Adjust template to loop through all the screenshots (if available) and render them.
* Set up a simple JS gallery with thumbnails on the detailed view of a theme.
Array begins with screenshot.png as the first item, then continues with screenshot-2.png.",matveb
Future Releases,59538,Theme update message showing user wrong theme popup,,Themes,6.3.2,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2023-10-04T11:47:21Z,2023-10-06T11:54:22Z,"When you are updating the theme and another theme popup is opened then the theme updated message shows on the opened popup twice message.
Video link: https://www.awesomescreenshot.com/video/21305588?key=95614ad9bc790ca5d1a26fa52a2e75e9",praful2111
Future Releases,39167,Theme mods should be able to be gotten/changed on inactive themes.,,Themes,2.1,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2016-12-07T22:37:54Z,2019-03-15T02:06:13Z,"Currently, there is no way (short of direct option queries) to get theme mods of an inactive theme. This can be problematic when a user wants to see what changes they had configured on a parent theme, when on a child theme, or when trying to see the other theme mods they had configured elsewhere.
This change moves the bulk of the theme mod functions to be methods on the `WP_Theme` class -- so if you `wp_get_theme()` any theme -- active or inactive -- you can view and change its mods.
The attached changeset also converts the existing legacy methods to use the new versions on the current theme.
Related: [4401]",georgestephanis
Future Releases,29555,Theme details allowed HTML,,Themes,3.9,normal,normal,,defect (bug),new,dev-feedback,2014-09-06T11:50:17Z,2019-06-04T21:12:13Z,"Theme authors can use some HTML in their theme's style.css Description (and Theme Name and Author). If I'm not wrong, sanitize_header() in WP_Theme class sets the allowed HTML tags and attributes and for Description they are:
{{{
'a' => array( 'href' => true, 'title' => true ),
'abbr' => array( 'title' => true ),
'acronym' => array( 'title' => true ),
'code' => true,
'em' => true,
'strong' => true,
}}}
This works in the installed themes browser, where theme details are grabbed from the theme's style.css. But in the theme install views, where theme details come from WordPress.org API, some HTML tags (for example ""a"") are completely stripped out (don't know if this is intentional) while others (for example ""abbr"") are not unencoded before being used as HTML in the view and they end up being displayed as plain text, even in the WordPress.org site (see the last two screenshot).
I've found the someway related #27641 but please notice HTML is returned by the API already encoded so even using triple braces `>` etc. will still be `>`
Installed themes browser:
[[Image(http://i.imgur.com/B9TdIUa.png)]]
Themes install:
[[Image(http://i.imgur.com/JoP1yjp.png)]]
WordPress.org themes site:
[[Image(http://i.imgur.com/fyYmdeK.png)]]",afercia
Future Releases,42486,The Tools screen is blank for users who cannot manage categories or tags,,Administration,4.9,normal,normal,Awaiting Review,defect (bug),assigned,dev-feedback,2017-11-09T17:05:12Z,2024-01-17T17:05:15Z,"Since Press This was removed in #41689, the Tools screen is only composed of the Categories and Tags Converter.
For users who can't manage categories or tags (Authors and Contributors), the Tools screen is now completely empty. Subscribers currently don't see the Tools admin menu item.
The Tools admin menu item should be removed if there's nothing to display on it.",johnbillion
Future Releases,18322,The Road to Magic Quotes Sanity,jorbin,Bootstrap/Load,3.2.1,normal,normal,Future Release,defect (bug),reopened,dev-feedback,2011-08-03T20:26:25Z,2023-06-26T20:19:27Z,"For back compat reasons, wp_magic_quotes() performs addslashes() on GPCS data. This is a pain, especially given that some core API expects slashes and some doesn't. In hopes of someday losing the automatic GPCS slashing, let's introduce a flag to turn off the slashing as well as slash and unslash functions that consult the flag. If slashing is on, these functions add and strip slashes. If slashing is off, they return data unchanged. Plugin authors can start using these functions and testing their code with GPCS slashing turned off and on. Eventually, GPCS slashing would default to off and all calls to the slash and unslash functions could be removed from core.",ryan
Future Releases,59802,The quote block Add Citation text color issue into the theme Twenty Fifteen,,Themes,6.3.2,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2023-11-03T09:51:33Z,2023-11-03T09:51:33Z,"Hello Team,
I have worked on the **""Quote""** block and found that its ""Add Citation"" text color is not changed when we try to set it from the block setting.
Here, I have attached its video.
**Issue: [https://share.cleanshot.com/c5VnwHz1Qt34NPXcHw9f]**
Thanks,",viralsampat
Future Releases,59801,The pullquote block text color and border issue into the theme Twenty Fifteen,,Themes,6.3.2,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2023-11-03T09:43:15Z,2023-11-03T09:43:15Z,"Hello Team,
I have worked on the **""Pullquote""** block into the ""Twenty Fifteen"" theme and found that the text color for admin is not changed.
Here, I have attached its video.
**Issue: [https://share.cleanshot.com/2QPVLc7H737ghxjw8lft]**
Thanks,",viralsampat
Future Releases,48265,The privacy export files cleanup can run unlink on directories throwing an error.,,Privacy,4.9.6,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2019-10-09T18:02:19Z,2021-11-24T09:25:40Z,"Looking into some test failures on VVV flagged in Slack here;
https://wordpress.slack.com/archives/C02RQBWTW/p1570445063460400
It was found that the `wp_privacy_delete_old_export_files` function runs `unlink` on all files and subdirectories older than `wp_privacy_export_expiration`, this becomes an issue as directories can't be removed via `unlink` and will throw an Operation is not permitted error.
This occurs as the `$export_files` list is collected from a `list_files` call which has a level of 100 resulting in subdirectories being included.
So the question for me is should the export cleanup only do files in the current `$export_dir`, or should it recurse into subdirectories and if so should the directories also be cleaned up if older than `wp_privacy_export_expiration`. If we do go to the extent of removing subdirectories should the `list_files` call be updated with an exclude filter so plugins can have custom directories in that location which would be avoided during the cleanup?
Note: If subdirectories are to be removed as well we'll have to recursively traverse them and remove their contents so `rmdir` will work.
Along with addressing the issue in `wp_privacy_delete_old_export_files` the cause of the original VVV test failures should also be addressed. What lies in the privacy unit test that creates the test_contents folder but doesn't clean it up here;
https://github.com/WordPress/wordpress-develop/blob/master/tests/phpunit/tests/privacy/wpPrivacyGeneratePersonalDataExportFile.php#L244
* simply removing this directory at the end of the test should suffice.",garrett-eclipse
Future Releases,54983,The post has already been deleted.,,"Posts, Post Types",5.4,normal,normal,Future Release,defect (bug),new,dev-feedback,2022-01-29T04:22:49Z,2022-10-07T21:37:04Z,"Hi,
One big issue on 5.9 . when i have deleted post then still on post page & getting error message ""The post has already been deleted."". So i think after delete post need to redirect page on post list?
More infomation you can see below mentioned quick video.
https://www.loom.com/share/616020077274422c8d90771034d22aff",sumitsingh
Future Releases,43893,The maybe_create_table() function has two definitions,,Database,,low,normal,Awaiting Review,defect (bug),new,dev-feedback,2018-04-28T14:22:56Z,2020-09-01T16:05:56Z,"The `maybe_create_table()` function has two definitions:
1. https://github.com/WordPress/wordpress-develop/blob/c71a898f784d8435c07bcf9ec9e30560dd3abe19/src/wp-admin/includes/upgrade.php#L2187-L2219
2. https://github.com/WordPress/wordpress-develop/blob/c71a898f784d8435c07bcf9ec9e30560dd3abe19/src/wp-admin/install-helper.php#L40-L70
The latter is contained within a `function_exists()` check, but this still means the function's behaviour can differ depending on which definition happens to load.
The function is not used at all in WordPress core. It (they?) should probably be deprecated.",johnbillion
Future Releases,55878,The Manage Themes Screen Needs to Indicate Clear User Actions,,Themes,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2022-05-30T19:34:11Z,2022-05-31T23:13:04Z,"**What problem does this address?**
A new user might not understand the difference between uploading a theme and browsing the theme repository. To make it easier for new users to use WordPress, user actions should be clearer.
**What is your proposed solution?**
[[Image(the-problem_add-new-theme.png)]]
- The Add New isn't descriptive of the action the user should it. The text on the button should be changed to ""Browse WordPress Themes"".
- Manage Themes should be changed to My Themes to indicate to the user these are the themes they have installed on their website.
- A button should be added that allows the user to upload a theme. It should say ""Upload Theme"".
- The button that says ""Add New Theme"" should be changed to ""Browse WordPress Themes"" so the user understands the button is not for uploading WordPress themes but to browse themes.
Originally posted here: https://github.com/WordPress/gutenberg/issues/41244",deborah86
Future Releases,58884,"The image size for the Site Logo block is hard coded to ""full""",audrasjb*,General,,normal,normal,Awaiting Review,enhancement,accepted,close,2023-07-23T19:41:10Z,2023-09-20T08:27:57Z,"The recommended size for the site icon is 512x512.
The Site Logo block is coded to use the ""full"" size, in general-templates.php:
{{{
$image = wp_get_attachment_image( $custom_logo_id, 'full', false, $custom_logo_attr );
}}}
If the icon is at the recommended size of 512x512, the full size is much too big for the common use of the Site Logo block (in the header). That leads to a ""Properly size images"" warning in page-speed tools.",asafm7
Future Releases,55996,the get_the_block_template_html call all the same functions as the the_conent filter so they are run twice,flixos90,Formatting,,normal,normal,Future Release,defect (bug),assigned,dev-feedback,2022-06-16T22:23:50Z,2024-03-13T15:42:08Z,"In get_the_block_template_html we have this code
{{{#!php
run_shortcode( $_wp_current_template_content );
$content = $wp_embed->autoembed( $content );
$content = do_blocks( $content );
$content = wptexturize( $content );
$content = convert_smilies( $content );
$content = shortcode_unautop( $content );
$content = wp_filter_content_tags( $content );
$content = do_shortcode( $content );
$content = str_replace( ']]>', ']]>', $content );
}}}
These are direct calls to the same functions as used by the filter the_content
{{{#!php
Library, the ""site_icon"" option isn't deleted from the database. Note the option is deleted if you go Appearance > Customize and remove the icon through the Site Identity tab.",henry.wright
Future Releases,42695,Text Widget: hard-coded width/height attributes are stripped from iframes,,Widgets,4.9,normal,normal,Future Release,defect (bug),new,dev-feedback,2017-11-25T04:30:54Z,2018-05-02T15:01:49Z,"hi when i update my WordPress 4.9 my exiting iframe size in text widget not working.please find my [http://dubaicarmelschool.com/] and iframe code below:
",dubaicarmelschool
Future Releases,27307,Text Widget size spill over the side of Widget Container in random width.,,Widgets,3.8.1,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2014-03-06T22:41:03Z,2017-05-26T13:45:11Z,"About 75 percent of the time when I add a text widget item to a widget area. The widget spills over the left side of the area. See Screenshot http://cl.ly/image/3Y363s242a3y
What is odd about this is that it only happens sometimes and it has randomly width that it spills over as well. See additional screenshot. http://cl.ly/image/3H3X371R0n3l
If you expand the browser window the widget size actually expands as well. But seems to keep what ever margin it had on the left constant. Have another screenshot here from my trunk build. http://cl.ly/image/3E203q083Z3V
I tried a search in Widgets for trac and couldn't find anything related. If this is proper UI for widgets it does seem a little random to me.
",RDall
Future Releases,38863,Text change when activating a theme,,Themes,,low,minor,Awaiting Review,enhancement,new,dev-feedback,2016-11-19T02:43:03Z,2022-06-10T05:43:12Z,"When switching themes, after activating we see:
New theme activated. Visit site
[/wp-admin/themes.php?marks=168#L168, /wp-admin/themes.php, L.168]
Because it needs not to be a NEW theme, I suggest the following:
''Theme changed and activated succesfully.'' ",Presskopp
Future Releases,54420,Tests: Mock REST API remote requests,hellofromTonya,Build/Test Tools,,normal,normal,Future Release,defect (bug),reopened,dev-feedback,2021-11-11T15:43:01Z,2022-10-10T13:18:47Z,"Recent timeout failures ([https://github.com/WordPress/wordpress-develop/runs/4174016878?check_suite_focus=true see GitHub failed job]) of specific REST API tests show some tests are not mocking the remote requests. These requests can be mocked with a callback hooked into `'pre_http_request'` filter.
Each test should be reviewed to determine:
* If a remote request to a live API endpoint is being made
* If those specific requests should/can be mocked
* and then mocks created for each in its context of the condition under test
Ideally a mocking strategy could be created to abstract the heavy lifting and make it easier for these tests to mock the requests.",hellofromTonya
Future Releases,53010,Tests: introduce namespacing for the test classes,hellofromTonya,Build/Test Tools,,normal,normal,Future Release,task (blessed),assigned,dev-feedback,2021-04-09T15:51:13Z,2024-03-15T08:10:07Z,"Introducing namespaces in the production code for WordPress Core is a hot topic, so I very purposely do NOT want to touch that in this ticket.
However, for the test suite, which doesn't get shipped with the WordPress production code, it's a whole other matter.
== Benefits
Using namespaces in the test suite provides us with the following benefits:
1. If used consistently and providing they follow a set pattern (more about this below), they will make it very easy for contributors to find the test files/classes they are looking for.
2. It will allow for shorter file and test class names, while those will still be descriptive.
3. And... it will allow for mocking PHP native functions by declaring a namespaced version of that same function in the test class.
4. It will also allow more easily for multiple test classes to be created to test one particular feature/function, which the current naming scheme does not allow for. This will allow for tests for the same functionality, but which need different fixtures (setup/teardown) to be encapsulated in their own test classes.
== Caveats:
As the WordPress Core test suite is used not only by Core, but also by plugins and themes for integration tests, the test class namespacing should be reserved for actual test classes and - for now - not be applied to test utility classes / Abstract base test classes (i.e. the `tests/phpunit/includes` directory should NOT be touched for now).
== Proposed pattern
The current directory structure for tests is, to put it mildly, confusing and inconsistent.
To solve that, I would like to propose the following pattern:
* File paths: `tests/phpunit/tests/wp-[includes|admin]/[SubFolder/]*Class_Under_Test/FunctionUnderTest[OptionalSubsetIndicator]Test.php`
* Namespace: `WordPress\Tests\WP_[Includes|Admin]\[SubFolder\]*Class_Under_Test`
* Classname: `FunctionUnderTest[OptionalSubsetIndicator]Test`
For WP Core files which only contain functions outside of a class structure, the following pattern is proposed:
* File paths: `tests/phpunit/tests/wp-[includes|admin]/[SubFolder/]*Functions_FileName/FunctionUnderTest[OptionalSubsetIndicator]Test.php`
* Namespace: `WordPress\Tests\WP_[Includes|Admin]\[SubFolder\]*Functions_FileName`
* Classname: `FunctionUnderTest[OptionalSubsetIndicator]Test`
The pattern I'm proposing does imply a re-organisation of the test suite directory and file structure, but that IMO is for the better.
It also follows a PSR4-like pattern which will be more intuitive for new contributors to work with, as well as follow the PHPUnit recommended test class name pattern with having the `Test` as the end of the class name.
This will also allow for using PSR-4 autoloading for the tests classes and adding the `autoload-dev` directive to the `composer.json` file.
== Planning
This should be regarded as a small project and not all renaming needs to be done at the same time.
New tests should start following the above proposed pattern as soon as consensus has been reached about this proposal.
Existing tests can be gradually switched over to the new pattern over time.
== Additional tasks associated with this project
- [ ] Updating the contributors handbook for Core.
- [ ] Verify that the WordPressCS sniffs will validate this pattern correctly.
- [ ] Write a Make post about the decision once consensus has been reached.",jrf
Future Releases,57586,term_exists() return type not consistent regarding wp_insert_term(),,Taxonomy,3.0,normal,normal,Future Release,enhancement,new,dev-feedback,2023-01-30T10:14:03Z,2023-09-15T03:57:43Z,"`term_exists()` returns an array of strings containing `term_id` and `term_taxonomy_id`. Although `wp_insert_term()` as well as `wp_update_term()` return an array of integers.
For consistency, it'd be better to return alway the same type. Also, it'd be less error prone.",hugod
Future Releases,27425,Templates For Posts Formats,,Post Formats,,normal,normal,,enhancement,new,dev-feedback,2014-03-15T18:16:18Z,2019-06-04T20:46:12Z,"If I opt to use Custom Post Templates, then I can easily put a custom post template by putting a file named single-[name of the custom post], but that same feature is not available for the post formats.
I love the post format feature in WordPress, and people just don't want to use that for some reasons, but this would really attract some of the audience to use the post formats.
For example, a post with Audio format will first look for single-audio.php or single-audioformat.php or anything cuz it single-audio.php may effect the Audio Custom post type.
What do you guys think of this idea?",hardeepasrani
Future Releases,23049,Template hierarchy for 404,johnbillion*,Themes,,normal,normal,Future Release,enhancement,accepted,dev-feedback,2012-12-22T17:19:05Z,2017-09-27T16:09:23Z,"load 404-{post-type}.php when url structure matches post permalink structure but there is no post at that address.
load 404-{taxonomy}.php when url structure matches taxonomy permalink structure but doesn't match any specific taxonomy tag URL.
And so on....
The idea is to have different 404 pages based on the context to which the URL refers. For example if a site has a blog and a shop it might be better to show a blog specific 404 page when the URL might be interpreted as a post and a shop specific 404 page when the URL might be interpreted as a product.",mark-k
Future Releases,37914,Taxonomy: Allow terms to be previewed before publishing,,Taxonomy,4.7,normal,normal,Future Release,enhancement,new,dev-feedback,2016-09-01T20:40:31Z,2019-06-04T21:26:08Z,"There is currently no mechanism to preview or draft taxonomy terms. As soon as a draft post with new terms is saved, for example, the new term is published, visible to other users in wp-admin, and could be visible on the front end of the site depending on the theme and plugins.
The lack of a draft or preview mechanism also makes it impossible to manage terms in the customizer. Long term, the goal is to enable posts and terms to be able to be live-previewed with front end context, based on functionality being developed in the [https://github.com/xwp/wp-customize-posts Customize Posts] and, now, [https://github.com/xwp/wp-customize-terms Customize Terms] plugins.
In 4.7, with the new ability to create posts wintih nav menus (#34923), we'd like users to also be able to create terms so that they an set up their site structure. Unfortunately this is not possible until we have a mechanism for previewing terms. I'm currently milestoning this for 4.7 so that we can try to add support for that feature (in a separate ticket), but this ticket is for API support only and still may be more than we can complete in time for 4.7.
Based on comments from @boonebgorges on #34923, there are a couple of potential approaches for enabling term previewing:
- Introduce a `term_status` field
> Even if we don't have anything as robust as a ""term status API"", we still have to be sure that, at the very least, term_status != 'publish' terms are excluded from most queries - a change that has the potential for weird back compat issues.
- An internal taxonomy for draft terms, which may be more conservative but also more complex, especially if we want to support things like hierarchy for draft terms.
> It may be easier (maybe more code, but fewer hacks) to do on-the-fly registration of a separate internal taxonomy for each taxonomy that's getting a draft term added via the Customizer.
We'll want a future-proof solution that can support term meta being previewable as well. `auto_draft` posts are the inspiration on the posts end for the customizer approach.",celloexpressions
Future Releases,54521,Taxonomy term quick edit does not save if taxonomy has non latin characters,,Taxonomy,5.8.2,normal,normal,Future Release,defect (bug),new,dev-feedback,2021-11-26T11:52:46Z,2022-10-07T21:33:25Z,"This issue started from the following WooCommerce ticket
https://github.com/woocommerce/woocommerce/issues/31037
After investigating, I could reproduce the issue by doing the following
- Register a new taxonomy that contains Greek character `wp_ελληνικό_tax`
-
{{{
register_taxonomy( 'wp_ελληνικό_tax', array( 'post' ), $args );
}}}
- Create a term
- Edit the term through quick edit
[[Image(https://user-images.githubusercontent.com/2484390/141967192-60de334d-e5ec-437e-9574-3cd9aa30110c.png)]]
(for a strange reason, I cannot make the image appear inline)
- You'll get a `0` error, with no indication
- If you edit the term through the normal edit (not quick edit) it works fine.
I already have a suggestion on how to fix this error
https://developer.wordpress.org/reference/functions/wp_ajax_inline_save_tax/
This **wp_ajax_inline_save_tax** function, sanitizes the taxonomy, and `wp_ελληνικό_tax` becomes `wp__tax`, which doesn't exist. (hence the 0 error)
Why is the taxonomy needed? Cause currently, it calls `get_term` , passing `term_id` and `taxonomy_slug`.
Instead, what we could do is
- avoid sanitizing the taxonomy slug, seems like there is no need
- try and get the tag/term earlier, by calling `get_term` with just the `term_id` (as `term_id` is unique, regardless of the taxonomy it belongs to)
I have attached a revised version of this function
{{{#!php
taxonomy;
$wp_list_table = _get_list_table( 'WP_Terms_List_Table', array( 'screen' => 'edit-' . $taxonomy ) );
// $tag = get_term( $id, $taxonomy );
$_POST['description'] = $tag->description;
........
.......
}
}}}
If agreed, I'd like to work on this issue and do my first contribution on WordPress.
Panos Synetos
Code Wrangler @ Automattic
",panagiotis.synetos
Future Releases,50047,Taxonomy parent select field not cleared after creating category,,Taxonomy,5.4,normal,minor,Awaiting Review,defect (bug),new,dev-feedback,2020-05-01T15:25:33Z,2020-05-01T16:53:13Z,"When creating a new category in the create category view and a parent is selected, the parent selector field is not reset to ""None"" after successful submission.
The same is true for custom select fields added to this view.
Don't know if this behavior is on purpose but IMO doesn't make sense?",wordnixe
Future Releases,29418,Taxonomy archive query not including all of its post types.,SergeyBiryukov,Taxonomy,3.9.2,normal,normal,Awaiting Review,defect (bug),reviewing,dev-feedback,2014-08-28T15:37:46Z,2020-05-06T21:00:39Z,"I've noticed this in a project i'm working on.
I did some digging in '''wp-includes/query.php''' file, and found that this is the issue.
In '''3.9.2 files''', in line '''2501''' there's this
{{{
foreach ( get_post_types( array( 'exclude_from_search' => false ) ) as $pt ) {
}}}
Not sure if this is intended or not, maybe yes, but the query var name is missleading in this case, which is also excluding the post type from its taxonomies archives too.
In any case, if this is to be fixed, and in fact is not supposed to be here, just changing the line for this should work, as we should expect.
{{{
foreach ( get_post_types( array() ) as $pt ) {
}}}
Hope this helps, thanks.",msaggiorato
Future Releases,9547,Taxonomy - interesting 'unused' term_order column in table term_relationships.,,Taxonomy,2.8,high,normal,Future Release,enhancement,assigned,dev-feedback,2009-04-16T15:19:42Z,2023-11-28T19:15:17Z,"During development of plugin [http://wordpress.org/extend/plugins/xili-language/ xili-language], and to sort term by term list of languages in a taxonomy, I discover unused column '''term_order''' in ''term_relationships'' table and lack of functions in core about this column. Like medias in post, here the user can define languages list with first, second, third,... languages for his website (and xml header). Taxonomy tools are here very powerful without adding tables or annoying coding.
([http://plugins.trac.wordpress.org/browser/xili-language/tags/0.9.8.2/xili-language.php see code here line 1309-1370]).
Before to complete these very basic functions,…
Is it forecast to have more basic / generic functions using '''term_order''' in taxonomy.php ?
[http://core.trac.wordpress.org/ticket/9546 Related ticket]",michelwppi
Future Releases,45107,Taxonomies should only be allowed to support one object type,,Taxonomy,,normal,normal,Awaiting Review,enhancement,new,needs-unit-tests,2018-10-17T16:48:28Z,2019-02-12T21:00:32Z,"Currently, taxonomies can be registered to any object type (posts, comments, users, etc.). But core does not enforce a one to one limit for object types to taxonomies, which can be problematic.
For example, if a taxonomy is registered to both users and posts, there can be unintended consequences. Adding a term to a post with an ID of 3 would also cause a user with an ID of 3 to have that term. Removing that term from the user would also affect the post. Unique IDs are only enforced on a per object type basis, not accross all types.
The approach here would be to introduce a `_doing_it_wrong()` notice (and possibly even return a `WP_Error`) when a taxonomy is registered to multiple object types.
**Good:** `register_taxonomy( 'custom_tax_name', array( 'post', 'page', 'cpt' ) );`
**Bad:** `register_taxonomy( 'custom_tax_name', array( 'post', 'user' ) );`
== Why ==
Adding this to Core would open the door for the following potential features:
- `WP_Tax_Query` support could be added to users (see #31383), comments, etc.
- Built-in fields for taxonomy could be added to the REST API for users, comments, etc.
- UIs could be added for users (also see #31383), comments, etc.
== Backward Compatibility ==
To continue supporting backward compatibility for sites that are registering a taxonomy for multiple object types, `register_taxonomy()` could continue working as is. The only change would be to return a `WP_Error` and a `_doing_it_wrong()` notice.
In the future, `register_taxonomy()` could be changed to only register objects with the same type as the first specified object type.
Example: `register_taxonomy( 'custom_tax_name', array( 'post', 'user', 'page' ) );` would only register the taxonomy for posts and pages (same object type).",desrosj
Future Releases,12056,"target=""_blank"" being stripped from Profile Bio and Category Description",,Formatting,2.9.2,normal,normal,Future Release,enhancement,new,dev-feedback,2010-01-27T16:50:00Z,2019-10-29T11:02:01Z,"Many apologies if this is a duplicate. I have searched but did not find it yet posted.
I noticed that target=""_blank"" is being stripped from my ""a href"" tags my profile ""Biographical Info"" field even though the ""a href"" with the URL and closing tag still remain. It happens every time I save my profile.
This was independently verified.
It is a regular wordpress install running 2.9.1 (not wordpressmu, etc.).
My original thread can be found here:
http://wordpress.org/support/topic/355388?replies=1",lovewpmu
Future Releases,47352,Take into account the current admin email address when rate limiting the recovery mode email,,Site Health,5.2,normal,normal,Future Release,defect (bug),new,dev-feedback,2019-05-22T20:28:27Z,2022-09-19T17:02:17Z,"Here's a process which I've seen occur twice in the last few days:
* A change to a site was deployed and a fatal error gets triggered somewhere.
* The recovery mode email was sent out.
* The developer checks the current value of the admin email address and discovers it belongs to someone who left the company years ago.
* They change the admin email address to their own email address and re-trigger the fatal error, but the recovery mode email doesn't get re-sent to the new address because there's a one day rate limit in place.
This prevents the user from enabling recovery mode for at least a day.
The option that acts as the ""last sent"" record for the recovery mode email (`recovery_mode_email_last_sent`) should take into account the admin email address, for example by hashing it and including it in the option key.
Aside: Is there a reason an option is used instead of a transient?",johnbillion
Future Releases,33234,Tags/Categories Count Incorrect,,Taxonomy,,normal,normal,,defect (bug),new,dev-feedback,2015-08-02T22:31:34Z,2023-05-03T20:24:41Z,The tags and categories management pages show inaccurate count when posts are marked private.,mikedunn
Future Releases,49263,Switching blog doesn't switch locale,,I18N,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2020-01-21T19:34:15Z,2020-05-22T21:02:25Z,"#26511 introduced `switch_to_locale()`, but didn't take into account the Multisite use case that @rmccue mentioned in ticket:26511#comment:8.
It seems reasonable to expect that switching to a site with a different locale would switch the locale.
You can see that it currently doesn't by setting up a network with the following conditions and code, and then loading each site.
* The locale of site `1` is `en_US`
* The locale of site `2` is `es_MX`
* The locale of site `3` is `fr_FR`
{{{#!php
add_action( 'admin_init', function() {
echo get_locale() . ' '; // loaded site
_e( 'Howdy, %s' );
echo ' ';
switch_to_blog( 2 ); // spanish
echo get_locale() . ' ';
_e( 'Howdy, %s' );
restore_current_blog();
echo ' ';
switch_to_blog( 3 ); // french
echo get_locale() . ' ';
_e( 'Howdy, %s' );
restore_current_blog();
echo ' ';
switch_to_blog( 1 ); // english
echo get_locale() . ' ';
_e( 'Howdy, %s' );
restore_current_blog();
echo ' ';
echo get_locale() . ' '; // back to loaded site
_e( 'Howdy, %s' );
wp_die();
} );
}}}
The strings are always translated using the loaded site's locale, rather than the switched site.
A rudimentary way to see the desired effect would be something like this:
{{{#!php
function switch_to_blog_locale() {
$locale = get_option( 'WPLANG', 'en_US' ); // bypass get_locale() b/c early return is stuck on the starting site.
switch_to_locale( $locale );
}
add_action( 'switch_blog', 'switch_to_blog_locale' );
}}}
...although that doesn't take user locales into account, doesn't restore previous locales, etc.
Related: #44844",iandunn
Future Releases,25293,Switch_to_blog not switching the siteid,,Networks and Sites,3.0,normal,minor,Future Release,defect (bug),new,dev-feedback,2013-09-12T09:11:20Z,2017-06-08T20:17:36Z,"When having multiple network on multisite making the following:
{{{
switch_to_blog(1);
$options = get_site_option( 'my_option' );
restore_current_blog();
}}}
The options retrieved are the options of the current siteid and not the siteid of the switched blog.
One of the options is to make something like this :
{{{
global $wpdb;
// Get the previous siteid
$previous_site_id = $wpdb->siteid;
$previous_blog_id = $wpdb->blogid;
// Go to site 1
switch_to_blog(1);
// Set the blog siteid to 1
$wpdb->set_blog_id( 1, 1 );
// Get the options
$options = get_site_option( 'my_option' );
restore_current_blog();
$wpdb->set_blog_id( $previous_blog_id , $previous_site_id );
}}}
Or
{{{
// Get the previous siteid
$site_id = $wpdb->siteid;
// Set the blog siteid to 1
$wpdb->set_blog_id( $wpdb->blogid, 1 );
// Get the options
$options = get_site_option( 'my_options' );
$wpdb->set_blog_id( $wpdb->blogid , $site_id );
}}}
The thing is that the switch_to_blog function does not specify the switched siteid on the method $wpdb->set_blog_id if the network is not the same as the current blog.",Rahe
Future Releases,41819,Support the paged argument in WP_Site_Query and WP_Network_Query,spacedmonkey,Query,4.6,normal,normal,Future Release,enhancement,assigned,dev-feedback,2017-09-06T18:21:04Z,2017-11-01T17:47:07Z,"The {{{WP_Site_Query}}} and {{{WP_Network_Query}}} both support the {{{offset}}} and {{{number}}} arguments.
It would be handy to be able to use the {{{paged}}} argument, to make the pagination easier.
",birgire
Future Releases,29429,Support frame-ancestors directive over X-Frame-Options,,Security,,normal,normal,Future Release,enhancement,reopened,dev-feedback,2014-08-29T14:25:35Z,2019-07-29T00:18:23Z,"According to MDN, `X-Frame-Options` is deprecated: https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options
`frame-ancestors` should be used instead.
Previously #12293",danielbachhuber
Future Releases,37000,Support for the SameSite cookie attribute,,Security,,normal,normal,Future Release,enhancement,new,dev-feedback,2016-06-02T13:31:13Z,2022-11-11T10:45:05Z,"IETF's [https://tools.ietf.org/html/draft-west-first-party-cookies Same-site Cookies draft] was [https://www.chromestatus.com/feature/4672634709082112 shipped in Chrome 51 and Opera 39].
The SameSite cookie attribute instructs a browser not to send that cookie with cross-origin third-party requests (such as iframes, embedded images, and Ajax requests). This effectively mitigates CSRF attacks as, for example, the user will not be authenticated for a given third party URL that's being used in a CSRF attack.
More information on the SameSite attribute can be found here: http://www.sjoerdlangkemper.nl/2016/04/14/preventing-csrf-with-samesite-cookie-attribute/
We should investigate whether setting the `SameSite=lax` attribute is of benefit to the `auth` and/or `logged_in` cookies in WordPress, and if so consider implementing it once the draft becomes an RFC.
PHP uses the `setcookie()` wrapper for setting cookies, which means that setting the SameSite attribute is not possible using that function, until such point that support for the attribute gets added. If WordPress were to implement the SameSite attribute, we'd need our own cookie handling function which constructs and sets the `Set-Cookie` header itself, and use it in place of `setcookie()` (side note: this may also be beneficial to unit testing).",johnbillion
Future Releases,44658,Support BETWEEN for term names in WP_Tax_Query/WP_Term_Query,,Query,,normal,normal,Future Release,feature request,new,dev-feedback,2018-07-27T20:23:30Z,2019-09-11T15:56:51Z,This patch adds `name__between` parameter in `WP_Term_Query` and `between` operator in `WP_Tax_Query`.,soulseekah
Future Releases,49964,Support asynchronously loading TinyMCE,,TinyMCE,5.0,normal,normal,Future Release,enhancement,new,dev-feedback,2020-04-20T22:05:18Z,2020-08-13T14:19:40Z,"In order to facilitate [https://github.com/WordPress/gutenberg/issues/21738 asynchronously loading TinyMCE in Gutenberg] we need to be able to prevent WordPress from automatically enqueueing `wp-tinymce` and injecting inline i18n initialization scripts. (There's plenty of context in the Gutenberg issue including related tickets, so I'll try not to repeat any of that here.)
I'd like to propose wrapping [https://developer.wordpress.org/reference/classes/_wp_editors/print_tinymce_scripts/ _WP_Editors#print_tinymce_scripts] in an action that Gutenberg could use for when the editor is loading.",sarayourfriend
Future Releases,41403,"Support ""class"" and ""id"" attributes on wp_oembed_get()",,Embeds,,normal,normal,Future Release,defect (bug),new,close,2017-07-21T19:58:48Z,2020-09-22T13:52:43Z,"The oembed function `wp_oembed_get( $url, $args )` allows us to set additional arguments for retrieving embed HTML.
The problem is that currently the function supports two arguments, only `width` and `height`. In some cases developers need more flexibility, to set other HTML attributes like `id`, `class` and maybe even `title` (for better accessibility).
----
I was trying to thinking of an example and I think that the simplest example would be [https://v4-alpha.getbootstrap.com/utilities/responsive-helpers/ bootstrap responsive embeds].
{{{
}}}
Currently you can't set custom classes in iframe with the attributes:
{{{
wp_oembed_get( 'https://...', array( 'class' => 'embed-responsive-item' ) );
}}}
",ramiy
Future Releases,34555,superscript in url,,Permalinks,,normal,normal,,defect (bug),new,dev-feedback,2015-11-02T10:39:17Z,2019-06-04T20:53:06Z,"If you have a superscript in the post title and selected post-name structure for permalink, it creates a slug as in the image: http://prntscr.com/8y3wsc
",sabrisahincan
Future Releases,20459,Super admin should be able to bypass banned/limited domains when creating users,,Users,,normal,minor,,enhancement,new,dev-feedback,2012-04-16T16:12:25Z,2019-06-05T06:38:31Z,"The function `wpmu_validate_user_signup()` is run whenever a new user is created, either through self-registration (wp-signup.php) or through manual user creation by an admin. `wpmu_validate_user_signup()` does two different kinds of validation:
(1) validation that is more or less technically required by WP, like spaces in usernames, email/login uniqueness, etc.
(2) checks against some admin-set membership restrictions, namely, email domain whitelist (limited_email_domains) and blacklist (`is_email_address_unsafe()` and banned_email_domains).
The second kind of validation is problematic in the following use case: An MS install might restrict open membership based on email domains, but the admin might occasionally want to make exceptions to the rule and manually create an account. Currently, there are two ways to bypass the built-in checks: to temporarily remove the domain restrictions at Network Admin > Settings, or to filter `'wpmu_validate_user_signup'` and remove the error messages.
Having to manually change settings for this purpose is pretty hackish. The filter method works, but my experience (from consulting with a fairly large number of MS network admins) is that this is a pretty common use case, so it seems like it should be supported by default.
So I'm proposing that the domain checks be skipped when `is_super_admin()`. Patch attached.",boonebgorges
Future Releases,46973,Suggestion for selection boxes in Reading setting > settings > Dashboard,,Administration,5.2,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2019-04-18T09:46:30Z,2019-04-19T13:17:28Z,"Hello,
I got across with a suggestion while going through Reading setting > Setting > Dashboard. It would be more convenient if the two selection box(under Reading setting header) will be placed side by side using the white space right side. It will enhance the user experience and will result in clean design.",monarkpatel
Future Releases,18400,"Suggested label change for ""Stick this post to the front page""",,"Posts, Post Types",,normal,normal,Future Release,enhancement,new,dev-feedback,2011-08-14T01:19:53Z,2020-02-06T19:45:40Z,"In the Publish meta box, it would be more clear to say ""Stick this post to the top of the front page"" compared to saying ""Stick this post to the front page"".",designsimply
Future Releases,41792,Suggested Enhancement to WordPress' Handling of Authors and Author URL's,,Themes,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2017-09-04T11:36:02Z,2017-09-06T07:59:42Z,"Hi, everyone, my first post here, but I have some concerns.
*WordPress' Handling of Authors*
I feel it's not the right UX when, say on a single author blog, the url ""blog.com/author"" goes to 404.
I'd like for WordPress to programmatically direct/redirect a blog.com/author to the archive of this single author if single author. I mean, say I, Kabolobari, am an author on a single author blog and the url to my posts is blog.com/author/kabolobari. So, WordPress automatically creates that based on my name choice.
Now, since WordPress can also tell a multi-author blog once there's more than one author, I'd like if WordPress then automatically builds the url for such as blog.com/authors/kabolobar, Kabolobari being one author on this blog.
Then if a user/browser were to backspace the url, of course, their intention would be to see all authors at blog.com/authors, right? Thus, WordPress shouldn't send them to a 404. WordPress should intelligently default that to a list of all the authors on the multi-author blog.
Is my explanation clear?
Then, WordPress can, as with other archives, leave a way for admins or theme developers to customize how they'd like this `authors.php`, as an example, template to be.
To summarize,
Single Author Blogs = blog.com/author/single-author
Then, blog.com/author = This Single Author and a list of their posts
Multi Author Blogs = blog.com/authors/multi-author
Then, blog.com/authors = These authors list and a list of their posts
Then leave all of these to be customizable by theme devs.
I'm having a hard time hacking my way around this because of this feature which I see is unavailable. If I'm wrong and there's actually a straightforward way about this, kindly direct me.
*As an Example*
Kindly, study the website kincommunity.com. Because what I’m building is very similar to that. Now, you should notice that when you hit Creators on the navigation at this site, Kin Community’s developers chose a custom post type route to display their Creators.
Thus, Creators takes you to kincommunity.com/our-community/. Then a single creator is at kincommunity.com/creators/rosanna-pansino/, for example. But when you try kincommunity.com/creators/, as a user you expect to see a list of all creators, right? But you get a 404.
I figure if WordPress allowed for a native way to flex around this, so that say you added a role of Creator (coding it yourself or with a plugin such as Members by Justin Tadblock) and you give this new role about same level of cap as Author.
Then one wouldn’t need to use CPT for this purpose and then the logic as I’ve explained above would take hold automatically with allowance for customization to look like the theme’s overall feel.
Could we examine these concerns? Thanks.",kbooshco
Future Releases,55401,Subpages of a web page can be called twice,,Permalinks,5.9.3,normal,major,Awaiting Review,defect (bug),new,dev-feedback,2022-03-16T15:48:12Z,2023-07-20T18:41:13Z,"Subpages of any website created with WordPress can be accessed twice.
If you add a /0/ to the end of the regular URL, the same page can be called again.
This page with /0/ at the end of the URL will also be indexed in Google.
Example:
https://wordpress.org/news/2022/03/wordpress-5-9-2-security-maintenance-release/
https://wordpress.org/news/2022/03/wordpress-5-9-2-security-maintenance-release/0/",manuel10503
Future Releases,18734,Subcategory archive does work with any name as parent category in URL,,Canonical,3.0.1,normal,normal,Future Release,defect (bug),new,dev-feedback,2011-09-21T15:10:46Z,2022-05-16T02:25:51Z,"Parent category is ''parentcategory'' and his sub category is ''subcategory''.
The URL will be ''domain.com/category/parentcategory/subcategory''.
The problem is, that you will get the same page if you use any words as ''parentcategory''.
Examples:
- ''domain.com/category/xxx/subcategory''
- ''domain.com/category/subcategory''
- ''domain.com/category/foo/bar/subcategory''
IMO {{{redirect_canonical}}} should do his work here (and sometimes it does).
In 3.1 it does redirect.
In 3.1.4 it doesn't redirect; after r17549.
In 3.2.1 it doesn't redirect.
Duck_ found that it does redirect before r18079.
In current trunk it doesn't redirect.
",ocean90
Future Releases,22402,Stripping non-alphanumeric multi-byte characters from slugs,,Formatting,,normal,normal,,enhancement,new,dev-feedback,2012-11-10T05:07:10Z,2019-06-04T19:44:12Z,"`sanitize_title_with_dashes()` strips non-alphanumeric characters from a title to create a slug. Unfortunately it only strips ASCII non-alphanumeric characters. Apart from a few exceptions, all multi-byte characters are preserved. This means all non-Western (and plenty of Western) non-alphanumeric characters end up in the slug as they're treated just like any other multi-byte character.
As an example, here are some common non-alphanumeric Chinese characters which would ideally be stripped from slugs, but are not:
* 。 (U+3002, Ideographic Full Stop, %E3%80%82)
* , (U+FF0C, Fullwidth Comma, %EF%BC%8C)
* ! (U+FF01, Fullwidth Exclamation Mark, %EF%BC%81)
* : (U+FF1A, Fullwidth Colon, %EF%BC%9A)
* 《 (U+300A, Left Double Angle Bracket, %E3%80%8A)
* 》 (U+300B, Right Double Angle Bracket, %E3%80%8B)
Obviously it would be impractical to make a list of ''all'' the non-ASCII characters we want to strip from slugs. The list would be gigantic.
So the question is, would it be possible to use Unicode ranges to blacklist (or whitelist) whole ranges of characters to be stripped from (or preserved in) slugs? Is this practical or even desirable?
Or would it make more sense to continue using a list of just the most common multi-byte characters to be stripped?
The latter makes a whole lot more sense, but the former is a more complete solution.
Thoughts?",johnbillion
Future Releases,25644,"strip_shortcodes always removes text between shortcode tags, should be optional",,Shortcodes,3.6.1,normal,normal,,enhancement,new,dev-feedback,2013-10-20T19:24:40Z,2019-06-04T21:09:05Z,"strip_shortcodes will always remove all of the content between shortcode tags. So, for example, if I have a shortcode tag which wraps a link or a style around some text the text is lost when the shortcode is removed.
Example:
''Lorem ipsum [highlight]dolor[ /highlight] sit amet, consectetur adipisicing elit''
becomes
''Lorem ipsum sit amet, consectetur adipisicing elit''
It should become
''Lorem ipsum '''dolor''' sit amet, consectetur adipisicing elit''
Removing the content between shortcodes may often be desirable behaviour, but there should be some way to retain the content. The easiest way would be for strip_shortcodes() to take a second parameter which defaults to true to remove the content, but if it is false then it leaves the content between the tags
Example change to wp-includes/shortcodes.php
Before
{{{
function strip_shortcodes( $content ) {
global $shortcode_tags;
if (empty($shortcode_tags) || !is_array($shortcode_tags))
return $content;
$pattern = get_shortcode_regex();
return preg_replace_callback( ""/$pattern/s"", 'strip_shortcode_tag', $content );
}
function strip_shortcode_tag( $m ) {
// allow [[foo]] syntax for escaping a tag
if ( $m[1] == '[' && $m[6] == ']' ) {
return substr($m[0], 1, -1);
}
return $m[1] . $m[6];
}
}}}
After
{{{
function strip_shortcodes( $content, $strip_between = true ) {
global $shortcode_tags;
if (empty($shortcode_tags) || !is_array($shortcode_tags))
return $content;
$pattern = get_shortcode_regex();
if($strip_between==true) return preg_replace_callback( ""/$pattern/s"", 'strip_shortcode_tag', $content );
else return preg_replace_callback( ""/$pattern/s"", 'strip_shortcode_tag_notbetween', $content );
}
function strip_shortcode_tag( $m ) {
// allow [[foo]] syntax for escaping a tag
if ( $m[1] == '[' && $m[6] == ']' ) {
return substr($m[0], 1, -1);
}
return $m[1] . $m[6];
}
function strip_shortcode_tag_notbetween( $m ) {
// allow [[foo]] syntax for escaping a tag
if ( $m[1] == '[' && $m[6] == ']' ) {
return substr($m[0], 1, -1);
}
return $m[1] . $m[5] . $m[6];
}
}}}
It's probably possible to do this with slicker code, but this is fairly simple and works.
An example of when this problem is encountered in the real world is with the [http://wordpress.org/plugins/rb-internal-links/ RB internal links plugin] being used in post content. When the post is displayed by the [http://wordpress.org/plugins/popular-widget/ popular widget plugin] any text which was internally linked is lost, leaving a snippet of the post which makes no sense to a human reader. For an example on a live site see the first entry under the '''Most popular (all time)''' section on the right hand side of [http://diymediahome.org DIY Media Home]",jonscaife
Future Releases,56172,Strict comparisons not used.,,General,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2022-07-08T05:04:18Z,2023-10-26T00:02:19Z,"On going through the core files, I observed that in many places strict comparison is not used. After that, I ran the code through the WPCS and also got the warnings for the same. Though it does not affect the flow of the site, it should be used.
Few exampals are:
1 options-general.php
{{{
215 | WARNING | Found: ==. Use strict comparisons (=== or !==).
393 | WARNING | Found: ==. Use strict comparisons (=== or !==).
}}}
2 sites.php
{{{
105 | WARNING | Found: ==. Use strict comparisons (=== or !==).
145 | WARNING | Found: !=. Use strict comparisons (=== or !==).
145 | WARNING | Found: !=. Use strict comparisons (=== or !==).
157 | WARNING | Found: ==. Use strict comparisons (=== or !==).
185 | WARNING | Found: !=. Use strict comparisons (=== or !==).
185 | WARNING | Found: !=. Use strict comparisons (=== or !==).
}}}
",hilayt24
Future Releases,35669,Store widgets in a custom post type instead of options,,Widgets,2.8,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2016-01-30T20:00:34Z,2019-01-10T05:18:15Z,"Widget instances are stored in options. For a multi-widget (`WP_Widget`) the widget instances of a given type (`id_base`) are stored in a serialized array of instance arrays. A widget ID is comprised of a widget's `id_base` followed by a number which is the array index for that widget instance. For example, the third-created Text widget would have the ID `text-4` (note that multi-widget numbering starts at 2). Old single widgets do not include the numeric index after the `id_base`, and technically they could be stored anywhere (see #35656 for suggestion to deprecate old single widgets).
== Issues
There are several problems with how widgets are currently stored as options.
'''Scalability:''' For sites with a large number of widget instances, the entire collection of widgets must be unserialized with each request to access only one widget of a given type. (Note #23909 for how all widget instances get registered with every request.) For sites that use Memcached as an external object cache where cache buckets have a 1MB limit, since all widget instances of a given type are stored in a single option, sites with a huge number of widgets will overrun this limit. What's more is that widget options get registered as autoloaded, so all widget options will get combined together in the `alloptions` key, making widgets even more liable to overrun the 1MB cache bucket limit in Memcached.
'''Concurrency:''' Since all widget instances of a given type are stored in a single option, if two users attempt to update two separate widgets at the same time, it is possible that one of the updates will get lost (see #31245). Additionally, the widgets admin page and widgets in the Customizer both get loaded with the max number (array index) for each widget type. When a new widget instance is created, this maximum number is incremented in memory and used in the new widget ID which is then passed to the server for saving. If two users have loaded the UI at the same time, when they both create a widget of a given type and save their widget changes, the one who saves last will overwrite the other user's widget since the two widgets would have the same ID. (See #32183 for more about the widget ID collisions, and see [https://wordpress.org/plugins/customize-widgets-plus/ Customize Widgets Plus] for a “Widget Number Incrementing” component which uses Ajax to generate new widget IDs in a more concurrency-safe manner.)
'''Addressability:''' As noted above, widget instance IDs are comprised of the widget type's `id_base` followed by the array index `number`. Two different widget instances can have the same `number`, such as `search-3` and `text-3`, since the `number` is incremented in the scope of the instances of the given type. No other objects in WordPress are identified by strings in this way, that is as of now: taxonomy terms actually used to have to be addressed by a numeric term ID and taxonomy name until term splitting happened in 4.2 (see #5809). Now, however, a term can be uniquely identified by a single integer ID.
All of the above issues would be resolved by switching to store widget instances in a custom post type, where each widget instance has a single unique auto-incremented post ID.
== Advantages
Storing widgets in custom post type has several benefits beyond fixing the above issues, including:
* widget authorship attribution
* revision history
* import/export
* querying
* widget drafts
* scheduled widgets
== Data Migration
Migrating widgets from options to a custom post type would involve some tedious data migration to update all references to current `id_base-number` widget IDs to their new integer IDs. The old widget ID could actually be copied directly into the `post_name` field for the `widget_instance` posts. Backwards compatibility for the `sidebars_widgets` option containing the old-style IDs may be necessary. Newly created widget IDs could have `post_name` fields populated with the `id_base` followed by the post ID. This switch would also necessitate discontinuing to register all widget instances with every request (#23909).
== Sidebars and Widget Groups
Perhaps out of scope for this ticket, but the way that widgets get associated with sidebars should also perhaps be changed to follow the pattern of how nav menu items are associated with a nav menu via a taxonomy term. The implementing of widget groups (#19912) could be the right opportunity to do this, where a `widget_grouping` taxonomy could be introduced, and when a grouping is assigned to a sidebar, the backwards-compatible widget IDs could be copied into the existing `sidebars_widgets` option. Otherwise, backwards compatibility might entail adding `pre_option_sidebars_widgets` filter.
== REST API Impacts
For more on widgets and now they relate to nav menu items in the context of a harmonized interface via the REST API, see https://github.com/WP-API/wp-api-menus-widgets-endpoints/issues/10
== Feature Plugin
See the [https://github.com/xwp/wp-customize-widgets-plus Customize Widgets Plus] feature plugin's “Widget Posts” module for an initial implementation of storing widgets in a `widget_instance` custom post type. This plugin depends on #32474 which facilitated plugins to store widgets in posts instead of options.",westonruter
Future Releases,50522,"stop setting ""older"" cookies with multiple path prefixes",,Login and Registration,5.4.2,normal,normal,Future Release,defect (bug),new,changes-requested,2020-07-01T13:38:23Z,2024-02-01T20:47:17Z,"According to `wp_clear_auth_cookie()`,
{{{#!php
'REGEXP', 'key' => 'foo', 'value' => '^bar']` working as substitution to raw SQL-request like `... foo.meta_key REGEXP ^bar ...`
please, specify this explicitly in the [https://developer.wordpress.org/reference/classes/wp_meta_query/ documentation] - especially the fact that this REGEXP should not be wrapped in `/`",letraceursnork
Future Releases,52871,"Space added after the ""option"" tag on the options-writing.php file",,Administration,,normal,normal,Awaiting Review,enhancement,new,close,2021-03-20T13:00:07Z,2023-05-29T15:44:27Z,"Space added after the ""option"" tag on the options-writing.php file as a standard workflow.",Laxman Prajapati
Future Releases,24879,Sourcemaps should be provided for use with minified javascript libraries,,Build/Test Tools,,normal,normal,Future Release,enhancement,new,dev-feedback,2013-07-29T15:49:33Z,2017-02-19T10:42:42Z,"Sourcemaps make it possible to debug minified files.
Supported in Chrome:
https://developers.google.com/chrome-developer-tools/docs/javascript-debugging#source-maps
Landing in Firefox in v23:
https://wiki.mozilla.org/DevTools/Features/SourceMap
When this feature is enabled, the Chrome console currently shows a 404 when the script specifies a sourcemap file and it isn't found.",jblz
Future Releases,15861,Sorting users by post count,,Users,,normal,normal,,defect (bug),new,dev-feedback,2010-12-17T10:21:24Z,2019-06-05T06:37:48Z,"Currently, to enable sorting by post count, there's a JOIN made between the users table and the posts table.
This is bad, because users is a global table, which might be stored in a separate database.
Short-term solution for 3.1 is to disable sorting.
Long-term solution is to avoid the JOIN somehow. ",scribu
Future Releases,11740,Sorting tags and towns does not work well for utf-8,nbachiyski,I18N,2.9,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2010-01-06T12:42:24Z,2024-02-28T16:41:53Z,"There are problems with sorting special Czech characters:
1) Options - General - Timezone selection.
Evropa (Europe)
First item should be Amsterdam, but instead of it there is ""Řím"" (Rome in Czech). And this is not right, character Ř should be between R and S.
2) Editing posts - Select from most used tags.
You can create tags ""Rome"", ""Amsterdam"" and ""Řím"".
Tags are also sorted in a bad way, first is ""Řím"".
It is very problematic for Czech users when there are many tags, because it does not help them...",pavelevap
Future Releases,57825,Something's wrong with the way the 'admin_init' hook and/or the wp_update_post function works,,General,6.1.1,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2023-02-28T19:54:51Z,2023-02-28T19:54:51Z,"Hi,
(I'm not sure what's happening here, so I left the Component dropdown with its default value.)
The issue in a nutshell: when hooked to `admin_init`, the below function's wp_update_post() call is executed even when the wrapper if-else statement evaluates to false, and it updates all `mac-submenus` post type entries' status to 'draft' regardless of the fact that the `$post_id` variable doesn't even have a value in this case.
I don't know how is this even possible, but it's happening - and if another admin hook is used ( for instance `in_admin_header` ), the function works perfectly, just as expected.
{{{#!php
-1,
'post_type' => 'mac-submenus',
// We only check published submenu posts
'post_status' => array('publish'),
'fields' => 'ids',
);
$submenu_post_ids_Arr = get_posts( $spq_Arr );
// Get the custom item array of the menu associated with the 'primary_menu' location
global $new_menu_Arr;
// Get all menu items that are top-level and parent
$parent_menu_items_Arr = mac_helper_search(
$new_menu_Arr,
'has_children',
true
);
$top_level_menu_items_Arr = mac_helper_search(
$new_menu_Arr,
'is_top_level',
true
);
$tlp_items_Arr = array_uintersect(
$parent_menu_items_Arr,
$top_level_menu_items_Arr,
function( $val1, $val2 ) {
return strcmp($val1['has_children'], $val2['has_children']);
}
);
// Check if all 'mac-submenus' entries have their respective top-level & parent menu
// item in the menu associated with the 'primary_menu' location.
//
// If a submenu entry DOESN'T have such corresponding menu item:
// - check if it has a top-level BUT NOT PARENT corresponding menu item
// - if it has, change the submenu post status to 'draft'
// --------------------------------------------------------------------------------------------
// 1. Get submenu posts having a corresponding top-level parent menu item.
$posts_with_tlp_Arr = array();
foreach ( $submenu_post_ids_Arr as $post_id ) :
$post_has_tlp = false;
foreach ( $tlp_items_Arr as $menu_item ) :
$mi_title = html_entity_decode( $menu_item['title'] );
$p_title = html_entity_decode( get_the_title( $post_id ) );
if ( $mi_title == $p_title ) :
$post_has_tlp = true;
break;
endif;
endforeach;
if ( $post_has_tlp )
$posts_with_tlp_Arr[] = $post_id;
endforeach;
// 2. Get posts that don't have a corresponding top-level parent menu item, and
// change their status to 'draft';
$posts_with_no_tlp_Arr = array_diff( $submenu_post_ids_Arr, $posts_with_tlp_Arr );
if ( !empty($posts_with_no_tlp_Arr) ) :
foreach( $posts_with_no_tlp_Arr as $post_id ) :
$update_args_Arr = array(
'ID' => $post_id,
'post_type' => 'mac-submenus',
'post_status' => 'draft',
);
wp_update_post( $update_args_Arr );
endforeach;
endif;
}
add_action( 'admin_init', 'cpt_mac_submenus_create_delete_check_menu_items' );
}}}
I spent an hour with testing code variations, but couldn't find a problem with the above code or a fix of the issue.",lunule
Future Releases,48078,Some WP_XXX_Query::query() methods produce incorrect results when called in a loop,,Query,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2019-09-19T18:28:19Z,2019-09-20T11:47:58Z,"While testing a [https://core.trac.wordpress.org/attachment/ticket/37392/37392.9.patch patch] for #37392 I came across what ''may'' be a bug in `WP_Site_Query::query()`.
That patch creates a `WP_Site_Query` object and then in a loop does various different `query()`'s, as in:
{{{#!php
$q = new WP_Site_Query();
$args = array(
'network_id' => $network_id,
'number' => 1,
'fields' => 'ids',
'no_found_rows' => false,
);
foreach ( array( 'public', 'archived', ... ) as $status ) {
$_args = $args;
$_args[ $status ] = 1;
$q->query( $_args );
// do something with the results of this site query.
}
}}}
However, calling `query()` in a loop like that doesn't produce the expected results other than the 1st time through the loop.
Why? Because when `query()` calls `WP_Site_Query::get_site_ids()` on subsequent iterations, the protected class member `$sql_clauses` still has its value from the previous iteration through the loop and the ""new"" query basically gets added to the previous queries.
In the case of the above code this results in the query for `archive = 1` to actually be `public = 1 AND archive = 1` which is **not** what is intended.
Looking at other `WP_XXX_Query()` classes, I ''think'' the following suffer from the same thing (although I haven't written code to test that):
1. `WP_Network_Query`
2. `WP_Term_Query`
but the following do **not**:
1. `WP_Query` (because it doesn't use a class member for the clauses)
2. `WP_User_Query` (because it uses a `prepare_query( $query )` method which resets the class member(s))
So, I guess the question is: should these `query()` methods be expected to work when called multiple times in a loop (with different queries each time) or is that **not** an intended use?",pbiron
Future Releases,17619,Soft 404 at /wp-content/plugins/,,General,,normal,normal,Future Release,enhancement,new,dev-feedback,2011-05-30T16:31:30Z,2019-09-24T19:39:34Z,"/wp-content/plugins/index.php would be better written with a proper 404.
{{{
}}}",miqrogroove
Future Releases,48331,Snoozing the admin email verification screen when a user initiates/confirms a site email change,,Site Health,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2019-10-16T19:45:01Z,2019-12-06T14:21:48Z,"When presented with the admin email verification screen, clicking update takes you to the `Settings > General` page where the user can update the email address. But, even if the user initiates an admin email address change (which requires a confirmation URL in an email to be clicked), they will continue to see the verification screen until they click to confirm the email is correct or ""Remind me later"", even if the email change request is confirmed.
When a user navigates to the Settings > General page from clicking Update on the verification screen and follows through to initiate a request to change the admin email, the verification screen should be snoozed the same as clicking ""Remind me later"".
Being consistently presented with the verification screen could cause the user to confirm the email just to get the notice to stop.
When a request to change the email is confirmed, both the old and new email receive a notification informing them of the action. The verification screen could probably be snoozed same amount of time as `admin_email_check_interval` at that point.",desrosj
Future Releases,39636,Smilies not converted when directly followed by punctuation marks,,Formatting,4.7.1,normal,normal,Future Release,enhancement,new,dev-feedback,2017-01-19T10:29:30Z,2022-04-11T03:02:17Z,"Steps to recreate:
- Create a new post or comment
- Insert a smilie directly followed by a period or other punctuation mark such as :).
- View the post or comment
Expected:
Ideally the smilie would show followed by the punctuation mark.
I've attached a screenshot showing how a post with the following text appears. Smiles with a space between them and the punctuation mark show, but the others do not.
{{{
This is a test :). It uses smilies :)
If a smilie has punctuation directly after, it is not converted :(! :(
The expected behavior would be to look like this:
:) ! :) ,
However instead they appear as this
:)! :),
}}}
",ourvalley
Future Releases,54211,Small css bug when using customize-controls in customizer.php,,Customize,3.4,normal,minor,Awaiting Review,defect (bug),new,dev-feedback,2021-10-02T11:21:51Z,2022-09-09T10:34:04Z,"The form code is wrong in the css for some elements. To reproduce problem, add in customizer.php custom two customize-control-radio and two customize-control-select. You see the 'radio' has extra 10px padding on bottom. The 'select' is missing the 10px padding. So it looks very bad when you organize the elements. So either remove the 10px or add the 10px to the 'select' css.",akissz
Future Releases,57438,Slug is not generated when saving posts as draft,,"Posts, Post Types",,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2023-01-10T04:28:22Z,2023-03-08T16:39:30Z,"When saving posts as draft, the slug is empty. Only when publishing posts, the slug is generated.
Slug should be auto-generated even when saving posts as draft.
Steps to reproduce:
- Add a new post (in the classic editor or Gutenberg)
- Enter the post title
- Save the post as draft
- Reload the page (if in Gutenberg) and see the slug is empty",rilwis
Future Releases,58132,Slashes used in block templates slug is a problem on Windows,,Editor,5.9,normal,normal,6.6,defect (bug),new,dev-feedback,2023-04-14T11:26:33Z,2024-02-29T21:46:03Z,"Generally, they are all stored flat in the theme `templates` or `block-templates` folder; we have no problem here. But when they are stored deep under some folder/s, the slug checks won't pass on Windows.
This is because finding the template paths [https://developer.wordpress.org/reference/functions/_get_block_templates_paths] return backslashes `\` and [https://core.trac.wordpress.org/browser/tags/6.2/src/wp-includes/block-template-utils.php#L313] currently only does `substr` extracts to come up with a slug that is passed to [https://developer.wordpress.org/reference/functions/_build_block_template_result_from_file/], which eventually fails line [https://core.trac.wordpress.org/browser/tags/6.2/src/wp-includes/block-template-utils.php#L981] as the slugs in the query are using forward slashes `\`.",gaft
Future Releases,57964,Sitehealth recommended improvements - utf8mb4 requires a newer client library,,Site Health,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2023-03-21T17:01:37Z,2023-03-23T08:34:22Z,"WordPress: 6.2-RC2
Sitehealth recommended improvements - utf8mb4 requires a newer client library
UTF8MB4 is the character set WordPress prefers for database storage because it safely supports the widest set of characters and encodings, including Emoji, enabling better support for non-English languages.
Your MariaDB version supports utf8mb4.
WordPress’ utf8mb4 support requires MySQL client library (libmysql) version 5.5.3 or newer. Please contact your server administrator.
{{{
from phpinfo.php
mysqli
Client API library version 3.1.20
Client API header version 10.4.28-MariaDB
mysqlnd
Version mysqlnd 8.1.16
In WordPress site health info:
Extension mysqli
Server version 10.4.28-MariaDB
Client version 10.4.28-MariaDB
}}}
https://php.watch/versions/8.2/mysqli-libmysql-no-longer-supported
With PHP 8.2 should this recommended be given as libmysql no longer supported in PHP 8.2. Does any version of mysqlnd support utf8mb4 instead and should be the recommendation instead?
Note: Running PHP 8.1 on production site and my local PHP 8.2 doesn't use libmysql if this is already fixed. ",ipajen
Future Releases,43598,site-options notoption only queried and never set in not multisite wordpress installs,SergeyBiryukov,"Options, Meta APIs",4.9.5,normal,normal,Future Release,enhancement,reviewing,dev-feedback,2018-03-21T10:08:34Z,2019-09-23T23:15:04Z,"We have notoptions mechanism that works well. WordPress core does also query $network_id:notoptions regardless of multiste. However, such option is set only in multisite installs. As a result, if you are not running multisite, you are only querying for $network_id:notoptions and you never set it. It beats the idea of notoptions - we read it, but we never set it - what's the point?
Possible solutions:
- read $network_id:notoptions only in multisite installs
- set $network_id:notoptions also in not multisite installs",Grzegorz.Janoszka
Future Releases,35182,Site icon URLs don't respect SSL in admin,,Administration,4.4,normal,normal,,defect (bug),new,dev-feedback,2015-12-21T12:14:56Z,2019-06-04T19:33:29Z,"It appears that the following check in `wp_get_attachment_url()`:
{{{#!php
if ( is_ssl() && ! is_admin() && 'wp-login.php' !== $GLOBALS['pagenow'] ) {
$url = set_url_scheme( $url );
}
}}}
prevents `get_site_icon_url()` from using SSL for serving the icon links in the head, which results in non-HTTPS icon URLs on all admin pages:
[[Image(http://kaspars.net/wp-content/uploads/2015/12/site-icon-url-https.png)]]
",kasparsd
Future Releases,56987,Site Health: add visual placeholder for checks that are still loading,,Site Health,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2022-11-03T16:26:43Z,2023-10-23T18:41:50Z,"I love the Site Health feature, and I think it can improved in a few small ways to potentially impact user experience in one big way 💙
Right now, there is some helpful text that says ""Results are still loading"" and – when at least 1 recommendation can be made – another piece of text becomes a counter for the increasing number of possible Site improvements.
This is great to have, but in my experience, the longer running in-progress checks are easily overlooked because there is not a big obvious visual indicator that background processing is happening.
It wasn't until I started writing this description and looking for clues, that I zoomed in to see that the thin grey circle next to the top text (id: `#site-health-progress`) has animation connected to it. (I recall this previously had a percentage; I think it's OK that number is omitted.)
When a recommendation finishes, it appears in either the top list for ""recommended improvements"" or the bottom list for ""items with no issues detected"". This is where I have ideas for UX tweaks:
* ""items with no issues detected"" is hidden by default behind a button shaped toggle, so users are never presented with what work is being done
* ""items with no issues detected"" toggle state is not persistent between page refreshes (using a screen option) so curious users cannot opt-in to seeing progress
* longer running checks give the impression that checks have completed or the page may be stuck
----
In my imagination, a few things should happen in conjunction:
* Add visual placeholders for in-progress checks
* perhaps as its own separate list with an item for each one, with a spinner where the open/close toggle is
* maybe some new creative UI if there is visual noise from elements jumping around
* ""items with no issues detected"" should be open by default
* when the user toggles it closed, it should stay closed until opened, etc..
* ""Screen Options"" could be added to use an existing API (or something more Gutenbergy?)
* More explicit and intentional verbiage - are these checks, items, issues, recommendations, improvements, or tests?
* Fewer words to give users less to read
* Narrow the scope of these adjectives into a familiar Type/State/Status pattern?
* More precise counts & labels:
* Simple: `All (24) | Pending (2) | Running (5) | Finished (17)`
* Wordy: `All (24) | Needs Attention (2) | In Progress (5) | Satisfactory (17)`
* Checks should be dismissible so users can hide ones they are comfortable with
* Screen Options to the rescue again!
* Add ""Dismissed (1)"" to the above counts
* Save state of checks in a transient, run as cron every 24 hours
* Add some text about ""checks running periodically""
* Allow this to be disabled with filters and/or multisite installs
* Debounce for some number of seconds so navigating between ""Status"" and ""Info"" does not always rerun every check
* Show a (2) count bubble in the admin menu
* Send an email when new recommendations are discovered
* Add some ""Rerun"" or ""Check Now"" button to flush the transient & run the job
----
I think these iterations change Site Health from being the very useful tool that it currently is (when discovered organically) to an interface that feels trustworthy and remarkable enough for users to feel compelled to take action on, and plugins & WordPress core to pull users into when issues come up.",johnjamesjacoby
Future Releases,46967,"Site health, info tab: show the current uploads directory info on network installs",,Site Health,5.2,normal,normal,Future Release,defect (bug),new,dev-feedback,2019-04-18T00:21:04Z,2019-06-20T14:44:58Z,"Follow-up from #46954.
Most of the information shown in the ""Directories and Sizes"" section doesn't apply for sites on a network install. Useful debug info would be to show the current site's upload directory path, size, and percentage of used space. Other info that may be useful there is the max file size allowed, as set in the network settings.",azaozz
Future Releases,52471,Site Health Upload-related INI values could use consistent formatting,,Site Health,,normal,normal,Awaiting Review,enhancement,new,close,2021-02-08T16:32:09Z,2021-02-14T19:05:33Z,"In #50038, we added a new section to Site Health -> Info section to show upload-related limits.
Currently, it does not show the information in a consistent way. It shows values like `128M`, `2G`, and `128 MB`.
I would like to suggest to tweak this to use `size_format` function to properly format them. We already use `wp_convert_hr_to_bytes` function to parse INI-style values (`128M`, `2G`, `2M`, etc); they just need some formatting.
Despite being a smaller diff, I suppose 5.7 is too early to target this, assuming this gets accepted of course.",ayeshrajans
Future Releases,47653,Site Health plugin security check,,Site Health,5.2,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2019-07-05T04:28:58Z,2021-09-07T17:01:22Z,"Having inactive plugins is not necessarily a bad thing. It is if they're up to date, if they haven't had an update in a few months or if they're untested with the current version of WordPress core.
Also, when there are outstanding updates and inactive plugins, the main notice (H4, visible while collapsed) should be about the updates, not the inactive plugins.",galbaras
Future Releases,52343,Site Health Page: Inactive theme message is inconsistent,,Site Health,5.6,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2021-01-22T07:34:10Z,2021-01-28T18:07:48Z,"On the Site Health page, the Theme related messages are confusing. The way theme name is written in different areas is not consistent as well.
`File: /wp-admin/includes/class-wp-site-health.php`
**Scenario 1 (More than 2 themes available including Twenty Twenty-One):**
**Message:**
----
Your site has 1 inactive theme, other than Twenty Twenty-One, the default WordPress theme, and Yardrive, your active theme. We recommend removing any unused themes to enhance your site’s security.
----
From the above message, it is clear that WordPress recommends removing all themes that unused. If someone removes **all** except the active one, Site Health then says:
**Your site does not have any default theme.**
This is confusing. The initial message should be more self-explanatory, something like:
Your site has 1 inactive theme, other than Twenty Twenty-One, the default WordPress theme, and Yardrive, your active theme. We recommend keeping at least one theme to be used as the default along with the active theme and remove the rest to enhance your site's security. Default themes are used by WordPress automatically if anything is wrong with your chosen theme.
**Scenario 2: (2 themes without any bundled theme)**
**Message:**
----
Your site has 1 inactive theme, other than twentytwentyone, the default WordPress theme, and Yardrive, your active theme. We recommend removing any unused themes to enhance your site's security.
----
Again, this is confusing. It says ""other than twentytwentyone"", when I do not have that theme installed at all!
Also, look at how the theme name is written in different cases.
In the first case, it says **Twenty Twenty-One**, and for the second one, it becomes **twentytwentyone**. They should be consistent.
If there is no twentytwentyone, either remove it from the message or include the exact theme name that is installed instead of twentytwentyone.
Twenty Twenty-One is the default theme with WordPress 5.6, which is fine, but at the same time, the theme name should be used in such a way that it does not create any confusion in users' minds. Please note, I am talking about WordPress users, not developers.
If someone has any bundled theme like twenty19 or twenty17 installed other than twenty21 as the default theme, either it should not complain about twenty21 or this should be made clear so that general WordPress users know that twenty21 is the default theme for WordPress 5.6 and is recommended to be there as the default theme.
If the above makes sense, I would be happy to go ahead and try to build a patch for this.
Regards",subrataemfluence
Future Releases,55288,"Site Editor on 5.9.1 fails to find homepage template for FSE themes, on WP subdirectory installation",,Editor,5.9.3,normal,critical,Awaiting Review,defect (bug),new,dev-feedback,2022-03-01T18:47:29Z,2022-08-11T19:29:10Z,"I'm getting an error when launching the site editor on 5.9.1, stating “The editor is unable to find a block template for the homepage”. This happens on both Twenty-Twenty-Two and a custom FSE theme (otherwise functional, has templates/single.html and templates/index.html). **My WP installation is in a subdirectory**, using the [[https://github.com/roots/bedrock|Bedrock]] site structure, so the editor URL is `https://example.test/wp/wp-admin/themes.php?page=gutenberg-edit-site`
I've tried it on PHP 7.4.25 and 8.0.14. I've confirmed it still happens with all plugins deactivated.
Notably, activating the Gutenberg plugin version 12.6.1 eliminates the error and the editor loads correctly.
There are several other reports of the same error in this Twenty-Twenty-Two forum thread: https://wordpress.org/support/topic/the-editor-is-unable-to-find-a-block-template-for-the-homepage/
The error code output from the copy button is
{{{
Error: `getHomepageParams`: HTTP status error, 404
at https://example.test/wp/wp-includes/js/dist/edit-site.js?ver=403e01f2b098b6a656118a51787581cb:8766:13
at async getHomepageParams (https://example.test/wp/wp-includes/js/dist/edit-site.js?ver=403e01f2b098b6a656118a51787581cb:8762:20)
at async redirectToHomepage (https://example.test/wp/wp-includes/js/dist/edit-site.js?ver=403e01f2b098b6a656118a51787581cb:8797:28)
at async reinitializeEditor (https://example.test/wp/wp-includes/js/dist/edit-site.js?ver=403e01f2b098b6a656118a51787581cb:9067:5)
}}}
",andronocean
Future Releases,16833,Signup mechanism shortens usernames without warning,,Users,3.0,normal,normal,Future Release,defect (bug),new,dev-feedback,2011-03-11T15:09:23Z,2017-07-10T16:18:37Z,"When a user signs up for an account on a wordpress blog, if their chosen username is longer than the limit, wordpress chops of the end of the username, without warning the user, and without offering the user the opportunity to choose again.
Steps to reproduce: Go to a wordpress blog, sign up with a long username, and read the confirmation email. An example: forum.xbmc.org, which has a limit of 15 characters.",hughcharlesparker
Future Releases,48115,Sidebar starter content issue with Twenty Twenty,,Customize,4.7,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2019-09-24T00:15:38Z,2021-06-01T00:50:40Z,"Hello,
While testing the beta I found the sidebar contents functioned a little odd. On initial install the sidebars showing on the front-end match what was in Appearance > Widgets which is;
Footer #1 (Search, Recent Posts, Recent Comments) and in Footer #2 (Archives, Categories, Meta)
But navigating the Appearance > Customizer > Widgets showed the defaults as Footer #1 (About this site) and Footer #2 (Find Us) and once I published the Customizer I found the front-end showed these two and then now the Appearance > Widgets also showing these.
So it seems the default widget content from TwentyTwenty only loads into Customizer as a default and isn't the actual defaults found on install in Appearance > Widgets.
Thanks",garrett-eclipse
Future Releases,41358,Shutdown hooks can significantly slow down REST API responses,,REST API,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2017-07-18T16:36:56Z,2019-01-30T16:09:27Z,"If you have a site with some slow, maybe deferred actions hooked into `shutdown`, these actions will slow the response from the REST API unnecessarily.
To test, simply add the following then do a request to the WP Rest API:
{{{#!php
My Sites > Network Admin > Plugins > Add New`
(Themes has the same above issue & relative navigation...)",johnjamesjacoby
Future Releases,39439,Should wp_insert_attachment() update GUID,,"Posts, Post Types",4.8,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2017-01-02T12:58:08Z,2021-08-06T11:58:02Z,"I have a ""special"" case scenario related to media library attachments.
For the context, I've built a plugin that connects to an external server and sync images stored into the remote server into local WordPress media library. The importer upload files, generate the thumbnails and create a new ""attachment"" post.
Now, an import process is ran everyday, and basically we re-import the remote images into WordPress but in order to avoid duplicates, we're updating existing attachments if exist. Now, during this update process, we only remove the files stored into the `uploads` directory, import the new one with its thumbnails and update the attachment post.
Before doing so, our first approach was to check if an attachment exists, if exists, delete the attachment + its files and then simply create a new attachment. This first approach works but we're having huge ID number into the DB after the import as it generates thousand of new records which we didn't want. So now, only the files are updated, if an attachment post exists, we update its metadata and everything works as expected.
Now the issue/remark we have is that during the update of the attachment post, each time we import the new image file, we set the `guid` property to change and use the new imported file path. But when we check the database table, the `guid` is not updated at all and reflects the path to the image file imported the first time. Looking at source code, during an update, the `guid` is not modified in general as for RSS feeds we need that unique `guid`.
Our question is, is it relevant in this scenario to keep old `guid` property that points to a file that no longer exists? and so should we allow the `guid` to be updated by default in core for the attachment?
If RSS readers need that `guid`, why attachments use the file path and not an attachment page permalink ? Is there another location that uses this `guid` property in place of the meta data for the file path ?
",jlambe
Future Releases,44133,Should the Data Export indicate when we have no information on the user,xkon,Privacy,4.9.6,normal,normal,Future Release,enhancement,assigned,dev-feedback,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
Future Releases,24572,Should be able to unlock a post outside of ajax handler,,"Posts, Post Types",,normal,normal,,enhancement,new,dev-feedback,2013-06-12T20:28:37Z,2019-06-04T20:44:25Z,"Right now you can programmatically lock a post for editing using wp_set_post_lock, but you can't unlock it in a similar fashion. The only unlocking code is found in the ajax handler wp_ajax_wp_remove_post_lock.
I've created a function wp_unset_post_lock in the style of wp_set_post_lock that unlocks a post with a given ID. I've also refactored wp_ajax_wp_remove_post_lock to use this function.
The only resulting difference is that we use the current user's ID instead of the one supplied in the ajax call, but since we're unlocking the post instead of locking it, it doesn't really matter who's ID is in the meta.
This change was requested by Joey Kudish of the VIP team.",bbrooks
Future Releases,55796,SHORTINIT requires rest-api.php via rest_cookie_collect_status() via wp_get_current_user(),,Application Passwords,2.0,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2022-05-23T21:36:15Z,2022-05-24T06:09:11Z,"Hello friends! 👋
I believe it may be unintended behavior that in order to use the `SHORTINIT` constant with standard cookie authentication, either `wp-includes/rest-api.php` must be included or its related default filters need to be removed.
----
**wp_get_current_user() – jjj1.php**
{{{
true
) );
}}}
Produces:
{{{
Fatal error: Uncaught Error: Call to undefined function wp_get_current_user() in wp-includes/class-wp.php:635
Stack trace:
#0 wp-includes/class-wp.php(768): WP->init()
#1 wp-includes/functions.php(1330): WP->main(Array)
#2 jjj1.php(31): wp(Array)
}}}
IMO, the inside of `WP->init()` has needed a `function_exists()` call around `wp_get_current_user()` since WordPress 2.0.0, and I'm only just now getting around to suggesting such 😅
----
**rest_cookie_collect_status() - jjj2.php**
{{{
true
) );
}}}
Produces:
{{{
Fatal error: Uncaught TypeError: call_user_func_array(): Argument #1 ($callback) must be a valid callback, function ""rest_cookie_collect_status"" not found or invalid function name in wp-includes/class-wp-hook.php:309
Stack trace:
#0 wp-includes/class-wp-hook.php(331): WP_Hook->apply_filters('', Array
#1 wp-includes/plugin.php(476): WP_Hook->do_action(Array)
#2 wp-includes/pluggable.php(705): do_action('auth_cookie_mal...', false, '')
#3 wp-includes/class-wp-hook.php(307): wp_validate_auth_cookie(false)
#4 wp-includes/plugin.php(191): WP_Hook->apply_filters(false, Array)
#5 wp-includes/user.php(3583): apply_filters('determine_curre...', false)
#6 wp-includes/pluggable.php(70): _wp_get_current_user()
#7 wp-includes/class-wp.php(635): wp_get_current_user()
#8 wp-includes/class-wp.php(768): WP->init()
#9 wp-includes/functions.php(1330): WP->main(Array)
#10 jjj2.php(65): wp(Array)
}}}
This happens because `wp-includes/default-filters.php` assumes that the REST API will always be loaded, and the default `pluggable.php` versions of the cookie based authentication functions apply filters that the REST API also uses by default, including the Application Password feature.
----
If the REST API were a SHORTINIT auth requirement, my ''guess'' is that it would have been required earlier in `wp-settings.php`.
This is all somewhat of a catch-22 situation, because `default-filters.php` ''is'' loaded for `SHORTINIT` which is far ahead of when both cookie auth and the REST API are both included.
It is possible to work around this by removing the hooks, but obviously that only counts for today's hooks, and not future hooks if something new is introduced. I think a core code change will be required to decide when & how the REST API filters are applied. 😬",johnjamesjacoby
Future Releases,43686,Shortcodes containing asterisks may create invalid regex breaking the editor,,Shortcodes,,normal,normal,Future Release,defect (bug),new,dev-feedback,2018-04-03T21:31:40Z,2019-01-16T02:41:00Z,"Despite not being a reserved character an asterisk in a shortcode followed by another character will generate invalid regex which breaks the editor.
This code reproduces the issue:
{{{#!php
init();
$wp_rewrite->flush_rules();
remove_filter( 'pre_option_page_on_front', '__return_empty_string' );
}}}
Not terribly elegant, but it can reduce DB I/O by many dozens of reads.",boonebgorges
Future Releases,30300,setUserSetting js function only removes first unwanted character,,Administration,2.7,normal,normal,,defect (bug),new,dev-feedback,2014-11-09T17:08:15Z,2019-06-04T19:26:58Z,"The function comments of the function setUserSetting in `wp-includes/js/utils.js` says the following: ""Both name and value must be only ASCII letters, numbers or underscore (...)"". The function removes the unwanted characters with the js `replace` function, in the current code, it only removes the first occurrence of an unwanted character. This is solved by adding the `g` modifier to the replace regex. See the attached patch.
How to reproduce:
* Open your browsers console while you are logged in to your WordPress installation.
* Run the following command: `setUserSetting('test--', 'bad-value-')` (note that the - character is not allowed)
* The console will return `""test-""` (not `""test""` as expected).
* Run `getUserSetting('test-')`.
* The console returns `""badvalue-""` (not `""badvalue""` as expected).
* You may want to delete the setting by executing `deleteUserSetting('test-')`. ",TV productions
Future Releases,55584,Settings API autoload hook,,"Options, Meta APIs",,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2022-04-18T04:56:49Z,2023-08-31T17:43:17Z,"Currently all settings registered via Settings API is forced to enable autoload, There is no hook to replace this.
Lets imagine just for example:
1. all wordpress plugins is using this to register their settings data. but not delete this value during uninstall.
2. Average wodpress admin install then uninstall 50 plugins in their lifetime.
3. Average autoloaded setting is 100kb per plugin
there will be 5mb autoloaded options which not used anymore. that event is per pageload. Just imagine that. ",hir88en
Future Releases,58380,Setting time limit for updates doesn't always work.,pbiron*,Upgrade/Install,,normal,normal,6.6,enhancement,accepted,dev-feedback,2023-05-23T13:34:30Z,2024-02-12T09:05:39Z,"Warning: set_time_limit(): Cannot set max execution time limit due to system policy in /customers/7/5/e/lucasgent.be/httpd.www/***/wp-admin/includes/class-wp-upgrader.php on line 475
I usually comment out these lines since on my host one.com I ALWAYS get this additional warning line after succesfull updates.
Is there something that can be done, so I don't have to do this for each new WP site...? Maybe a sort of option where you can enable/disable this? ",NekoJonez
Future Releases,31839,Setting error reporting level for wp_debug_mode,,Bootstrap/Load,4.1.1,normal,normal,,enhancement,new,dev-feedback,2015-04-01T16:25:34Z,2023-12-12T20:27:56Z,"Since PHP 5.4.0 `E_STRICT` errors appear as part of `E_ALL` and headers cannot be sent sometimes - stuff that can lead to a whole set of problems. For me, they are useless and annoying - but for others they can be useful.
I just want the possibility to set the `error_reporting` level used in `wp_debug_mode()`. I have applied a small patch to `load.php` as shown below.
I have defined a `WP_DEBUG_LEVEL` constant in `wp-config.php` like so: `define( 'WP_DEBUG_LEVEL', E_ALL & ~E_STRICT );` because I do not want to see the `E_STRICT` warnings.
Afterwards I modified the `wp_debug_mode` function like so:
{{{
#!php
function wp_debug_mode() {
if ( WP_DEBUG ) {
if( !defined( WP_DEBUG_LEVEL ) )
define( 'WP_DEBUG_LEVEL' , E_ALL) ;
error_reporting( WP_DEBUG_LEVEL );
if ( WP_DEBUG_DISPLAY )
ini_set( 'display_errors', 1 );
elseif ( null !== WP_DEBUG_DISPLAY )
ini_set( 'display_errors', 0 );
if ( WP_DEBUG_LOG ) {
ini_set( 'log_errors', 1 );
ini_set( 'error_log', WP_CONTENT_DIR . '/debug.log' );
}
} else {
error_reporting( E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_ERROR | E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING | E_RECOVERABLE_ERROR );
}
if ( defined( 'XMLRPC_REQUEST' ) )
ini_set( 'display_errors', 0 );
}
}}}
Here's the [https://gist.github.com/AlexandruIfrim/8e3626f27344f8f28a87 gist] of it.",aifrim
Future Releases,58903,set_transient() allows invalid transient name,,"Options, Meta APIs",,normal,normal,Future Release,defect (bug),new,changes-requested,2023-07-25T19:33:17Z,2024-02-08T20:13:48Z,"Due to a typo/bug in my plugin code, I found that WordPress accepts empty strings, null, and false for the `$transient` arg, aka: the transient name, in `set_transient()` function which creates transients in the options database with values of simply `_transient_` and `_transient_timeout_`.
That said... the transient created with an empty string continued to work (could be set and get and deleted). Because the typo in my code referenced a variable that held the transient name but was empty, the get, set, and delete function calls worked (annoyingly).
I did observer two issues...
1. In the event two developers cause the same mistake/error, their transients will collide with each other.
2. More importantly, I observed the empty string transient will not be cleaned up by the delete_expired_transients routine. (The Transients Manager plugin must use delete_expired_transients() as it could not delete the transient either.) I will submit a second ticket for this issue.
Upon review of the set_transient() and add_option() code, I observed several opportunities to improve, including:
- return false for empty $transient value
- return false for bool, non-scalar $transient values
- cast $transient as string
- return false for strings with more than 172 characters
These false returns will guide developers to fix issues with malformed $transient names.
I have a pull request to github ready to follow this ticket.",jeremyescott
Future Releases,29795,Set JPEG quality for individual image_size,,Media,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2014-09-29T14:20:54Z,2017-11-10T12:24:43Z,"Based on this idea I would like to work on this topic:
https://wordpress.org/ideas/topic/jpeg-compression-factor-for-different-image_size
Usecase:
If a theme use an image as a full screen background image the image quality doesn't need to be as high as for a featured image or thumbnail.
The difference in file-size would benefit the webspace and the speed on page load.
I can think of two ways to solve it:
1. Add a argument to add_image_size:
{{{
add_image_size( $name, $width, $height, $crop, $quality );
}}}
2. Add filter for it:
{{{
apply_filters( 'jpeg_quality_for_image_size', $quality, $size );
}}}
In both cases the information about the current image size needs to be added to the set_quality or get_quality functions to be available.",Drivingralle
Future Releases,14125,Seperate out non-editable options in edit site,sorich87*,"Options, Meta APIs",,normal,normal,,enhancement,accepted,dev-feedback,2010-06-28T04:11:36Z,2019-06-04T20:41:23Z,"In the edit site screen, blog options which are arrays are shown as SERIALIZED and the textbox is disabled. The attached patch pulls those options out of the options metabox and displays the option name in another metabox below.
Related: #14120",wpmuguru
Future Releases,43208,Separate setting validation from sanitization,,"Options, Meta APIs",,normal,normal,Awaiting Review,enhancement,new,needs-unit-tests,2018-02-01T23:45:12Z,2020-11-06T23:12:25Z,"As widely known, validation is different from sanitization. A value should first be validated and then be sanitized. Historically, WordPress has been mixing these two responsibilities in the `sanitize_option()` function, however it is easily possible to add an extra layer on top of that which maintains full backward-compatibility.
Newer parts of core, such as the Customizer and the REST API, have been dealing with this in a better way, keeping the two separate. We can achieve the same for options themselves too.
I suggest introducing a `validate_option_{$option}` filter that works somewhat similar like the `customize_validate_{$setting_id}` filter used in the Customizer. It passes an empty `WP_Error` object that can be added to. In addition to allow separate validation from sanitization, it also makes handling of validation easier, since it can then automatically set the value to the previous value and call `add_settings_error()`, passing any error messages set, which matches current core behavior.",flixos90
Future Releases,13372,Separate Image sizes for different post types,,Media,4.6.1,normal,normal,Awaiting Review,enhancement,reopened,close,2010-05-13T07:59:07Z,2020-04-18T04:45:23Z,"Would be nice, especially moving forward with custom post types to have the ability to set different image sizes using an additional parameter of `add_image_size()` for different post types: Page, Post, and Custom.",brandondove
Future Releases,14558,Separate Database Table Support for Custom Post Types,,"Posts, Post Types",,normal,normal,Awaiting Review,enhancement,reopened,dev-feedback,2010-08-07T06:55:07Z,2024-03-04T09:51:27Z,"While working on custom post types, I felt need for this enhancements.
This can be achieved by adding an extra argument to the register_post_type function like below...
{{{
register_post_type( 'acme_product',
array(
'labels' => array(
'name' => __( 'Products' ),
'singular_name' => __( 'Product' )
),
'public' => true,
/* Database separation */
'db_tables' => array(
'prefix' => '', //by default, value of $table_prefix will be used. If user sets this value to something, it will be used as prefix for both of following tables
'base_prefix' => '' , //this will control it tables are to be kept sitewide or per blog
'posts_name' => 'acme',
'postmeta_name' => 'acmemeta',
),
);
}}}
This small enhancement (not from coding perspective) will help more plugins authors go for custom post type.
Reasons are - first they will get option to have separate data storage.
Second - if some other badly coded plugin manipulates wp_posts table in some wrong way, it won't have sideeffect on third-party data.
Third - Plugin authors will get more space to experiment as at any time they will be dealing with their own plugin's data.
Of course, one of the goal of this nice feature must be to abstract database layer, but as a developer I feel it would be better if I can have some control over database without loosing power of this new (custom post type) feature.",rahul286
Future Releases,47788,send_headers hook does not work in wp-login or wp-admin,,Administration,5.2.2,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2019-07-28T10:18:17Z,2019-10-20T11:56:12Z,"Assume that I want to start using CSP (Content Security Policy) on my website. I add this to my theme's functions.php:
{{{#!php
Media > Library - edit), the selected image gets overflow in iPhone-6/7/8 portrait mode. So for that, we can apply max-width: 100%.
Thanks,
Shashank.",shashank3105
Future Releases,49963,Security of failed update/rollback,,Upgrade/Install,5.5,normal,major,Awaiting Review,enhancement,new,dev-feedback,2020-04-20T20:31:29Z,2020-04-20T20:44:53Z,"As discussed on the [[https://make.wordpress.org/core/2020/04/16/devchat-meeting-summary-april-15-2020/|previous devchat]] in case of failed update/rollback there are email notifications.
Idea is good: any errors related to Core, Plugin or Theme update should be reported to an email of admin as soon as possible.
But in the real world there are too few properly configured mail servers in wordpress and servers at all. Actually there is no good documentation how to set up email: https://wordpress.org/search/mail
In addition there are a lot of ''lazy'' administrators with email addresses like admin@example.com or something similar.
Thus so many **really important mails** about failed update/rollback will be send to `/dev/null`. It is security issue because website will be inconsistent state indefinite amount of time (for example login plugin not updated and not rollbacked).
1. Do you know how many wordpress installs have properly configured mails?
2. How to motivate admins to use real email addresses?
3. Maybe there is sense to prepare good documentation about mailing in wordpress?
4. Should auto-updates plugin works at all wothout properly configured emergency notifications?
* Original Github Issue: https://github.com/WordPress/wp-autoupdates/issues/83
* Feature Plugin: WP Auto-updates https://make.wordpress.org/core/2020/02/26/feature-plugin-wp-auto-updates/",mahnunchik
Future Releases,57280,Security automatic updates for plugins and themes,,Upgrade/Install,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2022-12-06T02:50:08Z,2022-12-06T17:04:31Z,"The option to enable automatic security updates for plugins and themes would allow users to secure their websites without worrying too much about significant/major breaking features.
This enhancement would allow more granular control of auto-updates without forcing users to update to major releases.
I propose new toggles in the WordPress Updates page under the Plugins and Themes section at wp-admin/update-core.php:
This site's plugins are automatically kept up to date with each new version
**Switch to automatic updates for maintenance and security releases only.
**
This site's plugins are automatically kept up to date with maintenance and security releases.
**Enable automatic updates for all new versions.
**
The same logic would be applied to themes.
Defining what kind of updates apply to security would be challenging, so I propose starting with popular or problematic plugins.",JosVelasco
Future Releases,50181,Second params of get_option() not used,,"Options, Meta APIs",5.4.1,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2020-05-15T15:50:44Z,2020-05-18T10:08:43Z,"Hello
In a develp=opment I have something like
{{{
$options = get_option( 'my_option', array() );
foreach ( $options as $option ) {
// doing things
}
}}}
The option stored seems to be not unserializable.
So when going through https://github.com/WordPress/WordPress/blob/master/wp-includes/option.php#L152 + unserialize() which return false on error the second parameter is not used and we got a Warning.
We're not testing `$options` thinking with the second param setted to `array()` will allways return an array...
",sebastienserre
Future Releases,18513,Searching with explicit post types unsets page post type,,Query,3.2.1,normal,normal,,defect (bug),new,needs-unit-tests,2011-08-24T22:13:08Z,2022-02-12T20:43:32Z,"Tested on WP 3.2.1, Twenty Eleven with no plugins, multisite.
If I explicitly limit a search query via a GET request using an array of post_type values, the post_type for page is automatically excluded.
To reproduce:
* Do a search on a WP install (perhaps through a modified search form), such that the URL is like:
http://example.com/?post_type[]=post&post_type[]=page&post_type[]=attachment&s=Test
or
http://example.com/?post_type[]=post&post_type[]=page&post_type[]=book&s=Test
That's searching for ""Test"" on post, page and attachment/book post types.
* Adding the following to a theme's functions.php:
{{{
add_filter( 'pre_get_posts', 'wpcpt_search' );
/**
*
* @param array $query
*/
function wpcpt_search( $query ) {
if ( ! $query->is_search )
return $query;
print_r( $query->query_vars );
return $query;
}
}}}
That spits out (and seemingly confirmed via the values shown in the Debug Bar plugin) the following at the beginning:
{{{
Array ( [s] => Test [post_type] => Array ( [0] => post [2] => attachment )
}}}
and only returns results for posts and attachments (or books). The fact that key 1 is missing makes me think that page was in the array at some point, but it's been unset, but I can't see where, or why, this might be done.
(When no post_type is set, giving a post_type of 'any', which in turn gives all of the non-excluded_from_search post types, then page is one of the array values, and the search results correctly include pages.)
",GaryJ
Future Releases,12477,Search with special characters and similar terms,nbachiyski,I18N,,normal,normal,,feature request,new,dev-feedback,2010-03-02T17:42:46Z,2019-06-04T20:01:58Z,"I did:Tried searching for terms Metis and Métis
I saw:Those two searches turned up different sets of results.
I expected:The same set of search results, or at least everything when
I searched for Metis.
Can search be smarter when special characters are involved?",mrroundhill
Future Releases,39443,Search Page Template the_category() bug,,"Posts, Post Types",4.7,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2017-01-03T07:38:03Z,2020-01-04T03:30:46Z,"Suppose If I've selected three categories following a structure HR -> Reports -> Daily Reports.
Single.php shows the structure in the right way but when I use the same the_category () function inside Search template then it shows the different result. Rather than showing it in the default structure, it shows it like Daily Reports -> HR -> Reports. In search template the structure changes to order by name. The_category working perfectly in other pages.",cybentizen
Future Releases,41564,Search for hyphenated post templates for post types with underscores,,"Posts, Post Types",,normal,normal,Awaiting Review,feature request,new,dev-feedback,2017-08-04T17:16:29Z,2017-08-13T15:54:10Z,"Custom post type names adhere to the rules within sanitize_key() (lowercase alphanumeric characters, dashes, and underscores).
This means registering a post type `some_post_type` is perfectly fine. The archive and single templates would be be `archive-some_post_type.php` and `single-some_post_type.php`.
These file names do not adhere to the core standard for file names.
Files should be named descriptively using lowercase letters. Hyphens should separate words.
Searching for `archive-some-post-type.php` in addition to `archive_some_post_type.php` would allow this standard to be followed better.",desrosj
Future Releases,29030,Screen Options Poor Update/Rendering Causes Many things to Break,,Administration,3.9.1,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2014-07-26T01:21:46Z,2018-08-08T19:15:02Z,"Screen options dont work properly in many different situations. I noticed the first issue when trying to create a sticky header plugin for the wp_list_table. When scrolling down the page the headers stick to the top by cloning the header with javascript and hiding the other original at the same time. However, If screen options are updated the tables break completly even after the plugin is disabled. Wordpress checks the current table headers to determine which ones are hidden and should be added to the `manageedit-{$post_type}columnshidden` field in the `user_meta` table. So since the cloned table header the plugin created is hidden visually while scrolling up, wordpress thinks that all columns aredisabled and adds all the columns to `manageedit-{$post_type}columnshidden`.
[[Image(http://i.stack.imgur.com/wrYin.png)]]
This is poor practice because it doesn't seperate presentation well enough from the logic used to render screen options. Any user who has access to `wp-admin/edit.php`can completly break their tables if any html/css visually hides the `` or a column-header perhaps by a plugin, or maybe the browser doesn't load a certain script, or perhaps they are just messing with the dev-tools. Beginers that don't know how to properly [remove columns][5], could run into this issue if they ever try to use css instead. `manageedit-{$post_type}column` should not rely on the visibility of and only the actual checked input fields. Also `cb` and `title` should not be allowed to be added to the `manageedit-{$post_type}column`. They should only be able to be removed with `unset`.
----------
**To recreate this issue:**
1. open up firebug/chrome dev tools/etc. on http://www.example.com/wp-admin/edit.php
2. add `thead {display: none;}` to the style editor
3. On the page screen options uncheck at least one column ( this is to ensure `manageedit-{$post_type}columnshidden` is a database field for the current user and if not it creates it )
4. Hit apply to refresh the page
*The tables will now be broken....*
----------
To chck the columns I used the `get_user_meta();` function to print the array of `hiddencolumns` on each post types `edit.php` admin screen notices:
{{{
post_type)
return $post->post_type;
elseif ($typenow)
return $typenow;
elseif ($current_screen && $current_screen->post_type)
return $current_screen->post_type;
elseif (isset($_REQUEST['post_type']))
return sanitize_key($_REQUEST['post_type']);
return null;
}
function get_current_user_manageedit_pagecolumnshidden() {
$current_ptype = get_current_post_type();
$user_id = get_current_user_id();
$key = 'manageedit-'.$current_ptype.'columnshidden';
$single = true;
if(get_user_meta($user_id, $key, $single))
return get_user_meta($user_id, $key, $single);
}
function echo_current_user_manageedit_pagecolumnshidden() {
global $pagenow;
if ( $pagenow !== 'edit.php' )
return;
$columnshidden= get_current_user_manageedit_pagecolumnshidden();
echo ''; print_r( $columnshidden ); echo ' ';
}
add_action('all_admin_notices', 'echo_current_user_manageedit_pagecolumnshidden');
}}}
**Output for the broken tables :**
{{{
Array
(
[0] => cb
[1] => title
[2] =>
[3] =>
)
}}}
----------
After determining that `cb` & `title` were in fact added to the `$meta_value`you need to fix the table. This will do the trick:
{{{
function delete_current_user_manageedit_pagecolumnshidden() {
$user_id = get_current_user_id();
$meta_key = 'manageedit-pagecolumnshidden';
if( get_user_meta($user_id, $meta_key) )
delete_user_meta( $user_id, $meta_key );
}
add_action ('admin_init', 'delete_current_user_manageedit_pagecolumnshidden');
}}}
''Side-Notes:''
*`columnshidden` appears [`wp_ajax_hidden_columns()`][1] & [`get_hidden_columns()`][2]
*client-side functionality appears to be here in [`common.js`][3] which checks for the [hidden table headers][4]
----------
Similar issues with the screen options can be recreated for different situations that have nothing to do with the tables.
**Recreate similar issue on nav-menus.php**
1. Go to http://example.com/wp-admin/nav-menus.php
2. Uncheck all the fields in the *""Show advanced menu properties""* Screen-Options tab
3. Add the screen options filter to hide them from display: `add_filter('screen_options_show_screen', 'remove_screen_options_tab');`
4. Reload http://example.com/wp-admin/nav-menus.php
All of the hidden advanced menu properties will now be broken and are all visible even though they were unchecked. I'm not sure if this is the same issue, but it appears that overall screen options have a high change of not working properly
----------
----------
**Other-Notes**
These issues of broken tables might also have to do with the same functionality problem of how screen options update/render:
http://wordpress.stackexchange.com/questions/31154/wp-list-table-custom-quick-edit-box-post-meta-data-missing-and-columns-change
http://wordpress.stackexchange.com/questions/123182/custom-admin-column-disappearing-when-using-quick-edit?lq=1
http://wordpress.stackexchange.com/questions/144361/wordpress-admin-wp-table-list-show-incorrectly
#21016
[1]: https://github.com/WordPress/WordPress/blob/448275cce483138f53ccfa586b2d28b7fe8b0785/wp-admin/includes/screen.php#L55
[2]: https://github.com/WordPress/WordPress/blob/270a57075c290736387b6551670fde34fb3f1851/wp-admin/includes/ajax-actions.php#L1307
[3]: https://github.com/WordPress/WordPress/blob/448275cce483138f53ccfa586b2d28b7fe8b0785/wp-admin/js/common.js#L29
[4]: https://github.com/WordPress/WordPress/blob/448275cce483138f53ccfa586b2d28b7fe8b0785/wp-admin/includes/screen.php#L17
[5]: http://codex.wordpress.org/Plugin_API/Filter_Reference/manage_$post_type_posts_columns",codecandid
Future Releases,54761,Save the prefered language from login page (since WP5.9),,Login and Registration,5.9,normal,normal,Future Release,enhancement,new,dev-feedback,2022-01-07T17:17:33Z,2022-04-09T08:18:57Z,"Hello,
On WP5.9 a language switcher is added in the wp-login.php. Here is the dev note by @audrasjb https://make.wordpress.org/core/2021/12/20/introducing-new-language-switcher-on-the-login-screen-in-wp-5-9/
I think it should be great if choosing a language here will update the Language user meta to display the back-office in the same language as previously chosen.
As per 1st test made, this doesn't currently update.",sebastienserre
Future Releases,40440,Save permalink without send form,,Rewrite Rules,,normal,normal,Awaiting Review,defect (bug),new,close,2017-04-13T18:52:02Z,2021-12-19T16:37:58Z,"if somebody open wp-admin/options-permalink.php, .htaccess are genereate and save without click submit button.
I report this bug as security issue but during send messages with John Blackbourn we have determined that this isn't a security bug so I add ticket as public.",sebastian.pisula
Future Releases,33924,sanitize_html_class valid characters,,Formatting,4.4,normal,normal,Future Release,defect (bug),new,dev-feedback,2015-09-18T16:39:10Z,2022-09-20T23:57:53Z,"`sanitize_html_class` excludes some increasingly common valid html characters.
In particular the `@` character.
The use of `@` may not be extremely common for class names but it is being encouraged by some pretty renowned folks in the area of class naming conventions. http://csswizardry.com/2015/08/bemit-taking-the-bem-naming-convention-a-step-further/#responsive-suffixes
Actually pretty much anything is now valid for html classes except for spaces or tabs. I also use the `/` quite a bit in my classes but I thought I'd start with the `@` .",m-e-h
Future Releases,50855,sanitize_file_name function not working as expected if there is '%20' in filename,audrasjb*,Formatting,5.4.2,normal,normal,Future Release,defect (bug),accepted,dev-feedback,2020-08-05T08:00:11Z,2022-10-07T21:04:13Z,"We have added '%' as a special character in `$special_char` variable
We are also replacing '%20' with '-'
Here the sequence of str_replace was not appropriate
We need to replace '%20' with '-' before all the special character are replaced
Current behavior:
- Filename Before: `this%20is%20example.png`
- Filename after sanitization: `this20is20example.png`
Expected behavior:
- Filename Before: `this%20is%20example.png`
- Filename after sanitization: `this-is-example.png`
File reference: https://github.com/WordPress/WordPress/blob/master/wp-includes/formatting.php
Function name: sanitize_file_name",dishitpala
Future Releases,54190,sanitize_file_name disallows acute accents and left smart apostrophe,,Media,5.5,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2021-09-27T14:23:29Z,2023-10-04T19:21:40Z,"The following change to line 1991 of wp-includes/formatting.php will disallow acute accents and left smart apostrophe in file names
{{{
$special_chars = array( '?', '[', ']', '/', '\\', '=', '<', '>', ':', ';', ',', ""'"", '""', '&', '$', '#', '*', '(', ')', '|', '~', '`', '´', '!', '{', '}', '%', '+', 'ʻ','’', '«', '»', '”', '“', chr( 0 ) );
}}}",jdorner
Future Releases,43723,Sanitize user_contactmethods output,,Administration,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2018-04-09T14:12:16Z,2019-01-17T01:14:01Z,"Data supplied in an array to the user-edit.php page via the filter 'user_contactmethods' is not properly escaped when it is outputted.
As you can see in [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/user-edit.php#L527 user-edit.php] the values of the $name and $desc variables are directly echoed using echo.
I'd expect it to use the WordPress Core [https://developer.wordpress.org/reference/functions/esc_attr/ esc_attr()] as the data is used part of an html tag's attribute and therefor should be limited to what is allowed inside an html attribute. ",BjornW
Future Releases,57021,Sanitize should accept broader types,,Formatting,6.2,normal,normal,Awaiting Review,enhancement,new,close,2022-11-07T14:39:00Z,2024-02-07T20:21:43Z,"by default $_GET/$_POST can be string|array type.
All sanitize functions accept only string, which makes it necessary to validate $_GET/$_POST for `is_string` all the time before calling sanitize function to avoid PHP notices.
Instead sanitize function should accept mixed param and validate string internally.",kkmuffme
Future Releases,41631,Same Term Not Added,,Taxonomy,4.8,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2017-08-13T20:24:40Z,2017-09-21T11:42:48Z,"Using latest version of WordPress, default theme, all plugins disabled. Problem first appeared in version 4.8 and continues with 4.8.1.
To recreate the issue:
1. Create regular post (“Posts”)
2. Add a new term to the Categories meta box
3. Save the term (it will appear on top of the list with a check mark next to it)
4. Add the same term again. Nothing happens and the term is not added
Version 4.7.5 and below would activate the term and put to the top of list. This was helpful when adding a string of terms and some of them were already in the database. ",vaprak
Future Releases,47670,RSS widget creates an accessibility problem when used more than once,audrasjb,Widgets,,normal,normal,Future Release,defect (bug),reviewing,dev-feedback,2019-07-09T18:49:02Z,2021-11-12T17:46:02Z,"Please consider the following patch to improve accessibility.
Accessibility guidelines in WCAG's standard 2.4.4 Link Purpose requires that link text should provide a purpose or context for the link.
In the RSS widget, the link text for the link to the RSS feed itself is an image of the RSS icon; its alt text is ""RSS"" which programmatically determines the link text. This passes the referenced standard.
A problem occurs when multiple instances of the RSS widget are used. There are then multiple links with link text ""RSS"", each of which lead to different URLs. The text ""RSS"" then does not provide enough context for visitors to know what each ""RSS"" link leads to.
The solution is the make each RSS link text unique to each feed's title, thus providing the necessary context.
Simply prepending the title of the widget instance adds the necessary context to the link text without using any additional words which could has i18n issues.
In class-wp-widget-rss.php (lines 89-91 in 5.2.2):
From:
{{{#!php
' . esc_html( $title ) . ' ';
}
}}}
To:
{{{#!php
' . esc_html( $title ) . ' ';
}
}}}
No harm is done when only a single instance of the RSS widget is used because the RSS link text is simply more explicit.",tpaw
Future Releases,6269,RSS Import Doesn't Properly Strip CDATA Tags,,Import,2.3.3,normal,normal,WordPress.org,defect (bug),new,dev-feedback,2008-03-18T00:58:13Z,2019-03-15T00:40:20Z,"When importing an RSS feed that uses the tag as opposed to , I noticed that WP's RSS import doesn't strip the CDATA tags as it does for the .
=========Code Lines (83-87)===============
{{{
if (!$post_content) {
// This is for feeds that put content in description
preg_match('|(.*?) |is', $post, $post_content);
$post_content = $wpdb->escape($this->unhtmlentities(trim($post_content[1])));
}
}}}
=====================================
I tweaked the code to solve the problem (see below)
==========Tweaked Code===============
{{{
if (!$post_content) {
// This is for feeds that put content in description
preg_match('|(.*?) |is', $post, $post_content);
$post_content = str_replace(array (''), '',$wpdb->escape($this->unhtmlentities(trim($post_content[1]))));
}
}}}
======================================
I'd be happy to submit a patch, except I'm not quite that savvy yet. It would be great it someone could incorporate it. Thanks.",sweetdeal
Future Releases,58281,Rollback Auto-Update (Rollback part 3),afragen,Upgrade/Install,6.3,normal,normal,6.6,enhancement,assigned,dev-feedback,2023-05-10T02:31:58Z,2024-02-21T18:22:14Z,"This is Rollback part 3. It began with `move_dir()` in WP 6.2 for part 1. Part 2 was completed with #51857 in WP 6.3. This brings us to part 3.
Part 3 is Rollback for auto-updates. When manually updating plugins if the plugin has a fatal error on reactivation, the plugin is prevented from reactivating. Unfortunately, during an auto-update, this reactivation check doesn't occur and the the next time the site runs users will see the WSOD.
Rollback Auto-Update performs a similar re-activation check and if there is a fatal error it is captured in an error handler and the previously installed plugin is restored. If this occurs an email will be sent notifying the site admin of the failed update and rollback.
After the rollback, the pending auto-updating for core and theme updates are restarted.
This code is currently running for everyone who has the [https://wordpress.org/plugins/rollback-update-failure/| Rollback Update Failure] feature plugin installed.
I personally have been testing this using a plugin that will fatal if the update occurs. The plugin is on my test site, active, and set to auto-update. I have been running like this since the beginning of the year.
The PR is slightly different than the code in the feature plugin. Please test, run the feature plugin on your site, and review the code in the PR. Mostly give us your comments and feedback.
props @costdev and @pbiron for continuing code review, rubber ducking, and sanity checks.",afragen
Future Releases,36939,Role groups,,Role/Capability,,normal,normal,,enhancement,new,dev-feedback,2016-05-25T02:17:46Z,2019-06-04T21:23:29Z,"WordPress's roles & capabilities API has support for allowing users to have multiple roles, and recent improvements to the Users list table have helped improve the administrator experience a bit by showing all roles rather than just the first one for each user.
I think what makes multiple user-roles confusing (or maybe less valuable) is that WordPress by itself does not directly benefit from allowing users to have multiple roles, because the existing roles are designed to blanket all of WordPress's bundled functionality.
I'd like to propose the introduction of Role Groups, as a layer that lives one layer above the main `WP_Roles` object to allow for groups of roles to be registered, enabling for users to have at least 1 role from each role group.
----
For example:
* You install bbPress, and Bob cannot publish posts but can moderate the forums
* You install WooCommerce, and Jane can contribute posts to the blog, and can also buy items from the store
* You install BuddyPress, and while Chris can administrate posts, pages, and media, he cannot moderate the community
In the above scenarios, each of these plugins would register their own role groups, and any user could easily have 1 role for each ""section"" of the same 1 WordPress site.
----
How could WordPress core use this?
* Create a role group for Posts, Pages, Media, Comments, and Users
* Ones ability to Edit posts should not assume they can moderate comments
* Ones ability to moderate comments should not assume they can publish posts
* Ones ability to upload media & attachments should not assume they can publish pages
* Ones ability to edit an existing user should not assume they can upload media
----
How does this complicate things?
Depending on how deeply this is implemented, potentially greatly, or not at all for vanilla WordPress installations.
* If we keep WordPress's built-in roles identical to how they are today, they become 1 role group that grants access to Posts, Pages, Media, Comments, and Users; then plugins can define their own role groups, and we make sure WordPress has an adequate interface for assigning multiple roles for each user.
* If we separate WordPress's roles into groups for each object type, backwards compatibility is a huge issue, as well as how confusing does it make granting access and assigning default roles for each group.
* We may be able to remove the ""Default Role"" setting UI entirely, and leave it to plugins to reopen this functionality for improved support for multiple roles.
----
What do we do now?
Let's talk this through, decide if it's worthwhile, and maybe work towards something viable. Much of this can happen without much (if any) modification to WordPress core. Worst case, we uncover more areas of WordPress that can be improved to support multiple roles per user, and address those in separate tickets. Best case, we make the existing roles & capabilities API more plugin-friendly.",johnjamesjacoby
Future Releases,21682,Rewrite endpoints are lost if a custom category or tag base is defined,DrewAPicture,Rewrite Rules,3.4,normal,normal,,defect (bug),reviewing,dev-feedback,2012-08-24T15:57:04Z,2019-06-04T21:07:44Z,"== Problem ==
So this little bug was winding me up for a while.
The standard approach according to the codex for adding rewrite endpoints is to call the `add_rewrite_endpoint()` function within the init hook. So far so good.
The problem occurs whenever `WP_Rewrite::init()` is called ''after'' the init hook. It resets the endpoints array and so when rewrite rules are subsequently generated through the options-permalink.php admin page the rewrite rules are unknown to the system and hence don't work.
`WP_Rewrite::init()` is called within `WP_Rewrite::set_category_base()`, `WP_Rewrite::set_tag_base()` and `WP_Rewrite::set_permalink_structure()`.
In the latter it is only called if the permalink structure has changed so on first save of a change endpoints are lost. In the other 2 it is called every time if the slug doesn't match the default so rewrites are always lost.
== Solutions: ==
1. add an action hook to the start of `WP_Rewrite::rewrite_rules()` where endpoints should be added
2. store the endpoints at the start of `WP_Rewrite::init()` and restore them at the end
3. don't reset them at all
I think solution 3 would make sense, the endpoints could be defaulted to an empty array and I can't see any reason to want to reset them anyway.
I've attached a simple patch that works (for me at least).
'''NB.''' this problem may also affect the `$extra_rules` and `$non_wp_rules` but I haven't tested that theory yet.",sanchothefat
Future Releases,53842,Review the type of select return values,,Build/Test Tools,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2021-07-30T22:06:25Z,2021-07-30T22:06:25Z,"In addressing ticket #46149, four tests were encountered which were testing (part of) a return value of WP Core functions, but were found to be using the wrong value type in this comparison.
This was discovered due to the fact that the `assertContains()` method in PHPUnit uses strict type comparisons as of PHPUnit 8.0.2.
For the time being, the tests will be updated to reflect the REAL return type per proposed commit https://github.com/jrfnl/wordpress-develop-official/commit/64dd09d5c292c3eac80419d5a1a325dab453a5ed
This ticket is being opened to follow up on this as it should be investigated whether the return type of these WP Core function as-is is actually correct and the test update was therefore justified. Or whether the test update should be reverted and the actual WP Core functions should be updated.
== Details
=== `Tests_Comment_GetPageOfComment::test_page_number_when_unapproved_comments_are_included_for_current_commenter()` and `Tests_Comment_GetPageOfComment::test_page_number_when_unapproved_comments_are_included_for_current_user()`
Both these tests generate a comment ID using a test Factory class:
{{{#!php
comment->create(
$comment_args
);
}}}
`$new_unapproved` will now contain a comment ID as an integer.
This integer is expected to be included in a list retrieved via the [https://developer.wordpress.org/reference/functions/get_comments/ `get_comments()`] function and filtered via [https://developer.wordpress.org/reference/functions/wp_list_pluck/ `wp_list_pluck()`].
Based on these two tests, the `comment_ID` as returned in the array retrieved via `get_comments()` is a string, not an integer.
So the questions for these two tests are:
* Should the `comment_ID` returned by `get_comments()` be a string or an integer ?
* If the `get_comments()` function should remain unchanged, should the TestCase::factory()->comment->create()` method be adjusted to return a string for the ID value instead of an integer ?
* If the answer to both the above questions is ""no"", no further action is needed once the proposed commit mentioned above has been committed.
=== `WP_Test_REST_Post_Meta_Fields::test_set_value_multiple_custom_schema()` and `WP_Test_REST_Term_Meta_Fields::test_set_value_multiple_custom_schema()`
These two tests both update the post meta of a WP post via a REST API POST request.
The data to be set is passed as integers:
{{{#!php
array(
'test_custom_schema_multi' => array( 2, 8 ),
),
);
$request->set_body_params( $data );
$response = rest_get_server()->dispatch( $request );
}}}
The test subsequently requests the post meta information via a call to [https://developer.wordpress.org/reference/functions/get_post_meta/ `get_post_meta()`] and ensures that the returned array contains both values.
The values returned in the array from `get_post_meta()`, however are ''strings'', not integers.
So the questions for these two tests are:
* Where does the type change from integer to string happen ?
* Is the data when set via the REST API being saved correctly ?
* Does the Core code need to change or is the test update correct ?
In this case, I suspect the type change ''may'' be due to the fact that all data received from `$_POST` will always be in string format, however, the handling of these API requests should be investigated to be sure.
",jrf
Future Releases,43812,Retrieving Blog/site description in multisite,,Networks and Sites,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2018-04-19T16:38:51Z,2019-01-16T06:50:09Z,"Hello,
In a project on a Multisite I need on site 1 (for example) to retrieve description on site 2.
With
{{{
get_blog_details()
}}}
I'm able to retrieve some info (name, url...) but not the description
",sebastien@…
Future Releases,50027,Retire Phpass and use PHP native password hashing,,Security,,normal,normal,Awaiting Review,defect (bug),new,needs-unit-tests,2020-04-29T10:36:12Z,2023-10-13T01:11:52Z,"PHP comes with built-in password hashing functions since PHP 5.5. Now that we have updated the minimum requirements to PHP 5.6, we can rely on PHP to provide us with password hashing mechanisms that ensures a cryptographically secure random numbers are are used for salt, and the hashes are backwards compatible.
I created and maintain [https://wordpress.org/plugins/password-hash/ PHP Native Password Hash] plugin to swap WordPress's baked in Phpass with PHPs.
**0.Phpass recommends to use PHP native hashing**
> At this time, if your new project can afford to require PHP 5.5+, which it should, please use PHP's native password_hash() / password_verify() API instead of phpass.
I propose that we upgrade the hashing mechanisms to password_hash()/password_verify/password_needs_rehash() combo.
**1.We do not need to force users to change their passwords.**
Phpass-hashed passwords have the signature `$P`, and the very old MD5 hashes are fewer than 32 characters long. We will inspect the signature first, and if the password is using the old standard, we will validate the password one last-time, and then use password_hash() to rehash it. From this point forward, that user is ""upgraded"" to the new mechanism.
**2.Expose a filter for plugins**
The plugin I maintain supports BCrypt, Argon2I, and Argon2ID for hashing. We can expose a filter that WordPress core emits so plugins can change the hashing algorithm if necessary.
**3.Use BCrypt as the default algorithm**
If a plugin does not take over, WordPress core will use BCrypt. BCrypt is secure, and is available in any PHP version 5.5, 5.6, 7.* and 8.*.
**4.Do not remove Phpass**
We will **not** remove Phpass from WordPress core. This is needed for backwards compatibility to ensure that existing users will eventually be updated.
The end goal is that we seamlessly migrate active users passwords to better mechanisms without breaking functionality for existing users. Frameworks such as Drupal and phpBB (which used phpass in the past) have moved to better mechanisms since the minimum required PHP versions have been updated, and we can easily follow suit.
If the maintainers agree, I would be overjoyed to collaborate on patches.
",ayeshrajans
Future Releases,34116,"Rethink default install content like ""Sample Page"", etc.",,General,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2015-10-01T14:30:09Z,2021-04-10T11:17:18Z,"New installs of WordPress come built in with ""Sample Page"", a default blog post, and a built in comment.
I would like to propose that we rethink this content. In its current state, all it means is that any site owner needs to make some changes to their website, including either trashing or changing the sample page, editing the information in it and the sample blog post, and deleting the sample content.
IMO, there are a variety of steps I'd prefer to take, but I'll rank a few in terms of what I think have few consequences to options that may be more of a difficult sell.
1. Change the name of Sample page to ""About"". Nearly every website has an about page. It's a much better option in my opinion. It's even the recommendation of the current sample page.
2. Delete the sample comment on Hello World altogether. People get web comments, this just has to be trashed on all new installs.
3. Change the status of ""Hello World"" to draft. It's not ready to publish, so let's not make it published.
4. Change ""uncategorized"" to ""general"" or something that's not so awful. (I know this has been discussed elsewhere a good bit but I'd be sad to not mention it)
Currently the sample content is used as a defacto new user walkthrough. I would rather see proper new user onboarding, personally. But even if that's a step too far, I'd like to make some of these changes to the default content. Numbers 1 and 2 feel particularly doable to me, and 3 and 4 would be really nice additions.",krogsgard
Future Releases,58427,Retain existing user session when changing password,,Users,4.0,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2023-05-30T03:59:13Z,2023-05-30T04:45:30Z,"When a user changes their password, their existing user session is ignored and a new session is started.
This happens due to `wp_update_user()` not passing the current session token to `wp_set_auth_cookie()`.
https://github.com/WordPress/wordpress-develop/blob/e82251df5bd59fb4327d0b0aa7a57ade20fe97c2/src/wp-includes/user.php#L2717-L2735
This can cause problems for some plugins which use the `attach_session_information` hook, or, which add additional information to the current session through `WP_Session_Manager::update()`.
Other issues that occur is when the password is updated through the rest api, is that a new session will be created, but the response (and rest of the rest api processing) will be operating with the old session token, as that's what's set in `$_COOKIE`. So if any user fields in the rest-api response are reliant upon a piece of session metadata, it'll be incorrect for the following HTTP requests from the user.
The workaround for plugins is to hook to `attach_session_information` and when a new session is being created for the current user, copy the current sessions metadata over to the new session. This is less than ideal, as it's not clear that the new session is definitely the same as the clients session (ie. The newly created session might not come from `wp_set_auth_cookie()` and might be a new session created for another purpose).
PR attached, which retains the existing session when changing the password. ",dd32
Future Releases,44805,Resurrecting post from trash reverts its slug,,"Posts, Post Types",4.9.7,normal,normal,Awaiting Review,defect (bug),assigned,dev-feedback,2018-08-16T06:26:13Z,2018-08-30T00:53:02Z,"=== Steps to reproduce
Using the REST API:
* Create a post
* Delete the post (not forced)
* Update the post's slug
* Update the post's status to `publish`
==== Create
`POST wp-json/wp/v2/posts`
{{{#!json
{
""status"": ""publish"",
""slug"": ""a"",
""title"": ""a""
}
}}}
==== Delete
`DELETE wp-json/wp/v2/posts/`
==== Update slug
`POST wp-json/wp/v2/posts/`
{{{#!json
{
""slug"": ""foo""
}
}}}
==== Update status
`POST wp-json/wp/v2/posts/`
{{{#!json
{
""status"": ""publish""
}
}}}
=== Expected
Post should be published with a slug of `foo` (the updated value)
=== Actual
Post is published with a slug of `a` (the old value)
",ajmccluskey
Future Releases,41672,REST create user: existing_user_login is returned before existing_user_email,shooper,Users,4.7,normal,normal,Future Release,enhancement,assigned,dev-feedback,2017-08-19T01:37:10Z,2021-11-08T20:17:57Z,"When I post to `/wp-json/wp/v2/users` to create a user:
{{{
{
""email"": ""brianhenryie@gmail.com"",
""username"": ""brianhenryie"",
""password"": ""password""
}
}}}
and a user with that username and email address exists, the response is:
{{{
{
""code"": ""existing_user_login"",
""message"": ""Sorry, that username already exists!"",
""data"": null
}
}}}
whereas a more useful response would be the existing_user_email response:
{{{
{
""code"": ""existing_user_email"",
""message"": ""Sorry, that email address is already used!"",
""data"": null
}
}}}
which is learned once the original POST is updated with a new username.
i.e. existing_user_email tells a user if they already have an account. This information could be used to attempt to log in.",bbrian
Future Releases,48885,"REST API: Support reading public settings, implement context handling",spacedmonkey,REST API,3.7,normal,normal,Future Release,enhancement,assigned,dev-feedback,2019-12-05T17:09:25Z,2022-07-18T09:32:20Z,"It would be good to make it possible to read and update individual site settings at
`/wp/v2/settings/title`
for example.
This is needed as part of https://github.com/WordPress/gutenberg/pull/18760",scruffian
Future Releases,40477,REST API: Does NOT Trigger New User Notifications!,,Users,4.7,normal,normal,Awaiting Review,defect (bug),new,needs-unit-tests,2017-04-19T07:35:19Z,2017-12-04T05:11:43Z,"If you create new users with WP REST API. The notification for new WordPress users via email does NOT get triggered. I tried it on a fresh install. Used the [Email log](https://wordpress.org/plugins/email-log/) WP plugin to test that no emails were sent.
",mrahmadawais
Future Releases,38878,REST API: Default query for users endpoint doesn't scale,,REST API,4.7,normal,normal,Future Release,defect (bug),new,dev-feedback,2016-11-20T11:55:53Z,2019-07-11T18:34:11Z,"The user query is performed with the `has_published_posts` argument which generates the following query
> SELECT SQL_CALC_FOUND_ROWS wp_users.* FROM wp_users INNER JOIN wp_usermeta ON ( wp_users.ID = wp_usermeta.user_id ) WHERE 1=1 AND wp_users.ID IN ( SELECT DISTINCT wp_posts.post_author FROM wp_posts WHERE wp_posts.post_status = 'publish' AND wp_posts.post_type IN ( 'post', 'page', 'attachment', 'forum', 'topic', 'reply' ) ) AND ( wp_usermeta.meta_key = 'wp_2_capabilities') ORDER BY display_name ASC LIMIT 0, 10
'forum', 'topic', and 'reply' are bbPress' post types. We use bbPress on wordpress.org/support/ where I noticed in the logs that the server/database can't handle the request.
I'm currently not sure how and if this needs to be fixed but having at least a ticket for it might help others.",ocean90
Future Releases,56919,REST API term embed 401 - not allowed to view terms for this post,,REST API,6.0.3,normal,blocker,Awaiting Review,defect (bug),new,dev-feedback,2022-10-27T10:30:13Z,2023-10-29T05:52:08Z,"Setup
1. WP 6.0.3
2. CPT attached with multiple taxonomies all of them registered as `show_in_rest` `true`
When calling `GET` at CPT rest endpoint with `&embed=1` the path `_embedded.wp:term` returns 401 json object with error message `Sorry, you are not allowed to view terms for this post`.
This issue is breaking my applications and I had to rollback to `6.0.2`",prionkor
Future Releases,43209,REST API should take settings errors into account,,"Options, Meta APIs",,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2018-02-01T23:59:10Z,2018-02-01T23:59:10Z,"The `WP_REST_Settings_Controller` should notify the client when updating a setting fails due to an invalid value provided per the setting's `sanitize_callback` (should actually be validation, see related #43208). Currently this goes completely unnoticed.
While `update_option()` doesn't return any information like that, it may be possible to use the information passed to `add_settings_error()` in case of a validity issue, and forward that to the client by returning a `WP_Error` with the message.",flixos90
Future Releases,49871,REST API post link should be permalink for scheduled posts,,Permalinks,4.7,normal,normal,Future Release,enhancement,new,dev-feedback,2020-04-10T19:13:25Z,2020-07-02T13:35:48Z,"Scheduled posts now return something like this:
{{{
{
""id"": 34,
""date"": ""2039-12-09T20:19:00"",
""slug"": ""message-from-the-past"",
""status"": ""future"",
""link"": ""https://example.com/?p=34"",
}
}}}
But I believe it makes more sense to actually return the permalink as link:
{{{
{
""id"": 34,
""date"": ""2039-12-09T20:19:00"",
""slug"": ""message-from-the-past"",
""status"": ""future"",
""link"": ""https://example.com/2039/12/09/message-from-the-past"",
}
}}}
The only caveat is that we will need to create 301 redirects in case the slug changes (which is the case for published posts already).
For example. if the slug becomes `old-message` the new link would be `https://example.com/2039/12/09/old-message`, but visiting `https://example.com/2039/12/09/message-from-the-past` should redirect to the new URL.
There has been some discussion about this over here: https://github.com/WordPress/gutenberg/pull/21410#issuecomment-612132635",Jules Colle
Future Releases,57088,Rest API improve time response with cache,,REST API,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2022-11-12T12:29:53Z,2022-11-15T11:36:11Z,"Hi, again :)
I'm developing wordpress websites but only using the rest api, as Headless CMS.
I've blocked the frontend, and created custom endpoints to be consumed by a React application.
So, more than a year pass and I'm consumed by an issue on my websites, the rest api it's little slow like 300ms-1000ms of time response this is a lot.
As I know, I can cache the responses using transient api, I've tried that, but without success.
What is the best solution to avoid database access?
1. Should I create a wp-content/object-cache.php and cache the responses of endpoint?
2.Advanced-cache.php can help me to improve the response time of rest api?
3. do we have a method/hook/filter to check if cache exist before WordPress load everything /plugins/themes etc...? For example on https://developer.wordpress.org/reference/hooks/request/ and this hook, returns the response from cache without having to load every file from WordPress.
I tried some cache plugins, but doesn't improve the speed?
Any example to do this correctly, to improve the rest api time and database overload.
Thanks
",emanuelx
Future Releases,36447,Responsive preview icons in Customizer need tooltips,iamjolly,Customize,4.6,normal,normal,Future Release,enhancement,assigned,dev-feedback,2016-04-08T02:44:59Z,2021-11-09T15:43:27Z,"The new icons at the bottom of the Customizer for toggling the preview window of your site really need tooltips to indicate what they're for.
Just like the tooltips on the Visual Editor icons, other icons in the Dashboard should have tooltips as well. As leading usability expert Jakob Nielsen explains;
>A user’s understanding of an icon is based on previous experience. Due to the absence of a standard usage for most icons, text labels are necessary to communicate the meaning and reduce ambiguity.
https://www.nngroup.com/articles/icon-usability/
Even the Google Design Guidelines recommend tooltips for icons
https://www.google.com/design/spec/components/tooltips.html#
I originally raised this as a post on the [https://wordpress.org/support/topic/responsive-preview-icons-in-customizer-need-tooltips Beta forum] but it was suggested that since it's getting late in the 4.5 release cycle it would be best to raise it as a Trac ticket.",ahortin
Future Releases,36477,Responsive images (srcset) can include images larger than the full size,,Media,4.4.2,normal,normal,Future Release,defect (bug),assigned,needs-unit-tests,2016-04-11T13:27:58Z,2023-09-01T15:35:00Z,"In many cases, I saw the resized and smaller images are much larger than the origin image, especially for the optimized images, it will make no sense to do that resize in this case, the worst case I've seen is about 13x larger than the origin and bigger image.
If an example can help to explain the problem, please take this picture:
https://cdn2.peterdavehello.org/wp-content/uploads/2016/04/status.png
Many thanks!",peterdavehello
Future Releases,57455,"respond_to_request: store matched handlers across other methods, saving a call to get_routes().",,REST API,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2023-01-12T21:35:26Z,2023-01-19T23:25:46Z,"== Current Behavior
Out of the box, API requests (example: GET http://localhost:8889/wp-json/wp/v2/posts) will make two calls to `WP_REST_Server::get_routes()`.
**Call 1**: `WP_REST_Server::dispatch()` -> `WP_REST_Server::match_request_to_handler()` -> `WP_REST_Server::get_routes()`.
This is the main path used when serving the request. It gets the routes, matches to the request, then determines which handler will be used for the request. Later, `WP_REST_Server::respond_to_request()` saves the matched route and matched handler.
**Call 2**: `rest_send_allow_header()` -> `WP_REST_Server::get_routes()`.
This is used to set the allow header of the response (example: ""Allow: GET, POST, HEAD"").
This header shows all HTTP methods that are allowed to be sent on the same route. This information was already found in the ""Call 1"" pathway above, but it was discarded.
To find the allowed headers, `rest_send_allow_header()` calls `WP_REST_Server::get_routes()` which rebuilds information for all existing routes (but we only need information for one route).
== Objective
To reduce the number of calls to `WP_REST_Server::get_routes()` per single request from 2 to 1.
While this only saves 0.1ms on a fresh site, on sites with large custom APIs, this could save 10ms or more.
== Patch
When `WP_REST_Server::match_request_to_handler()` -> `WP_REST_Server::get_routes()` finds the matching route,
it will now not only remembers the exact matching handler, but all other handlers matching the route with different http methods.
For example, imagine an ""/a/b/c"" route exists with GET and POST handlers.
Previous to the patch, `match_request_to_handler()` would find the GET /a/b/c handler and remember it, setting it on `$response->matched_handler`.
After the patch, a new variable `$response->all_methods_matched_handlers` is set containing the array: [ (GET /a/b/c handler), (POST /a/b/c handler) ],
`rest_send_allow_header()` now looks for `$response->all_methods_matched_handlers` and uses it to set the Allow header if possible, saving a call to `WP_REST_Server::get_routes()`.
This was my way to save the information found in call 1 and to pass it along to call 2, but I definitely open to other ideas of accomplishing the same thing.
== Basic Testing
Add a log message when get_routes is called:
{{{#!diff
--- a/src/wp-includes/rest-api/class-wp-rest-server.php
+++ b/src/wp-includes/rest-api/class-wp-rest-server.php
@@ -862,6 +862,7 @@ class WP_REST_Server {
* `'/path/regex' => array( array( $callback, $bitmask ), ...)`.
*/
public function get_routes( $route_namespace = '' ) {
+ error_log( 'calling get_routes' );
$endpoints = $this->endpoints;
if ( $route_namespace ) {
}}}
Query an endpoint:
`curl http://localhost:8889/wp-json/wp/v2/posts`
Before the patch: See two calls to get_routes
After the patch: See one call to get_routes
== Alternative Approaches
#39473 adds a per-request cache to get_routes. I'd be happy to rework this if this is a better method.
",mreishus
Future Releases,41236,Reset Password button text during the registration process,,Login and Registration,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2017-07-04T14:05:11Z,2017-07-06T08:51:21Z,"After completing the registration form at wp-login.php, the user is sent a ""Your username and password"" email which contains a link to the reset password page. Here, the user can set a password.
The button on the page reads ""Reset Password"".
The button text doesn't quite make sense. The user isn't resetting their password; instead, they are setting a password for the first time.
Something like ""Set password"" seems more appropriate. ",henry.wright
Future Releases,39687,Request headers sent incorrectly from `WP_Http` to `Requests`,,HTTP API,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2017-01-25T12:02:48Z,2017-01-27T08:51:23Z,"While having a closer look at Requests (and also the way it is used in WP), I noticed something that appears to be a bug.
The `$headers` variable that is passed from `WP_Http::request()` to `Requests::request()` is an array of `$key => $value` pairs where `$value` may be an array itself in case multiple values for that header have been passed to `WP_Http::request()`. However, the Requests library expects each `$value` of the `$headers` array to always be a string, as it uses `sprintf()` with it directly (the passed `$headers` array is sent through `Requests::flatten()`).
This can cause issues when specifying multiple headers of the same name.",flixos90
Future Releases,43733,Replace Underscores.js with Lodash.js,adamsilverstein,External Libraries,,normal,normal,Awaiting Review,task (blessed),assigned,dev-feedback,2018-04-10T14:30:08Z,2023-07-17T23:20:28Z,"Should we replace Underscores.js with Lodash.js?
[https://wordpress.slack.com/archives/C5UNMSU4R/p1523367735000195 Discussed in Slack today (April 10th, 2018)].
It was suggested for converting WP Core to lodash, [https://github.com/facebook/jscodeshift jscodeshift] could be leveraged.
Here is a list of [https://github.com/lodash/lodash/wiki/Migrating API pairings between lodash and underscores].
Concerns:
Lodash 5.0 is set to have some [https://github.com/lodash/lodash/wiki/Roadmap backwards incompatible changes] that could make the migration awkward.
General backwards compatibility concerns as well. How do we want to handle Backwards Compat? Most likely only core will be changed, and a migration path/tool will be offered out to theme/plugin authors.",ChopinBach
Future Releases,10955,Replace ThickBox,,External Libraries,2.9,normal,normal,Future Release,enhancement,reopened,dev-feedback,2009-10-14T14:37:42Z,2023-11-10T16:01:17Z,"Have you thought about replacing ThickBox? It is no longer under development (as their site says) and it doesn't conform to standard jQuery plugin practices. For example, I'm trying to use it for a plugin of mine and I'm wanting to tie into the ""onClose"" event for ThickBox which isn't too easily done. I know I could just include one of the other plugins, like colorbox, with my plugin but I think it'd be a great service to other developers if you included a more flexible library.
(I would have assigned this to 3.0+ but the option isn't available.)",aaron_guitar
Future Releases,30233,Replace or rewrite domain_exists() for more accurate usage,,Networks and Sites,3.0,normal,normal,,enhancement,new,dev-feedback,2014-11-02T01:47:25Z,2019-06-04T20:09:42Z,"`domain_exists()` was added in [https://mu.trac.wordpress.org/changeset/543 MU:543] in almost its current form. The enforcement of trailing slashes on paths was added in #20589 and a filter was added in #21442.
A few notes:
* The lookup for a domain and path combination is restricted to one network. This allows the same domain and path combination to be used on multiple networks, which should not be default behavior.
* The name, `domain_exists()`, implies a check for domain. It is really checking for a full site URL.
* While it is entirely possible to ignore the result by providing your own in the filter, it would be nice to not always require this for multi-network configurations.
My **guess** is that the original intent was to ensure a subdomain or path was not present when creating a site on an open network.
In thinking of how to address this, these two possibilities came to mind.
* Deprecate `domain_exists()` and wrap a new function that does a larger check. `wp_get_site()` could work alongside `wp_get_sites()` and support domain/path lookup.
* Allow the current `$site_id` argument to be `null` (for all), or an array (for many), in addition to the current `int` expectation.
",jeremyfelt
Future Releases,53938,replace core uses of wp_parse_url() with PHP's native parse_url(),,HTTP API,,normal,normal,Awaiting Review,enhancement,new,close,2021-08-16T20:58:40Z,2021-08-17T16:38:31Z,"[https://developer.wordpress.org/reference/functions/wp_parse_url/ wp_parse_url()] was introduced in #34408 to get around URL parsing failures of PHP's [https://www.php.net/manual/en/function.parse-url parse_url()] in PHP < 5.4.7.
With the minimum supported PHP for core now 5.6.20, `wp_parse_url()` no longer seems necessary and `parse_url()` can be used directly. For background on this ticket, see the [https://wordpress.slack.com/archives/C02RQBWTW/p1629146151384100 slack thread].
",pbiron
Future Releases,37593,"Replace ""Super Admin"" with ""Network Administrator""",Mista-Flo,Administration,,normal,normal,Future Release,enhancement,assigned,dev-feedback,2016-08-07T19:17:59Z,2018-09-24T16:39:10Z,"After a note by @ocean90 (https://wordpress.slack.com/archives/core-multisite/p1470482829000310) and a following discussion (see particularly https://wordpress.slack.com/archives/core-multisite/p1470579794000339), it was cleared that the term ""Super Admin"" is used inconsistently in Core at the moment.
Given that there is no Multinetwork UI in Core at the moment, all usages of the term ""Super Admin"" should probably be replaced by ""Network Administrator"". The term ""super admin"" should rather denote the user level where a user has control over all networks in an entire setup. While for a basic Multisite with one network ""super admin"" and ""network administrator"" denote a similar user level, the terms are different for a Multinetwork - and the way Core works currently, it should probably only use ""Network Administrator"".",flixos90
Future Releases,60061,"Rename ""add new plugin"" button",,Plugins,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2023-12-13T16:26:01Z,2024-01-26T09:31:53Z,"Hello
For several versions now, we can update a plugin (and theme) by using the ""add new plugin"" feature.
I think we should find a better wording because the button is not only to add a new plugin, we can update one too.
At first, we could change the label button to ""Add new or update a plugin"" but it's quite long label",sebastienserre
Future Releases,30691,Removing a featured image does not remove the 'post_parent' value - reproducible,,Media,,normal,major,Awaiting Review,defect (bug),reopened,dev-feedback,2014-12-12T12:38:49Z,2021-04-28T16:18:49Z,"Removing a featured image does not remove the 'post_parent' value in the wp_posts row associated with the attachment. This causes invalid results when using functions like get_children() and get_posts().
1) install a fresh copy of WordPress 4.0.1
2) edit the first post and add a featured image
3) use phpMyAdmin and look at the wp_posts table. You will see an entry for the attachment and the 'post_parent' column will be set to the ID of the first post
4) Edit the first post and remove the featured image
5) again use phpMyAdmin and look at the wp_posts table. You will see the entry for the attachment and the 'post_parent' column WILL STILL BE SET to the ID of the first post.
to see a example of an error with get_children() do the following after doing the above.
1) activate twenty-thirteen and view the site
2) edit twenty-thirteen's 'content.php'. Line 15-19 should be
{{{
}}}
add the following right after it.
{{{
'attachment', 'numberposts' => -1, 'post_status' => null, 'post_parent' => $post->ID );
$attachments = get_posts($args);
if (! empty($attachments)) {
echo 'attachment ID ='.$attachments[0]->ID.' ';
echo 'attachment post_parent ='.$attachments[0]->post_parent.' ';
echo '$post->ID ='.$post->ID.' ';
echo ' guid . '""/>';
var_dump($attachments);
}
?>
}}}
3) view the site and you will see the featured image.
4) use phpMyAdmin edit the entry for the attachment and set the 'post_parent' column to '0'.
5) view the site and you will NOT see the featured image.
",juggledad
Future Releases,47690,remove_submenu_page() doesn't remove corresponding entry from $_wp_submenu_nopriv,johnbillion,Administration,,normal,normal,Future Release,defect (bug),reviewing,dev-feedback,2019-07-12T10:41:09Z,2020-04-13T10:43:50Z,"It can sometimes be desirable to give access to a submenu to a user that wouldn't normally have access to it.
Calling `remove_submenu_page()` and then calling `add_submenu_page()` to re-register the screen with a different user capability doesn't work completely because the entry that gets added to the `$_wp_submenu_nopriv` global by `add_submenu_page()` doesn't get removed by `remove_submenu_page()`.
This means the menu item appears but access to the screen is denied when `user_can_access_admin_page()` is called, resulting in a `Sorry, you are not allowed to access this page` error.
",johnbillion
Future Releases,44793,"remove_accents() doesnt escape all versions of ""i""",SergeyBiryukov,Formatting,,normal,normal,Future Release,defect (bug),reviewing,dev-feedback,2018-08-14T17:42:24Z,2019-09-22T20:30:02Z,"The version with both dieresis and accent is missing. Suggested addition is the following
{{{
plus '΅Ι' => 'I', 'ΐ' => 'i',
}}}
",bagosm
Future Releases,34753,"Remove use of ""Toggle"" in strings",,Administration,4.4,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2015-11-20T15:14:58Z,2021-08-01T11:50:10Z,"Hello!
It would be nice to have WordPress stop using ""Toggle"" in strings in multiple places and contexts -- most particularly action buttons and helper text.
It's really two possible actions/behaviors, most of the time different ones depending on the context/location/result of the previous clic, and it's always a pain to translate properly (current way in French replace ""Toggle"" with the French equivalent of ""Open/Close"". Not elegant).
I could change the text, sure. But the buttons themselves, not so much. They'd need to go from displaying ""Toggle"" to displaying ""Open"" or ""Close"" depending on the current status of the target. That'd require some JavaScript wizardry.
Hence, this ticket.
Thanks!",xibe
Future Releases,25927,Remove the theme information from style.css and add a theme manifest file,,Themes,3.7.1,normal,normal,,feature request,reopened,dev-feedback,2013-11-12T17:31:31Z,2019-06-04T21:09:32Z,"Currently the metadata related to a theme is store in a comment at the top of style.css.
I argue this is not a clean separation of concerns, yes .css files can contain semantic information to help the reader navigate the file, but using it to store metadata is bad practice.
I propose creating a theme manifest file that sits at the root of the theme directory and contains all the metadata related to the theme that's currently at the top of style.css, things like the name, author, etc. but it could also contain a file list for the theme with a few lines about the files usage.
Externalising the metadata and adding more contextual information will greatly improve developers ability to hack on top of others themes and understand their rationale for certain decisions.",jolyonruss
Future Releases,48470,Remove the Custom Header and Custom Background admin pages,,Administration,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2019-10-30T17:30:46Z,2019-10-30T17:30:46Z,"I fell into a rabbit hole today looking into why the `custom-header.js` file is [https://core.trac.wordpress.org/browser/branches/5.3/Gruntfile.js#L689 specified to not get minified] in `Gruntfile.js`. I did not find an answer to that question (it has been like that since Core switched to the new build process in [25001] and I couldn't find prior discussion), but I realized that the custom header and background pages in the admin should probably be officially deprecated in favor of the Customizer.
This is a follow up of #25569, #25571, #28032, which proposed removing these pages, but instead settled on an intermediary set of changes to encourage users, and theme and plugin developers to use the Customizer for this feature instead. Those changes were:
- Change the admin menu links from links to `themes.php?page=custom-header`/`themes.php?page=custom-background` to deep links in the Customizer (`https://site.com/wp-admin/customize.php?autofocus[control]=header_image`)
- Added an admin notice informing users that the feature can now be managed with live-preview in the Customizer.
- Hid the Background and Header links in the admin bar and with CSS when Customizer support is present.
This was in version 4.1 (5 years ago). Proper due diligence needs to be performed first, but I'd like to propose removing support for these pages in the admin in favor of redirecting users to the appropriate areas of the Customizer. The pages have been neglected for some time, and the previews are pretty broken for most themes providing a bad experience whenever a plugin or theme has linked to these pages directly.",desrosj
Future Releases,50653,Remove the _doing_it_wrong from WP_Block_Patterns_Registry::unregister(),,Editor,5.5,normal,normal,Future Release,defect (bug),new,dev-feedback,2020-07-13T21:51:41Z,2020-07-26T01:50:07Z,"There's a `_doing_it_wrong()` call inside `WP_Block_Patterns_Registry::unregister()` when you try to unregister a block pattern that doesn't exist.
IMO this is incorrect usage of `_doing_it_wrong()` because the function hasn't been incorrectly called, it's just been called with invalid data.
----
In addition, the `register()` and `unregister()` functions in this class ought to be returning a `WP_Error` instead of boolean `false`. Should we improve this for 5.5?",johnbillion
Future Releases,59883,Remove support for HTML4 and XHTML,,HTML API,trunk,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2023-11-10T19:20:48Z,2024-01-22T23:24:42Z,"== Summary
WordPress still officially supports HTML4 and XHTML, but the browsers it serves and the broader web effectively don't. Let's remove support so that we can modernize the code we write and simplify Core's HTML-handling functionality.
== Background
This came up recently in #58664 and in an exploration [https://github.com/WordPress/wordpress-develop/pull/5337 rewriting esc_attr()].
In various places WordPress maintains the appearance of supporting HTML4, for example:
- `wp_kses_named_entities()` rejects valid named character references like `⇵` and in turn corrupts documents containing these entities.
- script and style tags conditionally add `type` attributes that never need to be printed
- widgets selectively render `` and strip tags out of the `$title` for a page when TITLE elements can contain no tags anyway. This leads to corruption in the page title for removing what WordPress thinks are tags but aren't.
- various places run `kses` as if serving XHTML, adding needless invalid syntax like the self-closing flag on void elements, e.g. ` `, ` `, ` `
The //appearance// of serving HTML4 or XHTML stems from the fact that it's very rare to serve actual XHTML content, and perhaps impossible to serve HTML4 content, to any supported browser or environment.
- browsers ignore any `` or `` declaration specifying HTML4 or XHTML. They interpret a page as HTML5 regardless. You can confirm this by visiting a page with the `〈` named character reference. If interpreted as HTML4 it will transform into the U+2329 `〈` code point, but if interpreted as HTML5 will transform into the U+27E8 codepoint `⟨`.
- the only way to serve a page as XHTML is to send the HTTP header `Content-type: application/xhtml+xml` or to serve the page with the `.xml` file extension in the URL (e.g. serve `index.xml` instead of `index.html` or `index.php` or `/index` or `/`). It's not enough to send a ` ` tag; it //must// come through the HTTP headers.
Because of this behavior in browsers, WordPress sends content that it thinks is one thing but is received as another. Removing official support means that we can start to remove those places that purport to send HTML4 or XHTML content when that assumption is wrong and can lead to data corruption, let alone needless syntax noise.
WordPress still serves XML content in RSS feeds; this proposal does not recommend removing support for generating the XML feeds, but it may extend to the escaping and rendering of embedded HTML within those feeds, since an RSS reader is unlikely to and should not be interpreting embedded HTML as HTML4 and should be supporting embedded HTML5 as any web browser would. As an embedding, the content rendered into the feed remains separate from the surrounding RSS XML container.
== Action plan
Removing support for HTML4 and XHTML doesn't require any immediate action because HTML5 parsers compliantly parse HTML4 and XHTML up to their conflicting rules, such as with the `〈` named character reference. Since WordPress is already ""broken"" in this sense today, removing support does not imply that these are new bugs; rather it acknowledges that we missed updating WordPress once HTML4 and XHTML properly disappeared.
In future work it opens up opportunities to modernize WordPress:
- we don't need to handle complicated corner cases where pre-HTML5 renders require special cases.
- we can remove code meant for backwards compatibility which no longer provides that support.
- we can update Core functions such as `_wp_kses_named_entities()` to prevent them from corrupting data based on inaccurate parsing rules from the past.
- we can define a body of support and scope for what WordPress will and won't attempt to clean up. Functions like `force_balance_tags()` and encoding functions attempt to normalize and sanitize HTML but just as often further break that HTML when passing it through to the browser would have a deterministic and safe resolution.
- we can eliminate wrapping script output with CDATA escaping which is only needed for XML compatibility.
- we can use HTML5 form validation by default in more places instead of requiring an opt-in.
The HTML API is providing WordPress the ability to have a smarter Core HTML system that won't be confused by rare or unexpected inputs and leans heavily on a spec-compliant ""garbage-in garbage-out"" approach. This dramatically simplifies HTML processing code without opening unsafe avenues; this is because HTML5 defines how to handle abnormal inputs.
Weston [https://github.com/GoogleChromeLabs/wpp-research/pull/74 queried the HTTP Archive] and found up to potentially two sites among millions that are serving XHTML content through the inclusion of proper HTTP headers.
== Linked Issues
- #60320 the `CDATA` wrappers around inline JavaScript break non-JavaScript `SCRIPT` contents.",dmsnell
Future Releases,56685,Remove LiveJournal from importer recommendations,,Import,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2022-09-29T05:06:49Z,2022-10-04T03:23:52Z,"The LiveJournal importer has seemingly been broken for quite some time, but is still recommended on the Importers screen.
After reviewing some data, including the support threads and plugin directory install metrics, I recommend that we retire the LiveJournal plugin from being recommended on the Importer screen.
See also #47243 and #meta5550
The importer list is pulled from WordPress.org, but a fallback list is included in core: https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/import.php#L187",dd32
Future Releases,56362,Remove Link/Bookmark API form Core: Phase 2,desrosj,General,2.1,normal,normal,Future Release,enhancement,assigned,dev-feedback,2022-08-10T19:15:19Z,2023-04-27T15:51:25Z,"In WordPress 3.5, the Link Manager was disabled in Core by default in new installs, and hidden entirely when no links were present on a site updating (see #21307).
The intention was to return to this later and remove the Bookmark/Links API from Core entirely. However, no one returned to that second phase. This ticket is to explore removing this long hidden API from Core.",desrosj
Future Releases,36765,Remove Legacy Code from pingback_ping,,Pings/Trackbacks,4.1,normal,normal,,defect (bug),new,needs-unit-tests,2016-05-05T14:59:53Z,2019-06-04T20:58:45Z,"Proposing we remove the legacy conditional url_to_postid and //$way debugging line leftover from [30139].
{{{
/ let's find which post is linked to
// FIXME: does url_to_postid() cover all these cases already?
// if so, then let's use it and drop the old code.
}}}
Related: #34419
",dshanske
Future Releases,51407,Remove inline event handlers and JavaScript URIs for Strict CSP-compatibility,adamsilverstein,Security,4.8,normal,normal,Future Release,enhancement,assigned,dev-feedback,2020-09-28T13:34:53Z,2023-12-26T18:36:00Z,"Content Security Policy is a mechanism designed to make applications more secure against common web vulnerabilities, particularly cross-site scripting. It is enabled by setting the Content-Security-Policy HTTP response header.
An application can add a critical defense-in-depth layer against markup injection attacks by adopting a strict policy that prevents the loading of untrusted scripts or plugins.
A basic policy (nonce + strict-dynamic + unsafe-eval) would block more than [https://speakerdeck.com/lweichselbaum/csp-a-successful-mess-between-hardening-and-mitigation?slide=16 40%] of the XSS sinks.
To make an application compatible with strict CSP, it is necessary to make changes to HTML templates and client-side code and add the policy header:
1. Add nonces to
Sorry… Briefly unavailable for scheduled maintenance.
Please try again in a minute.
Thank you for your patience.