__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,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,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,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,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,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,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
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,34353,redirect_canonical() – Undefined indexes 'host' and 'scheme',,Canonical,4.3.1,normal,normal,Future Release,defect (bug),reopened,has-patch,2015-10-19T08:47:03Z,2023-08-19T00:05:18Z,"Hello,
We have a problem on our Blog (http://blog.mila.com). Since over half a year, we get these notifications on top of our wordpress blog:
'''Notice: Undefined index: HTTP_HOST in /opt/wordpress/wp-includes/canonical.php on line 66'''
'''Notice: Undefined index: HTTP_HOST in /opt/wordpress/wp-includes/nav-menu-template.php on line 558'''
The notifications come and go, so i don't know what the problem is..
This is line 66 in the canonical file:
{{{#!php
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,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,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,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,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,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,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,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,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,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,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,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
'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-03-20T15:39:49Z,"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,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,38656,wpautop incorrectly handling paragraphs within block elements,,Formatting,5.0,normal,normal,Future Release,defect (bug),new,has-patch,2016-11-04T06:10:39Z,2019-03-26T15:02:11Z,"When there are two line breaks within a block element, `wpautop()` will replace it with `
`, but the corresponding opening and closing tags won't exist.
For example, `
a\n\nb
` will produce `
a
b
`, when it really should produce `
\n
a
\n
b
\n
`.",pento
Future Releases,5250,wpautop() issue with lists,,Formatting,2.3,normal,normal,Future Release,defect (bug),reopened,close,2007-10-24T00:32:38Z,2023-02-02T13:34:08Z,"First of all, my sincere apologies if this is a duplicate.
The problem, in short: WordPress inserted a number of unclosed `
` tags into my post. It should either insert correctly closed tags, or none at all. I honestly would prefer the former.
In detail: I had HTML code very similar to this:
{{{
text
subtext
more text
}}}
This was automatically converted to:
{{{
text
subtext
more text
}}}
Note the extra `
` tag in the above, which is unclosed (making the W3C validator choke on my website).
Also note, I was not using the WYSIWYG editor (turning it off was the first thing I did), so it's unlikely to be due to that.
As a workaround, manually inserting properly closed `
` tags works just fine:
{{{
text
subtext
more text
}}}
Since this workaround exists, the bug is not very prioritary, but it should also (hopefully) be easy to fix.",Narc0tiq
Future Releases,32787,make_clickable filter,johnjamesjacoby,Formatting,0.71,normal,normal,Future Release,enhancement,assigned,has-patch,2015-06-25T09:38:02Z,2022-08-02T13:01:09Z,"Hi,
it could be very usefull to add filters to regex callback functions in make_clickable :
_make_url_clickable
_make_web_ftp_clickable_cb
_make_email_clickable_cb
Example :
{{{
function _make_email_clickable_cb($matches) {
$email = $matches[2] . '@' . $matches[3];
$href = apply_filters( 'make_email_clickable_href', 'mailto:'.$email );
$text = apply_filters( 'make_email_clickable_text', $email );
$html = apply_filters( 'make_email_clickable_html', ''.$text.'' );
return $matches[1] . $html;
}
}}}
Thank you.",tlexcellent
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 `