__group__,ticket,summary,owner,component,_version,priority,severity,milestone,type,_status,workflow,_created,modified,_description,_reporter
Future Releases,57030,Condition is not strictly checked on options-general.php file,SergeyBiryukov,Administration,3.0,normal,normal,Future Release,defect (bug),assigned,changes-requested,2022-11-08T09:56:56Z,2023-07-06T03:14:17Z,In options-general.php file it is 0 is being compared with another variable which is $current_offset. As 0 is numeric value this needs to be compared.,rakibwordpress
Future Releases,47505,Create a comprehensive input validation API for WordPress editor and administration interface,audrasjb*,Administration,,normal,normal,Future Release,defect (bug),accepted,,2019-06-07T14:24:03Z,2019-10-04T15:43:46Z,"Currently, WordPress lacks a comprehensive API for validating form input and alerting users to errors or missing fields. One example of how this can cause problems was captured by @conner_bw in #47018 -- failing to fill in the required ‘Name’ field when creating a new taxonomy term highlights the field in red but provides no textual message indicating that a required field is missing. As noted by @afercia:
> there are at least two WCAG success criteria (1 is level A, the other one is level AA) that requires a clear identification of the item in error and clear suggestions for correction.
([https://wordpress.slack.com/archives/C02RP4X03/p1556291609088300 See Slack discussion])
The lack of input validation mechanisms has also been noted as a shortcoming in Gutenberg ([https://twitter.com/thespacedmonkey/status/1136570949048909824 see tweet] from @spacedmonkey about this).
In the [https://wordpress.slack.com/archives/C02RP4X03/p1556291406082600 Slack discussion] of #47018, the Accessibility team agreed that the broader goal of researching and planning a comprehensive form validation API would be a valuable project that would benefit all users. This ticket should serve as a starting point for that exploration process. One example of how this could work shared during the discussion was something along the lines of Tenon’s React-based form validation library: [https://www.tenon-ui.info/forms-full-demo]
Two use cases that this API should cover:
- Required input is missing
- Required input is not the expected type
To be continued!",greatislander
Future Releases,56254,PHP Warning: Undefined array key 1 wp-admin\menu-header.php on line 202,,Administration,,normal,normal,Awaiting Review,defect (bug),new,has-patch,2022-07-20T10:30:24Z,2023-08-08T18:27:56Z,"i get the above warning when i use php version 8.1.6 in iis server,for php7.427 the code works , am using wordpress 6.0.1 released on jul 12 2022, am unable to fix it , kindly support , i get this error after succesfull login as admimistrator in plugin.php page , and other admin pages.",pras.88in
Future Releases,57393,Unify checkbox handling and match wording with function on the User Profile screen,,Administration,4.9,normal,normal,Future Release,enhancement,new,has-patch,2022-12-28T16:53:48Z,2023-02-07T06:14:36Z,"[The focus of this ticket shifted from discussing a potential functional bug to an improvement of wording and a more consistent behavior of checkboxes.
Using texts like ""Disable"" for toggled-on checkboxes can be confusing to users. For a better user experience, the toggled-on state should mean ""enabled"".]
Original ticket description:
CodeMirror highlighting, line numbers, code-folding, brace-matching and other customizations are disabled when highlighting is disabled. This is a real issue for plugins like code-snippets which rely on these features.
Here is the condition in question:
{{{
function wp_enqueue_code_editor( $args ) {
if ( is_user_logged_in() && 'false' === wp_get_current_user()->syntax_highlighting ) {
return false;
}
}}}
I believe that the user-form-variable syntax_highlighting is probably misnamed as it should be something like disable_syntax_highlighting to reflect the choice being made.
As it is, when ticked (true), highlighting should be disabled. When un-ticked (false), highlighting should be enabled.
{{{
if ( ! is_user_logged_in() || 'true' === wp_get_current_user()->syntax_highlighting ) {
return false;
}
}}}",mjdewitt
Future Releases,27888,Feature request: `get_current_admin_url()` and `get_current_admin_hook()`,lucatume,Administration,3.9,normal,normal,Awaiting Review,feature request,assigned,has-patch,2014-04-18T12:22:45Z,2019-12-11T20:16:46Z,"It would be sweet if to be able to get the current page's url using some kind of API. And its hook, for that matter. For instance:
{{{
public function get_current_admin_page_url()
{
if (!is_admin()) {
return false;
}
global $pagenow;
global $typenow;
global $taxnow;
global $plugin_page;
$url = $pagenow;
if (!empty($plugin_page)) {
$url .= '?page='.$plugin_page;
}
elseif (!empty($typenow)) {
$url .= '?post_type='.$typenow;
}
elseif (!empty($taxnow)) {
$url .= '?taxonomy='.$taxnow;
}
return $url;
}
}}}
And something similar for `get_current_admin_hook()`.",Denis-de-Bernardy
Future Releases,53692,Inaccurate schema for the app_id property in the application-passwords endpoints,,Application Passwords,5.6,normal,normal,Awaiting Review,defect (bug),new,has-patch,2021-07-19T12:28:48Z,2021-07-19T12:32:43Z,The schema for the `app_id` property of objects in the `wp/v2/application-passwords/*` endpoints has a `format` of `uuid`. This is not entirely accurate because if no app ID was provided when the application password was registered then this field contains an empty string.,johnbillion
Future Releases,57809,Application password success_url should allow http when host is localhost or localhost:port,,Application Passwords,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2023-02-25T21:32:38Z,2023-03-22T02:19:31Z,"When using wp-admin/authorize-application.php to walk a user through the application password flow, WordPress will refuse to use a success_url with an http scheme, requiring that it's https (or a custom scheme). This is good security, and browsers implement the same SSL requirement for many browser APIs for the same reason. However, browsers also have an exception for http://localhost URLs, because it makes local testing much easier. WordPress should do the same here; a local test of a web app which interacts with the WordPress API should be able to walk a user through the application passwords flow, and at the moment it can't. Similarly, a non-web app running on a desktop computer can stand up a temporary HTTP webserver on a high-numbered port to serve the success_url much more easily than it can register a custom URL scheme.",aquarius
Future Releases,60208,Prevent redirect loops,,Bootstrap/Load,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2024-01-07T20:16:15Z,2024-02-07T20:15:22Z,"There are all kinds of issues open that deal with redirect loops and their patches try to resolve the symptom.
I propose to instead fix the root cause by checking in wp_redirect/wp_safe_redirect if the $location is equal to the current host/request uri and if that's the case to not execute the redirect but wp_die - just like it's done in those function if response code is not in the 3xx range.
If a rogue plugin causes this, this will at least give you a hint of what was happening/where to start, when your WP page suddenly starts to reload indefinitely.",kkmuffme
Future Releases,49728,[PHP 8] Prepare for the internal functions throwing `TypeError` or `ValueError` exceptions on unexpected types/values,hellofromTonya,Build/Test Tools,,normal,minor,6.6,defect (bug),assigned,,2020-03-30T12:02:20Z,2024-02-18T15:03:30Z,"**Description**
PHP 8.0 is still in the making, but we know that certain changes are coming up to make things more straightforward and in favor of exceptions instead of rather silent PHP warnings.
One of these changes is that from PHP 8+, internal functions will throw an exception if the function call arguments are of a type that is not expected.
The simplest example would be `strlen([])`, which would throw `TypeError: strlen() expects parameter 1 to be string, array given` exception in PHP 8. You can read more at the RFC (https://wiki.php.net/rfc/consistent_type_errors) and a detailed Change Record (https://php.watch/versions/8.0/internal-function-exceptions).
WordPress has a PHPUnit annotation with the name `@expectedIncorrectUsage` that are used to track these kinds of errors. One example is at `Tests_DB::test_prepare_sprintf_invalid_args`, which uses the `@expectedIncorrectUsage` annotation to track PHP warnings, but instead, PHP 8's new TypeError triggers an exception (https://travis-ci.com/github/Ayesh/wordpress-develop/jobs/308369270#L2827).
**Proposal**
I propose to extend the `expectedIncorrectUsage` annotation to check the PHP version, and make PHPUnit expect a `TypeError` or a `ValueError`. Ideally, we should be expecting exactly a `TypeError` or a `ValueError` (sprintf too few arguments for example), which we can pass either from the annotation in the caller, or a check on the parent/sibling classes.
",ayeshrajans
Future Releases,53520,Add regression test for the wp_option data corruption bug,,Build/Test Tools,,normal,normal,Future Release,enhancement,new,,2021-06-26T01:22:16Z,2021-11-10T18:50:31Z,"Gutenberg v10.7.x introduced a bug that caused some `wp_option`s to get blank or corrupted data after (any) settings were updated in the `options-general.php` page. This was eventually fixed in v10.7.4, with this PR: https://github.com/WordPress/gutenberg/releases/v10.7.4. See https://github.com/Automattic/wp-calypso/issues/53447 and https://github.com/Automattic/wp-calypso/issues/53431.
There's already a regression E2E test in Gutenberg that was introduced in this PR: ttps://github.com/WordPress/gutenberg/pull/32797. Ideally, though, it'd be either moved to WP core or also implemented here. It doesn't need to be an E2E test, and could be a lower-level integration test, if we can figure out how to reproduce at a lower level (there was a failed attempt to do this, though, see this comment: https://github.com/WordPress/gutenberg/pull/32797#issuecomment-865005516.",fullofcaffeine
Future Releases,42076,Allow the external HTTP tests to run internally,,Build/Test Tools,,normal,normal,Awaiting Review,enhancement,new,,2017-10-03T16:44:26Z,2020-03-22T14:07:03Z,"The tests in the `external-http` group are the worst. They not only perform calls out over the internet, but they rely on a combination of wordpress.org, wordpress.com, example.org, example.com, and youtube.com.
The external oEmbed tests that use youtube.com (`Tests_External_HTTP_OEmbed`) can probably be removed. They're technically fragile (YouTube could change the structure of their embed URLs and cause the tests to fail) and don't actually test anything that core has control over.
It _should_ be possible to run the rest of the external-http tests against a local web server running PHP. As an example, frameworks such as Behat usually run against a server being run by PHP's built in web server.
If the test files from wordpress.com and wordpress.org were downloaded and placed into the test suite data directory, they could be served by a local web server and therefore tested without a remote HTTP request.
Spinning up a local web server in PHP could be made optional via a flag or an environment variable, and could be enabled on Travis by default.
It may even be that the functionality that is being tested by these external HTTP tests can be abstracted and made testable without performing an HTTP request at all, or it could be that the functionality is already covered by unit tests in the Requests framework.
Feedback / ideas welcome.",johnbillion
Future Releases,42278,Speed up tests by using shared user fixtures,,Build/Test Tools,,normal,normal,Future Release,enhancement,new,dev-feedback,2017-10-19T09:09:44Z,2019-01-08T10:13:51Z,"There are a lot of tests that require user fixtures. These are then created, and afterwards deleted, as part of the test class set up and tear down methods.
These fixtures could all be reused between tests, if a user for every role in Core would be created in the database as part of the unit test setup process.
If we had that, all the tests that need for example a user with the `editor` role could just grab the existing user from the database, instead of creating this as a test fixture.",Frank Klein
Future Releases,41451,Use pretty permalinks by default in the test suite,,Build/Test Tools,,normal,normal,Awaiting Review,enhancement,new,,2017-07-26T21:16:09Z,2018-10-19T11:13:58Z,"There are 118 instances of `$this->set_permalink_structure( ... )` in the test suite. The majority of these calls are present simply to enable pretty permalinks, regardless of the permastructure for posts.
Pretty permalinks should be enabled by default for the test suite. Let's try it and see if anything breaks.",johnbillion
Future Releases,53651,unit test for wp_removable_query_args,,Build/Test Tools,,normal,normal,Future Release,enhancement,new,,2021-07-12T23:38:51Z,2022-01-20T13:01:43Z,Added missing unit test,pbearne
Future Releases,40538,Fix or remove useless PHPUnit tests,johnbillion*,Build/Test Tools,,normal,normal,Future Release,task (blessed),accepted,has-patch,2017-04-23T01:11:24Z,2022-09-01T22:54:20Z,"There are 29 tests in the test suite which don't perform an assertion. They should be fixed or removed.
PHPUnit 6 has switched to being strict about useless tests by default, so that gives us an additional reason to address them. In addition, there's no reason for core's default PHPUnit configuration to not be strict about useless tests so the same behaviour is seen when running older versions of PHPUnit.
Previously: #36016",johnbillion
Future Releases,42093,Improve handling of SUBDOMAIN_INSTALL test coverage,jeremyfelt,Build/Test Tools,,normal,normal,Future Release,task (blessed),assigned,has-patch,2017-10-04T18:55:45Z,2023-10-20T14:15:29Z,"We have a bunch of tests that run (or are skipped) based on `is_subdomain_install()`, but our Travis CI configuration never runs the tests in a subdomain configuration.
To run the tests now, you need to setup the environment manually. In its current state, 7 tests fail:
{{{
1) Tests_Multisite_Site::test_created_site_details
2) Tests_Multisite_Site::test_new_blog_url_schemes with data set #0 ('https', 'https', false)
3) Tests_Multisite_Site::test_new_blog_url_schemes with data set #1 ('http', 'https', false)
4) Tests_Multisite_Site::test_new_blog_url_schemes with data set #2 ('https', 'http', false)
5) Tests_WP_oEmbed::test_wp_filter_pre_oembed_result_multisite_sub_samesub
6) Tests_WP_oEmbed::test_wp_filter_pre_oembed_result_multisite_sub_othersub
7) Tests_WP_oEmbed::test_wp_filter_pre_oembed_result_multisite_preserves_switched_state
}}}
The first is a result of our site factory only creating new subdirectory sites. I believe the `test_new_blog_url_schemes` should be skipped for `is_subdomain_install()`, but I haven't verified. I'm not sure yet what the issue is with the oEmbed tests.
I'd like to:
* Clean up the existing tests so that they pass.
* Determine a good way of running these in our Travis CI configuration.
It'd be nice *not* to run the entire set of core/multisite tests again just to account for this. Hopefully there's a creative approach to run only the subdomain specific tests.
Previously: #36567, #36566.
",jeremyfelt
Future Releases,26402,Add option to DB if option is only present in cache when updating option,,Cache API,3.8,normal,normal,Future Release,defect (bug),new,has-patch,2013-12-04T17:57:07Z,2017-03-17T17:45:33Z,"In very rare circumstances some options may not be in DB but in cache. On update if updating DB fails remove from cache and try to add option. This would eventually fix cache inconsistencies if they occur.
Both update_option and update_site_option are affected.",codix
Future Releases,30430,WP_Object_Cache does not properly cache objects nested in arrays,,Cache API,2.0,normal,normal,Awaiting Review,defect (bug),new,reporter-feedback,2014-11-21T00:17:31Z,2022-07-08T23:23:03Z,"I noticed on a plugin that cached data wasn't coming out the way it was inserted. What was happening is that it was an array of objects. The code would then go and change the original data and the data in the cache is changed. I would expect data retrieved from the cache to be exactly the same as what was inserted.
To make sure there was minimal performance impact I did some tests and the test script is attached. Initially I thought unserialize(serialize($data)) would be a good route, but it was twice as slow as rolling your own solution. I tried numerous methods and the function I initially build was always the fastest.
The transient/option table doesn't have this problem because it calls maybe_serialize.
Another way to fix this would be to call maybe_serialize on the set, and maybe_unserialize on a get but that would spread the cost to both functions and I think it is better to have the set be slightly more expensive than having every set and get take slightly longer.
",jamesgol
Future Releases,59661,WP_Query::generate_cache_key should consider changes to request via `posts_request_ids` filter.,thekt12,Cache API,,normal,minor,Future Release,defect (bug),assigned,has-patch,2023-10-17T15:10:17Z,2023-11-28T16:15:20Z,"In `WP_Query::get_posts()`, [https://github.com/WordPress/wordpress-develop/blob/781953641607c4d5b0743a6924af0e820fd54871/src/wp-includes/class-wp-query.php#L3175 $cache_key = $this->generate_cache_key( $q, $new_request );] doesn't consider the possibility for changes to the request via [https://github.com/WordPress/wordpress-develop/blob/6.3/src/wp-includes/class-wp-query.php#L3310 posts_request_ids] filter.
This can result in cache collision.
For example we have one page doing `get_posts` with this filter,
and we have a different page that doesn't use the filter but does the same `get_posts` with exactly same args. This will result in two different request to have same result.
To give overview, `posts_request_ids`filter is used to modify final `post_ids` in a split operation.
Solution is to have check for `has_filter( 'posts_request_ids' )`, serialize outcome from global `$wp_filter[ 'posts_request_ids' ]` and set to to `args` before cache_key is generated. Seralization we also allow for the cases where just one of he array of filters set in `posts_request_ids` is modified.
",thekt12
Future Releases,21650,replace serialize() with print_r() in stats() function in wp-includes/cache.php,,Cache API,3.4.1,normal,normal,Future Release,defect (bug),new,has-patch,2012-08-21T13:42:29Z,2022-10-10T19:46:05Z,"In PHP 5.3 it is no longer possible to serialize data that contains a SimpleXMLElement object. It produces a fatal error. See https://bugs.php.net/bug.php?id=49800
The stats() function attempts to determine the allocated space for objects in the cache by using strlen() of the serialized object.
This can fail for the reason above.
Given that the figure returned is simply an estimation of the space
I propose that the code is changed to use
print_r( $cache, true ) instead of serialize( $cache )
ie. to become
`echo ""
';`
This TRAC was raised after a longish chain of events starting with #18488 and the final response (today) which led to another chance discovery of a similar problem in the debug-bar plugin.
http://wordpress.org/support/topic/plugin-debug-bar-fatal-error-uncaught-exception-serialization-of-simplexmlelement-is-not-allowed
",bobbingwide
Future Releases,28664,"wp_load_alloptions() fails to set object cache when persistent alloptions cache is ""0""",,Cache API,,normal,normal,Awaiting Review,defect (bug),new,has-patch,2014-06-28T17:44:57Z,2022-07-08T14:55:25Z,"When alloptions persistent object cache is set to `0`, `wp_load_alloptions()` fails to reset it with appropriate values. This results in every use of `get_option()` to produce the load alloptions query `SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'` because the object cache never gets appropriately populated. Specifically, `wp_cache_add()`won't set the alloptions value when it's already seen to be set.
The end result is a massive impact on site performance when the object cache backend failboats. I'd expect WordPress to handle this scenario a bit more gracefully, possibly falling back to its internal object cache if it detects failures with the persistent object cache. However, it's debatable as to whether the solution lies within a drop-in, or whether it's the responsibility of core.
`wp_cache_add()` is used over `wp_cache_set()` for performance reasons with *external* object caches — it doesn't matter one way or another for the internal object cache (genesis #4138). One option is to distinguish between them, and offer different behaviors. However, the most technically appropriate solution is likely to check that the data coming from `wp_cache_get()` is as expected.
To answer your question before you ask it, I'm not sure how the Memcached persistent object cache value gets set to zero. It seems to come and go, sometimes occurring regularly when I restart Memcached, and I've seen the issue reproduce with both Ryan Boren's and Zack Tollman's drop-ins (meaning real bug is most likely outside of WordPress).",danielbachhuber
Future Releases,44744,Bug on canonical redirect with Hebrew query string.,SergeyBiryukov,Canonical,4.9.8,normal,major,Future Release,defect (bug),reviewing,has-patch,2018-08-06T14:52:40Z,2019-11-09T10:42:56Z,"Hello,
Example URL:
http://domain.com/?שלום
The example comes after having problems with Woocommerce product filters.
Line 491-493 in {{{/wp-includes/canonical.php}}} we have this:
{{{#!php
''/%postname%'') in the adjacent input field. Therefore, the value of ''$wp_rewrite->use_trailing_slashes'' is changed to false.
**Step 2. Trigger the canonical redirect on front page**
Now let's disable the feed URL by redirecting the visitors trying to access it:
{{{#!php
''http://example.com'').
The problem is that the PHP notice is displayed then:
''Notice: Undefined index: path in /var/www/vhosts/maciejbis.net/example.com/wp-includes/canonical.php on line 576 ''
I guess that the source of the problem is here (line 501):
https://core.trac.wordpress.org/browser/tags/5.5.1/src/wp-includes/canonical.php#L501
{{{#!php
$redirect['path'] = user_trailingslashit( $redirect['path'] );
}}}
Unfortunately because of ''user_trailingslashit()'' function, the slash is removed and value is set to ''null''. The value of `$redirect['path']` should not be changed in this particular case (value '/' should be preserved).
My first suggestion is to exclude ''user_trailingslashit()'' function there and not use it when value of `$redirect['path']` variable is just a single slash '/':
{{{#!php
$redirect['path'] = ( $redirect['path'] === '/' ) ? $redirect['path'] : user_trailingslashit( $redirect['path'] );
}}}
Another idea is to do the same but directly in ''user_trailingslashit()'' function:
https://core.trac.wordpress.org/browser/tags/5.5.1/src/wp-includes/link-template.php#L51
Basically this piece of code:
{{{#!php
if ( $wp_rewrite->use_trailing_slashes ) {
$string = trailingslashit( $string );
} else {
$string = untrailingslashit( $string );
}
}}}
can be replaced with:
{{{#!php
if ( $wp_rewrite->use_trailing_slashes ) {
$string = trailingslashit( $string );
} else if ( $string !== '/' ) {
$string = untrailingslashit( $string );
}
}}}
",mbis
Future Releases,39535,Canonical redirects disallow tag named comments,,Canonical,,normal,normal,Future Release,defect (bug),new,has-patch,2017-01-10T09:04:05Z,2019-02-28T19:41:33Z,"The `redirect_canonical` function includes a regular expression replacement which effectively disallows tags named ""comments"" to have an RSS feed:
https://github.com/WordPress/WordPress/blob/master/wp-includes/canonical.php#L285
For example:
/blog1/tag/comments/feed/
This is redirected to:
/blog1/tag/feed/
Could / should the regular expression on line 285 could pay attention to the first placeholder it matched (`comments/?`) or check whether the page is a tag request?",dwc
Future Releases,43274,Changing $(comments|feed)_base of WP_Rewrite causes errors because of hardcoded strings in redirect_canonical(),,Canonical,,normal,normal,Future Release,defect (bug),new,has-patch,2018-02-09T21:11:37Z,2019-01-14T22:41:57Z,"When you change `$comments_base`/`$feed_base` for `WP_Rewrite` instance, URLs with that base will not work because `comments` and `feed` strings are hardcoded in a few places in `redirect_canonical()`. Changing these to use `$wp_rewrite->comments_base` and `$wp_rewrite->feed_base` respectively will fix this issue.
NOTE: When testing feed URLs, changing `feed` with `feed_base` in `example.com/feed/` will not work. Feed URLs work in two places: `example.com/(feed|rss2?|rdf|atom)` and `example.com/feed_base/(feed|rss2?|rdf|atom)` ([https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-wp-rewrite.php?rev=42343#L860 see rules]). When you open `example.com/feed/` you match first rule where `feed` is type of feed. You need second rule to test it.
There is quick workaround though:
{{{#!php
add_action( 'after_setup_theme', function() {
$GLOBALS['wp_rewrite']->feed_base = 'mycustomfeedbase';
$GLOBALS['wp_rewrite']->feeds[] = 'mycustomfeedbase';
} );
add_action( 'parse_query', function( $q ) {
if ( $GLOBALS['wp_rewrite']->feed_base == $q->get( 'feed' ) ) {
$q->set( 'feed', 'feed' );
}
} );
}}}
Don't forget to flush rewrite rules.",dimadin
Future Releases,28081,Do a canonical redirect for pages when query var 'paged' is set,SergeyBiryukov*,Canonical,,normal,normal,Future Release,defect (bug),accepted,has-patch,2014-04-30T19:53:12Z,2023-03-22T13:28:23Z,"Example: http://make.wordpress.org/core/features-as-plugins/page/2323/
You can append /page/{any number} to a page and still get the same content as http://make.wordpress.org/core/features-as-plugins/
The same doesn't happen for posts.
[source:/trunk/src/wp-includes/canonical.php#L274]: Seems like l274 and l276 should be !is_singular() as it was before [6115]. (Block was changed in [9697].)
Want to use this ticket to get some reasons for [6115]. Currently I only can think of custom page templates which are using a custom pagination, so maybe wontfix.",ocean90
Future Releases,50163,Perform a canonical redirect when paginated states of the front page are not found,hellofromTonya,Canonical,,normal,normal,Future Release,defect (bug),assigned,has-patch,2020-05-14T06:44:54Z,2022-04-04T05:37:27Z,"As a followup to #45337, [34492], and [47727].
When example.com/ has a static front page assigned and uses `` accessing non-existing pages uses example.com/page/3/ and Canonical won't kick in.
This is because paged states of the front page use the `paged` query var, not the `page` query var.
Should also fix https://meta.trac.wordpress.org/ticket/5184 :)",dd32
Future Releases,39827,notice in wp-includes/canonical.php:392,SergeyBiryukov,Canonical,4.7.2,normal,normal,Future Release,defect (bug),reopened,has-patch,2017-02-10T02:28:03Z,2024-02-15T09:23:06Z,"Hello,
We're getting notice in wp-includes/canonical.php:392, but it requires some specific steps to obtain it.
Steps:
1. Setup a clean install of WPML
2. Set permalinks to postname without ending slash: /%postname%
3. Create a page in secondary language
4. Set this page as Home Page (under Settings/Reading) but only in the secondary language
When you enter ""home page"", you get 404 because a page for original language does not exist.
In line 121, you get {{{$redirect_url = get_permalink($redirect_post);}}} and value of $redirect_url is for instance ""http://testsite.dev?lang=fr"". As you see, there is no ""/"" before ""?"", that's why path is empty.
You have already fixed the similar issue in line:77-79
{{{#!php
// Notice fixing
if ( !isset($redirect['path']) )
$redirect['path'] = '';
}}}
I suspect, we need the same fix before line: 392
{{{#!php
$redirect['path'] = preg_replace('|/' . preg_quote( $wp_rewrite->index, '|' ) . '/*?$|', '/', $redirect['path']);
}}}
",jakubbis
Future Releases,21602,redirect_canonical can lead to infinite loop on index navigation if site url is not all lower case,,Canonical,,normal,blocker,Future Release,defect (bug),assigned,has-patch,2012-08-15T21:31:17Z,2023-04-29T00:09:21Z,"The function redirect_canonical in wp-includes/canonical.php (WordPress 3.4.1) on line 406 and 422 makes the following check:
{{{
if ( !$redirect_url || $redirect_url == $requested_url )
return false;
}}}
This ensures that it does not attempt to redirect you to the page you requested in the first place. However this function is not case sensitive so if the redirect URL is in a different case than the requested URL then the user can enter an infinite redirect loop. (For example if the Site Address (URL) of the site is set to be in all upper case.)
This function should do a case-insensitive string comparison since domain names are case-insensitive.
The issue only appears to happen with certain plugins installed (ShareThis and PilotPress both led to this issue,) I haven't figured out yet why it's only an issue with certain plugins but it should still be fixed in WordPress to make the proper string comparison. ",sreedoap
Future Releases,33821,redirect_canonical does not consider port in $compare_original,,Canonical,2.3,normal,normal,Future Release,defect (bug),new,has-patch,2015-09-11T03:18:16Z,2019-09-23T21:12:34Z,"In the `wp-includes/canonical.php` file the `$requested_url` is built starting at line 64. It combines `is_ssl()` for protocol, `$_SERVER['HTTP_HOST']`, and `$_SERVER['REQUEST_URI']` - but it does not consider `$_SERVER['SERVER_PORT']`
This causes a redirect loop for us because we run HTTPS on port 8443.
I suggest checking to see if a port other than 80 or 443 is being used and adding that as part of the comparison - suggested patch attached.",willshouse
Future Releases,44899,redirect_canonical redirects to another URL when it should not,,Canonical,4.9.8,normal,critical,Awaiting Review,defect (bug),new,,2018-09-05T14:34:56Z,2018-09-06T07:32:25Z,"Hi,
on a fresh install of WordPress 4.9.8 :
http://sub.yourdomain.com/?xtor=AD-4970-%5BSocial%5D-%5B%5D-%5BPPL%5D-%5BFacebook%5D-%5B228284160&105478095%5D-%5B0%5D
will be redirected to :
http://sub.yourdomain.com/?xtor=AD-4970-%5BSocial%5D-%5B%5D-%5BPPL%5D-%5BFacebook%5D-%5B228284160&105478095]-%5B0%5D
Problem is : it does an 301. And, combined with Facebook mobile on Iphone link to the WordPress, it retries forever. 21 000 hits / 5 minutes on our server. Glad it was strong enough to sustain until we find the bug and temporarily deactivated
{{{
redirect_canonical
}}}
with :
{{{#!php
set( 'post_type', [ 'post', 'portfolio', 'page' ] );
}
add_action( 'pre_get_posts', '_debug_php_warning_on_404' );
}}}
Then try a missing page slug __domain.test/missing-content__ it will show a warning:
wpdb::prepare was called incorrectly. The query only expected one placeholder, but an array of multiple placeholders was sent. Please see Debugging in WordPress for more information. (This message was added in version 4.9.0.)
The fix is to replace line 700 and check for array ""post_type"" query var:
{{{
if ( $post_type = get_query_var( 'post_type' ) ) {
if ( is_array( $post_type ) ) {
$where .= "" AND post_type IN ('"" . implode( ""', '"", esc_sql( $post_type ) ) . ""')"";
} else {
$where .= $wpdb->prepare( ' AND post_type = %s', $post_type );
}
}
}}}",arl1nd
Future Releases,4328,"Redirect Old Slugs feature needs to redirect slugs for pages, not just posts, and redirect old permalink structure",SergeyBiryukov,Canonical,2.2,normal,normal,Future Release,enhancement,reviewing,early,2007-05-24T01:52:44Z,2022-01-25T14:30:12Z,"Create a page, browse to it, edit it, change its slug, WP redirects to the old page's slug and serves a 404. Wasn't WP 2.1 or WP 2.2 supposed to make the redirect old slug feature built-in?
Along the same lines, it would be sweet if instead of simply redirect old slugs, WP would redirect old urls. When the date changes, when the page parent changes, or when the permalink structure changes, the url changes but neither of WP, the redirect old slug plugin, the permalink redirect plugin, or anything else catches this.",Denis-de-Bernardy
Future Releases,59868,Database insert with emoji fails when table has columns with both utf8mb3 (utf8) and utf8mb4 charsets,,Charset,4.2,normal,normal,Future Release,defect (bug),new,,2023-11-09T14:41:41Z,2023-12-14T21:19:02Z,"The `wpdb::get_table_charset()` function currently sets the charset to `utf8` when it detects that both `utf8` and `utf8mb4` charsets are present in the table's column definitions.
That same function also swaps in `utf8` for `utf8mb3` as they are effectively the same thing.
This means that the `wpdb::strip_invalid_text_from_query()` function used early by the `wpdb::query()` function to determine whether text is safe to be inserted, ends up stripping `utf8mb4` safe characters because it forces the use of `utf8` in the called `wpdb::strip_invalid_text()` function.
This results in insert queries failing where a table has columns with both `utf8mb3/utf8` and `utf8mb4` collations used, and there are emojis or other 4 byte characters being used in the column that has a `utf8mb4` charset and collation defined.
I propose that the `wpdb::get_table_charset()` function should use `utf8mb4` as the returned charset when it detects that 2 charsets are defined on the table, and they are `utf8` and `utf8mb4`, instead of the current behaviour of returning `utf8`.",ianmjones
Future Releases,60281,Cannot unset comment_notes_before,,Comments,3.0,normal,normal,Future Release,defect (bug),new,,2024-01-18T12:11:15Z,2024-01-18T17:02:39Z,"I want to reorder comment fields by unsetting and setting them back in my chosen order. Here's my code:
{{{
function my_reorder_comments_fields( $fields ) {
$comment_notes_before_field = $fields['comment_notes_before'];
$comment_field = $fields['comment'];
$author_field = $fields['author'];
$email_field = $fields['email'];
$url_field = $fields['url'];
$cookies_field = $fields['cookies'];
unset( $fields['comment_notes_before'] );
unset( $fields['comment'] );
unset( $fields['author'] );
unset( $fields['email'] );
unset( $fields['url'] );
unset( $fields['cookies'] );
$fields['author'] = $author_field;
$fields['email'] = $email_field;
$fields['comment_notes_before'] = $comment_notes_before_field;
$fields['cookies'] = $cookies_field;
$fields['comment'] = $comment_field;
return $fields;
}
add_filter( 'comment_form_fields', 'my_reorder_comments_fields' );
}}}
Result - https://imgur.com/a/ebY1HBW
You can see that `$fields['comment_notes_before']` remains on top.
To prove the point, I changed my code to just unset all fields:
{{{
function my_unset_comments_fields( $fields ) {
unset( $fields['comment_notes_before'] );
unset( $fields['comment'] );
unset( $fields['author'] );
unset( $fields['email'] );
unset( $fields['url'] );
unset( $fields['cookies'] );
return $fields;
}
add_filter( 'comment_form_fields', 'my_unset_comments_fields' );
}}}
Result: https://imgur.com/a/B5wNngj
So `$fields['comment_notes_before']` isn't getting unset while all other fields do.",bugnumber9
Future Releases,40143,Comment template functions don't check for comment existence,,Comments,,normal,normal,Future Release,defect (bug),new,has-patch,2017-03-13T16:59:35Z,2024-02-08T16:10:20Z,"Discovered during debugging an issue with Circle Lite theme, which uses [https://themes.trac.wordpress.org/browser/circle-lite/1.0.9/comments.php?marks=55#L42 comment_text( true )] in `kopa_comment_callback()` function.
That, while being an invalid usage (the function treats `true` as a comment ID), causes an inconsistent behaviour, depending on the existence of the comment:
* If the comment with ID 1 exists, the function returns its text, as expected. That's obviously not what the author of the theme intended, but still the correct behaviour of the function.
* If the comment with ID 1 does not exist, the function returns the text of the current comment in the loop instead of an empty string. What happens is `get_comment( $comment_ID )` returns null (as expected), but then null is passed to `get_comment_text()`, which treats it as the current comment.
After investigating more, it looks like most of comment template functions are either affected in a similar way or cause an undefined property notice when passed a non-existing comment ID. Let's bring some consistency here.",SergeyBiryukov
Future Releases,13792,Invalid reply link from comment admin when comment nested level > max,,Comments,2.9.2,normal,normal,Future Release,defect (bug),reopened,has-patch,2010-06-09T07:05:56Z,2017-07-31T16:17:39Z,"I have a blog with nested comments enabled, max depth of 4. When the last level comment is posted, it no longer contains a Reply link.
However, in the Comment admin, the Reply link is still present. If used, this new reply will show up at the very bottom of the comment list once posted (even if other newer regular comments are entered, this new reply will still show up at the very bottom).
The bug is, basically, that Comment admin doesn't respect the max nested value.",archon810
Future Releases,39566,WordPress ignoring previously approved comment for some comment authors,rachelbaker,Comments,4.7,normal,major,Future Release,defect (bug),assigned,,2017-01-12T15:41:04Z,2018-10-08T02:36:17Z,"I seem to have a reproducible bug with the option ""Comment author must have a previously approved comment"".
My client has a site that heavily uses guest commenting. They have selected the option ""...must have previously approved comment"". This works well most of the time, however more frequently some guests (identified by email) are being flagged as not having a previously approved comment even though they do. For one author (email) in question I am able to replicate this every time.
- All other possible comment moderation disabled.
- Comment as the guest in question, comment moderated.
- Log in as admin, approve the comment.
- Comment a second time as the guest, comment moderated again (shouldn't be)
- Disable the option ""must have previously approved...""
- Comment a third time, now the comment is approved automatically.
- Re-enable option ""must have previously approved...""
- Comment a forth time, the comment is moderated.
This appears to be a bug to me, and I can reproduce it every time. Not sure how to troubleshoot this further from here.",rperrett
Future Releases,45498,Wrong order of arguments in call_user_func() for Walker_Comment::start_el(),SergeyBiryukov,Comments,,normal,normal,Future Release,defect (bug),reviewing,has-patch,2018-12-06T16:52:14Z,2019-01-16T05:46:01Z,"Arguments order for rendering all types of comments is `$comment, $depth, $args` except for the custom callback:
`call_user_func( $args['callback'], $comment, $args, $depth );`
This causes every custom callback to throw an error when you use `$args` and `$depth` as you'd expect.
For example, `comment_reply_link()` inside callback can not be used like it's suppose to be used, like so:
{{{#!php
'div-comment',
'depth' => $depth,
'max_depth' => $args['max_depth'],
'before' => '
',
'after' => '
'
) ) );
}}}
You need to replace `$depth` and `$args`, like so:
{{{#!php
'div-comment',
'depth' => $args,
'max_depth' => $depth['max_depth'],
'before' => '
',
'after' => '
'
) ) );
}}}
",milana_cap
Future Releases,34475,get_comment_link incorrect page number in returned url.,SergeyBiryukov,Comments,4.3.1,normal,normal,Future Release,defect (bug),reviewing,reporter-feedback,2015-10-28T16:36:42Z,2019-10-03T22:15:05Z,Since 4.3 core update the get_comment_link function returns incorrect page numbers for paginated comments. Have tried using default twentyfifteen theme with no plugins enabled and issue still persists.,Property118
Future Releases,19739,Filters to allow comments on draft & trash post_status posts,,Comments,3.3,normal,normal,Future Release,enhancement,new,has-patch,2012-01-04T19:01:18Z,2023-03-02T15:52:31Z,"I'd like to use comments on draft posts as part of an editorial workflow. Will this be as easy as adding a filter to fire before the current comment_on_draft action that can be checked before exiting? I'll try that and add a patch if it looks good.
Related #13276. Not relevant to #18630, I think.",cyberhobo
Future Releases,39084,Introduce singular capabilities for managing individual comments,,Comments,,normal,normal,Future Release,enhancement,new,,2016-12-04T22:14:50Z,2017-07-14T19:41:15Z,"As we did in #35614 for taxonomy terms, singular capabilities should be introduced for approving, unapproving, spamming, unspamming, editing, and deleting individual comments.
This would allow fine-grained cap checks such as current_user_can( 'edit_comment', $comment_id ) and current_user_can( 'approve_comment', $comment_id ).",johnbillion
Future Releases,36564,Last Modified for Comments,,Comments,4.4,normal,trivial,Future Release,enhancement,new,dev-feedback,2016-04-17T20:44:59Z,2017-02-12T10:37:16Z,"Related #28463, #19495.
Posts have a last modified and last modified gmt, but comments have no such thing. There are several proposals indicating a need for comment revision, or tracking when the comment is first created.
Wanted to explore the idea of having last modified and last modified gmt stored as comment meta triggered by update_comment as a simple, low impact way of adding this feature that could be used by a variety of plugins.
This could be implemented by plugin hooking to edit_comment, but if such a feature is to be useful, it needs a standard storage format.",dshanske
Future Releases,33735,Reduce Duplication and Improve Comment Notification Email Functions,SergeyBiryukov,Comments,,low,normal,Future Release,enhancement,reviewing,dev-feedback,2015-09-04T22:55:04Z,2021-01-27T19:20:55Z,"Had touched on this in #33587.
wp_notify_postauthor and wp_notify_moderator have some duplicative code that could be eliminated and simplified.
The functions for notification also lack a filter similar to the one for displaying the comment text.
Proposing the function to show the comment in text form in the notification be separated out into its own function with a filter, and the default text be improved somewhat.
",dshanske
Future Releases,41339,WP_Comments_Query::__construct() should allow a 'status__not_in' parameter,,Comments,4.9,normal,normal,Future Release,enhancement,new,has-patch,2017-07-15T19:47:02Z,2017-07-30T15:24:18Z,"`WP_Comments_Query::__construct()` (and hence, `get_comments()`) currently allows a `status` parameter to get comments with a specific status.
It would be useful to also allow `$status__not_in` to exclude comments with specific stati.
Related: #41338",pbiron
Future Releases,47590,Add unit tests for requests to wp-cron.php,,Cron API,,normal,normal,Future Release,defect (bug),new,,2019-06-22T13:51:07Z,2019-06-30T22:07:49Z,"1. Ensure scheduled events are rescheduled correctly
1. Ensure single events are removed from the cron array
1. Ensure future events are not changed.
1. Ensure `doing_cron` transient is deleted.",peterwilsoncc
Future Releases,57271,Cron unschedule / reschedule event errors,audrasjb,Cron API,6.0,normal,normal,Awaiting Review,defect (bug),assigned,has-patch,2022-12-04T09:55:55Z,2024-03-07T01:04:44Z,"Multiple users have reported errors since v6.0 across installs with completely different themes and plugins ...
{{{
[09-Nov-2022 11:28:28 UTC] Cron unschedule event error for hook: do_pings, Error code: could_not_set, Error message: The cron event list could not be saved., Data: {“schedule”:false,”args”:[]}
[09-Nov-2022 18:05:03 UTC] Cron unschedule event error for hook: wordfence_processAttackData, Error code: could_not_set, Error message: The cron event list could not be saved., Data: {“schedule”:false,”args”:[]}
[21-Nov-2022 07:53:04 UTC] Cron reschedule event error for hook: wf_scan_monitor, Error code: could_not_set, Error message: The cron event list could not be saved., Data: {“schedule”:”wf_scan_monitor_interval”,”args”:[],”interval”:60}
[21-Nov-2022 07:53:04 UTC] Cron unschedule event error for hook: wf_scan_monitor, Error code: could_not_set, Error message: The cron event list could not be saved., Data: {“schedule”:”wf_scan_monitor_interval”,”args”:[],”interval”:60}
}}}
There are many more examples on the support thread https://wordpress.org/support/topic/cron-unschedule-event-error-for-hook/
I have so far been unable to find a way to manually re-produce this issue but this is what I have discovered so far ...
So this error happens when `wp_unschedule_event()` and `wp_reschedule_event()` fails.
`could_not_set` error is presented by` _set_cron_array()` which is the return function for `wp_unschedule_event()` and `wp_schedule_event()`.
`could_not_set` error is returned by `_set_cron_array()` when the updating of the cron table fails with `update_option( 'cron', $cron );`.
`update_option()` fails when …
1) The `$option` parameter is empty
This should never happen
2) The old option value is the same as the new option value
This suggests the cron job is running more than once but may not be the only reason ... ?
3) The database insert query `$wpdb->update()` fails
This is a bit worrying but shouldn’t be the case as surely there should be an accompanying database error?
I think we can rule out (1) seeing as the `$option` parameter is never empty.
We can maybe rule out (2) because from the thread above, this happens on high traffic sites as well as low traffic sites and on sites using the default wp-cron firing as well as cron fired by the system … ?
The leaves (3) being the most likely cause of the ""bug"".
I have tried to assign to @audrasjb (I hope that's OK to do?) because they added the commit on the 20th September that started to highlight the issue https://github.com/WordPress/WordPress/commit/84d19848666a81584e0007a6ab7f7ad3c990d71a
I realise that this is not going to be easy to diagnose until the issue can be manually replicated but I think it should be looked into.
Oliver
",domainsupport
Future Releases,50781,500 error caused by customize_changeset_uuid for non-authenticated users,,Customize,4.7,normal,normal,Future Release,defect (bug),new,dev-feedback,2020-07-27T08:40:21Z,2023-02-25T05:22:45Z,"Hello,
I have noticed that if a non-authenticated user visits a URL containing the following get parameter: `?customize_changeset_uuid=SOME_ID_HERE` WordPress returns 500 error.
There should be no reason to allow bots to flood someones Apache log with 500 errors by simply adding a get parameter.
If a user is not authenticated and they add the `?customize_changeset_uuid=ID_HERE` parameter they should either be redirected or the get parameter should be ignored rather than getting a 500 error.
Thanks for the consideration. ",bacardy4
Future Releases,39254,"When in Customizer Preview, starter content posts are not displayed in the loop",westonruter*,Customize,4.7,normal,normal,Future Release,defect (bug),accepted,reporter-feedback,2016-12-12T21:03:24Z,2020-05-27T04:33:56Z,"As discussed in [https://wordpress.slack.com/archives/core-customize/p1481567934000409 Slack], posts in Starter Content aren't appearing in the posts list.
Being able to display the bundled content, specifically posts, is key for an improved user experience when configuring a new theme. Posts give structure to the theme, allowing users to see exactly how the theme will look with content.
This would also allow theme developers to completely match the content bundled with the theme to the content on the theme’s demo site. This helps address the popular complaint amongst WordPress users that a newly installed theme looks nothing like the demo.",tiagonoronha
Future Releases,21627,Filter for custom-background CSS selector,peterwilsoncc,Customize,3.4.1,low,minor,Future Release,enhancement,assigned,,2012-08-18T11:46:55Z,2021-05-22T17:41:50Z,"There should be an easier way for changing the css selector from body to html or any other then making your own callback.
",Horttcore
Future Releases,40922,Use finer-grained capabilities with `customize_changeset` post type,,Customize,4.7,normal,normal,Future Release,enhancement,new,,2017-06-05T04:44:01Z,2020-05-16T17:41:59Z,"The `customize_changeset` post type is currently registered with all of its post type capabilities set to `customize`. As part of adding changeset endpoints in the REST API (#38900):
> fine-grained capabilities should be introduced for the `customize_changeset` post `caps`, instead of mapping all to `customize`.
@westonruter has compiled links to previous discussions and efforts around changeset capabilities here: https://github.com/WP-API/wp-api-customize-endpoints/pull/5#discussion_r118804994.
An example of unexpected behavior caused by the current mapping is where a post ID is passed to `current_user_can()`, such as
{{{
current_user_can( get_post_type_object( 'customize_changeset' )->cap->edit_post, $changeset_post_id )
}}}
This is equivalent to `current_user_can( 'customize' )`, which means the post ID is ignored because `map_meta_cap()` doesn't check the `$args` when mapping the `'customize'` meta cap.",dlh
Future Releases,35857,"Add QUnit tests for Customizer preview, including Selective Refresh",,Customize,3.4,normal,normal,Future Release,task (blessed),assigned,,2016-02-18T08:26:15Z,2023-03-17T17:06:23Z,"Initial Customizer unit tests for PHP and JS were added in #28579. The QUnit tests were done specifically for the Customizer controls (pane) and not the Customizer preview. This was understandable since he preview was devoid of much unique JS functionality. With the introduction of the Selective Refresh component (#27355), this has changed. There needs to be a new QUnit test suite specifically for the Customizer preview.
See @valendesigns initial foundation work here: https://github.com/xwp/wp-customize-partial-refresh/pull/32/files#diff-6fcbfd120899db12c05cdb1f6142cd87 ",westonruter
Future Releases,51486,The add_option function should not be able to update existing rows in the database.,,Database,2.9,normal,normal,Awaiting Review,defect (bug),new,,2020-10-09T01:12:29Z,2022-06-09T12:18:11Z,"In certain edge cases, `add_option` is able to update existing option values. This should not be possible. If SQL is executed which instructs ""Insert XYZ"" into database, then the insert should fail if the key already exists in the database, unless the SQL specifies that an UPDATE should happen.
The `add_option` function does check first to see if an option exists before attempting to add it to the database. In the overwhelming majority of cases, this works fine because when the option exists the function will return early before attempting to insert into the database.
However, consider a scenario where an object cache is being used. And further consider that the object cache may report incorrectly. If the object cache tells `add_option` that the value doesn't exist in the database (but in reality it does!), then `add_option` continues on and attempts to insert the supposedly new option.
In that particular circumstance, the SQL query, shown below, is executed which will insert the new row. And in the event that the option already exists, it will be overwritten.
The issue here is that `add_option` shouldn't be able to update the existing value. The query should fail. Why is the `ON DUPLICATE KEY UPDATE` clause included here?
{{{#!php
query(
$wpdb->prepare(
""INSERT INTO `$wpdb->options` (`option_name`, `option_value`, `autoload`)
VALUES (%s, %s, %s)
ON DUPLICATE KEY UPDATE
`option_name` = VALUES(`option_name`),
`option_value` = VALUES(`option_value`),
`autoload` = VALUES(`autoload`)
"",
$option,
$serialized_value,
$autoload
)
);
}}}
I realize this is an edge case. If the object cache being used gives bad information to `add_option` then really its the object caching plugin at fault. However, I can't understand a possible circumstance where `add_option` should ever UPDATE an existing option. The SQL here should not include `ON DUPLICATE KEY UPDATE`. Am I missing something? Is there a good reason for that clause? What would happen if that clause were removed?",khag7
Future Releases,28625,Enhancement: Add constants to support SSL connections for mysqli,,Database,4.0,normal,normal,Future Release,enhancement,assigned,has-patch,2014-06-24T22:39:12Z,2023-06-24T12:22:46Z,"In order to support SSL'ed MySQL connections with the `mysqli_*` functions introduced in WordPress 3.9 / PHP 5.5 `mysqli_ssl_set()` must be called to set the path to the SSL certs and keys to be used by the MySQL client before `mysqli_real_connect()` is called.
We should add the following optional constants to allow for users to configure secure connections to the database.
* `MYSQL_SSL_KEY`
* `MYSQL_SSL_CERT`
* `MYSQL_SSL_CA`
* `MYSQL_SSL_CA_PATH`
* `MYSQL_SSL_CIPHER`
In addition this should only be set if the feature flag `MYSQLI_CLIENT_SSL` is set for the existing `MYSQL_CLIENT_FLAGS` constant.",hypertextranch
Future Releases,54669,Remove ONLY_FULL_GROUP_BY from incompatible wpdb modes,,Database,3.9,normal,normal,Awaiting Review,enhancement,new,,2021-12-20T12:56:22Z,2022-06-15T20:52:56Z,"as GROUP BY is non-deterministic otherwise, ONLY_FULL_GROUP_BY ensures this is not the case.
which is why this is enabled by default since MySQL 8
I guess it was disabled originally, as some queries would have to be updated in WP core.
I think however, this should be done now, as otherwise we're accumulating more and more technical debt.",malthert
Future Releases,41424,"Use a better error message than ""Error establishing a database connection"" when site isn't found",,Database,4.9,normal,normal,Future Release,enhancement,new,,2017-07-24T14:24:44Z,2017-11-22T08:58:59Z,"In multisite, if this query returns no results, the database connection error is triggered:
SELECT blog_id FROM wp_blogs WHERE domain IN ( 'example.com' ) AND path IN ( '/' ) ORDER BY blog_id ASC LIMIT 1
I think the error should not mention database connection but allude to the fact that the site was not found.
For my use case, I had migrated a production database into QA and didn't update the domain to be qa.example.com so the connection failed.
I hope this is helpful. I'm not sure I know what the exact solution is but I thought the connection attempt had failed, when in fact the connection had been made but the data was not as expected. Also, the failure was not found in debug.log.",tthorp
Future Releases,40357,"dbDelta can't change primary keys, create AUTO_INCREMENT columns and doesn't make significant index changes",,Database,4.8,normal,normal,Awaiting Review,enhancement,new,has-patch,2017-04-04T17:20:04Z,2017-04-04T18:21:02Z,"dbDelta has three inter-related issues which center around changing indexes.
1) It isn't possible to change which column is the primary key
2) It isn't possible to add a new AUTO_INCREMENT column
2b) It isn't possible to modify an existing AUTO_INCREMENT to no longer be AUTO_INCREMENT
3) Indices with the same name are not dropped/re-created, even when the index definition is changed significantly.
== Use case ==
A client had been tracking inventory in a custom table where the product ID was the primary key. When he opened a new location, we added a location column, and wanted to be able to track how many of each product was in each location.
1. A table's purpose is being expanded, or otherwise doesn't meet the needs of the data.
Since the primary key is unique, we needed to add a new key column and change which column was designated as the primary key.
2. A table was originally defined without an AUTO_INCREMENT column and the need for such a column arises.
The new column we wanted to add and use for the key was simply an AUTO_INCREMENT integer column. In testing we defined the new column and also defined a new UNIQUE index (so, not changing the primary key yet).
Since dbDelta adds new columns before adding the new indices, and in separate ALTER TABLE statements, MySQL refuses to add a new AUTO_INCREMENT column without an index.
The solution is to add the new column without the AUTO_INCREMENT designation, then add the UNIQUE index, then alter the table to use AUTO_INCREMENT.
3. A primary (or other key) could be significantly and intentionally altered, significantly changing how queries are run.
I understand that WP doesn't want to drop and recreate indices when changing the sub-part of an index (see: https://core.trac.wordpress.org/ticket/34870#comment:21)
However I think that it should change the index, if the definition is significantly altered.
In the use case above, we could've changed the primary key to be `PRIMARY KEY(productId,location)` instead of adding a new column and switching the index to that column.
In other use cases, changing from a BTREE to FULLTEXT index would change which types of queries need to a full table scan.
== This Patch ==
This patch does the following:
1. You can now add a new AUTO_INCREMENT column to an existing table
When a new AUTO_INCREMENT column is added to an existing table, the column creation is done in two parts. First the column is created as a non-AUTO_INCREMENT column, and a separate `ALTER TABLE` statement is set to run after index creation to enable AUTO_INCREMENT.
Note: The CREATE TABLE statement given to dbDelta must provide the required indexes that MySQL expects.
2. You can now modify a column with AUTO_INCREMENT to no longer use AUTO_INCREMENT
3. You can change which column is the primary key
4. Significant index definitions cause an index to be dropped and re-created
The cases that cause an index to be dropped and re-created are:
* An index which wasn't UNIQUE, but now is or vice-versa
* An index which changes index type (eg. FULLTEXT => BTREE)
* An index which contains a different number of columns
* An index which contains a different column order
* An index which contains different columns
Note: Changing the index sub-part or no longer defining the index in the table does not cause it to be dropped.
== Other notes ==
1. I've tried to use WP coding standards and comment my code well. I'd love feedback if there are things I can do better.
2. I've included a file, test.php which takes 13 table definitions, takes them two at a time, and converts between each possible combination.
To run it, put it in the root WordPress directory and run `php ./test.php`.
3. Also, the dbDelta phpunit tests still pass.",stuporglue
Future Releases,15332,dbDelta($query) - do not create view,,Database,3.0.1,normal,normal,Future Release,feature request,reopened,has-patch,2010-11-07T14:23:52Z,2018-07-30T08:45:42Z,"during plugin creation I create few tables with dbDelta($query). that is working without problems.
But on the end I create two views on this tables with dbDelta($query) - that is not working. The views are not created.
The sql is ok, manually the create works.",christian_gnoth
Future Releases,48207,Implement new Comment Date Functions,,Date/Time,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2019-10-04T03:33:42Z,2019-11-08T11:42:21Z,WordPress 5.3 introduces get_post_datetime() and get_post_timestamp(). Suggesting that these be mirrored with the equivalent functions get_comment_datetime and get_comment_timestamp. ,dshanske
Future Releases,53236,Nonce lifespans are inaccurate and unintuitively affected by timezones,,Date/Time,2.5,normal,minor,Awaiting Review,defect (bug),new,has-patch,2021-05-20T09:51:46Z,2021-06-02T04:37:01Z,"The docs on [[https://developer.wordpress.org/reference/functions/wp_verify_nonce/|wp_verify_nonce()]] specify that nonces are either 0-12 or 12-24 hours old by default, but this isn't true. In reality, the value `1` means < 12 hours old, but `2` means anywhere from 1 second to < 24 hours old.
Observe what happens to the nonce tick value over a day:
||=local time=||=seconds since epoch=||=tick=||
||2021-05-20T00:00:00+03:00||1621458000||37534||
||2021-05-20T01:00:00+03:00||1621461600||37534||
||2021-05-20T02:00:00+03:00||1621465200||37534||
||2021-05-20T03:00:00+03:00||1621468800||37534||
||2021-05-20T04:00:00+03:00||1621472400||37535||
||2021-05-20T05:00:00+03:00||1621476000||37535||
||2021-05-20T06:00:00+03:00||1621479600||37535||
||2021-05-20T07:00:00+03:00||1621483200||37535||
||2021-05-20T08:00:00+03:00||1621486800||37535||
||2021-05-20T09:00:00+03:00||1621490400||37535||
||2021-05-20T10:00:00+03:00||1621494000||37535||
||2021-05-20T11:00:00+03:00||1621497600||37535||
||2021-05-20T12:00:00+03:00||1621501200||37535||
||2021-05-20T13:00:00+03:00||1621504800||37535||
||2021-05-20T14:00:00+03:00||1621508400||37535||
||2021-05-20T15:00:00+03:00||1621512000||37535||
||2021-05-20T16:00:00+03:00||1621515600||37536||
||2021-05-20T17:00:00+03:00||1621519200||37536||
||2021-05-20T18:00:00+03:00||1621522800||37536||
||2021-05-20T19:00:00+03:00||1621526400||37536||
||2021-05-20T20:00:00+03:00||1621530000||37536||
||2021-05-20T21:00:00+03:00||1621533600||37536||
||2021-05-20T22:00:00+03:00||1621537200||37536||
||2021-05-20T23:00:00+03:00||1621540800||37536||
…and over the boundary of a tick:
||=local time=||=seconds since epoch=||=tick=||
||2021-05-20T14:59:58+03:00||1621511998||7535||
||2021-05-20T14:59:59+03:00||1621511999||7535||
||2021-05-20T15:00:00+03:00||1621512000||7535||
||2021-05-20T15:00:01+03:00||1621512001||7536||
||2021-05-20T15:00:02+03:00||1621512002||7536||
In this example, you can see that a nonce generated at 3pm and verified one second later will return 2 because of the tick change. The ticks do not align with timezones due to their basis in universal time, so nonces will always appear “old” to your code at certain times of the day, as touched on in ticket:33635#comment:2.
I haven't thought of a way to reduce the huge variance in ages that have equal nonce values, but I did think of a way to make them more predictable. I've attached a patch that would align ticks to WP's timezone so there would be a predictable two ticks per calendar day, a.m. and p.m., starting at 00:00.",lev0
Future Releases,52220,Weekly archives/week 53 incorrect crossing over a year change,Rarst*,Date/Time,5.6,normal,normal,Awaiting Review,defect (bug),accepted,,2021-01-04T19:50:24Z,2021-01-05T20:28:24Z,"I run a site that publishes items every single day, and I regularly make use of its weekly archives.
The relevant dates here(via https://www.epochconverter.com/weeks/2020) are:
2020 week 52 is Dec 21 – Dec 27
2020 week 53 is Dec 28 – Jan 3
2021 week 1 is Jan 4 – Jan 10
Instead, my weekly archives come out as:
2020 week 52 is Dec 21 – Dec 27
2020 week 53 is Dec 28 – **Dec 31**
2021 week 1 is Jan 4 – [ongoing]
[I can provide live URLs for these, just wasn't sure if self-linking was frowned upon.]
There's three days in there that just…don't exist(in the archives; there ''are'' published entries).
It's kind of a pain to find much information on weekly archives in the first place since they're not all that common in actual use and the search terms are broad but I'm currently trying to find someplace else that publishes often enough I can try feeding it a query string to see what happens.
This replicates for previous year changes, ie. 2020 week 1 is Dec 30, 2019–Jan 5, 2020 but the archive just starts at Jan 1 instead.
Also replicates with all plugins disabled and using Twenty Twenty-One.",sugeneris
Future Releases,49413,wp_exif_date2ts should use Datetime and accept an optional offset,Rarst,Date/Time,,low,normal,Future Release,defect (bug),reviewing,has-patch,2020-02-12T07:57:33Z,2022-01-19T12:47:53Z,"I think this falls under the date/time component. This function should be updated to use DateTime and to accept an optional timezone offset.
Right now, this is called by wp_read_image_metadata with the result the timestamp is wrong. This is because timestamps in exif are stored without timezone offsets, usually in local time. Storing it as a timestamp was therefore a mistake in my opinion as it will always be off. We should be assuming that the time is local site time unless an optional offset/timezone string is passed in.
Separately, as newer cameras and most cell phones do store that offset, will be proposing changes for that in a separate ticket. ",dshanske
Future Releases,48935,Need to Remove strtotime() usage from core,,Date/Time,6.2,normal,normal,Awaiting Review,enhancement,new,,2019-12-11T12:58:07Z,2023-04-06T10:38:43Z,"`strtotime()` is routinely used in core for processing timezone-ambiguous input. Since it is affected by default PHP time zone setting (set by core to UTC on boot) it is also vulnerable to this setting being changed by third party code.
Related change of `date()` to `gmdate()` in 5.3 release caused some new issues, because in some places while changing default time zone broke things combination of `strtotime()` and `date()` meant things got broken ''by the same amount'' and outputs were ""correct"" (ignoring the fact they would be implied in absolutely different time zone from intended).
Dropping use of `strtotime()` in favor of date parsing with explicit time zone handling (such as `DateTimeImmutable` objects) is logical next step to make core insensitive to PHP time zone context.",Rarst
Future Releases,48936,Remove mysql2date() usage from core,,Date/Time,,normal,normal,Awaiting Review,enhancement,new,,2019-12-11T13:04:27Z,2023-02-24T15:20:34Z,"`mysql2date()` was originally meant from processing times as stored by WP in database.
Unfortunately its design is very limited because both time zone of input and output is ambiguous. It is interchangeably used for local and UTC times.
As implementation detail that meant that it would produce incorrect output for formats including time zones for local time inputs. Time zone would happen be UTC from WP core setting PHP time zone to UTC on load.
In 5.3 release this behavior was flipped to produce correct local time output for local time input, as considerably more common. Accordingly now ''UTC'' input produces incorrect output for formats with time zone.
While the function is common and familiar, it is hardly irreplaceable and its design is so limited it seems to be unsalvageable.
I propose we move towards eliminating its use in core and eventually formally deprecating it.",Rarst
Future Releases,29159,Classic editor: Visual editor is disabled when user agent is obscured by a proxy,,Editor,2.0,normal,normal,Future Release,defect (bug),new,has-patch,2014-08-08T23:54:26Z,2020-11-24T04:56:39Z,"user-agent checking is removing visual editor in function user_can_richedit. It took us many days to find a problem, which is described here: http://www.benjaminhorn.se/code/wordpress-visual-editor-not-visible-because-of-user-agent-sniffing/
It is not sensible to use user-agent as a check whether to show visual editor. Hopefully this check can be amended or removed in future WP versions.
There are various hosting environments where this check fails. Plus you would constantly need to manually add new strings over time.
We need to write plugins or theme hacks to circumvent this problem (that is after spending days of struggling to pinpoint the problem).",vmuryginIB
Future Releases,43071,User without the ability to publish are unable to edit post status,,Editor,,normal,normal,Awaiting Review,defect (bug),new,has-patch,2018-01-11T21:46:21Z,2021-12-10T05:34:24Z,"If a user is able to edit a post but unable to publish a post, they can change the post status from the `wp-admin/edit.php?post_type=post_type` page using the quick edit dropdown feature. However, if the user goes to the `wp-admin/post.php?post=ID&action=edit` page, they are unable to edit the post status.
User who are able to edit post_type should be able to do so from the post edit page.",NathanAtmoz
Future Releases,48256,WP remove first
in
,,Editor,5.2.3,normal,major,Future Release,defect (bug),new,,2019-10-08T12:41:01Z,2020-11-23T04:18:22Z,"When I create table and add text inside it remove first
but let
Example :
",Sebafaim
Future Releases,58801,Prefetch Block Editor from Posts page,adamsilverstein,Editor,,normal,normal,Future Release,enhancement,assigned,dev-feedback,2023-07-13T15:44:37Z,2023-12-04T22:00:53Z,"One of the most common user journeys in wp-admin for creating or editing a Post is navigating to the Posts page (`wp-admin/edit.php`) then to the Block Editor (either by clicking a post to edit or clicking the ""New Post"" button or sidebar menu).
We can greatly increase up the speed with which the editor loads by prefetching the edit screen once the user reaches the Posts page. Prefetch will ""prime the html cache"" for all of the resources needed by the editor, resulting in the editor loading much faster for users.
Note: since users can also reach the editor from the wp-admin bar, we might want to consider adding prefetch when the user interacts or opens the ""New"" menu. However, to keep this initial proposal small and easier to test I decided to limit the scope to the Posts page.",adamsilverstein
Future Releases,52990,Account for single quoted attributes when lazy loading images and iframes.,,Embeds,5.5,normal,normal,Awaiting Review,defect (bug),new,,2021-04-07T00:24:58Z,2021-06-11T00:22:11Z,"`wp_iframe_tag_add_loading_attr()` and `wp_img_tag_add_loading_attr()` includes a check to ensure the elements have a `src`, `width` and `height` attribute before adding the lazy loading attribute.
In both functions the check only considers attributes using double quotes so the lazy loading tag is not added for elements using single quoted attributes. [https://github.com/WordPress/wordpress-develop/blob/895d6a691d7ccdfe80cdf999bc0c8a78d11ad55a/src/wp-includes/media.php#L1893-L1895 img ref], [https://github.com/WordPress/wordpress-develop/blob/895d6a691d7ccdfe80cdf999bc0c8a78d11ad55a/src/wp-includes/media.php#L2012-L2015 iframe ref].
As WordPress does not normalize attribute tags to use double quotes, single quoted attribute tags ought to be considered.
Image version 5.5, iframe version 5.7.
Follow up to #50756, #52768.",peterwilsoncc
Future Releases,44399,Add unique capability for oembed,,Embeds,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2018-06-18T20:11:34Z,2019-01-17T00:27:46Z,"Ran into a very specific use case today wherein I have a custom user role with a custom WYSIWYG editor on their profile. The user role has unique capabilities for a couple custom post types with unique capabilities. The user needs to be able to paste a YouTube URL in their profile editor, but I found that it doesn't work.
After some digging, I found that the oEmbed ajax function `wp_ajax_parse_embed()` checks for `current_user_can('edit_posts')`. Also, the oEmbed REST API does the same thing in the `WP_oEmbed_Controller::wp_ajax_parse_embed()` method.
This is a problem for custom post types with custom capabilities. We don't want the user to have the `edit_posts` permission, but they do have the `edit_custom_posts` equivalent. While this isn't a problem for `current_user_can('edit_post', $post_id)` calls, as it uses the post to grab the post object and thereby post object capabilities, the `edit_posts` primitive check has no context.
Since we can't rely on being able to gather post object context (as, in my case, there may be no post object as we're on the user profile), I propose creating a single (or group) of oEmbed capabilities. Something like `create_oembeds`.
Wanted to gather some feedback and thoughts from the community before putting together a patch. Let me know what you think! :)",jason_the_adams
Future Releases,37336,Pre-existing page with slug /embed/ does not work as described,,Embeds,4.5,normal,normal,Awaiting Review,defect (bug),new,close,2016-07-12T02:22:56Z,2020-09-28T09:56:19Z,"In #34971, embeds were added to static frontpages, and there was a discussion of how this would affect an existing page with a slug of /embed/.
The solution was:
- an existing page with slug /embed/ will work as is and disable the pretty embed URL
- new pages can't be created with a slug of /embed/.
However, this did not work properly. On a site of mine, there is a page with URL /embed/ that was working fine prior to this upgrade. Now:
- if you visit /embed/, you are redirected to the homepage.
- if you attempt to edit the page, the slug previews as /embed-2/, meaning editing the page content and saving has the unwanted side effect of forcing the URL to change and all links to the page to break without warning.
Suggested changes:
- fix whatever is incorrectly redirecting the URL
- allow a slug of /embed/ to continue to save as-is if it already exists.",smerriman
Future Releases,42733,WordPress Embed URLs don't work for draft and scheduled posts with pretty permalinks,,Embeds,,normal,normal,Future Release,defect (bug),assigned,,2017-11-28T16:46:36Z,2023-05-29T10:41:09Z,"This came up during work on #41451. Two tests fail with ''is_embed is false but is expected to be true'':
- `Tests_Embed_Template::test_oembed_output_draft_post`
- `Tests_Embed_Template::test_oembed_output_scheduled_post`
Without pretty permalinks, the return of `get_post_embed_url()` is `http://example.org/?p=8&embed=true`. This URL is recognised as an embed URL when the request is parsed.
But with pretty permalinks enabled, the return is `http://example.org/?p=8/embed/`. This is not recognised as an embed URL.
The reason for the mixed URL structure seems to be `get_permalink()`. This function does not return pretty permalinks for draft or future posts, see https://core.trac.wordpress.org/browser/tags/4.9/src/wp-includes/link-template.php#L165",Frank Klein
Future Releases,41746,oEmbed does not respect canonical provider url parameter,,Embeds,2.9,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2017-08-28T20:30:45Z,2017-09-20T20:39:38Z,"I came across a Twitter URL format that would not embed correctly. Providing that URL to their provider endpoint returned an error. But the original page had a `` element which already had a working, canonical `url` parameter in its querystring.
An example URL is:
{{{https://twitter.com/i/web/status/898599373956722688}}}
If you try to fetch oEmbed data for that URL by just adding it as a `url` querystring parameter on the standard Twitter oEmbed provider URL, it will return an error.
But view source on that page, and you'll see:
{{{}}}
Note that the path of this URL is `.../{username}/status/{id}`, whereas the original URL was `.../i/web/status/{id}`.
I've worked out a small patch and method for getting WordPress to use oEmbed discovery to extract and use the canonical URL.
When using `wp_oembed_add_provider()`, if you leave the provider URL falsey, then `WP_oEmbed::get_provider()` will use discovery to find it (assuming that you haven't forced `discovery = false` in `$args`). Then my patch will pull the `url` arg from there and use that, instead of the original URL that was passed in to the embed handling.
Later, when the JSON response is being handled, the code will still be able to see whether this is a whitelisted URL pattern, and bypass/perform security filtering such as `kses()` (see `wp_filter_oembed_result()`).
",dougal
Future Releases,51471,pre_oembed_result filter missing from oembed proxy controller,,Embeds,,normal,normal,Future Release,defect (bug),assigned,has-patch,2020-10-07T18:14:51Z,2021-02-17T02:57:22Z,"[https://github.com/WordPress/WordPress/blob/5cee7eced0b691089a875d7e918d4380bac408af/wp-includes/class-wp-oembed.php#L363-L415 WP_oEmbed::get_html()] [https://github.com/WordPress/WordPress/blob/5cee7eced0b691089a875d7e918d4380bac408af/wp-includes/class-wp-oembed.php#L393 applies] the `pre_oembed_result` filter, allowing it to short-circuit the actual request to the oEmbed provider's REST API.
That same filter is however missing from [https://github.com/WordPress/WordPress/blob/5cee7eced0b691089a875d7e918d4380bac408af/wp-includes/class-wp-oembed-controller.php#L154-L220 WP_oEmbed_Controller::get_proxy_item()]. (Note that both `WP_oEmbed::get_html()` and `WP_oEmbed_Controller::get_proxy_item()` are otherwise quite similar, sharing the `get_data()` and `data2html()` calls, and `oembed_result` filter.)
It's arguable that the oembed REST API endpoint should allow for the same kind of filtering as the `oEmbed` class.
This issue seems somewhat similar to #45142, which was about the `oembed_result` filter.
cc @swisspidy @danielbachhuber",Bernhard Reiter
Future Releases,23431,[embed] shortcode doesn't work with do_shortcode(),,Embeds,3.5,normal,normal,Future Release,feature request,new,has-patch,2013-02-09T15:05:02Z,2022-07-15T15:43:20Z,"It would be preferable to use the [embed] shortcode through do_shortcode rather than apply_filters( 'the_content',... in order to avoid sharing plugins, related posts plugins etc appending content to something that could simple be post meta, i.e. looking to convert a youtube url to a video.",jtsternberg
Future Releases,36339,Possible issue with export_wp() and undefined custom post types,,Export,,normal,normal,Future Release,defect (bug),new,,2016-03-25T22:03:59Z,2020-07-06T14:20:09Z,"While writing the improved docblock for `export_wp()`, I noticed something that may be an issue if an invalid custom post type is supplied. Here is the code:
{{{#!php
can_export )
$args['content'] = 'post';
$where = $wpdb->prepare( ""{$wpdb->posts}.post_type = %s"", $args['content'] );
} else {
$post_types = get_post_types( array( 'can_export' => true ) );
$esses = array_fill( 0, count($post_types), '%s' );
$where = $wpdb->prepare( ""{$wpdb->posts}.post_type IN ("" . implode( ',', $esses ) . ')', $post_types );
}
}}}
The two things that occurred me are
1. If a valid custom post type is supplied but its `can_export` property is `false`, `posts` will be used instead. This is unexpected behaviour. I think it should stop and not export anything.
1. if an invalid custom post type is supplied, every post type that has `can_export` set to `true` is used. This is also unexpected behaviour. I think it should stop and not export anything.
Am I reading this wrong? Is there a reason why it works this way?",theMikeD
Future Releases,51142,Invalid Moment.js locale from get_user_locale(),,External Libraries,5.0,normal,normal,Future Release,defect (bug),new,has-patch,2020-08-25T22:28:16Z,2023-06-30T08:37:12Z,"`get_user_locale()` returns a locale in the format `en_US`, which is passed directly to Moment.js, e.g. `moment.updateLocale( 'en_US', {...} )`.
Since Moment.js doesn't actually support two-part locales, this causes some issues. For example, `moment().format( 'Do' )` returns `25` where it should return `25th`. This is because the local *ordinal* is lost as a result of setting an undefined locale.
The locale should either be passed in a format that Moment.js understands, such as `en`, or `moment.defineLocale( 'en_US', { parentLocale: 'en' } )` should be called before `moment.updateLocale( 'en_US', {...} )`. AFAIK these are equivalent.
You can see the issue reproduced here: https://codepen.io/slightlyfaulty/pen/WNwpMmG
Of course, swapping out old dusty Moment.js for its super modern and popular drop-in replacement [https://day.js.org/ Day.js] is also an option ",slightlyfaulty
Future Releases,55604,Update SimplePie to version 1.7.0,,External Libraries,6.0,normal,normal,Future Release,task (blessed),new,dev-feedback,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,19998,Feeds can contain characters that are not valid XML,,Feeds,3.3.1,normal,normal,Awaiting Review,defect (bug),new,has-patch,2012-02-09T16:28:47Z,2020-06-19T00:25:59Z,"It is possible for any of the feeds to contain control characters which are not valid in XML e.g. http://www.fileformat.info/info/unicode/char/1c/index.htm
When outputting user supplied content in an XML context we should strip these control characters - they are unprintable and just break feed parsers.
http://en.wikipedia.org/wiki/Valid_characters_in_XML has a good list of what is and isn't valid.
I guess we need a {{{strip_for_xml()}}} function or something.",westi
Future Releases,46227,Add Rel-Feed Link to Header,,Feeds,,low,trivial,Future Release,enhancement,reviewing,has-patch,2019-02-10T17:35:29Z,2021-05-13T20:03:29Z,"When the front page is not the posts page, proposing that Core add a link in the header to the actual posts page, using the rel=feed designator.
https://blog.whatwg.org/feed-autodiscovery
Example
This would allow a system to figure out where the posts page is.",dshanske
Future Releases,48689,PHP warnings after updating to WP 5.3: ftp_nlist() and ftp_pwd() expect missing parameters,costdev,Filesystem API,5.3,normal,minor,6.6,defect (bug),assigned,dev-feedback,2019-11-17T23:24:37Z,2024-02-06T05:48:16Z,"I updated several websites to WP 5.3 without any problems. But on one wesite I got these PHP warnings both in the backend and in the website:
{{{
Warning: ftp_nlist() expects parameter 1 to be resource, null given in /wp-admin/includes/class-wp-filesystem-ftpext.php on line 402
Warning: ftp_pwd() expects parameter 1 to be resource, null given in /wp-admin/includes/class-wp-filesystem-ftpext.php on line 226
Warning: ftp_pwd() expects parameter 1 to be resource, null given in /wp-admin/includes/class-wp-filesystem-ftpext.php on line 226
Warning: ftp_pwd() expects parameter 1 to be resource, null given in /wp-admin/includes/class-wp-filesystem-ftpext.php on line 226
Warning: ftp_nlist() expects parameter 1 to be resource, null given in /wp-admin/includes/class-wp-filesystem-ftpext.php on line 402
Warning: ftp_pwd() expects parameter 1 to be resource, null given in /wp-admin/includes/class-wp-filesystem-ftpext.php on line 226
Warning: ftp_pwd() expects parameter 1 to be resource, null given in /wp-admin/includes/class-wp-filesystem-ftpext.php on line 226
Warning: ftp_pwd() expects parameter 1 to be resource, null given in /wp-admin/includes/class-wp-filesystem-ftpext.php on line 681
Warning: ftp_pwd() expects parameter 1 to be resource, null given in /wp-admin/includes/class-wp-filesystem-ftpext.php on line 226
Warning: ftp_pwd() expects parameter 1 to be resource, null given in /wp-admin/includes/class-wp-filesystem-ftpext.php on line 226
Warning: Cannot modify header information - headers already sent by (output started at /wp-admin/includes/class-wp-filesystem-ftpext.php:402) in /wp-includes/functions.php on line 5946
Warning: Cannot modify header information - headers already sent by (output started at /wp-admin/includes/class-wp-filesystem-ftpext.php:402) in /wp-admin/includes/misc.php on line 1252
Warning: Cannot modify header information - headers already sent by (output started at /wp-admin/includes/class-wp-filesystem-ftpext.php:402) in /wp-admin/admin-header.php on line 9
}}}
I suppressed the ouput by ""muting"" the function calls with '@' in the file 'class-wp-filesystem-ftpext.php', i.e. changed {{{ftp_nlist()}}} to {{{@ftp_nlist()}}} etc..
I will be glad if any reason can be found and fixed until the next WP upgrade.
",Hinjiriyo
Future Releases,48289,wp_normalize_path() breaks path_is_absolute() in Windows.,SergeyBiryukov,Filesystem API,5.2.3,normal,normal,Future Release,defect (bug),reviewing,has-patch,2019-10-11T08:49:20Z,2021-04-08T07:28:58Z,"Apologies in advance if this is considered correct behaviour, but it's strange that this is the case.
On **Windows**, when you take an absolute file system path and use `wp_normalize_path()` and then pass this result to `path_is_absolute()`, you get `false` instead of `true`.
Super simple demo:
{{{#!php
[code-highlight line-numbers=""table"" linenostart=""53"" highlight-lines=""1,3,8"" style=""native"" lang=""html+php"" pyg-id=""1"" ]
checkstyle
[code-highlight style=""native"" lang=""perl"" pyg-id=""2"" ]
(?:s+)(?:(/*([^*]|[rn]|(*+([^*/]|[rn])))**+/)|(//(?!.*(CHECKSTYLE)).*))
[/code-highlight]
}}}
Here dump after this line
{{{
$textarr = wp_html_split( $content );
var_dump($textarr);
exit;
}}}
{{{
array(25) {
[0]=>
string(0) """"
[1]=>
string(3) ""
""
[2]=>
string(28) ""Some amount of useless text ""
[3]=>
string(11) """"
[4]=>
string(0) """"
[5]=>
string(4) ""
""
[22]=>
string(15) ""Some Text Again""
[23]=>
string(4) ""
""
[24]=>
string(1) ""
""
}
}}}
As you can see one shortcode was not splitted, and here the problem. If php closing tag is present (?>)
than everything works fine.
Problematic regex provider
{{{#!php
is found.
. '-(?!->)' // Dash not followed by end of comment.
. '[^\-]*+' // Consume non-dashes.
. ')*+' // Loop possessively.
. '(?:-->)?'; // End of comment. If not found, match all input.
$cdata =
'!\[CDATA\[' // Start of comment, after the <.
. '[^\]]*+' // Consume non-].
. '(?:' // Unroll the loop: Consume everything until ]]> is found.
. '](?!]>)' // One ] not followed by end of comment.
. '[^\]]*+' // Consume non-].
. ')*+' // Loop possessively.
. '(?:]]>)?'; // End of comment. If not found, match all input.
$escaped =
'(?=' // Is the element escaped?
. '!--'
. '|'
. '!\[CDATA\['
. ')'
. '(?(?=!-)' // If yes, which type?
. $comments
. '|'
. $cdata
. ')';
$regex =
'/(' // Capture the entire match.
. '<' // Find start of element.
. '(?' // Conditional expression follows.
. $escaped // Find end of escaped element.
. '|' // ... else ...
. '[^>]*>?' // Find end of normal element.
. ')'
. ')/';
}
return $regex;
}
}}}
Without any doubts this case should be included in regex. ",crosp
Future Releases,26842,"Contenteditable, multiple spaces,  , and U+00A0",,Formatting,4.7,normal,normal,Future Release,defect (bug),new,,2014-01-15T17:03:31Z,2020-09-04T18:52:17Z,"In contenteditable mode when the user types multiple spaces (ASCII char 32, U+0020) they are preserved. The browsers insert ` ` as every other character, the string is ` ` etc.
In WordPress TinyMCE is set to
{{{
'entities' => '38,amp,60,lt,62,gt',
'entity_encoding' => 'raw',
}}}
Anything other than the three basic ""htmlspecialchars"" `&`, `<` and `>` is outputted as UTF-8 when serializing the DOM. This outputs the (multiple) ` ` as U+00A0 which in PHP shows as `0xC2 0xA0`([http://en.wikipedia.org/wiki/Non-breaking_space reference]).
A problem with `0xC2 0xA0` is that in PHP the regex `\s` matches `0xA0` in certain cases, fails to match the ""white space"", breaks the UTF char, and sometimes leaves an `Â` behind. One example is wptexturize(), see #22692.
Another problem is that the user is not aware there are multiple ` ` when looking in the Text editor or the html source, as U+00A0 are ""invisible"".",azaozz
Future Releases,2691,HTML comments in posts aren't handled properly.,adamsilverstein*,Formatting,2.8.5,normal,normal,Future Release,defect (bug),accepted,close,2006-04-25T03:16:37Z,2024-01-10T10:11:05Z,"When an HTML comment is added in a post, autop adds paragraph (
) tags around the comment and for multi-line comments line breaks ( ) are added after every line. This should not happen in HTML comments.
This ticket is similar to #712 which was closed with wontfix. I would like to know why this isn't seen as an issue? It prevents the addition of RDF and other metadata, not to mention just plain old HTML comments in posts.",gord
Future Releases,17491,Make is_email() compliant with RFC5322 (updated by RFC6854),,Formatting,3.1.2,normal,minor,Future Release,defect (bug),reopened,dev-feedback,2011-05-18T14:48:52Z,2023-04-14T13:59:42Z,is_email('toto.@toto.com') returns true,arena
Future Releases,50863,[playlist] + text =
error,,Formatting,5.4.2,normal,normal,Awaiting Review,defect (bug),new,,2020-08-06T02:49:55Z,2020-08-06T13:41:14Z,"There is a bug that is very simple to reproduce -
if you create a [playlist] and then add some text, such as
[playlist ids=""1,2,3""] Hey everyone, check out my new songs!
it will produce an html parsing error where element is closed, but never opened.
Thank you",hvar
Future Releases,51019,convert_smilies() fails on large tags,,Formatting,5.5,normal,normal,6.6,defect (bug),new,changes-requested,2020-08-15T12:51:26Z,2024-02-29T12:08:49Z,"I have an image with huge data-url src (1.6M) in the post content.
The post content is not displayed, but (with `WP_DEBUG` on) there is a php error instead.
PHP Error output:
{{{
Warning: count(): Parameter must be an array or an object that implements Countable in /Users/joern/www/vhosts/wordpress.local/httpdocs/stable/wp-includes/formatting.php on line 3357
}}}
Som digging revealed, that `preg_split()` in `function convert_smilies()` fails with a `PREG_RECURSION_LIMIT_ERROR`.
IMHO there should a check for `preg_last_error()` whether `preg_split()` was successfull, and if not the function should just return its input.
Any thoughts on this?
I'd be happy to craft a patch.",podpirate
Future Releases,50514,make_clickable nested links bug,,Formatting,5.5,normal,normal,Awaiting Review,defect (bug),new,has-patch,2020-06-30T09:29:29Z,2020-10-12T17:15:58Z,"If you look at the source of [`make_clickable`](https://core.trac.wordpress.org/browser/tags/5.4/src/wp-includes/formatting.php#L2985) there's one last regex call to replace potentially nested links:
{{{#!php
// Cleanup of accidental links within links.
return preg_replace( '#(]+?>|>))]+?>([^>]+?)#i', '$1$3', $r );
}}}
From the looks of the expression, this is meant to remove accidental nested links only if the parent link wrapping them does not have any non-link text at the edges. Let me provide a few examples:
1. This works as intended:
{{{#!php
https://w.org';
$click = make_clickable($text);
# https://w.org
}}}
2. Let's introduce more content inside the link, either prepend or append it to the hyperlink's inner URL:
{{{#!php
https://w.org';
$click = make_clickable($text); # https://w.org
# https://w.org
$text = 'https://w.org ';
$click = make_clickable($text); # https://w.org
# https://w.org
}}}
There, I used a simple whitespace for the sake of an example.
**Suggested Patch**
I am suggesting a simple fix with the cleanup regex expression, although however if you managed to understand the root problem you'd be able to come up with something much better.
{{{#!php
]+?>|>))(.+)?]+?>([^>]+?)(.+)?#is', '$1$3$4$5', $r );
}}}
In my patch you'll see the following changes:
1. Added `(.+)?` for capturing any leading characters before any nested links
2. Added `(.+)?` for capturing any trailing characters before any nested links
3. Added `s` modifier so as to have the previous capturers work with newlines
4. `'$1$3$4$5'` restoring the captured leading or trailing characters back into the cleaned up HTML.
Also worth noting I am running WordPress 5.4.2, PHP 7.4.4, nginx/1.17.10 on an Alpine Linux docker container (Linux 4.19.76-linuxkit x86_64).",elhardoum
Future Releases,45702,make_clickable() doesn't handle linked text being a URL with spaces within it,,Formatting,,low,trivial,Future Release,defect (bug),new,,2018-12-19T07:22:42Z,2019-04-03T16:39:31Z,"As reported in https://meta.trac.wordpress.org/ticket/3998
> {{{
> https://codex.wordpress.org/Roles and Capabilities
> }}}
> turns into:
> {{{
> https://codex.wordpress.org/Roles and Capabilities
> }}}
> Looks like either `make_clickable()` or `bbp_make_clickable()` is trying to make the URL clickable without taking the existing `` tag into account.
As I've commented on the ticket:
----
This is a problem in `bbp_make_clickable()`, but is also present in `make_clickable()`.
Given the input string of `https://codex.wordpress.org/Roles and Capabilities` both will return the invalid output.
Both contain the following to correct it:
{{{
return preg_replace( '#(]+?>|>))]+?>([^>]+?)#i', ""$1$3"", $r );
}}}
But as the resulting HTML is the following it's not matched (due to the `` - which assumes that neither the linked text never has spaces or isn't a URL)
{{{
https://codex.wordpress.org/Roles and Capabilities
}}}
Adjusting the regular expression to the following does work however for this specific case:
{{{
return preg_replace( '#(]+?>|>))]+?>([^>]+?)([^<]*)#i', ""$1$3$4"", $r );
}}}
As a work around, you can remove the spaces from the linked text, which avoids it:
`https://codex.wordpress.org/Roles and Capabilities`.
----
Also created https://bbpress.trac.wordpress.org/ticket/3237",dd32
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,dev-feedback,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:
{{{
}}}
Since this workaround exists, the bug is not very prioritary, but it should also (hopefully) be easy to fix.",Narc0tiq
Future Releases,43010,Attribute Name Escape,,Formatting,,normal,normal,Awaiting Review,enhancement,new,,2018-01-02T17:03:09Z,2022-01-18T14:34:00Z,"The HTML5 spec allows us to arbitrarily named attributes for tags, e.g. '''''data-my-arb-attr-name'''=""attr value""''. This allows for generated attribute names and thus, a need to escape to avoid potential security implications.
I have seen several occasions of developers using `esc_attr` to resolve this case, however this is far from correct - the requirements of the name of an attribute are very different to that of the value, the best example of this simply being whitespace.
The requirements of an attribute name can be found here: https://html.spec.whatwg.org/multipage/syntax.html#attributes-2
There is a need for an `esc_attr_name` function to avoid compromises in html.
I have provided a simple addition patch to wp-includes/formatting.php which should resolve this issue.",joe_bopper
Future Releases,47557,Sanitize Email Suggestion,,Formatting,5.2.1,normal,minor,Awaiting Review,enhancement,new,,2019-06-18T15:19:58Z,2023-03-23T16:11:52Z,"I am using WooCommerce and I've noticed several customer emails come through like...
{{{
example@example.com1234
example@example.com1234567812345678
}}}
It's mostly due to the email input being the last one before the credit card step, but these emails are passing the validation and sanitization that exists: is_email and sanitize_email.
I am doing something like the following to fix...
{{{#!php
'.$text.'' );
return $matches[1] . $html;
}
}}}
Thank you.",tlexcellent
Future Releases,29717,"wp_check_invalid_utf8 - pcre tricks and failsafes, +mb_convert_encoding, iconv fix, performance",,Formatting,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,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,57579,Replace most strip_tags() with wp_strip_tags(),,General,,normal,normal,Future Release,defect (bug),new,changes-requested,2023-01-29T16:55:41Z,2024-02-05T12:35:55Z,"Originally reported as an issue with `strip_tags()` in `wp-admin/admin-header.php`, this ticket's scope as grown to initiative to replace `strip_tags()` with `wp_strip_tags()`.
Proposal:
* Replace most calls to `strip_tags()` with calls to `wp_strip_all_tags()`
@peterwilsoncc [#comment:1 notes]:
>this is a slight compatibility change as it will strip the contents of `