__group__ ticket summary owner component _version priority severity milestone type _status workflow _created modified _description _reporter
Next Release 23219 Duplicate enclosure metadata created because of disagreement on meta field formatting nacin XML-RPC 2.8 normal normal 3.6 defect (bug) closed needs-unit-tests 2013-01-16T21:48:42Z 2013-07-10T03:34:36Z "Years ago I reported an issue in Ticket #7773 that the enclosures would be duplicated each time the post was edited and resubmitted through the XMLRPC API. That bug was fixed in [10383] but a nuance was overlooked that causes this kind of duplication to occur with every edit if the ORIGINAL custom field meta for the enclosure was generated by the automatic content-scraper in WordPress.
If a post with links to ""enclosure"" type files is submitted either through the web interface or through the XMLRPC API, it will automatically generate the insertion of enclosure metadata as a custom field with fragile-structured content of the format:
{{{add_post_meta( $post_ID, 'enclosure', ""$url\n$len\n$mime\n"" );}}}
But the XMLRPC implementation, where the attempt is made to avoid generating duplicates, uses a slightly different fragile template, with no trailing newline:
{{{$encstring = $enclosure['url'] . ""\n"" . $enclosure['length'] . ""\n"" . $enclosure['type'];}}}
To make a long story short: the attempt to detect an existing enclosure on the post always fails because the existing enclosure string has a newline, and the XMLRPC-based one does not.
I propose that this be fixed by at enacting 1 and probably also 2:
1. Make sure duplicate detection method insensitive to trailing whitespace. This will fix the bug in a way that doesn't require retroactively ""fixing"" the existing stored metadata with trailing newline.
2. Change the format of the ""scraped"" enclosure generation to match the format used by XMLRPC. Either with or without the newline would probably be fine, but it seems cleaner to stick with the one that doesn't require a trailing newline, just three blobs of text separated by newlines. It also seems lucky that the last blob is a MIME type and thus would never have a meaningful newline at the trailing end.
I'm attaching a patch that achieves both of these goals. I report this to the XML-RPC component because that's the impact is, even if some of the issue is in the default scraping code from functions.php.
I'm a little less certain about how to tackle a unit test for these cases, but if somebody wants to point me in the right direction I can take a hack at that too.
" redsweater
Next Release 51493 Type error in wp_xmlrpc_server::_prepare_taxonomy() johnbillion XML-RPC 3.7 normal normal 5.7 defect (bug) closed needs-unit-tests 2020-10-10T19:51:57Z 2020-12-21T17:09:51Z "There's a type error in the `wp_xmlrpc_server::_prepare_taxonomy()` method.
Ref: https://core.trac.wordpress.org/browser/tags/5.5.1/src/wp-includes/class-wp-xmlrpc-server.php?marks=768-770#L742
If `$fields` array contains a `menu` element then it tries to read the `show_in_menu` property from `$_taxonomy`, but this is an array not an object.
Probably just needs `$_taxonomy` changed to `$taxonomy` but needs testing, ideally needs a unit test and steps to reproduce.
Introduced in [25133] / #20930.
" johnbillion
Next Release 24280 Unit tests for mt_publishPost, blogger_newPost and mw_newPost chriscct7 XML-RPC 3.0 normal normal defect (bug) closed needs-unit-tests 2013-05-07T17:58:02Z 2015-09-26T05:16:16Z "The mt_publishPost function requires both the publish_posts and edit_post privileges to publish a post.
Elsewhere, the publish_posts privilege is sufficient to publish a post." fgauthier
Next Release 16985 XML-RPC endpoint set the datetime when saving a Draft wonderboymusic XML-RPC 3.1 normal normal 4.4 defect (bug) closed needs-unit-tests 2011-03-28T13:33:46Z 2018-11-09T17:35:56Z "When uploading a draft post from one of the WordPress mobile apps the post date is set to the current time/date, even if the datetime field is not specified on the client request.
This could cause issues, because when you change the post status to ""publish"" it will be published using the date set during the first upload.
On the web dashboard if you do not set the post datetime explicitly, it is not set and hitting publish will then populate the datetime field with the current time.
The same happens if you start a draft on the web and then you publish it using any mobile apps.
details here: http://ios.trac.wordpress.org/ticket/826" daniloercoli
Next Release 19733 XML-RPC returns invalid dates if the date is zero westi XML-RPC 3.3 normal normal 3.4 defect (bug) closed needs-unit-tests 2012-01-04T14:04:38Z 2015-12-15T22:24:46Z "When a post has a 'pending' status, {{{post_date_gmt}}} is set to {{{0000-00-00 00:00:00}}} as a marker to update {{{post_date}}} when it's saved (see #5698).
mysql2date then proceeds to turn that date into a negative one, and IXR_Date destroys the thing a bit more, so {{{0000-00-00 00:00:00}}} turns into {{{-0001113TT0::0::00}}}, which is an invalid ISO8601 date" koke
Next Release 17981 XML-RPC wp.getComments should work for non-admins wonderboymusic XML-RPC 3.2 normal normal 4.4 defect (bug) closed needs-unit-tests 2011-07-04T22:23:03Z 2015-09-26T02:48:48Z "Right now, if the caller doesn't have the moderate_comments permission, the XML-RPC call returns a 401 error.
A more graceful alternative would be to return the approved comments. The user may not be able to moderate, but still should be able to read/reply" koke
Next Release 20665 wp.getUsersBlogs method runs out of memory when there are too many blogs nacin XML-RPC 3.0 normal normal 3.5 defect (bug) closed needs-unit-tests 2012-05-13T14:05:31Z 2012-06-30T11:49:03Z wp.getUsersBlogs method runs out of memory when there are too many blogs. But with the proposed changes (by avoiding switch_to_blog and restore_current_blog) you can list more blogs with same amount of memory. mohanjith
Next Release 20026 Adding a post_type filter in wp.getComments westi XML-RPC normal normal 4.4 enhancement closed needs-unit-tests 2012-02-12T15:48:53Z 2015-09-26T07:09:31Z This will be usefull when with the new custom post type support in XMLRPC nprasath002
Next Release 25958 Allow wp.getUsersBlogs to return the primary_blog flag wonderboymusic XML-RPC low normal 4.4 enhancement closed needs-unit-tests 2013-11-13T23:11:03Z 2015-09-26T04:34:51Z "Would be nice if wp.getUsersBlogs could return the primary blog flag in the response.
For example, when logging with the mobile apps, we can pre-select the primary blog as the default, and give the user a better experience just from the beginning." daniloercoli
Next Release 13835 XML-RPC API should return commentmeta values josephscott XML-RPC 2.9 normal normal feature request closed needs-unit-tests 2010-06-10T23:28:58Z 2017-02-13T22:33:21Z "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
Future Releases 16980 Empty Values are ignored by class-ixr.php XML-RPC 3.1 normal normal Future Release defect (bug) assigned needs-unit-tests 2011-03-27T12:34:47Z 2020-09-30T18:41:01Z "I tried to fix the following bug #10599
Found out when you send and empty value via xmlrpc it converts it to null value.
Say you send and array of arguments for mw_editpost, set
{{{
$content_struct[mt_keywords] = '';
}}}
IXR client passes a null value instead of an empty value.
In mw_post method consider this statement
{{{
$tags_input = isset( $content_struct[mt_keywords] ) ? $content_struct[mt_keywords] : null;
}}}
Even if you send an empty value this statement fails because
{{{
$content_struct[mt_keywords]
}}}
is set to null by IXR client." nprasath002
Future Releases 36030 Expose site icon on wp.getUsersBlogs XML-RPC normal normal Future Release enhancement new needs-unit-tests 2016-03-01T09:06:46Z 2019-06-20T14:07:35Z "WordPress 4.3 has added the ability for site owners to manage their site’s favicon, but never exposed it over the XML-RPC protocol.
It's useful for XML-RPC clients to receive it back in the response of wp.getUsersBlogs, so they can show the proper icon beside the name of the site.
In the patch I've provided an empty value is returned if site_icon is not set on the blog. I've avoided returning a default value, since it's better to leave this responsibility to clients. If siteIcon is empty, the client should show their default icon, or nothing." daniloercoli
Next Release 41686 Store Widgets in the Posts table Widgets normal normal defect (bug) closed needs-unit-tests 2017-08-21T11:14:20Z 2017-08-21T11:22:10Z "Currently widgets are stored in the options table. They can be accessed using WP_Widget. But storing it options has a number of drawbacks, most of which is performance. Migrating the data to the posts table as a new post type has a number of benefits.
- Revisions for widgets
- Author
- Date created / edited
- Trashing widgets
- Interact with widgets using the posts endpoint
- Easier migration of data using the wordpress exporter
- Post meta for widgets for better extending.
" spacedmonkey
Next Release 32417 Add new core media widget melchoyce Widgets 4.3 normal normal 4.8 feature request closed needs-unit-tests 2015-05-16T03:14:25Z 2017-10-24T20:39:33Z 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 35574 Add REST API JSON schema information to WP_Widget Widgets 2.8 normal normal Future Release enhancement new needs-unit-tests 2016-01-22T12:24:06Z 2017-04-23T23:27:58Z "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 31020 Introduce discrete capability for managing widgets johnbillion Widgets normal normal Future Release enhancement assigned needs-unit-tests 2015-01-15T07:11:15Z 2022-01-30T16:44:08Z "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 53771 What about an equivalent of `is_active_widget()` for Widget Blocks ? Widgets 5.8 normal normal Future Release enhancement new needs-unit-tests 2021-07-24T13:13:26Z 2021-07-29T17:06:25Z "This doesn't seem to exist in WordPress Core and I haven't found a ticket asking about this. (I hope I haven't missed one, sorry if I did).
`is_active_widget()` can't be used because all Block are added into the same Widget: `WP_Widget_Block`.
For BuddyPress when migrating our Legacy Widgets to Widget Blocks, I had 2 cases where some output wasn't made if a widget was active into a sidebar (Sitewide notice, and BP Primary Nav). To satisfy our need we are using [https://buddypress.trac.wordpress.org/browser/tags/9.0.0/src/bp-core/bp-core-template.php#L3869 this function] to check if a block or a widget is active into a Sidebar Widgets.
I thought maybe it can be interested to have an equivalent of `is_active_widget()` into WordPress. I quickly put up a patch about it." imath
Future Releases 42549 Widgets: Allow gallery widget to display images from currently-queried singular post if no images selected audrasjb Widgets 4.9 normal normal Future Release enhancement assigned needs-unit-tests 2017-11-14T18:22:48Z 2020-02-05T00:49:17Z In #42548 (pending) a `[gallery]` placed inside of a Text widget will result in the attachments for a given post to be used in the gallery when the widget appears on a singular template. The same behavior could be allowed for the Gallery widget as well. If you add a gallery widget to a sidebar but don't add any images to it, the widget could conditionally show if it is being rendered on a singular template for a post that has image attachments. westonruter
Future Releases 29319 filter dayswithposts in widget calendar SergeyBiryukov Widgets 3.0 normal normal Future Release enhancement reviewing needs-unit-tests 2014-08-22T14:28:53Z 2020-10-20T04:57:51Z "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 49588 "Cannot remove
" Widgets normal minor Awaiting Review feature request new needs-unit-tests 2020-03-06T18:02:23Z 2020-03-07T19:52:07Z "I cannot remove wrapping class in html widget:
...
It is defined here: https://github.com/WordPress/WordPress/blob/master/wp-includes/widgets/class-wp-widget-custom-html.php
I think it is job for some `apply_filters`.
Do we really need another `
';
} 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 enhancement new needs-unit-tests 2014-09-08T13:39:35Z 2019-06-04T21:12:17Z "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
Next Release 56134 "Site Health: If 0 active plugins (themes), they can't be ""all up to date""" SergeyBiryukov Site Health normal normal 6.1 enhancement closed needs-unit-tests 2022-07-03T11:50:52Z 2022-08-03T14:30:35Z "If 0 plugins are active it states:
{{{
Your site has 0 active plugins, and they are all up to date.
}}}
In my opinion we should strip the ""up to date"" part in that case.
Same for themes." Presskopp
Next Release 43986 "Disable ""Install Plugin"" button for PHP required version mismatch" afragen Site Health normal major 5.1 task (blessed) closed needs-unit-tests 2018-05-07T14:02:52Z 2019-06-24T16:14:18Z "**Note: This ticket is a subtask for the overarching #40934 ticket.**
As a first step in enforcing the ""Requires PHP"" plugin header information, we should disable the ""Install"" (plugin) button while displaying a notice with the reason why.
In contrast to blocking updates (which has infrastructure & security"" implications), disabling the ""Install"" button is relatively easy to do, provides most of the benefit of the ""Requires PHP"" header from all new and future installs, and most of all, provides a very real and convincing incentive for actually working on upgrading their servers.
While any installation path should be properly blocked based on this header, just disabling the ""Install"" button already makes sure we stop creating more problematic installations sites in the future." schlessera
Next Release 43992 Prevent activation of a plugin if its required PHP version is too high desrosj Site Health high major 5.2 task (blessed) closed needs-unit-tests 2018-05-07T15:32:13Z 2020-04-13T15:45:57Z "**Note: This ticket is a subtask for the overarching #40934 ticket.**
While the plans from #43986 and #43987 will ensure nobody can install or update plugins that require a PHP version higher than the version used, a third step should be to prevent plugin activations of said plugins. It is still possible to just upload plugin directories and then activate them from there. While the above tickets will cover the majority of cases, we should also account for the latter.
A difference between other work and this one would be that here, we need to read the required PHP version from the plugin readme file directly instead from the w.org plugins API." flixos90
Future Releases 48153 Allow the admin email verification capability to be filtered Site Health 5.3 normal normal Future Release defect (bug) assigned needs-unit-tests 2019-09-26T14:35:07Z 2020-02-21T17:53:27Z "Currently, the capability used to determine if the admin email verification screen should be displayed is hard coded as `manage_options`.
There are scenarios where a plugin or site owner would want to change this capability." desrosj
Future Releases 43989 "Allow plugin searches to be filtered by ""Requires PHP"" version information" Site Health normal normal Future Release task (blessed) new needs-unit-tests 2018-05-07T14:24:41Z 2019-06-24T16:10:01Z "**Note: This ticket is a subtask for the overarching #40934 ticket.**
If plugins now start making use of the ""Requires PHP"" version information in their plugin header, we should make sure that plugin searches can be filtered by their required PHP version.
This might include changes to the indexing infrastructure (indexing that information and allowing indexed queries against it) as well as changes to the UI (giving users the possibility to either use search flags in text form or faceted search mechanisms to communicate such a query." schlessera
Future Releases 47880 Extend unit tests for Site Health component. Site Health 5.2 normal normal Future Release task (blessed) new needs-unit-tests 2019-08-15T00:49:49Z 2020-07-06T23:20:09Z "A file for site health check unit tests has been added in `tests/phpunit/tests/site-health.php`.
At the time of writing it only includes tests for various states of cron, expanding these would help with future development of the component." peterwilsoncc
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 39277 get_post_galleries() produces PHP Warning in PHP 7.1 when parsing empty shortcode dd32 Shortcodes 4.7 normal normal 4.7.3 defect (bug) closed needs-unit-tests 2016-12-14T13:05:41Z 2017-02-17T06:46:46Z "With WordPress 4.7 and PHP 7.1, `get_post_galleries()` produces a PHP Warning when given an empty gallery shortcode:
> Illegal string offset 'src'
> /vagrant/wp/wp-includes/media.php:3696
This broke a probably-useless unit test in BuddyPress, but it will at least cause a PHP Warning if a certain common code path is triggered in production (and probably cause a regression in functionality).
Here's an example PHPUnit test you can copy/paste in to quickly see the issue. Compare it on PHP 7.1 against PHP < 7.1.
{{{
public function test_this_breaks_on_php71() {
$post_id = $this->factory->post->create( array(
'post_content' => 'blah [gallery] blah',
) );
$gallery = get_post_galleries( $post_id, false );
$this->assertSame( array( array( 'src' => array() ) ), $gallery );
}
}}}
I think returning an empty array, rather than an pair of nested arrays with only one `src` key set, is actually better/more expected behaviour." DJPaul
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 58366 Shortcode Support Regained but Content Filters are messing with Shortcode HTML Shortcodes 6.2.2 normal normal 6.6 defect (bug) new needs-unit-tests 2023-05-20T15:45:26Z 2024-02-22T20:41:52Z "I am extremely grateful that the Security Team were able to quickly regain support for shortcodes in the Block Theme templates. However, whatever change has been agreed and pushed out means that the filters to automatically inject ` ` and `
` tags into the content are now affecting shortcodes and we are seeing text being automatically wrapped in `
` tags and carriage returns replaced with ` ` tags.
Rather than revert to the insecure v6.2.1 we are going through shortcodes to remove any carriage returns.
Please advise.
Oliver" domainsupport
Future Releases 59509 Shortcode attributes named 0 are ignored Shortcodes 6.3.1 normal normal Awaiting Review defect (bug) new needs-unit-tests 2023-09-30T12:14:06Z 2023-10-04T10:02:59Z "Shortcode attributes in the form `0=...` are not picked up during parsing.
This is because the parser checks for an empty name with `empty(..)`, which also returns true for the string `'0'`." ourous
Future Releases 47616 Enhancement: doing_shortcode() function similar to doing_filter() audrasjb* Shortcodes normal normal Future Release enhancement accepted needs-unit-tests 2019-06-27T12:42:53Z 2021-11-09T08:46:59Z "Currently there is no way to determine whether the current code is run from a shortcode callback.
Similar to actions and filters it would be nice to have a `doing_shortcode()` function.
My idea is to have an optional parameter for the shortcode tag.
If the parameter is passed it will check if that exact shortcode is running.
If no parameter is passed it will return true if any shortcode is running.
Though I believe it's not officially supported, if shortcodes are triggered within shortcodes it would be best to keep an array of current shortcodes and only remove an active shortcode tag if the callback is finished." keraweb
Future Releases 24990 Nested Shortcode Inside [caption] Shortcodes 3.6 normal normal defect (bug) new needs-unit-tests 2013-08-08T09:38:06Z 2021-05-08T23:37:35Z "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 defect (bug) reopened needs-unit-tests 2013-12-16T15:13:48Z 2019-06-04T21:10:00Z "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
Next Release 40635 Move JavaScript `sanitizeText` and `stripTags` functions from press-this to core adamsilverstein Security normal normal 4.9 enhancement closed needs-unit-tests 2017-05-02T15:45:46Z 2017-10-04T18:57:47Z "The file `press-this.js` includes two generally useful helper functions:
* `stripTags` strips HTML tags from a string using a series of regex replace calls.
* `sanitizeText` strips HTML tags and converts HTML entities in a string. It leverages a textarea's content to encode HTML and returns a string that is safe to evaluate.
These functions would be generally useful in core and for plugin and theme developers and could be added to the `wp` namespace, eg `wp.utils.stripTags` and `wp.utils.sanitizeText`" adamsilverstein
Future Releases 50027 Retire Phpass and use PHP native password hashing Security normal normal Awaiting Review defect (bug) new needs-unit-tests 2020-04-29T10:36:12Z 2023-10-13T01:11:52Z "PHP comes with built-in password hashing functions since PHP 5.5. Now that we have updated the minimum requirements to PHP 5.6, we can rely on PHP to provide us with password hashing mechanisms that ensures a cryptographically secure random numbers are are used for salt, and the hashes are backwards compatible.
I created and maintain [https://wordpress.org/plugins/password-hash/ PHP Native Password Hash] plugin to swap WordPress's baked in Phpass with PHPs.
**0.Phpass recommends to use PHP native hashing**
> At this time, if your new project can afford to require PHP 5.5+, which it should, please use PHP's native password_hash() / password_verify() API instead of phpass.
I propose that we upgrade the hashing mechanisms to password_hash()/password_verify/password_needs_rehash() combo.
**1.We do not need to force users to change their passwords.**
Phpass-hashed passwords have the signature `$P`, and the very old MD5 hashes are fewer than 32 characters long. We will inspect the signature first, and if the password is using the old standard, we will validate the password one last-time, and then use password_hash() to rehash it. From this point forward, that user is ""upgraded"" to the new mechanism.
**2.Expose a filter for plugins**
The plugin I maintain supports BCrypt, Argon2I, and Argon2ID for hashing. We can expose a filter that WordPress core emits so plugins can change the hashing algorithm if necessary.
**3.Use BCrypt as the default algorithm**
If a plugin does not take over, WordPress core will use BCrypt. BCrypt is secure, and is available in any PHP version 5.5, 5.6, 7.* and 8.*.
**4.Do not remove Phpass**
We will **not** remove Phpass from WordPress core. This is needed for backwards compatibility to ensure that existing users will eventually be updated.
The end goal is that we seamlessly migrate active users passwords to better mechanisms without breaking functionality for existing users. Frameworks such as Drupal and phpBB (which used phpass in the past) have moved to better mechanisms since the minimum required PHP versions have been updated, and we can easily follow suit.
If the maintainers agree, I would be overjoyed to collaborate on patches.
" ayeshrajans
Future Releases 51438 Use CSP directive upgrade-insecure-requests when using HTTPS Security 5.7 normal normal Future Release enhancement new needs-unit-tests 2020-10-02T20:08:07Z 2021-11-09T00:01:22Z "While looking at ways on how to streamline HTTPS support in WordPress core, [https://core.trac.wordpress.org/ticket/47577#comment:4 one suggestion has been to include a `Content-Security-Policy` directive of `upgrade-insecure-requests`] for sites using HTTPS. This directive would ensure that browsers automatically replace (old) insecure requests for inline content (e.g. images) to use HTTPS (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests).
This could be as simple as injecting `` into `wp_head` for sites that use HTTPS (see `wp_is_using_https()` from #47577). Alternatively, since this is mostly beneficial for sites that may still (""accidentally"") have insecure URLs in their content after migrating from HTTP to HTTPS, it might make sense to rely on `wp_should_update_insecure_urls()` from #51437 instead." flixos90
Future Releases 52388 Use HTTPS URL already during installation if supported Security normal normal Future Release enhancement new needs-unit-tests 2021-01-28T03:06:59Z 2021-01-28T03:06:59Z "Following up on #51437, WordPress should try to check already during installation whether the current domain and server can be used over HTTPS. If so, it should suggest to use the HTTPS version of the URL by default.
This was originally brought up by @westonruter in https://core.trac.wordpress.org/ticket/51437#comment:1, but was out of scope for that ticket which focuses on migration from HTTP to HTTPS." flixos90
Future Releases 11623 review options list and update sanitize_option() Security 2.9 normal normal defect (bug) closed needs-unit-tests 2009-12-26T01:22:13Z 2020-02-05T06:39:44Z "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 54323 Too few arguments for function (closure) SergeyBiryukov Script Loader normal major 5.8.2 defect (bug) closed needs-unit-tests 2021-10-26T12:34:01Z 2021-11-02T18:29:53Z "The issue was reported in the Gutenberg repository: https://github.com/WordPress/gutenberg/issues/35912
Registering a block-style when `should_load_separate_core_block_assets` is enabled throws a fatal error if the block renders on the frontend (more details in the github ticket)" aristath
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
Next Release 32358 Add unminified jQuery to core for better debugging with SCRIPT_DEBUG enabled Script Loader normal normal feature request closed needs-unit-tests 2015-05-12T15:22:45Z 2017-06-15T13:03:49Z "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 37756 Allow inline scripts on script aliases Script Loader 4.5 normal normal Future Release defect (bug) new needs-unit-tests 2016-08-21T06:46:10Z 2019-12-13T22:21:50Z "It appears if {{{add_inline_script}}} is called on {{{jquery}}} then it gets ignored, and requires to use {{{jquery-core}}}
The same may apply to styles but not tested. Inline scripts should work on both the main script and the aliases.
" pcfreak30
Future Releases 34591 "BugFix to WP_Scripts::do_item(), remove doubled ""//""" Script Loader 4.3.1 normal normal Awaiting Review defect (bug) new needs-unit-tests 2015-11-05T11:01:37Z 2017-02-05T09:08:07Z "Current code in `do_item()` of class.wp-script.php on line 172:
{{{
$src = $this->base_url . $src;
}}}
may produce duplicate slashes `""//""`, resulting in problems.
This might be fixed with code:
{{{
$src = $this->base_url . $src;
}}}
Currently:
* WP_Scripts contains: `""public $base_url; // Full URL with trailing slash""` and
* script-loader.php contains calls `$scripts->add()` with initial `""/""` in relative paths
Together this produces doubled slashes `""//""`. For example:
http://www.ocelovehaly.cz/ll//wp-includes/js/jquery/jquery.js?ver=1.11.3
This makes W3TC include script in minified version, but not to remove it from the original HTML.
Including jQuery twice makes LayerSlider not to work.
Please, could you bugfix class.wp-script.php on line 172?
Thank you :-)" jan.mazanek
Future Releases 46089 Memory exhaustion when setting script translations on `wp-i18n` Script Loader normal normal Future Release defect (bug) new needs-unit-tests 2019-01-24T00:47:26Z 2021-02-04T05:53:32Z "A memory exhaustion occurs given the following snippet of code:
{{{#!php
Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 262144 bytes) in /srv/www/editor/htdocs/wp-includes/class.wp-dependencies.php on line 324
}}}
Memory exhaustion occurs here:
https://github.com/WordPress/WordPress/blob/4e3e9ca9cf893190609728848caf224034fd1ef0/wp-includes/class.wp-dependencies.php#L338
I think it stems from this line:
https://github.com/WordPress/WordPress/blob/4e3e9ca9cf893190609728848caf224034fd1ef0/wp-includes/class.wp-scripts.php#L517
Where `wp-i18n` is adding itself as a dependency.
Could probably do for a simple check to ensure that the incoming handle is not `wp-i18n`." aduth
Future Releases 54956 "[5.9] wp_block_type args - ""style"" and ""script"" are always loaded on Frontend" Script Loader 5.9 normal normal Awaiting Review defect (bug) new needs-unit-tests 2022-01-27T17:15:29Z 2022-07-19T13:58:22Z "Before 5.9 - `style` and `script` are loaded when the block is added to specific page.
After 5.9 - `style` and `script` are always loaded, on all pages, all the time, everywhere, regardless if the block is displayed on specific page or not.
More info about my use case:
- `style` and `script` both reference a registered script/style, which have multiple dependencies (`wp_register_style` has `$deps` array defined that references more registered styles)
Temporary fix I did to the client code:
- Replacing `style` and `script` with `styles` and `view_script` fixed the issue
However this ""fix"" requires specific WP Core version - 5.8.3 should use `style` and `script`, while 5.9 should use `styles` and `view_script`." pkostadinov
Future Releases 51124 Can we get an additional parameter in wp_add_inline_script to set the script type? audrasjb* Script Loader normal normal Future Release feature request accepted needs-unit-tests 2020-08-24T15:55:12Z 2021-11-08T02:55:50Z "Hi everyone,
This is probably a feature that not many developers out there will use but I think it would be nice to have.
One of my plugins uses `wp_add_inline_script` to inject an inline script into the page. Said inline script gets assigned `text/javascript` as type automatically and there doesn't seem to be a way to change that (if there is please let me know and I'll gladly close this ticket.)
My plugin needs said inline script to contain a JSON string and so it currently hooks into `script_loader_tag` to change its type to `application/json` which feels a bit like a hack. It would be nice if we could set the script type via parameter (eg. `wp_add_inline_script( 'some-handle', '...', 'before', 'application/json' );`) (or maybe via filter hook before `script_loader_tag` happens?)
Thoughts?" hcabrera
Future Releases 35963 Only remove item from WP_Dependencies::to_do if it was successfully processed Script Loader normal normal defect (bug) new needs-unit-tests 2016-02-26T12:37:32Z 2019-06-04T21:20:31Z "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 defect (bug) assigned needs-unit-tests 2016-06-26T13:53:32Z 2019-06-04T21:24:27Z "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 44302 X-DNS-Prefetch-Control default setting prevents resource hints from working for dubious 'security reasons' Script Loader normal normal enhancement closed needs-unit-tests 2018-06-04T09:24:25Z 2019-10-24T05:14:11Z "**Context**
Since 4.6, WordPress automatically adds `dns-prefetch` tags into the `wp_head` block, for the hostname of any enqueued external resources.
Theme/plugin developers may add prefetch/similar [https://make.wordpress.org/core/2016/07/06/resource-hints-in-4-6/ resource hints].
These 'hints' allows the browser to initiate early DNS lookups, execute SSL handshakes, and apply similar optimisations to increase the efficiency of their loading processes.
----
**Chrome(ium) ignores dns-prefetch over HTTPS**
The most common (and automatically added) hint, `dns-prefetch`, is frequently ''ignored'' by browsers - rendering the `dns-prefetch` tags inert.
Specifically, the default behaviour of many browsers (Chromium-derived browsers, specifically) is to ''not allow `dns-prefetch` unless a `X-DNS-Prefetch-Control` HTTP header is set/detected.
`X-DNS-Prefetch-Control` is implied to be set to 'on' by default, but this ''excludes domains loaded over HTTPS'', unless the value is explicitly set to ''on''.
Because an increasing proportion of websites are migrating to / adopting HTTPS, we should have a stance and a solution for enabling (or, perhaps, removing) `dns-prefetch` tags.
Note that, there's no equivalent for Firefox / other browsers, other than end-user level configuration (e.g., in Firefox, setting `network.dns.disablePrefetch` to `true`).
----
**It's a question of security**
The argument boils down to, effectively, ''""Site owners of pre-fetched connections might be able to detect/monitor those connections""''.
More verbosely,
''""Links with novel subdomains, when resolved during a prefetch, may notify a domain's resolver that a link was viewed, even if it was not clicked. In some such cases, the authority serving the content (such as a blog owner, or webmail server) may wish to preclude such abusive monitoring.""''
See 'DNS Prefetch Control' at http://dev.chromium.org/developers/design-documents/dns-prefetching
I believe that whilst the argument for avoiding DNS connection sniffing makes sense in a general context (although, it seems over-cautious), our use-case is much safer.
I'm struggling to envision many realistic risks or scenarios where this could be a meaningful attack vector, given that:
- It'll be rare for a WordPress site to have 'unknown' DNS lookups; we're limited to enqueued external resources, and resource hints added by theme/plugin developers.
- Rogue theme developers / site owners ''could'' manually add tags to their theme `
` markup, but by this point, they could be doing much worse stuff (intentionally or otherwise).
----
**The proposal**
We should detect whether resource hints are in play on a site, and if so, add a `X-DNS-Prefetch-Control: on` HTTP header.
This will result in a marked decrease to the loading time of WordPress sites which rely on third party resources (i.e., those which are enqueuing with resource hints), when loaded in a Chromium browser.
Optionally, we could restrict that behaviour to ''only'' trigger in the case that ''all'' enqueued resources / resource hints are from whitelisted CDNs (e.g., `cdnjs.com`, `ajax.googleapis.com`), which might have an added impact of encouraging CDN usage for common scripts/assets.
----
Thoughts appreciated. Apologies for any potential hiccups with categorisation of this ticket - first time I've raised a core issue/enhancement." jonoaldersonwp
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 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
Future Releases 40340 """Attach to existing content"" modal shows posts and pages of other users" Role/Capability normal normal Awaiting Review defect (bug) reopened needs-unit-tests 2017-04-02T15:19:15Z 2017-08-03T17:54:02Z "From the Media library, a user can attach media (through the Attach link) that were uploaded by himself only. The first image shows the Attach links appearing for certain media only.
In the same way, the ""Attach to existing content"" should also list only those posts/pages for which the user has the permissions to attach.
Instead it lists all posts (including private) and pages of all users, and then, upon selection, gives the message ""Sorry, you are not allowed to edit this post.""
" menakas
Future Releases 43877 Do not run unnecessary `user_has_cap` filter if the caps to check for include `do_not_allow` already Role/Capability normal normal Awaiting Review defect (bug) new needs-unit-tests 2018-04-27T12:27:30Z 2018-09-17T11:21:33Z "`do_not_allow` is a fake capability used essentially as a blacklist, saying that nobody can perform that action. It's typically returned in the `map_meta_cap()` result for an actual capability check. If `do_not_allow` is part of that array, it is immediately clear that the final result of the `WP_User::has_cap()` method will be `false`.
Currently however, the following code in the function still executes, including a `user_has_cap` filter. Since we already know the return value if `do_not_allow` is present in the `$caps` array checked for, everything happening afterwards is entirely unnecessary overhead. Especially since [40993] it should be clear that nothing can get around a `do_not_allow` being present.
For efficiency and possibly performance reasons, I suggest we check for `do_not_allow` right after the `map_meta_cap()` call, and if it is present, return false." flixos90
Future Releases 50123 Roles & Caps: give anonymous users the `read_post` meta cap for public posts. Role/Capability normal normal Awaiting Review defect (bug) new needs-unit-tests 2020-05-07T23:30:23Z 2024-01-26T07:45:24Z "The meta capability `read_post` is used to determine if a user is permitted to read a post. For public posts (ie, both a public post type and public post status), it returns the `$post_type->cap->read` as the required primitive capability.
As logged out users do not have any primitive capabilities, this causes `current_user_can( 'read_post', $post_id )` to return a false negative for logged out users wishing to read a public post.
**Approach one:**
For public posts the `read_post` meta capability returns an empty array of primitives.
**Approach two:**
Logged out users are given the `$post_type->cap->read` capability for public post types.
**Approach three:**
WP gives logged out users the `read` primitive capability, if a developer uses an alternative primitive for public custom post types, then the developer is responsible for ensuring anonymous users have the capability.
**Notes:**
* ~~Private multisite sites should not allow logged out users to see such posts~~ ''Edit: removed as it's not a core feature of Multisite''
* Many, many unit tests will be required
" peterwilsoncc
Future Releases 59585 Unchecked variable creates fatal error in wp-includes/class-wp-user-query.php Role/Capability 6.3.2 normal normal Awaiting Review defect (bug) new needs-unit-tests 2023-10-10T13:32:17Z 2023-10-10T21:12:27Z "Hello!
I've ran into a bug that had me need to modify core.
I have no clue why this bug happens in this setup in particular, i've got other WP websites running on the same server with no problem, but this one crashes with no plugins and twenty twenty two active.
Here is what I found; at line 483 there is an array_filter that passes a variable to the function... without verifying the variable is actually what is expected.
Bug is present in 6.3.2
{{{#!php
$role_data ) {
$role_caps = array_keys( array_filter( $role_data['capabilities'] ) );
foreach ( $capabilities as $cap ) { [...]
}}}
I fixed it by checking the variable is something before doing the array_filter
{{{#!php
$role_data ) {
$role_caps = '';
if(isset($role_data['capabilities'])){
$role_caps = array_keys( array_filter( $role_data['capabilities'] ) );
}else{
return false;
}
foreach ( $capabilities as $cap ) {
}}}
I would like this to be added to core, so it doesnt crash anymore and wont crash when I update WordPress next time." Frederic Pilon
Future Releases 36376 current_user_can/has_cap fails when user has multiple roles dd32* Role/Capability normal normal Future Release defect (bug) accepted needs-unit-tests 2016-03-30T17:16:45Z 2019-01-14T04:46:21Z "To replicate the issue, install a role editor. Setup a user with primary role 'author' and secondary role 'customer' (this is a WooCommerce role which has ONLY 'read' access, nothing else).
https://dl.dropboxusercontent.com/s/xgucqvvh6no3skm/2016-03-30%20at%2017.49.png?dl=0
You can add a role with only:
{{{#!php
'read' => true
}}}
permissions if you don't have WooCommerce installed.
Dump:
{{{#!php
current_user_can( 'edit_posts' )
}}}
It will be false.
During get_role_caps() in class-wp-user.php, each role is retrieved and merged. The merge itself doesn't look at values, so if multiple roles have the same 'cap' but different value, these overwrite each other.
In my case, edit_posts was true for the author role, but false for customer role. Customer role false overwrote author role true.
Since caps only allow access to things if 'true', I think we can safely discard all 'false' caps when getting roles. If false caps are discarded, only true caps are left which works around the issue and fixes user capabilities if they have multiple roles at once.
Fix to follow (added array_filter to discard all 'false' caps, allowing us to merge only 'true' caps).
Had this reported to us in https://github.com/woothemes/woocommerce/issues/10612#issuecomment-203518038 but wasn't a WooCommerce issue.
" mikejolley
Future Releases 38997 delete_private_posts capability doesn't prevent user from deleting private posts Role/Capability 4.6.1 normal normal Future Release defect (bug) assigned needs-unit-tests 2016-11-30T21:09:31Z 2019-05-25T14:02:40Z "Attempting to prevent users from deleting a published post works, but if they set a post to 'private' they can delete it even if 'delete_private_posts' capability is set to 0.
{{{#!php
allcaps['delete_published_posts'] = 0;
// doesn't work
$current_user->allcaps['delete_private_posts'] = 0;
}}}
""doesn't work"" means that ""Trash"" link appears on hover over the post in edit.php and ""Move to Trash"" shows up on post.php
" yboris
Future Releases 38303 register_meta and capabilities aren't working as expected rmccue Role/Capability 4.6 normal normal Future Release defect (bug) reopened needs-unit-tests 2016-10-13T14:43:18Z 2017-06-25T20:31:21Z "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
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 2020-06-04T15:49:23Z 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 45197 Introduce `user_can_for_blog()` johnbillion Role/Capability normal normal 6.6 enhancement reviewing needs-unit-tests 2018-10-26T11:05:51Z 2024-03-07T16:46:56Z "The available user capability checking functions include:
* `current_user_can()`
* `user_can()`
* `current_user_can_for_blog()`
What's missing is `user_can_for_blog()` so that both a user ID and a site ID can be passed in order to check a given user's capabilities on a given site." 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 2017-07-14T19:41:15Z "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 42405 Introduce singular capabilities for enabling individual themes on Multisite Role/Capability normal normal Future Release enhancement new needs-unit-tests 2017-11-01T22:14:24Z 2017-11-01T22:14:24Z "Related: #39083
The ability to enable or disable individual themes for a site from the Network Admin -> Sites -> Edit -> Themes screen should be controlled by singular capabilities.
* `enable_theme`
* `disable_theme`" johnbillion
Future Releases 41701 Introduce singular capabilities for further management of individual plugins Role/Capability normal normal Future Release enhancement new needs-unit-tests 2017-08-22T14:14:11Z 2017-08-22T14:14:28Z "This is a follow-up to #38652 which introduced singular capabilities for activating and deactivating individual plugins.
Singular capabilities should be added for controlling the ability to do the following:
* Edit an individual plugin.
* Delete an individual plugin.
* Update an individual plugin.
Low priority stretch goals which might end up in another follow-up ticket:
* Edit an individual file in a plugin.
* Install an individual new plugin.
* Upload an individual new plugin.
Network activation and deactivation for Multisite will be handled in a separate ticket." johnbillion
Future Releases 42404 Introduce singular capabilities for managing individual plugins Role/Capability normal normal Future Release enhancement new needs-unit-tests 2017-11-01T22:11:24Z 2018-04-18T20:37:39Z "In #38652, singular capabilities were added for activating and deactivating individual plugins.
The same should be added for other management actions for plugins:
* `edit_plugin` (ability to adit plugin via the Plugin Editor)
* `delete_plugin` (ability to outright delete the plugin)
* `update_plugin` (ability to update a plugin)
Network activation and deactivation will be handled in #42403" johnbillion
Future Releases 41703 Introduce singular capabilities for network activation and deactivation of individual plugins Role/Capability normal normal Future Release enhancement new needs-unit-tests 2017-08-22T14:16:06Z 2020-09-20T12:12:58Z "This is a follow-up to #38652 which introduced singular capabilities for activating and deactivating individual plugins.
Singular capabilities should be added for controlling the ability to network activate and network deactivate individual plugins on Multisite.
See also #41701." johnbillion
Future Releases 43421 The $capabilities argument in the `add_role()` function is incompatible with `user_can` Role/Capability 4.9.4 normal normal Awaiting Review enhancement reopened needs-unit-tests 2018-02-26T17:19:26Z 2018-03-20T17:21:03Z "Reproduce:
Add a role to WP using `add_role()`, and pass it custom capabilities using the third argument. Like:
{{{#!php
add_cap($cap);
}
}}}
And repeat testing, it returns true as expected.
This has to do with how the caps are saved. The first way, when capabilities are retrieved in `WP_User::has_cap()`, they look like this:
{{{#!php
""read"",
[1]=>
""my_cap"",
[""my_new_role""]=>
bool(true)
[""exist""]=>
bool(true)
}
}}}
And when done via `add_cap`, they look like this:
{{{#!php
bool(true)
[""my_cap""]=>
bool(true)
[""my_new_role""]=>
bool(true)
[""exist""]=>
bool(true)
}
}}}
The subsequent `empty` array check is true for the first, and false for the second.
" eclev91
Future Releases 39174 Introduce network roles Role/Capability normal normal Future Release feature request new needs-unit-tests 2016-12-08T02:00:45Z 2019-03-15T02:07:55Z "We have been discussing introducing network roles during multisite office-hours several times. The original concept for roles on multisite/multinetwork was the following:
''Site Administrator < Network Administrator (currently also called ""Super Admin"") < Global Administrator < Super Admin (special access via `$super_admins` global, has all capabilities automatically)''
This ticket is about network roles in particular, but we need to figure out the entire concept we'll be going with beforehand.
After the initial discussions which happened several weeks ago, I started playing around with that idea and created a plugin with network roles which is available at https://github.com/felixarntz/wp-network-roles. The details on that plugin are described in this Google doc (and are probably worth reading to understand the following discussion better): https://docs.google.com/document/d/1MWwwKmhBJookr5dEcYga4sBtCwvx-K8uSucBFx6SP9U/edit#
I just had a long conversation with @johnbillion around this topic where we agreed on some ideas, disagreed on others, were entirely unsure about others. The following bullet points sum up what we talked about / which questions we raised.
* The original idea of network roles was that these roles behave similar to regular site roles: They all have a set of capabilities they can perform. These capabilities can apply to either the site or network level. This allows for roles like the current ""Super Admin"" / ""Network Administrator"" that has access to everything a site administrator has, but also to any network admin functionality - however it also allows for roles like a possible ""Network Editor"" which would be the same as if a user had the ""Editor"" role on every site of the network.
* Should we support both of these concepts? Or should network roles only affect the actual network admin area? If the latter, which roles would we even need in Core itself (in addition to the ""Super Admin"" / ""Network Administrator"")? This decision would also affect whether we should support inheritance of network capabilities to site capabilities or whether network roles would just be additional kind of roles for a user. An example to clarify:
* First approach: The ""Super Admin"" / ""Network Administrator"" has all the capabilities a regular site administrator has, plus the network admin area capabilities (like `manage_network` or `manage_network_options`), so they automatically behave as if they were a site administrator on every site in the network.
* Second approach: The ""Super Admin"" / ""Network Administrator"" role only has network admin area capabilities (like `manage_network` or `manage_network_options`), so the user also needs to have the site administrator role for each site they want to access. (probably not?)
* If we support inheritance, can we handle the two kinds of roles together? A ""Network Administrator"" that has access to the network admin area is conceptually a bit different from a ""Network Editor"" who can only access all site admin areas on that network. If we find solid descriptive names, we're probably good here. For example, instead of having a ""Network Administrator"" being the role where one can access the network admin and at the same point be an administrator on all the network's sites, maybe that role should rather be called ""Network Manager"", while ""Network Administrator"" is a different role which basically means that user is an administrator on all the network's sites, but cannot access the network admin area.
* We would certainly need to handle that in a slow migration path: If we introduce a network role system with a predefined set of capabilities in let's say 4.8, we write a dev-note at the same time that tells plugin authors that they now need to add their custom capabilities to the new network role because that role no longer automatically can do anything. At this point however we still keep the current super admin functionality in sync so that the role actually still can do anything. We wait until 2-3 releases later to actually remove the sync thing, which means we get rid of the `site_admin` network option and from that point on use `is_super_admin()` and `get_super_admins()` only to retrieve users specified in the `$super_admins` global.
* Is this the right approach at all? Currently the ""Super Admin"" / ""Network Administrator"" can do ""anything but..."" rather than having a predefined set of capabilities. While we can address that with a migration like described above, we still need to think about whether it ''is'' the right way to do it. Maybe we need a concept like ""Role X can do anything under certain circumstances unless specifically denied"".
* How should we handle Multisite / Multinetwork? Multisite is the ""easy"" thing here - for all of the changes here we need to consider Multinetwork especially, even though it is not really supported by Core at this point.
* What do we think a ""Super Admin"" is? Is that a network administrator with specific capabilities, is it kind of a global administrator or is it a special thing that can do anything, thus not having a predefined set of capabilities? Core itself doesn't really know what a super admin is at this point. In most setups it is a network administrator / network manager as it's stored in a network option. But if you use the `$super_admins` global, it suddenly turns into some kind of a global administrator. Which of the two are we going to stick with for that terminology?
* Can we rename the term ""Super Admin"" at all (in terms of BC)? It would probably become either ""Network Administrator"" or ""Network Manager"" depending on the approach. If we can't rename it and keep the name for the ""network administrator"" role, how are we going to handle the higher role level?
This will likely become a feature project, but this ticket is for more discussion beforehand." flixos90
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 defect (bug) new needs-unit-tests 2013-12-02T19:38:49Z 2019-06-04T21:09:43Z "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 42403 Introduce singular capabilities for network activating plugins Role/Capability normal normal enhancement closed needs-unit-tests 2017-11-01T22:08:36Z 2020-09-20T12:12:58Z "In #38652, singular capabilities were added for activating and deactivating individual plugins.
The same should be added for:
* `network_activate_plugin`
* `network_deactivate_plugin`
" johnbillion
Future Releases 59950 read_dashboard capability? Role/Capability 6.4 normal normal feature request closed needs-unit-tests 2023-11-22T16:22:15Z 2023-11-23T02:52:00Z "Hi there,
I was looking at how I could enable or disable the ability to view the dashboard for specific user roles, but apparently there is no read dashboard capability that can be removed to not show the dashboard to the user...
This probably has to do with the fact that the dashboard is the first page the user gets to when going to the administration panel...
I would like to see an option added to wordpress where there is a read_dashboard capability, and perhaps some sort of functionality to specify which is the default page for a user that has read_dashboard disabled. Perhaps it could fall back to the first page in the menu on the left? Or perhaps fall back to the wordpress release update page?" simbaclaws
Next Release 52252 PHP Notice when `monthnum` query var is set without the `year` QV peterwilsoncc Rewrite Rules 4.3 normal normal 6.1 defect (bug) closed needs-unit-tests 2021-01-08T03:21:59Z 2022-08-08T15:18:33Z "`E_NOTICE: Undefined index: year in wp-includes/rewrite.php:413` / `E_NOTICE: Undefined index: monthnum in wp-includes/rewrite.php:413`
It looks like [32648] assumes the permalink structures will always include both `year` & `monthnum` or `monthnum` & `day` https://core.trac.wordpress.org/browser/trunk/src/wp-includes/rewrite.php?marks=400-403#L393
But a request such as `?monthnum=1` will cause it to check for the `year` query var which might be unset.
(Props to the pentester hitting WordPress.org with many junk requests for bringing this to light)" dd32
Next Release 45337 Strange pagination issue SergeyBiryukov Rewrite Rules 4.4 normal normal 5.5 defect (bug) closed needs-unit-tests 2018-11-13T05:18:15Z 2020-10-07T17:13:29Z "Hi,
I am facing strange pagination issue in WordPress. I could replicate it on other major WordPress websites as well apart from the one I am working on.
If you check this website: https://highlandexpeditions.com/blog/, everything works fine. Pagination works fine too.
However, if you visit https://highlandexpeditions.com/blog/2/, you will get the same page as https://highlandexpeditions.com/blog/. But the pagination links are ruined. You will have pagination links like (https://highlandexpeditions.com/blog/2/page/2/, https://highlandexpeditions.com/blog/2/page/3/) which goes to 404 page.
I think WordPress should show 404 for https://highlandexpeditions.com/blog/2/ rather than showing https://highlandexpeditions.com/blog/.
I don't think it has anything to do with themes or plugin. Because another popular website like https://www.wpbeginner.com/blog/ has the same issue. If you visit this URL (https://www.wpbeginner.com/blog/2/), you will find its pagination URL is wrong. I am able to replicate it on other websites as well.
Thanks." sachit.tandukar
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
Next Release 47466 Add a comment to .htaccess markers, labelling inserted strings as read-only/ dynamic SergeyBiryukov Rewrite Rules normal minor 5.3 enhancement closed needs-unit-tests 2019-06-03T12:44:49Z 2019-07-28T16:51:27Z "When using WordPress on an Apache server, with pretty permalinks enabled, WordPress will write `rewriteRule` directives to the .htaccess file in order to allow the pretty permalink functionality. On an out-the-box WordPress installation this will look like so:
{{{
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
}}}
This inserted block is wrapped in `BEGIN WordPress`/ `END WordPress` comments, referred to as markers. WordPress then uses these markers in order to update the correct part of the .htaccess file if the htacess file needs to be rewritten.
I work for a development company, who host a number of WordPress and non-WordPress sites. We frequently need to make changes to the htaccess file, which we generally do outside of WordPress (i.e. by directly editing the file). For example, we often add HTTP redirects via the htaccess file. Often the sysadmins who make these changes are not familiar with WordPress, and insert their custom rules within the `BEGIN WordPress`/ `END WordPress` markers, assuming that any WordPress-related rules should go between these comments. These custom changes are then discarded by WordPress at a later date, when the rewrite rules are next flushed.
I propose that additional comments are added to the htaccess file, to make it clear the the contents of the markers should only be edited via the use of WordPress filters.
For example:
{{{
# BEGIN WordPress
#
# The directives (lines) between `BEGIN WordPress` and `END WordPress` are dynamically generated,
# and should only be modified through the use of WordPress filters.
# Any changes to the directives between these markers will be overwritten.
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
}}}
It's worth noting that some plugins also use `insert_with_markers`, and so this should be returned with the correct marker name for any use of `insert_with_markers`.
" bradleyt
Future Releases 16839 Category Base Should be Slugified SergeyBiryukov* Rewrite Rules 3.1 normal normal Future Release defect (bug) accepted needs-unit-tests 2011-03-12T21:42:52Z 2023-03-02T15:52:09Z "Vanilla install of 3.1. Change category base to Foo Bar. Link generated is example.com/Foo Bar/cat (note the %20/space). Clicking link tries to access /FooBar/cat and 404's.
I see there are a few other tickets regarding categories, including #16662 but no specific mention of custom category base.
" miklb
Future Releases 43746 Custom post type single post feed returns a 404 if has_archive is set to false when calling register_post_type() SergeyBiryukov Rewrite Rules 4.9.5 normal normal Future Release defect (bug) reviewing needs-unit-tests 2018-04-12T13:58:17Z 2019-01-16T03:58:48Z "When using {{{register_post_type()}}}, the single post feed returns a 404 if {{{has_archive}}} is set to false. This seems to happen regardless of the value of {{{feeds}}} in the {{{rewrite}}} array. For example:
{{{
register_post_type(
'example',
array(
'rewrite' => array( 'slug' => 'my-custom-post-type', 'feeds' => true ),
'has_archive' => false
)
);
}}}
{{{
$ curl -IL https://example.com/my-custom-post-type/some-text/feed/
HTTP/1.1 404 Not Found
}}}
I'd expect a feed for the post to be built if {{{feeds}}} is set to {{{true}}}.
Note I have flushed permalinks." henry.wright
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 2018-01-23T22:07:25Z "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 41791 Unicode + add_permastruct breaks rewrite rules Rewrite Rules 4.9 normal normal Awaiting Review defect (bug) new needs-unit-tests 2017-09-04T11:15:57Z 2017-09-15T13:14:58Z "This was reported here https://github.com/woocommerce/woocommerce/issues/16673
To recreate the issue, create a taxonomy with a cyrillic name such as Сертификат. View the taxonomy archive. You'll see no results; it will go to the homepage rather than an archive.
In WooCommerce you can recreate this by creating an attribute (Product > Attributes) with a cyrillic name, and enabling the 'archive', assigning a term from this taxonomy to a product, and trying to view products by that term.
I managed to trace it back to the `add_permastruct`. The `struct` is added with unicode % encoded characters. When the rewrite rules are processed, it thinks these are placeholders so the `matches` variables do not align. See this screenshot for clarity:
https://www.dropbox.com/s/5vztnfm6895488a/query%20is%20wrong.png?dl=0
Notice all the $matches? Compare to a working taxonomy:
https://www.dropbox.com/s/24zyr5v7taw7b60/correct.png?dl=0
This can be fixed by using `urldecode` when adding the permastruct. I don't know if this has side effects but it worked in testing.
Patch to follow.
" mikejolley
Future Releases 43571 `add_feed` with regex characters breaks rewrite rules SergeyBiryukov Rewrite Rules normal normal Future Release defect (bug) reviewing needs-unit-tests 2018-03-18T17:44:20Z 2019-01-16T03:54:36Z `add_rule( 'test.json', ... )` does not get escaped with `preg_quote`. Fine for this example, but something like `add_rule( 'test[json]', ... )` will definitely yield unexpected results. Something like `add_rule( 'test???', ... )` will break the whole feed (maybe even more) regular expression. soulseekah
Future Releases 35482 Archival pagination fails in 4.4 and up Rewrite Rules normal normal defect (bug) new needs-unit-tests 2016-01-15T20:59:37Z 2019-06-04T21:19:22Z "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 35916 WP_Rewrite::generate_rewrite_rules() ignores boolean $endpoints / $feed parameters for CPT Rewrite Rules normal normal defect (bug) new needs-unit-tests 2016-02-23T08:34:12Z 2019-06-04T21:20:24Z "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 defect (bug) new needs-unit-tests 2010-09-29T18:00:08Z 2022-12-05T12:09:28Z 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 defect (bug) new needs-unit-tests 2013-08-21T00:43:28Z 2019-06-04T21:08:57Z "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 enhancement reopened needs-unit-tests 2010-06-02T14:34:08Z 2019-06-04T21:05:49Z "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 enhancement closed needs-unit-tests 2011-04-20T00:18:21Z 2024-03-07T00:04:10Z "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 enhancement reopened needs-unit-tests 2011-03-11T01:09:14Z 2019-06-04T21:06:33Z "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." anonymized_154007
Future Releases 9824 make better use of stubs when verbose rules should apply Rewrite Rules normal normal task (blessed) reopened needs-unit-tests 2009-05-15T01:03:56Z 2019-06-04T21:05:28Z "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 2020-10-26T18:56:25Z "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 40577 Introduce a capability for viewing the revisions of a post adamsilverstein Revisions 2.6 normal normal Future Release enhancement assigned needs-unit-tests 2017-04-26T11:36:57Z 2023-03-02T06:35:53Z "In order to view the revisions of a post, a user needs the ability to edit the post. This makes sense because it may be undesirable for users to be able to view older revisions of a post which they cannot edit.
However it may be desirable to allow certain users to view the revisions of a post which they cannot edit, for example for auditing purposes, or to allow contributors to browse the revisions of their own published post." johnbillion
Next Release 40383 Comments Controller is not checking permission of Custom Post Type controller class TimothyBlynJacobs REST API 4.7 normal normal 5.3 defect (bug) closed needs-unit-tests 2017-04-07T10:07:37Z 2019-10-03T18:35:07Z "In class-wp-rest-comments-controller.php
{{{
protected function check_read_post_permission( $post, $request ) {
$posts_controller = new WP_REST_Posts_Controller( $post->post_type );
}}}
$posts_controller is hard coded to use WP_REST_Posts_Controller
But what if you have set
{{{
'rest_controller_class' => 'Plugin_REST_CPT_Controller',
}}}
Shouldn't the check_read_post_permission function check for a custom post type controller class first?
Something like this
{{{
protected function check_read_post_permission( $post, $request ) {
$post_type = get_post_type_object( $post->post_type );
$posts_controller_class = ! empty( $post_type->rest_controller_class ) ? $post_type->rest_controller_class : 'WP_REST_Posts_Controller';
$posts_controller = new $posts_controller_class( $post->post_type );
}}}
Would be happy to push a fix for this if needed" langan
Next Release 50189 Only validate format if type is string TimothyBlynJacobs REST API 5.3 normal normal 5.5 defect (bug) closed needs-unit-tests 2020-05-16T19:43:08Z 2020-07-04T19:52:01Z "In #44975 we added support for a schema to specify multiple types. The way this works is we iterate over each possible type and try to find a successful validation. This poses an issue if you are trying to use a schema with a string type and the format keyword. This is because the schema will try and apply the `format` validation even if it isn't checking against the string type.
From the JSON Schema spec:
> A format attribute can generally only validate a given set of instance types. If the type of the instance to validate is not in this set, validation for this format attribute and instance SHOULD succeed.
We should update `rest_validate_value_from_schema()` and `rest_sanitize_value_from_schema()` to only check against the `format` keyword if we are validating a string.
This could be a BC break if a developer had omitted a type definition or misspelled it ( `strin` instead of `string` ). We could potentially account for this by also applying the check if there was no type set or it was invalid.
" TimothyBlynJacobs
Next Release 49695 REST API check_template function can return false error TimothyBlynJacobs REST API 4.9 normal normal 5.6 defect (bug) closed needs-unit-tests 2020-03-24T23:51:00Z 2020-10-24T14:10:27Z "wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php Line 1209
function check_template
----
This function does not check get_post for an empty post:
{{{#!php
get_page_templates( get_post( $request['id'] ), $this->post_type );
}}}
On my Setup, this returned the WP_Error rest_invalid_param because get_post() returned an empty Post (with $post->ID == 0).
I changed this to:
{{{#!php
ID == 0) {
$post = null;
}
// If this is a create request, get_post() will return null and wp theme will fallback to the passed post type.
$allowed_templates = wp_get_theme()->get_page_templates( $post, $this->post_type );
}}}
This checks, if post is empty. This will save some API Requests from running in errors and does no harm.
PS: No idea, why get_post() can return an empty WP_Post object. My API did not send an ID and was a POST Request.
" Kipperlenny
Next Release 40861 REST API saves attachments with absolute path for `_wp_attached_file` on Windows platforms SergeyBiryukov REST API 4.6 normal normal 4.9.8 defect (bug) closed needs-unit-tests 2017-05-25T12:08:11Z 2018-07-24T16:53:18Z "On windows, create media with rest api insert the meta ""_wp_attached_file"" not correctly.
It save the absolute path and not the relative path.
the function ""wp_slash"" add backslash in windows file path.
file: class-rest-attachements-controller.php
line: 150
{{{#!php
cap->publish_posts ), even if the post was previously published.''" adamsilverstein
Next Release 50213 REST API: Allow queries other than the main query to be `is_home` whyisjake REST API 4.4 normal normal 5.5 defect (bug) closed needs-unit-tests 2020-05-20T14:42:07Z 2020-06-16T06:02:56Z "[35690] prevented `WP_Query` from falling back to `is_home` during REST requests.
ticket:34373#comment:2 noted:
> If WP_Query hardcodes an is_rest, it's going to mean some awkward workarounds in the case where one actually wants to make a 'home' query in a REST request.
And that is the situation I present now :)
My use case is a REST API endpoint that provides data to a mobile application in which some screens mirror the website's frontend.
Within the route callback, it's possible to create a category or singular query using `new WP_Query( $args )` and to pass those queries to existing functions that return data based on `$query->is_category()`, `$query->is_singular()`, etc. But it's currently not possible to reuse existing functions that check `$query->is_home()` unless the `is_home` property is set by hand. For example:
{{{
$query = new \WP_Query();
add_action(
'parse_query',
function ( $q ) use ( $query ) {
if ( $q === $query ) {
$q->is_home = true;
}
}
);
}}}
The attached patch proposes to limit the `is_home` restriction to the main query, which I think would allow for secondary queries to behave normally while respecting the spirit of [35690].
" dlh
Next Release 40614 REST API: String argument for rest_do_request/rest_ensure_request does not work as expected. kadamwhite REST API 4.4 normal normal 5.3 defect (bug) closed needs-unit-tests 2017-04-30T22:07:12Z 2020-02-03T16:47:54Z "According to the `rest_do_request()` php docs, a `string` parameter type is accepted. Currently, this is forwarded to `rest_ensure_request()` which only accepts a `WP_REST_Request` object or an array. When a string argument is passed a request object is instantiated with a string value for the request attributes which is improper.
Either the docs should be updated, or, ideally, the `rest_do_request` and `rest_ensure_request` functions would be updated.
I could see those two functions either accepting a route path, like `/wp/v2/posts` or a full url, `www.example.org/wp-json/wp/v2`. Since those API functions are internal to the API instance, it makes most sense, in my mind at least, to accept a path style argument. Otherwise, there would be needless boiler plate: `rest_do_request( rest_url( '/wp/v2/posts' ) )`.
The simplest implementation would then be to instantiate a `WP_REST_Request` object with the given path as the second constructor argument if the `$request` parameter is a string. However, this would make it impossible to quickly make a request with any query parameters attached.
That gives us a few options.
1. Change `rest_ensure_request` to do `WP_Rest_Request::from_url( rest_url( $request ) )` in case of a string argument.
2. Introduce `WP_Rest_Request::from_path` that accepts a path and does the proper `parse_url` and `wp_parse_str` handling.
3. Only accept a full URL to `rest_do_request`.
If it might be confusing that `rest_ensure_request` accepts a path argument instead of a URL, conceivably it could accept both and switch on the presence of a `/` at the start of the string.
Happy to submit a patch to whichever makes most sense." TimothyBlynJacobs
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 39341 `wp.api.utils.decorateFromRoute` should use `_.extend` not `_.union` adamsilverstein REST API 4.7 normal normal 4.7.3 defect (bug) closed needs-unit-tests 2016-12-20T10:55:03Z 2017-02-20T06:34:17Z "
{{{
modelInstance.prototype.options = _.union( routeEndpoint.args, modelInstance.prototype.options );
}}}
Are not the arguments to _.union objects not arrays? In which case _.extend would be more appropriate.
" Magenta Cuda
Next Release 45448 rest_sanitize_value_from_schema() returns invalid value when using a schema of type array with a null value SergeyBiryukov REST API 4.9.8 normal normal 5.1 defect (bug) closed needs-unit-tests 2018-11-29T17:37:21Z 2019-01-10T21:45:12Z "When using the following configuration, you will get an array containing 1 empty string instead of an empty array;
{{{
$schema = array(
'type' => 'array',
'items' => [
'type' => 'string',
],
);
$value = rest_sanitize_value_from_schema( null, $schema );
var_dump( $value );
}}}
The solution for this would be to modify the following line in rest_sanitize_value_from_schema():
{{{
$value = preg_split( '/[\s,]+/', $value );
}}}
with
{{{
$value = preg_split( '/[\s,]+/', $value, null, PREG_SPLIT_NO_EMPTY );
}}}
" hogash
Next Release 49116 Add Links to the REST version of a Resource in the header of the page dshanske REST API 4.7 normal normal 5.5 enhancement closed needs-unit-tests 2020-01-01T21:55:06Z 2020-08-09T04:38:37Z "Proposing as suggested by @timothybjacobs in Slack, that on each page, a link in the header of the HTML file to the REST route for that resource.
So, an author page would link to the user endpoint for that user. A post to the rest route to that specific post, etc.
The rel on the link to the REST API endpoint is rel=""https://api.w.org/"". This should probably be a rel=""alternate"" which indicates an alternative representation of the page, with type ""application/json"" as it is technically a json representation of the page, but this may need more discussion." dshanske
Next Release 35613 Add granularity to REST API embeds joehoyle REST API normal normal enhancement closed needs-unit-tests 2016-01-26T00:13:04Z 2017-01-27T20:23:10Z "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
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 2019-01-14T16:56:28Z "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
Next Release 39578 Enhancement for rest api comment controller create_item method to check for WP error rmccue REST API 4.7 normal normal 4.8 enhancement closed needs-unit-tests 2017-01-13T20:36:37Z 2017-01-18T01:32:38Z "In the WP_REST_Posts_Controller class, the create_item method calls the prepare_item_for_database method and checks its response for a WP error object.
{{{#!php
prepare_item_for_database( $request );
if ( is_wp_error( $prepared_post ) ) {
return $prepared_post;
}
}}}
This allows for further filtering and custom validation via the rest_pre_insert_{$this->post_type} filter and for returning a WP Error if needed to stop the request and return messaging.
I'd like to propose similar in the WP_REST_Comments_Controller class. Right now when the create_item method applys the rest_pre_insert_comment filter, it doesn't check for a WP Error response.
{{{#!php
cap->edit_posts`, etc, for the primitives and `edit_post, $post_id` for the meta caps.
To allow theme and plugin developers to modify the capability used for editing global styles via a filter, it would be good to defer to the post types setting. At the moment, such code would cause a conflict between the permission checks in the API and those in `wp_insert_post()`.
I'll put this on the 5.9 milestone for visibility as the endpoint was introduced during the current cycle." peterwilsoncc
Future Releases 39889 Improve/Fix REST Response on Multisite when an endpoint for a non-existent site is hit. REST API 4.7 normal normal Future Release defect (bug) new needs-unit-tests 2017-02-16T15:52:54Z 2019-07-09T18:42:18Z "Currently if you hit the endpoint for a domain on a site that doesn't exist it will behave the same as on a normal request.
- visit https://nonexistentsubdomain.eventsmart.com/wp-json in a REST client.
- Take note of the ""Location"" header in the response: https://eventsmart.com/wp-signup.php?new=nonexistentsite. It's also returned with a HTTP 302
Granted this is kind of edgecase, but I think it'd be better to handle things a bit better on REST requests. The question is how? I think from the standpoint of the REST client it'd be better to just return a 404 and a ""site doesnt' exist"" message (or something to that affect)." nerrad
Future Releases 53622 Query Param status default is a string value, but an array is required rachelbaker* REST API normal minor Awaiting Review defect (bug) accepted needs-unit-tests 2021-07-07T17:24:41Z 2023-02-20T21:33:06Z "The default value in the collection params that is a string. https://github.com/WordPress/wordpress-develop/blob/953e1c5f8313a89d4d3b99ab5996b4660045c976/src/wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php#L2847
Really, we should make that `['publish']`.
Original commit: https://github.com/WordPress/wordpress-develop/commit/ede099a7047a150a37d43a380e661b99387bce41" austyfrosty
Future Releases 49538 Can't get a subset of `_embedded` using `_fields` REST API 5.3 normal normal Future Release enhancement new needs-unit-tests 2020-02-27T21:26:38Z 2020-10-22T00:23:12Z "I'd expect to be able to limit which values get returned in embedded fields, the same way that I can with standard fields. e.g.,
https://wordpress.org/news/wp-json/wp/v2/posts/8384?_fields=slug,_embedded.author.name&_embed
That would make the response faster and smaller." iandunn
Future Releases 42785 Change default of `show_in_rest` in register_post_type and register_taxonomy REST API normal normal Future Release enhancement assigned needs-unit-tests 2017-12-03T19:34:14Z 2020-01-07T23:56:41Z "Right now `show_in_rest` is defaulted to `false` in `register_post_type` and `register_taxonomy`. To improve usefulness of the REST API I think the time has come to include default publicly readable data into the REST APi.
This helps with https://github.com/WordPress/gutenberg/issues/1342#issuecomment-319920850 for Gutenberg too.
I propose we default `show_in_rest` to `true` in the following scenarios:
- Object types registered with `public => true` (only).
- Object types registered with `publicly_queryable => true`.
I have other future ideas for further cases (including authenticated-only cases) but I think this is a good start.
" joehoyle
Future Releases 54293 Expand functionality of themes REST API REST API 4.7 normal normal Awaiting Review enhancement new needs-unit-tests 2021-10-20T09:30:08Z 2022-06-07T11:59:12Z "Current the REST API for themes is extremely limited. It only allows for listing themes and getting the current theme. However, there are lots theme related functions that are not possible to access via this api. This includes ( but it not limited to )
- Installing new themes
- Network activating theme ( multisite only )
- Network deactivating theme ( multisite only )
- Active ( switch to theme )
- Deleting theme
Any themes api should allow the patterns / structure of the plugins REST API, in it's params and responses.
It is also worth noting, that have a multisite element, as themes can be network activated / deactivated." spacedmonkey
Future Releases 41463 Improve REST API tests that don't perform any assertions johnbillion* REST API 4.7 normal normal Future Release enhancement accepted needs-unit-tests 2017-07-27T18:02:35Z 2022-09-01T22:54:20Z "There are a bunch of REST API tests that don't perform any assertions. This creates noise in the test results as they get marked as risky tests.
These tests are present because their test class extends the abstract `WP_Test_REST_Controller_Testcase` class, which requires several methods to be implemented which don't make sense for all REST API routes.
These tests can be improved so they do actually perform assertions related to their behaviour." johnbillion
Future Releases 52840 Include filesize information in REST API response for all media types rachelbaker* REST API normal normal Future Release enhancement accepted needs-unit-tests 2021-03-17T21:50:29Z 2023-01-13T21:45:46Z "Requesting the `/media` REST API endpoint, only **audio** attachments include filesize information in the response data (in `media_details->filesize`).
I suggest to check for each item if `filesize` is present, or else fill it in using the actual file. This would be pretty much in line with what is done in [https://github.com/WordPress/wordpress-develop/blob/fa05e5e7336a18c19fe6a94d68d30351876ee090/src/wp-includes/media.php#L3972-L3980 wp_prepare_attachment_for_js].
Making the information available locally, when creating the response data, is much more performant than having to request the file in one or more follow-up requests." tfrommen
Future Releases 49179 Manage Post trackbacks within the REST API REST API 4.7 normal normal Future Release enhancement new needs-unit-tests 2020-01-12T18:23:05Z 2020-10-24T05:51:08Z "Hi,
I've noticed, unlike the Classic Editor, the Blocks Editor does not include a place to add trackbacks to a post. After looking more into it, I've found a possible reason for it could be that the `WP_REST_Posts_Controller` doesn't support adding trackbacks.
I believe it's weird the Blocks Editor includes a Discussion panel saying `Allow pingback and trackbacks` although it's only possible to add trackbacks from the Classic Editor.
I suggest the attached as a primarily step before working from the Gutenberg GH repo to suggest a way to deal with this feature.
In the meantime, if some of you need to send trackbacks from the Blocks Editor, you can use this [https://github.com/imath/retroliens plugin]. " imath
Future Releases 39061 REST API pagination: Large INT passed to `paged` query arg doesn't fail properly joehoyle REST API 4.7 normal normal Future Release enhancement reopened needs-unit-tests 2016-12-04T18:43:51Z 2017-10-04T20:46:33Z "When an absurdly large value is passed to the REST API (e.g. `/wp/v2/pages?page=23924321212413345333`), it returns the first page of results instead of an error. The problem is during validation and sanitization of the value, where the passed value is run through `absint`, which returns another absurdly large value, which then gets nullified by PHP, which becomes `1`.
{{{
wp> print_r( rest_sanitize_value_from_schema( 23452345346346345456567356, array( 'type' => 'integer' ), 'page' ) );
3481259413623275520
=> bool(true)
wp> print_r( rest_validate_value_from_schema( 23452345346346345456567356, array( 'type' => 'integer' ), 'page' ) );
1
=> bool(true)
wp> absint(23924321212413345333);
=> int(5477577138703794176)
}}}
Edge case, but worth noting since smaller values that are larger than the number of pages return an empty array (like if there are only 2 pages of posts, but 3 are requested).
Related: #19728." morganestes
Future Releases 38702 REST API: Add accessor functions for post_status and post_parent REST API 4.7 normal normal Future Release enhancement new needs-unit-tests 2016-11-08T02:26:23Z 2022-01-18T13:48:55Z "In order to enable better permission checks for Customiser Changesets, these need to be filterable.
See [https://github.com/xwp/wp-customize-snapshots/issues/32 xwp/wp-customize-snapshots#32]. Split from #38701." rmccue
Future Releases 41821 REST API: Add support for threaded comments REST API 4.7 normal normal Future Release enhancement new needs-unit-tests 2017-09-07T06:39:29Z 2020-09-24T18:08:59Z "(I don't think we have a tracking ticket for this already.)
We should add support for threading comments, particularly in ""flat"" mode. Flat mode would allow threading in frontend code relatively easily.
The only issue with this is that it will overflow `per_page`. We intentionally treat this as an indicator and occasionally have less items already (if they're filtered inside the `get_items()` loop, e.g.), so I don't think this is a huge issue. In addition, threaded mode should be opt-in in any case.
Previously: https://github.com/WP-API/WP-API/issues/1612" rmccue
Future Releases 46238 REST API: Allow conditional field registration REST API normal normal Awaiting Review enhancement new needs-unit-tests 2019-02-12T00:42:00Z 2020-10-25T12:49:27Z "`register_rest_field()` allows us to add additional fields to API call responses but it doesn't allow us to do so conditionally. in prior art we add a field and then remove it later when it's not needed.
why would inclusion of a field be conditional? what is wrong with returning `null`?
we came across this when wanting to add metadata to video files, which are `post` types and conflated with posts and other media attachments. we'd like to be able to just add fields to video file media requests and not pollute the responses for all of the other ""subtypes."" we'd also like to do it without resorting to surprising behaviors like adding and later removing them.
in this ticket I'd like to propose two approaches to accomplishing this goal. the first is a bit clever but should make it possible to extend existing behaviors without breaking any code and without introducing further confusion on how to add fields. it uses a ""sentinel value"" passed into the `get_callback()` function which can be returned to indicate that the field should not exist.
the second approach creates a new function `register_conditional_rest_field()` and provides a wrapped response format to indicate whether the field should be added. this approach is less idiomatic in my opinion as we're not used to returning wrapped values.
---
I thought for sure I'd seen a discussion around this before but I couldn't find any tickets with my search. that being said I'm curious why this doesn't already exist as it seems like it could be a common need, though I'm not sure how the fact that media attachments are a bit odd in comparison to custom post types comes into play." dmsnell
Future Releases 41616 REST API: Expose old slugs REST API 4.8.1 normal normal Future Release enhancement new needs-unit-tests 2017-08-12T05:32:45Z 2021-10-08T10:20:07Z "Expose the old slugs for all posts including custom post types in the REST API.
For example, when building a React-powered app using the WordPress REST API the old slugs are required so that users can be automatically redirected if they clicked on an old link.
To expose the old slugs I created a small plugin (see below):
{{{#!php
true, 'show_in_nav_menus' => true ) ) ;
$args = array(
'get_callback' => 'get_old_slugs_for_api',
'schema' => null
);
foreach ($post_types as $type) {
register_rest_field( $type, 'old_slugs', $args );
}
}
function get_old_slugs_for_api( $object ) {
//get the id of the post object array
$post_id = $object['id'];
//return the post meta
return get_post_meta( $post_id, '_wp_old_slug' );
}
}}}
" crosescu
Future Releases 45140 REST API: Increase upper bound allowed on per_page argument REST API normal normal Future Release enhancement new needs-unit-tests 2018-10-21T17:16:19Z 2018-10-31T11:38:29Z "In contexts where a REST API client needs to fetch ''all'' entries for a resource, it would be more practical to fetch entries in sets of 200, 300, or 400, instead of sets of 100. Fetching entries in sets of 100 can cause excessive memory usage because WordPress is loaded over and over again. Increasing the limit will provide a better balance between memory consumption in a single request vs. total memory consumption across all requests.
The original `per_page=100` limit was [https://github.com/WP-API/WP-API/issues/1609#issuecomment-177169125 somewhat arbitrary]; if I recall correctly, we picked `100` as a nice round number that was reasonably certain not to cause performance issues.
Before we pick `per_page=200` vs. `per_page=300` vs. `per_page=400`, we should:
1. Profile memory consumption of each.
2. Identify what amount of memory we can reasonably expect on shared hosting these days.
After we've done this, we can pick the best available option.
Notably, we can't go above `500` as we'll hit `split_the_query` which has negative performance implications.
Previously https://github.com/WordPress/gutenberg/issues/6694" danielbachhuber
Future Releases 38813 REST API: Test schema registration for required fields. jnylen0 REST API normal normal Future Release enhancement assigned needs-unit-tests 2016-11-16T06:21:36Z 2019-11-30T10:53:13Z "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 40748 Use REST API for Community Events REST API 4.8 normal normal Future Release enhancement new needs-unit-tests 2017-05-12T17:39:23Z 2020-10-25T03:56:50Z "#40702 introduced new Community Events to the News widget on the Dashboard screen, but it uses admin-AJAX.
Converting to the REST API is a good opportunity to lay some groundwork for migration the rest of wp-admin in the future.
The work for this was started in #40702, but it'll be easier to keep track of with a new ticket.
I'm working on an updated version of `40702.11.diff` and will upload it soon." iandunn
Future Releases 39473 get_routes() called multiple times within single REST request causing the rest_endpoints() filter to also fire more than once REST API 4.4 normal normal Awaiting Review enhancement new needs-unit-tests 2017-01-04T21:59:38Z 2023-01-19T23:28:07Z "Hi all,
Many thanks for creating the REST API, and also for getting it into core! :)
When I had a closer look at how to integrate this in our projects I noticed something peculiar with the rest_endpoints() filter: it is called multiple times over; in some cases twice, in others three times.
So I did a little digging around and found that the root cause seemed to be the use of get_routes() at multiple locations:
- in the rest_pre_dispatch filter (rest_handle_options_request)
- in the rest_post_dispatch filter (rest_send_allow_header)
- in the dispatch() itself
- in the get_index() method
- in the get_namespace_index() method
After looking how these locations interact with each other, I couldn't detect any code which altered the generated route map between consecutive calls to get_routes().
I will add a patch in which I propose to store the generated route map in the class, and re-use that one instead of generating yet again the same array (and also re-filtering the same array).
Since the name 'endpoints' is already taken, and being used in the initialization as well, I thought it would be prune to use another variable name: $route_map, which is also being used in the current doc-block.
I did not profile this patch (not really sure how to do that), so I'm not sure if storing this rather large associative array is a good thing to do. However generating it multiple times (and re-filtering it also) may also be quite 'expensive'.
Thanks,
Ruud
" ruud@…
Future Releases 40365 Introduce a REST API endpoint for sites REST API normal normal Future Release task (blessed) new needs-unit-tests 2017-04-05T00:18:18Z 2020-04-03T05:00:47Z "It should be possible to manage sites in a multisite configuration through the REST API.
* List sites: `GET wp/v2/sites/`
* Retrieve a site: `GET wp/v2/sites/`
* Create a site: `POST wp/v2/sites/`
* Update a site: `PUT wp/v2/sites/`
* Delete a site: `DELETE wp/v2/sites/`
Data included in a site object should at least mirror the data available for the site in `wp_blogs`. Additional ideal pieces of data for a site include `blogname`, `blogdescription`, `home`, and `siteurl`. It's possible that creating a new meta table for sites can help developers register meta for inclusion with a site object (See #37923).
Sites should be accessible by default for authenticated users only. Network (global) admins should have access to all sites. Site users should have access to the sites they are members of. The ""My Sites"" list is a great candidate for exploring how this will work. See #15317.
As of the introduction of `get_sites()` in 4.6.0, retrieving sites is a much better experience. The methods used to create, update, and delete sites in multisite are not as pleasant right now. We should investigate each of these and determine what can be done to streamline the process. The first improvement is probably in creating a site. See #40364." jeremyfelt
Future Releases 39072 Add gmt_offset as a REST API setting REST API 4.7 normal normal defect (bug) closed needs-unit-tests 2016-12-04T20:21:43Z 2019-11-29T01:58:53Z "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
Future Releases 54666 Numeric theme not work REST API 5.7 normal normal defect (bug) closed needs-unit-tests 2021-12-20T08:52:40Z 2021-12-20T12:50:04Z "A template with a numeric name is not displayed in the list of active templates.
How to reproduce the problem:
- Create a template with a numeric name (example 123456).
- Activate the template in the list of templates on your site
The selected template will not appear as active in the list of templates.
Also, it will not be in the list of active templates in the REST API /wp-json/wp/v2/themes?status=active
This problem also affects the call of functions in the Gutenberg editor (add_theme_support does not work).
This problem may be related to the fact that when forming an array of templates, the key is the name of the template, and according to the documentation, the PHP converts the keys of the array (https://www.php.net/manual/en/language.types.array.php)
{{{
Additionally the following key casts will occur:
Strings containing valid decimal ints, unless the number is preceded by a + sign, will be cast to the int type. E.g. the key ""8"" will actually be stored under 8. On the other hand ""08"" will not be cast, as it isn't a valid decimal integer.
Floats are also cast to ints, which means that the fractional part will be truncated. E.g. the key 8.7 will actually be stored under 8.
Bools are cast to ints, too, i.e. the key true will actually be stored under 1 and the key false under 0.
Null will be cast to the empty string, i.e. the key null will actually be stored under """".
Arrays and objects can not be used as keys. Doing so will result in a warning: Illegal offset type.
}}}
Possible suggestions for solving the problem:
File in wp-icnludes/rest-api/endpoints/class-wp-rest-themes-controller.php replace this
{{{#!php
get_stylesheet() === $theme_b->get_stylesheet();
}
}}}
with this
{{{#!php
get_stylesheet() === (string)$theme_b->get_stylesheet();
}
}}}
or, when forming an array of templates, store the name as a value.
" winterpsv
Future Releases 44789 REST API: Improved media titles when created from filename REST API normal normal defect (bug) closed needs-unit-tests 2018-08-14T07:03:50Z 2024-01-29T19:29:09Z "Issue first discovered here: https://github.com/WordPress/gutenberg/issues/8902. It's very similar to this previous core ticket #37989
When you upload an image via the REST API, the image's automatically created title attribute is sub-optimal. As an example, if you upload `image name.png` through the REST API - the title will become `image-name`. If you do the same through WP core's media gallery though, the image title will be `image name`. More explanation on this in the above two tickets.
To get the rest api's behavior more inline with the rest of WP core, syncing up `WP_REST_Attachments_Controller::create_item media_handle_upload()` with `media_handle_upload()` seems like the best option.
I've attached a patch doing just this, however as a disclaimer, I'm fairly unfamiliar with the process of uploading an image via raw POST data - so I've just kind of left that path untouched and it will act the same as it currently does. Also, as an added benefit to making titles more friendly by default, using `wp_basename()` is i18n friendly.
Some concerns off the top of my head:
1. Will `pathinfo()` in this scenario always be okay? It is used in `media_handle_upload()` but not in `media_handle_sideload()` where the regex is used instead to remove the extension.
2. Are there cases where the ""name"" index in `$files['file']['name']` won't be available when uploading a file?
3. Any ideas to make the image title more friendly when going through the raw POST data path of the conditional?" iCaleb
Future Releases 44648 User creation even though an error is thrown REST API 4.9.7 normal normal defect (bug) closed needs-unit-tests 2018-07-26T10:08:29Z 2020-10-24T05:14:31Z "I just had an issue, the issue itself pretty mush doubles like this issue #40889
When creating a new account including a (registered) custom meta I get the following error message.
{{{
{
""code"":""rest_cannot_update"",
""message"":""Sorry, you are not allowed to edit the _r24b_remote_id custom field."",
""data"":{""key"":""_r24b_remote_id"",""status"":403}
}
}}}
But even though throwing an error, the user is created anyway, but I don't get the User ID in return.
Sending the unchanged request a second time will now cause this answer
{{{
{
""code"":""existing_user_login"",
""message"":""Der Benutzername existiert bereits!"",
""data"":null
}
}}}
So besides the bug from the other ticket.
A nested error like in my case should either make the whole creat process fail(or undo the successful first part of the creation) or the error message should contain the information that the user was created and only the meta field failed." apermo
Future Releases 38731 Allow publicly readable settings within WP_REST_Settings_Controller REST API 4.7 normal normal enhancement closed needs-unit-tests 2016-11-09T13:20:07Z 2020-10-25T03:00:16Z "With `register_setting()` developers can expose a setting to appear within REST queries on `/wp/v2/settings`. Very useful I thought for API only based frontends. However though I agree that editing these settings is limited to those authenticated users who have 'manage_options' it appears that the reading of these settings is limited to the same.
Would it therefore be useful to allow exposing some/all of these settings to unauthenticated users. Maybe with a `'public' => true` flag on each setting so that this can be opt-in from a security point of view?
The alternative appears to be for developers to effectively duplicate the WP_REST_Settings_Controller under a different namespace/endpoint exposing those fields they wish to be viewable." davecpage
Future Releases 41159 "REST API: Add a way to determine if a request is an embedded ""sub-request""" REST API 4.4 normal normal enhancement closed needs-unit-tests 2017-06-25T12:27:04Z 2020-10-25T04:02:12Z "Currently it's difficult to determine whether a request is the ""root"" request or a ""child"" embedded request due to `?_embed` using multiple `WP_REST_Request` objects. #38964 will help a bit, but we should also add a way to directly track whether a request is part of an embed tree. Something like this:
- `$request->is_embed`: boolean property indicating whether the request is a ""child"" embedded request
- `$request->embed_parent`: `WP_REST_Request` object pointing to parent request, or `null` if none" jnylen0
Future Releases 41549 REST API: Use `wp.apiRequest` helper in `wp.api` Backbone client adamsilverstein REST API normal normal enhancement closed needs-unit-tests 2017-08-03T14:50:13Z 2019-12-11T18:43:03Z "Follow-up to #40919. The `wp-api.js` Backbone client should use `wp.apiRequest` to do its API calls. This may be accomplished through overriding `Backbone.ajax` or through a change in the `wp-api.js` code.
This will allow client-side code to override or modify all WP REST API calls in a single, centralized place.
cc @adamsilverstein for your thoughts on the best way to achieve this." jnylen0
Future Releases 40580 rest_ensure_response() can return WP_Error object, but is consequently not checked in get_item() method REST API 4.7 normal normal enhancement closed needs-unit-tests 2017-04-26T15:46:26Z 2019-09-09T03:14:06Z "Hi,
I have used the rest_prepare_{$this->post_type} filter to check if my single post item is allowed to generate output on a particular REST request.
If in my case this isn't allowed, I use this filter to return a WP_Error object
I was assuming this was OK to do, since also the doc-block says:
@return WP_REST_Response|WP_Error Response object on success, or WP_Error object on failure.
But.. if $response becomes a WP_Error object, the call to $response->link_header fails.
I will attach a patch to check for the possibility that $response is an WP_Error object
Like to hear your thoughts.
Thanks,
Ruud
" ruud@…
Next Release 27833 Add hook to hidden inline data for quick edit chriscct7 Quick/Bulk Edit 3.8.3 normal normal enhancement closed needs-unit-tests 2014-04-16T12:53:27Z 2018-03-05T22:00:55Z "It'd be handy to be able to add data that will be used by the quick edit in the same place that the default data is already added. This could be achieved by adding an action hook in the get_inline_data() function.
{{{
/**
* {@internal Missing Short Description}}
*
* @since 2.7.0
*
* @param unknown_type $post
*/
function get_inline_data($post) {
$post_type_object = get_post_type_object($post->post_type);
if ( ! current_user_can( 'edit_post', $post->ID ) )
return;
$title = esc_textarea( trim( $post->post_title ) );
/** This filter is documented in wp-admin/edit-tag-form.php */
echo '
';
}
}
if ( !$post_type_object->hierarchical )
echo '
' . (is_sticky($post->ID) ? 'sticky' : '') . '
';
if ( post_type_supports( $post->post_type, 'post-formats' ) )
echo '
' . esc_html( get_post_format( $post->ID ) ) . '
';
do_action( 'inline_data', $post );
echo '
';
}
}}}" helgatheviking
Future Releases 39186 Bulk actions not correctly applied when selecting bulk actions in both the top and bottom bulk actions dropdowns engelen Quick/Bulk Edit 4.7 normal normal Future Release defect (bug) assigned needs-unit-tests 2016-12-08T14:48:44Z 2023-02-28T16:25:04Z "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 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 2021-10-29T07:36:52Z "`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 40669 Proper query cache invalidation on queries meta queries boonebgorges Query normal normal 4.9 defect (bug) closed needs-unit-tests 2017-05-04T19:21:14Z 2017-10-12T15:19:31Z "Currently, terms and comments have query caching and meta query support. Queries are cached using the use the last_changed in the object cache group. Query caches are invalidated (busted) when the last_changed value is changed, when a term / comment is changed / created. However, when meta on these objects are changed / deleted, query are not invalidated. Example.
- Run a comment query with a meta query foo=bar. Get 4 results.
- add_comment_meta to a new comment.
- Run a comment query with a meta query foo=bar. It will return cached result of 4, even through the result should be 5.
This is an issue, if plugin developers, use the meta functions to add meta to an object, queries should still invalidate. " spacedmonkey
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 39717 Search_terms_count includes stopwords Query normal normal defect (bug) closed needs-unit-tests 2017-01-27T06:17:49Z 2017-01-31T04:24:46Z "If a search includes stopwords, the ""search_terms_count"" parameter will not match the number of search terms in ""search_terms"". If you search for ""call of the wild"" in an English installation, you'll get:
{{{
[search_terms_count] => 4
[search_terms] => Array
(
[0] => call
[1] => wild
)
}}}
The correct result should be:
{{{
[search_terms_count] => 2
[search_terms] => Array
(
[0] => call
[1] => wild
)
}}}
A simple correction would be to move the line
{{{
$q['search_terms_count'] = count( $matches[0] );
$q['search_terms'] = $this->parse_search_terms( $matches[0] );
}}}
after the search term parsing and change it to this:
{{{
$q['search_terms'] = $this->parse_search_terms( $matches[0] );
$q['search_terms_count'] = count( $q[""search_terms""] );
}}}
Now the search_terms_count is correct. As far as I can tell, this has no adverse side effects." msaari
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 `