__group__ ticket summary owner component _version priority severity milestone type _status workflow _created modified _description _reporter
Slated for Next Release 60809 .editor-styles-wrapper styles opacity changed Editor trunk normal normal 6.5.1 defect (bug) new reporter-feedback 2024-03-20T03:57:30Z 2024-03-25T23:27:02Z "In WordPress 6.4.3, the block editor automatically applies this to `.editor-styles-wrapper`:
{{{
.editor-styles-wrapper.mce-content-body, .editor-styles-wrapper.editor-styles-wrapper {
opacity: 1;
}
}}}
While testing WordPress 6.5, this no longer occurs. Our theme has `opacity: 0` applied to the body, and we use jQuery to change it to `opacity: 1` when the DOM is loaded. This means that in 6.5, our block editor has 0 opacity.
The issue for us is that this also applies to the block editor and as a result we see a grey box instead of the blocks of content.
In testing with WordPress Alpha 6.6 or with the latest Gutenberg activated this doesn't appear to be the case, is there a reason this was removed from the 6.5 core?" killerbeez
Slated for Next Release 59945 About the feed name specified in the add_feed() Feeds 1.5 normal normal 6.6 defect (bug) new 2023-11-22T02:51:18Z 2024-02-17T13:49:13Z "There is no restriction on the first parameter of the add_feed function, but if it starts with ""_"" it will not function properly.
{{{
function feed2_callback( $is_comment_feed, $feed ) {
header( 'Content-Type: application/xml; charset=UTF-8', true );
echo '';
?>
Testwp_die
404
}}}
This is not a problem with the code I tried, but because the ""_"" at the beginning of the feed name is removed in the do_feed function.
{{{
function do_feed() {
global $wp_query;
$feed = get_query_var( 'feed' );
// Remove the pad, if present.
$feed = preg_replace( '/^_+/', '', $feed );
}}}
This process results in an action name of 'do_feed_' . **'feed2'** when $feed is '_feed2'.
Since this is not done in the add_feed function and the action name specified in the add_action function is 'do_feed_' . **'_feed2'**, it appears that the two action names do not match, resulting in the error indicated in the response.
Should I remove the leading '_' in the feed name in the add_feed function or not remove the '_' in the do_feed function?
In any case, I would like to see consistency in the handling of feed names.
" tmatsuur
Slated for Next Release 52723 Admin options.php default value to NULL for option_value may lead to MySQL Integrity constraint violation error, potential other bugs Options, Meta APIs 2.7 normal normal 6.6 defect (bug) new needs-unit-tests 2021-03-05T14:26:35Z 2024-02-27T12:01:48Z "It looks like `wp-admin/options.php` set a `null` value by default for any unchecked option:
https://core.trac.wordpress.org/browser/trunk/src/wp-admin/options.php#L306
Now, this leads to execute queries like this by `update_option`:
UPDATE `wp_options` SET `option_value` = NULL WHERE `option_name` = 'default_pingback_flag'
Which is wrong, given the schema explicitly set `option_value` to `NOT NULL`:
https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/schema.php#L144
This would trigger an integrity constraint violation error by MySQL when in (default) strict mode:
Error! SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'option_value' cannot be null
To get around this (and for other reasons too, I presume), WordPress currently tries to disable any MySQL strict mode in the `$wpdb` class, with the effect that MySQL silently ""fix"" the error itself:
https://core.trac.wordpress.org/browser/trunk/src/wp-includes/wp-db.php#L567
https://core.trac.wordpress.org/browser/trunk/src/wp-includes/wp-db.php#L826
But **not every environment support this**, so there are people out there who cannot save options and they are confused about the reason why, for example:
https://www.reddit.com/r/Wordpress/comments/l61rvs/cannot_disable_avatars/
https://wordpress.org/support/topic/discussion-comment-settings-saved-changes-are-not-taking-effect-at-all/
https://wordpress.org/support/topic/wordpress-database-error-column-option_value-cannot-be-null/
A simple solution would be to set a different default value (`0` or even an empty string) in `wp-admin/options.php` and, ''better yet'', **cast any `NULL` value to the same different default value in both `update_option` and `add_option`**.
Please note that, without a fix, **this bug may also lead to other nasty side effects**.
As a quick fix/test, I successful got around this with this simple filter:
{{{#!php
see signup-activate-1.patch
If running `wp()` is required for a reason i don't see, a query could still be saved and it could be interested to use this to set a ""page"" title for the `` tag.
> see signup-activate-2.patch
" imath
Slated for Next Release 59514 Add more context to split_the_query filter Query 3.4 normal normal 6.6 enhancement new has-patch 2023-10-02T11:41:06Z 2024-03-13T15:45:24Z "Current the split_the_query filter has the current WP_Query instance as context. However to calculate the value you need the value variables.
- $old_request
- $limits
- $fields
- $q ( query arguments ).
It is worth noting that `$this->request` can be received by `WP_Query` instance and `$wpdb->posts` can be received from global $wpdb.
With this extra context, will be make the filter much more useful.
" spacedmonkey
Slated for Next Release 35833 "Adding a table with the ""widefat"" class on post and taxonomy list table screens causes the quick edit UI and bulk edit to fail" Quick/Bulk Edit 4.4.2 normal normal 6.6 enhancement assigned has-patch 2016-02-15T05:11:47Z 2024-02-12T09:19:40Z "This is a very strange issue. On a fresh WP install running twentysixteen with no plugins activated, including this code causes the quick edit UI to miscalculate its width and end up looking wacky:
{{{
add_action( 'load-edit.php', 'xxx_test_table_in_help_tab' );
function xxx_test_table_in_help_tab() {
$test_table_args = array(
'id' => 'test_help_table',
'title' => 'Something',
'content' => '
Something
',
);
get_current_screen()->add_help_tab( $test_table_args );
}
}}}
I'm attaching a screenshot of what the quick edit UI looks like with this code in place. Removing the class ""widefat"" restores the quick edit UI to normal. As strange as it sounds, I believe the presence of the widefat class is causing something in the quick edit JS to miscalculate. I haven't found the exact line where the issue is, but it seems to all come down to the presence of the ""widefat"" class." Braad
Slated for Next Release 41172 Allow autosaving to be disabled on a per post type basis Autosave normal normal 6.6 enhancement new has-patch 2017-06-26T08:24:58Z 2024-02-27T22:31:57Z Autosaving should be a post type feature, so that individual post types can opt out. Disabling this feature should remove both the server-side and the client-side saving. Frank Klein
Slated for Next Release 58312 Display password hint on additional screens Users 4.3 normal normal 6.6 enhancement new dev-feedback 2023-05-14T20:39:22Z 2024-02-12T15:00:40Z "In WordPress 4.1.0, the function `wp_get_password_hint` was introduced. This function returns a hint to display to the user when creating a new password.
Currently, it is only used when user go through the ""Forget password"" steps. This ticket and the PR with it add the password hint to three screens, WordPress install screen, new user screen and user profile screen." petitphp
Slated for Next Release 33073 "Some strings need ""no HTML entities"" translator comments" I18N normal normal 6.6 enhancement new has-patch 2015-07-22T14:44:59Z 2024-02-12T13:49:08Z "This is a renewal of #10005, which was apparently my first patch to WP 6 years ago, but never got accepted. #10005 was closed as fixed, but it truth it was not (see my last comment there).
So, I'm opening a new ticket about this... and updating the description and patch from 6 years :)
Here goes!
Several strings need to have an indication warning translators against the inclusion of HTML entities within their translation, because of where the strings are user (RSS feeds, e-mails, JavaScript...).
Case in point: in French, there should be a non-breaking space ( ) before any double sign (; : ! ?). So, translators would turn ""URL: %s"" into ""Adresse web : %s"". But since it is used in e-mails, it is displayed as-is. And for strings that are used in feeds, it breaks them...
Suggestions comment: ""Do not add HTML entities ( , etc): used in [context]"".
Patch fixes all strings that I could find.
I do hope it is a simple enough patch, and not too close to RC, that it could make it into 4.3.
Thanks!" xibe
Slated for Next Release 39281 Twenty Seventeen: header.php forces thumbnails on all post types Bundled Theme 4.8 normal normal 6.6 enhancement reopened has-patch 2016-12-14T17:23:54Z 2024-02-22T06:48:27Z "My plugin has custom post type and custom 'single-post-type' views and doesn't utilize thumbnails in them. As a result layout appears broken, and there is nothing I can do to make the plugin compatible with Twentyseventeen.
I went to have a look how WooCommerce deals with this, and it turns out that there is this piece of code in the style of twentyseventeen:
{{{
.single-product .single-featured-image-header {
display: none
}
}}}
While that does work, I don't think it's a solution. At the very least there has to be a filter to dynamically disable the thumbnail from `header.php`" justnorris
Slated for Next Release 52551 Twenty Twenty-One: Search box alignment Bundled Theme 5.7 normal minor 6.6 enhancement new has-patch 2021-02-17T07:17:16Z 2024-03-18T10:28:19Z I was Customized theme twenty twenty-one search-box on tablet and smartphones view. here search-box text field and button are not in correct alignment. vinita29
Slated for Next Release 54738 Unable to upload images with URL over API when the image doesn’t have a filetype in the filename Media normal normal 6.6 enhancement new has-patch 2022-01-04T15:37:53Z 2024-02-14T16:59:53Z "**Problem**: It’s not possible to upload images with URL per API when the image doesn’t have a filetype in the filename.
**Elaboration**: There are some websites which don’t put filetypes inside the URL for images. For example: https://img.ricardostatic.ch/t_1800x1350/pl/1187743940/3/1/
Or: https://media.istockphoto.com/photos/coppersmith-repair-copper-kettle-on-fire-in-kashgar-in-xinjiang-picture-id1298102169?s=612x612
The format of the image is set and recognized by the browser with the MIME-Type. In theory WordPress could handle this, but unfortunately it never gets to the point where the correct MIME type is read out of the image signature.
**Reason**: At the function wp_check_filetype type will always be defined as false - if there is no filetype set inside the filename.
Call of the function: https://github.com/WordPress/WordPress/blob/266c58518846201a7e98cd7995ce2c7429caf1db/wp-includes/functions.php#L2984
Further down there would be a function to get back the real mime type from the signature of the image. However, the function is never called since type at this point is always false in that give case:
https://github.com/WordPress/WordPress/blob/266c58518846201a7e98cd7995ce2c7429caf1db/wp-includes/functions.php#L2999
**Possible Bug**: If the filename has no filetype the function wp_get_image_mime should always be called to get the type from the signature of the image.
**Following Bug**: After changing this, the filename at the upload should be extended with the filetype: https://github.com/WordPress/WordPress/blob/266c58518846201a7e98cd7995ce2c7429caf1db/wp-admin/includes/file.php#L924
Since it’s only really showing up in the library with the correct filetype." masteradhoc
Slated for Next Release 60625 Update user interface for Site icon selection Administration trunk normal normal 6.6 enhancement new 2024-02-23T15:39:53Z 2024-03-05T15:37:15Z "Currently a user can set a site icon in two places outside the site editor: the general settings screen (added in 6.5) and the Customizer. Both these places have currently a design with some years to it. This ticket is aimed to discuss the design of these two places, and possible come up with a new one, and implement it.
Note that a preview also is displayed in the media modal when cropping the site icon.
This ticket has it's roots in ticket #54370" kebbet
Slated for Next Release 40370 "add_image_sizes does not create the ""crop position"" versions of the image" Media 2.9 normal normal 6.6 enhancement reopened dev-feedback 2017-04-05T13:29:32Z 2024-02-12T09:04:43Z "I wanted to introduce 3 different version of post thumbnails - each with different cropping position (top, center, left) , so i added them like this:
{{{#!php
add_image_size( 'newscentered', 400, 400, array( 'center', 'center') );
add_image_size( 'newstop', 400, 400, array( 'center', 'top' ) );
add_image_size( 'newsbottom', 400, 400, array( 'center', 'bottom' ) );
}}}
Now, whenever i use the the_post_thumbnail() with the name of my custom image size i always get the same image, cropped to the default WordPress crop position of ('center', 'center') .
Why is that happening? I did 'refresh' the thumbnails and tried also uploading fresh image files and still i can't get 3 differently cropped versions of the image.
I noticed that when i set the cropping defaults using the following function and set the cropping there, then it works:
{{{#!php
set_post_thumbnail_size( 400, 400, array('center', 'bottom'));
}}}
... but it affects the cropping of all of my thumbnails, so i can only get one ""crop position"" for all my images.
Guys, is this some kind of bug or do i configure something in a wrong way?
I'm using the newest official WordPress version" piejesus
Slated for Next Release 48086 Add required extensions and libraries to composer.json Build/Test Tools 5.2.3 normal normal 6.6 task (blessed) new has-patch 2019-09-20T12:00:49Z 2024-02-26T16:59:03Z "Composer offers a way to require or suggest certain platform packages: https://getcomposer.org/doc/01-basic-usage.md#platform-packages
Ticket 48081 addresses the PHP version, and this one covers the required libraries and extensions.
I've used the WP-CLI ext package (https://github.com/johnbillion/ext) to generate all the required and suggested extensions and libraries.
" dingo_d
Slated for Next Release 60700 Coding Standards fixes for WP 6.6 General normal normal 6.6 task (blessed) new has-patch 2024-03-06T05:03:13Z 2024-03-27T12:28:38Z "Previously:
- #59650 (6.5)
- #58831 (6.4)
- #57839 (6.3)
- #56791 (6.2)
- #55647 (6.1)
- #54728 (6.0)
- #53359 (5.9)
- #52627 (5.8)
- #51799 (5.7)
- #50767 (5.6)
- #49542 (5.5)
- #49222 (5.4)
- #47632 (5.3)
- #45934 (5.1)" mukesh27
Slated for Next Release 60699 Docblock improvements for 6.6 General normal normal 6.6 task (blessed) new 2024-03-06T04:57:35Z 2024-03-19T14:44:26Z "Previously:
- #59651 (6.5)
- #58833 (6.4)
- #57840 (6.3)
- #56792 (6.2)
- #55646 (6.1)
- #54729 (6.0)
- #53399 (5.9)
- #52628 (5.8)
- #51800 (5.7)
- #50768 (5.6)
- #49572 (5.5)
- #48303 (5.4)
- #47110 (5.3)
- #46543 (5.2)
- #42505 (5.1)
- #41017 (4.9)
- #39130 (4.8)
- #37770 (4.7)
- #32246 (4.6)" SergeyBiryukov
Slated for Next Release 59233 Improve error handling for unserialize() General normal normal 6.6 task (blessed) new dev-feedback 2023-08-28T23:47:32Z 2024-02-26T22:05:20Z "From https://core.trac.wordpress.org/ticket/59231:
> === [https://wiki.php.net/rfc/unserialize_warn_on_trailing_data Make unserialize() emit a warning for trailing bytes]
>
> While based on the current test suite, WP is not ''directly'' affected by this, the [https://developer.wordpress.org/reference/functions/maybe_unserialize/ `maybe_unserialize()`] function could still be confronted by data with trailing bytes.
>
> However, the call to the PHP native `unserialize()` within `maybe_unserialize()` silences all (PHP 8.0+: non-fatal) errors, so this new warning will not affect WP or its ecosystem as long as the `maybe_unserialize()` function is used.
>
> Having said that, a critical look at `maybe_unserialize()` may be warranted as the new warning in PHP is related to security issues discovered in other projects, so WP may want to consider rejecting unserialization for data throwing this warning.
>
> Also note that there are 7 uses of `unserialize()` in total within WP Core, one within `maybe_unserialize()`, but the function is also used in 6 other places and 5 of those do not use error silencing.
>
>
> === [https://wiki.php.net/rfc/improve_unserialize_error_handling Improve unserialize() error handling]
>
> This, again, affects the [https://developer.wordpress.org/reference/functions/maybe_unserialize/ `maybe_unserialize()`] function and this time, the code should probably be adjusted to handle the new errors which `unserialize()` can now throw.
>
> The change does not affect unserializing valid data, but in the case of invalid data, the type of and severity of the notices/warnings/catchable exceptions have been changed.
>
> All 7 uses of `unserialize()` in WP Core should be reviewed and for the 6 uses outside of the `maybe_unserialize()` function, it should be reviewed whether they can/should switch to using `maybe_unserialize()` and/or whether they should get their own (improved) error handling.
" jrf
Slated for Next Release 59649 PHP 8.0: improvements to allow for named parameters in 6.6 General normal normal 6.6 task (blessed) new 2023-10-17T12:16:28Z 2024-02-26T10:21:48Z "Previously:
* #58976 (6.4)
* #57838 (6.3)
* #56788 (6.2)
* #55650 (6.1)
* #55327 (6.0)
* #51553 (5.9)
Quoted in full below:
> PHP 8.0 introduces the ability to pass named parameters to function calls.
> Ref: https://wiki.php.net/rfc/named_params
>
> Code example:
> {{{#!php
> // Using positional arguments:
> array_fill(0, 100, 50);
>
> // Using named arguments:
> array_fill(start_index: 0, num: 100, value: 50);
>
> // Named arguments do not have to follow the same order as positional arguments:
> array_fill(value: 50, num: 100, start_index: 0);
> }}}
>
> **More than anything, this means that, as of PHP 8.0, renaming a parameter in a function declaration is a backward-compatibility break! **
>
> This should most definitely get prominent mention in the PHP8 dev-note as a lot of Core/plugin/theme developers will not be aware of this at this time.
>
>
> I'm opening this ticket to address a number of issues this brings up for WordPress Core.
>
> I've so far identified three tasks which should be executed ASAP to prepare for named parameters in function calls.
>
> == Task 1: Review Function Signatures of methods in child classes
>
> Methods in child classes may use different parameter names than those used for the same method by its parent. Similarly, classes implementing an interface do not have to use the same parameter names.
>
> While this does not change in PHP 8, it could create problems when the method is called using named parameters.
>
> To quote from [https://wiki.php.net/rfc/named_params#parameter_name_changes_during_inheritance the RFC]:
>
> > If an inheriting class changes a parameter name, calls using named arguments might fail, thus violating the Liskov substitution principle (LSP).
>
> > PHP will silently accept parameter name changes during inheritance, which may result in call-time exceptions when methods with renamed parameters are called
>
> Code sample:
> {{{#!php
> interface I {
> public function test($foo, $bar);
> }
>
> class C implements I {
> public function test($a, $b) {}
> }
>
> $obj = new C;
>
> // Pass params according to I::test() contract
> $obj->test(foo: ""foo"", bar: ""bar""); // ERROR!
> }}}
>
>
> **Note: For variadic functions this will not cause an error, but will move the unrecognized names to be part of the variadic argument, which can cause all sorts of problems.**
> Code sample [https://twitter.com/giveupalready/status/1312139952776306688 courtesy of Chris Riley] illustrating the problem: https://3v4l.org/MhJ79
>
> With regards to WordPress, I'd like to propose making the parameter names in child classes/classes implementing an interface consistent to prevent such issues.
>
>
>
>
> == Task 2: Review Other Function Signatures
>
> 1. The function signatures of existing functions and methods of all WordPress code should be examined and non-descriptive parameter names should be fixed (renamed) **NOW** as later will no longer be an option without creating a BC-break.
> 2. While using reserved keywords as parameter name labels is allowed, in the context of function calls using named parameters, this will easily lead to confusion. I'd like to recommend to rename function parameters which use reserved keywords to remove this confusion.
> {{{#!php
> function array_foobar($toggle = false, $array = []) {}
>
> array_foobar(array: $value);
> }}}
>
>
> == Task 3: Review all uses of `call_user_func_array()`
>
> Named parameters cause a BC-break for `call_user_func_array()` when passing an associative array.
> In previous PHP versions, the array keys would have been ignored. In PHP 8, string keys will be interpreted as parameter name labels.
>
> For more detail, see: https://wiki.php.net/rfc/named_params#call_user_func_and_friends
>
> Basically, we need to make sure that any array passed to `call_user_func_array()` does NOT have string keys. If it does or if the format of the array is unknown (like when it is passed in via a function parameter), we need to add extra safeguards to make the code cross-version compatible.
> A typical way to do this would be to use `array_values()` on the array before passing it to `call_user_func_array()`, though beware that ''**will**'' break code written for PHP 8 which actually expects the label to be used.
>
>
>
>
>
>
> == Other references:
>
> * https://twitter.com/CiaranMcNulty/status/1312087225857970182
>
>
> Related Trac tickets: #50913, #50531" hellofromTonya
Slated for Next Release 59654 PHP 8.x: various compatibility fixes for WordPress 6.6 General normal normal 6.6 task (blessed) new 2023-10-17T12:33:14Z 2024-02-26T10:20:59Z "Previously:
* #57837 (6.3)
* #56790 (6.2)
* #55656 (6.1)
* #54730 (6.0)
* #53635 (5.9)
* #50913 (5.6)
This ticket will be used as an ""epic"", allowing a variety of small patches each fixing a specific failure to be added to and committed against this ticket.
For patches addressing all instances of failures related to one specific PHP version (such as PHP 8.0, 8.1, or 8.2) change across the codebase, separate tickets should still be opened.
For an example of issues/patches with separate tickets, see:
* #53299 PHP 8.1: Update `is_serialized` function to accept Enums
* #53465 PHP 8.1.: the default value of the flags parameter for `htmlentities()` et all needs to be explicitly set
When opening a separate ticket, please tag it with the appropriate PHP version keyword so that these tickets can be easily found:
* PHP 8.3: keyword is `php83` with its report https://core.trac.wordpress.org/query?keywords=~php83
* PHP 8.2: keyword is `php82` with its report https://core.trac.wordpress.org/query?keywords=~php82
* PHP 8.1: keyword is `php81` with its report https://core.trac.wordpress.org/query?keywords=~php81
* PHP 8.0: keyword is `php8` with its report https://core.trac.wordpress.org/query?keywords=~php8" hellofromTonya
Slated for Next Release 59231 Prepare for PHP 8.3 General 6.4 normal normal 6.6 task (blessed) new has-patch 2023-08-28T23:15:51Z 2024-02-17T16:12:34Z "This is a meta ticket to track the efforts to prepare for PHP 8.3.
For PHP 8.0/8.1/8.2 specific fixes, please refer to the generic WP 6.4 PHP 8.x ticket: #58850
Please link patches related to a specific PHP 8.3 related task to the appropriate dedicated issue, if there is one (see the links in the description below).
Generic/one-off PHP 8.3 related patches can be linked to this ticket.
----
== PHP 8.3: Important dates
PHP 8.3 is [https://wiki.php.net/todo/php83 expected to be released on November 23 2023].
Other note-worthy dates:
* The first alpha was released on June 8th 2023.
* Feature freeze started on July 18, 2023.
**Note**:
The below represents the status per August 28, 2023. As PHP 8.3 is in feature freeze, these statuses should be reasonably reliable.
== Readiness of essential tooling
=== [https://github.com/composer/composer Composer]
Current status:
* CI for Composer itself was not yet being run against PHP 8.3. I've opened [https://github.com/composer/composer/pull/11601 a PR] for this. ''[JRF: this PR has since been merged]''
* I've ran linting, PHPCompatibility (bleeding edge) and the test suites against PHP 8.3 and found no problems for PHP 8.3 though.
* The only issues I've managed to identify are in the test suite of Composer, which has no impact on end-users of Composer.
=== [https://github.com/sebastianbergmann/phpunit PHPUnit]
Current status:
* CI for PHPUnit itself is being run against PHP 8.3.
* No known issues in the last release supported for the WP test suite (9.6.11).
=== [https://github.com/Yoast/PHPUnit-Polyfills PHPUnit Polyfills]
Current status:
* CI for PHPUnit Polyfills itself is being run against PHP 8.3.
* No known issues in the last release (1.1.0).
=== [https://github.com/wp-cli/wp-cli WP-CLI]
Current status:
* CI for WP-CLI was not (yet) being run against PHP 8.3. A [https://github.com/wp-cli/.github/pull/68 PR to change this has been opened and merged].
* **''Status unknown''**.
=== Other tooling
Other (PHP) tooling doesn't necessarily have to run against PHP 8.3 (yet), so has not been evaluated.
== Initial DevOps Tasks
Typical tasks which need to be executed to allow WordPress to prepare for PHP 8.3:
=== [https://github.com/WordPress/wpdev-docker-images Docker]
* Add PHP 8.3 to the Docker images. A [https://github.com/WordPress/wpdev-docker-images/pull/113 PR for this] was merged on July 26, 2023
=== GitHub Actions
* Add PHP 8.3 to the GitHub Actions `phpunit-tests.yml` configuration. [https://github.com/WordPress/wordpress-develop/pull/5106 GH PR #5106] ''[JRF: this PR has since been merged]''
Notes:
- Test failures on PHP 8.3 should not (yet) fail the build, but as the actual script to run the tests has been moved, it is currently impossible to use `continue-on-error` as that keyword is not supported when calling a reusable workflow... /cc @desrosj
== PHP 8.3 changes for which WordPress will need to prepare
=== [https://wiki.php.net/rfc/deprecations_php_8_3 Generic deprecations for PHP 8.3]
Based on initial (bleeding edge) PHPCompatibility scans + the tests, WP is not affected by the deprecations which passed from this RFC (not all of them did).
=== [https://wiki.php.net/rfc/deprecate_functions_with_overloaded_signature Deprecation of functions with overloaded signatures]
This RFC only partially affects PHP 8.3. If a replacement is readily available already, the deprecation of the overloaded signature takes place in PHP 8.3.
If no replacement was available, the replacement functions are being introduced in PHP 8.3 and the actual deprecation of the overloaded signature takes place in PHP 8.4.
Based on initial (bleeding edge) PHPCompatibility scans + the tests, WP is affected by two of the deprecations in PHP 8.3:
* `get_class()` and `get_parent_class()` - this is already being tracked in #58876, there is a patch available, which IMO is ready for commit. ''[JRF: the PR for this has since been merged]''
* `ReflectionProperty::setValue()` with static properties. [https://github.com/WordPress/wordpress-develop/pull/5105 GH PR #5105] ''[JRF: this PR has since been merged]''
The other deprecations in this RFC do not appear to affect WP Core at this time.
There is one - `stream_context_set_option()`, which will impact Requests, but only in PHP 8.4 and [https://github.com/WordPress/Requests/pull/822 a patch has already been pulled] for this.
=== [https://wiki.php.net/rfc/saner-inc-dec-operators Saner increment/decrement operators]
To my surprise, I have not found any issues in WP with this change based on the tests alone, but I would not be surprised if the odd issue around this gets reported over time.
=== [https://wiki.php.net/rfc/marking_overriden_methods Marking overridden methods]
This is a new feature with limited validation functionality attached. The attribute basically allows to mark methods in a (child) class/interface which overload a method in a parent class or from an interface, as doing so intentionally.
Per the RFC:
> ... being able to express if a method is intended to override another method or implement an interface would make it easier to debug a mistake, to refactor and to clean up existing code. Another possible use case is to easily detect a possibly breaking change in a parent class that was provided by a library without needing to read the changelog in detail or missing some item in the list of changes
I'd like to advocate for adding these attributes to WP Core in all the relevant places as it:
* Increases awareness of the method overload for contributors.
* Can serve as a warning that the method signature should not be touched (unless the parent method signature changes).
* Has no downside as attributes are ignored in older PHP versions and in PHP versions where the attribute referenced does not exist.
In the rare case that the attribute, once added, would result in a fatal error, that would be fantastic, as that means we have actually found a bug in WP before it got into a stable release.
Separate ticket to allow for discussing this proposal in more detail and for patches: #59232.
=== [https://wiki.php.net/rfc/unserialize_warn_on_trailing_data Make unserialize() emit a warning for trailing bytes]
While based on the current test suite, WP is not ''directly'' affected by this, the [https://developer.wordpress.org/reference/functions/maybe_unserialize/ `maybe_unserialize()`] function could still be confronted by data with trailing bytes.
However, the call to the PHP native `unserialize()` within `maybe_unserialize()` silences all (PHP 8.0+: non-fatal) errors, so this new warning will not affect WP or its ecosystem as long as the `maybe_unserialize()` function is used.
Having said that, a critical look at `maybe_unserialize()` may be warranted as the new warning in PHP is related to security issues discovered in other projects, so WP may want to consider rejecting unserialization for data throwing this warning.
Also note that there are 7 uses of `unserialize()` in total within WP Core, one within `maybe_unserialize()`, but the function is also used in 6 other places and 5 of those do not use error silencing.
=== [https://wiki.php.net/rfc/improve_unserialize_error_handling Improve unserialize() error handling]
This, again, affects the [https://developer.wordpress.org/reference/functions/maybe_unserialize/ `maybe_unserialize()`] function and this time, the code should probably be adjusted to handle the new errors which `unserialize()` can now throw.
The change does not affect unserializing valid data, but in the case of invalid data, the type of and severity of the notices/warnings/catchable exceptions have been changed.
All 7 uses of `unserialize()` in WP Core should be reviewed and for the 6 uses outside of the `maybe_unserialize()` function, it should be reviewed whether they can/should switch to using `maybe_unserialize()` and/or whether they should get their own (improved) error handling.
Separate ticket to allow for discussing this and the previously listed RFC in more detail and for patches: #59233.
=== [https://wiki.php.net/rfc/assert-string-eval-cleanup Deprecate remains of string evaluated code assertions]
As WP Core does not use assertions, it is not affected by the changes in this RFC.
Plugins/themes may still be affected, though I'd hope none of those would use `assert()`.*
* `assert()` is intended for dev-only use. The behaviour of `assert()` is heavily affected by ini settings which cannot be changed at runtime, which means that end-users may be confronted by unexpected fatal errors due to the use of `assert()` if they run on an incorrectly configured webhost.
=== [https://wiki.php.net/rfc/proper-range-semantics Define proper semantics for range() function]
This RFC adds a number of errors and warnings for incorrect use of the `range()` function.
WP Core has 8 uses of this function in `src`, 2 in `class-wp-text-diff-renderer-table.php` and 6 in various files from external dependencies.
I've visually reviewed each of these and they all look to be okay, though a check to safeguard that the WP native uses are covered sufficiently by tests would be prudent. [TODO]
=== [https://wiki.php.net/rfc/datetime-exceptions More Appropriate Date/Time Exceptions]
This RFC reclassifies warnings and errors from the DateTime extension to catchable Exceptions when the OO-interface is used (procedural use of the DateTime functionality is not affected).
Based on the tests, WP Core is not affected by this and as the DateTime use of WP Core is pretty well tested, I'm fairly confident, we'll be fine.
=== [https://wiki.php.net/rfc/json_validate New json_validate() function]
This function is a high-performance way to validate json prior to decoding it. This function cannot be polyfilled without a performance hit.
However, due to the potential for using json for Denial-of-Service attack vectors (via a HUGE file/stream), I would strongly recommend for WP Core to start using this new function in all appropriate places wrapped within an `if ( function_exists() ) {}`.
The `json_decode()` function is used 44 times within `src` (excluding external dependencies).
We may want to consider introducing a `wp_json_decode()` function to ensure the use of `json_validate()` (when available).
This would then mirror the already existing [https://developer.wordpress.org/reference/functions/wp_json_encode/ `wp_json_encode()`] function.
See: #59234
== Status of External Dependencies
=== [https://github.com/JamesHeinrich/getID3 GetID3]
Current status:
* Linting is enabled against PHP 8.3. The build passes without finding any PHP 8.3 related issues.
* **Important**: the project has no test suite, so the linting passing on PHP 8.3 is only a small comfort and does not provide any real security.
* In other words: **''status unknown''**.
* WordPress is using the latest version (1.9.22), see #56692
=== [https://github.com/PHPMailer/PHPMailer PHPMailer]
Current status:
* Linting and tests are being run against PHP 8.3.
* No known issues in the last release (6.8.0) (aside from something in the PHPMailer test suite, which doesn't affect WP).
* WordPress is using the latest version, see #57873
=== [https://github.com/WordPress/Requests Requests]
Current status:
* Linting and tests are being run against PHP 8.3.
* No known issues in the last release (2.0.7) (aside from something in the Requests test suite, which doesn't affect WP).
* WordPress is using the latest relevant version `2.0.6`, see #58079. Requests 2.0.7 only updated the certificates bundle, while WP uses its own)
=== [https://github.com/simplepie/simplepie SimplePie]
Current status:
* Tests are being run against PHP 8.3.
* No known issues in the current `master` branch.
* WordPress is behind and is still using version `1.5.8`, while the latest release is `1.6.0`, see #55604
I've done a test run of SimplePie 1.5.8 against PHP 8.3 and based on the tests, there are no relevant PHP 8.3 issues known at this moment.
=== [https://github.com/paragonie/sodium_compat Sodium Compat]
Current status:
* A [https://github.com/paragonie/sodium_compat/pull/160 PR has been opened] to enable running of the tests against PHP 8.3. The build passes without finding any PHP 8.3 related issues. ''[JRF: this PR has since been merged]''
* No known issues in the last release (1.20.0).
* WordPress is using the latest version, see #58224.
=== [https://github.com/openwall/phpass PHPass]
Current status:
* Tests are being run against PHP 8.3.
* No known issues in the current `main` branch, which translates to the `0.5.4` version.
* WordPress is using version `0.5.0`, but the script is a little out of sync with upstream, though not in a way that it impacts the running of WP on PHP 8.3." jrf
Tickets Awaiting Review 27606 """Add Existing User"" form does not preserve input in case of an error" Users low minor Awaiting Review defect (bug) new has-patch 2014-03-31T10:43:42Z 2019-05-03T10:39:43Z "Background: #27006
In single site, ""Add New User"" form preserves entered values in case of an error.
In Multisite, ""Add New User"" form preserves the values, but ""Add Existing User"" does not.
In network admin, ""Add New User"" form does not preserve the values." SergeyBiryukov
Tickets Awaiting Review 48553 """Admin Color Scheme"" should not be saved before hitting the ""Update Profile"" button in profile page" Users 3.8 normal normal Awaiting Review defect (bug) assigned has-patch 2019-11-10T11:29:13Z 2023-05-26T09:54:34Z "On the profile page (''/wp-admin/profile.php'') when you click on a color scheme, it instantly updates (via AJAX) in the user meta and changes the color.
I think this should not happen. User meta should be updated only after they hit the ""Update Profile"" button. It's OK to show the color (preview) as soon as they click an option, but storing the value in the database should be updated along with other info after clicking the save button.
[[Image(https://s.nimbusweb.me/attachment/3516583/0ug6f4ro5vxd2e91ggdm/alEdMIiK5cCc8V2P/screenshot-core.wp-2019.11.10-17_25_46.png)]]" mukto90
Tickets Awaiting Review 56599 """All"" view not selected for all relevant views for custom post type" Posts, Post Types 4.2 normal trivial Awaiting Review defect (bug) new has-patch 2022-09-19T10:58:34Z 2022-09-19T14:24:10Z When the screen options get saved, the parameter `mode=list` gets appended to the URL. For the posts table, the “All” view gets the `.current` HTML class, since `\WP_Posts_List_Table::is_base_request()` returns `true`. For all other post types—including pages—it returns `false`. alpipego
Tickets Awaiting Review 40340 """Attach to existing content"" modal shows posts and pages of other users" Role/Capability normal normal Awaiting Review defect (bug) reopened needs-unit-tests 2017-04-02T15:19:15Z 2017-08-03T17:54:02Z "From the Media library, a user can attach media (through the Attach link) that were uploaded by himself only. The first image shows the Attach links appearing for certain media only.
In the same way, the ""Attach to existing content"" should also list only those posts/pages for which the user has the permissions to attach.
Instead it lists all posts (including private) and pages of all users, and then, upon selection, gives the message ""Sorry, you are not allowed to edit this post.""
" menakas
Tickets Awaiting Review 57365 """Attempt Block Recovery"" functionality broken for buttons ""Convert to.."" click" Editor 6.1.1 normal normal Awaiting Review defect (bug) new 2022-12-21T12:16:37Z 2022-12-30T05:56:34Z "When i edit the HTML manually and click away, the ""Attempt Block Recovery"" error appears.
== BUG:
**Clicking on the ""''Convert to HTML''"" or ""''Convert to Blocks''"" does nothing.**
[[Image(https://i.imgur.com/fzLTpaH.png)]]
The button ""Attempt Block Recovery"" itself works and reverts the action to the previous state before I edited the html.
I also screenshotted the red text from the console:
[[Image(https://i.imgur.com/1l0PjIv.png)]]" mikulabc
Tickets Awaiting Review 60082 """Copied"" tooltip should be hidden when another attachment URL is copied (in list mode)" Media 6.0 normal normal Awaiting Review defect (bug) new 2023-12-15T13:05:00Z 2024-03-12T15:39:27Z "In the media list view, clicking the ""Copy URL"" action link displays previously clicked ""Copy URL"". The previously clicked row showing ""Copied!"" when hover the media again.
=== Environment
- WordPress: 6.4.2
- PHP: 8.2.0
- Server: Apache/2.4.54 (Unix) OpenSSL/1.0.2u PHP/8.2.0 mod_wsgi/3.5 Python/2.7.18 mod_fastcgi/mod_fastcgi-SNAP-0910052141 mod_perl/2.0.11 Perl/v5.30.1
- Database: mysqli (Server: 5.7.39 / Client: 8.2.0)
- Browser: Firefox 119.0 (macOS)
- Theme: Twenty Twenty-Four 1.0
- MU-Plugins: None activated
- Plugins:
* WordPress Beta Tester 3.5.5
=== Steps to Reproduce
1. Go to media library
2. Click ""Copy URL"" of one of the media.
3. Click ""Copy URL"" of another media.
4. The previously clicked row showing ""Copied!"" when hover the media again.
=== Expected Results
1. The previously ""Copied!"" tooltip should be close after clicking the next one.
=== Actual Results
1. The previously clicked row showing ""Copied!"" when hover the media again." jayadevankbh
Tickets Awaiting Review 58518 """More info about performance optimization"" links in Site Health go to 404 error on WordPress.org" Site Health normal normal Awaiting Review defect (bug) new 2023-06-12T14:03:56Z 2023-06-13T06:47:37Z "On the Site Health page, at least under the ""Enqueued scripts"" improvements, the links for ""More info about performance optimization"" go to a broken link on wordpress.org (https://wordpress.org/support/article/optimization/). According to archive.org, it looks like that link was live as late as May 16, 2023. Not sure if there is now a new page. The only optimization page is https://wordpress.org/documentation/article/search-engine-optimization/." jeffgreendesign
Tickets Awaiting Review 59340 """Open in new tab"" checkbox in hyperlink entry doesn't save" Editor 6.3 normal normal Awaiting Review defect (bug) new 2023-09-13T16:37:54Z 2023-09-29T15:48:45Z "When interfacing, the ""Open in new tab"" selection sometimes doesn't work. Rapidly entering the information on a slow internet connection should reproduce the bug.
It's probably tied to network information, where the ""Save"" button SHOULD send a delayed network transmission of the update. Instead, it drops the information.
This compounds as a worse problem with the new UI information, since it requires several clicks to confirm each hyperlink's present status.
The workaround is to wait 2-3 seconds after selecting the checkbox but before selecting ""Save"".
This most heavily affects power users and users with slow internet connections." phileossopher
Tickets Awaiting Review 48954 """Sticky"" post state shows even for non-Post post-types" Posts, Post Types normal normal Awaiting Review defect (bug) new 2019-12-12T21:54:48Z 2019-12-12T22:15:24Z "Reported in the support forums: https://wordpress.org/support/topic/sticky-tag-remains/
When users of my Post Type Switcher plugin switch a Post into a Page, that page still shows as ""Sticky"" in the Pages list-table UI, even though Pages do not support the ""sticky"" functionality." johnjamesjacoby
Tickets Awaiting Review 58287 """The server cannot process the image"" error, set_imagick_time_limit() and WP 6.2" Media 6.2 normal major Awaiting Review defect (bug) new 2023-05-10T15:51:53Z 2023-05-10T19:54:45Z "On many of our sites, managed on different machines and with different configurations, with version 6.2 of WordPress, when uploading images we often get this error:
""The server cannot process the image. This can happen if the server is busy or does not have enough resources to complete the task. Uploading a smaller image may help. Suggested maximum size is 2560 pixels.""
Nothing appears in the `debug.log`, but analyzing the issue -which had never occurred before WordPress 6.2- we realized that it seems to be due to the new `set_imagick_time_limit()` method of the `WP_Image_Editor_Imagick` class.
Maybe the value `0.8 * $php_timeout` is that a bit too conservative? Maybe it could be made hookable?" delitestudio
Tickets Awaiting Review 43531 $content_width and Add Media (+ twentyseverteen?) Media 4.9.4 normal normal Awaiting Review defect (bug) new 2018-03-12T20:07:38Z 2019-01-21T22:04:59Z "I apologize in advance if this isn't a bug. However, I couldn't seem to find any documentation on the expected behavior (e.g., there's nothing on the codex page for the image_size_names_choose filter). None the less, it certainly feels odd / awkward.
When adding an image (to a post / page), the size setting select (Add Media > Attachment Display Setting > Size) doesn't feel quite right. I understand the relationship between (global) $content_width and this setting. That is, the tag's width= is forced / maxed to the $content_width (if the image is wider than the $content_width).
I see this happening for the size = large images, as well as any image sizes I've added via add_image_size() that are too wide. However, it (i.e., the forced max width=) doesn't happen to the size Medium when the Medium width is set wider than the content width.
Perhaps this is intentional?
Theme was twentyseventeen. Unfortunately, I've haven't had time to try to reproduce this on another theme. The size Medium was set to 800 x 800.
I'd like to suggest the Settings > Media page display the current $content_width, as well as explain a bit, as well as link to a deeper explanation. As it is, a user can select a theme, blindly set the image sizes (not realizing who they actually map to the theme), and then be hit with the experience (?) described above, AND have no idea why.
Truth be told, it took me too long to figure this out. Somehow I've managed to avoid $content_width. Too many custom themes maybe? :)
Or am I just missing something about the intent of what otherwise feels like a sloppy experience?
I hope this helps. TIA
" ChiefAlchemist
Tickets Awaiting Review 43695 $depth and $args are switched when using custom callback in wp_list_comments() Comments 4.9.5 normal normal Awaiting Review defect (bug) new has-patch 2018-04-05T05:55:31Z 2021-11-26T11:12:27Z "For the custom function I am using the [latest function from walker](https://github.com/WordPress/WordPress/blob/master/wp-includes/class-walker-comment.php#L343) as a base.
When you use custom callback in comments.php template:
{{{#!php
'comment',
'format' => 'html5',
'style' => 'ol',
'short_ping' => true,
];
// Use our custom callback if it's available
if( function_exists( 'custom_render_comment' ) ){
$args['format'] = 'custom';
$args['callback'] = 'custom_render_comment';
}
wp_list_comments( $args );
}}}
The arguments that get passed to custom_render_comment function are switched:
{{{#!php
NULL [""max_depth""]=> string(1) ""5"" [""style""]=> string(2) ""ol"" [""callback""]=> string(21) ""faeiv2_render_comment"" [""end-callback""]=> NULL [""type""]=> string(7) ""comment"" [""page""]=> int(0) [""per_page""]=> int(0) [""avatar_size""]=> int(32) [""reverse_top_level""]=> bool(false) [""reverse_children""]=> string(0) """" [""format""]=> string(6) ""faeiv2"" [""short_ping""]=> bool(true) [""echo""]=> bool(true) [""has_children""]=> bool(true) }
}
var_dump($args):
int(1)
*/
}
}}}
The result is this error:
{{{
Warning: array_merge(): Argument #1 is not an array in [...]/wp-content/themes/mytheme/inc/render-comment.php on line 56
}}}
I haven't found any mention of switching arguments in the WordPressCodex.
The fix is easy, just switch those variables, but I think it should be addressed somewhere in the documentation." vincurekf
Tickets Awaiting Review 52651 $option_group argument in settings_fields() function is misdescribed Options, Meta APIs 2.7 normal normal Awaiting Review defect (bug) new 2021-02-25T10:59:49Z 2021-02-28T10:52:51Z "The settings_fields() function in plugin.php takes a single argument described as $option_group. However this argument is then used to populate the 'option_page' hidden element.
The docBlock param description says ""This should match the group name used in register_setting()"" but if you follow this advice, your option group will not be included in $allowed_settings and you will get an error.
{{{#!php
/**
* Output nonce, action, and option_page fields for a settings page.
*
* @since 2.7.0
*
* @param string $option_group A settings group name. This should match the group name
* used in register_setting().
*/
function settings_fields( $option_group ) {
echo """";
echo '';
wp_nonce_field( ""$option_group-options"" );
}
}}}
It seems a common fix for this on the internet is to pass the 'option_page' value instead.
https://wordpress.stackexchange.com/questions/376785/wordpress-error-options-page-setting-not-found-in-the-allowed-options-list
if the argument name could be changed to $option_group and the docBlock updated accordingly, that would correct the issue without breaking existing implementations
{{{#!php
"";
echo '';
wp_nonce_field( ""$option_page-options"" );
}
}}}
" pe01b6
Tickets Awaiting Review 43372 $wp_query->max_num_pages return value as float Query 4.9.4 normal trivial Awaiting Review defect (bug) new 2018-02-20T16:32:40Z 2022-02-10T15:13:40Z "As a page number, Integer would make more sense than Float.
This is not a big problem but kinda annoying when you do strict comparison on this value. since no one will define a page number as float." ironghost63
Tickets Awaiting Review 43664 $wpdb->get_results fails in specific cases with non-latin charaters in where clause Database 4.9.4 normal normal Awaiting Review defect (bug) new 2018-03-30T08:37:47Z 2018-04-08T19:09:08Z "Let's say we have user with display name 'Алексей';
{{{$wpdb->get_results(""SELECT user_login FROM $wpdb->users where `display_name`='Алексей' "", ARRAY_A);}}}
executes normally
{{{$wpdb->get_results(""SELECT user_login AS 'russian person' FROM $wpdb->users where `display_name`='Алексей' "", ARRAY_A);}}}
executes normally as well
but
{{{$wpdb->get_results(""SELECT user_login AS 'person from Russia' FROM $wpdb->users where `display_name`='Алексей' "", ARRAY_A);}}}
returns empty array and results in error:
[table Russia.doesn't exist]
SHOW FULL COLUMNS FROM `Russia`
That means 'from' in 'person from Russia' somehow gets in sql
It's an obscure enough situation, but might signify that something is wrong with wpdb query handling" altert
Tickets Awaiting Review 40014 & converted to '#038 Themes 4.7.2 normal normal Awaiting Review defect (bug) new 2017-03-02T08:41:46Z 2017-03-03T05:01:54Z "Hi guys,
This is a follow-up to #30831.
Using WordPress v4.7.2 . With paginate_links() and setting the 'add_args' to an an array of values breaks the url. Specifically replaces '''&''' with '''#038''';
Sample code below:
{{{
echo paginate_links(
array(
'base' => str_replace( $big, '%#%', esc_url( get_pagenum_link( $big ) ) ),
'current' => max( 1, get_query_var( 'paged' ) ),
'total' => $query_object->max_num_pages,
'format' => 'page/%#%',
'add_args' => array( 'project' => 1 /* or whatever the project number is*/ ),
) );
}}}
The code above replaces '''&''' with '''#038''';
Sample result: http://domain.com/?page_id=1&paged=2#038project=1
" fervillz
Tickets Awaiting Review 40899 '&' Is always escaped in the JavaScript template. General 4.7.5 normal normal Awaiting Review defect (bug) new 2017-06-01T08:41:12Z 2020-09-08T13:05:47Z "When I tried the JavaScript template, '&' was always escaped.
Source:
{{{
}}}
Rendering:
{{{
&
Unscaped: Wo&r'l""d
Escaped: W<i>o</i>&r'l""d
}}}
While checking the interpolation of the variable, '&' was always converted to '& amp;'.
Is this a specification or a bug?
" tmatsuur
Tickets Awaiting Review 27244 'Restore This Autosave' immediately updates a published post Revisions normal normal Awaiting Review defect (bug) new 2014-02-28T23:43:29Z 2024-02-25T19:29:55Z "The ""Restore This Autosave"" button on the revisions screen immediately replaces the post with the autosave without making it clear that that is the case.
Steps to reproduce:
1. Publish a post.
2. Edit the content of the post and trigger an autosave (either by waiting two minutes or by clicking the 'Preview Changes' button).
3. Navigate away from the post editing screen.
4. Return to the post editing screen and note the message stating ""There is an autosave of this post that is more recent than the version below"". Click ""View the autosave"".
5. On the revisions screen, click ""Restore This Autosave"".
6. Note that the autosave has been published rather than simply being restored to the editing screen." johnbillion
Tickets Awaiting Review 40585 'Update' vs 'Schedule' Posts, Post Types normal normal Awaiting Review defect (bug) reopened has-patch 2017-04-27T16:48:26Z 2017-05-08T18:44:30Z "Hi, today i work with WordPress and i noticed a problem. My timeline event is:
1) I have an article ""X"" published of the 26 april at 20.00.
2) Today, 27 april at 18.02 i start the edit the article
3) At 18.15 finish edit article and modified date of article in pubblication in 27 april at 18.15
4) Now i don't look button ""Update"" but i look button ""Planning"".
I have feeling that WordPress don't check date in this moment (18.15) but check date open edit article (18.02).
The article is pubblished in all cases but theoretically the article is deleter on the google serp for some minutes.
Sorry for my english :)" micheleconversano
Tickets Awaiting Review 39914 'orderby' date results differs depend on 'post_status' Query 4.7.2 normal normal Awaiting Review defect (bug) new 2017-02-19T09:40:43Z 2017-02-19T09:40:43Z "Default 'orderby' date return different order results depend on 'post_status' passed in WP_Query.
For example, 3 published posts with identical post_date (if bulk publish, import or other stuff) in WP_Query will return different posts order on page, which depend on 'post_status' = 'publish' or 'any'.
Since all posts are published, setting 'post_status' should not affect default orderby date results. Most notably this difference in edit.php?post_type= in comparison with front-end WP_Query results.
Is it normal behaviour of such querying results?" esemlabel
Tickets Awaiting Review 42422 'unique' index not removed from the 'slug' column of the 'wp_terms' table Taxonomy 4.8.3 normal normal Awaiting Review defect (bug) new 2017-11-02T19:07:15Z 2017-11-11T18:10:02Z "This is a follow-up to #22023.
It appears that on one of my older installations of wordpress the unique index was never removed from the 'slug' column of the 'wp_terms' table. The latest update 4.8.3 must have stirred something up with wp cron, conflicting with the unique status of the column. This has caused thousands of the following errors to be logged which in turn caused our server to 503 due to hitting the PHP FcgidMaxProcessesPerClass limit.
Note: this installation has had regular updates since being installed years ago.
{{{
stderr:
WordPress database error Duplicate entry 'category-slug' for key 'slug' for
query INSERT INTO `wp_terms` (`name`, `slug`, `term_group`) VALUES ('Category Name', 'category-slug', 0) made by do_action_ref_array, WP_Hook->do_action,
WP_Hook->apply_filters, _wp_batch_split_terms, _split_shared_term
}}}" joellisenby
Tickets Awaiting Review 43676 .htaccess rules don't work with Plain Rewrite Rules normal normal Awaiting Review defect (bug) new has-patch 2018-04-02T21:03:48Z 2022-01-05T12:08:54Z "If I use ""Plain Url Style"" in Permalink Settings then I can't add custom rules .htaccess from mod_rewrite_rules filter. I think that this is bug.
For example:
{{{#!php
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule wp-content/uploads/(.*) http://example.com/wp-content/uploads/$1 [NC,L]
\n\n"" . $rules;
return $rules;
}
add_filter( 'mod_rewrite_rules', 'uploads_from_remote_server' );
}}}
This filter not working in Plain Url Style but should." sebastian.pisula
Tickets Awaiting Review 44313 /wp-admin/css/forms.css problem when adding a