';
} 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,needs-unit-tests,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,needs-unit-tests,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,needs-unit-tests,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
Next Release,9264,Self closing shortcodes,westi,Shortcodes,2.7.1,normal,normal,3.3,defect (bug),closed,needs-unit-tests,2009-03-02T23:06:19Z,2012-11-01T00:15:05Z,"First bug report, be gentle.
I've noticed that the shortcode regex doesn't take note of the self closing ""/"" properly, and continues to search for a closing tag within the content passed to it.
I think it should stop looking for a closing tag if the tag is self closing. See the following example:
{{{
[test id=""1""/] first self closed, now [test id=""2""]with content[/test]
}}}
This gets sent to the shortcode callback function as:
'''Attributes:''' id=""1""
'''Content:''' first self closed, now [test id=""2""]with content
I've posted some further tests at http://blograndom.com/tests/shortcode/ , to prove the bug exists and my proposed fix (see attached diff file). The fix also offers slight speed enhancements for self closing divs because it stops looking.
It looks like the trunk version of shortcodes.php is slightly different to 2.7.1, but I've applied the patch from the trunk version which still seems to have the same problem.",rb-cohen
Next Release,10082,Shortcodes need a character separating them to work,,Shortcodes,2.8,high,major,3.3,defect (bug),closed,needs-unit-tests,2009-06-09T20:21:27Z,2013-10-30T03:35:15Z,"the following works:
{{{
[media id=""448""]test[/media]
[media id=""448""]test[/media]
}}}
the following doesn't:
{{{
[media id=""448""]test[/media][media id=""448""]test[/media]
}}}
",Denis-de-Bernardy
Next Release,14481,Shortcode Enhancements,,Shortcodes,3.0,normal,normal,,enhancement,closed,needs-unit-tests,2010-07-30T22:37:23Z,2015-08-23T02:03:39Z,"Somewhat of a copy of a post to wp-hackers: I wrote my own implementation of shortcodes. It does things a bit differently, has nested evaluation, and allows self-nesting. Since there are some significant differences to the existing implementation,
A lot of the changes are borrowed from definitions in the HTML specification (particularly name and attribute matching). The following are the comments at the top of my shortcode file. I tried to keep track of all the differences (and questions) there.
== From Test Cases ==
(http://svn.automattic.com/wordpress-tests/wp-testcase/test_shortcode.php)
{{{
Shortcode Statuses (to implement, or not to implement?)
enabled = the shortcode works as normal (default)
strip = the shortcode will be parsed and removed. e.g.
'[shortcode foo=""bar""]' produces ''. '[shortcode]foo[/shortcode]'
produces 'foo'.
faux = the shortcode will be abbreviated. e.g. '[shortcode
foo=""bar""]' products '[shortcode]'. '[shortocde]foo[/shortcode]'
produces '[shortcode]'
disabled = the shortcode is not parsed at all. e.g.
'[shortcode foo=""bar""]' products '[shortcode foo=""bar""]'
}}}
== Major Differences/Improvements ==
I. Addressing http://codex.wordpress.org/Shortcode_API#Limitations
1. You can nest any tag at any depth regardless of ancestors (#10702)
2. Tag and attribute names may match: `/[A-Za-z][-A-Za-z0-9_:.]*//*` (trialing /* because that comment ends), with case-insensitive interpretation
3. Interpretation doesn't get tripped up by things like hyphens
== II. Addressing Ticket #12760, ==
1. Changed from fix in #6518. Reasoning: balancing double-square-brackets can have misleading results with nesting
2. Shortcodes escapable by using `[[`, `]]`
3. `]]` is escaped ""right to left"", so `[shortcode]]]` would evaluate to `result]`
4. '[[' is escaped left to right `[[[shortcode]]]` => `[result]`
== III. Enhancements ==
1. Only matches valid shortcode for registered hooks, everything else will appear as text
2. Can register multiple hooks to single shortcode, uses priority (default: 10)
== IV. Conflicting Design Changes ==
1. Quoted literals are escaped by entities rather than cslashes
2. Inline (self-closing) shortcodes get passed content to accomodate multiple callbacks
3. No equivalent to shortcode_parse_atts function (Not marked private in function reference, but not documented in shortcode API page)
4. Boolean attributes take the place of positional attributes `[foo bar]` gets attributes `array('bar' => 'bar')` instead of `array('0' => 'bar')`
5. Disallows attribute and tag names that don't match `/[A-Za-z][-A-Za-z0-9_:.]*/`
6. Disallows unquoted attribute values (also boolean attributes), unless they match `/[-A-Za-z0-9_:.]+/`
== Basic Interpretation Method ==
1. If an open tag is encountered, it is added to the stack
2. If a close tag is encountered and there is no matching open tag on the stack the close tag is ignored
3. If a close tag is encountered and there is a matching open tag on the stack all opened tags on the stack before the matched tag will be implicitly self-closed
4. If text or an inline tag is encountered, it will be evaluated to its parent's content immediately
5. If tags are not closed by the end of the interpretation, they will be implicitly self-closed
== Issues ==
1. Haven't written new unit tests to reflect new functionality added, functionality differences
2. Documentation is not as good (though I hope most of the code is self-explanatory)
3. Not 100% backwards compatible",deadowl
Future Releases,24990,Nested Shortcode Inside [caption],,Shortcodes,3.6,normal,normal,Future Release,defect (bug),new,needs-unit-tests,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,needs-unit-tests,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,needs-unit-tests,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,11623,review options list and update sanitize_option(),dd32*,Security,2.9,normal,normal,Future Release,defect (bug),accepted,needs-unit-tests,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
Next Release,30518,WP_Dependencies::recurse_deps can recurse infinitely,,Script Loader,4.0,normal,normal,,defect (bug),closed,needs-unit-tests,2014-11-27T00:04:43Z,2015-04-03T20:19:43Z,"Script dependencies can recurse infinitely (unto memory exhaustion, etc.)
http://i.imgur.com/uVHDCpX.png
Patch attached, sets a maximum depth and when it is reached stops recursion.",ccomp5950
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,needs-unit-tests,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,needs-unit-tests,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,needs-unit-tests,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
Next Release,33694,Capability missing for editing scheduled posts created by one self (implicit permission bypass),johnbillion,Role/Capability,2.0,normal,normal,4.4,defect (bug),closed,needs-unit-tests,2015-09-02T20:02:44Z,2016-08-30T15:29:26Z,"The following capabilities exist today in the Wordpress privilege system:
Edit Posts
Edit Others Posts
Edit Published Posts
Publish Posts
The standard Wordpress role ""Contributor"" only has the capability ""Edit Posts"" out of the four above, which in reality translates to ""Edit posts only created by one self"".
This is good, because editorial staff can then edit the posts before they are published, which is the entire purpose of this role, i.e. a contributor can never publish any content that has not first been vetted by senior staff.
BUT, there is a dangerous logic hole in this permission system right now, which makes it possible for the contributor role to publish arbitrary contents after all!
Namely, when a post created by a ""contributor"" has been edited by senior staff and subsequently scheduled for publishing (say, in three hours), the permission system apparently still considers the post as both ""non-published"" and still ""owned by its initial creator"", i.e. the ""contributor"" user. Thus, the current permission setup in Wordpress and for the contributor roles does in this situation allow the ""contributor"" user to freely modify the contents of the post, and subsequently thus have these arbitrary modifications published on the pre-scheduled moment in time.
In addition to the fact that scheduled posts most of the time won't be re-visited by the editorial staff before being published (thus giving lots of time for the original ""contributor"" user to edit them even without any malicious intent), this can also be exploited with explicit malice by such a ""contributor"" user, by purposely making the desired edits to the post, say, five seconds before the scheduled publishing time, thereby having these new contents published instantly thereafter, before any members of the editorial staff has had any chance to vet these changes, or most of the time even know of them.
There are two possible simple solutions to this problem, out of which I therefore suggest you choose one for implementation as soon as possible:
1.
Make the permission system consider scheduled posts as ""Published"" already from the moment they are scheduled, thus blocking any edits of them given already today's alotted capabilities in Wordpress for the ""contributor"" role.
2.
Add a new capability to the permission system called ""Edit Scheduled Posts"", which the ""contributor"" role does NOT have by default, therefore blocking this role from editing scheduled posts, EVEN if they are originally created by the ""contributor"" user in question.
",SimpleBugReporter
Next Release,25597,The capability used for managing tags should be separate from that for categories,johnbillion,Role/Capability,2.3,normal,normal,,defect (bug),closed,needs-unit-tests,2013-10-15T14:25:32Z,2016-08-31T21:02:46Z,"The capability used for managing categories is `manage_categories`. Guess what it is for managing tags? It's not `manage_tags`, nor `manage_post_tags`. It's `manage_categories` too.
This causes a problem when you're trying to control capabilities for tags and categories separately.
The patch to change the capability for tags to `manage_post_tags` is a simple one, but it could potentially introduce an issue where people who have the `manage_categories` capability would no longer be able to manage tags.
Thoughts? Should this be changed?",johnbillion
Next Release,38303,register_meta and capabilities aren't working as expected,rmccue,Role/Capability,4.6,normal,normal,4.8,defect (bug),reopened,needs-unit-tests,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,21786,remove_cap can't unset a negative capability,ryan,Role/Capability,,normal,minor,3.5,defect (bug),closed,needs-unit-tests,2012-09-04T09:17:13Z,2012-09-21T13:42:29Z,"WP_User::add_cap() accepts two parameters -- the second decides if a user does or does not have the capability. I.E.:
{{{
$user->add_cap( 'foo', false );
}}}
means a user will not have a capability that any role otherwise allows.
WP_User::remove_cap( 'foo' ) incorrectly does an empty() check rather than ! isset(), preventing negative capabilities from being unset from a users individual capabilities array.
This makes it impossible to revert negative capabilities without first making them positive, and then removing them.
See: #9128",johnjamesjacoby
Next Release,29714,user_can_access_admin_page() returning false for edit.php?post_type=CPT,,Role/Capability,4.0,normal,normal,,defect (bug),closed,needs-unit-tests,2014-09-20T12:30:26Z,2014-11-23T17:11:29Z,"I have a Custom Post Type (CPT) for which I intend to allow registered subscribers the capability to edit posts, but not create posts or manage the custom taxonomies for the posts.
In this example the CPT is ""oik_site"" - plural label ""Sites""
When the registered user is logged and viewing the Dashboard then the admin menu correctly shows the only available option; Sites - which invokes wp-admin/edit.php?post_type=oik_site
When the user clicks on the link WordPress dies with ""You do not have sufficient permissions to access this page.""
The expected result is that the user should be shown the list of sites, without the Add New button.
I have tracked the problem down to what I believe to be a bug in user_can_access_admin_page().
The ""oik_site"" CPT is defined with
{{{
$post_type_args['capability_type'] = 'oik_site';
$post_type_args['capabilities'] = array( 'create_posts' => 'create_oik_sites' );
$post_type_args['map_meta_cap'] = true;
}}}
The 'create_posts' capability is defined as 'create_oik_sites', overriding the default 'edit_oik_sites'.
Subscribers are given the 'edit_oik_sites' capability only.
'''Where it goes wrong...'''
The processing in wp-admin/includes/menu.php has correctly checked the user's capability to ""edit_oik_sites"" and the admin menu has been simplified so that the 'All Sites' sub menu item is no longer displayed.
Since the user doesn't have either create_oik_sites nor manage_categories the Add New and Custom Taxonomy submenu items have been deleted.
Everything seems fine until we call user_can_access_admin_page().
Here it determines $parent to be null and $pagenow to be ""edit.php"".
$wp_menu_nopriv is correctly set to the menu items that the subscriber cannot use
{{{
[edit.php] => 1
[upload.php] => 1
[link-manager.php] => 1
[edit.php?post_type=page] => 1
[edit-comments.php] => 1
...
}}}
Note: edit.php?post_type=oik_site IS NOT SET in the $wp_menu_nopriv array.
Since these tests are true the function returns false.
{{{
if ( empty( $parent) ) {
if ( isset( $_wp_menu_nopriv[$pagenow] ) )
return false;
}}}
Had the second test taken into account the post_type being edited then this would not have failed.
'''Proposed fix'''
Adding the following code after the test on empty( $parent ) gives the expected results.
{{{
if ( $pagenow == ""edit.php"" && isset( $_REQUEST['post_type'] ) ) {
$pagenow .= '?post_type=' . $_REQUEST['post_type' ];
}
}}}
",bobbingwide
Next Release,39205,Replace is_super_admin() check with current_user_can( 'upgrade_database' ),flixos90,Role/Capability,,normal,normal,4.8,enhancement,assigned,needs-unit-tests,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
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,needs-unit-tests,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,needs-unit-tests,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,needs-unit-tests,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,needs-unit-tests,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,needs-unit-tests,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,needs-unit-tests,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,38653,Trigger a doing it wrong when checking a role name as a capability,,Role/Capability,,low,normal,Awaiting Review,enhancement,new,needs-unit-tests,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,11384,rewrite->flush() needlessly deletes the rewrite_rules option,,Rewrite Rules,2.9,normal,normal,,defect (bug),closed,needs-unit-tests,2009-12-10T13:39:52Z,2016-01-10T19:03:06Z,"All sorts of cache-related plugins hook into the update_option_rewrite_rules and force-flush whatever they're caching when rewrite_rules are updated.
When a page is saved, WP_Rewrite::flush() mindlessly deletes the rewrite_rule option, triggering all sorts of cache flushing that may or may not be necessary.
The attached patch keeps the rewrite_rules option intact when a soft refresh occurs.
Tests done:
- non-verbose rules used, page changes parent: no refresh
- verbose rules used, page changes parent: refresh
Dunno what else needs to be testing...",Denis-de-Bernardy
Future Releases,35482,Archival pagination fails in 4.4 and up,,Rewrite Rules,,normal,normal,Awaiting Review,defect (bug),new,needs-unit-tests,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,needs-unit-tests,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,needs-unit-tests,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,needs-unit-tests,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,needs-unit-tests,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,needs-unit-tests,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,needs-unit-tests,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,needs-unit-tests,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,needs-unit-tests,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
Next Release,26042,wp_save_post_revision() can compare against the wrong $last_revision post,wonderboymusic,Revisions,,normal,major,4.0,defect (bug),closed,needs-unit-tests,2013-11-15T04:30:59Z,2014-05-22T18:50:12Z,"There is a unit test that now consistently fails: `Tests_Post_Revisions::test_revision_dont_save_revision_if_unchanged()`. After some substantial debugging, I have determined that ordering post revisions by `post_date DESC` is completely unreliable when posts are added within seconds or milliseconds of each other, even when `post_date` is explicitly set to increment on `wp_update_post()` because the revisions still occur with milliseconds of each other, regardless of what the post's `post_date` is.
When all revisions occur in nearly unison, ordering becomes moot. Sometime the revisions return `DESC`. Sometimes they awesomely return in `ASC` order, which makes `the $last_revision` that `$post` is compared against the first revision.
The only way to combat this is to sort in `wp_get_post_revisions()` by `ID DESC`. All of the unit tests pass with this change. Is there any reason we can't rely on sequential posts `DESC` for ordering?
",wonderboymusic
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,needs-unit-tests,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
Next Release,39072,Add gmt_offset as a REST API setting,,REST API,4.7,normal,normal,4.7.1,defect (bug),new,needs-unit-tests,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,38483,REST API: (CPT) Status handling doesn't account for edit_published_posts,rachelbaker,REST API,4.7,normal,normal,,defect (bug),closed,needs-unit-tests,2016-10-25T12:21:29Z,2016-10-31T01:58:10Z,"Moving this ticket over from Github: https://github.com/WP-API/WP-API/issues/2050.
JakePT commented on Jan 18:
''I'm trying out the API for the first time, and am enjoying it greatly, but I've run into one issue that I can't seem to get around.''
''The issue is a mismatch between how wp-admin handles post editing capabilities and the API does.''
''I have a Custom Post Type, item, and have map_meta_cap set to true, and capabilitiy_type set to array( 'item', 'items' ). I have given the Administrator role the all the capabilities, but only given Editor edit_items edit_others_items and edit_published_items.''
''In wp-admin it works as expected, the user can edit existing Items, even ones created by others, but cannot publish new ones (only submit them for review), and they can't delete them. This is exactly what I want.''
''The problem is that with the API when an Editor submits an update to an Item, if the model's status is set to publish the API always checks for current_user_can( $post_type->cap->publish_posts ), even if the post was previously published.''",adamsilverstein
Next Release,38610,Set `format` enum based on the post formats registered to the theme,rmccue,REST API,,normal,normal,4.7,defect (bug),closed,needs-unit-tests,2016-11-01T19:25:28Z,2016-11-02T16:22:05Z,"In the Post schema, we're registering the `enum` based on `get_post_format_slugs()`, which returns all slugs, not those specific to the theme.
Instead, we should make sure the `enum` is specific to the post formats supported by the theme.",danielbachhuber
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,needs-unit-tests,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,34999,Calling wp_die() in a REST API request should return valid JSON,,REST API,4.4,normal,normal,,enhancement,closed,needs-unit-tests,2015-12-11T00:21:43Z,2016-04-11T23:10:26Z,"See https://github.com/WP-API/WP-API/issues/790, whenever `wp_die()` is used in an API Request (which ideally it should not, but it can still happen) we should return a valid JSON response with the error.
I've been working on this, and started with an initial patch which just output the JSON and called exit, however this circumvents the rest of the API's routing etc _post_ die as script execution must stop at that point.
I ended up using PHP exceptions, which I know it not that common within WordPress, however this is the only way we can stop PHP execution of the scope that call `wp_die()` and still have the REST API handle the response as usual, as if the endpoint returned a WP_Error, essentially.
Attached a patch that implements this, though right now is a hack to checking if wp_die() caused the exception, this should use a `WP_Die_Exception` class if we actually decide to do this.",joehoyle
Future Releases,35613,Add granularity to REST API embeds,joehoyle,REST API,,normal,normal,Future Release,enhancement,assigned,needs-unit-tests,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,needs-unit-tests,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
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,needs-unit-tests,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
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,needs-unit-tests,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
Next Release,35115,404 error when URL includes title=...,pento,Query,4.4,normal,normal,4.4.1,defect (bug),closed,needs-unit-tests,2015-12-16T03:51:27Z,2015-12-21T08:35:16Z,"Our web site is broken since upgrading to WordPress v4.4. We have several pages where we pass parameters in the URL. Since 4.4, any URL which includes ""title="", where is any text at all, results in a 404 error.
Our permalinks are of the post name format (""/%postname%/""). I have not tested this with any other permalink formats, as changing permalinks would also break our site.
To reproduce, simply add ""?title=test"" to any page URL, at least while using post name permalinks.",Fuse99
Next Release,25380,Allow posts_per_page option for pre_get_posts action hook on feed,wonderboymusic,Query,3.6.1,normal,normal,3.9,defect (bug),closed,needs-unit-tests,2013-09-22T06:05:10Z,2014-03-07T18:58:34Z,"This is a patch to fix an issue where posts_per_page option for pre_get_posts action hook does not work while is_feed() is true.
For example, this code can't change the number of posts per page in a feed.
{{{
is_main_query() )
return;
if ( is_feed() ) {
// Display 50 posts for the feed
$query->set( 'posts_per_page', 50 );
}
}
add_action( 'pre_get_posts', 'my_pre_get_posts_for_feed', 1 );
}}}",wokamoto
Next Release,26775,Fatal error in wp_reset_postdata(),SergeyBiryukov,Query,3.7,normal,normal,3.8.1,defect (bug),closed,needs-unit-tests,2014-01-05T14:16:48Z,2014-01-28T04:29:15Z,"[25601] introduced a [https://www.google.com/search?q=""Call%20to%20a%20member%20function%20reset_postdata()%20on%20a%20non-object"" fatal error] when calling `wp_reset_query()` or `wp_reset_postdata()` without a valid `$wp_query` global:
{{{
Fatal error: Call to a member function reset_postdata() on a non-object in wp-includes/query.php on line 118
}}}
We should probably add a `_doing_it_wrong()` message in there, but at least let's fix the fatal error.",SergeyBiryukov
Next Release,36953,Meta lazyloading can cause excessive calls to object cache,DBrumbaugh10Up,Query,,normal,normal,4.6,defect (bug),closed,needs-unit-tests,2016-05-26T16:36:34Z,2016-07-07T14:35:14Z,"`WP_Query` calls `wp_queue_posts_for_term_meta_lazyload()`, which in turn grabs the `{$taxonomy}_relationships` cache for each found post, for each taxonomy that they belong to. So if you're fetching 20 items, and each item is in 10 taxonomies, the process will require 200 cache gets. This is in addition to the dozens of other other cache priming gets that happens in `WP_Query`.
On very high traffic sites running an object cache backend, the high volume calls to the cache can cause performance issues.
A truly general fix would be `wp_cache_get_multi()`, which would allow functions like this to reduce cache roundtrips by one or two orders of magnitude. See #20875.
In the meantime, two things to explore:
1. `WP_Query` decides whether to queue posts for termmeta lazyloading based on the value of 'update_term_meta_cache'. This should be more fine-grained. A new `WP_Query` parameter `lazyload_term_meta`, which would default to the value of `update_term_meta`, seems appropriate. This way, very high-traffic sites that don't use termmeta and thus don't need to lazyload it can disable the feature in a targeted way, via a `pre_get_posts` callback.
2. Look for ways to cut back on cache queries in the lazyload process. Not sure if that's feasible, since different posts keep their taxonomy relationships in different cache buckets, but it's worth looking into.
1 should be doable for 4.6.
cc @patrickgarman, who brought this to my attention.",boonebgorges
Next Release,23268,NOT EXISTS meta query with OR relation,wonderboymusic,Query,3.5,normal,normal,3.9,defect (bug),closed,needs-unit-tests,2013-01-22T21:14:14Z,2015-02-06T19:58:04Z,"
With this meta query ( which is trying to exclude posts that have the app_exclude checkbox checked, without excluding posts that don't have it set at all )
{{{
$query['meta_query'] = array(
'relation' => 'OR',
array(
'key' => 'app_exclude',
'compare' => 'NOT EXISTS'
),
array(
'key' => 'app_exclude',
'compare' => '!=',
'value' => '1'
),
);
}}}
I'd expect / hope to get this sql.
{{{
SELECT SQL_CALC_FOUND_ROWS
wp_posts.ID
FROM
wp_posts
LEFT JOIN
wp_postmeta ON (wp_posts.ID = wp_postmeta.post_id AND wp_postmeta.meta_key = 'app_exclude')
INNER JOIN
wp_postmeta AS mt1 ON (wp_posts.ID = mt1.post_id)
WHERE
1 = 1 AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish') AND (wp_postmeta.post_id IS NULL
OR (mt1.meta_key = 'app_exclude' AND CAST(mt1.meta_value AS CHAR) != '1'))
GROUP BY wp_posts.ID
ORDER BY wp_posts.post_date DESC
LIMIT 0 , 6
}}}
but I get this SQL
{{{
SELECT SQL_CALC_FOUND_ROWS
wp_posts.ID
FROM
wp_posts
LEFT JOIN
wp_postmeta ON (wp_posts.ID = wp_postmeta.post_id AND wp_postmeta.meta_key = 'app_exclude')
INNER JOIN
wp_postmeta AS mt1 ON (wp_posts.ID = mt1.post_id)
WHERE
1 = 1 AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish')
AND (wp_postmeta.post_id IS NULL AND (mt1.meta_key = 'app_exclude' AND CAST(mt1.meta_value AS CHAR) != '1'))
GROUP BY wp_posts.ID
ORDER BY wp_posts.post_date DESC
LIMIT 0 , 6
}}}
Note the... (wp_postmeta.post_id IS NULL '''AND''' (mt1.meta_key = 'app_exclude' AND CAST(mt1.meta_value AS CHAR) != '1'))",timfield
Next Release,22967,Null value in meta query changes the type of comparison,wonderboymusic,Query,3.5,normal,normal,3.8,defect (bug),closed,needs-unit-tests,2012-12-17T00:05:35Z,2013-11-08T22:51:03Z,"If a null value is set in a meta query, it effectively returns the same results as setting the 'compare' arg to 'EXISTS', even if it's explicitly set to the default '='.
For example:
{{{
$value_var = null;
...
meta_query => array(
array(
'key' => '_my_meta_key',
'value' => $value_var,
'compare' => '='
)
)
...
}}}
That returns all rows where '_my_meta_key' exists and ignores 'value' instead of treating it like an empty string. This can be troublesome where the value is passed in dynamically like the example, so validation would have to be done prior to every meta query to ensure the value isn't null.
I've attached a patch for review that checks for the existence of the 'value' key rather than using `isset` and casts it to a string if it's null.",bradyvercher
Next Release,21779,"Querying Taxonomies (Tag) containing the sequence ""-נ-"" *still* fails.",nacin,Query,,normal,normal,3.5,defect (bug),closed,needs-unit-tests,2012-09-03T15:10:37Z,2015-01-08T07:54:55Z,"The issue described in #13413
Still exists on IIS at least and seems to have only ever been fixed for a brief period of time between 3.1 and 3.1.1
Same steps, latest trunk:
1. Created a Tag ""test -נ- end""
2. Added the Tag to a Post
3. Pressed that Tag in my Tag Cloud
4. Get the not Found Message.
System:
* Windows/IIS 7
* PHP 5.4.6
Changing the preg_*() calls in parse_tax_query() to include the /u modifier or changing \s to \r\n\t do seem to fix this issue.
Tested WordPress 3.1, 3.1.1, 3.1.4, 3.2, 3.4.1 and latest trunk.
I've tried to track down the history of this bug. It is ""fixed"" in 3.1, but after 3.1.1 tag queries with the letter nun returned all posts:
* http://core.trac.wordpress.org/changeset/17500/trunk/wp-includes/query.php
The new preg_split() with the problematic \s is in effect, which splits the tag into two (non-existing) terms. Due to a (different) bug fixed in 3.2 all posts are returned.
After 3.2 no posts are returned.
* http://core.trac.wordpress.org/changeset/17686/trunk/wp-includes/taxonomy.php
The underlying cause of the bug, unfortunately, has not been fixed.
",rstern
Next Release,16373,Wrong page loaded requesting custom registered query_vars when correcting is_* for page_on_front requests,markjaquith,Query,3.0,high,normal,,defect (bug),closed,needs-unit-tests,2011-01-25T21:51:12Z,2014-01-26T16:51:28Z,"* Install vanilla WP 3.0.4.
* Register a new 'qv_test' query var in the default theme's function.php file.
{{{
function custom_query_vars_test ($vars) {
$vars[] = 'qv_test';
return $vars;
}
add_filter('query_vars','custom_query_vars_test');
}}}
* Create a 'Home' page.
* Under Settings → Reading set the 'Front page displays' setting to 'A static page (select below' and set the 'Front page:' setting to the 'Home' page.
* Load the front end page.
* Add the 'qv_test' query var to the request (e.g. http://blogurl.com/?qv_test=test)
The wrong page is loaded.
Adding an invalid query_var (one that is not registered) continues to correctly load the page.
The issue occurs regardless of permalink configuration.
This issue appears related to #12047 and is either a regression from the fixes applied to that issue, or is simply case not covered by the fixes. Changes in revision [14445] also relate to #12047.
This issue still exists as of at least 3.0.4 up to 3.1-RC3.
",jondavis
Next Release,33211,get_adjacent_post is not working with post_format,,Query,,normal,normal,,defect (bug),closed,needs-unit-tests,2015-07-31T01:36:13Z,2015-07-31T08:48:25Z,"When I was creating a custom post navigation function today for a client with WP 4.2.3, specifically for post formats, I noticed that the following does not return adjacent posts, even though they exist. I'm not sure if this has ever worked or is a regression. Has anyone been successful in using `get_adjacent_post` with `post_format`?
{{{
$prev = get_adjacent_post( true, '', true, 'post_format' );
$next = get_adjacent_post( true, '', false, 'post_format' );
}}}",valendesigns
Next Release,8885,get_posts() should default orderby post_date_gmt,,Query,2.7,normal,normal,,defect (bug),closed,needs-unit-tests,2009-01-19T13:03:12Z,2016-09-01T08:02:35Z,"the function get_posts() in posts.php is defaulted to orderby post_date. The problem with this is if entries are added in differing timezones (e.g., I changed my system timezone after x number of posts have been made), then the sorting is incorrect. Since post_date_gmt is correct despite the timezone you are in, sorting based on this should be the default behavior.",caorongjin
Next Release,31723,is_page( false ) === true ?,,Query,,normal,normal,,defect (bug),closed,needs-unit-tests,2015-03-21T16:06:44Z,2015-05-06T14:48:52Z,"https://developer.wordpress.org/reference/classes/wp_query/is_page/
''Is the query for an existing single page?''
But this really does not make sense to me:
{{{
if ( empty( $page ) )
return true;
}}}
Is there a reason that is_page() will return true on empty, false, 0 values?
",Compute
Next Release,28012,orderby post__in interferes with menu_order,,Query,3.9,normal,normal,,defect (bug),closed,needs-unit-tests,2014-04-24T14:27:30Z,2015-08-24T01:30:59Z,"Hi,
with Version 3.9 the following issue came up.
{{{
$query_pages = array(3,9,6,2,10);
$pagequery = array(
'posts_per_page' => count($query_pages),
'post_type' => 'page',
'post__in' => $query_pages,
'orderby'=> 'post__in');
query_posts($pagequery);
}}}
When running through the loop, all posts on my front end have the same order as they have inside the $query_pages array. But once a post has a menu_order value like 1 or 2 it gets forced to the end of the loop and the order is distorted.
Page Structure inside Dashboard:
-- Page ( ID 3 )
--- child of Page 3 with ( ID 6 and menu order 2 )
--- child of Page 3 with ( ID 9 and menu order 1 )
-- Page ( ID 2 )
-- Page ( ID 10 )
Expected Output by using the above code:
-- Page ( ID 3 )
-- Page ( ID 9 )
-- Page ( ID 6 )
-- Page ( ID 2 )
-- Page ( ID 10 )
Generated Output
-- Page ( ID 3 )
-- Page ( ID 2 )
-- Page ( ID 10 )
-- Page ( ID 9 )
-- Page ( ID 6 )
",Matthias82
Next Release,16472,set_query_var() / get_query_var() does not work for NULL values,,Query,,normal,normal,,defect (bug),closed,needs-unit-tests,2011-02-06T16:08:06Z,2014-02-02T06:16:59Z,"Setting a query var to NULL will convert it into an empty string:
{{{
$name = 'test';
$value = NULL;
set_query_var($name, $value);
$get = get_query_var($name);
echo $value === $get ? 'same' : 'different';
var_dump($get);
}}}
This will output ""different"" and showing that the query var now is an empty string.",hakre
Next Release,27193,tax_query returns only partial results,,Query,1.5,low,normal,,defect (bug),closed,needs-unit-tests,2014-02-24T01:46:56Z,2014-12-15T07:53:28Z,"Querying by taxonomy using WP_Query returns unexpected results. It appears only the first criteria is matched.
=== Premises ===
Post 1 is in category 'category1'. `$category1` is the term_id.
Post 2 is in category 'category2'. `$category2` is the term_id.
Post 3 is in tagged with 'tag1'. `$tag1` is the term_id.
Post 4 is in tagged with 'tag2'. `$tag2` is the term_id.
{{{
$category1 = $this->factory->term->create( array( 'taxonomy' => 'category', 'name' => 'alpha' ) );
$category2 = $this->factory->term->create( array( 'taxonomy' => 'category', 'name' => 'beta' ) );
$tag1 = $this->factory->term->create( array( 'taxonomy' => 'post_tag', 'name' => 'gamma' ) );
$tag2 = $this->factory->term->create( array( 'taxonomy' => 'post_tag', 'name' => 'delta' ) );
$post_id1 = $this->factory->post->create( array( 'post_title' => 'alpha', 'post_category' => array( $category1 ) ) );
$post_id2 = $this->factory->post->create( array( 'post_title' => 'beta', 'post_category' => array( $category2 ) ) );
$post_id3 = $this->factory->post->create( array( 'post_title' => 'gamma', 'post_tag' => array( $tag1 ) ) );
$post_id4 = $this->factory->post->create( array( 'post_title' => 'delta', 'post_tag' => array( $tag2 ) ) );
}}}
=== Testing tax_query for categories 1 and 2 ===
{{{
$args = array(
'tax_query' => array(
array(
'taxonomy' => 'category',
'field' => 'term_id',
'terms' => array( $category1, $category2 )
)
)
);
$query = new WP_Query( $args );
$posts = $query->get_posts();
}}}
'''Expected result:''' `$posts` contains post 1 and 2.
'''Actual result:''' `$posts` contains post 1.
'''Workaround:''' Add `'relation' => 'OR'` to the tax_query.
=== Testing two taxonomies at once ===
{{{
$query = new WP_Query( array(
'tax_query' => array(
array(
'taxonomy' => 'category',
'field' => 'term_id',
'terms' => array( $category1, $category2 )
),
array(
'taxonomy' => 'post_tag',
'field' => 'term_id',
'terms' => array( $tag1, $tag2 )
),
'relation' => 'OR'
)
) );
}}}
'''Expected result:''' `$posts` contains posts 1, 2, 3 and 4.
'''Actual result:''' `$posts` contains posts 1 and 2.",p_enrique
Next Release,27344,Array support in WP_Meta_Query when compare operator is LIKE or NOT LIKE,,Query,3.8,normal,normal,,enhancement,closed,needs-unit-tests,2014-03-10T22:40:02Z,2015-01-12T21:22:45Z,"= Usage scenario =
Consider a lead custom post type with several custom fields (including '''contact name''' and '''company name''') and a search form (with fields for each of the supported custom fields). Contact name and company name may contain multiple words and it should be possible to search for one or more words. The search form has an extra criteria `