__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,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,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,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
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,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,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,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,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,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,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,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,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-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,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:
{{{