text:
__group__ ticket summary owner component _version priority severity milestone type _status workflow _created modified _description _reporter
Future Releases 12706 Custom post status bugs Posts, Post Types 3.0 normal normal Future Release task (blessed) reopened has-patch 2010-03-25T14:41:39Z 2017-02-26T15:22:13Z "A developer should be able to register a custom post status using `register_post_status()`. The admin UI (including post submit box and quick edit) should reflect this new custom post status. Furthermore, there are many hard-coded references to 'draft' and 'pending' statuses in core that should properly use the post status API.
All existing arguments to `register_post_status()` should be fully implemented, should also support per-post-type arguments. As things get implemented across core, there will likely be a need for supporting capabilities and bits of API.
Related: #23169 (register_post_status_for_object_type), #23168 (unregister_post_status)." ptahdunbar
Future Releases 9824 make better use of stubs when verbose rules should apply Rewrite Rules normal normal Future Release task (blessed) reopened 2009-05-15T01:03:56Z 2015-12-03T15:01:04Z "Related to:
Problem fixed is:
> posts show up as www.apexprd.org/page/2 and not /news-and-events/page/2 as it should.
with permalinks set to /something/$postname%/
we arguably don't necessarily need verbose rules here, since there is a stub." Denis-de-Bernardy
Next Release 32417 Add new core media widget melchoyce Widgets 4.3 normal normal 4.8 feature request assigned has-patch 2015-05-16T03:14:25Z 2017-02-27T20:31:28Z Adding images to your widget areas is a common, yet currently incredibly tedious task -- you need to upload it in your media library, find the url, copy the url, and then manually add an image tag inside of a text widget. That's a lot to ask for a beginner user to do. We should include a default image widget in core to make this task easier. melchoyce
Future Releases 27888 Feature request: `get_current_admin_url()` and `get_current_admin_hook()` Administration 3.9 normal normal Awaiting Review feature request new has-patch 2014-04-18T12:22:45Z 2016-12-04T20:28:55Z "It would be sweet if to be able to get the current page's url using some kind of API. And its hook, for that matter. For instance:
public function get_current_admin_page_url()
if (!is_admin()) {
return false;
global $pagenow;
global $typenow;
global $taxnow;
global $plugin_page;
$url = $pagenow;
if (!empty($plugin_page)) {
$url .= '?page='.$plugin_page;
elseif (!empty($typenow)) {
$url .= '?post_type='.$typenow;
elseif (!empty($taxnow)) {
$url .= '?taxonomy='.$taxnow;
return $url;
And something similar for `get_current_admin_hook()`." Denis-de-Bernardy
Future Releases 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 2016-10-07T19:07:58Z "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 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 2015-12-03T20:06:48Z 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 34058 Proposal: wp_get_archives_object() function General 4.3.1 normal normal Future Release feature request new 2015-09-28T16:10:27Z 2016-01-08T15:59:59Z "I'm currently working on building a personal site using the WP REST API, and one of the features I want to introduce is an equivalent to the archives widget on the front-end.
Unfortunately, this isn't so straight forward given that I have no quick means of accessing an object representing the current archives. The existing function `wp_get_archives()` will return lots of lovely HTML - which I can use out of the box perfectly well - but this is useless given that I want full control of the data to manipulate/parse/sort as well as having something that is more suitable for output via JSON in the API.
I propose that a new function called `wp_get_archives_object()` be added to give developers immediate access to the archives object for general use without having to get their hands dirty.
As a compromise, perhaps add an additional parameter to `wp_get_archives()` that when set to `true` simply returns the object?" davetgreen
Future Releases 38750 Split wp_signups into wp_user_signups and wp_blog_signups Login and Registration 3.0 normal normal Awaiting Review feature request new dev-feedback 2016-11-10T19:07:00Z 2016-12-27T18:24:25Z "Right now, `wp_signups` (and the entire related API) does double-duty. It's 1 database table that's used for both users & blogs, but there are a few issues with this approach:
* Open sign-ups may or may not include ability to create sites
* There is no UI for managing sign-ups in WordPress core
* Sign-ups are different between singlesite & multi-site
* Plugins like BuddyPress do their best to include and/or work-around WordPress's core functionality, but end up writing a ton of additional code to manage this
* Other membership plugins are forced to roll their own approach every single time
* It's possible for multisite sign-up race conditions to exist, with users & sites created or activated from underneath each other (documented in `wpmu_activate_signup()`)
I'm adding the multisite focus to this issue, because all of the current code is only relevant to multisite, but I'd like to see single-site inherit whatever future approach we can come up with.
The core sign-ups code, stinks. Yet open registration is part of what makes WordPress & community/membership sites great. I think it would be great to take what we've learned from BuddyPress, WordPress.org, WordPress.com, and the bevy of Membership plugins, and make a great sign-up component/API for WordPress core." johnjamesjacoby
Future Releases 35435 Support Webmentions Pings/Trackbacks normal normal Future Release feature request new 2016-01-13T05:25:25Z 2016-10-29T17:43:22Z "Webmention have been released as a public working draft as of today. https://www.w3.org/TR/2016/WD-webmention-20160112/ . Previous linkback protocols(trackback and pingback) did not achieve this status.
The Webmention is a simplified evolution of the Pingback. It drops XML-RPC in favor of simple form encoding. The recommendation calls for asynchronous processing to prevent DoS attacks.
There is already a webmention plugin for WordPress in the repository. https://wordpress.org/plugins/webmention/ and a feature plugin could be developed for merging into core.
Trackbacks and Pingbacks both have their unique problems. The idea of linkbacks in general remains a good one, spoiled by less robust implementations. To go to the logical extreme, suggesting that adoption of webmentions be concurrent with the disabling by default of the earlier and less secure protocols.
Finally, no feature should be adopted in WordPress unless it has users...the pingback implementation in WordPress displays pingbacks in a way that does not convey useful meaning.
Current implementations of Webmention parse the HTML to generate a comment or other richer forms of response that are more useful to a site than what is currently available." dshanske
Future Releases 38462 Unit test to detect identical hooks with differing parameters Plugins normal normal Awaiting Review feature request new 2016-10-23T16:10:59Z 2016-12-07T15:08:33Z "Two recent instances where a hook that is triggered in multiple places in core has ended up having differing parameters:
* #38057
* #38314
It would be ideal to have unit test coverage which scans core's PHP files for all instances of `do_action` and `apply_filters`, filters hooks that occur multiple times, and then verifies that every instance of the hook accepts the same number of parameters." johnbillion
Future Releases 18848 Filter post listing screen by post parent johnbillion Posts, Post Types 3.3 normal normal Awaiting Review feature request assigned 2011-10-03T16:19:10Z 2015-10-03T23:17:46Z "It's not possible to filter a post listing screen by post_parent. This would be super handy for hierarchical post types (eg. Pages) where you may have several levels of hierarchy and want to view only the descendants of a particular page. I'm not sure that we need a UI (eg. dropdown menu) for it, but a working URL query var would be great.
I made an attempt at patching this a while ago using the child_of parameter but it got complicated quite quickly, so I'm putting it out there as a feature request in case anyone feels like tackling it." johnbillion
Future Releases 32358 Add unminified jQuery to core for better debugging with SCRIPT_DEBUG enabled Script Loader normal normal Future Release feature request assigned has-patch 2015-05-12T15:22:45Z 2016-07-11T10:50:47Z "I looked through old trac tickets to see if anyone proposed this in the past, but didn't find anything.
Most of the scripts included in core have both minified and unminified versions. By default the minified scripts are used. When SCRIPT_DEBUG is set to true, the unminified scripts will be used.
There is no unminified version of jQuery-core in WordPress core. That should be added.
I'd like to submit a patch for this myself" CrazyJaco
Future Releases 36797 Post which contain all HTML / HTML5 form elements. Themes 4.5.2 normal normal Awaiting Review feature request new 2016-05-10T07:41:33Z 2016-05-11T04:42:10Z "Anybody can update the - `theme-unit-test-data.xml`. Its generated `2 YEARs Old` - `(2014-09-02 17:16)`
URL: `https://wpcom-themes.svn.automattic.com/demo/theme-unit-test-data.xml`
I'm just testing the HTML / HTML5 form elements for different themes. But, There is no post in '''Theme Unit Test `(theme-unit-test-data.xml)`''' which contain all the '''HTML / HTML5 form elements'''.
I think It'll be helpful for theme reviews too.
== '''REFERENCE from Twenty Fifteen Theme'''??? ==
Below is the reference Screenshot of theme `Twenty Fifteen` default WordPress themes screenshot.
In this screenshot we will see the input styling does `NOT WORKING / APPLIED` for the below fields.
- Tel
- Number
- Date
- Month
- Week
- Time
- Datetime
- Datetime-Local
So, If the `(theme-unit-test-data.xml)` will add the post which contain all the `HTML / HTML5 fields`. Then, It'll be helpful to for '''Theme Reviewers'''." Mahesh901122
Future Releases 14781 Allow upload of PHP files as plugin Upgrade/Install normal normal Future Release feature request new has-patch 2010-09-04T13:28:06Z 2017-02-05T14:27:44Z Currently allowed are only ZIP packages. Plugins that consist of a single PHP file are not supported. It would be handy if uploading a single PHP file is an option. hakre
Next Release 37964 Allow customizer controls to be encapsulated by accepting pre-instantiated settings westonruter* Customize 3.4 normal normal 4.8 enhancement accepted has-patch 2016-09-07T06:31:49Z 2017-01-19T01:18:54Z "In #35926 the ability to add setting-less controls was made possible. The work here only went halfway, however. Consider wanting to re-use a control in a standalone context (see #29071), where the settings used in the control are just plain `wp.customize.Value` instances. Controls should allow pre-instantiated `Value` (`Setting`) objects to be passed in as `params.settings`. And when this is done, there would be no `api( settingId... )` deferrals.
So one should be able to create a new control like this:
var control = new wp.customize.Control( 'product_color', {
type: 'color',
params: {
settings: {
'default': new wp.customize.Value( '#000000' )
} );
Instead of having to do:
wp.customize.create( 'product_color', 'product_color', '#000000', {} );
control = new wp.customize.Control( 'product_color', {
type: 'color',
params: {
settings: {
'default': 'product_color'
} );
The goal is to allow controls to be encapsulated and to be able to use them in standalone contexts or embedded inside of other controls.
* #30738
* #37275
* #29071" westonruter
Next Release 21627 Filter for custom-background CSS selector peterwilsoncc Customize 3.4.1 low minor 4.8 enhancement assigned 2012-08-18T11:46:55Z 2017-01-31T20:40: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
Next Release 39778 Introduce helper function to validate UUID V4 Customize trunk normal normal 4.8 enhancement new 2017-02-03T17:17:45Z 2017-02-03T20:29:19Z WordPress 4.7.0 introduced a new helper function that would help with the creation of UUID V4 for customizer transactions but never exposed a way to quickly validate UUID V4 without manually copying over the regex found in class-wp-customize-manager.php. I propose we should introduce an helper function to validate UUID so plugins can quickly generate and validate UUID v4. jonathanbardo
Next Release 30738 JS content templates for base WP_Customize_Control westonruter* Customize 4.1 normal normal 4.8 enhancement accepted 2014-12-17T02:33:15Z 2017-02-18T01:14:42Z "This will make it possible to create all of the base Customizer control types directly in JS, and will allow them to share a single template passed from the server on Customizer init for all controls with the basic types (following up on #28709).
I think we may need to explore adjusting how register_content_type works since this control handles multiple types and all fallback types. But more likely we'll just do something a bit different, probably adding fallback handling on the other side and hard-coding these types into the Customizer Manager somewhere.
Follow-up to #29572. Related to several tickets I'm currently creating." celloexpressions
Next Release 39004 Alt attributes should be searchable in media library joedolson* Media 3.0 normal normal 4.8 enhancement accepted has-patch 2016-12-01T15:58:50Z 2017-01-20T18:32:42Z "The alt attribute is intended to be the alternative replacement value for an image. As such, if you're managing an image library correctly, it would be entirely reasonable that most images would have an alt attribute but no caption or description. However, this means that your only searchable field is the image title.
" joedolson
Next Release 36163 Make Walker_Nav_Menu::start_lvl more flexible by introducing filters for class name(s) at least Menus normal normal 4.8 enhancement new 2016-03-07T21:49:07Z 2017-02-03T15:19:15Z "It seems that most of the posibilities to ""tune"" menus output through filters in Walker_Nav_Menu::start_el, have limited use cases without the ability to alter Walker_Nav_Menu::start_lvl output?" ruslik
Next Release 37528 Add network ID parameter to wp_update_network_site_counts() jeremyfelt Networks and Sites 4.6 normal normal 4.8 enhancement assigned has-patch 2016-07-30T19:04:35Z 2016-12-04T15:47:41Z "Now that `wp_update_network_site_counts()` uses `get_sites()` internally, we can now consider passing a `network_id` parameter through.
Currently, we assume `$wpdb->siteid` which I think is a fine fallback, though we could also consider using `get_current_network_id()` if we felt like not exposing the `$wpdb` global." johnjamesjacoby
Next Release 39676 Remove restriction of minimum site title length of 4 characters flixos90 Networks and Sites normal normal 4.8 enhancement assigned has-patch 2017-01-24T13:39:07Z 2017-01-24T16:30:25Z "Currently `wpmu_validate_blog_signup()` does not allow specification of sites with titles shorter than 4 characters.
We discussed this restriction while dealing with #37616, and came to the conclusion that it should be removed, since sometimes there are cases where shorter names should be allowed. For setups that need the current requirement, it is easily possible to re-add it by using the `wpmu_validate_blog_signup` filter (see the [https://wordpress.slack.com/archives/core-multisite/p1480442803001226 full discussion on Slack]).
While this change is backward-incompatible for people that rely on that requirement, it's not too critical to remove. We will still need to mention it in a dev-note, including the workaround that re-enables the check.
Unit tests for `wpmu_validate_blog_signup()` should also be added as part of this change.
As part of the #37616 task, this ticket represents number 16 of that ticket's list." flixos90
Next Release 39494 Make it possible for taxonomy query to include children in REST API REST API 4.7 normal normal 4.8 enhancement new 2017-01-05T23:33:44Z 2017-01-06T01:42:10Z "Greetings!
Currently when a registered taxonomy is used it's assumed that include_children is false. That's a bummer as a useful bit of functionality is being cut out of the WordPress query.
'field' => 'term_id',
'terms' => $request[ $base ],
'include_children' => false,
What about making it possible for $request[$base] to either be a string and work as-is for backwards-compatibility, or an array with term_id and include_children indexes?
As a potential solution:
'field' => 'term_id',
'terms' => $terms,
'include_children' => $include_children,
" jason_the_adams
Next Release 39061 REST API pagination: Large INT passed to `paged` query arg doesn't fail properly joehoyle REST API 4.7 normal normal 4.8 enhancement reopened 2016-12-04T18:43:51Z 2017-02-27T20:25:46Z "When an absurdly large value is passed to the REST API (e.g. `/wp/v2/pages?page=23924321212413345333`), it returns the first page of results instead of an error. The problem is during validation and sanitization of the value, where the passed value is run through `absint`, which returns another absurdly large value, which then gets nullified by PHP, which becomes `1`.
wp> print_r( rest_sanitize_value_from_schema( 23452345346346345456567356, array( 'type' => 'integer' ), 'page' ) );
=> bool(true)
wp> print_r( rest_validate_value_from_schema( 23452345346346345456567356, array( 'type' => 'integer' ), 'page' ) );
=> bool(true)
wp> absint(23924321212413345333);
=> int(5477577138703794176)
Edge case, but worth noting since smaller values that are larger than the number of pages return an empty array (like if there are only 2 pages of posts, but 3 are requested).
Related: #19728." morganestes
Next Release 39854 REST API: Add gmt_offset to base /wp-json response jnylen0* REST API 4.7 normal normal 4.8 enhancement accepted has-patch 2017-02-12T15:57:27Z 2017-02-27T07:49:03Z "API clients often have a need to retrieve information about the current site. This doesn't fit into the `wp/v2/settings` endpoint for a couple of reasons:
- That endpoint requires administrative privileges (`current_user_can( 'manage_options' )`). See also #38731.
- We decided not to implement finer-grained permissions on the settings endpoint, as a read-only piece of information isn't a read/write ""setting"". See also ticket:38490#comment:10.
The most immediately obvious piece of information to add is `gmt_offset`. This is a crucial piece of information for any clients that need to manipulate datetimes returned via the API, but it's not currently available anywhere. See also ticket:38342#comment:48 for the specific case of Quick Draft inside wp-admin.
I expect we will need to enhance the base `/wp-json` response to accept a `?context=edit` or similar parameter - so let's use this ticket for both the approach to `/wp-json` and the addition of the `gmt_offset` field specifically." jnylen0
Future Releases 37526 Introduce the possibility to register new administration panels Administration normal normal Awaiting Review enhancement new dev-feedback 2016-07-30T10:34:59Z 2016-11-15T00:13:33Z "I'm currently trying to build a plugin that implements a completely custom administration panel. Unfortunately it's currently not possible to fully make it work with the Core implementation. Therefore my proposal is to introduce a function like `register_administration_panel( $name, $args )` that developers can use to build their own custom admin panel and have Core support it. They would need to take care of the functionality for that panel themselves - the registration would only ensure that the parts that are unified for all administration panels in Core will act in a compatible manner.
WordPress Core supports two additional administration panels on Multisite ('network' and 'user') which could leverage that function as well. The idea is that everywhere we currently check for `is_network_admin()` and `is_user_admin()`, we'd now use the administration panels registered to detect where we currently are. This would provide a flexible API and also clean up some code. The default admin would not be checked for there, instead it will be the fallback as it currently is in Core implementation as well.
Note that registering a custom administration panel should be considered an edge-case. The reason I personally would appreciate that functionality for is that I'm building a plugin that implements a global administration panel (for Multinetwork). Note that while the examples I mentioned are all Multisite-related, the function shouldn't be restricted to Multisite. The average plugin won't and shouldn't use it, but the function can be useful for custom projects which require an interface that other plugins should not interact with at all, for example a member area of a membership site with custom functionality.
Introducing this functionality would also make #37445 and #37446 unnecessary (two tickets I opened earlier).
I will add a patch as a proof-of-concept of what this could look like." flixos90
Future Releases 38238 Sorting a list table by some kind of count should default to DESC initially helen Administration normal normal Awaiting Review enhancement reviewing has-patch 2016-10-05T21:32:01Z 2016-10-31T00:21:11Z "List tables that can be sorted by some kind of count (posts with that term, comments on that post, etc.) should likely use `DESC` for that sort initially, as more frequent user workflows involve wanting to see things with many X (popularity/usage), as opposed to items with no X (cleanup). For example, you may want to see which categories are most popular (related: #36964) or which posts have generated a lot of comments.
Should also consider how sortable custom columns indicate whether to use `ASC` or `DESC` initially." helen
Future Releases 17851 Wrapping Sections with add_settings_section chriscct7 Administration 3.1.3 normal normal Future Release enhancement reviewing has-patch 2011-06-20T03:09:34Z 2016-12-04T19:49:39Z "This is my first time reporting, so excuse my ignorance. I just wanted to see about enhancing the add_settings_section function.
As of now, individual sections are not wrapper in any sort of container, which makes no sense to semantic sense to me. Sections should/need to be styled differently, but as of now, you really don't have much control of that.
I propose something similar to the register_sidebar function, looking like this:
add_settings_section( $id, $title, $callback, $page, $args )
$args would accept 3 parameters: before_section, after_section, and section_class.
This way you can style each individual section with relative ease. Just a thought and enhancement to the Settings API.
Thomas" griffinjt
Future Releases 26999 Improve the layout of phpunit unit tests to gauge code coverage Build/Test Tools normal normal Future Release enhancement new 2014-02-03T17:28:28Z 2016-12-13T14:44:25Z "Some groups of unit tests are laid out better than others. To improve code coverage, we should be able to map files or features to a defined set of files/folders. Sure, we have ""post"" and ""query"" and whatnot, but the overlap between the 2 makes it impossible to understand what ""should"" go in each file. Every time I write a unit test, I am placing the new tests in a best-guess (or, most of the time, arbitrary) location.
This is a spike ticket for cleanup and improvements. If this picks up steam from me or any others, might move to 3.9." wonderboymusic
Future Releases 35430 Should the 'counts' cache group be persistent? Cache API 4.4 normal normal Future Release enhancement new early 2016-01-13T02:58:54Z 2016-10-03T22:34:32Z I checked that the places storing data in the `'counts'` cache group have proper way to delete the data in cache on updates. For example, `wp_count_posts()` stores the post count, and `_transition_post_status()` deletes the count. So could we change the `'counts'` cache group to be persistent? This can reduce the repeated counting queries to the database. wjywbs
Future Releases 4328 Redirect Old Slugs feature needs to redirect slugs for pages, not just posts, and redirect old permalink structure markjaquith Canonical 2.2 normal normal Future Release enhancement new has-patch 2007-05-24T01:52:44Z 2016-05-14T16:44:50Z "Create a page, browse to it, edit it, change its slug, WP redirects to the old page's slug and serves a 404. Wasn't WP 2.1 or WP 2.2 supposed to make the redirect old slug feature built-in?
Along the same lines, it would be sweet if instead of simply redirect old slugs, WP would redirect old urls. When the date changes, when the page parent changes, or when the permalink structure changes, the url changes but neither of WP, the redirect old slug plugin, the permalink redirect plugin, or anything else catches this." Denis-de-Bernardy
Future Releases 15397 redirect_guess_404_permalink() doesn't guess posts with updated dates Canonical normal normal Future Release enhancement new 2010-11-12T00:17:38Z 2015-10-04T18:44:28Z "'''Problem'''
Here's my post path scheme: http://site.com/YEAR/MONTH/DAY/SLUG. Whenever I have writers working on a post for a while and saving drafts (we're all using Windows Live Writer), they oftentimes publish to the date when the last draft was saved, i.e. several days in the past. Then, they quickly correct the date but the previously tweeted/shared link is now 404 due to the changed date.
I've looked into the source of redirect_guess_404_permalink(), and it purposedly narrows down the query when it sees a post date to that date only. If I understand correctly, this is done to minimize accidental redirects to the wrong post, but has the side effect of not guessing the new link if only the date was changed.
A workaround of removing these lines:
if ( get_query_var('year') )
$where .= $wpdb->prepare("" AND YEAR(post_date) = %d"", get_query_var('year'));
if ( get_query_var('monthnum') )
$where .= $wpdb->prepare("" AND MONTH(post_date) = %d"", get_query_var('monthnum'));
if ( get_query_var('day') )
$where .= $wpdb->prepare("" AND DAYOFMONTH(post_date) = %d"", get_query_var('day'));
fixes the problem for me.
Can this case be solved in the trunk and the code above removed, or logic improved? My .htaccess file is filled with 301 redirects to correct wrong dates.
Thank you." archon810
Future Releases 32917 Tests_DB_Charset tests don't fully cover wpdb::strip_invalid_text_for_column() Charset 4.2 normal normal Awaiting Review enhancement new 2015-07-08T00:20:27Z 2015-07-08T01:02:31Z "Related / previously:
* #32351
* #32308
* #32127
* #21212
`Tests_DB_Charset` includes a data provider that feeds various charsets into its `wpdb::strip_invalid_text()` test, but not for its `wpdb::strip_invalid_text_for_column()` test, which means it's not being tested fully. It should be." johnbillion
Future Releases 20597 Allow WP_Comment_Query::query to filter by category Comments 3.4 normal normal Future Release enhancement new 2012-05-02T03:35:35Z 2015-12-03T15:02:00Z "The attached patch allows WP_Comment_Query::query to accept three additional arguments:
* `cat`
* `category__in`
* `category__not_in`
The resulting comments are then filtered by these category arguments as well as any other arguments.
These arguments work the same way as their `WP_Query` counterparts.
I would appreciate advice on the appropriateness of using `INNER JOIN` (as I have done here) to join in the taxonomy tables to the query." sambauers
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 2017-02-27T00:50:40Z "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 2016-12-04T22:14:50Z "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 37703 Optimise `wp_delete_comment` as called from `wp_delete_post` Comments normal normal Awaiting Review enhancement new 2016-08-18T01:32:53Z 2016-08-18T01:54:12Z "Remove the need for reparenting comments in `wp_delete_comment` by deleting comments in descending order.
Potentially accept an array of comments. " peterwilsoncc
Future Releases 36701 Pages parameter for get_comments Comments 4.5.1 normal normal Future Release enhancement new 2016-04-28T14:36:10Z 2016-04-28T14:41:55Z "Would it also be possible to add a $paged parameter to get_comments?
That way we can have more control over the pagination.
For example:
Reviews are usually just comments with an extra meta_key.
To display only the reviews, we can easily filter them inside get_comments.
There's one issue, the pagination (paginate_comments_links) grabs total comment count and ignoring the fact that get_comments only displays selected comments based on meta_key.
Hope it makes sense what I wrote, if not, just let me know.
" mireillesan
Future Releases 33735 Reduce Duplication and Improve Comment Notification Email Functions SergeyBiryukov Comments low normal Future Release enhancement reviewing has-patch 2015-09-04T22:55:04Z 2016-05-09T21:26:53Z "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 17020 Some comment queries are not filterable Comments 3.1 normal normal Future Release enhancement new 2011-04-02T16:56:32Z 2015-12-03T15:27:23Z "Although WP_Comment_Query::query() is fully filterable, some supplemental comment queries are still unfilterable. The submitted patch adds the following hooks:
* function get_approved_comments() - query filter 'get_approved_comments_query'
* function wp_dashboard_recent_comments() - query filter 'dashboard_recent_comments_query'" kevinB
Future Releases 31897 Update Customizer nonces via Heartbeat API voldemortensen Customize 3.4 low normal Future Release enhancement assigned 2015-04-05T23:24:07Z 2016-02-25T01:16:45Z "Currently the Customizer's nonces get updated when the preview gets refreshed ~~(only the `save` and `preview` nonces, not the `update-widget` nonce, however). If the user leaves the window open in the background for a long time, they will get stale nonces. We should be using the Heartbeat API and the `wp_ajax_customize_refresh_nonces` filter introduced in #31294 to keep the nonces up date.~~ (This is no longer true as of #35617.)
See also #31436 where Heartbeat integration will also be required to handle Customizer concurrency issues." westonruter
Future Releases 31624 $wpdb->prepare() named placeholders Database 4.2 normal normal Awaiting Review enhancement new 2015-03-13T08:36:52Z 2015-03-18T03:55:42Z "I think it would be handy to add named placeholders to $wpdb->prepare(). The functionality exists in most modern frameworks and cuts out the need for having to worry about the order of variables, (or repetition) in the current vsprint like syntax.
What I'm proposing is that the second parameter of prepare() can optionally be an associative array where the $key is the named placeholder and the $value is the value associated with it.
This wont affect any existing functionality of prepare() and is fully backwards compatible. If no associative array is passed it will continue to work as always.
Patch with the described functionality is attached for testing." ozthegreat
Future Releases 35109 Add Online DDL support to dbDelta Database normal normal Future Release enhancement new 2015-12-15T22:24:20Z 2016-02-21T22:53:02Z "Since MySQL 5.1, a bunch of table level operations can be done in an asynchronous manner.
We can add support for this by adding `ALGORITHM=INPLACE` to the `ALTER TABLE` query, but the fun part is that this algorithm isn't supported for all types of operations.
So, we have a couple of options:
* Keep an array of what operations can be done online in each MySQL and MariaDB version, which will need to be updated for each new version of MySQL.
* Try all `ALTER` queries with the algorithm flag, then catch any SQL errors and fall back to the old style if needed. This will need careful testing with old versions of MySQL, particularly.
https://dev.mysql.com/doc/refman/5.7/en/innodb-create-index-overview.html" pento
Future Releases 28625 Enhancement: Add constants to support SSL connections for mysqli pento Database 4.0 normal normal Future Release enhancement assigned has-patch 2014-06-24T22:39:12Z 2016-08-22T02:51:08Z "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.
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 31018 Persistent database connections with mysqli Database 4.2 normal normal Awaiting Review enhancement reopened has-patch 2015-01-14T22:37:39Z 2016-05-27T02:03:49Z "WordPress currently does not allow support for persistent database connections. This can be accomplished by prepending ""p:"" to the hostname with mysqli however with its current configuration WordPress will be confused by the "":"" and think the hostname is actually a port if specified in the wp-config.php file. This patch add support for a constant that allows persistent connections to be turned on or off.
Why should this be added to core? Because persistent connections are useful :P. But really, we have seen requests for this in other tickets such as #27933. Additionally I am involved in a project where 10,000+ sites are requiring persistent db connection, not an insignificant number. Persistent db connections are also needed to ensure proper performance on IIS and Azure installations.
In short a couple lines of code is all it takes to ensure WordPress continues to work well across other platforms and project requirements.
Props to awoods and bradparbs for helping identify the issue and solution." blobaugh
Future Releases 29938 mysqli_query and multiple resultsets Database 3.9 normal normal Awaiting Review enhancement new 2014-10-12T10:24:20Z 2015-12-03T15:26:30Z "The WordPress Database API does not expose a way to work with multiple resultsets.
Multiple resultsets are returned by queries that have several sets of results available and this is often the case with stored procedures and the usual way is to call {{{next_result}}} and {{{use/store_result}}} on the mysqli connection, however the connection is abstracted away behind the undocumented {{{$wpdb->dbh}}} field.
-- Test procedure for out of sync mysqli commands
DROP PROCEDURE IF EXISTS `mysqli_procedure_test`;
CREATE PROCEDURE `mysqli_procedure_test`()
SELECT * FROM `wp_posts` LIMIT 1;
SELECT * FROM `wp_posts` LIMIT 1;
When calling this procedure (apart from the issues outlined in ticket #28155) you can only access the first resultset using the documented APIs. To fetch the second one one would have to use the mysqli API directly.
Need to come up with additional public methods to work with these via the Database API instead. There must be a way for a user to fetch the next resultset if there's one, or make this transparent somehow, perhaps using a {{{$wpdb->call( $procedure, $arguments )}}} invocation in the case of procedures? And something like {{{$wpdb->next_results}}} for everything else?
Needs brainstorming." soulseekah
Future Releases 31920 oEmbed: Support YouTube timestamps as hashes peterwilsoncc Embeds normal normal Future Release enhancement assigned 2015-04-07T15:24:26Z 2016-06-19T23:01:10Z "YouTube can provide timestamps as a hash, which doesn't get properly processed by the oEmbed endpoint: `https://www.youtube.com/watch?v=8A6q6eGM_Aw#t=8m30s`
Converting the hash to a proper query argument produces the expected behavior: `https://www.youtube.com/watch?v=8A6q6eGM_Aw&t=8m30s`
Although it's a pain to maintain compatibility shims, including in core would reduce user confusion around oEmbed.
* Support YouTube timestamp as hash (e.g. https://www.youtube.com/watch?v=8A6q6eGM_Aw#t=8m30s)
* by converting the hash to a query arg
add_filter( 'oembed_fetch_url', function( $provider, $url, $args ) {
if ( false === stripos( $provider, 'www.youtube.com/oembed' ) || false === stripos( $url, '#t=' ) ) {
return $provider;
$url = str_replace( '#t=', '&t=', $url );
$provider = add_query_arg( 'url', rawurlencode( $url ), $provider );
return $provider;
}, 10, 3 );
}}}" danielbachhuber
Future Releases 27048 Export: Allow multiple post types to be selected Export 3.8 normal normal Future Release enhancement new has-patch 2014-02-07T09:39:39Z 2016-01-29T17:09:01Z The export tool currently only allows for all post types to be exported, or for only one to be exported. I propose fixing this so that the selection is made via checkboxes and any number of post types can be exported. This will be beneficial in many use cases. hlashbrooke
Future Releases 19879 Better caching for get_dirsize Filesystem API 3.3.1 normal normal Future Release enhancement new dev-feedback 2012-01-23T15:42:59Z 2016-10-25T16:15:36Z "In a multisite install, when trying to determine whether a site has exceeded its storage quota, WordPress will scan through a blog's upload directory and sum up the file sizes, by running {{{filesize}}} against each one. With a large number of files, this can significantly slow down the upload process or certain portions of the Dashboard.
{{{get_dirsize}}} has transient caching in place but this is a single cache entry for all folders. It might be better if WordPress has a separate cache entry for each folder and was invalidated based on context so that get_dirsize does not need to be run constantly on older, unchanged directories as frequently." batmoo
Future Releases 26868 Function 'make_clickable()' doesn't make hyperlinks from explicit URLs using the `mailto:`, `tel:` and other schemes that do not start with `//` Formatting 3.8 normal normal Future Release enhancement new dev-feedback 2014-01-18T16:00:14Z 2015-10-01T04:01:37Z "Function `make_clickable()` tries to recognise URLs and convert these into clickable hyperlinks. The function is by default configured as a filter for comment text.
Unfortunately, the function assumes that all explicitly declared URLs begin with the string `//` after the scheme and colon parts which is not the case for the `mailto:`, `tel:` and many other schemes. Such URLs could usefully be made clickable, especially for use on smartphones and tablets.
This also leads to inconsistencies between explicitly and implicitly declared URLs. For example, the string `firstname.lastname@example.com` is converted into a clickable hyperlink whilst the string `mailto:email@example.com` is not.
By contrast, the TinyMCE post editor correctly and automatically makes both implicit and explicit `mailto:` links clickable but does nothing with `tel:`.
For reference, the syntax of URLs is defined by http://tools.ietf.org/html/std66, the `mailto:` scheme by http://tools.ietf.org/html/rfc6068 and that for `tel:` by http://tools.ietf.org/html/rfc3966.
As #16892 has illustrated, parsing URLs can be hard. The use of `wp_allowed_protocols()` may help in detecting which strings we wish to make clickable.
Found whilst testing #22946." mdgl
Future Releases 24225 Improve regular expressions when matching attributes miqrogroove Formatting 3.6 normal normal Future Release enhancement assigned has-patch 2013-04-29T15:37:56Z 2015-09-18T04:42:15Z "When working with HTML attributes in various functions we use something like `[\'""](.+?)[\'""]` to match the attribute value. Although not used much in attribute values, such an approach breaks when a single or double quote is intentionally part of the value:
* `attr=""val'ue""`
* `attr='val""ue'`
Some of these are new 3.6 functions, mostly around media." kovshenin
Future Releases 22330 Optimize regexes to remove protocol from URL Formatting 3.4.2 normal normal Future Release enhancement new has-patch 2012-10-31T09:30:48Z 2015-10-07T02:15:00Z "Regexes used to chop off the protocol of a URL should be anchored to the start of the string.
1. The regex fails faster and thus avoid useless work. No need to look further down the URL for strings like `""http://""`.
2. The regex should not alter any URLs that might be contained in the query string." GeertDD
Future Releases 24106 Simplify wp_slash() Formatting 3.6 normal normal Future Release enhancement new dev-feedback 2013-04-16T19:37:12Z 2015-10-08T17:17:38Z "[23416] added the function {{{wp_slash()}}} for the slashing sanitization in #21767.
[https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-04-16&sort=asc#m595515 According to ryan], it has been modelled after {{{$wpdb->prepare()}}}, and therefore uses a custom {{{foreach}}} loop with an {{{if}}}-check in it.
I suggest to instead model it after {{{stripslashes_deep()}}} and {{{urlencode_deep()}}} to simplify the function and make it better readable.
The attached patch also makes it clearer that this function works in a recursive manner." TobiasBg
Future Releases 20771 esc_url() instead of esc_html() in wp_nonce_url() johnbillion* Formatting 3.4 normal normal Future Release enhancement accepted 2012-05-29T06:21:37Z 2016-04-01T13:46:09Z "The `wp_nonce_url()` function currently uses `esc_html()` in its output, which doesn't really seem to be the appropriate escaping function since it's generating a URL.
Attached patch changes the output to use `esc_url()`" jkudish
Future Releases 32787 make_clickable filter johnjamesjacoby Formatting 0.71 normal normal Future Release enhancement assigned has-patch 2015-06-25T09:38:02Z 2016-06-28T20:22:55Z "Hi,
it could be very usefull to add filters to regex callback functions in make_clickable :
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 21667 Add some user agent to wp_is_mobile stevenkword General 3.4.1 normal normal Awaiting Review enhancement assigned dev-feedback 2012-08-23T12:35:29Z 2016-04-18T10:44:35Z "Hello,
I've run some test with the help of the twitter/G+ community on wp_is_mobile and found some mobile browser that don't pass the test.
You can see the test here : http://www.inpixelitrust.fr/blog/wp_is_mobile/
I was able to get the user agent of 3 of those which don't work :
HTC sensation z710 4.0.3 native browser (UA: Mozilla/5.0 (X11;Linux x86_64; HTC/Sensation/220.127.116.11; fr-de)
AplliWebkit/534.24(KHTML,like Gecko) Chrome/11.0.696.32 Safari/534.34 )
BlackBerry Playbook (Ua Mozilla/5.0 (PlayBook; U; RIM Tablet OS 2.0.1; en-US) AplleWebkit/535.8+ (KHTML, like Gecko) Version/220.127.116.11 Safari/535.8+ )
Could be great to add those to the UA sniffing :)
" inpixelitrust
Future Releases 34699 New function: `get_query_arg()` General normal normal Awaiting Review enhancement new dev-feedback 2015-11-16T12:51:31Z 2017-02-21T06:03:53Z "For example i have url $url = 'http://example.com/?param=1¶m2=2¶m3=3' and I want get `param2` so I use function: get_query_arg('param2', $url);
Second argument: exists function add_query_arg and remove_query_arg" sebastian.pisula
Future Releases 35386 Refining Walker code General normal normal Awaiting Review enhancement new has-patch 2016-01-09T16:12:59Z 2016-04-05T06:20:00Z This a simple patch for the Walker class. Previously, if root was not 0, a second for loop was performed in the walk function. This new code does the same functionality with less loops Funkatronic
Future Releases 24284 is_multi_author() should query by specific post type and status General normal normal Awaiting Review enhancement new has-patch 2013-05-08T08:18:58Z 2015-12-03T17:20:12Z "Current is_multi_author() function only checks by the 'post' post-type and 'publish' post-status..
I think the function should be able to query by custom-post-type and custom-post-status" alex-ye
Future Releases 39695 Add preload headers in redirects HTTP API normal normal Awaiting Review enhancement new has-patch 2017-01-25T22:09:45Z 2017-02-27T09:32:49Z "http2 push enabled servers can immediately push linked assets or documents for the client. This saves clients from one round-trip.
At the moment at least Cloudflare and h2o web server can http2 server push assets defined in Link headers: https://www.w3.org/TR/preload/#server-push-http-2.
I believe more will follow in the next few years. WordPress powers so much of the web that it's our responsibility to try to make it as fast as we can.
This is usually quite hard topic because we have no idea what is stored in the client browser cache.
We can start implementing the Link preload headers in internal redirects because in that situation it's quite obvious that the client wants to make that request as their next one.
This is what I want to achieve
$ curl --http2 -i https://wordpress.test/wp-admin/
Location: https://laextra.test/wp-login.php?redirect_to=https%3A%2F%2Flaextra.test%2Fwp-admin%2F&reauth=1
Link: ; rel=preload; as=document
I created a patch which adds these headers automatically in '''wp_redirect()''' function.
Links about http2 server push:
https://h2o.examp1e.net/configure/http2_directives.html" onnimonni
Future Releases 34883 Support TLS Client Certificates HTTP API normal normal Future Release enhancement new has-patch 2015-12-06T21:04:02Z 2016-10-05T03:41:48Z "As we get savvier about TLS as part of the HTTPS Everywhere movement, one use-case that would be nice to support is using Client Certificates when making HTTPS requests. Using client certificates for authentication is a strong way to build trusted APIs.
This looks like it would be fairly straightforward to implement as the option is supported by both Curl and PHP stream contexts ({{{CURLOPT_SSLCERT}}} or {{{local_cert}}}, respectively). We'd just need to add the handling for specifying the path to a client cert as part of the $options array in the API calls, and turn that in the proper option for the actual transporter.
I should be able to create a patch for this shortly." Outlandish Josh
Future Releases 25585 Arabic stopwords comparison I18N 3.7 normal normal Future Release enhancement reopened 2013-10-13T14:49:30Z 2016-06-07T18:26:22Z "WordPress uses simple string comparison in WP_Query->parse_search_terms() function, which is fine for many languages but Arabic need more than that to provide a really smart search!
There are some chars need to removed before the string comparison, like:
Tā' marbūṭah
If this cannot be in core, Could you at least add some filters to do it ?!" alex-ye
Future Releases 15384 wp-login.php refactor valendesigns Login and Registration normal normal Awaiting Review enhancement assigned dev-feedback 2010-11-11T12:40:35Z 2016-09-17T19:50:18Z "wp-login.php needs some serious work. When looking to do some improvements in #5919, I realized I literally needed a goto in order to achieve the goals outlined in this comment:
I am thinking a WP_Login class with some methods that can handle various different forms, POST handling, and rerouting." nacin
Future Releases 30128 Allow to use associative arrays beside indexed arrays in wp_mail $headers Mail 2.3 normal normal Awaiting Review enhancement new has-patch 2014-10-27T21:15:12Z 2015-04-30T21:57:55Z "eg:
$headers = [
'From' => 'Me Myself ""
string(28) ""Some amount of useless text ""
string(11) """"
string(0) """"
string(4) "" ""
string(121) ""[code-highlight line-numbers=""table"" linenostart=""53"" highlight-lines=""1,3,8"" style=""native"" lang=""html+php"" pyg-id=""1"" ]""
string(6) "" ""
string(15) ""Some Text Again""
string(4) "" ` and never closing that tag, on the oembed returned markup, right before `
I did some tracing and found out that it was `wpautop` fault. Even though `WP_oEmbed::_strip_newlines()` was successfully stripping the new lines from the returned oEmbed HTML, something was adding an extra newline before the `\s*|', '', $pee );
Now the oembed is fully functional and doesn't have that unclosed ` ` tag:
Lisbon with #WordPressVIP @ Terreiro do Paço http://instagram.com/p/vGw5IchocB/ — Henrique Mouta (@vaurdan) November 7, 2014 ) tags around the comment and for multi-line comments line breaks ( world b tags are generated when shortcodes are followed by HTML tags and wpautop is enabled Formatting 3.4.1 normal normal Future Release defect (bug) new has-patch 2012-08-26T06:58:21Z 2015-10-13T04:33:17Z "This bug was encountered in separate plugins, but it seems that its source is in the core:
https://github.com/pods-framework/pods/issues/271" dandv
Future Releases 25785 Unexpected Paragraph Formatting Within a Div Container Formatting 3.7 normal normal Future Release defect (bug) new 2013-10-31T02:01:15Z 2015-12-03T17:46:28Z "Though HTML mode in WordPress allows for the user to add in their own CSS styling and HTML content formatting if necessary, its normal behavior also makes it auto-format paragraph breaks without the user's input of paragraph tags. This is EXPECTED behavior.
I have discovered that in this specific manner of formatting when writing a post or page (note the LACK of spacing between the div tag and the content and the multiple paragraphs):
Second paragraph.
$thelist .= ""\n\t';
} else {
$thelist .= implode( $separator, $links );
* Filter the category or list of categories.
* @since 1.2.0
* @param array $thelist List of categories for the current post.
* @param string $separator Separator used between the categories.
* @param string $parents How to display the category parents. Accepts 'multiple',
* 'single', or empty.
return apply_filters( 'the_category', $thelist, $separator, $parents );
}}}" pietergoosen
Future Releases 29586 Sync get_the_category_list with get_the_term_list Taxonomy 2.5 normal normal Future Release enhancement new 2014-09-08T13:39:35Z 2015-06-16T04:29:51Z "It would be great to have {{{get_the_term_list()}}} support the same features {{{get_the_category_list()}}} has.
I created a proof of concept patch what works. The only thing I hate is the part I need to specify that I want to have a list instead of a separator because when it's empty {{{get_the_category_list()}}} assumes to show a list but {{{get_the_term_list()}}} will then just show only the links." markoheijnen
Future Releases 36949 Term exists should use get_terms internally Taxonomy 2.3 normal normal Future Release enhancement new 2016-05-26T08:33:16Z 2016-05-26T12:31:58Z More than WP_Term_Query has been merged, it makes sense to converge to use it in all internal functions to query the terms table. Using WP_Term_Query / get_terms will also add caching to a functions that do not currently have it. spacedmonkey
Future Releases 36641 WP_Term method __toString Taxonomy normal normal Awaiting Review enhancement new has-patch 2016-04-22T20:59:58Z 2017-02-05T14:18:20Z "I think that this is good idea. For example:
var_dump(implode(', ', get_the_terms( get_the_ID(), 'category' )));
echo '';
I have ```string(**) ""Cat 1, Cat 2""```
" sebastian.pisula
Future Releases 23635 get_objects_in_term - identify matching terms Taxonomy 3.5.1 normal normal Future Release enhancement new 2013-02-26T21:29:54Z 2015-12-03T15:05:25Z "`get_objects_in_term` is great for viewing taxonomy relationships for non-posts. However the return value is too limited for certain use cases. For When fetching object_ids for multiple terms the return value doesn't inform as to the matching term.
For instance this query:
$object_ids = get_objects_in_term(array(55, 66, 77, 88, 99), ""my_custom_taxonomy"");
Might return an array of object_ids as follows:
array(101, 202, 303, 404);
However there's no way to tell '''which''' term a particular object_id matched. Did object 101 match term 77? Or maybe it was term 99? Or both?
I've created a modified version of `get_objects_in_term` which will addresses this issue. I'll submit a patch, but am wondering if there's another way to achieve this functionality. " leepowers
Future Releases 38160 Attachment template hierarchy selects generic attachment.php before specific post type templates Themes normal normal Awaiting Review enhancement new 2016-09-26T13:29:00Z 2016-09-26T13:29:00Z "When viewing a single attachment at its permalink, the template hierarchy is as follows (using `foo.jpg` as an example).
1. `image-jpeg.php`
2. `jpeg.php`
3. `image.php`
4. `attachment.php`
5. `single-attachment-foo.php`
6. `single-attachment.php`
7. `single.php`
8. `singular.php`
9. `index.php`
Note that the generic `attachment.php` appears higher in the hierarchy than the more specific `single-attachment-foo.php`. This means it's impossible to target a specific attachment if an `attachment.php` file is in place." johnbillion
Future Releases 37825 Introduce functions to check whether there are multiple taxonomy terms Themes normal normal Awaiting Review enhancement new 2016-08-25T12:33:10Z 2016-09-25T20:08:48Z "We've had a function `is_multi_author()` since version 3.2.0, which is regularly used by themes to check if a site has multiple authors with published posts.
A similar function is often needed by themes for taxonomies (mostly categories), for example the latest default themes have contained a function `*_categorized_blog()`. I think this functionality is essential for several themes, and we can make their lifes easier by providing these functions to them (especially since several theme authors don't really wanna mess with hooks for invalidating transients).
Of course, for backward compatibility a theme should check whether that function exists, and if not, it still needs to take care of things by itself. However, I think this will still be a good solution long-term to include this functionality in WordPress Core." flixos90
Future Releases 39083 Introduce singular capabilities for managing individual themes Themes normal normal Future Release enhancement new 2016-12-04T22:12:26Z 2016-12-04T22:12:26Z "As we did in #35614 for taxonomy terms, singular capabilities should be introduced for switching, editing, deleting, and updating individual themes.
This would allow fine-grained cap checks such as `current_user_can( 'switch_theme', $theme )` and `current_user_can( 'delete_theme', $theme )`." johnbillion
Future Releases 15086 get_template_part() should let you specify a directory westi* Themes 3.0 normal normal Future Release enhancement accepted dev-feedback 2010-10-10T21:36:45Z 2015-09-23T23:41:49Z "IT would be nice for `get_template_part()` to allow you to specify a directory to look for a file in. Right now you actually *can* do this, but it requires passing a 'slug' to the function like `directory/slug`. Since everywhere else in the code slugs are sanitized, this seems like an unexpected way to allow this functionality (I didn't realize this worked until @nacin pointed it out). Since this slug isn't actually sanitized at all, you can currently do `get_template_part( '../../../test' );` which seems rather unsafe (`get_template_part` should be able to include from outside the themes directory).
I suggest sanitizing $slug and adding a third [optional] parameter that allows you to specify the directory to look in. The directory parameter should be sanitized enough to not allow it to start with a . or a / (although this more likely belongs in `locate_template()` as something done to $template_name inside the foreach).
What does everyone think about this approach?
How many themes do we think are currently using the $slug parameter to specify a directory?
Right now the optional $name parameter is set up as a fall through, so if $slug-$name.php doesn't exist $slug.php is used. Should $directory be set up similarly ($directory/$slug-$name.php -> $directory/$slug.php -> $slug-$name.php -> $slug.php)?" aaroncampbell
Future Releases 29804 Use HR instead of IMG as a placeholder for the more and nextpage tags TinyMCE normal normal Future Release enhancement new has-patch 2014-09-29T20:23:14Z 2016-10-06T16:23:04Z Read more here: #28335. iseulde
Future Releases 20307 Edit User link in admin toolbar johnbillion* Toolbar normal normal Future Release enhancement accepted has-patch 2012-03-27T11:51:18Z 2016-11-23T08:42:08Z When you're viewing an author archive, there should be an 'Edit User' item in the admin toolbar in the same way we have 'Edit {taxonomy}' on taxonomy archives, 'Edit Post' on single posts, etc. johnbillion
Future Releases 33932 Filters for Plugin/Theme Update Email Notifications ocean90 Upgrade/Install 3.7 normal normal Future Release enhancement reviewing has-patch 2015-09-20T04:51:05Z 2016-06-06T21:58:33Z "I've had several requests to enable core update emails, but disable emails for plugins/themes.
If this idea is approved, '''I would love to be the one to tackle this''' as I have yet to contribute to core.
Goal is to keep `send_core_update_notification_email` intact, but allow filters for both plugin/theme background update notifications.
Apparent use-case is a user wants core emails, but not plugin/theme emails. One filter rules them all currently from what I can see in the code-base.
Example use-case in the wild: https://wordpress.org/support/topic/for-on-the-wishlist?replies=8" ronalfy
Future Releases 34676 Optimize bulk plugin updates Upgrade/Install 4.4 normal normal Awaiting Review enhancement new has-patch 2015-11-13T16:03:40Z 2016-05-08T14:55:44Z "When selecting more then one plugins to update the following things are done:
* Maintenance mode on (if -a- plugin is active)
* Per plugin:
1. Get plugin info
2. Download package
3. Unpack package
4. Install package
* Maintenance mode off
10 plugins require updates.
Only the last one is active = requires maintenance mode to be enabled.
Server might not have the best connection to WordPress.org or other plugin resource.
This means that the site will not be available during:
* Downloading of all plugins
* Unpacking of all plugins
* Installing of all plugins
This means at least (10*download request) + (10*unpacking) + (10*installing) = 30 actions.
Not including optional plugin info request * 10.
Also not including plugins that need to do delta's on tables or other upgrading scripts.
Though only one plugin actually required the site to not be available, which would be (1*installing) = 1 action.
**Ideal flow:**
* Download all packages
* Unpack downloaded packages
* Determine per plugin if maintenance is required
* Install plugin
* Disable maintenance if next plugin is not active
* Finally: disable maintenance if enabled
* Remove all unpacked packages and downloads
I can think of a performance argument to include the unpacking of packages in the maintenance mode because it might be a strain on the server, but functionally I don't think it should be.
As far as I can see the only file that this is effectively handled in is `class-wp-upgrader.php`." jipmoors
Future Releases 9257 EXIF GPS data Upload 2.7 normal normal Future Release enhancement new has-patch 2009-03-01T19:30:17Z 2015-10-13T03:21:02Z "Attached patch adds GPS longitude and latitude to image meta data.
Changed: wp_read_image_metadata function (file: wp-admin/includes/image.php).
It complies with exif standard:
[http://www.exif.org/Exif2-2.PDF] (page 46)
Commented on wp-hackers list:
[http://comox.textdrive.com/pipermail/wp-hackers/2009-March/025093.html]" B-Scan
Future Releases 18791 Add custom post type support for Author Template functions Users 3.2.1 normal normal Future Release enhancement new 2011-09-27T12:32:48Z 2015-11-01T19:23:39Z "Functions defined in `wp-includes/author-template.php` assumes that post type == post. It will be good to enhance them so they will be able to work with specified post type.
At first sight following functions will need update:
I suspect there will be other updates needed, to support new `post_type` argument added to author's url." sirzooro
Future Releases 39123 Allow usernames to be changed by administrators Users normal normal Awaiting Review enhancement new dev-feedback 2016-12-06T21:25:53Z 2016-12-13T16:54:09Z "Usernames cannot be changed. I'd like to propose that users who have the `edit_users` capability (administrators on single site installations, and super admins on multisite installations) are given the ability to update a user's username from their profile editing screen.
The historical reason for disallowing changes to usernames is not clear, but it's most likely related to the generation of the `user_nicename` field which ideally needs to remain persistent so author archives don't 404.
However, this can be addressed in the same way as changes to post slugs, where a user's old usernames and nicenames are recorded in usermeta when their username is updated (and their nicename is regenerated) and a canonical redirect can kick in to redirect to the new author archive URL.
Any other considerations to make if usernames are allowed to be changed by administrators?" johnbillion
Future Releases 21730 More modular and reusable email validation functions Users normal normal Future Release enhancement new has-patch 2012-08-29T16:04:04Z 2015-12-17T16:04:16Z "Email validation, especially as it's handled in Multisite (most of which is verbatim from MU), is pretty messy. We have some functions like `is_email_address_unsafe()` for checking banned domains, but we don't have a parallel function for checking against limited_email_domains. There are no filters outside of `wpmu_validate_user_signup`, which means that if you want to use email validation outside of the normal MS registration workflow and want to tweak the way that it works (see eg #15706, #20459), you pretty much have to roll your own. And there's no single function that a plugin like BuddyPress can use to do all relevant email checks in one fell swoop.
The attached patch suggests the following changes:
- Put the limited_email_domains check into a function, `is_email_address_allowed()`.
- Put filters on the output of this new function as well as `is_email_address_unsafe()`.
- Introduce function wp_validate_email_address(), which wraps the following four checks: is_email(), email_exists(), is_email_address_allowed(), is_email_address_unsafe().
- Rearranges `wpmu_validate_user_signup()` a bit so that all email checks (as opposed to username checks) happen together.
I'm not married to anything in this particular implementation (the way that wp_validate_email_address() sends back error messages is not particularly beautiful, but I didn't want to introduce a ton of overhead), but I would really like to see some sort of treatment along these lines, to make things more modular and reusable.
If something like this gets approved by the devs, I would like to further suggest the following:
- Give a similar treatment to username validation
- Move the generic validation functions out of ms-functions.php (with function_exists() checks on the MS-specific stuff)
I'm happy to work more on this kind of patch, but didn't want to go too far in case it's a non-starter for some reason." boonebgorges
Future Releases 39090 Remove duplicate query from posts page in the admin Users normal normal Future Release enhancement new 2016-12-05T20:33:19Z 2016-12-07T16:00:15Z "The posts page in the admin (`/wp-admin/edit.php`) is running twice the query below. This is a problem specially for sites with a significant number of users since this query can be super slow (see #19867 and #28160).
SELECT wp_users.ID,wp_users.user_login,wp_users.display_name
FROM wp_users
INNER JOIN wp_usermeta
ON ( wp_users.ID = wp_usermeta.user_id )
AND ( ( wp_usermeta.meta_key = 'wp_user_level'
AND wp_usermeta.meta_value != '0' ) )
ORDER BY display_name ASC
The query is executed by `WP_User_Query::query()` and, in this particular page, is called by the function `wp_dropdown_users()`.
The attached patch fixes this problem by adding the result to the cache when the query is run the first time. Preventing multiple executions of the same query." rodrigosprimo
Future Releases 32796 User deletion API is inconsistent between MS and non-MS Users normal normal Future Release enhancement new has-patch 2015-06-26T12:56:44Z 2015-07-05T03:25:22Z "On non-multisite, `wp_delete_user( $u )` does what you'd expect: it deletes user `$u` from the database. On multisite, the same function basically wraps `remove_user_from_blog()`; if you want to delete a user from the database altogether, you've got to use `wpmu_delete_user()`.
I understand the historical reasons behind the divergence, but it's pretty lame from a developer's point of view to have to check `is_multisite()` before removing a user from the database.
There's a note in the docblock for `wpmu_delete_user()` that says ` * @todo Merge with wp_delete_user() ?`. Maybe we could actually make this happen?
" boonebgorges
Future Releases 34316 User status inconsistent between single-site & multisite Users 1.5 normal normal Awaiting Review enhancement new dev-feedback 2015-10-15T19:00:15Z 2016-12-20T21:32:34Z "The way a user's status is defined in WordPress differs between single-site and multisite:
* In single-site, the `user_status` column is used
* In multisite, there are two additional columns for `spam` and `deleted`
Not only this, but the `update_user_status()` function is multisite only, and the `user_status` column is an integer without an API to help announce what values equate to what results.
On the plus side, user statuses aren't really ever used in core. Marking users as spammers in multisite installations is the only real benefit of this feature as it exists today. I'd like to propose the following:
* Stop creating the the `spam` and `deleted` columns in `wp_users` on new installations
* ALTER the `user_status` column from `INT(11)` to `VARCHAR(20)` ala `wp_posts`
* A bevy of `wp_register_user_status()` like functions to introduce bonafide support for them
* A database upgrade routine to move user status `0` to `active` and `1` to `spammer`
* A new index on the `wp_users` table for the updated `user_status` column type. We may need a few, based on how users are commonly queried in core, BuddyPress, etc...
* Update the `WP_User` and `WP_User_Query` classes to suss out any `user_status` inconsistencies
A few considerations worth noting:
* Large installations would need to manually perform these DB upgrades. I'm embarrassed to say I've personally frozen WordPress.org for several minutes years ago by missing a `DO_NOT_UPGRADE_GLOBAL_TABLES` check on the `wp_users` table
* Several plugins use their own values in the `users_status` column, assuming their numeric ID is unique and special. The authors of these plugins would need notifying, and their code updating to support the above ideas
* This work *could* parlay into the Post Status API that's on infinite back-burner. There are some really excellent ideas floating around about how `post_status` could work that would translate nicely to users, too" johnjamesjacoby
Future Releases 34226 Add 'widget_display_callback' filter to the_widget() Widgets 4.3.1 normal normal Awaiting Review enhancement new 2015-10-08T22:11:32Z 2015-12-08T05:16:27Z "When a widget is output through a registered sidebar it passes through the 'widget_display_callback' filter (see 'display_callback' in 'wp-includes/widgets.php', allowing for short-circuiting. This is not the case when 'the_widget' is called, however. This patch simply adds the same feature to that function.
The reason I came across this is because I am using the [https://wordpress.org/plugins/display-widgets/ Display Widgets] plugin to hide widgets under certain circumstances. It hooks into 'widget_display_callback', runs some logic, and returns false if it should not appear. Using 'the_widget' in a template file, I noticed that the widget still appeared.
It seems logical to me that any time a widget is displayed, it should go through this filter." MarcGuay
Future Releases 35574 Add REST API JSON schema information to WP_Widget Widgets 2.8 normal normal Future Release enhancement new 2016-01-22T12:24:06Z 2017-01-04T01:08:23Z "With the REST API, there is an emerging-established way in WordPress for describing a data structure, such as a widget instance.
One aspect of the REST API endpoint schema is the `default` values for given fields on a property. Widgets often have duplicated logic between the `WP_Widget::widget()`, `WP_Widget::update()`, and `WP_Widget::form()` methods for checking if a given `$instance` property has been set, and if not, supplying a default value. In some cases, these `isset` checks are ''not'' performed resulting in PHP notices if the methods are programmatically invoked with an empty array. With JSON Schema defined, we would provide `$instance` defaults upon which the current stored `$instance` can be merged.
Widgets in WordPress are assumed to be arrays, with the applied filters and function return values. With a schema defined, the data type of a widget instance would be guaranteed. Meta in the REST API is a challenge given that it may or may not contain serialized PHP. Widgets are stored in serialized PHP arrays in WP options (though it is possible to store them in posts, per #32474). Additionally, the instance arrays may also contain PHP objects for classes that cannot be cleanly serialized into JSON, and having a REST API JSON schema defined for a widget would guarantee that a widget instance can be represented in JSON. This would, in turn, allow widgets to be exposed as [https://github.com/WP-API/WP-API/issues/19 endpoints] in the REST API, and it would allow widget instances to be completely manipulated with JavaScript (such as in the Customizer, as described in #33507).
By adding schema information to `WP_Widget`, we get a lot more than having default `$instance` data available. For one, the widget form can be automatically generated based on the schema if one is not defined (i.e. if `noform` is returned from the `WP_Widget::form()` method). (This may actually be focus of the Fields API.)" westonruter
Future Releases 33915 Add a filter in dynamic_sidebar() function to modify sidebar index Widgets 4.3 normal normal Future Release enhancement new has-patch 2015-09-17T15:04:28Z 2016-02-24T11:48:07Z Changing sidebars depending on the page/post/etc loaded through a plugin. Nothing too complex, just no way to do it. There is a filter dynamic_sidebar_params but that isn't called until later on in the function after the widgets have been collected for that sidebar. fahidjavid
Future Releases 31020 Introduce discrete capability for managing widgets johnbillion Widgets normal normal Future Release enhancement assigned dev-feedback 2015-01-15T07:11:15Z 2016-11-04T03:44:43Z "As with management of nav menus (#29213), managing widgets currently requires `edit_theme_options` capability, a capability associated with administrators which grants the power to make many wide sweeping changes. There should be a discrete capability `manage_widgets` just for managing widgets, one that is inherited for anyone who has `edit_theme_options` by default. This was done for Customizer access in #28605 with the introduction of a `customize` capability.
Originally brought up in #14386.
The same is proposed for menus in #29213." westonruter
Future Releases 34093 New filter: `get_calendar_post_type` in get_calendar() Widgets normal normal Future Release enhancement new has-patch 2015-09-30T06:19:27Z 2016-10-07T20:09:03Z Filter for post type in calendar. If I want show posts from others post type sebastian.pisula
Future Releases 29319 filter dayswithposts in widget calendar Widgets 3.0 normal normal Awaiting Review enhancement new 2014-08-22T14:28:53Z 2015-12-03T14:43:16Z "Hello
here is Konrad, WPML developer. We are fighting now with bug related WordPress calendar widget: it always displays all posts, and we want to filter its results regarding to language of post.
Steps to reproduce:
1. install WPML
2. publish some post in En language July 1st
3. translate this post July 2nd to Polish language
4. activate calendar widget
Result: calendar will show that there are posts in July 1st and 2nd.
Expected result: when user displays English posts, calendar should display only July 1st. When user switches to Polish language, calndar should display only July 2nd.
We want to fix this in WPML but we need filter inside of get_calendar() function.
Wordpress gets days with posts by this query inside of get_calendar():
$dayswithposts = $wpdb->get_results(""SELECT DISTINCT DAYOFMONTH(post_date)
FROM $wpdb->posts WHERE post_date >= '{$thisyear}-{$thismonth}-01 00:00:00'
AND post_type = 'post' AND post_status = 'publish'
AND post_date <= '{$thisyear}-{$thismonth}-{$last_day} 23:59:59'"", ARRAY_N);
The result should be able to filter, then WPML will hook here.
I am attaching proposed diff file.
(I see that we can hook into get_calendar filter but this variable has full html output of calendar. This will unefficient to parse this HTML)
" kkarpieszuk
Next Release 39535 Canonical redirects disallow tag named comments Canonical normal normal 4.8 defect (bug) new has-patch 2017-01-10T09:04:05Z 2017-02-20T02:35:20Z "The `redirect_canonical` function includes a regular expression replacement which effectively disallows tags named ""comments"" to have an RSS feed:
For example:
This is redirected to:
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
Next Release 39210 switch_to_locale() unloads all plugin and theme translations I18N 4.7 normal normal 4.8 defect (bug) new has-patch 2016-12-09T16:07:08Z 2017-01-22T21:03:17Z "When using switch_to_locale() in the backend, all translations loaded into the `$l10n` global will be unloaded, except for the default one. This makes plugin and theme translations unavailable after using switch_to_locale().
In the `load_translations` method of `WP_Locale_Switcher` there are two functions called right after each other for each of the currently loaded domains:
unload_textdomain( $domain );
get_translations_for_domain( $domain );
`unload_textdomain` loads all unloaded functions into the `$l10n_unloaded` global. Later when `_load_textdomain_just_in_time()` is called in `get_translations_for_domain()`, all domains set in `$10n_unloaded` will be short-circuited in the following statement
// Short-circuit if domain is 'default' which is reserved for core.
if ( 'default' === $domain || isset( $l10n_unloaded[ $domain ] ) ) {
return false;
This results in only the new translations for the domain `default` being loaded. All plugin and theme translations will be lost. But even when `|| isset( $l10n_unloaded[ $domain ]` is commented out, it doesn't work, because WordPress then tries to load a language file from the `WP_LANG` folder, and not from either a theme or plugin directory.
In #26511 it was already mentioned by @rmccue that this might affect emails to be sent in the wrong language: https://core.trac.wordpress.org/ticket/26511#trac-change-8-1430202811399151.
I run into this problem when I want to send notification emails to subscribed email adresses whenever I publish a post.
= Test case =
I created a minimal theme with a translations for `en_EN` and `de_DE` that displays some debug output in the backend and the frontend.
Preparatory steps:
1. Set site language to German (de_DE).
2. Set admin user language to English (en_EN). If the language dropdown does not appear, temporarily set the site language to German so the translation is downloaded and then select the users language again.
3. Install the test theme.
Now an admin notice should appear in the backend that shows debug output. There are string translations saved before and after `switch_to_locale`. Whenever `Untranslated default string` shows up, then a translation couldn't be loaded.
Now if this is not intended behavior, I don't really know how I would approach fixing this." gchtr
Next Release 38341 Hide 'Empty Trash' button when trash is already empty Posts, Post Types normal normal 4.8 defect (bug) new has-patch 2016-10-18T13:50:00Z 2017-02-22T08:08:04Z "Noticed while working on #37407.
Here's a screenshot:
[[Image(https://cldup.com/TxxKy9pM0E.png)]]" swissspidy
Next Release 39186 Bulk actions not correctly applied when selecting bulk actions in both the top and bottom bulk actions dropdowns Quick/Bulk Edit 4.7 normal normal 4.8 defect (bug) new has-patch 2016-12-08T14:48:44Z 2016-12-11T22:02:05Z "In `WP_List_Table` objects, the bulk actions dropdown and ""Apply"" button is displayed twice: once below the table and once above the table. The `name` attribute of the bulk actions dropdown element is always set ""action"". This wouldn't be a problem if the top and bottom actions were two in different forms.
However, both dropdown elements are in the `posts-filter`-form. You can start to see the problem here. Two form elements both have the same name, which yields unexpected behaviour when trying to apply bulk actions.
Take the following use case, for example:
- Select some posts from the posts list in `/wp-admin/edit.php`.
- Select ""Edit"" from the bulk actions dropdown above the list table.
- Select ""Move to Trash"" from the dropdown below the list table.
- Click the apply button next to the dropdown on the bottom of the list table.
- The submit request is sent. You would expect the posts to be moved to the trash, but instead, nothing happens.
Screencast of bug: http://recordit.co/EjHAbw2KNr
The solution I see would rename the dropdowns for the top and bottom dropdowns (they already have different names) and name the ""Apply"" buttons. Then, when one of the buttons is pressed, execute the corresponding bulk action.
In any case, we shouldn't have any two form elements with the same name in a single form." engelen
Next Release 39072 Add gmt_offset as a REST API setting REST API 4.7 normal normal 4.8 defect (bug) new 2016-12-04T20:21:43Z 2017-02-13T16:55:03Z "The timezone string can be seen and updated via the REST API, but there is no way to get the GMT offset (which I would imagine is more more valuable for calculating things). There is also no way to update it (aka manual offset).
The attached patch is one way to fix it. It makes sure to clear out the timezone string if you are manually overriding/setting the offset. I'm not sure if what I have is the best way to handle that case for the API, but I took a stab at it. If a timezone string is set, the offset is correctly returned for that timezone." jshreve
Next Release 39683 REST API JS Client: Should enable connecting to multiple endpoints at the same time REST API 4.7 normal normal 4.8 defect (bug) new has-patch 2017-01-24T22:33:27Z 2017-02-10T17:18:07Z "Originally from @lucasstark: https://github.com/WP-API/client-js/issues/145
If you need to talk to more than one endpoint the way the api is initialized does not make this straight forward.
It seems like it should be possible, since wp.api.endpoints is a collection of each unique endpoint you might initialize, however, the collections and models on each endpoint will be overwritten each time you call wp.api.init, so obviously we need a solid way to initialize more than one endpoint at once.
An example use case would be in a multisite environment you might want to talk to two of the subsites at the same time.
You'd think you could do something like this rough example:
var sites = [];
'apiRoot': 'http://example.com/subsite1/wp-json/'
sites[ 1 ] = endpoint;
'apiRoot': 'http://example.com/subsite2/wp-json/'
sites[ 2 ] = endpoint;
But now sites[1].collections is configured with the URL for the second site." adamsilverstein
Next Release 39881 `WP_REST_Posts_Controller::check_read_permission()` should check if `$parent` exists before calling itself rachelbaker REST API 4.7 normal normal 4.7.4 defect (bug) reviewing dev-feedback 2017-02-15T14:35:58Z 2017-02-27T12:56:13Z "In `WP_REST_Posts_Controller::check_read_permission()` there ends up being a check for if the `post_status` of the post in question is `'inherit'` and if the `post_parent` is greater than 0. It then checks the parent for permissions regarding the child. However, sometimes (as I have found with attachments), the child believes it has a parent, but the parent is missing. This results in a `null` post being sent to `$this->check_is_post_type_allowed()` which fails early and throws error about property of non-object.
I believe if the parent is missing, the next sequence should take precedence: which is that if `post_status` is `'inherit'`, `check_read_permission()` returns true. This would essentially be the same as if the `post_parent` value was set to `0`.
A simple check if `$parent` has a value before passing it to a recursive call of `check_read_permission()` can alleviate this.
To reproduce this error, try to access a post with attachments, using `_embed` on the REST API, where one of the attachments has a `post_parent` that is invalid (integer that doesn't exist in corresponding `wp_posts` table)." GhostToast
Next Release 39920 Empty if-statement Rewrite Rules 1.5 normal normal 4.8 defect (bug) new 2017-02-20T14:13:26Z 2017-02-20T14:34:53Z "Hello!
In this [https://github.com/WordPress/WordPress/blob/c4e78a8d8ba2e0b5b85866c6fc46895aead5802a/wp-admin/includes/misc.php#L74 code fragment]:
'show_in_rest' => true,
'auth_callback' => 'check_logged_in' );
register_meta( 'comment', 'flagged', $args );
function check_logged_in(){
return is_user_logged_in();
However, I don't want them to be able to edit the comment itself so `current_user_can( 'edit_comment' )` should return false.
So that's the use case.
What happens at the moment is, well, no one can update the comment because there's no edit_comment_meta capability. But it's not a problem making the capabilities work like that.
However, `edit_post_meta` currently doesn't work like that. For `current_user_can( 'edit_post_meta' )` to return true, a user also has to have the `edit_post` capability. It's straightforward to change, but does have one backwards incompatibility: if someone is using current_user_can( 'edit_post_meta' ) with a registered meta key which has an auth_callback that returns true but they really ''don't'' want the person to update the post meta so are relying on the fact that they don't have the edit_post capability, then that will change and that person will be able to update the post meta. It's a slightly convoluted edge case, admittedly.
Attached is a patch that shows how it would work with unit tests.
" tharsheblows
Next Release 38851 WP_User_Query cannot retrieve multisite users who have not been assigned a role on a site Users normal normal 4.8 defect (bug) new 2016-11-18T15:11:32Z 2016-12-04T18:58:48Z "If you add a user to a multisite at network level, but do not proceed to assign them a role on a site within the network, `WP_User_Query` cannot retrieve those users (even if the query is run at network level), as they have no associated `wp_capabilities` meta_key.
To reproduce the problem:
1) Add a user to a multisite via Network Admin > Users > Add New.
2) Run a WP_User_Query at network level (e.g. by doing something like:
add_action('load-users.php', 'myAction');
function myAction()
$screen = get_current_screen();
if( $screen->base === 'users-network' {
$query = new WP_User_Query();
$users = $query->results;
The returned results will not include the user added in step 1. In fact, it will only return users who have capabilities set on the first site in the network, even though this query is not occurring at site level.
This could be fixed by allowing something like `'blog_id' => 'all'` in a `WP_User_Query`." robdxw
Next Release 39643 WP_User_Query does not allow search_fields to use display_name Users trunk normal normal 4.8 defect (bug) new has-patch 2017-01-19T22:34:31Z 2017-01-21T05:14:39Z "'''Expected Behavior:'''
The following query:
'search_columns' => 'display_name',
should search the users table and ONLY look at the column 'display_name'.
'''Observed problematic behavior:'''
During the prepare_query method, the search column parameter gets reset to the default value because of this line (around line 526) which appears to be filtering the allowed values for safety:
parese_request()` we have:
$self = $_SERVER['PHP_SELF'];
$home_path = trim( parse_url( home_url(), PHP_URL_PATH ), '/' );
$home_path_regex = sprintf( '|^%s|i', preg_quote( $home_path, '|' ) );
// Trim path info from the end and the leading home path from the
// front. For path info requests, this leaves us with the requesting
// filename, if any. For 404 requests, this leaves us with the
// requested permalink.
$req_uri = str_replace($pathinfo, '', $req_uri);
$req_uri = trim($req_uri, '/');
$req_uri = preg_replace( $home_path_regex, '', $req_uri );
$req_uri = trim($req_uri, '/');
$pathinfo = trim($pathinfo, '/');
$pathinfo = preg_replace( $home_path_regex, '', $pathinfo );
$pathinfo = trim($pathinfo, '/');
$self = trim($self, '/');
$self = preg_replace( $home_path_regex, '', $self );
$self = trim($self, '/');
This ends up with: `$req_uri = $self = non-existent`
Later in the same function we have:
// If req_uri is empty or if it is a request for ourself, unset error.
if ( empty($request) || $req_uri == $self || strpos($_SERVER['PHP_SELF'], 'wp-admin/') !== false ) {
unset( $error, $_GET['error'] );
if ( isset($perma_query_vars) && strpos($_SERVER['PHP_SELF'], 'wp-admin/') !== false )
unset( $perma_query_vars );
$this->did_permalink = false;
Here because `$req_uri == $self` this code unsets the 404 which subsequently results in the front page being loaded rather than the 404 page
I did some further investigation and this appears to only happen on multisite installs. If I take a normal wordpress install and set `$_SERVER['PHP_SELF'] = ''` the 404's work as normal.
" l3rady
Future Releases 17376 Multisite Subfolders and bunk /wp-admin areas Bootstrap/Load normal normal Future Release defect (bug) new has-patch 2011-05-11T15:07:38Z 2016-04-26T16:48:47Z "On a multisite installation with subfolders, navigating to:
loads a dashboard and maintains the i-dont-exist in the url. That part exists if i navigate to themes and/or plugin pages. However, I'm actually altering the base site.
This can be quite confusing if someone makes a typo in a sitename and they end up changing the base site (like happened to us) :(" MadtownLems
Future Releases 19455 "The ""magic_quotes_sybase"" Problem" johnbillion Bootstrap/Load normal normal Future Release defect (bug) reopened 2011-12-06T10:13:21Z 2015-11-18T15:03:45Z "
Post A Post, titled (in the double quote) : `""Charlie's little cat""`
It will become (in the double quote) : `""Charlie''s little cat""`
Notice that, single quote become double quotes!!
YES , My 'magic_quotes_gpc' and 'magic_quotes_sybase' are enabled!
Here is The PHP.NET links: http://php.net/manual/en/security.magicquotes.disabling.php" summerblue
Future Releases 25691 Refactor StringExtractor nbachiyski Build/Test Tools 3.8 normal normal Future Release defect (bug) assigned 2013-10-25T00:59:03Z 2016-04-26T21:37:47Z There are two huge and very logic-heavy methods: `find_function_calls` and `entry_from_call`. We must break them in smaller ones and make them more digestible. nbachiyski
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 2015-10-03T20:41:16Z "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 32848 Null values for Update Options does not reset in $all_options Cache API 4.2.2 normal normal Awaiting Review defect (bug) new has-patch 2015-06-30T22:04:47Z 2015-07-01T17:45:38Z "This is a fun, extremely niche case.
We were using the Settings API to save out options for a plugin when we came across a really frustrating scenario. Half the time our setting was returning values that were not accurate to the setting that was stored in the database and in cache.
Come to find, the value being returned from wp_load_alloptions was incorrect while every other instance was correct. In our case, these values were in the database, memcache, and the single value in wp-object-cache.
On [https://core.trac.wordpress.org/browser/tags/4.2.2/src/wp-includes/option.php#L319 ""line 319 of option.php""], we're using isset to check the value in the array. This returns false if the value is NULL. This leads to all kinds of sadness.
I would propose we instead use `array_key_exists` here to ensure we're getting true if the key is present in the array at all. " MikeNGarrett
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 2015-03-07T12:55:59Z "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 23290 When using switch_to_blog() with a persistent object cache that lacks wp_cache_switch_to_blog() support, non-persistent groups are not maintained Cache API 3.0 low normal Future Release defect (bug) new has-patch 2013-01-25T05:28:44Z 2015-10-13T03:37:18Z If you're using a persistent object cache that lacks the new `wp_cache_switch_to_blog()` support, WordPress core `else`s into a complete cache clobbering branch. It is smart about grabbing the global groups and re-adding those after `wp_cache_init()` is called, but it doesn't do the same for non-persistent groups. Those are a hardcoded array. So if you call `switch_to_blog()`, you would lose any custom-added non-persistent groups. markjaquith
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 2016-08-30T22:43:02Z "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 17661 Appending date & author based query vars to a permalink overrides the permalink Canonical 3.1 normal normal Future Release defect (bug) new has-patch 2011-06-02T11:05:05Z 2015-10-03T20:44:44Z "Some canonical code branches are not properly accounting for extra query variables being specified via the url.
For example, these url's are not handled properly:
/2008/?author=1 redirects to /author/admin/
/author/admin/?year=2008 redirects to /year/2008/
/category/uncategorized/?year=2008 redirects to /2008/
This happens with most date based branches, as once a higher priority canonical rule is hit, the permalink component is ignored.
The canonical code includes a branch to add any ""forgotten"" `$_GET` variables back onto the url, however this doesn't help when it's the rewritten variables are being lost." dd32
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 2017-02-17T03:18:48Z "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 23602 "Incorrect canonical redirect if p=123 query argument present in ""paged"" archives" Canonical 3.5 normal normal Future Release defect (bug) new 2013-02-25T08:34:19Z 2015-10-13T04:59:09Z "URLs that include `page/n` AND `p=n` query variable, such as:
will issue a 301 redirect to the homepage. This is being reported as incorrect behaviour in Google Webmaster Tools, because:
The target URL does not exist and your server is not returning a 404 (file not found) error.
Your server is redirecting requests for a non-existent page, instead of returning a 404 response code. This creates a poor experience for searchers and search engines.
A fix would be to strip the `p=` query variable and redirect to the paged archive.
" kasparsd
Future Releases 10690 WordPress does not support non-ascii characters in the domain name markjaquith Canonical 2.8.4 normal normal Awaiting Review defect (bug) reopened 2009-08-26T18:26:13Z 2016-02-04T23:36:14Z WordPress' clean_url() strips out most characters, which are non-ascii for security reasons. This is causing problems, if you want to run a WordPress blog on a domain containing non-ascii-characters (e.g. müller.com), because WordPress generates wrong URLs on redirects. paddya
Future Releases 20386 "Year permalinks ""win"" against category permalinks" Canonical normal normal Future Release defect (bug) new 2012-04-07T05:20:55Z 2015-09-23T21:20:22Z "We need to decide whether category permalinks should take priority over year permalinks.
e.g. /2008/?category_name=cat-a
Should that stay the same, or redirect to:
We have a unit test which is failing." markjaquith
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 2016-03-23T21:54:43Z "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 2016-10-07T17:08:43Z "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 10543 Incorrect (non-UTF-8) character handling in tag's name and slug westi* Charset 2.8.2 normal normal Future Release defect (bug) accepted dev-feedback 2009-08-04T05:26:11Z 2015-12-03T20:03:42Z "Incorrect (non-UTF-8) character tag's name and slug are handled in different way: name is truncated on 1st such character, and in slug they are just removed (no truncation). WP should handle both in the same way - drop invalid characters, instead of truncation.
I found this issue recently. One of the Polish programs for adding posts to the Wordpresses does not encode tags in UTF-8 - it left them in ISO-8859-2. I notified author of this bug. Unfortunately there are many copies around, so it may take a long time before everyone upgrade." sirzooro
Future Releases 35951 remove_accents() doesn't escape Unicode NFD characters johnbillion Charset normal normal Future Release defect (bug) assigned 2016-02-25T16:18:53Z 2016-10-20T15:36:07Z "OS X filesystem HFS uses unicode '''NFD''' instead of '''NFC'''. This causes all sorts of problems when uploaded files with accents are moved between environments or if the site is developed in OS X machine and then pushed to production.
I'm trying to solve this problem using remove_accents() function and sanitizing all uploaded files. But in my test machine `remove_accents()` doesn't do anything for NFD characters.
It should use something like `Normalizer::normalize()` to avoid this. But sadly Normalizer isn't available in all systems.
I included zip file which contains nfd characters. If you open it in linux machine you can see a small difference between the characters and ""normal"" utf-8 accented characters like: '''öäå'''.
Try to copy the contents and run it through `remove_accents('content')` and you can see that nothing is changed.
If you have Normalizer available you can test that `remove_accent()` if characters are first filtered by running Normalizer for example: `remove_accents(Normalizer::normalize('content'))`
I realize this doesn't concern native english speaking countries but it's really big annoyance for the rest of us." onnimonni
Future Releases 36208 Comment queries should ignore comments associated with non-active custom post types Comments 4.4 normal normal Future Release defect (bug) new 2016-03-11T13:50:28Z 2016-11-18T01:11:58Z "As of 4.4 we introduced the `_doing_it_wrong()` (r34091) when checking meta capabilities on custom post types that aren't registered.
This also spread and affected comments, primarily on the dashboard where we show comments and try to add links for these and check the users capability against them, they will produce this wonderful output:
> PHP Notice: map_meta_cap was called incorrectly. The post type shop_order is not registered, so it may not be reliable to check the capability ""edit_post"" against a post of that type. Please see Debugging in WordPress for more information. (This message was added in version 4.4.0.) in /wordpress/wp-includes/functions.php on line 3827
Ideally, `WP_Comment_Query` should bypass comments associated to non-existing post types as well.
In the attached patch I've introduced both `post_type__in` and `post_type__not_in` which accepts an array of post type string names.
I've also added the default value for `post_type__in` to `get_post_types()`, as by default you'd never want to query for non-existing data any way, but this allows the query to be overwritten via filters, or directly with a new construct for those who have the need.
I am wondering if the use of `post_type = 'any'` would need to short-circuit the new arguments to avoid breaking BC (current tests all pass with the patch applied though) ?
Related #16956
What this looks like (from #34918):
It also shows up on the Dashboard in the comments widget:
[[Image(http://crosseyedeveloper.com/wp-content/uploads/2015/12/commentcap21.jpg)]]" Clorith
Future Releases 36409 Comments number is wrong Comments normal normal Future Release defect (bug) new has-patch 2016-04-04T14:21:26Z 2016-05-22T03:05:33Z "Hi,
the comment number return the number of approved comments, this means all approved comments even those are replies to unapproved comments, for example if a user post comment and people replied to it, then the admin decide to hide this parent comment by disapproving it, the comment number will decrease only by one and keeping counting the hidden replies
So there are two option to fix that :
1. Hold/Disapprove all children when disapproving the parent.
2. Recalculate the comment number and excluding comments has an unapproved parent.
Sidati" sidati
Future Releases 13792 Invalid reply link from comment admin when comment nested level > max Comments 2.9.2 normal normal Future Release defect (bug) reopened has-patch 2010-06-09T07:05:56Z 2015-12-03T19:50:32Z "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 35805 Reverse page order in wp_list_comments() with newest comments first boonebgorges Comments 4.4.2 normal normal Future Release defect (bug) reviewing 2016-02-12T00:21:26Z 2016-04-09T14:11:13Z "Hey there,
since wp 4.4 there were lots of bugs in the wp_list_comments()-function. Some of them are already fixed, now I found another one.
If you change the comments order from default (oldest first) to newest first, the page order is wrong (reverse page order).
== Example ==
You have 4 pages by sending following param you get these pages:
page=1 -> 4
page=2 -> 3
page=3 -> 2
page=4 -> 1
== How I call this function ==
Inside the post-loop I'm calling:
got lower: '; var_dump($meta); } $meta = get_post_meta ($post->ID, '_ALLDAY'); if ($meta ) { echo '
got upper: '; var_dump($meta); } update_post_meta (21, '_allday','Tried to update lowercase'); $meta = get_post_meta ($post->ID, '_allday'); if ($meta ) { echo '
got lower: '; var_dump($meta); } else { echo '
Tried to get lower but no go'; } $meta = get_post_meta ($post->ID, '_ALLDAY'); if ($meta ) { echo '
Still have upper: '; var_dump($meta); } }}} Output of above: got upper: array(1) { [0]=> string(14) ""tis the upper."" } Tried to get lower but no go Still have upper: array(1) { [0]=> string(25) ""Tried to update lowercase"" } " anmari Future Releases 37508 wpdb->result instance should be checked `mysqli_num_fields` in `load_col_info()` Database 3.9 normal normal Future Release defect (bug) new has-patch 2016-07-29T07:33:53Z 2016-10-11T12:03:50Z "In `wpdb::load_col_info()` the function `mysqli_num_fields()` is called passing `$this->result` without any check on this property value. The problem is that function has a type hint to `mysqli_result` (see http://php.net/manual/en/mysqli-result.field-count.php), but `$this->result` may be `false`. Just like in other places in the same class, the function should check that `$this->result instanceof mysqli_result` before calling `mysqli_num_fields()`." giuseppe.mazzapica Future Releases 37411 Add more formats to wp_maybe_decline_date() SergeyBiryukov* Date/Time 4.4 normal normal Future Release defect (bug) accepted has-patch 2016-07-19T15:28:48Z 2016-10-31T21:19:40Z "In some themes, date format is not localized (see an [https://themes.trac.wordpress.org/browser/sadakalo/1.7.0/content.php?marks=13#L9 example] in Sadakalo theme). Formats like `'F jS Y'` don't make a lot of sense for languages with declensions, which generally use `'j F Y'` (where F requires genitive case). We could improve the situation by adding more formats to `wp_maybe_decline_date()` introduced in #11226." SergeyBiryukov Future Releases 25399 XML-RPC and wp-mail.php struggle with timezone offsets Date/Time normal normal Future Release defect (bug) new 2013-09-23T18:48:45Z 2016-01-03T21:00:08Z See iso8601_to_datetime() and wp-mail.php, and #20328 for background. nacin Future Releases 25768 date_i18n() is wrong for certain formats, escapes sequences and daylight saving time Date/Time 3.7.1 normal normal Future Release defect (bug) new dev-feedback 2013-10-30T11:08:20Z 2015-12-03T15:31:34Z "{{{date_i18n()}}} returns wrong values in the following cases: * If time zone is not GMT {{{date_i18n( 'c', time() )}}} does not return the correct difference to GMT part, e.g., 2013-10-30T14:00:00+00:00 instead of 2013-10-30T14:00:00+01:00. * The time zone offset is sometimes wrong: {{{ /* * Test is called in time zone Europe/Berlin at a date where daylight saving time is off! * (Daylight saving time in Europe/Berlin was switched off at 2013-10-27) */ // results 2013-10-29T22:15:03+01:00 while daylight saving time (Europe/Berlin) is off; result is correct echo(date_i18n('Y-m-d\TH:i:sP', 1383084903)); // results 2013-10-11T19:37:20+01:00 while daylight saving time (Europe/Berlin) is on; result is wrong! should be +02:00! echo(date_i18n('Y-m-d\TH:i:sP', 1381520240)); }}} * {{{date_i18n( 'D | \D | \\D | \\\D | \\\\D | \\\\\D | \\\\\\D' )}}} does not escaping properly. The implementation of {{{date_i18n()}}} is not very well at all. Therefore it was completely rewritten solving the issues above. Performance should be better too. I added some tests too. This ticket is a result of the discussion in ticket #20973. You can find a more detailed discussion there." raubvogel Future Releases 20973 date_i18n() produces invalid output for shorthand formats Date/Time 3.4 normal normal Awaiting Review defect (bug) reopened dev-feedback 2012-06-15T13:39:50Z 2016-10-10T21:32:30Z "date_i18n() function relies on parsing passed format to make adjustments. However shorthand formats are not handled and produce invalid output. Example: {{{ var_dump( date_i18n( 'Y-m-d\TH:i:sP', time() ) ); // 2012-06-15T13:34:03+03:00 << ok var_dump( date_i18n( DATE_W3C, time() ) ); // 2012-06-15T13:34:03+03:00 << ok var_dump( date_i18n( 'c', time() ) ); // 2012-06-15T13:34:03+00:00 << broken time zone! }}} Hook-level fix: {{{ add_filter( 'date_i18n', 'fix_c_time_format', 10, 3 ); function fix_c_time_format( $date, $format, $timestamp ) { if ( 'c' == $format ) $date = date_i18n( DATE_W3C, $timestamp ); return $date; } }}} See [http://wordpress.stackexchange.com/q/54700/847 Why time functions show invalid time zone when using 'c' time format?] Possibly related (can't say for sure from description) #13538" Rarst Future Releases 25347 mysql2date() limitation for scheduled posts Date/Time 3.0 normal normal Awaiting Review defect (bug) new 2013-09-18T00:21:21Z 2015-10-04T02:10:02Z "The latest [http://codex.wordpress.org/Theme_Unit_Test Theme Unit Test] data is [https://wpcom-themes.svn.automattic.com/demo/theme-unit-test-data.xml available here] for theme reviewers (and theme developers) to test against. There is a post scheduled for year 2050. During the import process in `wp_insert_post` there is this snippet: {{{ } elseif( 'future' == $post_status ) { $now = gmdate('Y-m-d H:i:59'); if ( mysql2date('U', $post_date_gmt, false) <= mysql2date('U', $now, false) ) $post_status = 'publish'; }}} `mysql2date` uses `strtotime` and the future date could return `false` which would update the status of the future post to `publish`. This is probably related to the date limitation for 32-bit systems, as described [http://php.net/manual/en/function.strtotime.php on php.net]: {{{ The valid range of a timestamp is typically from Fri, 13 Dec 1901 20:45:54 UTC to Tue, 19 Jan 2038 03:14:07 UTC. (These are the dates that correspond to the minimum and maximum values for a 32-bit signed integer.) }}} Since that's still fine given the current date, it might be a minor issue, but it's being exposed in a use case such as the import process where a future post is being published instead while migrating to another site. For that specific use case scenario adding a non-false check would help, but is probably an overhead: {{{ if ( false !== mysql2date('U', $post_date_gmt, false) && mysql2date('U', $post_date_gmt, false) <= mysql2date('U', $now, false) ) }}}" nofearinc Future Releases 37336 Pre-existing page with slug /embed/ does not work as described Embeds 4.5 normal normal Awaiting Review defect (bug) new 2016-07-12T02:22:56Z 2016-07-12T07:17:11Z "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 21872 RSS Widget, and all of fetch_feed() I believe, forces its own feed order of Post Date DESC External Libraries normal normal Awaiting Review defect (bug) new 2012-09-11T15:25:32Z 2015-12-03T19:08:34Z "My events management plugin wanted to provide Upcoming Events via RSS. I wrote a pre_get_posts filter to modify the order and orderby of the event's feed to be Ascending based on a the event's start date, and it was good. Good, however, for only as long as you don't subscribe to the feed using WordPress (whether it be the event site or one on a totally different network). WordPress, upon fetching the feed, always re-sorts the posts according to the post date. Subscribing with something like iGoogle, will show me my upcoming events in the order that I've coded. Is this an intentional design decision? It feels to me that the generating site should be responsible for the order of the feed, and WordPress should respect the generating site's wishes and present the feeds in the order it is given." madtownlems Future Releases 16747 'feedtype_enclosure' hooks not triggered without custom field Feeds 1.5 normal normal Awaiting Review defect (bug) new has-patch 2011-03-04T13:42:07Z 2015-12-23T18:48:29Z "file: '''wp-includes/feed.php''', functions: '''atom_enclosure()''' and '''rss_enclosure()''' If a ""enclosure"" custom field is not provided, the ''atom_enclosure'' and ''rss_enclosure'' filters are never triggered (because they're inside an if statement). Wouldn't it make sense to replace this ... {{{ function atom_enclosure() { if ( post_password_required() ) return; foreach ( (array) get_post_custom() as $key => $val ) { if ($key == 'enclosure') { foreach ( (array) $val as $enc ) { $enclosure = split(""\n"", $enc); echo apply_filters('atom_enclosure', '' . ""\n""); } } } } }}} ... with this ... {{{ function atom_enclosure() { if ( post_password_required() ) return; $output = ''; foreach ( (array) get_post_custom() as $key => $val ) { if ($key == 'enclosure') { foreach ( (array) $val as $enc ) { $enclosure = split(""\n"", $enc); $output = '' . '\n'; } } } echo apply_filters('atom_enclosure',$output); } }}} ... so that those functions can be hooked via plugins, even if the custom field doesn't exist? ''In my particular case, I wanted to use a different--already existing--custom field name to pull the url from, but I couldn't hook '''atom_enclosure()''' because '''apply_filters()''' is only triggered if the ""enclosure"" custom field name exists.''" tcloninger Future Releases 21753 Feed excerpts are missing important filter formatting Feeds 3.4.1 normal normal Awaiting Review defect (bug) new has-patch 2012-08-31T14:20:56Z 2016-02-10T23:54:23Z "Excerpts included in feeds are missing important formatting because the relevant filters are not applied (e.g. wpautop). In file wp-includes/feed.php, function the_excerpt_rss() does not apply the same filters as the_excerpt() whilst results in lost formatting instructions. By comparison, function the_content_feed() ensures that the same filters declared for the_content() are applied. A suggested patch is attached. Note that for symmetry between the_excerpt_rss() and the_content_feed() this patch also removes the (unnecessary?) filter ent2ncr() from the_excerpt_rss() and retains the (controversial?) escaping for CDATA blocks (see #3670). A few related issues are worth mentioning. Firstly, shortcodes are still not applied to excerpts (see #7093). Also, the (obsolete?) RDF feed does not make use of a CDATA block unlike those for RSS, RSS2 and Atom (see #20888). Finally, a similar problem occurs with comment text in feeds (see #16466)." mdgl 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 2016-02-11T00:07:02Z "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 33591 Media File Missing Length Causes Wordpress Atom Feed to Be Invalid stevenkword Feeds 4.2.4 normal normal Awaiting Review defect (bug) assigned 2015-08-28T21:14:56Z 2015-12-26T19:11:05Z "In wp-includes\feed.php, the atom_enclosure() function can produce invalid XML, which will break some feed readers and XML parsers that might digest the feed. This happens when the get_post_custom() function returns data that doesn't include all the metadata that it ought to for a given enclosure. This line- {{{$enclosure = explode(""\n"", $enc);}}} ...creates an array by splitting the enclosure meta information on newline characters (""\n""). Then, this line: {{{ echo apply_filters( 'atom_enclosure', '' . ""\n"" ); }}} ...assumes that the url will be at position 0 in the array, the length in position 1, and the type in position 2. If the length line is simply missing, as is the case for a particular post I have on my blog, then the next line in the metadata is some kind of configuration data that looks something like this: {{{ a:1:{s:8:""duration"";s:8:""00:05:29"";}"" } }}} This breaks the feed in a couple of ways. First, because the length attribute is missing from the metadata, the length attribute of the resulting link tag will read ""audio/mpeg"" (or whatever type of file it is). Second, it tries to put a type that contains quotes, which ends the attribute's value early and creates a broken link tag. {{{ }}} The broken link tag will break some feed readers and other XML parsers that are pointed at the blog's ATOM feed. The same issue may also affect the rss_enclosure function in feed.php, though I haven't tested it for that case. I'm not sure whether the more important bug bug is that that the ATOM feed breaks if the length is missing, or if the bug is, ""Hey, the length meta data is missing for this object, how did THAT happen?"" Still, it would seem that the assumption that the length will be at the second (or 1th) position in the array is not a safe one. At the very least, it might be good to encode the output so that double quotes from the metadata don't break the XML of the feed? Also, any pointers on sleuthing out why the metadata is missing would be much appreciated. At the very least, it seems prudent to wrap the length (contents of {{{$enclosure[1]}}}) and the type ({{{$enclosure[2]}}}) in the htmlspecialchars() function, the same way the href attribute is." jonnybot Future Releases 20888 RDF Feed validation problems. Feeds 3.3.2 normal normal Awaiting Review defect (bug) reopened has-patch 2012-06-08T11:05:19Z 2016-05-05T20:13:59Z "The RDF feed produced by feed-rdf.php produced validation errors due to description either not encoded correctly or not wrapped in CDATA tags. To reproduce view a RDF feed: http://en.blog.wordpress.com/feed/rdf/ To see the validation errors: http://validator.w3.org/feed/check.cgi?url=http%3A%2F%2Fen.blog.wordpress.com%2Ffeed%2Frdf%2F Attached is a patch to fix this issue. " hootbah Future Releases 34128 Tests_Feed_RSS2::test_channel fails when WP_TESTS_TITLE contains an apostrophe Feeds normal normal Future Release defect (bug) new 2015-10-02T14:12:16Z 2016-05-03T19:58:15Z "If the site configuration contains an apostrophe in the site title, the test_channel unit fails. {{{ 1) Tests_Feed_RSS2::test_channel Failed asserting that two strings are equal. --- Expected +++ Actual @@ @@ -'Rob's Test Blog' +'Rob's Test Blog' }}} The happens with either of the following configurations: {{{ define( 'WP_TESTS_TITLE', 'Rob\'s Test Blog' ); }}} and {{{ define( 'WP_TESTS_TITLE', 'Rob's Test Blog' ); }}}" miqrogroove Future Releases 28616 ftp_fput should have a retry threshold Filesystem API 3.9 normal normal Awaiting Review defect (bug) new has-patch 2014-06-23T18:27:07Z 2016-10-04T08:39:28Z "In class-wp-filesystem-ftpext.php in put_contents(), ftp_fput() is called to transfer a file to the FTP server. The first problem is that warnings are suppressed, so the user never knows that this is the location where something went wrong. The broader problem is that a single transient network failure between the web server and FTP server causes this call to fail. Well, that would be not a big problem if the user's operation were a single call. However, this function is used by Wordpress auto-upgrade when direct file access fails. For each file in the Wordpress distribution, this function is called to transfer it to the FTP server. As the default Wordpress distribution gets more and more bloated, the number of calls increases proportionally, and the likelihood of at least one FTP transaction failing increases. A single failure aborts the entire Wordpress upgrade. It seems reasonable to at least retry up to (say) three times the ftp_fput() call before returning an error to the higher level and aborting a large process such as Wordpress upgrade which is using FTP as backing for the filesystem abstraction layer." runderwo Future Releases 31066 wp_upload_dir calls wp_mkdir_p on each invocation Filesystem API normal normal Future Release defect (bug) new close 2015-01-20T06:27:02Z 2016-02-18T13:33:36Z "Every time `wp_upload_dir` is called, `wp_mkdir_p` is also called. For normal filesystems, this is not a huge issue, but using external filesystems (S3, etc) potentially means an external request on every call. Ideally, I'd actually like to avoid calling `wp_mkdir_p` at all there. S3 (along with a few other external FSes) doesn't actually have a concept of directories; rather they're just part of the filename. Adding a `upload_dir_requires_creation` filter to `wp_upload_dir` would help with this, as plugins could then switch this off if they know the underlying FS doesn't need it, or they already handle it themselves." rmccue Future Releases 4539 Abbreviated year followed by punctuation or markup doesn't texturize jmstacey Formatting 2.5 low normal Awaiting Review defect (bug) reopened has-patch 2007-06-26T03:36:36Z 2016-09-10T08:07:30Z "An abbreviated year followed by punctuation or markup doesn't texturize properly. e.g. (Bruce Sterling, '97) is texturized as (Bruce Sterling, '97) when the apostrophe should be texturized as ' e.g.
"" [10]=> string(1) "" "" [11]=> string(464) """" [12]=> string(10) ""checkstyle"" [13]=> string(9) """" [14]=> string(0) """" [15]=> string(4) ""
"" [18]=> string(72) "" (?:s+)(?:(/*([^*]|[rn]|(*+([^*/]|[rn])))**+/)|(//(?!.*(CHECKSTYLE)).*))"" [19]=> string(6) ""
"" [20]=> string(19) "" [/code-highlight] "" [21]=> string(3) ""
) 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 27350 Invalid HTML Output Formatting 3.8 normal normal Awaiting Review defect (bug) new dev-feedback 2014-03-11T08:19:48Z 2015-12-03T19:29:28Z "Paste into editor's Text tab: {{{
I saw it here, I instantly knew what I wanted. I love my new woven wood
- Ginny Good
style=""width: 120px; height: 92px; text-align: left; margin-left: auto; margin-right: auto;""
border=""1"" cellpadding=""7"" cellspacing=""2"">
I saw it here, I instantly knew what I wanted. I love my new woven wood
- Ginny Good
"" [2]=> string(28) ""Some amount of useless text "" [3]=> string(11) """" [4]=> string(0) """" [5]=> string(4) """" [6]=> string(1) "" "" [7]=> string(3) ""
string(121) ""[code-highlight line-numbers=""table"" linenostart=""53"" highlight-lines=""1,3,8"" style=""native"" lang=""html+php"" pyg-id=""1"" ]""
string(6) ""
"" [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 31695 Enclosing oEmbed using `embed_oembed_html` is generating invalid HTML Formatting normal normal Awaiting Review defect (bug) new 2015-03-19T16:26:12Z 2016-01-05T19:00:19Z "This bug was detected when trying to preview a post that had a Twitter oembed URL. There was no error on the log, and the previewed content was empty ( `the_content()` was printing an empty string ). After some debugging, I found that something was adding an extra `
` and never closing that tag, on the oembed returned markup, right before ` }}} I did some tracing and found out that it was `wpautop` fault. Even though `WP_oEmbed::_strip_newlines()` was successfully stripping the new lines from the returned oEmbed HTML, something was adding an extra newline before the `\s*|', '', $pee ); } }}} Now the oembed is fully functional and doesn't have that unclosed `
` tag: {{{
Lisbon with #WordPressVIP @ Terreiro do Paço http://instagram.com/p/vGw5IchocB/
— Henrique Mouta (@vaurdan) November 7, 2014
) tags around the comment and for multi-line comments line breaks (
tags are generated when shortcodes are followed by HTML tags and wpautop is enabled Formatting 3.4.1 normal normal Future Release defect (bug) new has-patch 2012-08-26T06:58:21Z 2015-10-13T04:33:17Z "This bug was encountered in separate plugins, but it seems that its source is in the core: http://wordpress.stackexchange.com/questions/21414/wordpress-wpautop-shortcode-generating-invalid-markup https://github.com/pods-framework/pods/issues/271" dandv Future Releases 25785 Unexpected Paragraph Formatting Within a Div Container Formatting 3.7 normal normal Future Release defect (bug) new 2013-10-31T02:01:15Z 2015-12-03T17:46:28Z "Though HTML mode in WordPress allows for the user to add in their own CSS styling and HTML content formatting if necessary, its normal behavior also makes it auto-format paragraph breaks without the user's input of paragraph tags. This is EXPECTED behavior. I have discovered that in this specific manner of formatting when writing a post or page (note the LACK of spacing between the div tag and the content and the multiple paragraphs): {{{
Second paragraph.}}} Correct HTML should look like this: {{{ }}} I think the same sitiuation occurs for DEL tag. " misieg772 Future Releases 20368 htmlspecialchars() returns empty string for non-UTF-8 input in PHP 5.4 Formatting normal major Awaiting Review defect (bug) new 2012-04-05T12:43:23Z 2015-12-03T19:07:49Z "The default value of the input `$encoding` parameter for `htmlspecialchars()` changed to UTF-8 in PHP 5.4. The prior default was ISO-8859-1. The function's UTF-8 handler checks the input, returning an empty string if the input isn't valid UTF-8. WordPress will see the UTF-8 validator kicking because most of the `htmlspecialchars()` calls don't use the `$encoding` parameter. This will cause major problems for sites that have a `DB_CHARSET` other than `utf8`. [http://article.gmane.org/gmane.comp.php.devel/71783 Posting 58859 to php-internals] by Rasmus gives a clear example of the problem. Here is a link to [http://thread.gmane.org/gmane.comp.php.devel/71777 view the whole thread], starting with posting 58853). Creating two centralized functions is an approach for resolving this problem. This route is simpler and easier to maintain than adding the parameters to each `htmlspecialchars()` call throughout the code base. 1. `wp_hsc_db()` for safely displaying database results. Uses `DB_CHARSET` to calculate the appropriate `$encoding` parameter. MySQL's character set names are not equivalent to the values PHP is looking for in the `$encoding` parameter. Please see the `hsc_db()` method in the [http://plugins.svn.wordpress.org/login-security-solution/trunk/login-security-solution.php Login Security Solution plugin] for a mapping of the valid options. 2. `wp_hsc_utf8()` for safely displaying strings known to be saved as UTF-8, such as error messages written in core. Uses `UTF-8` as the `$encoding` parameter. Some calls in core use the `$flags` parameter, so these new functions will need the parameter too. The default should be `ENT_COMPAT`, which works under PHP 5.2, 5.3 and 5.4. It may be suggested that WP use `htmlspecialchar()`'s auto-detection option (by passing an empty string to the `$encoding` parameter). This is not advisable because it can produce inconsistent behavior. Even the PHP manual says this route is not recommended." convissor Future Releases 30597 wp_filter_post_kses mangles URLs with colons in them Formatting 4.0 normal normal Awaiting Review defect (bug) new 2014-12-04T18:34:40Z 2015-09-20T18:58:32Z "Try to save this entirely valid post content: {{{ watch what happens }}} The KSES logic is overly aggressive and strips the URL. It's getting confused by the colon. Might be related to #24663" rkaiser0324 Future Releases 34406 wp_kses_hair is too stringent redux Formatting 1.5 normal normal Awaiting Review defect (bug) new has-patch 2015-10-23T03:25:07Z 2016-01-08T21:28:29Z "Attributes from custom xml name spaces may use numbers, underscores, en dashes, and em dashes, but the regex used inside `wp_kses_hair()` doesn't allow them through. Technically, there are other allowed characters, but that's probably getting into very fringe edge-case territory. Admittedly, en and em dashes may be edge-case territory as well, so two patches are provided: one allowing numbers and underscores, and one additionally allowing en and em dashes. Related: #17847 [http://www.w3.org/TR/html-markup/syntax.html#attribute-name Here's a link to the W3C spec for reference.]" travisnorthcutt Future Releases 36998 wp_sanitize_redirect() strips spaces out of URLs instead of encoding them Formatting normal normal Future Release defect (bug) new 2016-06-02T11:20:31Z 2016-06-02T12:37:31Z "This is similar to #17052, #10690 and one or two others that relate to non-ASCII characters being stripped from URLs, however I couldn't find a ticket that relates directly to spaces being stripped out in the `wp_sanitize_redirect()` function. This function is called when using `wp_redirect()` or `wp_safe_redirect()` and, when it is called, it strips out the spaces from URLs instead of encoding them as `%20` (which I would think would be the correct way of doing things). This results in unexpected behaviour and broken redirects when passing a URL with spaces to `wp_redirect()`. The cause for this will likely be the same as what was fixed in #23605 for the `esc_url()` function, but this is in a separate location so I'm not 100% if the same fix will apply. The fix for `esc_url()` was to simply add `$url = str_replace( ' ', '%20', $url );`, which works just fine, but the case in `wp_sanitize_redirect()` may be a bit different (although I don't see why it would be)." hlashbrooke Future Releases 4298 wpautop bugs markjaquith Formatting 2.7 low minor Future Release defect (bug) reopened 2007-05-19T22:14:10Z 2015-10-05T18:00:40Z "wpautop should at least ignore multiline html tags, and possibly ignore any area enclosed within html. {{{
`, but the corresponding opening and closing tags won't exist. For example, `
` 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: {{{
more text
` 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: {{{
more text
new line
$pee = preg_replace('|(?)\s*\n|', ""
\n"", $pee); echo $pee; // outputs
\n }}} '''Solution:''' Use [\r\n\t ] rather than \s." tenpura Future Releases 29913 wptexturize should handle broken HTML consistently Formatting 1.5 normal minor Awaiting Review defect (bug) new 2014-10-10T00:38:40Z 2015-12-03T17:41:25Z "Spunoff from ticket:29557#comment:93 because it's not that important. When encountering broken HTML, `wptexturize()` should match web browser behavior, without getting too complicated. This bug is for: 1. unclosed comments: ` for page_on_front if ( !empty($qv['paged']) ) { $qv['page'] = $qv['paged']; unset($qv['paged']); } } } }}} Add `&& !$this->is_paged` check." sheo13666q Future Releases 30911 Overhaul post_status logic in WP_Query Query normal normal Future Release defect (bug) new 2015-01-05T15:24:11Z 2016-05-24T18:17:23Z "`WP_Query` filters based on post_status in two different places: 1. When building the main SQL query (`SELECT ID FROM $wpdb->posts`...). https://core.trac.wordpress.org/browser/tags/4.1/src/wp-includes/query.php#L2946 This block is responsible for parsing the 'post_status' query var, and rectifying these passed post_statuses with the 'perm' param, the logged-in user's permissions, and whether `is_admin()`. (The ability to query by 'post_status' dates from [5575].) 2. On `single` queries (`is_page()`, `is_single()`), additional filtering happens *after* the query. https://core.trac.wordpress.org/browser/tags/4.1/src/wp-includes/query.php#L3511 The intended purpose of this block is to ensure that Preview works (since posts being previewed generally are not published). The current incarnation of the preview logic (ie, living in `WP_Query`) was introduced in [2523]. These two 'post_status' blocks have two different purposes and two different histories, but they interact in a number of problematic ways. Just a few of the problems: a. Querying posts with 'fields=ids' means that the post ids are returned before the second filter block gets a chance to run. As a result, certain `WP_Query` objects (eg 'p=123&post_status=trash') can return different post IDs depending on whether you request 'fields=ids'. b. Values passed to the post_status parameter of `WP_Query` are sometimes overridden forcibly, based on logged-in user status. In an ideal world, `WP_Query` would not make any essential reference to the logged-in user. Realistically, we can't change some of this behavior for reasons having to do with backward compatibility. But there are places where the current user logic could be reworked so that it provides defaults, which can then be overridden by the params passed to `WP_Query`. Some relevant tickets: #28568, #29167 c. Filtering out non-previewable posts after the main query has taken place means doing more SQL queries than necessary in cases where post_status=draft and `is_single()`. d. Filtering out non-previewable posts after the main query has taken place can result in certain sorts of data leakage. See eg #30910. e. Having two separate blocks that filter results based on post_status makes unnecessarily complicated to fix post_status bugs. See eg #30530, #22001, #23309. My initial thought is that the second block should be removed. Preview logic should either be merged with the first block of post_status parsing logic that runs when building the main post query, or it should be moved into a separate query_var, which would then be passed when making a Preview request. In general, the challenge here is to ensure that the default post_status whitelist is properly sensitive to the permissions of the logged-in user - which sometimes means building clauses like `(post_status = 'publish' OR ( post_status = 'private' AND post_author = 123 ))`. I've started to write some unit tests that describe the (weird and complicated) existing behavior. See #29167 [31047]." boonebgorges Future Releases 34660 Query breaks when nopaging = false and posts_per_page = -1 Query 4.4 normal normal Future Release defect (bug) new has-patch 2015-11-11T16:06:20Z 2015-11-11T21:53:19Z "Whenever `nopaging = false` and `posts_per_page = -1`, the SQL query breaks because the LIMIT clause is set to: `LIMIT 0, -1` This patch ensures that `nopaging` is set to TRUE whenever `posts_per_page = -1`." mgibbs189 Future Releases 18513 Searching with explicit post types unsets page post type Query 3.2.1 normal normal Future Release defect (bug) new dev-feedback 2011-08-24T22:13:08Z 2015-10-03T22:03:05Z "Tested on WP 3.2.1, Twenty Eleven with no plugins, multisite. If I explicitly limit a search query via a GET request using an array of post_type values, the post_type for page is automatically excluded. To reproduce: * Do a search on a WP install (perhaps through a modified search form), such that the URL is like: http://example.com/?post_type[]=post&post_type[]=page&post_type[]=attachment&s=Test or http://example.com/?post_type[]=post&post_type[]=page&post_type[]=book&s=Test That's searching for ""Test"" on post, page and attachment/book post types. * Adding the following to a theme's functions.php: {{{ add_filter( 'pre_get_posts', 'wpcpt_search' ); /** * * @param array $query */ function wpcpt_search( $query ) { if ( ! $query->is_search ) return $query; print_r( $query->query_vars ); return $query; } }}} That spits out (and seemingly confirmed via the values shown in the Debug Bar plugin) the following at the beginning: {{{ Array ( [s] => Test [post_type] => Array ( [0] => post [2] => attachment ) }}} and only returns results for posts and attachments (or books). The fact that key 1 is missing makes me think that page was in the array at some point, but it's been unset, but I can't see where, or why, this might be done. (When no post_type is set, giving a post_type of 'any', which in turn gives all of the non-excluded_from_search post types, then page is one of the array values, and the search results correctly include pages.) " GaryJ Future Releases 27015 WP_Query::get_queried_object() does not always work in 'pre_get_posts' Query 3.8 normal normal Future Release defect (bug) new has-patch 2014-02-05T00:58:42Z 2015-07-07T15:53:21Z "Related: #26627 The referenced ticket fixes the situation for categories. Inline docs indicate the method returns objects for the following query types: '''category, tag, taxonomy, posts page, single post, page, author'''. Some of these work, some do not. This became apparent from the forums: http://wordpress.org/support/topic/get_queried_object-no-longer-working-with-pre_get_posts-and-pretty-permalinks/ Props jeich Test setup. Trunk at r27067 used. (and 3.7 for regression check) Default setup of fresh install except for the following as plugin: * Hook 'pre_get_posts' and dump get_queried_object return if it is_main_query * Add custom taxonomy and associate with posts * Register CPT Change permalink setting to complete CPT rewrite registration Also modify the DB as follows to test various query types: * Add a tag to the Hello World post. * Add a custom taxonomy term to the Hello World post. * Add a CPT post The site was browsed through various pages using the default (none) permalink, then the month and name permalink. The result of getting a queried object was recorded: || ||=no permalink =||=month and name=|| ||uncategorized category ||stdClass object ||stdClass object|| ||tag archive ||NULL ||NULL|| ||taxonomy term archive ||stdClass object ||stdClass object|| ||CPT archive ||stdClass object ||stdClass object|| ||single post ||NULL ||NULL|| ||single CPT ||NULL ||NULL|| ||page ||NULL ||WP_Post object|| ||author archive ||WP_User object ||False|| ||posts page ||WP_Post object ||WP_Post object|| NULLs indicate failure of `get_queried_object()`. Except for tag archive, all NULLs returned are due to regression prior to 3.7. Why the tag archive failed in 3.8 is unclear, but the proposed patch addresses this issue as well as all other NULL returns. For those that don't know, the reason for different results with pretty permalinks enabled is different query vars are defined when rewrite rules are applied. The default no pretty permalinks does not use rewrite rules and the query vars can only be what is parsed from the request. " bcworkz Future Releases 24142 Zero value for posts_per_page value in wp_query custom instance and for 'Blog pages show at most' option Query normal normal Future Release defect (bug) reopened 2013-04-20T09:04:16Z 2015-06-15T12:46:23Z "To show no posts if the posts_per_page value is 0. Currently for custom instances of wp_query, if the value is 0 then this is changed with the value from posts_per_page option from the database. ""get_options( 'posts_per_page' )"" For home page if we set value 0 on the settings page, in wp-admin/options-reading.php, after the saves are changed, this value is changed to 1. I think for both cases if the posts per page value is 0 then no posts should not display. " alexvorn2 Future Releases 37530 is_front_page() is based on wrong data -> gives wrong results Query 4.5.3 normal normal Awaiting Review defect (bug) new has-patch 2016-07-31T14:28:49Z 2016-08-27T08:58:13Z "1) is_front_page() is based on the SQL query, so it always gives back false when you try to use it eg at pre_get_posts. If it has no way to figure it out if it's the front page or not, it should return null instead 2) is_front_page() in themes gives the wrong result false back when you set an static page for the front page and then modify the main query on start page to posts or any other custom post type except page. This forces you to make an additionally SQL query instead of using the main query to build a custom front page. Both is because of this: https://core.trac.wordpress.org/browser/tags/4.5.3/src/wp-includes/query.php#L4458 . This does not really make sense to get the front page." TheInfinity Future Releases 15667 wp_list_pages, if it finds no pages to display, shows random child pages instead because of a bug in get_pages() jackreichert Query 3.0.2 normal minor Future Release defect (bug) assigned has-patch 2010-12-03T19:12:46Z 2015-09-18T04:03:01Z "How to reproduce:[[BR]] - About page is published - additionally, there is a number of parent pages[[BR]] - these each have a number of children[[BR]] - when calling wp_list_pages(), the ""exclude"" attr excludes all parent pages, and display only the About page. This works as long as there is at least 1 other page published that is not in the list of excluded IDs. In this example, as soon as the About page is set to ""draft"", wp_list_pages stops working correctly. So... with no other pages besides the excluded ones published, we do this: 1) wp_list_pages('title_li=&depth=1&exclude=3,5,7'); => wp_list_pages SHOULD return nothing, but instead it displays all child pages of the first parent page ID in the ""exclude"" attr (here: 3). Now we now add the ""exclude_tree"" attr just for fun: 2) wp_list_pages('title_li=&depth=1&exclude=3,5,7&exclude_tree=3,5,7'); => should again return nothing, but instead, it displays the first-ever published child page globally (here: a child page of 5). It looked like random behavior at first but I've been able to identify the above pattern. I'm guessing it's a failing condition somewhere in the function." bobsoap Future Releases 19907 Updating an unpublished draft post in quick-edit mode sets the post's publish date Quick/Bulk Edit 2.7 normal major Future Release defect (bug) new has-patch 2012-01-27T14:51:32Z 2015-11-01T16:50:56Z "'''Problem:''' • If you update an unpublished draft post in quick-edit mode, the post's ''publish date'' is saved. [[BR]] • Then, later on, when you actually publish the post, its publish date is incorrect. '''Suggested fix:''' • If the post is a draft, do not automatically set the post's publish date in quick-edit mode. '''Steps to reproduce:''' (1) Go to WP-Admin -> Posts. (2) Create and save a new post. Make sure you click ""Save Draft"" — not ""Publish"". (3) Note that the post is marked as ""Publish immediately""; that is, it has no publish date. (4) Go back to WP-Admin -> Posts. (5) Hover your pointer over the post you just created. Click ""Quick Edit"". — Note that in the panel that appears, the ""Date"" field is automatically set to [the current date and time]. (6) Click ""Update"" in quick-edit mode. (7) Hover your pointer over the post you just updated. Click ""Edit"". — Note that in the Edit Post page that appears, the post is now marked as ""Publish on: [the date and time from step (5)]"" " uxtremist Future Releases 39889 Improve/Fix REST Response on Multisite when an endpoint for a non-existent site is hit. REST API 4.7 normal normal Future Release defect (bug) new 2017-02-16T15:52:54Z 2017-02-16T17:52:39Z "Currently if you hit the endpoint for a domain on a site that doesn't exist it will behave the same as on a normal request. - visit https://nonexistentsubdomain.eventsmart.com/wp-json in a REST client. - Take note of the ""Location"" header in the response: https://eventsmart.com/wp-signup.php?new=nonexistentsite. It's also returned with a HTTP 302 Granted this is kind of edgecase, but I think it'd be better to handle things a bit better on REST requests. The question is how? I think from the standpoint of the REST client it'd be better to just return a 404 and a ""site doesnt' exist"" message (or something to that affect)." nerrad Future Releases 34560 High memory usage ( and possible server error) editing post with many/large revisions adamsilverstein Revisions 3.6 normal major Future Release defect (bug) assigned dev-feedback 2015-11-02T23:42:27Z 2016-12-20T17:11:18Z "**Version:** This issue was seen under WordPress 4.3.1, but it likely applies to any modern version of WordPress, even as far back as [https://github.com/WordPress/WordPress/blob/2.9-branch/wp-admin/edit-form-advanced.php 2.9] or maybe earlier. **Expected Behavior:** A WordPress user should be able to happily create thousands of revisions of pages (or blog posts) containing megabytes of HTML text, limited only by the amount of server memory needed to contain the specific edited revision of the page or post (minus baseline memory needs). So, for example, if you have a 256MB PHP memory limit, you should be able in theory to edit pages of 100MB or more for thousands of revisions (ignoring non-memory constraints like CPU usage, database configuration, communication timeouts, or browser-side limitations). Certainly you should be able to edit a page or post of under 1MB for hundreds of revisions given 256MB of allowed PHP memory (or even just with a 32MB memory limit given few plugins). While editing in WordPress will have limits based on available memory or CPU use or communications timeouts and the memory demand of the current revision being edited, those editing limits should not be substantially affected by the number of revisions of a post previously saved or the sizes of previously saved revisions. **Exhibited Behavior:** Right now, you will unhappily see ""500 server error"" and ""white screen of death"" results eventually if you, say, edit a 400K page for hundreds of revisions, even with a 256MB server memory limit. Here is an example error from a server with 256MB memory limit resulting from trying to edit a page after saving about 350 revisions of a page that grew to be 437,042 bytes in size: {{{ [02-Nov-2015 14:40:42 UTC] PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 437043 bytes) in /usr/home/narrafirma/public_html/narrafirma.com/wp-includes/wp-db.php on line 1389 }}} **Steps to reproduce:** Create a new WordPress page. Put 500K or so of text in it (or any other large amount, the smaller the amount, the more revisions needed to be saved). Save the page for hundreds of revisions. Failure will occur when the number of revisions times the post size exceeds the PHP available memory minus the core memory need of WordPress+plugins. To speed this failure process, reduce the memory available to PHP. **Likely cause:** The file edit-form-advanced.php has the following section of code which retrieves all revisions for a post using wp_get_post_revisions and then counts the result (twice) to display a count of revisions on the page. While the current approach has a certain elegant simplicity and is easy to understand, the approach is unfortunately computationally inefficient because retrieving all the revisions of a post just to count them potentially consumes a lot of memory, a lot of CPU time, and a lot of database bandwidth when there are many revisions of a post if some are of significant size. From [https://github.com/WordPress/WordPress/blob/4.3.1/wp-admin/edit-form-advanced.php edit-form-advanced.php (4.3.1)]: {{{ $publish_callback_args = null; if ( post_type_supports($post_type, 'revisions') && 'auto-draft' != $post->post_status ) { $revisions = wp_get_post_revisions( $post_ID ); // We should aim to show the revisions metabox only when there are revisions. if ( count( $revisions ) > 1 ) { reset( $revisions ); // Reset pointer for key() $publish_callback_args = array( 'revisions_count' => count( $revisions ), 'revision_id' => key( $revisions ) ); add_meta_box('revisionsdiv', __('Revisions'), 'post_revisions_meta_box', null, 'normal', 'core'); } } }}} **Suggested fix:** Retrieve the count of revisions in some other way with custom SQL. Alternatively, add an option in when retrieving revisions via ""wp_get_post_revisions"" (in ""wp-includes/revision.php"") to only retrieve the metadata for the revision (like size, timestamp, user, and so on) and use that option in this code. Incidentally, another minor optimization for this code fragment may be to store the count of revisions in the code above so the counting process is not done twice (depending perhaps on how count is implemented versus variable allocation costs in PHP). **Caveats:** I have only tested this error condition for a page, but I am assuming this issue will apply to blog posts as well (or any kind of posts with revisions). I am not sure what other implications there would be from such a change, like if the revisions' contents were needed elsewhere later for comparisons -- although such a situation could potentially be dealt with by selectively loading specific revision's contents as needed for diff comparisons, even if all the metadata might be needed up front. **Other potential benefits of the proposed fix:** Beyond avoiding server errors and white screens, making the proposed change may speed up opening long posts and pages for editing by reducing server load substantially. When editing even small posts with a few revisions, this change will still likely speed up the initial opening of the editor at least slightly. **Use cases:** An example situations of a large page with multiple revisions is where a team uses a WordPress page to track component version deployment status of a large system. Another use case is when a WordPress page grows into a book-length document through repeated editing by someone :-) who is also used to saving a lot to avoid losing work from browser crashes. **Additional suggestion for further code review:** All uses of ""wp_get_post_revisions"" and any similar functions, as well as all uses of ""count"", could be reviewed in the WordPress codebase looking for similar computational inefficiencies. " pdfernhout Future Releases 35482 Archival pagination fails in 4.4 and up Rewrite Rules normal normal Awaiting Review defect (bug) new 2016-01-15T20:59:37Z 2016-02-01T12:38:50Z "Stemming from research into a weird 'category' issue in #35344 1. Make your permalinks {{{/%category%/%postname%/}}} or anything _as long as_ you start with `/%category%/` 2. Go to `example.com/category/SOMECAT/` and everything works. 3. Go to `example.com/SOMECAT/` and WP thinks it's an _archive_! And pagination fails. Either it's a 404, or it redirect you to the 'most appropriate' page (I ended up on http://local.wordpress-trunk.dev/page-a/2/ a lot) I tested this with `/%author%/%postname%/` and `/bob/%postname%/` - the former had the same issue, the latter shows a 404 for `http://local.wordpress-trunk.dev/bob/` and this is expected! If the permalink 'base' is any of our structure tags ( https://codex.wordpress.org/Using_Permalinks#Structure_Tags ) then WordPress is attempting to generate an archival page for something it knows, and the pagination is failing. Logically this is becuase any 'base' page that _can_ generate an archive of itself (cats, tags, dates, but _not_ `bob`) should be doing so. Contrary to initial reports, this is a 4.4+ bug, it was _not_ introduced by 4.4.1 Slugs like bob and 'archive' (the slug you get if you pick the 'Numeric' permalink option) have never, that I can see, paginated. Digging even deeper.... 1. Permalinks set to `/%year%/%category%/%postname%/` 2. Visit `example.com/2016/SOMECAT` and the page displays an archive 3. Pagination from here does _not_ work (tested on 4.4 and 4.3 so I think its okay to assume that never worked....) I'm not sure if these should have worked. I know that if you do `/%year%/%month%/%postname%/` then the year ''and'' the year/month archive URLs will work, but that may be a separate issue." Ipstenu Future Releases 33728 Rewrite endpoints cannot be added to custom taxonomies with public rewrites johnbillion Rewrite Rules 4.4 normal normal Future Release defect (bug) reviewing has-patch 2015-09-04T14:37:20Z 2016-09-02T11:02:39Z "Take the following scenario: 1. A plugin registers a custom taxonomy that is public and has pretty rewrite rules enabled: {{{ function genre_taxonomy() { $tag_args = array( 'label' => 'Genre', 'public' => true, 'rewrite' => array( 'slug' => 'genre' ), ); register_taxonomy( 'genre', array( 'post' ), $tag_args ); } add_action( 'init', 'genre_taxonomy', 5 ); }}} 2. A second plugin registers a rewrite endpoint that is added to all URLs on the site: {{{ function ajax_endpoint() { add_rewrite_endpoint( 'ajax', EP_ALL ); } add_action( 'init', 'ajax_endpoint' ); }}} `EP_ALL` means ""add this to all pages"", which should logically include all custom taxonomies. This however, is not the case. Works: - site.com/ajax/1 - site.com/tag/blug/ajax/1 - site.com/blog/hello-world/ajax/1 - site.com/2015/05/01/ajax/1 - all other standard rewrites Fails: - site.com/genre/rock/ajax/1 It fails because custom taxonomies do not get included in `EP_ALL` unless they are explicitly included. If we look at `register_taxonomy()`, we see this is done intentionally: {{{ if ( false !== $args['rewrite'] && ( is_admin() || '' != get_option( 'permalink_structure' ) ) ) { $args['rewrite'] = wp_parse_args( $args['rewrite'], array( 'with_front' => true, 'hierarchical' => false, 'ep_mask' => EP_NONE, ) ); if ( empty( $args['rewrite']['slug'] ) ) $args['rewrite']['slug'] = sanitize_title_with_dashes( $taxonomy ); if ( $args['hierarchical'] && $args['rewrite']['hierarchical'] ) $tag = '(.+?)'; else $tag = '([^/]+)'; add_rewrite_tag( ""%$taxonomy%"", $tag, $args['query_var'] ? ""{$args['query_var']}="" : ""taxonomy=$taxonomy&term="" ); add_permastruct( $taxonomy, ""{$args['rewrite']['slug']}/%$taxonomy%"", $args['rewrite'] ); } }}} In my opinion, '''this is fundamentally wrong'''. If a rewrite endpoint is added with `EP_ALL`, it should actually be registerred on '''all''' rewrites, not just some. Let's see another example to help illustrate that this is wrong. 1. A plugin (such as WooCommerce) registers a custom taxonomy with public rewrites called ""Product Category"". With this taxonomy, the following rewrite is available: `site.com/products/product-category/mugs` 2. A second plugin (such as AffiliateWP) registers a rewrite endpoint with `EP_ALL` to permit the following: - site.com/ref/1 - site.com/page-name/ref/1 - site.com/2015/01/01/ref/1 - site.com/category/news/ref/1 - etc, etc - AND - site.com/products/product-name/ref/1 (works) - site.com/products/product-category/mugs/ref/1 (fails) The rewrite endpoint works fine on custom post type rewrites '''but not taxonomy rewrites'''. There are two ways for rewrite endpoints to work on the custom taxonomy: 1. Have the taxonomy include `'ep_mask' => 'EP_ALL'` (or similar) when it is registered. This requires that the plugin that registers the taxonomy to include this, which very, very, very few do as it is not necessary for pretty permalinks to work. 2. Manually add rewrite rules for the endpoints to all custom taxonomies: {{{ $taxonomies = get_taxonomies( array( 'public' => true, '_builtin' => false ), 'objects' ); foreach( $taxonomies as $tax_id => $tax ) { add_rewrite_rule( $tax->rewrite['slug'] . '/(.+?)/ref(/(.*))?/?$', 'index.php?' . $tax_id . '=$matches[1]&ref=$matches[3]', 'top'); } }}} While manually adding the rewrite rules does work, '''it should not be necessary''' when `add_rewrite_endpoint( 'ref', EP_ALL );` should be sufficient. I propose that `EP_TAXONOMY` be introduced, as suggested in #21050, and that `EP_TAXONOMY` be included in `EP_ALL`. Related #19275" mordauk Future Releases 35916 WP_Rewrite::generate_rewrite_rules() ignores boolean $endpoints / $feed parameters for CPT Rewrite Rules normal normal Awaiting Review defect (bug) new 2016-02-23T08:34:12Z 2016-09-23T09:34:08Z "Hello, I'm trying to declare custom rewrite rules for a custom post type without endpoints and feeds. As result, WP ignore the endpoint flag in the WP_Rewrite::generate_rewrite_rules(). What I did is as following. I created a custom post type called 'event' with the following arguments for register_post_type() : {{{#!php array( // Array of WP post type args 'labels' => array( 'name' => 'Events', 'singular_name' => 'Event', ), 'public' => true, 'publicly_queryable' => true, 'show_ui' => true, 'show_in_menu' => true, 'query_var' => false, 'rewrite' => false, 'capability_type' => 'post', 'hierarchical' => false, 'menu_position' => 5, 'menu_icon' => 'dashicons-tickets-alt', 'supports' => array( 'title', 'editor', 'thumbnail', ), 'taxonomies' => array( 'post_tag', 'my_category', ), ); }}} Then I called {{{#!php $args_post_type = array( 'feed' => false, 'paged' => false, 'ep_mask' => EP_NONE, 'endpoints' => false, ); add_permastruct('events', 'events/%event%', $args_post_type); }}} The resultings rewrite rules are : {{{ 'events/[^/]+/attachment/([^/]+)/?$' => string 'index.php?attachment=$matches[1]' (length=32) 'events/[^/]+/attachment/([^/]+)/trackback/?$' => string 'index.php?attachment=$matches[1]&tb=1' (length=37) 'events/[^/]+/attachment/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$' => string 'index.php?attachment=$matches[1]&feed=$matches[2]' (length=49) 'events/[^/]+/attachment/([^/]+)/(feed|rdf|rss|rss2|atom)/?$' => string 'index.php?attachment=$matches[1]&feed=$matches[2]' (length=49) 'events/[^/]+/attachment/([^/]+)/comment-page-([0-9]{1,})/?$' => string 'index.php?attachment=$matches[1]&cpage=$matches[2]' (length=50) 'events/[^/]+/attachment/([^/]+)/embed/?$' => string 'index.php?attachment=$matches[1]&embed=true' (length=43) 'events/([^/]+)/embed/?$' => string 'index.php?event=$matches[1]&embed=true' (length=38) 'events/([^/]+)/trackback/?$' => string 'index.php?event=$matches[1]&tb=1' (length=32) 'events/([^/]+)(?:/([0-9]+))?/?$' => string 'index.php?event=$matches[1]&page=$matches[2]' (length=44) 'events/[^/]+/([^/]+)/?$' => string 'index.php?attachment=$matches[1]' (length=32) 'events/[^/]+/([^/]+)/trackback/?$' => string 'index.php?attachment=$matches[1]&tb=1' (length=37) 'events/[^/]+/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$' => string 'index.php?attachment=$matches[1]&feed=$matches[2]' (length=49) 'events/[^/]+/([^/]+)/(feed|rdf|rss|rss2|atom)/?$' => string 'index.php?attachment=$matches[1]&feed=$matches[2]' (length=49) 'events/[^/]+/([^/]+)/comment-page-([0-9]{1,})/?$' => string 'index.php?attachment=$matches[1]&cpage=$matches[2]' (length=50) 'events/[^/]+/([^/]+)/embed/?$' => string 'index.php?attachment=$matches[1]&embed=true' (length=43) }}} Looking at class-wp-rewrite.php, I noticed in generate_rewrite_rules() that piece of code that forces the $post flag for CTP {{{#!php if ( ! $post ) { // For custom post types, we need to add on endpoints as well. foreach ( get_post_types( array('_builtin' => false ) ) as $ptype ) { if ( strpos($struct, ""%$ptype%"") !== false ) { $post = true; // This is for page style attachment URLs. $page = is_post_type_hierarchical( $ptype ); break; } } } }}} and that piece of code that unconditionnaly add extra endpoints / feeds... for post {{{#!php // If we're matching a permalink, add those extras (attachments etc) on. if ( $post ) { // Add trackback. $rewrite = array_merge(array($trackbackmatch => $trackbackquery), $rewrite); }}} Could confirm that problem? Thanks" solo14000 Future Releases 14991 extra_rules_top should take priority over extra_permastructs Rewrite Rules 3.1 normal normal Future Release defect (bug) new dev-feedback 2010-09-29T18:00:08Z 2015-12-03T20:01:51Z Since extra_rules_top are specifically added instead of generated like the those from the extra_permastructs which runs through generate_rewrite_ruls(), shouldn't the extra_rules_top take priority in conflicts? prettyboymp Future Releases 25106 web.config for multisite configurations on IIS7 Rewrite Rules 3.5 normal normal Future Release defect (bug) new 2013-08-21T00:43:28Z 2015-07-13T07:36:07Z "The code that WordPress gives me for the web.config is incorrect. I downloaded the new 3.6 and this issue happened. I found the issue and solved it but wanted to let you know of this error as not many people run multisites on IIS7. So the rewrite code that was the issues is the following and was Rule 2 {{{
Role displayed in Admin as ' . $name ; echo ' Database entry: ' . $role . ''; echo '
'; $rolename = get_role($role); $caps = $rolename->capabilities; foreach ($caps as $capability => $value): echo $capability . ' '. $value . ""\n"" ; endforeach; echo ''; endforeach; }}} the default wp roles return the following capability value pairings {{{ delete_published_posts 1 }}} roles created with Justin Tadlock's members plugin return the following {{{ delete_published_posts delete_published_posts }}} roles created manually in functions.php utilizing {{{ add_role( 'test_role', 'Test Role' ); //saved and then removed before running the code below ... $role = get_role('test_role'); $role->add_cap('read'); $role->add_cap('edit_posts); $role->add_cap('edit_others_posts'); $role->add_cap('publish_posts'); $role->add_cap('read_private_posts'); $role->add_cap('delete_posts'); $role->add_cap('delete_private_posts'); $role->add_cap('delete_published_posts'); $role->add_cap('delete_others_posts'); $role->add_cap('edit_private_posts'); $role->add_cap('edit_published_posts'); }}} return the following ... {{{ delete_published_posts 1 }}} but lack the user levels as mentioned above. Let me know if there is any further info I can provide to help sort this out~ " 10sexyapples Future Releases 26365 map_meta_cap() should use parent post status when post has a post status of inherit Role/Capability 3.8 normal normal Awaiting Review defect (bug) new has-patch 2013-12-02T19:38:49Z 2015-06-18T23:41:42Z "When a post has a status of inherit `map_meta_cap()` fails to use the parent's status and so logic that uses the status to determine the mapping doesn't behave as expected. For example `read_post()` will often fail when it should pass. Similarly for `delete_post()` and `edit_post()`. This has recently caused a variety of difficulties in a project I've been working on where we have a custom post type that uses the inherit post status on children so authors only need to manage the post status of the main parent post. The fix is two parts. One a fix to `get_post_status()` that causes it to check the parent status so it'll work backwards to the first post that has a valid (not 'inherit') post status. The second is a fix to `map_meta_cap()` that checks for a post status of inherit on the post object and then uses `get_post_status()` on the post_parent id value. A couple related/similar issues: #23458 (these patches would fix the root issue) #17668 (fixed) " methnen Future Releases 34591 "BugFix to WP_Scripts::do_item(), remove doubled ""//""" Script Loader 4.3.1 normal normal Awaiting Review defect (bug) new reporter-feedback 2015-11-05T11:01:37Z 2017-02-05T09:08:07Z "Current code in `do_item()` of class.wp-script.php on line 172: {{{ $src = $this->base_url . $src; }}} may produce duplicate slashes `""//""`, resulting in problems. This might be fixed with code: {{{ $src = $this->base_url . $src; }}} Currently: * WP_Scripts contains: `""public $base_url; // Full URL with trailing slash""` and * script-loader.php contains calls `$scripts->add()` with initial `""/""` in relative paths Together this produces doubled slashes `""//""`. For example: http://www.ocelovehaly.cz/ll//wp-includes/js/jquery/jquery.js?ver=1.11.3 This makes W3TC include script in minified version, but not to remove it from the original HTML. Including jQuery twice makes LayerSlider not to work. Please, could you bugfix class.wp-script.php on line 172? Thank you :-)" jan.mazanek Future Releases 35963 Only remove item from WP_Dependencies::to_do if it was successfully processed Script Loader normal normal Future Release defect (bug) new has-patch 2016-02-26T12:37:32Z 2016-03-23T20:04:21Z "If WP_Dependencies::do_item returns false, the item is removed from being processed again. Due to this, if an item gets switched to the footer, it is never actually outputted. A common scenario is depending on jquery which depends on jquery-core and jquery-migrate. jquery is processed right, but jquery-core and jquery-migrate are moved to the bottom but still removed from the list. The following example demonstrates: {{{#!php registered['jquery']; wp_dequeue_script('jquery'); wp_deregister_script('jquery'); wp_register_script('jquery', $jquery->src, $jquery->deps, $jquery->ver, true); } }, 0); }}} Attached is a very simple patch to resolve this" pcfreak30 Future Releases 37185 "wp_print_styles() doesn't call ""wp_print_styles"" action when ""$handles"" argument passed" Script Loader 3.3.1 normal normal Future Release defect (bug) assigned has-patch 2016-06-26T13:53:32Z 2016-07-08T01:19:15Z "In {{{wp_print_styles()}}}, there is ""wp_print_styles"" action calls when function is used with optional ""$handles"" argument. {{{if ()}}} statement should be deleted ( like {{{wp_print_scripts()}}} ). Unit tests are passed." evgenniy Future Releases 11623 review options list and update sanitize_option() dd32* Security 2.9 normal normal Future Release defect (bug) accepted 2009-12-26T01:22:13Z 2015-12-03T18:01:38Z "A lot of options have been added since 2.0.5, and as a result, not all of them have been added to {{{sanitize_option()}}} Ideally, Options which are to be (int) or absint() should have a filter applied to them here. Attached patch is for the first option thats brought this up, 'start_of_week' which is tested to be int in some function uses, ignored elsewhere. I've set this to security as its preventive security.." dd32 Future Releases 24990 Nested Shortcode Inside [caption] Shortcodes 3.6 normal normal Future Release defect (bug) new dev-feedback 2013-08-08T09:38:06Z 2016-06-28T19:29:25Z "Nested shortcodes inside caption observation: {{{ [caption] Caption Text [shortcode][/caption] }}} 1. shortcode inside alt and title processed. 2. Caption Text doesn't" prionkor Future Releases 26649 escaped shortcodes should not be expanded during 'get_the_excerpt' Shortcodes 3.7.1 normal normal Awaiting Review defect (bug) reopened 2013-12-16T15:13:48Z 2015-10-04T02:16:09Z "It is possible for ""the_content"" filter to be invoked while processing ""get_the_excerpt"". If the do_shortcodes() filter hook is attached to both ""the_content"" and ""get_the_excerpt"" then this can lead to an unexpected expansion of an escaped shortcode. This can lead to unwanted side effects, as reported here. http://www.oik-plugins.com/2013/12/escaped-shortcodes-unexpectedly-expanded-get_the_excerpt/ This minor problem can be alleviated by a simple change to strip_shortcode_tag(), returning the HTML code [ as the first character rather than the left square bracket. {{{ function strip_shortcode_tag( $m ) { // allow [[foo]] syntax for escaping a tag if ( $m[1] == '[' && $m[6] == ']' ) { return ""["" . substr($m[0], 2, -1) ; } return $m[1] . $m[6]; } }}} I don't believe that it's necessary to make the same change in do_shortcode_tag(). " bobbingwide Future Releases 31665 Duplicate slugs in DB, created for hierarchical terms with long, non-latin names, when the default slug already exists Taxonomy 4.1.1 normal normal Future Release defect (bug) new 2015-03-17T10:43:33Z 2015-03-18T15:16:36Z "When WP automatically generates a slug for a child term, and if the produced slug (which is normally generated just from the term's name) already exists in that taxonomy, it forms a slug by concatenating all the parent terms' slugs hierarchically For example, in a term structure like: Parent -Child If a term with the name ""Grandchild"" is to be inserted under ""Child"", normally it would get the slug ""grandchild"". However if that slug already exists in the taxonomy, WP generates the slug ""parent-child-grandchild"". When the slugs have long, non-latin names, they are stored urlencoded in wp_terms, and the stored string's length can easily overflow the field's size ( varchar(200) ). Any terms created under that condition end up having the same slug stored in the DB (the produced urlencoded one, truncated to 200 chars). To reproduce the issue: Create a term (e.g. category) with this name (without the quotes): ""Ένα δύο τρία τέσσερα πέντε"" Create another term with the same name, defining the first term as its parent. Create a third term with the same name, defining the second term as its parent. The second and third terms end up having duplicate slugs in the DB, a situation which is normally an error. This issue is also not detected if the same procedure is repeated using wp_insert_term(). Normally an attempt to insert a duplicate slug to the same taxonomy would raise a ""duplicate_term_slug"" WP_Error, which is not the case." nevma Future Releases 16101 Numeric term fields are strings Taxonomy normal normal Future Release defect (bug) new 2011-01-04T23:25:00Z 2015-09-23T18:48:30Z "The numeric fields (term_id, parent, etc.) on term objects are strings. I only noticed this because term_exists() uses is_int() to determine if the $term value is an ID or slug. Only ticket I could find about this is #5381. sanitize_term() should fix this, but it bails early in the ""raw"" context. sanitize_term_field() sanitizes the numeric fields in every context. I don't see a reason for sanitize_term() to bail early so I made a patch that takes that out. The patch also adds some missing fields to the list of those to be sanitized and changes term_exists() to use is_numeric() (which will correctly identify strings containing only numbers) instead of is_int(). " foofy Future Releases 31270 Unexpected slugs for same-title different-parents term creation boonebgorges Taxonomy 4.1 normal normal Future Release defect (bug) assigned has-patch 2015-02-09T03:35:53Z 2015-11-10T07:13:14Z "When creating a new term which matches an existing terms name, it uses that slugs slug as the slug prefix, which can result in an unexpected term slug. For example, take this: {{{ Foo (slug: foo) - Bar (slug: foo-bar) }}} If we now create a root level ""Bar"" term, it'll get a slug of {{{foo-bar-2}}}, when one would expect it to receive {{{bar}}} since no conflicting slug exists. This is related directly to [28733] / #17689. Unit test attached showing behaviour." dd32 Future Releases 15806 get_terms with hide_empty returns count > 0 with unpublished items Taxonomy 3.0 normal normal Awaiting Review defect (bug) reopened reporter-feedback 2010-12-14T00:24:21Z 2016-08-19T16:05:15Z "Hi, I ''think'' that's a bug. I've defined a custom post type and a custom category taxonomy for it. On my front end, i'm using get_terms with hide_empty to show the categories of the existing custom post type. get_terms does ignore unpublished posts but it seems to include trashed item. I have one category that is linked to only a trashed item and the function includes it in the count. I can't select 3.0.3 in the version dropdown but it happened on any 3.0.x that I tried. " bendog Future Releases 29894 get_terms() isn't caching - duplicate queries generated boonebgorges* Taxonomy 4.0 normal normal Future Release defect (bug) accepted 2014-10-08T17:33:47Z 2015-10-31T15:20:30Z "get_terms() doesn't seem to be caching correctly and therefore generates duplicate queries. In my plugin I have the following calls: {{{ wp_dropdown_categories(array( 'taxonomy' => 'product_category', 'hide_empty' => 0, 'show_option_none' => __('Any', 'mp'), 'name' => 'child_of', )); }}} {{{ $cats = get_terms('product_category', array( 'hide_empty' => 0, )); }}} {{{ $cats = get_terms('product_category', array( 'hide_empty' => 0, )); }}} Yes, I realize I could technically create my own cache for the duplicate get_terms() function, but no matter what I'll still have 2 queries due to using wp_dropdown_categories() and get_terms() in the same request - even though they generate the same query (see below). {{{ SELECT t.*, tt.* FROM hf9v_terms AS t INNER JOIN hf9v_term_taxonomy AS tt ON t.term_id = tt.term_id WHERE tt.taxonomy IN ('product_category') ORDER BY t.term_id ASC include('wp-admin/admin-footer.php'), do_action('in_admin_footer'), call_user_func_array, MP_Shortcode_Builder->display_short_code_form, call_user_func, MP_Shortcode_Builder->display_mp_list_categories_attributes, wp_dropdown_categories, get_terms }}} {{{ SELECT t.*, tt.* FROM hf9v_terms AS t INNER JOIN hf9v_term_taxonomy AS tt ON t.term_id = tt.term_id WHERE tt.taxonomy IN ('product_category') ORDER BY t.name ASC include('wp-admin/admin-footer.php'), do_action('in_admin_footer'), call_user_func_array, MP_Shortcode_Builder->display_short_code_form, call_user_func, MP_Shortcode_Builder->display_mp_list_categories_attributes, get_categories, get_terms }}} {{{ SELECT t.*, tt.* FROM hf9v_terms AS t INNER JOIN hf9v_term_taxonomy AS tt ON t.term_id = tt.term_id WHERE tt.taxonomy IN ('product_category') ORDER BY t.name ASC include('wp-admin/admin-footer.php'), do_action('in_admin_footer'), call_user_func_array, MP_Shortcode_Builder->display_short_code_form, call_user_func, MP_Shortcode_Builder->display_mp_list_products_attributes, get_terms }}} As you can see, the SQL statements are identical and therefore the db should only be queried once. " webgeekconsulting Future Releases 37728 hide_empty doesn't work correctly in get_terms when no taxonomy specified Taxonomy 4.5 normal normal Awaiting Review defect (bug) new has-patch 2016-08-19T00:42:03Z 2016-08-19T07:55:29Z "In #35495, the taxonomy argument to `get_terms` was made optional. Calling get_terms without specifying a taxonomy will return terms from all taxonomies. However, if taxonomy isn't provided, hide_empty (when true, as per default) does not work correctly. Parent terms which are empty themselves but have nonempty child terms are not returned. You can replicate this by creating an empty category with non-empty child categories. Using: `get_terms()` - won't include the category `get_terms(array('taxonomy'=>'category'))` - will include the category `get_terms(array('taxonomy'=>array('category','post_tag')))` - will include the category This is caused by the `get_terms` function in `WP_Term_Query`. `$has_hierarchical_tax` gets set to true if a single hierarchical taxonomy is passed, or multiple taxonomies with at least one hierarchical. However, if no taxonomies are passed, this never gets set to true. In this case it should be set to true, since it will at minimum include the in-built `category` taxonomy." smerriman Future Releases 37276 tax_query with field=name doesn't work if the term contains an apostrophe Taxonomy normal normal Awaiting Review defect (bug) new has-patch 2016-07-04T21:24:28Z 2016-09-24T17:38:19Z "Related to the bug in #27810. If you create a tax_query with field=name and term containing an apostrophe, eg: {{{ new WP_Query(array( 'tax_query'=>array( array( 'taxonomy'=>'sample-tax', 'field'=>'name', 'terms'=>""Test's"" ) ) )); }}} the query built in the transform_query function in class-wp-tax-query.php comes back with: `... AND wp_terms.name IN ('Test\\\'s')` and thus generates no results. It looks like the apostrophe is getting double escaped by both the `esc_sql` and `sanitize_term_field` calls in @boonebgorges patch. Stab in the dark - in `wp_insert_term`, `wp_unslash` is called on the name field after sanitizing it - does the same need to apply here?" smerriman Future Releases 33017 Images displayed with page.php instead of index.php Themes normal normal Awaiting Review defect (bug) reopened dev-feedback 2015-07-16T15:04:19Z 2016-10-31T00:17:07Z "I am developing a theme and currently do not have an `attachment.php` or a `single.php`. When I insert an unattached image into a post and select ""Link to: Attachment Page"", I expect the image to be displayed with `index.php` according to the template hierarchy [https://developer.wordpress.org/files/2014/10/wp-template-hierarchy.jpg]. However, the attachment page is displayed with the `page.php` tempalte instead, and the URL is under my static front page. The issue does not show up with images attached to the post." creon Future Releases 24143 When define('WP_CONTENT_DIR', 'your-dir') twentythirteen - The theme directory does not exist. Themes 3.4 normal normal Awaiting Review defect (bug) reopened 2013-04-20T10:08:16Z 2016-09-17T22:24:55Z "If you use either of following in you wp-config.php you'd automatically get a Broken Themes. {{{ define('WP_CONTENT_DIR', 'your-dir'); define('WP_CONTENT_URL', 'your-url'); }}} The following themes are installed but incomplete. Themes must have a stylesheet and a template. Name Description twentythirteen The theme directory does not exist." azizur Future Releases 32920 Centering iFrames using visual editor TinyMCE normal normal Awaiting Review defect (bug) new dev-feedback 2015-07-08T11:32:54Z 2016-08-18T08:30:24Z "When we need to put a video embed code into editor, we use the text editor put the video html then switch back to visual editor. Visual editor does great job to resize video by dragging the placeholder which means to represent the video. But when I select the placeholder and hit text align (left, right or center) the placeholder acts as if it is aligning itself accordingly (by adding `.alignleft`, `.alignright`, `.aligncenter` classes). If I hit save then preview the changes. No alignment happens. So, either the iframe should be wrapped with a `
` tag with css text align. For example for center alignment of the video should create html like. {{{
}}} and so on.. Or the alignment classes should not be added to make impression that video is actually aligning, it gives wrong visual feedback. " prionkor Future Releases 26842 Contenteditable, multiple spaces,  , and U+00A0 TinyMCE 4.7 normal normal Future Release defect (bug) new 2014-01-15T17:03:31Z 2016-12-20T21:33:34Z "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 31772 Browser unresponsive with long password Users 3.7 normal normal Awaiting Review defect (bug) new has-patch 2015-03-26T00:47:25Z 2015-05-07T10:11:48Z "== Steps to reproduce 1. Login 1. Navigate to profile 1. Click in the text input for ""New Password"" 1. Paste in a long password * E.g. 600 characters: {{{ 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 }}} 1. Press the ""tab"" key - **Expected behaviour**: - The cursor moves to the ""Repeat New Password"" field. - ""Strength indicator"" changes to ""Strong"" or ""Weak"" (probably should be ""weak""). - **Actual behaviour**: - The cursor does not move. - The cursor stops blinking. - ""Strength indicator"" does not change. - The browser is not responsive. - After several seconds or a minute, the cursor eventually starts blinking, moves to the ""Repeat New Password"" field and the strength indicator changes to ""Strong"" (probably should be ""weak""). 1. Press the ""shift+tab"" keys - **Expected behaviour**: The focus moves to the ""New Password"" field and its content is selected. - **Actual behaviour**: - The cursor does not move. - The cursor stops blinking. - The browser is not responsive. - After several seconds or a minute, the focus eventually moves to the ""New Password"" field and the content is selected. 1. Press the delete/backspace key - As expected, the password is deleted and the browser is immediately responsive. My testing was as an administrator using Chrome on Mac OS X. I think this issue applies to any role and any browser on any OS. I expect the delay is longer with slower hardware. == Solutions == Certainly the strength checker need not run on `focus` events. It should only be necessary on `change`. It could also run after a short timeout (~500 ms) if no other `change` event has occured, so that it only runs when the user stops typing. An elaborate solution might be to make the password strength checking code more efficient. Or only run it on the first N characters. Or alternatively, seek a third party library that checks password strengths more performantly. A simple solution could be to set the `maxlength=""""` attribute on password ``s. Rough testing on Chrome on an 18-month old MacBook Air suggests The limit would probably need to be less than about 64-256 in order to keep the browser responsive (without modifying the unperformant code). The disadvantage of this approach is that long passwords can not be input by the keyboard, or will be truncated if pasted in. This might be an issue for users that use password managing software like OnePassword. We would need to investigate how long the passwords generated by such software is. For reference and comparison; - The server-side limit is currently 4096: https://github.com/WordPress/WordPress/blob/master/wp-includes/class-phpass.php#L217 - If a password is set that is longer than 4096 characters, WP silently fails to save the password." BevanR Future Releases 31127 Can't add a new user to two sites before they've accepted their account jeremyfelt Users 3.0 normal normal Future Release defect (bug) assigned has-patch 2015-01-25T18:57:47Z 2016-04-26T16:25:44Z "In multisite, when adding a new user to a site, the user account isn't created immediately. Their info is stored in the `wp_signups` table until the user checks their email and clicks their sign-up acceptance link. If an admin attempts to invite the user to a second site before the person has accepted their user account for the first, they'll get this message: > That username is currently reserved but may be available in a couple of days. > That email address has already been used. Please check your inbox for an activation email. It will become available in a couple of days if you do nothing." ericlewis Future Releases 15001 Duplication and incompatibilities in register_new_user() and wp_insert_user() Users 3.0 normal normal Future Release defect (bug) new has-patch 2010-09-30T19:16:11Z 2015-10-03T21:00:34Z "As a result of [12778], the commit of a patch that was part of #11644 (the MU-merge ticket), `wp_insert_user()` was modified to introduce user verification checks. The addition of these checks also introduced a number of duplications and incompatibilities between it and `register_new_user()`. (Bear in mind that `register_new_user()` calls `wp_create_user()` which calls `wp_insert_user()`.) These issues include: * Duplication (both run-time execution and code): both functions perform `username_exists()` and `email_exists()` checks. Ideally, we should only perform each check once, and from a single piece of code. * Whereas both functions perform `username_exists()` and `email_exists()` checks, `register_new_user()` performs more checks (empty_username, invalid_username, empty_email, invalid_email). If the former 2 are being checked, all 6 criteria should be checked. * `wp_insert_user()` can now return a WP_Error object, but `register_new_user()` can't handle it (I reported this in #14290) * `register_new_user()` generates a new generic error if `wp_create_user()` (via `wp_insert_user()`) returns an error (assuming proper patch #14290), rather than passing along the more specific error it was told about If an error is returned by `wp_create_user()`, `register_new_user()` throws a generic 'registerfail' error (`'ERROR: Couldn't register you... please contact the webmaster !'`). However, most likely it received a more informative WP_Error object. * `register_new_user()` allows errors to be suppressed via filters, but `wp_insert_user()` does not `register_new_user()` has the filter 'registration_errors' which allows plugins to suppress any encountered errors. Having done so, `register_new_users()`'s subsequent call to `wp_create_user()` can generate an error (of the type already suppressed) which is then un-suppressable. This renders the 'registration_errors' filter useless for the username_exists and email_exists errors (and possibly other in the future). ---- These different issues may warrant separate tickets, but cumulatively I think they point to the need to refactor `register_new_user()` and `wp_insert_user()` to be more efficient and compatible. This is a rare instance where I don't include an immediate patch for a ticket, but I wanted to get it out there and see if we can try and get these fixed for 3.1. " coffee2code Future Releases 36196 Users without a role are not being displayed Users 4.4 normal normal Future Release defect (bug) new has-patch 2016-03-10T16:27:32Z 2017-02-13T11:46:40Z "Users without a role are not displayed on the site user page. (in my case http://localhost/wordpress1/wordpress/wp-admin/users.php). But the invisible user are still being counted (e.g. i should have '4 items' although no user is visible). But on the network user page the users are visible. (in my case http://localhost/wordpress1/wordpress/wp-admin/network/users.php). I can reproduce this bug with PHP code: {{{#!php $wpUser = get_user_by('id', 35); $wpUser->set_role(''); }}} and with this SQL-Query: DELETE FROM `wordpress1`.`wp_usermeta` WHERE `user_id`='35' AND `meta_key`='wp_capabilities'; My only workaround is to use a non existing role: {{{#!php $wpUser = get_user_by('id', 35); $wpUser->set_role('anonymous'); }}} The strange thing is that this bug only exists on multi site installations. Normal single site installations work fine." tobi823 Future Releases 28163 function email_exists() check without removing umlauts Users 3.8.3 normal normal Awaiting Review defect (bug) new has-patch 2014-05-07T14:17:20Z 2015-11-01T16:55:43Z "But with wp_insert_user() the umlauts got removed. A littel bit confusing." hpr78 Future Releases 37454 get_avatar_data() delivers different url for scheme=https and is_ssl() Users 4.3 normal normal Awaiting Review defect (bug) new has-patch 2016-07-25T08:09:46Z 2017-02-15T07:56:44Z "get_avatar_data() has an option to set the scheme. If https is used, an image URL is returned which is different to the one which is returned in case delivery is conducted via https without the scheme parameter. I think it would be better to serve the same gravatar url for https pages and explicit https-scheme requests. Regarding performance and depending on the infrastructure, it could also be benefical to drop https://%d.gravatar.com completely and serve all requests to gravatar independent of the page's protocol via https://secure.gravatar.com/ to benefit from HTTP/2 (http and https://%d.gravatar.com requests are served via HTTP/1.1 whereas https://secure.gravatar.com/ allows multiplexing via HTTP/2)." neoxx Future Releases 11160 Inconsistancies in Naming and Using Sidebar Names and IDs. azaozz Widgets 2.9 normal normal Future Release defect (bug) new 2009-11-17T12:58:55Z 2015-09-02T00:55:29Z "register_sidebar() allows more sidebar names and IDs to be registered than dynamic_sidebar() recognizes as valid names and IDs. For example, register_sidebar() allows me to name a side bar ""1"" with a id of ""first"". I don't know why anyone would choose those values, but register_sidebar() allows it [1]. {{{ register_sidebar( array('name' => 1, id => 'first') ); }}} dynamic_sidebar() will not be able to find the sidebar given its name (1). {{{ if ( is_int($index) ) { $index = ""sidebar-$index""; /// 1 becomes 'sidebar-1' ... }}} The main problem is that dynamic_sidebar() is trying to process both IDs and names through the same variable ($index) while register_sidebar() separates the two with an array ( array('name' => 'Top', 'id' => 'sidebar-1' ). According to the in-line docs for dynamic_sidebar(): It is confusing for the $index parameter, but just know that it should just work. When you register the sidebar in the theme, you will use the same name for this function or ""Pay no heed to the man behind the curtain."" Just accept it as an oddity of WordPress sidebar register and display. It does ""just work"" if you never use your own sidebar IDs. I started looking at this because I wanted to use is_active_sidebar() which tests to see if a dynamic_sidebar() has anything in it. There is no get_dynamic_sidebar(). dynamic_sidebar() sends everything to the browser or returns false. {{{ register_sidebar( array('name' => 'Top') ); // id defaults to ""sidebar-1"" ... if ( is_active_sidebar('Top') ) dynamic_sidebar('Top'); }}} Which fails because is_active_sidebar() just completely skips over searching for an id to go with a name. To get it to work you need to know when it was registered. Not something theme authors and designers are going to follow easily. There's a ticket to fix this: [http://core.trac.wordpress.org/ticket/10440 #10440] {{{ if ( is_active_sidebar(1) ) dynamic_sidebar('Top'); }}} Like dynamic_sidebar(), is_active_sidebar() converts 1 to ""sidebar-1"". Unlike dynamic_sidebar() it assumes everything is entered as an id. unregister_sidebar() assumes its parameter (incorrectly named $name, not $id) is an id. But it wants a literal id, like ""sidebar-1"". unregister_sidebar(1) unregisters a sidebar with an id of 1, while dynamic_sidebar(1) tries to display a sidebar with an id of ""sidebar-1"". === Widgets (Admin Page) === The dynamic_sidebar() function is used by the Widgets management page. So, it is possible to create a sidebar with register_sidebar() that dynamic_sidebar() cannot find. You can populate it with drag and drop [2] and not have it appear on the web site. == After Patch == If committed, this patch would remove the need for tickets [http://core.trac.wordpress.org/ticket/10440 #10440] and [http://core.trac.wordpress.org/ticket/10956 #10956]. It changes the current argument behavior of unregister_sidebar(), but doesn't break backward compatibility. It allows is_active_sidebar(), unregister_sidebar() and dynamic_sidebar() all point to the same sidebar. === Before === These all refer to the same sidebar: {{{ is_active_sidebar(1); unregister_sidebar('sidebar-1'); dynamic_sidebar('Sidebar Top'); }}} In an admittedly contrived case, dynamic_sidebar() would silently fail to allow this sidebar to show: {{{ register_sidebar( array('name'=>'Sidebar Top', 'id' => 1) ); }}} === After === These all refer to the same sidebar (the first two would have broken before the patch): {{{ is_active_sidebar('Sidebar Top'); unregister_sidebar('Sidebar Top'); dynamic_sidebar('Sidebar Top'); }}} After the patch this shows fine: {{{ register_sidebar( array('name'=>'Sidebar Top', 'id' => 1) ); }}} After the patch it is possible to force an argument to be only a name or only an id: {{{ is_active_sidebar(array( 'name' => 'Sidebar Top' )); unregister_sidebar(array( 'name' => 'Sidebar Top' )); dynamic_sidebar(array( 'id' => 1 )); }}} === Notes === [1] register_sidebar() allows the user to override the default setting of: 'id' => ""sidebar-$i"", [2] When you refresh the Widgets management page the widgets will disappear from the sidebar. They are still attached to a sidebar, but dynamic_sidebar() cannot see the sidebar." CharlesClarkson Future Releases 16773 Unescaped preg_match breaks with PHP 5.3 Namespaced Widget Classes. Widgets 3.1 normal minor Awaiting Review defect (bug) new has-patch 2011-03-06T13:31:25Z 2017-01-15T06:02:01Z "In file '''/wp-admin/includes/widgets.php''' at line '''118''' in function '''next_widget_id_number''' we have: {{{ preg_match( '/' . $id_base . '-([0-9]+)$/', $widget_id, $matches ) }}} It generates very ugly warnings ''for Namespaced Widget Classes'' as it should cuorrectly be: {{{ preg_match( '/' . preg_quote($id_base, '/') . '-([0-9]+)$/', $widget_id, $matches ) }}} Thanks. '''PS''': ''I think you should do a whole sanity check regarding use of Namespaces and Closures. I'm currently switching completely to PHP 5.3 style and I'll keep you updated if I find other... problems.''" 5ubliminal Future Releases 23423 sanitize_title() in dynamic_sidebar() restricts the use of specific characters for sidebar IDs chriscct7 Widgets 2.2 normal normal Future Release defect (bug) reopened 2013-02-08T13:25:00Z 2016-01-02T03:38:45Z "In the dynamic_sidebar() function in wp-includes/widgets.php uses sanitize_title() on the given index when it looks for a sidebar with a name that matches the index. After that it leaves the index value sanitized making it impossible to use characters not allowed by sanitize_title() in a sidebar ID. By not overwriting the given index value with the sanitized version it would still be possible to use any character for the ID. To achieve this, lines 847-853 {{{ $index = sanitize_title($index); foreach ( (array) $wp_registered_sidebars as $key => $value ) { if ( sanitize_title($value['name']) == $index ) { $index = $key; break; } } }}} should be replaced with {{{ $sanitized_index = sanitize_title($index); foreach ( (array) $wp_registered_sidebars as $key => $value ) { if ( sanitize_title($value['name']) == $sanitized_index ) { $index = $key; break; } } }}}" paulvandermeijs Future Releases 30429 wp.newPost gets non-GMT date calculation wrong wonderboymusic XML-RPC 3.4 normal critical Future Release defect (bug) reopened 2014-11-21T00:04:01Z 2016-03-16T02:08:41Z "In class-wp-xmlrpc-server.php, there is a bug with the calculation of dates if a post_date is set. {{{ if ( ! empty( $dateCreated ) ) { $post_data['post_date'] = get_date_from_gmt( iso8601_to_datetime( $dateCreated ) ); $post_data['post_date_gmt'] = iso8601_to_datetime( $dateCreated, 'GMT' ); } }}} `get_date_from_gmt` assumes the parameter passed is a GMT string. `iso8601_to_datetime( $dateCreated )`, however, is the local time. It should have the GMT parameter as per the next line to ensure the two dates are always in sync; currently the first one is always incorrect." smerriman