__group__,ticket,summary,owner,component,_version,priority,severity,milestone,type,_status,workflow,_created,modified,_description,_reporter
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,2016-12-02T18:47:13Z,"There should be an easier way for changing the css selector from body to html or any other then making your own callback.
",Horttcore
Future Releases,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,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,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,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.

Casino Royale '06

is texturized as

Casino Royale, ‘06

when the apostrophe should be texturized as ’",pah2
Future Releases,8213,WP text formatting functions handle block-level INS tag incorrectly,markjaquith,Formatting,2.7,low,normal,Awaiting Review,defect (bug),reopened,,2008-11-14T14:51:09Z,2015-10-05T18:02:40Z,"From W3C documentation:
""INS and DEL are used to markup sections of the document that have been inserted or deleted with respect to a different version of a document (e.g., in draft legislation where lawmakers need to view the changes).
These two elements are unusual for HTML in that they may serve as either BLOCK-LEVEL or INLINE elements (but not both). They may contain one or more words within a paragraph or contain one or more block-level elements such as paragraphs, lists and tables.""
----
When I want to use INS tag as BLOCK-LEVEL element (to wrap to paragraphs for example) wrong HTML is produced:
{{{

First paragraph.

Second paragraph.

}}}
Correct HTML should look like this:
{{{

First paragraph.

Second paragraph.

}}}
I think the same sitiuation occurs for DEL tag.
",misieg772
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.
{{{

Once
I saw it here, I instantly knew what I wanted. I love my new woven wood
shades.- Ginny Good

Once
I saw it here, I instantly knew what I wanted. I love my new woven wood
shades.

- Ginny Good

}}}
",Denis-de-Bernardy
Future Releases,37986,Requests: 'ssl' and 'local' args missing from HTTP API debug hooks,,HTTP API,4.6,low,minor,Awaiting Review,defect (bug),new,,2016-09-08T11:19:47Z,2016-09-08T11:19:47Z,The `$args` array passed to the `http_api_debug` hook is missing the `ssl` and `local` elements that were present prior to WordPress 4.6.,johnbillion
Future Releases,37938,Split Source Parsing Functions from Press This So Can Be Used Globally,,Press This,4.2,low,minor,Future Release,enhancement,new,,2016-09-03T17:08:26Z,2016-09-04T14:55:38Z,"WordPress already has an HTML parsing function in the form of WP_Press_This::source_data_fetch_fallback and its private called functions.
Suggesting this be split off so it can be used elsewhere. Specifically, my use case is over on the Ping and Trackbacks component. One of the proposals I keep advocating for is improving the presentation.
As we already have this code in WordPress that allows for parsing of HTML for images, embeds, meta tags, etc, it should be used over writing new code to do the same.
But if it were to be called right now, it would reretrieve source HTML already retrieved by the Pingback code and passed into the comment array.",dshanske
Future Releases,38653,Trigger a doing it wrong when checking a role name as a capability,,Role/Capability,,low,normal,Awaiting Review,enhancement,new,,2016-11-04T03:35:56Z,2016-12-04T22:08:11Z,"Code which checks `current_user_can( 'administrator' )` is essentially bypassing all the power of fine grained capability checking in the roles and capabilities API. Let's trigger a call to `_doing_it_wrong()` when a cap check is performed against any of the built-in roles, in order to persuade developers to use the capabilities API as it's intended.
There may be valid use cases for checking a user's role in this way. If there are, let's look at how to address those.",johnbillion
Next Release,39157,Feed returns 404 when there are no posts,,Feeds,4.7,normal,normal,4.7.1,defect (bug),new,has-patch,2016-12-07T18:55:57Z,2016-12-08T20:27:37Z,"Probably result of #30210.
In WP 4.6.1 website without posts returned empty feed.
In WP 4.7 there is only 404 response and message: `ERROR: This is not a valid feed.`
And another side effect: When using `add_feed()` to adding own function then it worked in WP 4.6.1 by default because `$wp_query` contains by default 10 latest posts and even if there were no posts, callback function was processed. But now there is check for `$wp_query->have_posts()` (see [38929]) and so after update to WP 4.7 all these functions stopped working :-( Probably some plugins will be affected by this behaviour...",pavelevap
Next Release,39004,Alt attributes should be searchable in media library,joedolson*,Media,3.0,normal,normal,4.8,enhancement,accepted,dev-feedback,2016-12-01T15:58:50Z,2016-12-04T17:31:48Z,"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,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,33958,All Options Filter,pento,"Options, Meta APIs",,normal,normal,4.8,enhancement,assigned,has-patch,2015-09-22T08:26:51Z,2016-11-21T00:50:46Z,Add filter for all options,sebastian.pisula
Next Release,39211,is_page_template could return true on terms,swissspidy,"Posts, Post Types",4.7,normal,normal,4.7.1,defect (bug),assigned,has-patch,2016-12-09T16:18:01Z,2016-12-09T22:00:32Z,"Since this function no longer checks is_page(), the ID from get_queried_object_id will always be used to check the post template slug - this ID is not guaranteed to be a post ID. If that ID matches a Post ID with that page template it will return true even though that template is not being loaded. If that ID matches with any Post ID that does not have page template set it will most likely return true is_page_template() with no argument.",natereist
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-10T00:34:26Z,"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.7.1,defect (bug),new,has-patch,2016-12-04T20:21:43Z,2016-12-08T16:33:25Z,"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,39070,WP-API JS client can't use getCategories for models returned by collections,adamsilverstein,REST API,4.7,normal,normal,4.7.1,defect (bug),assigned,has-patch,2016-12-04T20:03:25Z,2016-12-08T16:56:31Z,"Migrating report from https://github.com/WP-API/client-js/issues/144
----
If I do this:
{{{
var postsCollection = new wp.api.collections.Posts();
postsCollection.fetch();
}}}
I'm only seeing the category id returned in the attributes object for each post.
Is there a way to include all category data there? Or from that point, when I'm looping over postsCollection, how do I get the category data for each post?
I tried doing this:
{{{
postsCollection.each( function( post ) {
post.getCategories().done( function( postCategories ) {
// ... do something with the categories.
// The new post has an single Category: Uncategorized
console.log( postCategories[0].name );
// response -> ""Uncategorized""
});
});
}}}
But this is giving me post.getCategories is not a function.
Any insight here? Basically I'm just trying to find out how to loop over posts AND include their categories.",jesseenterprises
Next Release,38303,register_meta and capabilities aren't working as expected,rmccue,Role/Capability,4.6,normal,normal,4.8,defect (bug),reopened,,2016-10-13T14:43:18Z,2016-11-15T01:28:22Z,"The first part of this is #38284, there aren't capabilities for object types other than posts.
The second part is best described by a use case:
I want logged in users to be able to flag inappropriate comments. After 10 flags, the comment gets unpublished and a notice goes to a moderator to check it. I'm going to store these flags and the user in the comment meta table using something like
{{{#!php
'string',
'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,39205,Replace is_super_admin() check with current_user_can( 'upgrade_database' ),flixos90,Role/Capability,,normal,normal,4.8,enhancement,assigned,has-patch,2016-12-09T13:46:41Z,2016-12-09T19:56:42Z,This is part of the [https://core.trac.wordpress.org/ticket/37616#comment:26 #37616] task. There is an `is_super_admin()` check which needs to be replaced with `current_user_can( 'upgrade_database' )` in `wp-admin/includes/ms.php` (line 776),dhanendran
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
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,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,34634,Empty PHP_SELF causes 404 pages to load front page with 200 status code,,Bootstrap/Load,2.0,normal,normal,Awaiting Review,defect (bug),new,has-patch,2015-11-09T14:34:39Z,2016-09-15T20:39:40Z,"I've been having this issue where visiting a non-existent page in wordpress on our live server would result in the homepage being loaded with a 200 OK response, however on local and staging going to an non-existent page would result in the correct 404 page and template being loaded.
I have a standard 4.3.1 WP install subdomain base multisite with pretty permalinks enabled running with Nginx/PHP-FPM.
I've looked to see what was different between local and live and it turns out on live `$_SERVER['PHP_SELF']` is being set blank and on staging it is being set to `/index.php`. So to test I set at the top of my index.php file the following line `$_SERVER['PHP_SELF'] = '';`. Then when running on staging I was now getting the homepage load on a non-existent page.
So I've fired up my debugger to see what is going on in core and here are my findings.
In wp-load.php we set PHP_SELF to something based off REQUEST_URI
{{{#!php
// Fix empty PHP_SELF
$PHP_SELF = $_SERVER['PHP_SELF'];
if ( empty( $PHP_SELF ) )
$_SERVER['PHP_SELF'] = $PHP_SELF = preg_replace( '/(\?.*)?$/', '', $_SERVER[""REQUEST_URI""] );
}}}
So the request `http://www.example.com/non-existent` results in `PHP_SELF` equal to `/non-existent` instead of `/index.php`
Then in `class-wp.php WP->parese_request()` we have:
{{{#!php
$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:
{{{#!php
// 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:
www.mysite.com/i-dont-exist/wp-admin
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,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,2015-01-27T20:03:51Z,"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,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,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,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,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,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:
http://example.com/page/3/?p=123
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.
From:
http://example.com/page/3/?p=123
to:
http://example.com/page/3/
",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:
/category/cat-a/?year=2008
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,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,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,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,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):
[[Image(http://crosseyedeveloper.com/wp-content/uploads/2015/12/commentcap.jpg)]]
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.
Regards,
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:
{{{#!php

}}}
And comments-content.php has following part:
{{{#!php
$cpaged, // Variable defined before, default: 1
'per_page' => 2
) );
?>
}}}
PS: In ticketing system the version 4.4.2 is not available :-)",Ninos Ego
Future Releases,34110,WordPress Trackback Bug when Comment Pagination is Enabled,,Comments,,normal,normal,Future Release,defect (bug),new,,2015-10-01T11:40:36Z,2016-07-25T19:33:53Z,"Hi, I just find a comment bug with wordpress which I think is there for a ling site, may be since v2.7+ but never actually fixed.
'''Bug Details/ Reproduce process'''
Inside your theme while fetching your comments after
{{{
have_comments()
}}}
try to fetch comments only by using
{{{
wp_list_comments( array( ""type"" => ""comment"") )
}}}
and then below check if trackback exists and if they do print the trackbacks separately using
{{{
wp_list_comments( array( ""type"" => ""pings"") )
}}}
Now add a bunch of comments on any of your blog post which also have some trackbacks. Add more than 60 - 70 comments on that post. and from settings enable comment pagination option. So that comments get divided into several comment pages. If you are thinking this is never going to happen in real life, let me tell you I have blog posts which has more than 2.500 comments in it and none of them are spam comments.
Now, after you enable the comment pagination, visit your blog page link i.e. example.com/some-post/ and you will see the trackbacks below your comments as it should show up now start navigation through your comment pagination, you will see the following -
Trackback is showing on the normal blog post link
Trackbacks also showing for /comment-page-1/
But when you will move further from comment page 1 you will only see the heading i.e. Trackback or whatever you have set, but not the actual trackbacks. This problem is also present in genesis theme, earlier I though it was a genesis bug but while developing a non genesis wordpress there I understood that it is actually a wordpress core bug.",isaumya
Future Releases,34475,get_comment_link incorrect page number in returned url.,,Comments,4.3.1,normal,normal,Awaiting Review,defect (bug),new,reporter-feedback,2015-10-28T16:36:42Z,2016-09-27T09:06:44Z,Since 4.3 core update the get_comment_link function returns incorrect page numbers for paginated comments. Have tried using default twentyfifteen theme with no plugins enabled and issue still persists.,Property118
Future Releases,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,39133,Check email length in is_email(),,Comments,trunk,normal,normal,Awaiting Review,enhancement,new,has-patch,2016-12-07T05:38:44Z,2016-12-07T08:23:33Z,"In reference to this ticket - https://core.trac.wordpress.org/ticket/38506#comment:12
It would be better to check email length within the is_email() itself instead of
validating it at various other places.
",PranaliPatel
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,Awaiting Review,enhancement,new,dev-feedback,2016-04-17T20:44:59Z,2016-05-10T05:06:44Z,"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,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,37653,"customizer sections with 'active_callback' set to 'is_front_page' don't show when ""Front page displays"" ""a static page"" and no page is selected",,Customize,3.4,normal,normal,Future Release,defect (bug),new,reporter-feedback,2016-08-13T18:02:08Z,2016-11-05T04:22:27Z,"When using a theme with customizer sections set up with the ""active_callback"" feature set to ""is_front_page"", when customizing the theme on a blog which has ""Front page displays a static page"" under ""Reading setting"", these sections to not show up when accessing ""Appearance""->""Customize"".
The problem appears to be that when running ""Customize"", the WP_Query object is started with an empty string. When the query is empty, then `is_front_page` looks at the value of `get_option( 'show_on_front')` and if it is set to ""posts"" it checks `is_home` - which resolves to `true` when the query is empty.
On the other hand, if `get_option( 'show_on_front')` resolves to ""pages"", `is_front_page` then checks `$this->is_page( get_option( 'page_on_front' ) )` which never resolves to true when starting with an empty query.
The problem with `is_page` not responding correctly `get_option( 'show_on_front') == ""pages""` is that `WP_Query::__construct()` will not do anything if `empty($query)` and will not run `WP_Query::query()` - which would in turn run `get_posts()` and then `parse_query` only there does `get_option('show_on_front')` gets resolved and `is_page` is set if needed.
Tested on 4.5.1, but the code paths I traced exist without change in trunk. I'm running my tests on a mutli-site set up, so that might also contribute to the issue, but not in anyway I managed to detect.",Guss77
Future Releases,37964,Allow customizer controls to be encapsulated by accepting pre-instantiated settings,westonruter*,Customize,3.4,normal,normal,Future Release,enhancement,accepted,has-patch,2016-09-07T06:31:49Z,2016-10-26T20:31:50Z,"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:
{{{#!js
var control = new wp.customize.Control( 'product_color', {
type: 'color',
params: {
settings: {
'default': new wp.customize.Value( '#000000' )
}
}
} );
}}}
Instead of having to do:
{{{#!js
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.
Related:
* #30738
* #37275
* #29071",westonruter
Future Releases,30738,JS content templates for base WP_Customize_Control,westonruter*,Customize,4.1,normal,normal,Future Release,enhancement,accepted,,2014-12-17T02:33:15Z,2016-10-21T16:12:38Z,"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
Future Releases,32315,$wpdb->insert fails without error msg,,Database,,normal,normal,Awaiting Review,defect (bug),reopened,,2015-05-08T17:44:34Z,2016-11-08T02:41:16Z,"Given a field in MySQL defined as char(8), but the string you attempt to insert in that field has a length of 20.
If you use $wpdb->query($wpdb->prepare(...)) syntax, it will insert the record (and possibly truncate the string).
If you use $wpdb->insert(...) syntax, no record is created, and no error is reported in any manner. If you edit the MySQL def to char(20) or shorten the string to 8 chars, $wpdb->insert then inserts the record.
Preferably, both forms of syntax should work the same and either (a) provide an understandable error and fail; (b) provide a warning and succeed.",dlt101
Future Releases,18210,"Update_post_meta is case insensitive on meta_key, but get_post_meta is NOT",,Database,3.2,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2011-07-22T07:05:28Z,2015-06-22T03:13:45Z,"In WordPress 3.3-aortic-dissection and 3.2.1
get_post_meta is case sensitive on the meta-key
BUT
update_post_meta is NOT case sensitive
Thus If there is a pre-existing meta record with a key in say UPPERCASE, then one can issue an update for a lowercase key that one can not then fetch as it does not exist - only the uppercase key exists.
Example Code
{{{
$meta = get_post_meta ($post->ID, '_allday');
if ($meta ) { echo '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,34870,dbDelta Not Specifying Key Length Duplicate Indexes,,Database,2.8.1,normal,normal,Awaiting Review,defect (bug),new,has-patch,2015-12-06T17:51:28Z,2016-12-06T20:40:17Z,"Reference ticket #10404.
This is to decompose the original ticket into components. May be fixed in 4.4. Needs testing.
----
Does not match index definition. Creates duplicate indexes each time dbDelta is run:
{{{
KEY movie_type_idx (movie_type),
}}}
Does NOT create duplicate indexes:
{{{
KEY movie_type_idx (movie_type(255)),
}}}
----
Reported by: @sebet",charlestonsw
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,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.
* `MYSQL_SSL_KEY`
* `MYSQL_SSL_CERT`
* `MYSQL_SSL_CA`
* `MYSQL_SSL_CA_PATH`
* `MYSQL_SSL_CIPHER`
In addition this should only be set if the feature flag `MYSQLI_CLIENT_SSL` is set for the existing `MYSQL_CLIENT_FLAGS` constant.",hypertextranch
Future Releases,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`;
DELIMITER ;;
CREATE PROCEDURE `mysqli_procedure_test`()
BEGIN
SELECT * FROM `wp_posts` LIMIT 1;
SELECT * FROM `wp_posts` LIMIT 1;
END;;
DELIMITER ;
}}}
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,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,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,38773,Calculation error in human_time_diff,,Date/Time,,normal,normal,Awaiting Review,defect (bug),new,has-patch,2016-11-13T10:27:40Z,2016-11-13T15:54:05Z,"Hi,
a few days ago I used human_time_diff() for the first time. It was in a wp-cron task manager, to check when the last run happened. Now the human_time_diff is rounded by php round, this means that if 2h and 1min ago it returns 2 hours ago, but if 2h, 30m and 1sec it returns 3 hours... and this is not true, because 3 hours haven't passed... and this also happens on 2 years and 1 hour (3 years?). So there is a patch to correct this, even if you want to correct it.
Thanks :)",SGr33n
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,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,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,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,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,32620,WordPress is not stripping invalid tags in get_the_content_feed,,Feeds,4.2.2,normal,minor,Awaiting Review,defect (bug),new,,2015-06-12T00:01:42Z,2016-02-10T23:52:50Z,"I think that maybe get_the_content_feed does not stript invalid tags from post content. I have posted a question about it in here: http://wordpress.stackexchange.com/questions/191199/does-get-the-content-feed-strip-invalid-tags
I have an '''iframe''' within a post body content, and wordpress feed is not working anymore.
== Possible solutions ==
1) When generating rss feed maybe would be nicer to add more functions to strip those invalid tags, sanitize the string, and also remove shortcodes '''[bla] blabla [\/bla]'''
2) or... you could add a menu option in Wordpress panel to fine tune how feed would be generated. You could choose if invalid tags should be removed or not, so the feed would contain only plain text in ",juniorm
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,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,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 `

}}}",vaurdan
Future Releases,33787,Euro hex code being converted to smiley url,,Formatting,4.2,normal,normal,Future Release,defect (bug),new,has-patch,2015-09-09T09:36:51Z,2015-09-10T23:30:56Z,"While using a hex code for euro symbol ""€"" in a HTML email, `wp_staticize_emoji_for_email` filter tries to convert it into a smiley url, which doesn't exist, and the symbol appears broken in the email.
[[Image(euro-to-emoji url.png)]]
To test this out, here is a small plugin.
Updating the regex in `/wp-includes/formatting.php` https://core.trac.wordpress.org/browser/trunk/src/wp-includes/formatting.php#L4530, fixes the issue.
",UmeshSingla
Future Releases,2691,HTML comments in posts aren't handled properly.,,Formatting,2.8.5,normal,normal,Future Release,defect (bug),reopened,dev-feedback,2006-04-25T03:16:37Z,2015-05-13T21:07:17Z,"When an HTML comment is added in a post, autop adds paragraph (

) tags around the comment and for multi-line comments line breaks ( ) are added after every line. This should not happen in HTML comments.
This ticket is similar to #712 which was closed with wontfix. I would like to know why this isn't seen as an issue? It prevents the addition of RDF and other metadata, not to mention just plain old HTML comments in posts.",gord
Future Releases,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:
{{{

hello

test

world

}}}
Preview output:
{{{

hello

test

world

}}}
Seen in 3.8 and in trunk. Doesn't seem to be an editor bug because switching tabs will improve the output. Something wrong with wpautop()?
",miqrogroove
Future Releases,29956,Paragraphs within list items disappear in the editor when switching from text to visual and back,,Formatting,4.0,normal,normal,Future Release,defect (bug),new,,2014-10-14T16:42:07Z,2015-05-23T00:00:30Z,"On a fresh wordpress 4.0 in the editor when I enter

a

b

or

a
b

and switch from text to visual and back, I get

ab

",brunni
Future Releases,21689,Unbalanced

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):
{{{

Insert FIRST PARAGRAPH here.
Insert SECOND PARAGRAPH here.

}}}
The end result (both visually and looking at the source code) is that there is a MISSING opening paragraph tag at the beginning of the first paragraph right after the opening div tag.
IF the user adds their own spacing between the divs and the content, paragraph formatting with happen on its own, but if the user doesn't add in the spacing and starts the paragraphed content right after the div like in the example above, the first paragraph tag isn't automatically added in.
For a screenshot of the end result source code that is generated (with the missing opening paragraph tag), please see the attached file.
Cheers!",EMG
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,38656,wpautop incorrectly handling paragraphs within block elements,,Formatting,,normal,normal,Future Release,defect (bug),new,has-patch,2016-11-04T06:10:39Z,2016-11-06T12:46:29Z,"When there are two line breaks within a block element, `wpautop()` will replace it with `

`, but the corresponding opening and closing tags won't exist.
For example, `

a\n\nb

` will produce `

a

b

`, when it really should produce `

\n

a

\n

b

\n

`.",pento
Future Releases,10033,wpautop problems with html comments and object tags,,Formatting,2.8,normal,minor,Future Release,defect (bug),new,,2009-06-04T12:06:35Z,2015-09-08T17:48:41Z,"Bumped into this one when upgrading my mediacaster plugin to use swfobject 2.1 (which is not 1.5 compatible), as documented here:
http://code.google.com/p/swfobject/wiki/documentation
I take it I'm not the only one who is going to need to upgrade a plugin. It's minor, since I'll just move the filter further down in the queue, but it's still worth reporting:
{{{

}}}
So, two/three issues:
- wpautop should also ignore double object tags, and html comments
- wptexturize should ignore html comments",Denis-de-Bernardy
Future Releases,5250,wpautop() issue with lists,,Formatting,2.3,normal,normal,Future Release,defect (bug),reopened,,2007-10-24T00:32:38Z,2015-10-05T17:54:56Z,"First of all, my sincere apologies if this is a duplicate.
The problem, in short: WordPress inserted a number of unclosed `

` tags into my post. It should either insert correctly closed tags, or none at all. I honestly would prefer the former.
In detail: I had HTML code very similar to this:
{{{

text

subtext

more text

}}}
This was automatically converted to:
{{{

text

subtext

more text

}}}
Note the extra `

` tag in the above, which is unclosed (making the W3C validator choke on my website).
Also note, I was not using the WYSIWYG editor (turning it off was the first thing I did), so it's unlikely to be due to that.
As a workaround, manually inserting properly closed `

` tags works just fine:
{{{

text

subtext

more text

}}}
Since this workaround exists, the bug is not very prioritary, but it should also (hopefully) be easy to fix.",Narc0tiq
Future Releases,27733,wpautop(): \s in regex destroys some UTF-8 characters,,Formatting,0.71,normal,major,Future Release,defect (bug),new,early,2014-04-09T09:17:39Z,2015-06-24T23:24:14Z,"\s in preg_replace() incorrectly targets some UTF-8 characters.
'''Steps to reproduce:'''
1. Create a post with
{{{
ム
new line
}}}
as a content.
2. It will be output as
{{{

�\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,36904,Add caching to comment feed in WP_Query,,Query,2.2,normal,normal,Future Release,enhancement,new,has-patch,2016-05-22T15:21:35Z,2016-05-26T12:39:45Z,"In the WP_Query class, the comments table is queried. When WP_Comment_Query was introduced and added caching. Similar caching should be applied to WP_Query class.
Caching could be added to the WP_Query class, or WP_Query could use the WP_Comment_Query. ",spacedmonkey
Future Releases,28399,Allow WP_Query to query by comment_count column of CPT/posts table,,Query,4.0,normal,normal,Future Release,enhancement,new,,2014-05-29T14:50:45Z,2015-12-03T15:16:21Z,"In the current WP_Query, it is possible to order results by comment_count ASC/DESC.
But is it not possible to query the table based on this CPT/posts table column. Therefor it is impossible to (for example) query posts without any comment or posts having over 10 comments.
I propose a diff to use WP_Query in the following way (building on the syntax from meta_query and tax_query)
a) Easy call:
`$args['comment_count'] = n; n >= 0`
b) Extended call:
`$args['comments']['count'] = n; n >= 0`
Optional in this call:
`$args['comments']['compare'] = Compare; Compare: =, !=, >, >=, 'rand' which translates to ORDER BY RAND().
This is very slow when you have many posts, since it effectively calls RAND() for each row.
A faster way would be to call RAND() only once and put it in the LIMIT clause.
The only thing is that we have to make sure that the generated number is smaller than (total number of posts - number of posts to fetch).
So, this would require to do an extra query to calculate the total. It should still be faster than the current method.
If we want to get more than one post, we can get them in any order and then call shuffle() on the resulting array.",scribu
Future Releases,33306,Only Query for author ID if user is member of blog,,Query,4.3,normal,normal,Future Release,enhancement,new,,2015-08-07T17:45:42Z,2016-05-24T19:37:00Z,"In WP_Query if a user is part of the multisite install but is not part of the current blog the query is still altered from only finding public posts to finding public posts and those that are private and from that author_id. While this never has an impact on the returned end results, not having private and author ID as a parameter lets MySQL optimize the queries and in the circumstances this has been tested on (large site, lots of posts lots of users) makes them run faster. On a site without multisite installed this will have the same behavior.",sboisvert
Future Releases,19653,Order by meta field forces ignore of null records,,Query,,normal,normal,Future Release,enhancement,new,has-patch,2011-12-23T15:11:45Z,2015-09-15T08:49:44Z,"When doing a sort on posts with a meta value, the way the SQL is currently generated in meta.php creates a condition where records that DO NOT have the queried meta value are excluded from the results. This may or may not be the desired behaviour, but we don't give developers the choice without resorting to custom queries or manual rewrites of large swathes of the $clauses array.
The issue: the way WP_Meta_Query->get_sql() creates the join on the meta key is by setting an inner join on wp_postmeta and then adding the key test to the where clause.
I would suggest writing an outer (left) join on wp_postmeta, with the key condition in the join. This would also eliminate any potential future ambiguity if, for example, you are sorting on one meta key but filtering on another, since the key condition would be within the join clause, not the where clause:
{{{
LEFT JOIN wp_postmeta ON wp_posts.ID = wp_postmeta.post_id AND wp_postmeta.meta_key = 'my_custom_field_name'
}}}
Related to ticket #18158 is the question of how we expose this to the developer in the query API.
{{{
'meta_key' => self::get_meta_key( 'my_custom_field_name' ),
'orderby' => 'meta_value',
'exclude_empty_meta' => false
}}}
If this gets any traction I would be happy to submit a patch.",tomauger
Future Releases,29424,Query argument 'orderby' makes duplicated parameters possible; does not support some available columns,,Query,2.5,normal,normal,Future Release,enhancement,new,,2014-08-29T10:22:06Z,2015-01-04T14:10:11Z,"In your newest post in [http://make.wordpress.org/core/2014/08/29/a-more-powerful-order-by-in-wordpress-4-0/ make-blog] there a serveral errors in code.
1. Duplicated parameters are possible. Following Code will output the ""error"":
{{{
$query = new WP_Query( array( 'orderby' => array( 'title' => 'DESC', 'post_title' => 'ASC' ) ) );
//ouputs: ORDER BY post_title DESC, post_title ASC
}}}
2. Why is
* ""title"" equal to ""post_title""
* ""name"" to ""post_name""
* ""author"" to ""post_author""
and so on?
3. By the way, ""date_gmt"", ""post_status"", ""modifed_gmt"", ""content_filtered"", ""mime_type"", ""type"" are missing...
4. there are some columns missing in ""orderby"".",ChriCo
Future Releases,9785,Search Enhancements -- consolidated ticket,,Query,2.8,normal,normal,Future Release,enhancement,reopened,,2009-05-10T23:54:34Z,2015-01-12T01:32:13Z,"Closing the following as dups, pending ""the big search overhaul"" that may never come:
- #5149 -- search everywhere (with committed patch)
- #9230 -- search in post and pages and both
- #5525 -- also search for posts with search query as terms (tags, cats, ...)
- #5054 -- allow to negate keyword on search
- #7394 -- assign greater weight to posts with search query in title
- #7647 -- search in attachment descriptions",Denis-de-Bernardy
Future Releases,20352,Use str_getcsv() to parse search terms in WP_Query,,Query,,normal,normal,Future Release,enhancement,new,has-patch,2012-04-03T23:05:25Z,2015-11-01T15:00:09Z,"We use an [http://core.trac.wordpress.org/browser/tags/3.3.1/wp-includes/query.php#L2183 ugly regex] to split search terms like these:
{{{
term1 term2 ""exact match""
}}}
We could use str_getcsv() instead, for better readability.",scribu
Future Releases,37038,WP_Tax_Query needs caching,,Query,3.1,normal,normal,Future Release,enhancement,new,,2016-06-06T19:13:31Z,2016-09-02T23:35:38Z,"The WP_Tax_Query is a class used to extend the WP_query class (and others) to query the terms and return SQL statement to join object tables. However how it gets the term taxonomy id, performs raw sqls queries that are not cached.
There are number of ways in which caching could be added to method. It could use get_terms to get the wp_term objects and pluck out the require attribute. Or a new cache could be added.",spacedmonkey
Future Releases,23044,adjacent_image_link() needs optimization,,Query,3.5,normal,normal,Future Release,enhancement,new,has-patch,2012-12-22T05:04:20Z,2015-10-07T20:39:44Z,"`adjacent_image_link()` is really slow and stupid. It queries for '''all''' of the images attached to that post. And then it picks the previous or next one in PHP. And there's no caching, so you'll typically get this happening '''three times''' on an attachment page, (image [linked to next], prev link, next link).
We should actually just make the query grab the ONE image we want.",markjaquith
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,35613,Add granularity to REST API embeds,joehoyle,REST API,,normal,normal,Future Release,enhancement,assigned,,2016-01-26T00:13:04Z,2016-04-05T06:22:37Z,"Currently `?_embed` is all or nothing. It'd be good to have some granularity here, for example specifying `?_embed=author` if we need just the post author but don’t want the performance hit of embedding everything else.
@joehoyle wrote a plugin for this ( https://gist.github.com/joehoyle/12e37c293adf2bb0ea1b ) and mentioned that it will be easier to use after #34729 lands.",jnylen0
Future Releases,38813,REST API: Test schema registration for required fields.,,REST API,,normal,normal,Future Release,enhancement,new,,2016-11-16T06:21:36Z,2016-11-16T06:21:36Z,"Follow-up from #38792.
For all endpoints included in WordPress core, we want to make sure arguments and parameters are consistently registered and expose a nice, stable API to the world. While we can check this manually, building it into the unit tests is even better.
@jnylen0 wrote an initial version [https://gist.github.com/nylen/9021f6d19157a023a0a8a607a3adb28a in Node-based JS], so we can port this to PHP and use the built-in schema rather than sending a HTTP request.",rmccue
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-07-20T00:51:47Z,"**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
{{{
}}}
what i can tell this is trying to do is if a user types in just ""domain.com/wp-admin"" that it would redirect them to ""domain.com/wp-admin/"" but the desired results did not happen. the above code would redirect you to ""domain.com/domain.com/wp-admin/"" which obviously would cause issues after the user logs in as the redirect_to would point to http://domain.com./domain.com/wp-admin/ which would cause an endless loop. To fix this problem you need to add a / to the beginning of the rewrite like so
{{{
}}}
that extra / before the wp-admin/ forces it to the root of the site.. now i am not sure what this would do to a site in a sub directory but im not in a sub directory so not an issue for me.",mrevets
Future Releases,13701,Full support for middle and little endian permalink structures,,Rewrite Rules,2.9.2,normal,normal,Future Release,enhancement,reopened,reporter-feedback,2010-06-02T14:34:08Z,2015-10-07T02:20:27Z,"This only happened after I switched over to the WordPress 3.0 development version, so I'm inclined to think it's a bug. When I use the traditional wp_get_archives or the dropdown version it shows that posts exist. However, when I click to go to any of those past posts, I only get a 404 Error. This problem is very consistent, happening 100% of the time. Disabling all plugins has no affect on the problem.
The only other information that might be helpful is that I've integrated WordPress into a website that I built and I am using a custom theme that I built. It only has the index.php, single.php, and style.css files.
Again, the wp_get_archives function worked just fine with the exact same setup that I have now prior to switching to the 3.0 version, so I'm not sure what changed.",RevelationTravis
Future Releases,17185,Optimize verbose attachment rules,,Rewrite Rules,,normal,normal,Awaiting Review,enhancement,reopened,dev-feedback,2011-04-20T00:18:21Z,2015-05-11T17:09:41Z,"Looking at the rules created for verbose pages it seems that there are a large number of redundant rules created specifically for attachments.
For example:
{{{
page-slug/attachment-slug/attachment/([^/]+)/?$ => index.php?attachment=$matches[1]
another-page/another-attachment/attachment/([^/]+)/?$ => index.php?attachment=$matches[1]
page-slug/attachment/([^/]+)/?$ => index.php?attachment=$matches[1]
another-page/attachment/([^/]+)/?$ => index.php?attachment=$matches[1]
...
}}}
As well as the associated trackback, feed and comment page rules for each.
I think we could get rid of specific attachment rewrite rules for pages and their attachments and replace them with a catch-all rewrite for page attachments:
{{{
.+?/attachment/([^/]+)/?$ => index.php?attachment=$matches[1]
}}}
I also set the flag to include paged requests (slug/page/xx/) to false for pages and page attachments for verbose rules. I think think this could also be applied to post rewrite rules and non-verbose page rules since neither are paged, though they have pages (slug/xx/), but I will open another ticket for that. This is the part I am less sure about since myself and others have been confused by the paged rules before (page/xx/), so correct me if I'm wrong here (or anywhere else!).
For the /%postname%/ structure the attached patch cuts the number of rewrites rules for 1297 pages from 14361 to 6562. This translated to a drop from 0.42s to 0.31s average response time in testing (tested using siege with one concurrent user for 30 seconds) on a single post permalink so near the bottom of the rewrite stack for verbose page rules in trunk.
I have run this patch against the current tests for WP_Query and WP_Rewrite (test_query.php in the unit-tests SVN) using several different verbose rewrite structures, including /%postname%/ and /%category%/%postname%/. The only 'fail' was for the test of paged rewrites for pages which I mentioned above (there were a couple of other tests that showed up as fails initially but further investigation proved to be problems with conflicting page and post slugs). This gives me confidence in the patch but even more rigorous testing is definitely required.
I also wrote a patch which utilised a new parameter for generate_rewrite_rules() to disable adding the attachment rules, but this didn't seem so clean.
Related: #16687 which is for %postname% in particular rather than all verbose structures",duck_
Future Releases,16830,url_to_postid() doesn't resolve attachments when rewrite rules are disabled,,Rewrite Rules,1.2,normal,normal,Awaiting Review,enhancement,reopened,dev-feedback,2011-03-11T01:09:14Z,2015-12-31T12:27:49Z,"The code of {{{url_to_postid()}}} is pretty clear in the case of disabled rewrite rules: all URLs not using the {{{p=N}}}, {{{page_id=N}}} or {{{attachment_id=N}}} forms are not parsed and the function return 0. That make sense.
Now there is a special case for attachments. Attachments can be saved under a the {{{/wp-content/uploads/year/month/}}} folder structure while rewrite rules are disabled at the same time.
This means there is a missed opportunity for {{{url_to_postid()}}} to resolve attachment's URLs of the long-form when rewrite rules are disabled.
This was tested and reproduced on WordPress 3.1.",Coolkevman
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:
http://core.trac.wordpress.org/ticket/6603#comment:27
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
Future Releases,16841,Manually created user roles not showing in author dropdown regardless of assigned capabilities,,Role/Capability,3.1,normal,normal,Future Release,defect (bug),new,,2011-03-12T23:39:39Z,2016-06-16T15:37:04Z,"I posted the below on wp-testers hoping to verify or gain experiences from others in order to confirm this prior to reporting it as a bug, but, haven't received any further input, and it's just becoming more evident to me that perhaps it should be posted here, so, I hope I'm not creating a false report here. Please excuse me if I am.
I'm posting this as a link so that it will translate more clearly rather than just cluttering up this message with more text than necessary.
http://lists.automattic.com/pipermail/wp-testers/2011-March/014130.html
Upon further investigation I have also come across the following: #16451
I'm not an expert at debugging this sort of thing, but, I have attempted all within my knowledge thus far, and in looking at all of the returned objects and entries, the only difference I can spot between how the default user roles ( which show up properly in the dropdown ) and the custom created roles ( which do not ) are being returned is that the default user roles, editor for instance, correctly show the deprecated level_7 entry, and the custom user role ( with more assigned privileges than the editor ) does not show user levels in the capabilities array at all, and shows level_0 in the object.
This is leading me to think that perhaps there is something happening with those user levels in creating the author dropdown on the post editor that is blocking the custom user roles from showing up as expected.
When running the following code:
{{{
echo '

Capabilities assigned to the role of ' . $name. '

';
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,36961,wp_roles displays incorrect roles in multisite,,Role/Capability,4.2,normal,normal,Future Release,defect (bug),new,dev-feedback,2016-05-27T18:24:06Z,2016-09-23T08:57:41Z,"The WP_User class accepts a 3rd parameter for a site ID, but this never translates over to roles.
In class-wp-user.php WP_User->_init_caps() the correct capabilities are retrieved from the database, but when WP_User->get_role_caps() gets called, the first thing it does is fire wp_roles() in capabilities.php This will global $wp_roles or if not set, it will initialize a new WP_Roles class.
Where this becomes a problem is if you're not on the site you're checking the roles on, wp_roles() returns the roles of the current site instead. Back in WP_User->get_role_caps(), the arrays get filtered and since there's a mismatch of roles defined on current site vs roles actually assigned to user, you will get an empty array as a result when looking at WP_User->roles
To see this in action, I set up a test multisite install to confirm. I deleted all roles but admin on the main site, then created 2 new arbitrary roles. I then created a second site in the install, deleted all roles but admin, and created another arbitrary role. I added a new user to the install. If I go to network admin and attempt to assign the user to site 2, the roles drop down displays the roles defined on site 1 rather than site 2. If I go to the dashboard of site 2 and go to add the user, I see the correct roles available.
I'm not sure if this is intended behavior, though I can't imagine it is as it leads to a bug in network admin allowing a user to be set to a role that potentially doesn't even exist on the site you assign them to.
I've tested this from WP 4.2-4.5 and get the same results in wp-admin
Logging as roles/capabilities component, because even though it affects multisite, I think the core issue exists in roles and capabilities. ",ryanduff
Future Releases,38433,Complete test coverage for current_user_can_for_blog(),,Role/Capability,4.3,normal,normal,Future Release,enhancement,new,,2016-10-21T14:15:43Z,2016-10-21T14:15:43Z,"In `Tests_User_Capabilities`, all roles and capabilities are tested using `current_user_can()`. They should all be tested using `current_user_can_for_blog()`, too.",johnbillion
Future Releases,33240,Introduce a capability for previewing posts,,Role/Capability,,normal,normal,Future Release,enhancement,assigned,,2015-08-03T11:36:52Z,2016-10-22T12:45:07Z,"In order to preview an unpublished post (ie. draft or pending), a user needs the `edit_posts` capability for that post type ([https://core.trac.wordpress.org/browser/tags/4.2.3/src/wp-includes/capabilities.php#L1174 src]).
There is a valid use case where a site requires a user role which has the capability to preview unpublished posts but not edit them, for example for editorial review/sign-off, layout review, early access, etc.
You can [http://wordpress.stackexchange.com/a/196209/27051 get around this by using a combination of the posts_results and the_posts filters], but this isn't very future-proof because the post results skip a bunch of logic that occurs between those two filters.
A `preview_post` meta capability and a `preview_posts` primitive capability could be introduced and implemented wherever the `edit_posts` capability is used in regard to previewing unpublished posts. By default, it will simply map to the `edit_posts` capability.
Thoughts?",johnbillion
Future Releases,38652,Introduce singular capabilities for managing individual plugins,,Role/Capability,,normal,normal,Future Release,enhancement,new,,2016-11-04T02:57:31Z,2016-11-04T02:58:20Z,"As we did in #35614 for taxonomy terms, singular capabilities should be introduced for activating, deactivating, editing, deleting, and updating individual plugins.
This would allow fine-grained cap checks such as `current_user_can( 'activate_plugin', $plugin_file )`.",johnbillion
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,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,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,31093,Make $tag argument optional for has_shortcode(),,Shortcodes,,normal,normal,Future Release,enhancement,new,dev-feedback,2015-01-21T19:53:17Z,2015-08-23T18:18:41Z,Use case: I'd like to see if my string has ''any'' shortcodes.,danielbachhuber
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,32789,Abstract get_category_by_path into get_term_by_path,,Taxonomy,,normal,normal,Future Release,enhancement,new,,2015-06-25T15:59:01Z,2015-09-19T16:47:58Z,"Having a function like `get_term_by_path` would be great as currently you have to fork the `get_category_by_path` function on your own to get a term by path for any other custom taxonomy.
Would there be any opposition to a patch for this? The abstracted function wouldn't house the `_make_cat_compat` usage, which would remain in the backwards compatible `get_category_by_path` function after checking to see if $category is not null.",sc0ttkclark
Future Releases,13949,Add a sprintf style argument to wp_list_categories() for title tag.,,Taxonomy,,normal,normal,Future Release,enhancement,new,has-patch,2010-06-17T18:01:20Z,2016-08-19T06:09:14Z,"By default, wp_list_categories() will use the value of $term->description for the title tag of every link that it generates. If the argument ""use_desc_for_title"" is set to false, it will produce a string like: ""View all posts filed under $term->name"". With the inclusion of custom post_types into core, it would be wonderful to have more control over this title. The best solution that I can think of is to add a sprintf style argument which will allow themes and plugins to provide a custom format. Something like:
'title_format' => 'View all tacos posted under %s.'
",mfields
Future Releases,30705,Add parameter to get_the_term_list() to allow templating,,Taxonomy,2.5,normal,normal,Future Release,enhancement,new,,2014-12-13T21:32:57Z,2015-01-16T17:14:02Z,"Similar to #27238 the parameter $term_template is suggested to allow for user created formatting for get_the_term_list(), as opposed to the previous standard of simply linking to each list in the term.
The reasoning for the change is that general linking is not always the desired action for displaying term lists. The method for inclusion is similar to [30209].",davidjlaietta
Future Releases,36978,Add pre filter to get_term_by,,Taxonomy,,normal,normal,Awaiting Review,enhancement,new,has-patch,2016-05-30T22:25:13Z,2016-05-30T22:26:08Z,"Like other get get_*_by functions the get_term_by should have a pre filter. This filter should specially be useful to short-circuit the default logic, perhaps to add caching. ",spacedmonkey
Future Releases,23422,Add query filter argument to register_taxonomy,,Taxonomy,,normal,normal,Future Release,enhancement,new,,2013-02-08T12:38:35Z,2016-05-23T16:06:05Z,"Following on from the #21240 ticket which introduced the show_admin_column functionality I would like to suggest an additional argument to easily add the select list query filter for a taxonomy to the post-type list.
Currently a taxonomy query can be added via the 'restrict_manage_posts' action and 'parse_query' filter.
It would be useful to add an additional register_taxonomy argument of 'show_column_filter' to define a standard select option list of the taxonomy terms. Things like default option and hierarchy could be optional settings is an array is passed instead of boolean.
",tifosi
Future Releases,33975,Improve capabilities management when registering custom taxonomy,,Taxonomy,,normal,normal,Future Release,enhancement,new,,2015-09-23T12:02:12Z,2016-07-07T08:51:17Z,"Currently we have such caps when using `register_taxonomy()` [https://codex.wordpress.org/Function_Reference/register_taxonomy#Arguments codex]:
{{{
'manage_terms' - 'manage_categories'
'edit_terms' - 'manage_categories'
'delete_terms' - 'manage_categories'
'assign_terms' - 'edit_posts'
}}}
IMO, setting `manage_terms` to false block access to page (cheating message),
setting `edit_terms` to false displays this message: ""You are not allowed to edit this item."", which is very odd. Editing means editing, So I should not be able to use Quick Edit and Edit links (they should be hidden).
Also, I propose to add a `create_terms` capability maping - for displaying the add term form and giving ability to create them, separately from editing/deleting.
Related: #22511",slaFFik
Future Releases,24386,Make _pad_term_counts work for non-post type objects and attachments,,Taxonomy,,normal,normal,Future Release,enhancement,new,,2013-05-22T18:23:31Z,2015-01-19T17:10:14Z,"If you register a hierarchical taxonomy against a non-post object (such as users), or attachments that aren't associated with another post, _{{{pad_term_counts}}} does bubkus, due to the INNER JOIN on {{{$wpdb->posts}}}, and the check for 'publish' status (which is relevant for attachment post types).
I'm suggesting an alternative approach would be to use $term->count, and eschew going back to the database altogether.",TomAuger
Future Releases,36171,Proposed clean up of get_the_category_list() and link filter,,Taxonomy,4.4.2,normal,normal,Future Release,enhancement,new,has-patch,2016-03-08T17:09:25Z,2016-03-14T05:43:52Z,"The current source code of the {{{get_the_category_list()}}} function is quite messy and there is also a lot of duplicate code which we can avoid.
Also, on a micro optimization level, in stead of passing the category ID to {{{get_category_link()}}}, we can pass the whole category object. Doing this will avoid the extra overhead of having to get the complete category object from the term cache.
There is also no filter to filter each category link on category level, we only have the {{{the_category}}} filter which filters the string of links. We have being receiving a couple of questions on wordpress.stackexchange.com regarding filtering these category links according to category. [http://wordpress.stackexchange.com/q/219554/31545 Here] is such one question.
My proposal is included in my code, a filter called {{{the_category_list_links}}} which we can use to filter each category link individually according to the category. One such use-case of the filter can look something like
{{{
add_filter( 'the_category_list_links', function ( $the_link_list, $category, $cat_parents )
{
$category_color = get_field( 'category_color', $category );
if ( !$category_color )
return $the_link_list;
$the_link_list = str_replace( 'using_permalinks() ) ? 'rel=""category tag""' : 'rel=""category""';
$links = array();
foreach ( $categories as $category ) {
/**
* Break the link for better link building
*/
$start_link = 'term_id ) ) . '"" ' . $rel . '>';
$end_link = $category->name . '';
/**
* Build the category links
*/
$the_link_list = '';
switch ( strtolower( $parents ) ) {
case 'multiple':
$cat_parents = $category->parent ? get_category_parents( $category->parent, true, $separator ) : '';
$the_link_list = $cat_parents . ' ' . $start_link . $end_link;
break;
case 'single':
$cat_parents = $category->parent ? get_category_parents( $category->parent, false, $separator ) : '';
$the_link_list = $start_link . $cat_parents . $end_link;
break;
case '':
default:
$the_link_list = $start_link . $end_link;
}
/**
* Filter the category links on category level.
*
* @since X.X.X
*
* @param string $the_link_list Post category link.
* @param object $category The current category object
* @param $cat_parents Link list of parents of the current category
*/
$links[] = apply_filters( 'the_category_list_links', $the_link_list, $category, $cat_parents );
}
$thelist = '';
if( '' === $separator ) {
$thelist .= '

';
$thelist .= ""\n\t

"";
$thelist .= implode( ""

\n\t

"", $links );
$thelist .= '

';
$thelist .= '

';
} 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,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:
{{{
#!php
$object_ids = get_objects_in_term(array(55, 66, 77, 88, 99), ""my_custom_taxonomy"");
}}}
Might return an array of object_ids as follows:
{{{
#!php
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,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,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,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`
== '''WHY'''??? ==
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
[[Image(https://farm8.staticflickr.com/7320/26928024935_6f3cc3c8e7_k.jpg)]]
----
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,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, &nbsp, and U+00A0",,TinyMCE,,normal,normal,Future Release,defect (bug),new,,2014-01-15T17:03:31Z,2016-12-02T02:57:26Z,"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,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
**Scenario:**
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,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,2016-10-16T16:50:46Z,"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,2016-07-25T23:07:52Z,"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,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:
{{{
get_the_author_link()
the_author_link()
get_the_author_posts()
the_author_posts()
the_author_posts_link()
get_author_posts_url()
wp_list_authors()
}}}
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-07T12:23:02Z,"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).
{{{#!php
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 )
WHERE 1=1
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-11-08T20:14:39Z,"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,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,2016-01-08T17:10:17Z,"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,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,2016-06-06T20:43:31Z,"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
Future Releases,32417,Add new core media widget,wonderboymusic,Widgets,4.3,normal,normal,Future Release,feature request,assigned,has-patch,2015-05-16T03:14:25Z,2016-10-14T17:14:08Z,"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,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
Future Releases,13835,XLM-RPC API should return commentmeta values,josephscott,XML-RPC,2.9,normal,normal,Future Release,feature request,reopened,,2010-06-10T23:28:58Z,2015-12-03T15:48:05Z,"This ticket is a follow up on my Twitter and subsequently email conversation with Joseph Scott (josephscott) about the new commentmeta table in WordPress 2.9 and the XML-RPC API. We use the plugin Feature Comments (http://wpprogrammer.com/feature-comments-wordpress-plugin/) for hiding or featuring certain comments. The plugin stores either a value of 'Buried' or 'Featured' in the commentmeta table and uses these values to append a css class to comment_class.
I'd love to retrieve these commentmeta values (buried/features) through the XML-RPC API (which we use) with wp.GetComment or wp.GetComments, so we're able to programmatically hide or feature these comments in our own iPhone app.
Please note this is a specific example, but my request should I no way be seen as a private request. I think the commentmeta in 2.9 was a great addition for stuff like Twitter usernames, mood, gender, and so forth. I hope we're able to retrieve these values programmaticaly through the API as well.",djr