__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 `
` wrap? There can be `
` wrap added by `register_sidebar` or using `widget_text` filter" jasom Future Releases 11160 Inconsistancies in Naming and Using Sidebar Names and IDs. azaozz Widgets 2.9 normal normal defect (bug) new needs-unit-tests 2009-11-17T12:58:55Z 2019-06-05T06:37:18Z "register_sidebar() allows more sidebar names and IDs to be registered than dynamic_sidebar() recognizes as valid names and IDs. For example, register_sidebar() allows me to name a side bar ""1"" with a id of ""first"". I don't know why anyone would choose those values, but register_sidebar() allows it [1]. {{{ register_sidebar( array('name' => 1, id => 'first') ); }}} dynamic_sidebar() will not be able to find the sidebar given its name (1). {{{ if ( is_int($index) ) { $index = ""sidebar-$index""; /// 1 becomes 'sidebar-1' ... }}} The main problem is that dynamic_sidebar() is trying to process both IDs and names through the same variable ($index) while register_sidebar() separates the two with an array ( array('name' => 'Top', 'id' => 'sidebar-1' ). According to the in-line docs for dynamic_sidebar(): It is confusing for the $index parameter, but just know that it should just work. When you register the sidebar in the theme, you will use the same name for this function or ""Pay no heed to the man behind the curtain."" Just accept it as an oddity of WordPress sidebar register and display. It does ""just work"" if you never use your own sidebar IDs. I started looking at this because I wanted to use is_active_sidebar() which tests to see if a dynamic_sidebar() has anything in it. There is no get_dynamic_sidebar(). dynamic_sidebar() sends everything to the browser or returns false. {{{ register_sidebar( array('name' => 'Top') ); // id defaults to ""sidebar-1"" ... if ( is_active_sidebar('Top') ) dynamic_sidebar('Top'); }}} Which fails because is_active_sidebar() just completely skips over searching for an id to go with a name. To get it to work you need to know when it was registered. Not something theme authors and designers are going to follow easily. There's a ticket to fix this: [http://core.trac.wordpress.org/ticket/10440 #10440] {{{ if ( is_active_sidebar(1) ) dynamic_sidebar('Top'); }}} Like dynamic_sidebar(), is_active_sidebar() converts 1 to ""sidebar-1"". Unlike dynamic_sidebar() it assumes everything is entered as an id. unregister_sidebar() assumes its parameter (incorrectly named $name, not $id) is an id. But it wants a literal id, like ""sidebar-1"". unregister_sidebar(1) unregisters a sidebar with an id of 1, while dynamic_sidebar(1) tries to display a sidebar with an id of ""sidebar-1"". === Widgets (Admin Page) === The dynamic_sidebar() function is used by the Widgets management page. So, it is possible to create a sidebar with register_sidebar() that dynamic_sidebar() cannot find. You can populate it with drag and drop [2] and not have it appear on the web site. == After Patch == If committed, this patch would remove the need for tickets [http://core.trac.wordpress.org/ticket/10440 #10440] and [http://core.trac.wordpress.org/ticket/10956 #10956]. It changes the current argument behavior of unregister_sidebar(), but doesn't break backward compatibility. It allows is_active_sidebar(), unregister_sidebar() and dynamic_sidebar() all point to the same sidebar. === Before === These all refer to the same sidebar: {{{ is_active_sidebar(1); unregister_sidebar('sidebar-1'); dynamic_sidebar('Sidebar Top'); }}} In an admittedly contrived case, dynamic_sidebar() would silently fail to allow this sidebar to show: {{{ register_sidebar( array('name'=>'Sidebar Top', 'id' => 1) ); }}} === After === These all refer to the same sidebar (the first two would have broken before the patch): {{{ is_active_sidebar('Sidebar Top'); unregister_sidebar('Sidebar Top'); dynamic_sidebar('Sidebar Top'); }}} After the patch this shows fine: {{{ register_sidebar( array('name'=>'Sidebar Top', 'id' => 1) ); }}} After the patch it is possible to force an argument to be only a name or only an id: {{{ is_active_sidebar(array( 'name' => 'Sidebar Top' )); unregister_sidebar(array( 'name' => 'Sidebar Top' )); dynamic_sidebar(array( 'id' => 1 )); }}} === Notes === [1] register_sidebar() allows the user to override the default setting of: 'id' => ""sidebar-$i"", [2] When you refresh the Widgets management page the widgets will disappear from the sidebar. They are still attached to a sidebar, but dynamic_sidebar() cannot see the sidebar." CharlesClarkson Future Releases 23423 sanitize_title() in dynamic_sidebar() restricts the use of specific characters for sidebar IDs chriscct7 Widgets 2.2 normal normal defect (bug) reopened needs-unit-tests 2013-02-08T13:25:00Z 2019-06-05T06:39:05Z "In the dynamic_sidebar() function in wp-includes/widgets.php uses sanitize_title() on the given index when it looks for a sidebar with a name that matches the index. After that it leaves the index value sanitized making it impossible to use characters not allowed by sanitize_title() in a sidebar ID. By not overwriting the given index value with the sanitized version it would still be possible to use any character for the ID. To achieve this, lines 847-853 {{{ $index = sanitize_title($index); foreach ( (array) $wp_registered_sidebars as $key => $value ) { if ( sanitize_title($value['name']) == $index ) { $index = $key; break; } } }}} should be replaced with {{{ $sanitized_index = sanitize_title($index); foreach ( (array) $wp_registered_sidebars as $key => $value ) { if ( sanitize_title($value['name']) == $sanitized_index ) { $index = $key; break; } } }}}" paulvandermeijs Future Releases 33915 Add a filter in dynamic_sidebar() function to modify sidebar index Widgets 4.3 normal normal enhancement new needs-unit-tests 2015-09-17T15:04:28Z 2019-06-05T06:41:40Z Changing sidebars depending on the page/post/etc loaded through a plugin. Nothing too complex, just no way to do it. There is a filter dynamic_sidebar_params but that isn't called until later on in the function after the widgets have been collected for that sidebar. fahidjavid Future Releases 34093 New filter: `get_calendar_post_type` in get_calendar() Widgets normal normal enhancement new needs-unit-tests 2015-09-30T06:19:27Z 2023-05-17T05:47:36Z Filter for post type in calendar. If I want show posts from others post type sebastian.pisula Next Release 21533 Error suppression in wp-db is lame: Part 2 Warnings/Notices 3.4.1 normal normal 3.5 defect (bug) closed needs-unit-tests 2012-08-10T00:01:42Z 2012-08-14T20:34:12Z "Previously: #15402 This was fixed in [16321] however that was built upon [16320] and both were reverted in [16336] because it ""Breaks things"". What things it breaks I have no idea though (bad westi for not using a better commit message ;)). However I assume it was [16320] that broke things and not [16321]. [16321] seems perfectly valid to me and we should re-apply it along with a fix to `__get()` that throws a warning when `$result` isn't set yet." Viper007Bond Next Release 17670 Errors in get_page_by_path() Warnings/Notices 3.1 highest omg bbq blocker 3.3 defect (bug) closed needs-unit-tests 2011-06-03T03:48:30Z 2011-11-08T16:00:18Z "Example of accessing an Image through it's not post url: {{{ Expected url: /2008/06/10/post-format-test-gallery/canola2/ Accessed url: /canola2/ }}} get_page_by_path() will result in these 2 warnings: {{{ NOTICE: wp-includes\post.php:3167 - Trying to get property of non-object NOTICE: wp-includes\post.php:3162 - Trying to get property of non-object }}} Similar warnings are now emmited by trunk when accessing child pages as well" dd32 Next Release 33793 Adding a user with a username 52 characters or longer fails, but displays success message. boonebgorges Users 3.8.8 normal normal 4.4 defect (bug) closed needs-unit-tests 2015-09-09T16:31:11Z 2016-05-24T12:14:25Z "Steps to reproduce: 1. Login 2. Users -> Add New (/wp-admin/user-new.php) 3. Fill out the form with following data: '''Username:''' Any valid email with 52 characters or more, e.g. `abcdefghijklmnopqrstuvwxyzabcdefghijklmn [at] example.com` (without the email obfuscation). '''E-mail:''' ''Any'' '''Password:''' ''Any'' '''Repeat Password:''' ''Any'' 4. Submit form by 'Add New User' button. 5. WordPress redirects to Users page (/wp-admin/users.php?id=0) with a 'New user created.' success message, but the user is not visible in list, and is not present in `wp_users` table. If you repeat the steps specifying a username that is 51 characters or less, then the new user is created correctly, and the success message includes an 'Edit user' link. I've seen this broken behaviour in: * 4.3 * 4.2.1 * 3.9 * 3.8.8 In 3.8.7 adding a user with a username >51 characters (and >60 characters) creates a new user correctly. The username is truncated to the first 60 characters when necessary. (`wp_users.user_login` is a `varchar(60)`). I suspect the reason 51 characters succeeds and 52 does not may be to do with the `wp_users.user_nicename` field, which is a `varchar(50)`. The add new user operation auto generates the `user_nicename` value, as a sanitised form of the `user_login`, stripping the `@` in the process. I have not confirmed this though." tommarshall Next Release 44293 Discrepancy between documentation and implementation of wp_new_user_notification() pento Users 4.3 normal minor 5.1 defect (bug) closed needs-unit-tests 2018-06-01T21:32:59Z 2019-01-16T04:26:49Z "Based on the documentation, the options for recipients are 'admin', 'user', and 'both'. However, the way to send an email to both admin and user is actually to enter any arbitrary value for at least one of the two unnecessary parameters. `wp_new_user_notification($user_id)` or `wp_new_user_notification($user_id, null, 'admin')`sends only the admin email. `wp_new_user_notification($user_id, null, 'user')` sends only the user email. `wp_new_user_notification($user_id, null, 'anythingYouWant')` sends both. One of two things is happening here: 1. The function is more permissive than intended, allowing any value in the $notify parameter. Perhaps the function should actually check for 'both' instead of simply `return`ing if the two parameters are empty. OR 2. The documentation is making an unnecessary reference to the word 'both' where in reality, any string except 'admin' and 'user' will result in both emails being sent. Perhaps the documentation should be changed to suggest that acceptable values are 'admin', 'user' or literally any other string that returns false on the empty() test on line 1873 of wp-includes/pluggable.php." 360zen Next Release 53386 Multisite is_super_admin call during app password validation can lead to infinite loop TimothyBlynJacobs Users 5.6 normal normal 5.9 defect (bug) closed needs-unit-tests 2021-06-11T18:36:19Z 2021-11-15T03:16:35Z "In multisite, the following code sample leads to an infinite loop when validating an application password: {{{#!php user_can( $user, 'app_password_cap' ), 10, 2, ); }}} This is because, in multisite, the `user_can` call leads to an `is_super_admin` call, which in turn leads to a `wp_get_current_user` call which ultimately triggers `wp_is_application_passwords_available_for_user`… starting the whole process over again. (Worth noting that a very similar example to the above is included in the [https://make.wordpress.org/core/2020/11/05/application-passwords-integration-guide/ Application Passwords Integration Guide], so this use-case should be a supported one. For anyone who encounters this, a workaround is to remove your hook before you call `user_can`, and add it back after.)" chrisvanpatten Next Release 52605 Reset password email sent in wrong language desrosj Users 5.7 normal normal 5.7 defect (bug) closed needs-unit-tests 2021-02-22T17:35:36Z 2021-06-06T12:39:07Z "Testing the new WP 5.7 feature allowing admin to send a reset password link to users. https://make.wordpress.org/core/2021/02/22/send-reset-password-links-in-wordpress-5-7/ in 5.7-beta3-50398. On a fresh WordPress site, 1. Select Spanish as website language. 2. Assign French as language for the administrator. 3. Create a subscriber and select German for his/her language. 4. As admin, click on ""Send password reset"" (not yet translated) for the German subscriber in the users list. The email is sent in French (the language of the administrator). I expect it to be sent in German. If I assign the default site language to the German user, the email is still sent in French. I expect it to be sent in Spanish." Chouby Next Release 41453 Users with no role on a site on a multisite network see inaccessible links in the admin toolbar Users 3.0 normal normal 4.9 defect (bug) closed needs-unit-tests 2017-07-26T23:52:46Z 2017-10-23T18:34:13Z "Previously, for single site installations: #25162 A user who is a member of a site on a multisite network but has no role on the site will encounter mostly the same problems as those which were fixed for single site users in #25162: * An immediate ""You do not have sufficient permissions"" error upon logging in. * An admin toolbar link to `My Sites`, which they cannot access. * An admin toolbar link to their profile, which they cannot edit. * An admin toolbar submenu link to the `Dashboard` of their site, which they cannot access. * A link to the `Dashboard` from `My Sites`, which they cannot access (if they're a member of at least one site with a role)." johnbillion Next Release 37499 WP_User_Query:prepare_query() bug leads to user meta query with blog_id 0 Users 4.6 normal normal defect (bug) closed needs-unit-tests 2016-07-28T15:04:56Z 2016-07-29T13:56:53Z "In `WP_User_Query:prepare_query()`, one can find the following line, to ""Prevent extra meta query"" (SIC): {{{ $qv['blog_id'] = $blog_id = 0; }}} Setting the `blog_id` to `0` was, in previous versions of that code (from r32207), to make the code not proceed with further test cases afterward, as one can find `if ( $blog_id &&` peppered throughout this method. In 4.6, this method has changed (r37360) to have more processing after this `blog_id` reset happens, leading to a query being place with `AND blog_id = 0` instead of the intended proper `blog_id` that exists before that reset. Said query therefore becomes ""invalid"", since it will not return the expected blog users. In my experience, this happens at least when `wp_dropdown_users()` tries to get a list of the blog's users in the post/page edit screen. Both r32207 and r37360 by @boonebgorges :) Sample data lifespan (note how `blog_id` becomes `0`): {{{ get_users(): array ( 'blog_id' => '114310708', 'include' => '', 'exclude' => '', 'orderby' => 'display_name', 'order' => 'ASC', 'who' => 'authors', 'fields' => array ( 0 => 'ID', 1 => 'user_login', 2 => 'display_name', ), 'count_total' => false, ) User query construct: array ( 'blog_id' => '114310708', 'include' => '', 'exclude' => '', 'orderby' => 'display_name', 'order' => 'ASC', 'who' => 'authors', 'fields' => array ( 0 => 'ID', 1 => 'user_login', 2 => 'display_name', ), 'count_total' => false, ) Bad WP_User_Query attempt. Args: Array ( [blog_id] => 0 [role] => [role__in] => Array ( ) [role__not_in] => Array ( ) [meta_key] => [meta_value] => [meta_compare] => [include] => [exclude] => [search] => [search_columns] => Array ( ) [orderby] => display_name [order] => ASC [offset] => [number] => [paged] => 1 [count_total] => [fields] => Array ( [0] => ID [1] => user_login [2] => display_name ) [who] => authors [has_published_posts] => ) }}}" stephdau Next Release 14290 register_new_user() can't handle WP_Error result from wp_create_user() nacin Users 3.0 normal normal 3.7 defect (bug) closed needs-unit-tests 2010-07-12T21:29:42Z 2013-08-29T22:15:27Z "register_new_user() in wp-login.php does not properly handle a WP_Error object, which is the potential return value from its call to wp_create_user(). wp_create_user() is basically a pass-through to wp_insert_user(). As a result of [12778], the commit of a patch that was part of #11644 (the MU-merge ticket), new checks were added to wp_insert_user() which changed the potential behavior of the function to return a WP_Error object. register_new_user() can thus fail with a FATAL error: {{{ Notice: Object of class WP_Error could not be converted to int in /Users/scott/Sites/wp30.dev/wp-includes/functions.php on line 3150 Catchable fatal error: Object of class WP_Error could not be converted to string in /Users/scott/Sites/wp30.dev/wp-includes/formatting.php on line 2782 }}} Currently it is not likely the above situation would be tripped. But this is only because register_new_user() and wp_insert_user() perform almost identical error checks (the former does more, actually). However, the errors generated in register_new_user() can all be suppressed by plugins via the 'registration_errors' hook. However, some those same error checks will then be performed in wp_insert_user() and thus return a WP_Error (without a way to suppress those). Related issues aside, the fact of the matter is that wp_create_user() can return a WP_Error object and register_new_user() can't handle it. The fix is simple and attached. " coffee2code Next Release 26906 wp_user_update does not update custom user meta fields Users 3.8 normal normal defect (bug) closed needs-unit-tests 2014-01-22T08:39:37Z 2015-10-04T02:17:14Z "Version: 3.8 '''Problem explanation:''' according to user.php => wp_update_user() in line // Add additional custom fields, the loop did do the job and read the custom fields into the array and store in $userdata, however, when wp_insert_user($userdata) read the data and insert the data into DB, the custom fields are gone and not being saved '''Cause of the problem:''' in wp_insert_user() because final data are using $data = compact( 'user_pass', 'user_email', 'user_url', 'user_nicename', 'display_name', 'user_registered' ); and this method exclude all the custom fields other than default variables. '''Suggested solution:''' add a foreach to read all the key name from $userdata at the beginning of wp_user_data() when using compact using foreach and $$var to create the array for output '''Workaround or other solution:''' I think most people are doing this using update_user_meta() to accomplish the job but if there is many fields, this might not be very effective. " simongcc Next Release 39090 Remove duplicate query from posts page in the admin Users normal normal 6.3 enhancement closed needs-unit-tests 2016-12-05T20:33:19Z 2023-10-17T14:32:58Z "The posts page in the admin (`/wp-admin/edit.php`) is running twice the query below. This is a problem specially for sites with a significant number of users since this query can be super slow (see #19867 and #28160). {{{#!php SELECT wp_users.ID,wp_users.user_login,wp_users.display_name FROM wp_users INNER JOIN wp_usermeta ON ( wp_users.ID = wp_usermeta.user_id ) WHERE 1=1 AND ( ( wp_usermeta.meta_key = 'wp_user_level' AND wp_usermeta.meta_value != '0' ) ) ORDER BY display_name ASC }}} The query is executed by `WP_User_Query::query()` and, in this particular page, is called by the function `wp_dropdown_users()`. The attached patch fixes this problem by adding the result to the cache when the query is run the first time. Preventing multiple executions of the same query." rodrigosprimo Next Release 30064 WP_User_Query should support orderby => include boonebgorges Users normal normal 4.1 enhancement closed needs-unit-tests 2014-10-21T20:45:40Z 2014-10-24T19:50:54Z A la `orderby` => `post__in` danielbachhuber Next Release 24635 update_user_caches() should support accepting a WP_User instance Users 3.0 normal normal 4.4 enhancement closed needs-unit-tests 2013-06-24T08:19:53Z 2015-10-08T00:04:04Z "At present update_user_caches($user) blindly stores the value from $user into the object cache. Although core only ever passes the raw data from `wp_users` into this function, due to the naming of it, and the phpdoc, plugin devs may pass a WP_User instance to the function. The result is that a WP_User instance is stored within the object cache rather than stdClass of a `wp_users` row as expected. For most intents this causes little issue, the function and cache still work, so the developer will see no side effects. But this has the cause that when that user's data is retrieved from the cache, the original WP_User object is restored -- including all meta keys that were stored in it, If one of those meta keys is a serialized object which calls a not-yet-loaded function, it can cause the request to fatal error. It's a pretty specific issue, but can simply be avoided by never storing a WP_User instance in the cache. Attached patch simply tests for the data and acts appropriately. mostly untested." dd32 Next Release 36009 "wp_new_user_notification ""user"" option for third parameter" SergeyBiryukov Users 4.4.2 normal normal 4.6 enhancement closed needs-unit-tests 2016-02-29T12:39:05Z 2018-09-14T13:08:35Z "I propose adding a third option for the third parameter {{{$notify}}} in {{{wp_new_user_notification()}}} called ""user"" (string) which would allow for sending the notification to the user only. Many user-driven sites have the need for sending this email to new users but would rather not flood an admin email with registration notifications. I don't think this only flaw is enough to justify plugging the function with a custom one. It'd be much preferred to allow for this third option in the core function instead." Jonathandejong Future Releases 60299 Default assignment of `use_ssl` user meta value causes unnecessary DB write. Users normal normal 6.6 defect (bug) new needs-unit-tests 2024-01-19T15:14:18Z 2024-02-19T17:35:21Z "When the `$meta` in `wp_insert_user()` is processed using `update_metadata()` it first does a comparison against the current values in the database prior to running an update query. However, because the DB returns a string value ('1' or '0') while the meta_value is set to a boolean value by default the comparison always fails causing a write when not needed. While this is relatively minor in itself, in multi-datacenter setups using hyperdb, this can cause a bit of overhead since all future reads to the usermeta table are then sent to the master database." prettyboymp Future Releases 16293 In multisite installs, users with id 1 can't be deleted Users normal normal Future Release defect (bug) reopened needs-unit-tests 2011-01-19T00:21:34Z 2024-02-08T20:18:09Z "You can't delete a user with user id of 1. See: source:trunk/wp-admin/network/edit.php@17326#L359" PeteMall Future Releases 40477 REST API: Does NOT Trigger New User Notifications! Users 4.7 normal normal Awaiting Review defect (bug) new needs-unit-tests 2017-04-19T07:35:19Z 2017-12-04T05:11:43Z "If you create new users with WP REST API. The notification for new WordPress users via email does NOT get triggered. I tried it on a fresh install. Used the [Email log](https://wordpress.org/plugins/email-log/) WP plugin to test that no emails were sent. " mrahmadawais Future Releases 50072 Users with email addresses containing a single quote cannot reset their passwords Users 5.4 normal major Awaiting Review defect (bug) new needs-unit-tests 2020-05-04T09:28:31Z 2020-05-05T11:27:55Z "I just found that users with a single quote in their email addresses cannot reset their passwords. This happens because there is a difference in the email addresses compared by the wp_insert_user() function. Take a look at this example. I have a user with an email address equal to **daniel.o'brian@gmail.com** When he tries to reset his password, he receives the reset key, but his activation key is not stored in the database. Looking at lines 1805-1808 of the file users.php I found the problem: {{{ if ( $update ) { if ( $user_email !== $old_user_data->user_email || $user_pass !== $old_user_data->user_pass ) { $data['user_activation_key'] = ''; } }}} In the above code the variable $user_email is **daniel.o'brian@gmail.com**, but the $old_user_data->user_email is escaped and appears to be **daniel.o\'brian@gmail.com**, so there isn't the match and user activation key is cleared. Can you confirm and provide a fix? In the meantime, I can change this behavior by escaping the $user_email myself in the filter wp_pre_insert_user_data which is a few lines above the checking, I guess. Thanks!" daniele.perilli Future Releases 38851 WP_User_Query cannot retrieve multisite users who have not been assigned a role on a site Users normal normal Future Release defect (bug) new needs-unit-tests 2016-11-18T15:11:32Z 2017-12-01T05:20:30Z "If you add a user to a multisite at network level, but do not proceed to assign them a role on a site within the network, `WP_User_Query` cannot retrieve those users (even if the query is run at network level), as they have no associated `wp_capabilities` meta_key. To reproduce the problem: 1) Add a user to a multisite via Network Admin > Users > Add New. 2) Run a WP_User_Query at network level (e.g. by doing something like: {{{ add_action('load-users.php', 'myAction'); function myAction() { $screen = get_current_screen(); if( $screen->base === 'users-network' { $query = new WP_User_Query(); $users = $query->results; } } }}} The returned results will not include the user added in step 1. In fact, it will only return users who have capabilities set on the first site in the network, even though this query is not occurring at site level. This could be fixed by allowing something like `'blog_id' => 'all'` in a `WP_User_Query`." robdxw Future Releases 54310 WP_User_Query does not return results in the same format if fields set to all_with_meta and doesn't return any metadata Users normal normal Awaiting Review defect (bug) new needs-unit-tests 2021-10-22T17:54:26Z 2021-10-25T23:32:25Z "Digging into WP_User_Query if you set the fields to all_with_meta it returns an array index by the user_ID veers a keyed list for all other results this is the {{{ if ( 'all_with_meta' === $qv['fields'] ) { cache_users( $this->results ); $r = array(); foreach ( $this->results as $userid ) { $r[ $userid ] = new WP_User( $userid, '', $qv['blog_id'] ); } $this->results = $r; } elseif ( 'all' === $qv['fields'] ) { foreach ( $this->results as $key => $user ) { $this->results[ $key ] = new WP_User( $user, '', $qv['blog_id'] ); } } }}} I feel we should return the same shape array for both so propose to set the all to array index to the User_ID's with a change like this {{{ if ( 'all_with_meta' === $qv['fields'] ) { cache_users( $this->results ); $r = array(); foreach ( $this->results as $userid ) { $r[ $userid ] = new WP_User( $userid, '', $qv['blog_id'] ); } $this->results = $r; } elseif ( 'all' === $qv['fields'] ) { foreach ( $this->results as $user ) { $this->results[ $user->ID ] = new WP_User( $user, '', $qv['blog_id'] ); } } }}} And better still it doesn't return the meta values !!! So let's add this as well {{{ if ( 'all_with_meta' === $qv['fields'] ) { cache_users( $this->results ); $r = array(); foreach ( $this->results as $userid ) { $r[ $userid ] = new WP_User( $userid, '', $qv['blog_id'] ); $r[ $userid ]->meta = get_user_meta( $userid ); } $this->results = $r; } elseif ( 'all' === $qv['fields'] ) { foreach ( $this->results as $key => $user ) { $this->results[ $key ] = new WP_User( $user, '', $qv['blog_id'] ); } } }}} " pbearne Future Releases 37454 get_avatar_data() delivers different url for scheme=https and is_ssl() Users 4.3 normal normal Awaiting Review defect (bug) new needs-unit-tests 2016-07-25T08:09:46Z 2017-02-15T07:56:44Z "get_avatar_data() has an option to set the scheme. If https is used, an image URL is returned which is different to the one which is returned in case delivery is conducted via https without the scheme parameter. I think it would be better to serve the same gravatar url for https pages and explicit https-scheme requests. Regarding performance and depending on the infrastructure, it could also be benefical to drop https://%d.gravatar.com completely and serve all requests to gravatar independent of the page's protocol via https://secure.gravatar.com/ to benefit from HTTP/2 (http and https://%d.gravatar.com requests are served via HTTP/1.1 whereas https://secure.gravatar.com/ allows multiplexing via HTTP/2)." neoxx Future Releases 39370 wp_insert_user() appends suffix to nicename when updating already existing user Users 4.6.1 normal normal Future Release defect (bug) new needs-unit-tests 2016-12-22T14:11:21Z 2020-03-12T02:58:27Z "wp_insert_user() appends suffix to nicename when updating already existing user, even though the user_nicename prop is set to exactly the same value as it currently has. Steps to reproduce: - Asuming you have a user in your wordpress database with the ID 1 and user_nicename set to 'test-nicename'. - If you then make an update using wp_insert_user() of that user and in the update set the user_nicename to 'test-nicename', then wordpress will update the user, but append -2 as a suffix to the nicename. This happens because of a check located on line 1597 - 1609 in wp-includes/user.php {{{#!php get_var( $wpdb->prepare(""SELECT ID FROM $wpdb->users WHERE user_nicename = %s AND user_login != %s LIMIT 1"" , $user_nicename, $user_login)); if ( $user_nicename_check) { $suffix = 2; while ($user_nicename_check) { // user_nicename allows 50 chars. Subtract one for a hyphen, plus the length of the suffix. $base_length = 49 - mb_strlen( $suffix ); $alt_user_nicename = mb_substr( $user_nicename, 0, $base_length ) . ""-$suffix""; $user_nicename_check = $wpdb->get_var( $wpdb->prepare(""SELECT ID FROM $wpdb->users WHERE user_nicename = %s AND user_login != %s LIMIT 1"" , $alt_user_nicename, $user_login)); $suffix++; } $user_nicename = $alt_user_nicename; } }}} This code is there to make sure that there are no duplicate nicenames in the wp_users table, which is fine. However it does not take into account updating the nicename of a user with the same value as it currently has. The way to solve it is very easy, only simply changes the if() statement to check the id fethced in $user_nicename_check against the ID of the user currently being updated, like so: {{{#!php get_var( $wpdb->prepare(""SELECT ID FROM $wpdb->users WHERE user_nicename = %s AND user_login != %s LIMIT 1"" , $user_nicename, $user_login)); if ( $user_nicename_check && $ID != $user_nicename_check) { $suffix = 2; while ($user_nicename_check) { // user_nicename allows 50 chars. Subtract one for a hyphen, plus the length of the suffix. $base_length = 49 - mb_strlen( $suffix ); $alt_user_nicename = mb_substr( $user_nicename, 0, $base_length ) . ""-$suffix""; $user_nicename_check = $wpdb->get_var( $wpdb->prepare(""SELECT ID FROM $wpdb->users WHERE user_nicename = %s AND user_login != %s LIMIT 1"" , $alt_user_nicename, $user_login)); $suffix++; } $user_nicename = $alt_user_nicename; } }}} This makes prevents the code from appending the suffix when the $user_nicename_check ID matches the ID of the user currently being updated " alfhen Future Releases 42183 wp_update_user() conditional compares a plain-text password to the hashed old SergeyBiryukov Users 4.5.2 normal normal Future Release defect (bug) reviewing needs-unit-tests 2017-10-11T14:20:02Z 2019-01-16T03:25:00Z "In file wp-includes/user.php, function [https://developer.wordpress.org/reference/functions/wp_update_user/ wp_update_user()] On line 1767: {{{ if ( ! empty( $userdata['user_pass'] ) && $userdata['user_pass'] !== $user_obj->user_pass) }}} The second conditional is comparing a plain-text password to a hashed version of password, so this would almost always evaluate to true except for the case where the new password itself matches the old hashed password. This block will then evaluate to false and therefore password itself won't be updated. It's a rare case but the logic here is incorrect. And obviously this code block would run when passwords are the same since it's comparing plain-text to the hashed version." yudge Future Releases 39242 Add caching to count_user_posts() whyisjake* Users 3.0 normal normal Future Release enhancement accepted needs-unit-tests 2016-12-11T23:24:32Z 2023-01-17T18:46:29Z "The `count_user_posts()` function does not cache the results of its query. On the surface, this seems easy enough, but since it accepts multiple parameters and intersects with page/post editing, it starts to get complex quickly as authors change, posts are transitioned from public to private, and custom post types do more elaborate things. Since some themes use this directly (Twenty Fourteen, et al) and the REST API exposes this data too, there's at least a small win from not hitting the database for each and every check. Eventually, `count_many_users_posts()` may be able to check for cached counts for existing users, and only query for (and prime the caches of) users who do not already have cached counts." johnjamesjacoby Future Releases 42326 Allow for user deletion in multisite Users 3.0 normal normal Awaiting Review enhancement new needs-unit-tests 2017-10-24T18:30:56Z 2017-10-24T21:19:24Z When multisite is enabled, it is impossible to completely delete user a user. A user is only removed from a site. However, if a user is has no sites on the network, then it should be safe to remove them. spacedmonkey Future Releases 39123 Allow usernames to be changed by administrators Users normal normal Awaiting Review enhancement new needs-unit-tests 2016-12-06T21:25:53Z 2017-11-21T17:13:11Z "Usernames cannot be changed. I'd like to propose that users who have the `edit_users` capability (administrators on single site installations, and super admins on multisite installations) are given the ability to update a user's username from their profile editing screen. The historical reason for disallowing changes to usernames is not clear, but it's most likely related to the generation of the `user_nicename` field which ideally needs to remain persistent so author archives don't 404. However, this can be addressed in the same way as changes to post slugs, where a user's old usernames and nicenames are recorded in usermeta when their username is updated (and their nicename is regenerated) and a canonical redirect can kick in to redirect to the new author archive URL. Any other considerations to make if usernames are allowed to be changed by administrators?" johnbillion Future Releases 34316 User status inconsistent between single-site & multisite Users 1.5 normal normal Awaiting Review enhancement new needs-unit-tests 2015-10-15T19:00:15Z 2017-09-27T15:30:10Z "The way a user's status is defined in WordPress differs between single-site and multisite: * In single-site, the `user_status` column is used * In multisite, there are two additional columns for `spam` and `deleted` Not only this, but the `update_user_status()` function is multisite only, and the `user_status` column is an integer without an API to help announce what values equate to what results. On the plus side, user statuses aren't really ever used in core. Marking users as spammers in multisite installations is the only real benefit of this feature as it exists today. I'd like to propose the following: * Stop creating the the `spam` and `deleted` columns in `wp_users` on new installations * ALTER the `user_status` column from `INT(11)` to `VARCHAR(20)` ala `wp_posts` * A bevy of `wp_register_user_status()` like functions to introduce bonafide support for them * A database upgrade routine to move user status `0` to `active` and `1` to `spammer` * A new index on the `wp_users` table for the updated `user_status` column type. We may need a few, based on how users are commonly queried in core, BuddyPress, etc... * Update the `WP_User` and `WP_User_Query` classes to suss out any `user_status` inconsistencies A few considerations worth noting: * Large installations would need to manually perform these DB upgrades. I'm embarrassed to say I've personally frozen WordPress.org for several minutes years ago by missing a `DO_NOT_UPGRADE_GLOBAL_TABLES` check on the `wp_users` table * Several plugins use their own values in the `users_status` column, assuming their numeric ID is unique and special. The authors of these plugins would need notifying, and their code updating to support the above ideas * This work *could* parlay into the Post Status API that's on infinite back-burner. There are some really excellent ideas floating around about how `post_status` could work that would translate nicely to users, too" johnjamesjacoby Future Releases 44347 WP allows creating username that is already used email address Users normal normal Awaiting Review enhancement new needs-unit-tests 2018-06-10T22:43:02Z 2019-03-02T02:03:26Z "As reported in Support Forum (https://wordpress.org/support/topic/wp-allows-creating-username-that-is-already-used-email-address/) it seems I can create a user with wp_create_user where the user's ""username"" is set as a value that is an existing Email Address for another user in the WordPress system. (I have not submitted a bug here before, so let me know if more info is needed on this and what to do next)." phillipburger Future Releases 31772 Browser unresponsive with long password Users 3.7 normal normal defect (bug) new needs-unit-tests 2015-03-26T00:47:25Z 2019-06-05T06:40:45Z "== Steps to reproduce 1. Login 1. Navigate to profile 1. Click in the text input for ""New Password"" 1. Paste in a long password * E.g. 600 characters: {{{ 123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890 }}} 1. Press the ""tab"" key - **Expected behaviour**: - The cursor moves to the ""Repeat New Password"" field. - ""Strength indicator"" changes to ""Strong"" or ""Weak"" (probably should be ""weak""). - **Actual behaviour**: - The cursor does not move. - The cursor stops blinking. - ""Strength indicator"" does not change. - The browser is not responsive. - After several seconds or a minute, the cursor eventually starts blinking, moves to the ""Repeat New Password"" field and the strength indicator changes to ""Strong"" (probably should be ""weak""). 1. Press the ""shift+tab"" keys - **Expected behaviour**: The focus moves to the ""New Password"" field and its content is selected. - **Actual behaviour**: - The cursor does not move. - The cursor stops blinking. - The browser is not responsive. - After several seconds or a minute, the focus eventually moves to the ""New Password"" field and the content is selected. 1. Press the delete/backspace key - As expected, the password is deleted and the browser is immediately responsive. My testing was as an administrator using Chrome on Mac OS X. I think this issue applies to any role and any browser on any OS. I expect the delay is longer with slower hardware. == Solutions == Certainly the strength checker need not run on `focus` events. It should only be necessary on `change`. It could also run after a short timeout (~500 ms) if no other `change` event has occured, so that it only runs when the user stops typing. An elaborate solution might be to make the password strength checking code more efficient. Or only run it on the first N characters. Or alternatively, seek a third party library that checks password strengths more performantly. A simple solution could be to set the `maxlength=""""` attribute on password ``s. Rough testing on Chrome on an 18-month old MacBook Air suggests The limit would probably need to be less than about 64-256 in order to keep the browser responsive (without modifying the unperformant code). The disadvantage of this approach is that long passwords can not be input by the keyboard, or will be truncated if pasted in. This might be an issue for users that use password managing software like OnePassword. We would need to investigate how long the passwords generated by such software is. For reference and comparison; - The server-side limit is currently 4096: https://github.com/WordPress/WordPress/blob/master/wp-includes/class-phpass.php#L217 - If a password is set that is longer than 4096 characters, WP silently fails to save the password." BevanR Future Releases 31127 Can't add a new user to two sites before they've accepted their account jeremyfelt Users 3.0 normal normal defect (bug) assigned needs-unit-tests 2015-01-25T18:57:47Z 2019-06-05T06:40:34Z "In multisite, when adding a new user to a site, the user account isn't created immediately. Their info is stored in the `wp_signups` table until the user checks their email and clicks their sign-up acceptance link. If an admin attempts to invite the user to a second site before the person has accepted their user account for the first, they'll get this message: > That username is currently reserved but may be available in a couple of days. > That email address has already been used. Please check your inbox for an activation email. It will become available in a couple of days if you do nothing." ericlewis Future Releases 15001 Duplication and incompatibilities in register_new_user() and wp_insert_user() Users 3.0 normal normal defect (bug) new needs-unit-tests 2010-09-30T19:16:11Z 2019-06-05T06:37:31Z "As a result of [12778], the commit of a patch that was part of #11644 (the MU-merge ticket), `wp_insert_user()` was modified to introduce user verification checks. The addition of these checks also introduced a number of duplications and incompatibilities between it and `register_new_user()`. (Bear in mind that `register_new_user()` calls `wp_create_user()` which calls `wp_insert_user()`.) These issues include: * Duplication (both run-time execution and code): both functions perform `username_exists()` and `email_exists()` checks. Ideally, we should only perform each check once, and from a single piece of code. * Whereas both functions perform `username_exists()` and `email_exists()` checks, `register_new_user()` performs more checks (empty_username, invalid_username, empty_email, invalid_email). If the former 2 are being checked, all 6 criteria should be checked. * `wp_insert_user()` can now return a WP_Error object, but `register_new_user()` can't handle it (I reported this in #14290) * `register_new_user()` generates a new generic error if `wp_create_user()` (via `wp_insert_user()`) returns an error (assuming proper patch #14290), rather than passing along the more specific error it was told about If an error is returned by `wp_create_user()`, `register_new_user()` throws a generic 'registerfail' error (`'ERROR: Couldn’t register you... please contact the webmaster !'`). However, most likely it received a more informative WP_Error object. * `register_new_user()` allows errors to be suppressed via filters, but `wp_insert_user()` does not `register_new_user()` has the filter 'registration_errors' which allows plugins to suppress any encountered errors. Having done so, `register_new_users()`'s subsequent call to `wp_create_user()` can generate an error (of the type already suppressed) which is then un-suppressable. This renders the 'registration_errors' filter useless for the username_exists and email_exists errors (and possibly other in the future). ---- These different issues may warrant separate tickets, but cumulatively I think they point to the need to refactor `register_new_user()` and `wp_insert_user()` to be more efficient and compatible. This is a rare instance where I don't include an immediate patch for a ticket, but I wanted to get it out there and see if we can try and get these fixed for 3.1. " coffee2code Future Releases 41673 Abstract update capability logic into a meta capability Users 4.9 normal normal enhancement closed needs-unit-tests 2017-08-19T12:50:14Z 2020-12-11T00:56:06Z "From [comment:4:ticket:41538] There are three places in core now which use logic to determine whether a user has any one of the `update_*` capabilities. This should be abstracted into a meta capability such as `manage_updates`." johnbillion Future Releases 18791 Add custom post type support for Author Template functions Users 3.2.1 normal normal enhancement new needs-unit-tests 2011-09-27T12:32:48Z 2019-06-05T06:38:28Z "Functions defined in `wp-includes/author-template.php` assumes that post type == post. It will be good to enhance them so they will be able to work with specified post type. At first sight following functions will need update: {{{ get_the_author_link() the_author_link() get_the_author_posts() the_author_posts() the_author_posts_link() get_author_posts_url() wp_list_authors() }}} I suspect there will be other updates needed, to support new `post_type` argument added to author's url." sirzooro Future Releases 21730 More modular and reusable email validation functions Users normal normal enhancement new needs-unit-tests 2012-08-29T16:04:04Z 2019-06-05T06:38:46Z "Email validation, especially as it's handled in Multisite (most of which is verbatim from MU), is pretty messy. We have some functions like `is_email_address_unsafe()` for checking banned domains, but we don't have a parallel function for checking against limited_email_domains. There are no filters outside of `wpmu_validate_user_signup`, which means that if you want to use email validation outside of the normal MS registration workflow and want to tweak the way that it works (see eg #15706, #20459), you pretty much have to roll your own. And there's no single function that a plugin like BuddyPress can use to do all relevant email checks in one fell swoop. The attached patch suggests the following changes: - Put the limited_email_domains check into a function, `is_email_address_allowed()`. - Put filters on the output of this new function as well as `is_email_address_unsafe()`. - Introduce function wp_validate_email_address(), which wraps the following four checks: is_email(), email_exists(), is_email_address_allowed(), is_email_address_unsafe(). - Rearranges `wpmu_validate_user_signup()` a bit so that all email checks (as opposed to username checks) happen together. I'm not married to anything in this particular implementation (the way that wp_validate_email_address() sends back error messages is not particularly beautiful, but I didn't want to introduce a ton of overhead), but I would really like to see some sort of treatment along these lines, to make things more modular and reusable. If something like this gets approved by the devs, I would like to further suggest the following: - Give a similar treatment to username validation - Move the generic validation functions out of ms-functions.php (with function_exists() checks on the MS-specific stuff) I'm happy to work more on this kind of patch, but didn't want to go too far in case it's a non-starter for some reason." boonebgorges Future Releases 32796 User deletion API is inconsistent between MS and non-MS Users normal normal enhancement new needs-unit-tests 2015-06-26T12:56:44Z 2019-06-05T06:41:04Z "On non-multisite, `wp_delete_user( $u )` does what you'd expect: it deletes user `$u` from the database. On multisite, the same function basically wraps `remove_user_from_blog()`; if you want to delete a user from the database altogether, you've got to use `wpmu_delete_user()`. I understand the historical reasons behind the divergence, but it's pretty lame from a developer's point of view to have to check `is_multisite()` before removing a user from the database. There's a note in the docblock for `wpmu_delete_user()` that says ` * @todo Merge with wp_delete_user() ?`. Maybe we could actually make this happen? " boonebgorges Next Release 39552 SVG upload support broken in 4.7.1 joemcgill Upload 4.8 normal normal 4.7.3 defect (bug) closed needs-unit-tests 2017-01-12T01:08:50Z 2017-02-27T19:27:58Z "The added function wp_get_image_mime {{{#!php query` the query is rewritten to its temporary counterpart `DROP TEMPORARY TABLE`. http://core.trac.wordpress.org/browser/tests/trunk/includes/testcase.php#L55 However, all `CREATE TABLE` queries are not rewritten to `CREATE TEMPORARY TABLE`, so when the time comes the database shoves an error into the face of anyone who's trying to drop a table. This is currently only relevant to custom tests extending from the `WP_UnitTestCase` class." soulseekah Next Release 24974 Deprecated use of assignment by reference in testcase.php Unit Tests normal normal 3.7 defect (bug) closed 2013-08-06T20:43:39Z 2013-08-08T09:32:09Z ">As of PHP 5, the new operator returns a reference automatically, so assigning the result of new by reference results in an E_DEPRECATED message in PHP 5.3 and later, and an E_STRICT message in earlier versions. (From [http://php.net/manual/en/language.operators.assignment.php#example-115 the PHP docs]) There are two instances of this in [http://core.trac.wordpress.org/browser/tests/trunk/includes/testcase.php#L132 /includes/testcase.php]. Since WordPress requires at least PHP 5.2, I assume that the unit tests do also." jdgrimes Next Release 26867 Explicitly globalize some missing query globals in wp-settings.php nbachiyski Unit Tests normal normal 3.9 defect (bug) closed 2014-01-18T03:43:47Z 2014-01-22T14:47:59Z "When WordPress is loaded in a function (e.g. unit tests) the variables initialized at the top level aren't globals, but we expect them to be. For example, if in a unit test there is no way to access $wp_query, either directly or via `get_query_var()` before some other part of the code has initialized it. This happens especially when we are testing a plugin and it uses `$wp_query` in its initialization routine." nbachiyski Next Release 23685 Explicitly globalize version variables wonderboymusic Unit Tests 3.6 normal normal 3.8 defect (bug) closed 2013-03-04T11:00:09Z 2013-11-05T00:57:53Z "When WordPress is loaded in a function (e.g. unit tests) the variables initialized at the top level aren't globals, but we expect them to be. For example, if in a unit test there is no way to access `$wp_version`. Neither via `$wp_version` (it's not in the same scope), not via `$GLOBALS['wp_version']` (it's not a global). To fix that we need to explicitly make the version variables global. See #17749." nbachiyski Next Release 26344 Failure in Tests_Basic::test_readme() SergeyBiryukov Unit Tests normal normal 3.8 defect (bug) closed 2013-12-01T00:25:28Z 2013-12-01T00:26:07Z "{{{ 1) Tests_Basic::test_readme readme.html's version needs to be updated to 3.8. Failed asserting that two strings are equal. --- Expected +++ Actual @@ @@ -'3.8' +'3.8 +' }}}" SergeyBiryukov Next Release 26345 Failure in Tests_Post_Query::test_meta_query_decimal_results() SergeyBiryukov Unit Tests normal normal 3.8 defect (bug) closed 2013-12-01T00:41:43Z 2013-12-01T00:42:40Z "The test sometimes fails due to different order of items in the array: {{{ 1) Tests_Post_Query::test_meta_query_decimal_results Failed asserting that two arrays are equal. --- Expected +++ Actual @@ @@ Array ( - 0 => 3 - 1 => 4 - 2 => 5 + 0 => 5 + 1 => 3 + 2 => 4 ) }}} Since we don't specify an order there, `assertEqualSets()` should be used instead of direct array comparison." SergeyBiryukov Next Release 19456 Globalize $wp_rewrite in wp-settings.php Unit Tests 1.5 normal normal 3.4 defect (bug) closed 2011-12-06T10:54:23Z 2011-12-20T21:14:20Z See #17749, [attachment:globalise_wp_rewrite.diff:ticket:17749] from mtorrent. nacin Next Release 25133 Incorrect instructions in tests/README.txt SergeyBiryukov Unit Tests normal normal 3.7 defect (bug) closed 2013-08-24T13:54:07Z 2013-08-31T13:42:57Z "The fourth step in the `README.txt` file included with the tests says the following: > 4. Run the tests from the ""trunk"" directory: But this won't work. The `phpunit.xml.dist` file is in the `/trunk/tests/` directory, so the tests need to be run from there. I am attaching a patch which addresses this by changing these instructions to say: > 4. Run the tests from the ""trunk/tests"" directory:" jdgrimes Next Release 26091 Infinite loop in WP_FIlesystem_MockFS->mkdir() SergeyBiryukov Unit Tests 3.7 normal major 3.8 defect (bug) closed 2013-11-17T20:27:24Z 2013-11-18T15:40:52Z "When running the unit tests under Windows/WampServer with command `phpunit` (no parameters): `Fatal error: Maximum function nesting level of '100' reached, aborting! in C:\wamp\www\wordpress-svn\src\wp-includes\formatting.php on line 1413` The error stops the tests. The PhpUnit output seems to point to an infinite loop in this code: {{{ function mkdir( $path, /* Optional args are ignored */ $chmod = false, $chown = false, $chgrp = false ) { $path = trailingslashit( $path ); $parent_node = $this->locate_parent_node( $path ); if ( ! $parent_node ) { $this->mkdir( dirname( $path ) ); [...] }}}" p_enrique Next Release 25913 Investigate why we skip so many Unit Tests Unit Tests 3.8 normal normal defect (bug) closed 2013-11-11T17:54:43Z 2014-01-27T03:18:06Z My hunch as that we shouldn't be skipping so many tests. I am creating this ticket as a stake to point commits and comments (if necessary). wonderboymusic Next Release 25242 Provide correct multisite test information in bootstrap.php nacin Unit Tests normal normal 3.7 defect (bug) closed 2013-09-06T17:40:31Z 2013-09-12T21:04:16Z "`tests/phpunit/includes/bootstrap.php` current provides instructions to use `phpunit -c multisite.xml` to run multisite unit tests. As of [25156], things were modified quite a bit and this no longer works. Patch accounts for the new location of `multisite.xml` and the `WP_TESTS_MULTISITE` constant." jeremyfelt Next Release 21115 Remove ancient wp-settings.php global unsetting code nacin Unit Tests normal normal 3.5 defect (bug) closed 2012-06-29T20:56:09Z 2012-06-29T20:57:10Z "We have this: {{{ // Ensure these global variables do not exist so they do not interfere with WordPress. unset( $wp_filter, $cache_lastcommentmodified ); }}} It used to include more variables, but they were removed when a few of us took an axe to wp-settings.php back in 3.0. I suggest we remove both. $cache_lastcommentmodified can easily become a static variable within that function (I mean, we're dealing with pre-1.5 code here) and a lot of things would be broken if people overrode WordPress globals prior to startup, not just $wp_filter." nacin Next Release 13407 Test-Suite: Allow wp-test multiple classes and exclusion of westi Unit Tests 3.0 normal normal defect (bug) closed 2010-05-16T01:43:09Z 2010-05-29T17:21:26Z "Improvement to the -t commandline switch. Examples: Run all tests but TestLargeThemeDir, TestImportWP, TestWPQueryPosts, WPTestGalleryPost {{{ $ wp-test -t ""! TestLargeThemeDir, TestImportWP, TestWPQueryPosts, WPTestGalleryPost"" }}} Only run Test_Clean_Pre and Test_Seems_UTF8 {{{ $ wp-test -t Test_Clean_Pre,Test_Seems_UTF8 }}} Additionally a .cmd file helps to start right away on windows. Related: #12277, #11867" hakre Next Release 12277 Test-Suite: Cross-Plattform portability: No Color Codes in Windows Shell westi Unit Tests normal normal defect (bug) closed 2010-02-18T19:04:08Z 2012-11-25T08:56:05Z "The Windows Shell does not provide any colors. Well to be more precise it does support colors but not the way {{{PHPUnit_TextUI_ResultPrinter}}} handles them. A fix is to not output color-codes on windows." hakre Next Release 11892 Test-Suite: make wp_die() a pluggable function westi Unit Tests 3.0 normal blocker 3.0 defect (bug) closed 2010-01-14T00:51:10Z 2010-05-18T10:27:17Z "There are multiple occurences of the die() (and perhaps exit()) statement within the code. Those can be a blocker in running the testsuite. I suggest to replace those with a call to a new function called wp_exit(); which is plugable so that the testsuite can replace it. Otherwise it's not possible to test code containing those statements. At least I'm not aware of a method to do so." hakre Next Release 26155 Tests_Image_Functions failures SergeyBiryukov Unit Tests normal normal 3.8 defect (bug) closed 2013-11-22T03:05:16Z 2013-12-05T23:36:51Z "Three image tests are failing if both fileinfo PHP extension and `mime_content_type()` function are missing: {{{ 1) Tests_Image_Functions::test_wp_save_image_file Failed asserting that two strings are equal. --- Expected +++ Actual @@ @@ -'image/jpeg' +'' S:\home\wordpress\develop\tests\phpunit\tests\image\functions.php:142 S:\usr\local\php5\phpunit:46 2) Tests_Image_Functions::test_mime_overrides_filename Failed asserting that two strings are equal. --- Expected +++ Actual @@ @@ -'image/gif' +'' S:\home\wordpress\develop\tests\phpunit\tests\image\functions.php:180 S:\usr\local\php5\phpunit:46 3) Tests_Image_Functions::test_inferred_mime_types Failed asserting that two strings are equal. --- Expected +++ Actual @@ @@ -'image/jpeg' +'' S:\home\wordpress\develop\tests\phpunit\tests\image\functions.php:225 }}} We should skip these tests if the extension is not loaded, like we do in Tests_Image_Meta: [source:tags/3.7.1/tests/phpunit/tests/image/meta.php#L8]." SergeyBiryukov Next Release 26219 Tests_Post_Revisions::test_revision_dont_save_revision_if_unchanged unit test fails Unit Tests normal normal defect (bug) closed 2013-11-24T18:23:05Z 2013-11-24T18:32:10Z "This unit test is failing: 1) Tests_Post_Revisions::test_revision_dont_save_revision_if_unchanged Failed asserting that actual size 4 matches expected size 3. in tests/phpunit/tests/post/revisions.php:83 I've traced the problem down to wp-includes/revision.php line 95: {{{ if ( $revisions = wp_get_post_revisions( $post_id ) ) { // grab the last revision, but not an autosave foreach ( $revisions as $revision ) { if ( false !== strpos( $revision->post_name, ""{$revision->post_parent}-revision"" ) ) { $last_revision = $revision; break; } } }}} When creating the revisions programmatically it seems $last_revision is not fetched correctly. Since revisions are ordered I wonder if we could replace this code by one where we just grab the last revision out of the revisions array directly." nunomorgadinho Next Release 25633 Tests_XMLRPC_wp_getPosts::test_filters failing Unit Tests normal minor 3.8 defect (bug) closed 2013-10-18T21:54:52Z 2013-11-16T19:11:48Z "I get the following error when running the tests: {{{ 1) Tests_XMLRPC_wp_getPosts::test_filters Failed asserting that 11 matches expected 0. /Users/atimmer/Sites/wp-core/tests/phpunit/tests/xmlrpc/wp/getPosts.php:89 }}} It fails because it loops through the posts and returns posts by offset. Because it sorts by post_date and the post_dates are identical. I fixes it by sorting by ID instead." atimmer Next Release 25065 The unit tests assume that PHPUnit is installed via PEAR dd32 Unit Tests normal normal 3.7 defect (bug) closed 2013-08-18T00:49:15Z 2013-08-28T01:43:14Z "PHPUnit officially supports 3 [http://phpunit.de/manual/current/en/installation.html installation methods]: 1. via PEAR 2. via Phar file 3. via Composer Core apparently only supports the first one, which also happens to be the most cumbersome. Steps to reproduce: 1. Install PHPUnit via Phar: {{{ wget http://pear.phpunit.de/get/phpunit.phar chmod +x phpunit.phar mv phpunit.phar /usr/local/bin/phpunit }}} 2. Try to run the WP test suite with it: {{{ phpunit -c tests/phpunit.xml }}} Result: {{{ PHP Fatal error: require_once(): Failed opening required 'PHPUnit/Autoload.php' (include_path='.:/usr/local/Cellar/php55/5.5.1/lib/php') in /Users/User/svn/wp-develop/tests/includes/bootstrap.php on line 7 }}}" scribu Next Release 26164 Unit Tests :: links_add_target function and trivial changes wonderboymusic Unit Tests normal normal 3.8 defect (bug) closed 2013-11-22T15:24:16Z 2013-11-22T16:24:35Z "Hi: Attached are some Unit Tests of the formatting function '''links_add_target'''. Upon implementation of the tests I found 2 trivial changes with fixes in the included diff. Please let me know if correcting these items is desired or if I should update the test cases to sync with current functionality. * Replacing existing target="""" properties add additional space character * tags without properties (e.g. ) don't get appended with target property Thank you" mdbitz Next Release 25282 Unit Tests should run in Debug mode Unit Tests 3.7 normal normal 3.7 defect (bug) closed 2013-09-11T17:21:25Z 2015-10-13T14:01:25Z "We get reports for notices / warnings sporadically and arbitrarily. Almost every time, they reveal coding errors, inconsistencies, or missed variable checks. Currently, if you add these lines to `wp-tests-config.php`: {{{ error_reporting( -1 ); define( 'WP_DEBUG', true ); }}} A LOT of tests fail and a lot of errors/warnings are exposed. Let's clean this up." wonderboymusic Next Release 24662 Unit Tests: Re-implement the mock PHPMailer SergeyBiryukov Unit Tests normal normal 3.6 defect (bug) closed 2013-06-29T21:25:09Z 2013-06-29T22:31:16Z "Follow-up: #UT47 I would like to get this work again, especially for #23642." ocean90 Next Release 25118 Unit Tests: Restrict locales in test_locale_floats in db.php SergeyBiryukov Unit Tests 3.6 normal normal 3.7 defect (bug) closed 2013-08-22T14:51:01Z 2013-08-22T15:28:02Z "While running `phpunit tests/db.php` from the wordpress-tests project I got the following error: {{{ 1) Tests_DB::test_locale_floats constant(): Couldn't find constant LC_PAPER }}} Apparently I don't have a constant defined on my Linux (Fedora) box called `LC_PAPER`. I didn't see that as a possible argument in the [http://www.php.net/manual/en/function.setlocale.php setlocale function] either. I would suggest that we verify if a category is an existing constant when we try to set it as a locale." nofearinc Next Release 24207 Unit tests for widgets.php maxcutler Unit Tests 3.5.1 normal normal 3.6 defect (bug) closed 2013-04-27T23:52:42Z 2013-04-28T00:10:58Z Beginning a unit test file for widgets.php jupiterwise Next Release 23928 Update ajax autosave unit tests for 3.6 Unit Tests 3.6 normal normal 3.6 defect (bug) closed 2013-04-03T18:19:22Z 2013-05-16T15:25:50Z "The ajax autosave unit test is failing with trunk. Update it to be compatible with the following core changes: * Move nopriv_autosave to nopriv_heartbeat [23692] * Remove use of `$login_grace_period` [23699] * Send post_type with autosave [16657] (this was incorrect in the original unit test, I'm not sure why it's just now breaking) * Change `$_POST['post_ID']` to `$_POST['post_id']` [23683]" kurtpayne Next Release 26629 Update version in package.json and unit test it nacin Unit Tests 3.8 normal normal 3.9 defect (bug) closed 2013-12-14T22:00:55Z 2014-01-23T20:08:46Z "While working on #26073, I noticed that package.json's version is still at 3.7.0. I'm not sure about the severity (as package.json is not part of releases), but Composer users might appreciate an update. I'll attach a patch to update the version, and another one that adds a unit test to remind us of updating the version in the future, similar to the existing unit test for the version in readme.html." TobiasBg Next Release 24706 Use $wpdb->prefix to verify query in tests/meta/query.php (WP_Meta_Query test) SergeyBiryukov Unit Tests normal normal 3.6 defect (bug) closed 2013-07-08T00:54:26Z 2013-07-08T01:39:02Z "wp-tests-config-sample.php sets the table_prefix to ""wptests_"", which was causing tests/meta/query.php to fail on a test where it assumed the prefix was ""wp_""." codebykat Next Release 26836 Use Mock PHPMailer during Installation for Unit Tests nacin Unit Tests 3.9 normal normal 3.9 defect (bug) closed 2014-01-14T20:43:54Z 2014-01-14T21:55:42Z "We install the mock PHPMailer class for use during unit tests, however, it's not currently used during bootstrap installation since this is done in a separate process. Not doing this can result in mailer exceptions in environments that aren't properly configured for sending mail even though we don't want to actually send any during tests. This is the case on Travis CI for example, and is currently one more reason why AJAX unit tests fail (since they perform an installation during some tests that are marked for `@runTestsInSeparateProcesses`. The solution is simple, we already have a custom install script for bootstrapping tests, and we just need to inject the mock mailer there in the same way we do in bootstrap.php for the tests that aren't run in a separate process, see the attached patch." bpetty Next Release 23066 WordPress 3.5 Duplicate Entry Unit Tests 3.5 normal normal defect (bug) closed 2012-12-28T14:16:15Z 2013-05-15T08:43:37Z "WordPress 3.5 MU when running PHP 5.2.17/5.3.x/5.4.x seems to have some duplicate install code. Detected by Travis-CI. Example build where error is present: https://travis-ci.org/chriscct7/Easy-Digital-Downloads/jobs/3855494 3/4 of the way down you'll find the following: {{{ Installing network… Installing sites… WordPress database error Duplicate entry '1' for key 'PRIMARY' for query INSERT INTO `wp_terms` (`term_id`,`name`,`slug`,`term_group`) VALUES (1,'Uncategorized','uncategorized',0) made by wp_install, wp_install_defaults WordPress database error Duplicate entry '1-category' for key 'term_id_taxonomy' for query INSERT INTO `wp_term_taxonomy` (`term_id`,`taxonomy`,`description`,`parent`,`count`) VALUES (1,'category','',0,1) made by wp_install, wp_install_defaults }}} " chriscct7 Next Release 14057 Wordpress MU 2.91 Test Suite Errors Unit Tests 2.9.1 normal normal defect (bug) closed 2010-06-23T05:25:51Z 2010-06-23T06:17:59Z "I'm trying to run the latest version of the test suite (http://svn.automattic.com/wordpress-tests/) against wordpress MU by passing ""-v mu"" on the command line, and I get a whole slew of errors related to database tables being missing: {{{ WordPress database error Table 'wordpress_test.wp_sitemeta' doesn't exist for query SELECT meta_value FROM wp_sitemeta WHERE meta_key = 'wpmu_sitewide_plugins' AND site_id = 1 made by require_once, get_site_option ... WordPress database error Table 'wordpress_test.wp_users' doesn't exist for query SELECT * FROM wp_users WHERE user_login = 'd87193701cb6b55a91a34b0f049d22e4' made by wp_install, username_exists, get_userdatabylogin, get_user_by ... WordPress database error Table 'wordpress_test.wp_users' doesn't exist for query INSERT INTO wp_users (user_pass,user_email,user_url,user_nicename,display_name,user_registered,user_login) VALUES ('$P$BGRXqTL2Nqv3AGONWtsOSf9cPRfngW.','205a27b062b5876ffd9a5301166b9710@example.com','','d87193701cb6b55a91a34b0f049d22e4','d87193701cb6b55a91a34b0f049d22e4','2010-06-21 16:19:18','d87193701cb6b55a91a34b0f049d22e4') made by wp_install, wp_create_user, wp_insert_user WordPress database error Table 'wordpress_test.wp_usermeta' doesn't exist for query SELECT * FROM wp_usermeta WHERE user_id = 96 AND meta_key = 'first_name' made by wp_install, wp_create_user, wp_insert_user, update_usermeta, delete_usermeta ... ... WordPress database error Table 'wordpress_test.wp_usermeta' doesn't exist for query DELETE FROM wp_usermeta WHERE user_id = 96 AND meta_key = 'last_name' made by wp_install, wp_create_user, wp_insert_user, update_usermeta, delete_usermeta ... WordPress database error Table 'wordpress_test.wp_usermeta' doesn't exist for query SELECT * FROM wp_usermeta WHERE user_id = 96 AND meta_key = 'admin_color' made by wp_install, wp_create_user, wp_insert_user, update_usermeta ... WordPress database error Table 'wordpress_test.wp_users' doesn't exist for query SELECT * FROM wp_users WHERE ID = 96 LIMIT 1 made by wp_install, wp_create_user, wp_insert_user, WP_User->WP_User, get_userdata ... WordPress database error Table 'wordpress_test.wp_usermeta' doesn't exist for query SELECT * FROM wp_usermeta WHERE user_idTest Suite Test_Clean_Pre .FF. }}} Then some of the tests start to run, and when it gets to WPTestActions, I get these errors: {{{ WPTestActions ..........Action Time: 0.06314039 (0.00012628 each) ... Fatal error: Cannot use object of type Closure as array in C:\wordpress\wordpress-mu\wp-includes\plugin.php on line 680 = 96 AND meta_key = 'default_password_nag' made by wp_install, update_usermeta WordPress database error Table 'wordpress_test.wp_usermeta' doesn't exist for query INSERT INTO wp_usermeta (user_id,meta_key,meta_value) VALUES ('96','default_password_nag','1') made by wp_install, update_usermeta WordPress database error Table 'wordpress_test.wp_users' doesn't exist for query SELECT * FROM wp_users WHERE ID = 96 LIMIT 1 made by wp_install, WP_User->WP_User, get_userdata WordPress database error Table 'wordpress_test.wp_usermeta' doesn't exist for query SELECT * FROM wp_usermeta WHERE user_id = 0 AND meta_key = '' made by wp_install, WP_User->set_role, update_usermeta WordPress database error Table 'wordpress_test.wp_usermeta' doesn't exist for query INSERT INTO wp_usermeta (user_id,meta_key,meta_value) VALUES ('0','','a:1:{s:13:\""administrator\"";b:1;}') made by wp_install, WP_User->set_role, update_usermeta WordPress database error Table 'wordpress_test.wp_usermeta' doesn't exist for query SELECT * FROM wp_usermeta WHERE user_id = 0 AND meta_key = 'wp_1_user_level' made by wp_install, WP_User->set_role, WP_User->update_user_level_from_caps, update_usermeta WordPress database error Table 'wordpress_test.wp_usermeta' doesn't exist for query INSERT INTO wp_usermeta (user_id,meta_key,meta_value) VALUES ('0','wp_1_user_level','10') made by wp_install, WP_User->set_role, WP_User->update_user_level_from_caps, update_usermeta WordPress database error Table 'wordpress_test.wp_users' doesn't exist for query SELECT * FROM wp_users WHERE ID = 96 LIMIT 1 made by wp_install, wp_new_blog_notification, WP_User->WP_User, get_userdata WordPress database error Table 'wordpress_test.wp_blogs' doesn't exist for query SELECT * from wp_blogs where blog_id=1 PHP Fatal error: Cannot use object of type Closure as array in C:\wordpress\wordpress-mu\wp-includes\plugin.php on line 680 }}} " dvmorris Next Release 26725 Wordpress-tests' WP_PHPUnit_Text_UI Throws Unhandled Exceptions nacin Unit Tests 3.9 normal normal 3.9 defect (bug) closed 2013-12-27T01:24:15Z 2013-12-27T19:06:55Z "'''Summary''' In Wordpress-test's boostrap.php, the WP_PHPUnit_TextUI_Command class extends the PHPUnit test runner class simply to parse command line arguments and find some specific ones. PHPUnit's test runner is not actually be used for any other reason. If it encounters command line arguments that PHPUnit doesn't recognize, an unhandled exception occurs. This is problematic for a couple reasons (see problem details), but the most important one is that enforcing the correct PHPUnit command line arguments is out of the scope of this particular code. If there is a problem, it might be better if it were handled by PHPUnit and not this Wordpress class that we're just using to find specific arguments. '''Problem Details''' Currently the WP_PHPUnit_TextUI_Command constructor contains a code snippet cribbed directly from the PHPUnit_Text_UI_Command::handleArguments() method. {{{ $this->options = PHPUnit_Util_Getopt::getopt( $argv, 'd:c:hv', array_keys($this->longOptions) ); }}} This works fine when you run PHPUnit directly (and correctly). If you try to use one of a handful of different integration or continuous testing tools, PHPUnit is not being run directly from the command line and so unhandled exceptions will occur until boostrap.php is modified by hand. '''Specific use case''' Trying to use the MakeGood plugin for Eclipse as a tool for continuous testing will cause unhandled exceptions and prevent testing from happening. Here's what MakeGood does... {{{ [PATH_TO_ECLIPSE]\plugins\com.piece_framework.makegood.stagehandtestrunner_2.5.0.v201311031709\resources\php\bin\testrunner.php --no-ansi phpunit --log-junit=[PATH_TO_TEMP_DIR]\com.piece_framework.makegood.launch\MakeGood1388104275775.xml --log-junit-realtime --phpunit-config=[PATH_TO_phpunit.xml] -R --test-file-pattern=Test(?:Case)?\.php$ [TEST_PATH] }}} PHPUnit won't recognize --no-ansi (if not a few other things) and an exception is thrown. '''Proposed Solution''' Loop through ARGV directly and call longOption on each one, catching the exceptions thrown by any errors but not acting on them. Dealing with bad command line parameters is something that is either handled earlier or later, by PHPUnit. Also, instead of extending the PHPUnit runner class, just go directly to the source and extend PHPUnit_Util_Getopt." wawco Next Release 25818 `WP_UnitTestCase::go_to()` drops query vars wonderboymusic Unit Tests 3.8 normal normal 3.8 defect (bug) closed 2013-11-04T19:41:00Z 2020-10-07T07:02:42Z "If you register a custom taxonomy in a unit test case, create a term in it, add it to a post, delete rewrite rules, and then call `WP_UnitTestCase::go_to()` with a URL for the connected term, the query var is not registered, so the query just goes to home. It is not very clear what is the proper way to do this. I discovered the issue writing unit tests here: http://core.trac.wordpress.org/attachment/ticket/20767/20767.3.diff There should be assertions for `assertNotEmpty( get_query_var( 'sometax' ) )`, they currently fail because the query var isn't registered. When a custom taxonomy is registered, and then the query is filtered to include a 2nd term in the taxonomy using `pre_get_posts`, `$wp_query->query_vars` should include the query var and `tax_query`, it currently only includes `tax_query`. Looking into this." wonderboymusic Next Release 25632 post_parent out of range error in unit tests Unit Tests 3.7 normal minor defect (bug) closed 2013-10-18T21:01:34Z 2013-11-30T23:08:12Z "in tests/post/attachments.php Out of range value for column 'post_parent', the function _make_attachment() uses a default value of -1." atimmer Next Release 26248 setting WP_TESTS_FORCE_KNOWN_BUGS to true shouldn't produce fatal errors wonderboymusic Unit Tests normal normal 3.8 defect (bug) closed 2013-11-25T22:45:43Z 2013-11-25T22:49:51Z Sometimes it's fun to see how many unit tests would fail if there were no `@ticket` annotations. Problem: some tests try to use non-existent classes and functions, those tests should still be skipped. wonderboymusic Next Release 24870 Add JavaScript unit tests to core Unit Tests 3.5.2 normal normal enhancement closed needs-unit-tests 2013-07-29T00:59:01Z 2013-08-29T18:35:49Z "With more JavaScript entering core (like the new revisions screen), it would be great to build some JavaScript unit tests. I am opening this ticket to stimulate some discussion! I'm new to JavaScript unit testing, so could use some help from those with more experience. There are many javascript unit testing frameworks: Qunit and Jasmine seem like likely candidates. Those who have experience with JavaScript unit test - please offer direction! So far, I set up Jasmine.js and phantomjs (headless javascript engine), which seemed relatively painless. I'm going to work on writing some actual tests next, starting with revisions. Once I have something useful, I will post the results here." adamsilverstein Next Release 26364 Add Travis CI Configuration nacin Unit Tests 3.8 normal normal 3.8 enhancement closed 2013-12-02T19:26:36Z 2013-12-03T23:17:13Z "Going back to our efforts with #24976 (develop.svn.wp.org), I've built a new Travis CI configuration that works with the new repo. We still don't have an official GitHub mirror of this new repo yet, however, I have tested this with my own [https://github.com/tierra/wordpress git-svn mirror] (or more specifically, my [https://travis-ci.org/tierra/wp-travis travis-specific copy]), and it should work smoothly when an official mirror is in place. Of course, if this is merged now, I can still just enable Travis CI on my mirror, and we can track failures there for now too." bpetty Next Release 21993 Add WP_DOING_TESTS constant, check for it in WP_Ajax_Response Unit Tests 3.5 normal normal enhancement closed 2012-09-25T21:04:51Z 2012-09-26T12:24:32Z "I'm writing unit tests for #21767 that need to call functions such as `wp_ajax_add_tag()`. These functions instantiate a `WP_Ajax_Response` object and `send()`, which sends HTTP headers and causes the unit tests to fail. So far I can't find a way to keep the headers from being sent (anyone know how to do this?) so I'm opening this ticket as an alternate solution: introduce a WP_DOING_TESTS constant (defined in the bootstrap.php of the unit testing framework) and return out of the send() function if that constant is set to true. Again, happy to be told there is a better way to do this, but definitely want to be able to get testing coverage of these ""controller"" functions." alexkingorg Next Release 24208 Add more wp-includes/cache.php test coverage maxcutler Unit Tests 3.5.1 normal normal 3.6 enhancement closed 2013-04-28T00:16:12Z 2013-04-28T00:20:57Z Added tests for wp_cache_init() and wp_cache_replace(). tollmanz Next Release 26514 Add unit tests for wp.shortcode.attrs wonderboymusic Unit Tests normal normal 3.9 enhancement closed 2013-12-09T23:12:54Z 2014-01-17T18:01:35Z Add three unit tests for another method in wp.shortcode jorbin Next Release 21742 Allow unit tests to override is_*_admin() ryan Unit Tests 3.4.1 normal normal 3.5 enhancement closed 2012-08-30T18:01:36Z 2012-09-01T11:20:33Z Unit tests sometimes need to fake being in the user, network, or blog admin or on the front page. This is currently impossible due to the use of constants. A possible solution is to consult the current screen if it is setup and fallback to the constants otherwise. Alternatively, add filters in the is_*_admin() functions. ryan Next Release 25871 Always Clean Install in PHPUnit Tests wonderboymusic Unit Tests normal normal 3.8 enhancement closed 2013-11-07T20:36:24Z 2013-11-13T00:45:07Z "The unit tests only re-install WordPress from a previous run if using a different config (multisite vs single), it requires a DB upgrade (checking db_version), or `wp-tests-config.php` changes in any way (hashed). This was originally introduced from @nbachiyski with the [https://github.com/nb/wordpress-tests/commit/d3de3aeee26196a268abb0e3a278b6b51bc5e946 test runner rewrite], and modified again by @gcorne to [https://github.com/nb/wordpress-tests/commit/0db11272b36ce62ade4f920ed4f9ca87efa2a971 account for wp-tests-config.php]. The problem with doing this lies in these areas though: - In transitioning these unit tests to run against the `build` version instead of `src` (and we do want to do this soon after this change), we should never leave extra files like `.wp-tests-version` in the `build` directory that could be accidentally packaged with WP even if it was ignored in SVN. - We should '''always''' assume failure from previous unit test runs, and '''always''' build and test from a clean install. It doesn't matter if it's the same `db_version` and install type, anything could have gone wrong and leave us with incorrect testing results affected by previous runs. - Most of the time, this is actually ineffective because testers should already be running both the single site, and multisite tests one after the other, causing a re-install with the current code anyway. Besides the above though, re-installing WordPress takes less than a second compared with the 3 to 5 minutes the actual tests take anyway. It's not slowing down the tests any." bpetty Next Release 26163 Proposed Unit Test for normalize_whitespace function wonderboymusic Unit Tests normal minor 3.8 enhancement closed 2013-11-22T15:18:19Z 2013-11-22T16:18:15Z "Hi: I'm currently reviewing the code coverage of the existing Unit Tests and would like to submit the following Test Cases for validation of the '''normalize_whitespace''' formatting function. No current unit tests exist for this function." mdbitz Next Release 23499 Rename phpunit.xml to phpunit.xml.dist nacin Unit Tests 3.6 normal normal 3.6 enhancement closed 2013-02-18T09:53:30Z 2013-03-03T20:26:35Z "PHPUnit supports both `phpunit.xml` and `phpunit.xml.dist` where `phpunit.xml` has higher priority. This is ideal for cases like ours when we distribute the testing suite. By using `phpunit.xml.dist` we will allow users to add their own `phpunit.xml`, instead of editing ours." nbachiyski Next Release 23531 Separate tests into unit / integration / ... directories Unit Tests 3.6 normal normal enhancement closed 2013-02-19T15:51:16Z 2013-10-30T20:51:39Z "To improve the speed how tests can be run - especially the unit-tests - I suggest to divide tests into sub-directories, for example: ''unit'' - for unit tests[[BR]] ''integration'' - for integration tests[[BR]] ''functional'' - for functional tests Right now all tests are roughly labeled as ""Unit-Tests"" even they are not unit-tests per-se, e.g. some of them interacting with the database or the file-system. Background: [http://stackoverflow.com/q/4904096/367456 What's the difference between unit, functional, acceptance, and integration tests?]" hakre Next Release 23532 Sync Tests Repository on Github Unit Tests normal normal enhancement closed 2013-02-19T15:56:53Z 2013-09-13T23:42:30Z "Like with Wordpress, the tests should be synched as well with a git repository under https://github.com/WordPress/ Especially after taking in https://github.com/nb/wordpress-tests" hakre Next Release 26116 Unit Tests: Add assertNotWPError() to complement assertWPError() Unit Tests normal normal enhancement closed 2013-11-19T19:41:58Z 2014-01-27T03:16:58Z It's an easy fix, and makes it simpler to let tests make sure something has succeeded and isn't an error, as opposed to testing when hoping for an error. georgestephanis Next Release 25507 Unit test for `wp_strip_all_tags` and better docs nacin Unit Tests 3.8 normal normal 3.9 enhancement closed 2013-10-07T12:12:01Z 2014-01-30T22:09:54Z "There are no unit tests for `wp_strip_all_tags` currently - I also think the description needs some work to explain exactly how this is different from `strip_tags` as it wasn't obvious to be initially. " joehoyle Next Release 25784 shortcode.js needs unit tests Unit Tests 3.8 normal normal 3.8 enhancement closed 2013-10-31T00:48:50Z 2013-12-04T00:41:02Z Part of the ongoing effort to increase test coverage. iandunn Next Release 17749 Faster and phpunit runner-compatible unit tests nbachiyski Unit Tests normal normal 3.3 feature request closed 2011-06-10T13:25:47Z 2013-02-28T14:18:35Z "Currently the WordPress unit-tests use a custom test runner and most of the test cases replace all the data in the database tables before they run. Since we are using PHPUnit, we should use the phpunit test runner. This gives us: in-editor test running, CI, easier creation of more fine-grained suites. All these will make running the testt easier, which is a good step towards more people running them. Replacing the data before each testcase run is often slow. The data isn't replaced after each test withing the case, though, which is highly error-prone, because we need to account for any changes of the data made during the tests. Here is my take on solving these problems: * Create a very simple PHPUnit test suite, which loads all test classes from the tests directory. * Install WordPress once, before running any tests. * Make all the tables InnoDB. * In the default WordPress test case class start a transaction on {{{setUp}}}. * {{{ROLLBACK}}} all the changes on {{{tearDown}}}. * Reinitalize some global variables and clean cache on {{{setUp}}}. This way we install WordPress only once (fast) and at the same time we don't need to care about the changes we make during each test (not error prone). This approach, however, doesn't favor having prepared datasets in advance (shared fixtures). Which isn't bad. I strongly believe that shared fixtures more harm than good. They create unneeded dependencies between data, make test unclear, because the data lives far away, and are very sensitive to change, because many tests use the same data. If the tests are small enough (they should) fresh fixtures won't slow the test, the data will be in the test itself and no external data change would break them. In order to implement the test class and suite, a couple of changes to core were needed: * WordPress is loaded in a function call (that's how {{{phpunit}}} loads tests), so some variables need to be explictly initialized as globals (I guess there are more, which will be revaled after more test coverage). * Some filters were needed in order to be able to make the tables InnoDB (easier to implement than changing the enging after creation). The patch is attached. The test case class and runner code is at https://github.com/nb/wordpress-tests (the current repo doesn't have branch structure, otherwise I would have put it there)." nbachiyski Next Release 26566 Add unit test to verify all bundled themes have valid text domain declared nacin Unit Tests 3.8 high normal 3.9 task (blessed) closed 2013-12-12T00:25:03Z 2013-12-30T16:09:12Z #26542 was embarrassing — we almost released Twenty Fourteen without a text domain declared for it. Let's set up a unit test to make sure this never happens again. markjaquith Next Release 25096 Automate running JavaScript unit tests with Grunt Unit Tests normal normal 3.7 task (blessed) closed 2013-08-20T18:45:05Z 2013-09-25T18:03:18Z "As [https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-08-20&sort=asc#m669704 discussed in IRC], we are beginning the process of adding JavaScript unit tests. Grunt may be used to automatically run JS unit tests from the command line, shortening the develop-test feedback cycle. This patch adds a Grunt task to run QUnit-based tests like the ones being worked on in #25088. Install this patch alongside #25088, run `npm install` to install the QUnit plugin for Grunt, then run tests with `grunt test`. I am in the process of enhancing this to also provide an option to run tests in a local web server, in order to get more visual feedback, permit running tests in multiple browsers, and/or use browser development tools while writing tests." kadamwhite Next Release 25088 password-strength-meter.js should have unit tests SergeyBiryukov Unit Tests normal normal 3.7 task (blessed) closed 2013-08-20T02:31:32Z 2013-09-07T15:19:57Z "As discussed in [https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-08-20&sort=asc#m669704 IRC], our goal is to have unit testable javascript. The[http://core.trac.wordpress.org/browser/trunk/src/wp-admin/js/password-strength-meter.js password-strength-meter.js] file will serve as our initial testbed for testing. This file was chosen since there will likely be some changes to it in 3.7 and it is small and already largely testable. " jorbin Future Releases 11867 Increase Cross-Plattform portability of the Testsuite westi Unit Tests normal normal WordPress.org defect (bug) closed 2010-01-11T19:26:32Z 2010-02-18T19:07:51Z "The attached patch increases cross plattform compability for the testsuite. It does two things: 1. Getopt compability for non PHP 5.3 systems (especially Windows but also certain *NIX Systems). 2. Usage of the PATH_SEPARATOR constant for the include path to allow it to be used on windows as well. With these changes I was able to get the suite to run under windows. The 1. deficency [http://codex.wordpress.org/Automated_Testing#Running_The_Tests is documented in codex] (see ''Note for Windows Users'' remark), the 2. is not. After the patch is provided that notice can be removed in codex. Additionally I've extended the README.txt for the commandline parameters and wordwrapped it." hakre Future Releases 24079 Inline Docs for unit-tests SergeyBiryukov Unit Tests normal normal WordPress.org defect (bug) closed 2013-04-13T20:56:19Z 2013-04-14T03:47:23Z Added doc blocks for unit testing framework bobbravo2 Future Releases 22989 Translation units tests loading test data from non-dynamic path Unit Tests 3.5 normal normal WordPress.org defect (bug) closed 2012-12-18T09:07:44Z 2012-12-19T09:22:44Z "Many of the current translation (pomo) unit tests load test files from paths not prefixed with DIR_TESTDATA. The problems happen when the bootstrap.php file is located in a different folder from the default. In that case the mentioned tests fail with errors like {{{fopen(data/pomo/{filename}): failed to open stream: No such file or directory}}}. '''Reproducing this error''' Default bootstrap location, tests succeed: `www/test_svn/bootstrap.php`[[BR]] `www/test_svn/tests/`[[BR]] `www/test_svn/data/pomo/test_mo.php` Tests fail when bootstrap is moved &/or executed by other files: `www/visualphpunit/bootstrap.php`[[BR]] `www/test_svn/tests/`[[BR]] `www/test_svn/data/pomo/test_mo.php` The attached patch prefixes all the offending tests with DIR_TESTDATA so they can correctly locate the testdata even when the bootstrap is relocated." mbijon Future Releases 23690 Allow plugin test bootstraps access to tests_add_filter() earlier scribu Unit Tests normal normal WordPress.org enhancement closed 2013-03-04T18:15:06Z 2021-06-07T10:45:57Z "Currently, plugins that have their own unit tests have a bootstrap.php file that looks like this: {{{ array( basename( dirname( dirname( __FILE__ ) ) ) . '/my-plugin.php' ), ); require getenv( 'WP_TESTS_DIR' ) . '/includes/bootstrap.php'; }}} The problem is that the plugin folder needs to be inside `WP_CONTENT_DIR . '/plugins/'`, which is an artificial requirement. The bootstrap file could just `require()` the plugin file themselves and everything will work, *except* for one thing: hooks such as 'plugins_loaded' or 'init'. With the attached patch, the file could look like this: {{{ get_post_templates` relies on global `themes` cache group. This means that the same results are being used on every subsite in a network. In the past, it did not lead to issues, but now, with FSE, page templates can be created in admin area, which complicates things. `get_block_templates` function that is used in `WP_Theme->get_post_templates` loads templates created on subsite and later on caches those results. This leads to all sites in a network accessing the same cached results - site A can end up seeing templates of site B when editing a page. This becomes especially problematic if `wp_cache_themes_persistently` filter returns `true`. I think the solution here should be to move `get_block_templates` related code outside of cache regeneration part. This way, templates from files would be cached globally, but block templates would be unique per site in a network. Am I missing anything? If not, I can prepare PR for that." maniu Next Release 28263 get_raw_theme_root() fails to recognize a singular custom $wp_theme_directories Themes normal normal defect (bug) closed needs-unit-tests 2014-05-15T17:17:04Z 2014-05-27T19:19:32Z "When no `WP_CONTENT_DIR . '/themes` directory exists, `get_raw_theme_root()` fails to recognize a singular custom `$wp_theme_directories` because of this assumption: {{{ if ( count($wp_theme_directories) <= 1 ) return '/themes'; }}}" danielbachhuber Next Release 16395 Add 'Template Version' for use with 'Template' in Child-Themes Themes 3.1 normal normal enhancement closed needs-unit-tests 2011-01-28T16:36:15Z 2016-01-11T18:27:56Z "From the discussions on the http://make.wordpress.org/themes/ site I am suggesting the addition of 'Template Version' for inclusion into the get_theme_data() function to be used as a reference for a Child-Theme's compatibility with its Parent-Theme ('Template'). PS: This is my first ""patch"" submission, any constructive feedback would be greatly appreciated. EAC" cais Future Releases 58905 Ensure locate_template only loads theme files Themes normal normal 6.6 defect (bug) new needs-unit-tests 2023-07-25T19:44:43Z 2024-02-17T13:41:42Z "It's possible to have locate_template load files that are not template files which could be unexpected behavior that breaks the display of a page. The chance this breaks something is, I think, not infinitesimal. Therefore, this should go in early. An initial patch is attached. " jorbin Future Releases 56990 Render blocking CSS `classic-themes.css` unnecessarily enqueued Themes 6.1 normal normal Future Release defect (bug) assigned needs-unit-tests 2022-11-03T22:21:14Z 2023-06-20T17:57:20Z "Since WordPress 6.1, a new CSS file [https://github.com/WordPress/WordPress/blob/master/wp-includes/css/classic-themes.css classic-themes.css] is now enqueued on all pages on the front end of non-block themes. This stylesheet seems to only include styles related to the `wp-block-button__link` class and the stylesheet is added regardless of whether a block button is used on the page. Although the file itself is tiny, the cumulative impact of every WordPress site using a non-block theme is huge and no explanation is given in the doc block as to why the style is needed. This change was originally added in https://github.com/WordPress/gutenberg/pull/44731 and ported over to core. Even in [https://github.com/WordPress/gutenberg/pull/44731#pullrequestreview-1133944306 this comment] though, the front end view already looks fine, so it is unclear why the style needs to be added manually here. The original Gutenberg patch only enqueued the styles in the editor, so it is unclear why styles were added to the front end in this commit: https://github.com/WordPress/WordPress/commit/bbb40de012670768a525193639c0d5e4ea932df7. In my testing, removing the style had no front end impact, the button looked exactly the same before and after I removed the stylesheet. The button is already styled from `blocks.css`. This stylesheet adds an unnecessary render blocking stylesheet with a huge cumulative impact on WordPress sites. I suggest we remove it. Worth noting that this enqueue was added during RC, probably something we avoid doing if we hope to avoid performance regressions. Also points to the need for better performance metrics, even something as simple as catching new front end enqueues could be useful here." adamsilverstein Future Releases 57141 WP_Theme cannot locate a parent block theme Themes 6.0 normal normal Awaiting Review defect (bug) new needs-unit-tests 2022-11-18T04:02:53Z 2022-11-21T23:37:35Z "As reported here: https://github.com/WordPress/gutenberg/issues/45811 after a discussion in slack: https://wordpress.slack.com/archives/C02QB8GMM/p1668569269811889 On wp-themes.com we're running into a use-case where the Parent theme cannot be located when both the parent and child theme are block themes, and the parent does not have an index.php file. (See screenshot attached below, where the parent theme is 100% most definitely installed) This appears to work on some installations, but not on others. I believe it working might be down to caching, I haven't figured that out. The attached PR updates the code in WP_Theme to support the same theme files as supported via [53416] for themes in parent themes. " dd32 Future Releases 42513 WP_Theme::get_post_templates() is extremely inefficient for large themes Themes 4.8.3 normal normal Awaiting Review defect (bug) new needs-unit-tests 2017-11-11T14:07:01Z 2017-11-12T13:13:42Z "WP_Theme::get_post_templates() uses file_get_contents() to read the complete contents of each theme php file in the root of a theme into memory, twice, and processes the result with a custom Regular Expression. As a result, significantly more data than necessary is processed when loading large themes. In addition, because the standard get_file_data() function is not called (as it is with all other header comments), the ""extra_{$context}_headers"" filter is never called, which is inconsistent behavior with other file_header related operations, such as the WP_Theme constructor." gschoppe Future Releases 59507 global-styles-and-settings.php in wp_theme_has_theme_json Themes 6.3.1 normal normal Awaiting Review defect (bug) new needs-unit-tests 2023-09-29T18:45:19Z 2023-10-02T17:29:27Z "Wordpress 6.3.1 , php 8.1.23 {{{#!php Double Quotes', '') Error: Call to undefined function wp_rel_ugc() /var/www/tests/phpunit/tests/formatting/WPRelUgc.php:31 4) Tests_Rel_Ugc::test_wp_rel_ugc with data set #1 ('', '') Error: Call to undefined function wp_rel_ugc() /var/www/tests/phpunit/tests/formatting/WPRelUgc.php:31 5) Tests_Rel_Ugc::test_wp_rel_ugc with data set #2 ('', '') Error: Call to undefined function wp_rel_ugc() /var/www/tests/phpunit/tests/formatting/WPRelUgc.php:31 7) Tests_Rel_Ugc::test_wp_rel_ugc with data set #4 ('', '') Error: Call to undefined function wp_rel_ugc() /var/www/tests/phpunit/tests/formatting/WPRelUgc.php:31 8) Tests_Rel_Ugc::test_wp_rel_ugc with data set #5 ('', '') Error: Call to undefined function wp_rel_ugc() /var/www/tests/phpunit/tests/formatting/WPRelUgc.php:31 9) Tests_Rel_Ugc::test_wp_rel_ugc with data set #6 ('', '') Error: Call to undefined function wp_rel_ugc() /var/www/tests/phpunit/tests/formatting/WPRelUgc.php:31 10) Tests_Rel_Ugc::test_wp_rel_ugc with data set #7 ('', '') Error: Call to undefined function wp_rel_ugc() /var/www/tests/phpunit/tests/formatting/WPRelUgc.php:31 11) Tests_Rel_Ugc::test_wp_rel_ugc with data set #8 ('', '') Error: Call to undefined function wp_rel_ugc() /var/www/tests/phpunit/tests/formatting/WPRelUgc.php:31 12) Tests_Rel_Ugc::test_append_ugc_with_valueless_attribute Error: Call to undefined function wp_rel_ugc() /var/www/tests/phpunit/tests/formatting/WPRelUgc.php:81 ERRORS! Tests: 9960, Assertions: 44191, Errors: 12, Skipped: 11. }}} **Patch** Should I include changes to the `package-lock.json` even though I made no changes to the dependencies in `package.json`? " dhurlburtusa Future Releases 33017 Images displayed with page.php instead of index.php Themes normal normal defect (bug) reopened needs-unit-tests 2015-07-16T15:04:19Z 2019-06-04T21:15:50Z "I am developing a theme and currently do not have an `attachment.php` or a `single.php`. When I insert an unattached image into a post and select ""Link to: Attachment Page"", I expect the image to be displayed with `index.php` according to the template hierarchy [https://developer.wordpress.org/files/2014/10/wp-template-hierarchy.jpg]. However, the attachment page is displayed with the `page.php` tempalte instead, and the URL is under my static front page. The issue does not show up with images attached to the post." creon Future Releases 24143 When define('WP_CONTENT_DIR', 'your-dir') twentythirteen - The theme directory does not exist. Themes 3.4 normal normal defect (bug) reopened needs-unit-tests 2013-04-20T10:08:16Z 2021-04-20T06:02:42Z "If you use either of following in you wp-config.php you'd automatically get a Broken Themes. {{{ define('WP_CONTENT_DIR', 'your-dir'); define('WP_CONTENT_URL', 'your-url'); }}} The following themes are installed but incomplete. Themes must have a stylesheet and a template. Name Description twentythirteen The theme directory does not exist." azizur Future Releases 38160 Attachment template hierarchy selects generic attachment.php before specific post type templates Themes normal normal enhancement closed needs-unit-tests 2016-09-26T13:29:00Z 2022-07-01T22:43:21Z "When viewing a single attachment at its permalink, the template hierarchy is as follows (using `foo.jpg` as an example). 1. `image-jpeg.php` 2. `jpeg.php` 3. `image.php` 4. `attachment.php` 5. `single-attachment-foo.php` 6. `single-attachment.php` 7. `single.php` 8. `singular.php` 9. `index.php` Note that the generic `attachment.php` appears higher in the hierarchy than the more specific `single-attachment-foo.php`. This means it's impossible to target a specific attachment if an `attachment.php` file is in place." johnbillion Future Releases 15086 get_template_part() should let you specify a directory westi* Themes 3.0 normal normal enhancement accepted needs-unit-tests 2010-10-10T21:36:45Z 2019-06-04T21:06:02Z "IT would be nice for `get_template_part()` to allow you to specify a directory to look for a file in. Right now you actually *can* do this, but it requires passing a 'slug' to the function like `directory/slug`. Since everywhere else in the code slugs are sanitized, this seems like an unexpected way to allow this functionality (I didn't realize this worked until @nacin pointed it out). Since this slug isn't actually sanitized at all, you can currently do `get_template_part( '../../../test' );` which seems rather unsafe (`get_template_part` should be able to include from outside the themes directory). I suggest sanitizing $slug and adding a third [optional] parameter that allows you to specify the directory to look in. The directory parameter should be sanitized enough to not allow it to start with a . or a / (although this more likely belongs in `locate_template()` as something done to $template_name inside the foreach). What does everyone think about this approach? How many themes do we think are currently using the $slug parameter to specify a directory? Right now the optional $name parameter is set up as a fall through, so if $slug-$name.php doesn't exist $slug.php is used. Should $directory be set up similarly ($directory/$slug-$name.php -> $directory/$slug.php -> $slug-$name.php -> $slug.php)?" aaroncampbell Next Release 18614 post_type_archive_title doesn't work when tax_query is added to wp_query wonderboymusic Template 3.2 normal normal 3.7 defect (bug) closed needs-unit-tests 2011-09-07T17:52:04Z 2013-10-09T19:51:43Z "post_type_archive_title( ) gets called by wp_title( ) on Custom Post Type archive pages To get the data for the post type object, post_type_archive_title( ) calls get_queried_object( ). This is problematic. If the query has been altered in any way (such as adding a tax_query in pre_get_posts filter), get_queried_object( ) will probably return a term, not a post type object. Hence, accessing $post_type_obj->labels will fail and their will be no title returned {{{ //old potentially broken way $post_type_obj = get_queried_object(); // new doesn't break way $post_type_obj = get_post_type_object( get_post_type() ); }}}" wonderboymusic Next Release 39038 Add support for non-split shared terms to singular term capabilities Taxonomy normal normal defect (bug) closed needs-unit-tests 2016-12-03T04:53:54Z 2017-02-26T20:17:19Z "As reported in #35614 by @kevinB, the `edit_term`, `delete_term` and `assign_term` singular capabilities only pass the `term_id` and not the `taxonomy`. For compat with installations where shared terms aren't split, we should specify the taxonomy, or trigger splitting. > As implemented in 4.7 RC, these meta capability checks accept a term_id with no taxonomy specified. This is an issue for legacy installations that have term_id != term_taxonomy_id. Taxonomy determination is now slated to fall to WP_Term::get_instance(), which will try to disambiguate but may return WP_Error. > An obvious option would to require the additional taxonomy argument following term_id. This would cause a fourth item in the $args array passed into the 'map_meta_cap' filter - a break with tradition, but not a problem for API-compliant plugins in my view." dd32 Next Release 30999 Inconsistent parameters for edited_term_taxonomy action boonebgorges Taxonomy 3.0 normal normal 4.2 defect (bug) closed needs-unit-tests 2015-01-13T09:02:35Z 2015-02-24T17:21:29Z "There are three `edited_term_taxonomy` action hooks: * in the [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/taxonomy.php#L3423 wp_update_term] function; * in the [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/taxonomy.php#L3987 _update_post_term_count] function; * in the [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/taxonomy.php#L4014 _update_generic_term_count] function. The first one provides as second parameter `$taxonomy` the taxonomy '''slug''', while the others provide the taxonomy '''object'''." ipm-frommen Next Release 19205 Orphaned categories can be created by accident wonderboymusic Taxonomy normal minor 4.0 defect (bug) closed needs-unit-tests 2011-11-08T14:12:39Z 2014-07-18T23:55:48Z "There are two ways to do that. 1. You can work on category tree from two browser windows. - In window one, delete a category - In window two, add a child to the category that has been deleted. wp_insert_term needs to check if the parent exists. 2. If you delete a couple of categories with bulk-delete, a third level child node can become orphan. wp_delete_term uses get_term to find the parent node and can retrieve cached data." dzver Next Release 16282 PHP catchable error with get_term_link and WP3.1RC2 Taxonomy 3.1 normal normal defect (bug) closed needs-unit-tests 2011-01-18T12:23:37Z 2015-09-29T21:31:33Z "I recently updated my WP Network to 3.1RC2, and suddenly the get_term_link() I was using in the footer gave me this error: PHP Catchable fatal error: Object of class WP_Error could not be converted to string It was working fine in 3.0.4" illutic Next Release 26234 "Passing array of taxonomies to the_terms() triggers ""array to string"" conversion warning" Taxonomy 2.2 normal normal defect (bug) closed needs-unit-tests 2013-11-25T14:39:59Z 2015-09-18T01:36:54Z "To duplicate in a loop, call: {{{ the_terms( get_the_ID(), array( 'category', 'post_tag' ) ); }}} I expected to output the terms for a post across multiple taxonomies. Instead, an array to string conversion warning is returned. I've narrowed this down to an inconsistency in the way caching is handled between `update_object_term_cache()` and `get_object_term_cache()`, namely that `update` handles multiple taxonomies and relationships, and `get` assumes only one taxonomy is passed. The call stack to the error looks something like: * the_terms() * get_the_term_list() * get_the_terms() * get_object_term_cache() Each of the functions in the above stack safely handles multiple taxonomies, except for `get_object_term_cache().` If `get_object_term_cache()` were fixed, `wp_get_object_terms()` would fire (which also safely handles multiple taxonomies) and `the_terms()` would work as I expected." johnjamesjacoby Next Release 19492 Problems with using wp_insert_term together with switch_to_blog Taxonomy 3.2 normal normal defect (bug) closed needs-unit-tests 2011-12-09T23:38:33Z 2015-09-20T19:43:23Z "I'm running a network of about 80 sites using WP multisite 3.2. I'm experiencing irregularities using switch_to_blog whith wp_insert_term. To test this I have disabled all plugins, and am testing on a blank page so nothing else interferes. This is the sample code: switch_to_blog(75); wp_insert_term( 'New Term','category'); restore_current_blog(); When run from most blogs it adds the new term to the desired blog and the permalink to the new term page works. But for a few of the blogs, when it runs it adds the term, but the link to the new term page throws a 404 error. Opening wp-admin and adding any new term through wp-admin fixes it. Is this related to the other term_cache bugs? " ErikStromme Next Release 25629 Taxonomy get_sql() generate incorrect query Taxonomy 3.5.1 normal normal defect (bug) closed needs-unit-tests 2013-10-18T14:32:59Z 2014-04-24T18:18:04Z "Hello, I'm using Wordpress 3.5.1 and came to an incorrectly generated query when trying to display the pages list causing no display of any page. WP is configured to run multiple sites and I'm using the administrator account. Here is the incorrect generated query : {{{ SELECT prefix_posts.* FROM prefix_posts WHERE 1=1 AND 0 = 1 AND prefix_posts.post_type = 'page' AND (prefix_posts.post_status = 'publish' OR prefix_posts.post_status = 'future' OR prefix_posts.post_status = 'draft' OR prefix_posts.post_status = 'pending' OR prefix_posts.post_status = 'private') GROUP BY prefix_posts.ID ORDER BY prefix_posts.menu_order,prefix_posts.post_title asc }}} As you can see, the ""WHERE 0=1"" cant' return anything. I bypassed this error using the diff below. Note that as of today, the error still exists in the svn trunk. {{{ Index: wp-includes/taxonomy.php =================================================================== --- wp-includes/taxonomy.php (revision 148746) +++ wp-includes/taxonomy.php (working copy) @@ -678,11 +678,27 @@ if ( empty( $terms ) ) { if ( 'OR' == $this->relation ) { - if ( ( $index + 1 === $count ) && empty( $where ) ) - return self::$no_results; + if ( ( $index + 1 === $count ) && empty( $where ) ) { + if (!empty($where)) { + $where = ' AND (' . implode("" $this->relation "", $where) . ')'; + } + else { + $where = ''; + } + + return array('join' => $join, 'where' => $where); + } + continue; } else { - return self::$no_results; + if (!empty($where)) { + $where = ' AND (' . implode("" $this->relation "", $where) . ')'; + } + else { + $where = ''; + } + + return array('join' => $join, 'where' => $where); } } }}} " xavismeh Next Release 27918 get_taxonomies() on single post type should return taxonomies registered on multiple post types Taxonomy 3.0 normal normal defect (bug) closed needs-unit-tests 2014-04-19T17:36:38Z 2015-10-14T02:16:44Z "A taxonomy registered on multiple post types is missing from get_taxonomies() when called with only one of those post types. It seems self-evident that get_taxonomies should return all of a post type's taxonomies, regardless of how they were registered. {{{ //... on init... register_taxonomy('foo', array('bar','baz'), $opts); //... in template ... // returns taxonomies registered only on 'bar', 'foo' is missing get_taxonomies('object_type'=>array('bar')); // returns 'foo' only if exact array is passed get_taxonomies('object_type'=>array('bar','baz')); }}} " johnrork Next Release 16863 get_terms hierarchical/hide_empty incompatible with include/exclude args Taxonomy 3.1 normal normal defect (bug) closed needs-unit-tests 2011-03-16T12:37:06Z 2015-01-26T17:27:27Z "{{{ $terms = get_terms('taxName', array( 'hierarchical' => true, 'hide_empty' => true, 'include' => array(1, 2, 3) )); }}} $terms will not contain a meaningful result set. In order for get_terms to process 'hierarchical' correctly it must recieve in 'include' a full list of term ids for all child terms that may have count > 0, this obviously negates the point of 'include' here. 'include/exclude' is processed at query level, 'hierarchical' is processed post query and expects the results of the query to be unfiltered. The following patch seems to fix the issue in my application, I think this approach would need to take in 'child_of' also, which I haven't done here. {{{ diff --git a/wp-includes/taxonomy.php b/wp-includes/taxonomy.php index 89532dc..2f51bea 100644 --- a/wp-includes/taxonomy.php +++ b/wp-includes/taxonomy.php @@ -1337,9 +1337,13 @@ function &get_terms($taxonomies, $args = '') { // Make sure we show empty categories that have children. if ( $hierarchical && $hide_empty && is_array($terms) ) { + + $taxTerms = !(empty($include) && empty($exclude) && empty($exclude_tree)) ? + get_terms($taxonomies) : $terms; + foreach ( $terms as $k => $term ) { if ( ! $term->count ) { - $children = _get_term_children($term->term_id, $terms, $taxonomies[0]); + $children = _get_term_children($term->term_id, $taxTerms, $taxonomies[0]); if ( is_array($children) ) foreach ( $children as $child ) if ( $child->count ) }}} " martinshopland Next Release 31118 get_terms() parameters do not respect multiple $taxonomies boonebgorges Taxonomy normal normal 4.2 defect (bug) closed needs-unit-tests 2015-01-24T19:02:59Z 2015-02-15T11:36:10Z "When passing an array of `$taxonomies` to `get_terms()`, a number of parameters only consider the first of these taxonomies: 'child_of', 'parent', 'pad_counts'. In addition, 'hierarchical' and 'pad_counts' will be forced to `false` if the first item in `$taxonomies` is non-hierarchical (eg, `array( 'post_tag', 'category' )`). As far as I can tell, the pattern of looking only at the first of `$taxonomies` comes from the original porting of category functionality to the taxonomy component. My guess is that using `$taxonomies[0]` in place of `$category` was the quickest way to do a straight port. See [5525]. No one has ever come back to clean these bits up." boonebgorges Next Release 37728 hide_empty doesn't work correctly in get_terms when no taxonomy specified boonebgorges Taxonomy 4.5 normal normal 5.3 defect (bug) closed needs-unit-tests 2016-08-19T00:42:03Z 2019-08-23T16:04:08Z "In #35495, the taxonomy argument to `get_terms` was made optional. Calling get_terms without specifying a taxonomy will return terms from all taxonomies. However, if taxonomy isn't provided, hide_empty (when true, as per default) does not work correctly. Parent terms which are empty themselves but have nonempty child terms are not returned. You can replicate this by creating an empty category with non-empty child categories. Using: `get_terms()` - won't include the category `get_terms(array('taxonomy'=>'category'))` - will include the category `get_terms(array('taxonomy'=>array('category','post_tag')))` - will include the category This is caused by the `get_terms` function in `WP_Term_Query`. `$has_hierarchical_tax` gets set to true if a single hierarchical taxonomy is passed, or multiple taxonomies with at least one hierarchical. However, if no taxonomies are passed, this never gets set to true. In this case it should be set to true, since it will at minimum include the in-built `category` taxonomy." smerriman Next Release 32044 is_object_in_term() leaks DB queries boonebgorges Taxonomy 4.1.1 normal normal 4.4 defect (bug) closed needs-unit-tests 2015-04-21T19:30:03Z 2016-08-24T09:19:49Z "`is_object_in_term()` should either use the Object Cache'd term relationships and populate the cache for next time, or not use them at all. Currently, `is_object_in_term()` reads from the cache with `get_object_term_cache()`, and falls back to `wp_get_object_terms()` - in that case, it doesn't then update the post-term relationship caches for next time. I'm not sure if `is_object_in_term()` is meant to respect object cache'd relationships or not - but right now its doing it half way. I don't quite know the history of the post-term relationships not being all that trusted (which is presumably why there is `wp_get_obejct_terms()` and `get_the_terms()` however, it seems just using the `get_the_terms` instead of `wp_get_object_terms` with have no regressions in this case, and cause the cache to be primed for 'next time'. Attached patch does just that. " joehoyle Next Release 20590 is_tax() with term parameter returns true for any taxonomy with that term Taxonomy normal minor 3.5 defect (bug) closed needs-unit-tests 2012-05-01T16:51:45Z 2012-10-18T12:59:26Z "I have two custom taxonomies, 'body' and 'operations', assigned to different custom post types. Both taxonomies contain the term 'shoulder' is_tax('operations','shoulder') returns true both when viewing the 'shoulder' archive for the taxonomy 'operations' and when viewing the archive page for the term 'shoulder' in the taxonomy 'Body-Parts' Therefore, is_tax() is returning true for the term, and ignoring which taxonomy it is in. The only way I can get it to return true only when viewing the 'shoulder' archive for 'operations' is by is_tax( 'operations', 'shoulder') && is_tax('operations') Version is 3.3.2 " petercarlill Next Release 29942 wp_get_object_terms - no caching mechanism in place - results in duplicate queries Taxonomy 4.0 normal normal defect (bug) closed needs-unit-tests 2014-10-12T16:47:12Z 2016-09-28T13:35:54Z "wp_get_object_terms() isn't caching queries which results in duplicate queries against the database. See the following debug info: {{{ SELECT t.term_id FROM hf9v_terms AS t INNER JOIN hf9v_term_taxonomy AS tt ON tt.term_id = t.term_id INNER JOIN hf9v_term_relationships AS tr ON tr.term_taxonomy_id = tt.term_taxonomy_id WHERE tt.taxonomy IN ('product_category') AND tr.object_id IN (229) ORDER BY t.name ASC include('wp-admin/edit-form-advanced.php'), do_meta_boxes, call_user_func, post_categories_meta_box, wp_popular_terms_checklist, wp_get_object_terms }}} {{{ SELECT t.term_id FROM hf9v_terms AS t INNER JOIN hf9v_term_taxonomy AS tt ON tt.term_id = t.term_id INNER JOIN hf9v_term_relationships AS tr ON tr.term_taxonomy_id = tt.term_taxonomy_id WHERE tt.taxonomy IN ('product_category') AND tr.object_id IN (229) ORDER BY t.name ASC include('wp-admin/edit-form-advanced.php'), do_meta_boxes, call_user_func, post_categories_meta_box, wp_terms_checklist, wp_get_object_terms }}} I've attached a patch that creates a cache of the database query - similar to what is being suggested in ticket #29894. " webgeekconsulting Next Release 28439 Add 'post_date' as a possible orderby argument to get_terms() Taxonomy 3.9.1 normal normal enhancement closed needs-unit-tests 2014-06-03T14:37:05Z 2015-08-26T02:25:12Z There have been a couple of times where I needed to retrieve a list of taxonomy terms ordered by the `post_date` of their applicable posts. This patch considers `post_date` as a potential `orderby` argument value in `get_terms()`. jchristopher Next Release 13949 Add a sprintf style argument to wp_list_categories() for title tag. Taxonomy normal normal enhancement closed needs-unit-tests 2010-06-17T18:01:20Z 2017-09-09T06:40:24Z "By default, wp_list_categories() will use the value of $term->description for the title tag of every link that it generates. If the argument ""use_desc_for_title"" is set to false, it will produce a string like: ""View all posts filed under $term->name"". With the inclusion of custom post_types into core, it would be wonderful to have more control over this title. The best solution that I can think of is to add a sprintf style argument which will allow themes and plugins to provide a custom format. Something like: 'title_format' => 'View all tacos posted under %s.' " mfields Next Release 30415 Add alternative to get_category_parents() that will work for any taxonomy Taxonomy normal normal enhancement closed needs-unit-tests 2014-11-20T08:46:10Z 2016-09-27T12:29:43Z "The {{{get_category_parents()}}} function is, as the name suggests, limited to only fetching the parents for the {{{category}}} taxonomy. It would be great if we had the same function available for any specified taxonomy to use. My suggested patch (attached) adds a new function, {{{get_term_parents()}}}, which is a direct copy of the existing function, but with an added {{{$taxonomy}}} parameter so you can use it for any given taxonomy. I have then updated the original {{{get_category_parents()}}} to simply be a wrapper for this new function, so it is fully backwards compatible. The only modification to the original function (aside from some coding standards updates) is the addition of an {{{is_taxonomy_hierarchical()}}} check, which now becomes necessary." hlashbrooke Next Release 18778 Add filters to transform_query() to allow caching of queries created by this function. Taxonomy normal normal enhancement closed needs-unit-tests 2011-09-26T12:02:08Z 2015-08-26T02:40:15Z [https://core.trac.wordpress.org/browser/trunk/wp-includes/taxonomy.php#L749 transform_query()] works great on regular datasets, but if you run this on a large set of data it can get very expensive. adding some filters in here that could allow these queries to be cached would be benefitial. tott Next Release 11058 Add unregister_taxonomy_for_object_type() nacin Taxonomy normal normal 3.7 enhancement closed needs-unit-tests 2009-11-01T10:39:26Z 2016-03-08T14:18:58Z There should be a function that unregisters a certain taxonomy after it has been registered. scribu Next Release 27764 Allow the_terms() and get_the_terms() to accept an array of taxonomies Taxonomy 3.8.2 normal normal enhancement closed needs-unit-tests 2014-04-11T18:35:53Z 2015-09-18T01:36:16Z "The '''the_terms()''' can accept array of taxonomies (several taxonomies) but the phpDocs say it can accept only a string (one taxonomy). This wrong documentation could save me a lot of time. I fix the documentation in the code for other developers. See the attached file. After the ticket will be accepted, i will fix the Codex." ramiy Next Release 19780 Named category functions/docs need cleaning up Taxonomy normal normal enhancement closed needs-unit-tests 2012-01-08T22:22:20Z 2015-09-02T02:22:41Z "Spawning from a small discussion in #19776, I think it's about time something is done to deal with the older named category functions such as `wp_category_dropdown` and `wp_list_categories` in category-template.php These functions aren't technically category-only as they accept a set $taxonomy. And because they are actually taxonomy-agnostic, I think we have a few different routes we can take to clean up after ourselves a bit: A) Lock down these functions to 'categories'-only in favor of new, taxonomy-agnostic ones. B) Leave the functions alone but let the inline-docs and hard-coded strings such as 'No Categories' reflect their versatility. e.g. 'No Terms' vs 'No Categories'. C) Deprecate these older functions in deference to newer, taxonomy-agnostic ones." DrewAPicture Next Release 25284 Support tax queries using term_taxonomy_id without specifying a taxonomy wonderboymusic Taxonomy normal normal 4.0 enhancement closed needs-unit-tests 2013-09-11T21:16:36Z 2014-09-10T21:50:01Z Taxonomy queries using `term_taxonomy_id` don't actually check to see if the terms exist in the specified taxonomy. So long as an existing taxonomy is used, it allows you to query across multiple taxonomies in one segment of the query. We should officially support not specifying a taxonomy if using term_taxonomy_id as the field, and do the magic to make include_children work. helen Next Release 52710 Taxonomy: Make it possible to bypass automatic caching of results in `get_terms()` spacedmonkey Taxonomy 2.3 normal normal 6.4 enhancement closed needs-unit-tests 2021-03-04T00:37:17Z 2023-11-01T15:08:11Z "With a few exceptions, every call to `get_terms()` places the query results in the object cache for 24 hours as part of `WP_Term_Query::get_terms()`. The query results are cached under a key that is based on the `last_changed` cache value for the `terms` cache group, such that whenever `last_changed` changes, all cache entries become stale. Many different events can bump the `last_changed` time for terms, including creating, updating, or deleting terms, or changing the terms assigned to a post. For busy sites (even not-so-busy ones), these events happen many times a day, if not many times an hour. The chances of any cached term results surviving for 24 hours without being made stale is basically zero. For sites that are behind a full-page HTML cache, the chances of a request reaching WordPress such that the cached term results can be reused before they're made stale are also somewhat small. Lastly, larger sites are likely to have implemented their own query caching in ways that are optimized for their use cases and that make core's caching redundant. For these sites, the result is a heap of unreachable cache entries waiting to expire or be evicted. The goal of this ticket is to give developers a way to prevent the caching from occurring. The attached patch proposes a boolean `update_get_terms_cache` parameter for `get_terms()` and `WP_Term_Query::get_terms()` (so named for the cache key prefix). When `false`, caching is skipped. The parameter can be set on a per-query basis or made `false` by default via the `get_terms_defaults` filter. That's one idea, and I'm open to any others that might gain a consensus. For example, the cache TTL could be made into a parameter. So could the `cache_group`, allowing developers to direct the results into a non-persistent group. " dlh Next Release 35886 get_term_parents function instead/inside get_category_parents Taxonomy 4.4.2 normal normal enhancement closed needs-unit-tests 2016-02-20T11:34:06Z 2016-09-27T12:29:51Z "Simply add one more arguments in {{{ get_category_parents}}} function for getting custom taxonomy parents. It can be like this: {{{#!php function get_taxonomy_parents( $id, $taxonomy = 'category', $link = false, $separator = '/', $nicename = false, $visited = array() ) { $chain = ''; $parent = get_term( $id, $taxonomy ); if ( is_wp_error( $parent ) ) return $parent; if ( $nicename ) $name = $parent->slug; else $name = $parent->name; if ( $parent->parent && ( $parent->parent != $parent->term_id ) && !in_array( $parent->parent, $visited ) ) { $visited[] = $parent->parent; $chain .= get_taxonomy_parents( $parent->parent, $taxonomy, $link, $separator, $nicename, $visited ); } if ( $link ) $chain .= 'term_id ) ) . '"">'.$name.'' . $separator; else $chain .= $name.$separator; return $chain; } }}} So developers can use it for getting any taxonomy parents. The possible problem is: The given taxonomy is not Hierarchical. The solution is checking taxonomy by {{{is_taxonomy_hierarchical( $taxonomy )}}} and return false if it is not. " hosein71 Next Release 24948 wp_delete_term() Shouldn't delete other default terms Taxonomy 3.1 normal minor enhancement closed needs-unit-tests 2013-08-05T00:26:10Z 2013-09-20T21:31:00Z When we create a custom taxonomy with default term, it can be deletable by wp_delete_term() because it controls only category`s default term to prevent delete. I think wp_delete_term() should control all taxonomy default terms, or at least there should be a pre_delete_taxonomy hook to stop the deletion. ecabuk Next Release 28688 wp_get_object_terms - orderby boonebgorges Taxonomy normal normal 4.2 enhancement closed needs-unit-tests 2014-06-30T08:11:23Z 2015-01-18T19:04:45Z "actually its only possible to sort the object_term-list by following args: - term_id - slug - name - term_group - term_order - count - none It would be helpful to add the following missing fields to orderby: - parent - taxonomy - term_taxonomy_id " ChriCo Future Releases 38243 Attempting to create a term with invalid UTF8 characters creates a blank term Taxonomy normal normal Future Release defect (bug) new needs-unit-tests 2016-10-06T13:52:37Z 2019-04-01T17:41:28Z "Attempting to insert a term which contains invalid UTF8 characters will incorrectly create a term in the database with a blank name & slug. This happens as we check that the term name & slug is provided, but fail to check after sanitizing the term. In the scenario that I've run into, something similar to this happens: {{{ $term_name = urldecode( ""360%BF"" ); // Invalid UTF8 character wp_insert_term( $term_name, 'my_taxonomy' ); }}} What this causes is * the checks on `$name` to pass * it then hits `sanitize_term()` and after passing through `sanitize_text_field()` and then `wp_check_invalid_utf8()` the `name` field of the term is set to an empty string. * `wp_insert_term()` then takes this empty name and creates an equally empty slug from it. * `wp_insert_term()` then calls `get_terms( array( 'name' => '' ) )` and needlessly & badly loads up all 60,000 terms into memory of the custom taxonomy * `wp_insert_term()` then see's an empty slug and ultimates settles on a setting the slug to the numeric ID of the term somehow * `wp_insert_term()` finally inserts a term with a numeric slug and empty `name` field I think at a minimum, we should verify that the term name is still valid after term sanitisation. See patch for that." dd32 Future Releases 46010 "Auto-generated term slugs can be greater than 200 characters, giving ""Could not insert term into the database."" error" Taxonomy normal normal Awaiting Review defect (bug) new needs-unit-tests 2019-01-16T14:37:23Z 2019-01-16T16:31:12Z "When a slug is not user defined, WordPress attempts to generate it from the term name within `wp_insert_term`. If the slug exists, when inserting subcategories, WordPress prefixes the slug with the top level term name. https://core.trac.wordpress.org/browser/tags/5.0.2/src/wp-includes/taxonomy.php#L2093 Because of this, long term names can go over the slug length limit and error. WordPress admin simply shows: > Could not insert term into the database. There is no reasoning provided, and when using wp_insert_term programatically it's hard to know what's at fault. This issue is more apparent when using cyrillic characters since they are stored encoded in the DB. Take ""Категория на продукта"" as an example. In the database this gets stored as: {{{ %d0%ba%d0%b0%d1%82%d0%b5%d0%b3%d0%be%d1%80%d0%b8%d1%8f-%d0%bd%d0%b0-%d0%bf%d1%80%d0%be%d0%b4%d1%83%d0%ba%d1%82%d0%b0 }}} This is 116 characters. The maximum allowed slug length defined in the wp_terms database schema is 200 characters. Steps to reproduce: - Add a top level category ""Категория на продукта"" - Add another ""Категория на продукта"" term as a subcategory of ""Категория на продукта"" - See error This is what WordPress attempted to insert into the database: {{{ ( [name] => Категория на продукта [slug] => %d0%ba%d0%b0%d1%82%d0%b5%d0%b3%d0%be%d1%80%d0%b8%d1%8f-%d0%bd%d0%b0-%d0%bf%d1%80%d0%be%d0%b4%d1%83%d0%ba%d1%82%d0%b0-%d0%ba%d0%b0%d1%82%d0%b5%d0%b3%d0%be%d1%80%d0%b8%d1%8f-%d0%bd%d0%b0-%d0%bf%d1%80%d0%be%d0%b4%d1%83%d0%ba%d1%82%d0%b0 [term_group] => 0 ) }}} The slug is too long. We either need error checking for this, or we need to truncate the slug length to avoid the issue and keep slug < 200 chars." mikejolley Future Releases 50568 Improve WP_Term's sanitization calls Taxonomy 5.5 normal normal Future Release defect (bug) new needs-unit-tests 2020-07-06T07:04:45Z 2024-03-12T17:49:50Z "Akin to `WP_Post::filter()`, I think `WP_Term::filter()` should have a bypass, too. This will significantly improve performance wherever terms are used (list edit screens, category widgets, blocks) because the bypass prevents redundant re-sanitization. The attached patch will shave off a 30% load time at `wp-admin/edit.php` after #50567's implementation. This patch tests for the `WP_Term` object's `::$filter` state, and only re-sanitizes the term when the state differs from the input argument. You'll also find that `sanitize_term()` now looks a lot like `sanitize_post()`--the same goes for `get_term()`'s resemblance to `get_post()`. Overall, it seems posts have received a lot more love over the years, and this patch steals some of that. There are a few issues with terms, however. For example, `update_term_cache()` caches terms regardless of being shared, while `WP_Term::get_instance()` tries to prevent that. The `$filter = 'display'` argument is used in contexts where `raw` would do fine, too (e.g. @ `WP_Terms_List_Table::single_row()`). If we iron those issues out, we can fully phase out the re-sanitization of terms." Cybr Future Releases 49799 get_the_terms() object term cache check too strict? Taxonomy 2.3 normal normal Awaiting Review defect (bug) new needs-unit-tests 2020-04-03T15:24:05Z 2020-04-16T05:58:55Z "I ran into a weird issue when doing integration tests on one of a client's project. I was setting up custom post and custom taxonomy from the factory (for posts I used the default one, and for custom taxonomy I have created my own factory that extends `WP_UnitTest_Factory_For_Term`), set everything up, but the part of the plugins code that used `get_the_terms` returned nothing. So after racking my brains, I tried `wp_get_post_terms`, and lo and behold, this worked (the test posts had assigned terms for them, I checked before invoking my function I needed to test using `get_the_terms`). So something was up with caching. I started to dig and it turned out that {{{#!php $terms = get_object_term_cache( $post->ID, $taxonomy ); }}} inside `wp-includes/category-template.php` returned an empty array. Now, since the line 1246 says {{{#!php if ( false === $terms ) { }}} The empty array, while being a ''falsy'' value, it's not a `false` value (https://3v4l.org/RVuG7), so the above check will return false and the returned value from the `get_the_terms` function will be `false`. So when I 'loosened' the condition in my test suite WP, the `$terms = wp_get_object_terms( $post->ID, $taxonomy );` works, and I get my terms inside the tests. If the condition is loosened, nothing seems to be lost in terms of checking the emptiness of the terms from the term object cache (if it's full, it's `false` all the times https://3v4l.org/34UQk). Now, on the face value, this could be the oddity of the test suite (which in my case is set up using wpcli scaffold command), but I'm thinking that changing this requirement cannot hurt (from what I can tell) in the long run. " dingo_d Future Releases 58404 Add pre_update_term filter hook Taxonomy normal normal Future Release enhancement new needs-unit-tests 2023-05-25T10:13:14Z 2023-09-25T22:52:28Z "Hi In file: {{{ wp-includes/taxonomy.php }}} In function: {{{ wp_update_term }}} How can to validate a custom term before updated? A filter needs here like pre_insert_term in wp_insert_term() functin. I think this filter has been forgotten in here. {{{ $term = apply_filters( 'pre_edit_term', $term, $taxonomy, $args ); }}} " kobi1 Future Releases 53319 "Add support for a ""reverse"" argument in get_term_parents_list() function" Taxonomy normal normal Future Release enhancement new needs-unit-tests 2021-06-02T10:36:36Z 2023-07-26T02:14:13Z "Please bare with me, I probably do everything wrong since it is my first Trac Ticket involving code. --- Recently I used `get_term_parents_list()` to create a list of hierarchical terms. I noticed that by default the function outputs the terms like so: `Parent Category/Child Category/Grandchild Category` I could not find any argument or way to invert that order, with the goal to display the terms like so: `Grandchild Category/Child Category/Parent Category` This is useful for example if we have Geographic zones and the utmost parent is a Country, the utmost child an area. In that case we may want to display Area/Region/Country which looks like an address structure rather than the opposed which is the default I don't think it should be too hard adding this new argument to the function. I have uploaded a file with the modified function and updated code comment to the ticket. I also tested my changes on a existing install and can confirm this introduced no unexpected issues. It would be awesome to see if we can add this tiny change in future release." bedas Future Releases 38310 "Improve ""wp_update_term"" documentation" ruudjoyo Taxonomy 4.7 normal normal Future Release enhancement reopened needs-unit-tests 2016-10-14T10:10:06Z 2021-09-29T05:26:16Z "Hi all, When using the wp_update_term function and reading through its inline docs, it struck me that some part of the inline docs is kind of vague (highly subjective, I know). I will add a patch with a proposal for a more specific inline docs. Thanks, Ruud" ruud@… Future Releases 45107 Taxonomies should only be allowed to support one object type Taxonomy normal normal Awaiting Review enhancement new needs-unit-tests 2018-10-17T16:48:28Z 2019-02-12T21:00:32Z "Currently, taxonomies can be registered to any object type (posts, comments, users, etc.). But core does not enforce a one to one limit for object types to taxonomies, which can be problematic. For example, if a taxonomy is registered to both users and posts, there can be unintended consequences. Adding a term to a post with an ID of 3 would also cause a user with an ID of 3 to have that term. Removing that term from the user would also affect the post. Unique IDs are only enforced on a per object type basis, not accross all types. The approach here would be to introduce a `_doing_it_wrong()` notice (and possibly even return a `WP_Error`) when a taxonomy is registered to multiple object types. **Good:** `register_taxonomy( 'custom_tax_name', array( 'post', 'page', 'cpt' ) );` **Bad:** `register_taxonomy( 'custom_tax_name', array( 'post', 'user' ) );` == Why == Adding this to Core would open the door for the following potential features: - `WP_Tax_Query` support could be added to users (see #31383), comments, etc. - Built-in fields for taxonomy could be added to the REST API for users, comments, etc. - UIs could be added for users (also see #31383), comments, etc. == Backward Compatibility == To continue supporting backward compatibility for sites that are registering a taxonomy for multiple object types, `register_taxonomy()` could continue working as is. The only change would be to return a `WP_Error` and a `_doing_it_wrong()` notice. In the future, `register_taxonomy()` could be changed to only register objects with the same type as the first specified object type. Example: `register_taxonomy( 'custom_tax_name', array( 'post', 'user', 'page' ) );` would only register the taxonomy for posts and pages (same object type)." desrosj Future Releases 36641 WP_Term method __toString Taxonomy normal normal Awaiting Review enhancement new needs-unit-tests 2016-04-22T20:59:58Z 2017-02-05T14:18:20Z "I think that this is good idea. For example: {{{#!php '; var_dump(implode(', ', get_the_terms( get_the_ID(), 'category' ))); echo ''; ?> }}} I have ```string(**) ""Cat 1, Cat 2""``` " sebastian.pisula Future Releases 40661 WP_Term_Query->parse_query() needs filter like 'get_terms' Taxonomy normal normal Awaiting Review enhancement new needs-unit-tests 2017-05-04T10:28:28Z 2017-08-04T17:50:55Z "The new class/method WP_Term_Query->parse_query() does not provide a filter like the old function get_terms() does. Using WP_Term_Query directly has thus different functionality from using the old wp_terms function. Using a plugin like: https://wordpress.org/support/plugin/custom-taxonomy-order-ne/ with a custom term_order field and sorting based on that, gives the default sort based on name. Adding a filter to the method like get_terms, provides backwards compatibility for plugin and theme authors, that are switching to WP_Term_Query directly. This filter gives options to apply a custom order to the list of terms. Reference on support forum: https://wordpress.org/support/topic/doesnt-reorder-when-using-wp_term_query/ If adding a filter is somehow not wanted by core devs, then I will have to answer to add this filter manually to the code when support requests are coming. To be clear, I would consider that a valid response." mpol Future Releases 55357 Add object_id property to WP_Term class Taxonomy normal normal defect (bug) closed needs-unit-tests 2022-03-09T18:23:40Z 2022-06-22T07:41:26Z When calling `get_terms` and `WP_Term_Query` with `fields` equal to `all_with_object_id`, the array of `WP_Term` objects that are returned, also have a `object_id` property set. This property is not defined as part of the class. WordPress should not be defining dynamically properties like this. spacedmonkey Future Releases 31665 Duplicate slugs in DB, created for hierarchical terms with long, non-latin names, when the default slug already exists Taxonomy 4.1.1 normal normal defect (bug) new needs-unit-tests 2015-03-17T10:43:33Z 2019-06-04T21:14:42Z "When WP automatically generates a slug for a child term, and if the produced slug (which is normally generated just from the term's name) already exists in that taxonomy, it forms a slug by concatenating all the parent terms' slugs hierarchically For example, in a term structure like: Parent -Child If a term with the name ""Grandchild"" is to be inserted under ""Child"", normally it would get the slug ""grandchild"". However if that slug already exists in the taxonomy, WP generates the slug ""parent-child-grandchild"". When the slugs have long, non-latin names, they are stored urlencoded in wp_terms, and the stored string's length can easily overflow the field's size ( varchar(200) ). Any terms created under that condition end up having the same slug stored in the DB (the produced urlencoded one, truncated to 200 chars). To reproduce the issue: Create a term (e.g. category) with this name (without the quotes): ""Ένα δύο τρία τέσσερα πέντε"" Create another term with the same name, defining the first term as its parent. Create a third term with the same name, defining the second term as its parent. The second and third terms end up having duplicate slugs in the DB, a situation which is normally an error. This issue is also not detected if the same procedure is repeated using wp_insert_term(). Normally an attempt to insert a duplicate slug to the same taxonomy would raise a ""duplicate_term_slug"" WP_Error, which is not the case." nevma Future Releases 16101 Numeric term fields are strings Taxonomy normal normal defect (bug) new needs-unit-tests 2011-01-04T23:25:00Z 2020-11-10T16:15:04Z "The numeric fields (term_id, parent, etc.) on term objects are strings. I only noticed this because term_exists() uses is_int() to determine if the $term value is an ID or slug. Only ticket I could find about this is #5381. sanitize_term() should fix this, but it bails early in the ""raw"" context. sanitize_term_field() sanitizes the numeric fields in every context. I don't see a reason for sanitize_term() to bail early so I made a patch that takes that out. The patch also adds some missing fields to the list of those to be sanitized and changes term_exists() to use is_numeric() (which will correctly identify strings containing only numbers) instead of is_int(). " foofy Future Releases 31270 Unexpected slugs for same-title different-parents term creation boonebgorges Taxonomy 4.1 normal normal defect (bug) assigned needs-unit-tests 2015-02-09T03:35:53Z 2019-06-04T21:13:57Z "When creating a new term which matches an existing terms name, it uses that slugs slug as the slug prefix, which can result in an unexpected term slug. For example, take this: {{{ Foo (slug: foo) - Bar (slug: foo-bar) }}} If we now create a root level ""Bar"" term, it'll get a slug of {{{foo-bar-2}}}, when one would expect it to receive {{{bar}}} since no conflicting slug exists. This is related directly to [28733] / #17689. Unit test attached showing behaviour." dd32 Future Releases 41373 WordPress 4.8 and WPML returns NULL on retrieve of translated slugname. Only ID works Taxonomy 4.8 normal normal defect (bug) closed needs-unit-tests 2017-07-20T08:18:06Z 2019-02-21T02:44:22Z "Hi There are mayor issues with wp 4.8 and wpml, polylang or any other multilanguage plugin. Since wp 4.8 the shortcode executed in the translated page is not calling the translated category anymore I have one category for my custom post type ""portfolio"" called ""gallery"" the category is translated to ""gallerij"" for the dutch language. They both have 3 posts attached. Each for their own language. I have this in my english page. `[portfolio category=""gallery""]` calling the posts from the category gallery and it is showing 3 posts. The page is duplicated into Dutch but the shortcode is the SAME. So the dutch page also has `[portfolio category=""gallery""]` and NOT `[portfolio category=""gallerij""]`. So the dutch page is calling the English category. Now in wp 4.7.x this works perfectly and the dutch page shows the dutch portfolio items, or if you use a blog shortcode the blog items for each language. But the moment wp 4.8 is installed the dutch pages with shortcodes are empty and i need to set the Dutch page with the shortcode to translated independently and change the shortcode manually to `[portfolio category=""gallerij""]` so that it is calling the dutch category called ""gallerij"" What changed in the wp code? The theme i am using did not change the theme code. Moreover it happens in any theme i try. The return is NULL when calling a slugname. I tested this 3 x times now in a clean wp install on my local host and i get similar results all the time. The moment i revert to wp 4.7 there is no issue. If i activate wp 4.8 the issue occurs and the translated page is empty not showing any portfolio or blog items. Note : i tested this in my local host and was able to reproduce the same issue over and over again by reverting back and forth to wp 4.7.4 and 4.8. Note : the categories are synchronized !! There is no issue in using the settings wrong or whatever. in wp 4.7.x this {{{#!php term_id; echo 'term-id :'.$term_id; }}} returns the id of the translated category in the translated page. in wp 4.8 and above it returns 0 for that category in the translated page but the correct id in the page with primary original language. So there are two faillures here. The get_term_by fails but also the query fails... see previous reply. They both return nothing when wp 4.8 is used. $cat a list of category slugnames in the original default language {{{#!php 'category', 'field' => 'slug', 'terms' => explode(',', $cat) ) ); $r = new WP_Query($query); }}} $cat has the slugname(s) selected separated by a ',' I reported this to wpml, https://wpml.org/forums/topic/translated-category/ but further testing learned that it happens in any multilanguage plugin so it must be a wp issue. As said it does not happen in wp 4.7.x or below. The solution provided for wpml does not work for me as all users have already generated shortcodes that use the slugnames, but more over these slugnames are used to filter the items by ajax filtering. its a big problem and serious bug. Pls provide a fix." BackuPs Future Releases 15806 get_terms with hide_empty returns count > 0 with unpublished items Taxonomy 3.0 normal normal defect (bug) closed needs-unit-tests 2010-12-14T00:24:21Z 2019-06-04T21:06:14Z "Hi, I ''think'' that's a bug. I've defined a custom post type and a custom category taxonomy for it. On my front end, i'm using get_terms with hide_empty to show the categories of the existing custom post type. get_terms does ignore unpublished posts but it seems to include trashed item. I have one category that is linked to only a trashed item and the function includes it in the count. I can't select 3.0.3 in the version dropdown but it happened on any 3.0.x that I tried. " bendog Future Releases 37276 tax_query with field=name doesn't work if the term contains an apostrophe Taxonomy normal normal defect (bug) closed needs-unit-tests 2016-07-04T21:24:28Z 2019-02-21T03:18:19Z "Related to the bug in #27810. If you create a tax_query with field=name and term containing an apostrophe, eg: {{{ new WP_Query(array( 'tax_query'=>array( array( 'taxonomy'=>'sample-tax', 'field'=>'name', 'terms'=>""Test's"" ) ) )); }}} the query built in the transform_query function in class-wp-tax-query.php comes back with: `... AND wp_terms.name IN ('Test\\\'s')` and thus generates no results. It looks like the apostrophe is getting double escaped by both the `esc_sql` and `sanitize_term_field` calls in @boonebgorges patch. Stab in the dark - in `wp_insert_term`, `wp_unslash` is called on the name field after sanitizing it - does the same need to apply here?" smerriman Future Releases 32789 Abstract get_category_by_path into get_term_by_path Taxonomy normal normal enhancement new needs-unit-tests 2015-06-25T15:59:01Z 2019-06-04T21:15:41Z "Having a function like `get_term_by_path` would be great as currently you have to fork the `get_category_by_path` function on your own to get a term by path for any other custom taxonomy. Would there be any opposition to a patch for this? The abstracted function wouldn't house the `_make_cat_compat` usage, which would remain in the backwards compatible `get_category_by_path` function after checking to see if $category is not null." sc0ttkclark Future Releases 30705 Add parameter to get_the_term_list() to allow templating Taxonomy 2.5 normal normal enhancement new needs-unit-tests 2014-12-13T21:32:57Z 2019-06-04T21:13:09Z "Similar to #27238 the parameter $term_template is suggested to allow for user created formatting for get_the_term_list(), as opposed to the previous standard of simply linking to each list in the term. The reasoning for the change is that general linking is not always the desired action for displaying term lists. The method for inclusion is similar to [30209]." davidjlaietta Future Releases 36978 Add pre filter to get_term_by Taxonomy normal normal enhancement new needs-unit-tests 2016-05-30T22:25:13Z 2019-06-04T21:23:44Z Like other get get_*_by functions the get_term_by should have a pre filter. This filter should specially be useful to short-circuit the default logic, perhaps to add caching. spacedmonkey Future Releases 23422 Add query filter argument to register_taxonomy Taxonomy normal normal enhancement new needs-unit-tests 2013-02-08T12:38:35Z 2019-06-04T21:08:16Z "Following on from the #21240 ticket which introduced the show_admin_column functionality I would like to suggest an additional argument to easily add the select list query filter for a taxonomy to the post-type list. Currently a taxonomy query can be added via the 'restrict_manage_posts' action and 'parse_query' filter. It would be useful to add an additional register_taxonomy argument of 'show_column_filter' to define a standard select option list of the taxonomy terms. Things like default option and hierarchy could be optional settings is an array is passed instead of boolean. " tifosi Future Releases 33975 Improve capabilities management when registering custom taxonomy Taxonomy normal normal enhancement new needs-unit-tests 2015-09-23T12:02:12Z 2019-06-04T21:17:04Z "Currently we have such caps when using `register_taxonomy()` [https://codex.wordpress.org/Function_Reference/register_taxonomy#Arguments codex]: {{{ 'manage_terms' - 'manage_categories' 'edit_terms' - 'manage_categories' 'delete_terms' - 'manage_categories' 'assign_terms' - 'edit_posts' }}} IMO, setting `manage_terms` to false block access to page (cheating message), setting `edit_terms` to false displays this message: ""You are not allowed to edit this item."", which is very odd. Editing means editing, So I should not be able to use Quick Edit and Edit links (they should be hidden). Also, I propose to add a `create_terms` capability maping - for displaying the add term form and giving ability to create them, separately from editing/deleting. Related: #22511" slaFFik Future Releases 24386 Make _pad_term_counts work for non-post type objects and attachments Taxonomy normal normal enhancement new needs-unit-tests 2013-05-22T18:23:31Z 2020-11-05T15:55:22Z "If you register a hierarchical taxonomy against a non-post object (such as users), or attachments that aren't associated with another post, _{{{pad_term_counts}}} does bubkus, due to the INNER JOIN on {{{$wpdb->posts}}}, and the check for 'publish' status (which is relevant for attachment post types). I'm suggesting an alternative approach would be to use $term->count, and eschew going back to the database altogether." TomAuger Future Releases 36654 New function `has_terms` Taxonomy normal normal enhancement closed needs-unit-tests 2016-04-24T10:10:32Z 2023-05-25T09:54:25Z "I suggest add new function: {{{ if(has_terms('category')) { the_terms(x, 'category'); } }}} " sebastian.pisula Future Releases 36171 Proposed clean up of get_the_category_list() and link filter Taxonomy 4.4.2 normal normal enhancement new needs-unit-tests 2016-03-08T17:09:25Z 2019-06-04T21:20:57Z "The current source code of the {{{get_the_category_list()}}} function is quite messy and there is also a lot of duplicate code which we can avoid. Also, on a micro optimization level, in stead of passing the category ID to {{{get_category_link()}}}, we can pass the whole category object. Doing this will avoid the extra overhead of having to get the complete category object from the term cache. There is also no filter to filter each category link on category level, we only have the {{{the_category}}} filter which filters the string of links. We have being receiving a couple of questions on wordpress.stackexchange.com regarding filtering these category links according to category. [http://wordpress.stackexchange.com/q/219554/31545 Here] is such one question. My proposal is included in my code, a filter called {{{the_category_list_links}}} which we can use to filter each category link individually according to the category. One such use-case of the filter can look something like {{{ add_filter( 'the_category_list_links', function ( $the_link_list, $category, $cat_parents ) { $category_color = get_field( 'category_color', $category ); if ( !$category_color ) return $the_link_list; $the_link_list = str_replace( 'using_permalinks() ) ? 'rel=""category tag""' : 'rel=""category""'; $links = array(); foreach ( $categories as $category ) { /** * Break the link for better link building */ $start_link = 'term_id ) ) . '"" ' . $rel . '>'; $end_link = $category->name . ''; /** * Build the category links */ $the_link_list = ''; switch ( strtolower( $parents ) ) { case 'multiple': $cat_parents = $category->parent ? get_category_parents( $category->parent, true, $separator ) : ''; $the_link_list = $cat_parents . ' ' . $start_link . $end_link; break; case 'single': $cat_parents = $category->parent ? get_category_parents( $category->parent, false, $separator ) : ''; $the_link_list = $start_link . $cat_parents . $end_link; break; case '': default: $the_link_list = $start_link . $end_link; } /** * Filter the category links on category level. * * @since X.X.X * * @param string $the_link_list Post category link. * @param object $category The current category object * @param $cat_parents Link list of parents of the current category */ $links[] = apply_filters( 'the_category_list_links', $the_link_list, $category, $cat_parents ); } $thelist = ''; if( '' === $separator ) { $thelist .= '
    '; $thelist .= ""\n\t
  • ""; $thelist .= implode( ""
  • \n\t
  • "", $links ); $thelist .= '
  • '; $thelist .= '
'; } else { $thelist .= implode( $separator, $links ); } /** * Filter the category or list of categories. * * @since 1.2.0 * * @param array $thelist List of categories for the current post. * @param string $separator Separator used between the categories. * @param string $parents How to display the category parents. Accepts 'multiple', * 'single', or empty. */ return apply_filters( 'the_category', $thelist, $separator, $parents ); } }}}" pietergoosen Future Releases 29586 Sync get_the_category_list with get_the_term_list Taxonomy 2.5 normal normal 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 '

ID . '"">
' . $title . '
' . apply_filters( 'editable_slug', $post->post_name ) . '
' . $post->post_author . '
' . esc_html( $post->comment_status ) . '
' . esc_html( $post->ping_status ) . '
' . esc_html( $post->post_status ) . '
' . mysql2date( 'd', $post->post_date, false ) . '
' . mysql2date( 'm', $post->post_date, false ) . '
' . mysql2date( 'Y', $post->post_date, false ) . '
' . mysql2date( 'H', $post->post_date, false ) . '
' . mysql2date( 'i', $post->post_date, false ) . '
' . mysql2date( 's', $post->post_date, false ) . '
' . esc_html( $post->post_password ) . '
'; if ( $post_type_object->hierarchical ) echo '
' . $post->post_parent . '
'; if ( $post->post_type == 'page' ) echo '
' . esc_html( get_post_meta( $post->ID, '_wp_page_template', true ) ) . '
'; if ( post_type_supports( $post->post_type, 'page-attributes' ) ) echo '
' . $post->menu_order . '
'; $taxonomy_names = get_object_taxonomies( $post->post_type ); foreach ( $taxonomy_names as $taxonomy_name) { $taxonomy = get_taxonomy( $taxonomy_name ); if ( $taxonomy->hierarchical && $taxonomy->show_ui ) { echo '
ID . '"">' . implode( ',', wp_get_object_terms( $post->ID, $taxonomy_name, array( 'fields' => 'ids' ) ) ) . '
'; } elseif ( $taxonomy->show_ui ) { echo '
ID.'"">' . esc_html( str_replace( ',', ', ', get_terms_to_edit( $post->ID, $taxonomy_name ) ) ) . '
'; } } 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 ` }}} " mouhdev Future Releases 56105 Call update_post_parent_caches in the_post function in WP_Query class Query normal normal Awaiting Review enhancement new needs-unit-tests 2022-06-30T12:01:38Z 2023-04-20T12:55:57Z "Hello Team, In {{{the_post}}} function {{{class WP_Query}}}, {{{update_post_author_caches}}} is already in use but not {{{update_post_parent_caches}}}. I am not sure if it is because of {{{update_post_parent_caches}}} calls the private function {{{_prime_post_caches}}} or what." priyankkpatel Future Releases 57416 Do not split query if requesting one post spacedmonkey Query 3.0 normal normal Future Release enhancement assigned needs-unit-tests 2023-01-03T13:49:30Z 2023-11-16T12:36:42Z When using WP_Query and requesting posts_per_page = 1, there is little to no value in splitting the query and priming posts using _prime_post_caches. This results in one query to get the posts and another to prime it. This means two database queries when this could simply be one. spacedmonkey Future Releases 39447 Improvement to the get_the_posts_navigation SergeyBiryukov Query normal normal Future Release enhancement reviewing needs-unit-tests 2017-01-03T14:36:31Z 2021-01-27T06:28:38Z "[https://core.trac.wordpress.org/browser/tags/4.7/src/wp-includes/link-template.php] Here at ''get_the_posts_navigation'' the function check global wp query('''Globals['wp_query'\]''') for displaying markup. But in many cases we may need to display the navigation for '''custom wp query''' which has unique query options(max_num_page, post_per_page). So it would be great, if we can check the our custom query's max_num_page. Hope it make sense. Thank you " thirumani02 Future Releases 41678 Make sure all field returns use filters in WP Query Query 1.5 normal normal Awaiting Review enhancement new needs-unit-tests 2017-08-20T13:01:32Z 2023-04-20T13:19:18Z Currently if fields is set to either `id` or `id=>parent`, it doesn't run through all the filters as these return early. spacedmonkey Future Releases 19653 Order by meta field forces ignore of null records Query normal normal Future Release enhancement new needs-unit-tests 2011-12-23T15:11:45Z 2019-03-29T18:34:21Z "When doing a sort on posts with a meta value, the way the SQL is currently generated in meta.php creates a condition where records that DO NOT have the queried meta value are excluded from the results. This may or may not be the desired behaviour, but we don't give developers the choice without resorting to custom queries or manual rewrites of large swathes of the $clauses array. The issue: the way WP_Meta_Query->get_sql() creates the join on the meta key is by setting an inner join on wp_postmeta and then adding the key test to the where clause. I would suggest writing an outer (left) join on wp_postmeta, with the key condition in the join. This would also eliminate any potential future ambiguity if, for example, you are sorting on one meta key but filtering on another, since the key condition would be within the join clause, not the where clause: {{{ LEFT JOIN wp_postmeta ON wp_posts.ID = wp_postmeta.post_id AND wp_postmeta.meta_key = 'my_custom_field_name' }}} Related to ticket #18158 is the question of how we expose this to the developer in the query API. {{{ 'meta_key' => self::get_meta_key( 'my_custom_field_name' ), 'orderby' => 'meta_value', 'exclude_empty_meta' => false }}} If this gets any traction I would be happy to submit a patch." tomauger Future Releases 35907 Permit sticky posts to affect the query in REST_REQUEST rmccue Query normal normal Future Release enhancement reopened needs-unit-tests 2016-02-22T23:44:13Z 2017-04-23T22:19:55Z Needed for https://github.com/WP-API/WP-API/issues/2210 danielbachhuber Future Releases 45084 WP_Term_Query multiple 'orderby' support Query normal normal Future Release enhancement new needs-unit-tests 2018-10-11T16:15:36Z 2021-03-03T20:27:19Z "Just like in the regular WP_Query it would be awesome if it supported multiple orderby values (array or space separated). I'm currently busy with a patch but the I would like some feedback and help with creating unit tests. Examples: {{{#!php 'meta_value name', 'order' => 'ASC', ); }}} {{{#!php array( 'meta_value' => 'ASC', 'name' => 'ASC', ), ); }}} " keraweb Future Releases 49149 Write tests for WP_Query Query normal normal Awaiting Review enhancement assigned needs-unit-tests 2020-01-07T22:01:10Z 2020-02-20T02:32:06Z "WP_Query is one of the most critical classes in WordPress. It holds a lot of features and complicated rules to generate the SQL queries to fetch posts from the databases. Working on bug fixes and new features for it is very tricky because one is always afraid that any change to it could silently break things and tear the world apart. One way to make us feel more secure when working with this class is to have better test coverage for it. Looking at the tests we currently have I found very few tests for this class. I've created this ticket to organize and receive patches to add tests to this class. Below I organized the WP_Query parameters we should, at first, create tests for. Once we have tests for them individually, we can think of a way to write tests that combine different parameters. {{{ * Author params * author * author_name * author__in * author__not_in * Category params * cat * category_name * category__and * category__in * category__not_in * Tag params * tag * tag_id * tag__and * tag__in * tag__not_in * tag_slug__and * tag_slug__in * Tax_query * Meta_query * date_query * post_mime_type * fields * name * page_id * pagename * post_parent * post_parent__in * post_parent__not_in * post__in * post__not_in * post_name__in * has_password * post_password * post_type * post_status * comment_count * nopaging * posts_per_page * offset * paged * ignore_sticky_posts * order and orderby paramaters }}} PS - what motivated me to open this ticket (and start working on these tests) was #48556 and #44737" leogermani Future Releases 30184 Author page and category Query 3.1 normal normal defect (bug) new needs-unit-tests 2014-10-29T19:20:41Z 2019-06-04T20:47:56Z "Got errors like next in debug.log PHP Notice: Undefined property: stdClass::$ID in /www/test1/wp-includes/query.php on line 4074 PHP Notice: Undefined property: stdClass::$nickname in /www/test1/wp-includes/query.php on line 4076 PHP Notice: Undefined property: stdClass::$user_nicename in /www/test1/wp-includes/query.php on line 4078 In wp-includes/query.php we have the method {{{ public function is_author( $author = '' ) { if ( !$this->is_author ) return false; if ( empty($author) ) return true; $author_obj = $this->get_queried_object(); $author = (array) $author; if ( in_array( $author_obj->ID, $author ) ) return true; elseif ( in_array( $author_obj->nickname, $author ) ) return true; elseif ( in_array( $author_obj->user_nicename, $author ) ) return true; return false; } }}} But if we query a author page with category param queried_object actually will be the category term object, so next patch prevent such problems {{{ public function is_author( $author = '' ) { if ( !$this->is_author ) return false; if ( empty($author) ) return true; $author_obj = $this->get_queried_object(); if ( ! is_a( $author_obj, 'WP_User' ) ) return false; $author = (array) $author; if ( in_array( $author_obj->ID, $author ) ) return true; elseif ( in_array( $author_obj->nickname, $author ) ) return true; elseif ( in_array( $author_obj->user_nicename, $author ) ) return true; return false; } }}} " dimitrov.adrian Future Releases 23309 Not all WP_Query::query_vars get updated during WP_Query::get_posts() Query normal normal defect (bug) new needs-unit-tests 2013-01-28T15:40:56Z 2019-06-04T20:43:47Z "There is a lot of logic within the WP_Query::get_posts() method that fills in missing query vars with defaults and manipulates others based on the rest of the query. However, some of the final states for many of the variables aren't updated in the WP_Query::query_vars array. For example, the post type is lost as a local variable and post_status is used for building compiling mysql expressions, but never directly updated. The result is that any plugins that want to recreate the query for another system, (ie, an external search provider) must directly copy much of the business logic that WP_Query::get_posts() has embedded in it in order to fill in for the incomplete query_var array. " prettyboymp Future Releases 30911 Overhaul post_status logic in WP_Query Query normal normal defect (bug) new needs-unit-tests 2015-01-05T15:24:11Z 2019-06-04T20:48:22Z "`WP_Query` filters based on post_status in two different places: 1. When building the main SQL query (`SELECT ID FROM $wpdb->posts`...). https://core.trac.wordpress.org/browser/tags/4.1/src/wp-includes/query.php#L2946 This block is responsible for parsing the 'post_status' query var, and rectifying these passed post_statuses with the 'perm' param, the logged-in user's permissions, and whether `is_admin()`. (The ability to query by 'post_status' dates from [5575].) 2. On `single` queries (`is_page()`, `is_single()`), additional filtering happens *after* the query. https://core.trac.wordpress.org/browser/tags/4.1/src/wp-includes/query.php#L3511 The intended purpose of this block is to ensure that Preview works (since posts being previewed generally are not published). The current incarnation of the preview logic (ie, living in `WP_Query`) was introduced in [2523]. These two 'post_status' blocks have two different purposes and two different histories, but they interact in a number of problematic ways. Just a few of the problems: a. Querying posts with 'fields=ids' means that the post ids are returned before the second filter block gets a chance to run. As a result, certain `WP_Query` objects (eg 'p=123&post_status=trash') can return different post IDs depending on whether you request 'fields=ids'. b. Values passed to the post_status parameter of `WP_Query` are sometimes overridden forcibly, based on logged-in user status. In an ideal world, `WP_Query` would not make any essential reference to the logged-in user. Realistically, we can't change some of this behavior for reasons having to do with backward compatibility. But there are places where the current user logic could be reworked so that it provides defaults, which can then be overridden by the params passed to `WP_Query`. Some relevant tickets: #28568, #29167 c. Filtering out non-previewable posts after the main query has taken place means doing more SQL queries than necessary in cases where post_status=draft and `is_single()`. d. Filtering out non-previewable posts after the main query has taken place can result in certain sorts of data leakage. See eg #30910. e. Having two separate blocks that filter results based on post_status makes unnecessarily complicated to fix post_status bugs. See eg #30530, #22001, #23309. My initial thought is that the second block should be removed. Preview logic should either be merged with the first block of post_status parsing logic that runs when building the main post query, or it should be moved into a separate query_var, which would then be passed when making a Preview request. In general, the challenge here is to ensure that the default post_status whitelist is properly sensitive to the permissions of the logged-in user - which sometimes means building clauses like `(post_status = 'publish' OR ( post_status = 'private' AND post_author = 123 ))`. I've started to write some unit tests that describe the (weird and complicated) existing behavior. See #29167 [31047]." boonebgorges Future Releases 34660 Query breaks when nopaging = false and posts_per_page = -1 Query 4.4 normal normal defect (bug) new needs-unit-tests 2015-11-11T16:06:20Z 2019-06-04T20:53:11Z "Whenever `nopaging = false` and `posts_per_page = -1`, the SQL query breaks because the LIMIT clause is set to: `LIMIT 0, -1` This patch ensures that `nopaging` is set to TRUE whenever `posts_per_page = -1`." mgibbs189 Future Releases 18513 Searching with explicit post types unsets page post type Query 3.2.1 normal normal defect (bug) new needs-unit-tests 2011-08-24T22:13:08Z 2022-02-12T20:43:32Z "Tested on WP 3.2.1, Twenty Eleven with no plugins, multisite. If I explicitly limit a search query via a GET request using an array of post_type values, the post_type for page is automatically excluded. To reproduce: * Do a search on a WP install (perhaps through a modified search form), such that the URL is like: http://example.com/?post_type[]=post&post_type[]=page&post_type[]=attachment&s=Test or http://example.com/?post_type[]=post&post_type[]=page&post_type[]=book&s=Test That's searching for ""Test"" on post, page and attachment/book post types. * Adding the following to a theme's functions.php: {{{ add_filter( 'pre_get_posts', 'wpcpt_search' ); /** * * @param array $query */ function wpcpt_search( $query ) { if ( ! $query->is_search ) return $query; print_r( $query->query_vars ); return $query; } }}} That spits out (and seemingly confirmed via the values shown in the Debug Bar plugin) the following at the beginning: {{{ Array ( [s] => Test [post_type] => Array ( [0] => post [2] => attachment ) }}} and only returns results for posts and attachments (or books). The fact that key 1 is missing makes me think that page was in the array at some point, but it's been unset, but I can't see where, or why, this might be done. (When no post_type is set, giving a post_type of 'any', which in turn gives all of the non-excluded_from_search post types, then page is one of the array values, and the search results correctly include pages.) " GaryJ Future Releases 15667 wp_list_pages, if it finds no pages to display, shows random child pages instead because of a bug in get_pages() jackreichert Query 3.0.2 normal minor defect (bug) assigned needs-unit-tests 2010-12-03T19:12:46Z 2019-06-04T20:41:37Z "How to reproduce:[[BR]] - About page is published - additionally, there is a number of parent pages[[BR]] - these each have a number of children[[BR]] - when calling wp_list_pages(), the ""exclude"" attr excludes all parent pages, and display only the About page. This works as long as there is at least 1 other page published that is not in the list of excluded IDs. In this example, as soon as the About page is set to ""draft"", wp_list_pages stops working correctly. So... with no other pages besides the excluded ones published, we do this: 1) wp_list_pages('title_li=&depth=1&exclude=3,5,7'); => wp_list_pages SHOULD return nothing, but instead it displays all child pages of the first parent page ID in the ""exclude"" attr (here: 3). Now we now add the ""exclude_tree"" attr just for fun: 2) wp_list_pages('title_li=&depth=1&exclude=3,5,7&exclude_tree=3,5,7'); => should again return nothing, but instead, it displays the first-ever published child page globally (here: a child page of 5). It looked like random behavior at first but I've been able to identify the above pattern. I'm guessing it's a failing condition somewhere in the function." bobsoap Future Releases 27088 Allow per-query filtering of post status objects Query 3.8.1 normal normal enhancement closed needs-unit-tests 2014-02-11T05:32:31Z 2024-03-21T17:47:35Z "There comes a time where queries need to pull in posts (or CPTs) that have a non-public post status. Unfortunately, there are no filters on `get_post_status()` or `get_post_status_object()` to allow this kind of atomic control within `WP_Query::get_posts()`. To rectify this, we should add (at a minimum) filters on: - `get_post_status()` - `get_post_status_object()` Additionally, a filter within `WP_Query::get_posts()` (on the return of `get_post_status_object()` with the query passed along for context) will allow per-query filtering of the status object if it needs to be overridden for specific reasons." ericmann Future Releases 15249 Filtering get_search_sql for advanced queries Query 3.1 normal normal enhancement assigned needs-unit-tests 2010-10-29T07:00:35Z 2019-06-04T20:41:32Z "Currently in the code for 3.1 (trunk) there are no filters running on the new function get_search_sql which would be useful for plugins to perform more complex MySQL functionality on specific columns. I suggest adding a filter ;)" sc0ttkclark Future Releases 25190 Improve name/pagename query variable mapping Query normal normal enhancement new needs-unit-tests 2013-08-30T08:12:13Z 2019-06-04T20:44:46Z `WP_Query` performs some mappings from custom query variables to `pagename` and `name` for custom post types. This could be improved so that `pagename` is not used for hierarchical post types when a top-level item has been requested. We could also do some mappings between `pagename` and `name` in case the incorrect query variable was used (see #16323). duck_ Future Releases 36881 Improved hot-wiring of set_found_posts Query normal normal enhancement new needs-unit-tests 2016-05-18T22:45:22Z 2019-06-04T20:59:10Z Currently you can filter posts_request and posts_result to hot wiring the query object add caching. However, this means that in many cases the set found posts method then never gets called. This means that found posts is un-filterable. The set found posts needs to be called after the post results filter. spacedmonkey Future Releases 33306 Only Query for author ID if user is member of blog Query 4.3 normal normal enhancement new needs-unit-tests 2015-08-07T17:45:42Z 2019-06-04T20:51:04Z In WP_Query if a user is part of the multisite install but is not part of the current blog the query is still altered from only finding public posts to finding public posts and those that are private and from that author_id. While this never has an impact on the returned end results, not having private and author ID as a parameter lets MySQL optimize the queries and in the circumstances this has been tested on (large site, lots of posts lots of users) makes them run faster. On a site without multisite installed this will have the same behavior. sboisvert Future Releases 9785 Search Enhancements -- consolidated ticket Query 2.8 normal normal enhancement closed needs-unit-tests 2009-05-10T23:54:34Z 2021-09-21T22:28:20Z "Closing the following as dups, pending ""the big search overhaul"" that may never come: - #5149 -- search everywhere (with committed patch) - #9230 -- search in post and pages and both - #5525 -- also search for posts with search query as terms (tags, cats, ...) - #5054 -- allow to negate keyword on search - #7394 -- assign greater weight to posts with search query in title - #7647 -- search in attachment descriptions" Denis-de-Bernardy Future Releases 20352 Use str_getcsv() to parse search terms in WP_Query Query normal normal enhancement new needs-unit-tests 2012-04-03T23:05:25Z 2019-06-04T20:43:04Z "We use an [http://core.trac.wordpress.org/browser/tags/3.3.1/wp-includes/query.php#L2183 ugly regex] to split search terms like these: {{{ term1 term2 ""exact match"" }}} We could use str_getcsv() instead, for better readability." scribu Future Releases 23044 adjacent_image_link() needs optimization Query 3.5 normal normal enhancement new needs-unit-tests 2012-12-22T05:04:20Z 2019-06-04T20:43:34Z "`adjacent_image_link()` is really slow and stupid. It queries for '''all''' of the images attached to that post. And then it picks the previous or next one in PHP. And there's no caching, so you'll typically get this happening '''three times''' on an attachment page, (image [linked to next], prev link, next link). We should actually just make the query grab the ONE image we want." markjaquith Next Release 44079 Require `manage_privacy_options` capability to edit the privacy policy page iandunn Privacy 5.1 normal normal 4.9.6 defect (bug) closed needs-unit-tests 2018-05-14T18:33:16Z 2018-05-16T21:27:37Z "#44055 identified the problem that Editors are shown a link to the privacy guide, but can't actually view it. The solution there, in r43248, was to hide the link if users don't have the `manage_privacy_options` capability. It doesn't seem like people without that capability should be able to edit the privacy page in the first place, though. Preventing them from editing it would solve the issue in #44055, and also any other issues stemming from the fact that editors could edit the page. An example of that kind of issue would be an editor who isn't trained in privacy law or organizational policies making edits that don't reflect the organization's desires. Also, if someone ''is'' editing the page, then they should probably be able to read the guide as well, because the guide informs what edits should be made. Previous discussion: * ticket:44055#comment:5 * https://wordpress.slack.com/archives/C02RQBWTW/p1526315451000694 * https://wordpress.slack.com/archives/C02RQBWTW/p1526319469000326" iandunn Next Release 43883 Add a user's attachments to the personal data export file allendav Privacy 5.1 normal normal 4.9.6 enhancement closed needs-unit-tests 2018-04-27T17:46:24Z 2018-05-16T21:27:37Z "Attachments (e.g. media) can contain personal data (e.g. images of the person, EXIF Geo location, etc) We should at least include a public link to each attachment a user has uploaded. For smaller attachments (e.g. < 3 MB), maybe include them in the export archive too. I'll take care of this after #43546 lands" allendav Next Release 43547 Add personal data from usermeta/userdata to personal data export tz-media Privacy 5.1 normal normal 4.9.6 enhancement closed needs-unit-tests 2018-03-14T19:26:30Z 2018-05-16T21:27:37Z "Add personal data from usermeta/userdata to the personal data export using the infrastructure added in #43438. See also #43440" allendav Future Releases 44236 Maintain consistency between privacy export report and archive filenames GripsArt Privacy 4.9.6 low minor Future Release defect (bug) assigned needs-unit-tests 2018-05-26T00:03:07Z 2019-01-27T09:03:40Z "Prior to r43180, the export `.zip` filename changed every time it was regenerated; after that commit, it was reused to ensure links aren't broken (see #43905). That commit didn't do anything to the `.html` filename, though, so after the initial regeneration, the value of `$obscura` will not match between the two filenames. I don't think this presents any issues for Core, and might not for plugins either, but it seems like they should be consistent, just to be safe. If a plugin hooks into `wp_privacy_personal_data_export_file_created`, it may reasonably assume that the filenames to match, and do something like `str_replace( '.html', '.zip', $foo )`. That seems unlikely, since both filenames are passed to the callback, but it's better to be safe than sorry." iandunn Future Releases 44084 Privacy: The personal data export file should be generated in the user's locale garrett-eclipse Privacy 4.9.6 normal normal Future Release defect (bug) assigned needs-unit-tests 2018-05-15T00:26:10Z 2020-10-08T07:01:36Z Similar to #43985, the HTML file containing the personal data export should be translated into the locale the user has selected for their profile, with a fallback to the site's locale. coreymckrill Future Releases 56694 Uncached database read for logged in users when Privacy Policy Page is deleted Privacy 5.7 normal normal Awaiting Review defect (bug) new needs-unit-tests 2022-09-29T20:47:20Z 2022-09-29T21:24:19Z "As a logged in WordPress user navigating around WordPress Admin, a hook fires on every admin page that attempts to notify you whether or not the suggested Privacy Policy text (in WordPress) has changed, sourced from the ""Privacy Policy Guide"" settings page. The Privacy Policy itself is a Page, and the numeric ID of that page is saved as a Setting. If the WordPress Page (that matches the ID that is set as the Privacy Policy Page setting) is permanently deleted, WordPress still attempts to query the database to look for this Page. This results in a single database read query that will never find what it is looking for, and is not cached because it does not exist, causing it to happen again on every subsequent page that any logged in user navigates to inside of WordPress Admin. * This user would normally never know this database chatter is happening because it isn't anything they are intentionally looking for * I discovered this misbehavior while using the Query Monitor plugin on a dev site, and noticed that there was always 1 uncached database read Screenshot of the query & call stack will be attached below." johnjamesjacoby Future Releases 43880 Add functionality to add an anonymous user an get its ID for anonymization of data related to a WordPress user. tz-media Privacy normal normal Future Release enhancement assigned needs-unit-tests 2018-04-27T14:05:28Z 2018-07-09T17:58:08Z "When we need to anonymize data that is (or can be) associated with a WordPress user, we anonymize it by changing the user ID of that data to a user that represents anonymized content. But currently no such user exists, so we set the ID to 0. In order to display an actual user name (at least for posts), we would need an actual user 'Anonymous' that we can re-assign the content to. This might be created on WordPress install by default (maybe even with a User ID of `0` that we can then hardcode into the anonymized functions), or by calling a function like `_wp_privacy_get_anonymous_user_id()` that creates the user if not already created and returns the user ID (that might be stored in a site_option)." TZ Media Future Releases 43879 Add tools for anonymizing of post authors tz-media Privacy normal normal Future Release enhancement assigned needs-unit-tests 2018-04-27T13:46:24Z 2020-09-07T08:30:09Z "Logged-in users that post content can request the removal of their personal data. So we should add functionality to add the posts to the erasure infrastructure that is already committed to trunk. See #43442 for reference (anonymize commenters)." TZ Media Future Releases 43588 Anonymize commenter IP address once a comment is no longer pending Privacy normal normal Awaiting Review enhancement new needs-unit-tests 2018-03-20T19:06:12Z 2019-01-09T19:17:26Z "A commenter's IP address is stored with each comment. The commenters IP address can often be used to identify a single individual or device at a location. To enhance commentor's privacy, and to reduce the amount of personal data stored by a WordPress site in preparation for upcoming laws like the GDPR, this issue proposes that once a comment transitions out of pending, core WordPress should zero the commentor's IP address final octet similar to how Google Analytics Anonymizes IP addresses The rationale for keeping it while a comment is pending is to continue to allow anti-spam access to the IP address which can be used to detect spam. The rationale for keeping all but the last octet is to still allow statistics to be gathered about the general geographic location of commenters based on the first three octets of the IP address." allendav Future Releases 44034 Privacy: Introduce a function to count user requests by type garrett-eclipse Privacy normal normal Future Release enhancement assigned needs-unit-tests 2018-05-10T11:13:55Z 2020-10-12T21:39:38Z "The user request list tables use {{{WP_Privacy_Requests_Table::get_request_counts( $type )}}} to count user requests by type. If export- and erase bubble counts will be added in #44000 and if e.g. plugins or core will add request stats to the dashboard ( e.g. ""At a glance"" or ""Activity"" metaboxes), then it makes sense to introduce a function like: {{{ wp_count_user_requests( $type ) }}} where type is either {{{'remove_personal_data'}}} and {{{'export_personal_data'}}}. An alternative would be if {{{wp_count_post( $post_type = 'user_request' )}}} would support {{{$post_name}}} as well, for the request types. " birgire Future Releases 43750 Establish a standard means of core reading privacy declarations from plugins' headers xkon Privacy 4.9.6 normal normal enhancement closed needs-unit-tests 2018-04-12T17:35:42Z 2020-01-22T21:53:35Z "To help administrators create and maintain their site's privacy policy, we not only need the privacy declarations for WordPress core (the software) but also need a means of getting privacy declarations from plugins. This ticket is about getting those privacy declarations from plugins. (See #43473 for core's declarations.) The proposed way right now is for plugins to add their privacy declarations to their readme.txt somehow. This ticket needs to define how exactly to add those to readme.txt (e.g. what section, format). This ticket also needs to result in the code that allows those privacy declarations to be surfaced in the privacy-policy-editing user interface proposed in #43435 (alongside the declarations from core itself from #43473) " allendav Next Release 16567 Can't create categories with different names but similar slugs on Edit Post screen boonebgorges Posts, Post Types 3.0.5 normal normal 4.8 defect (bug) closed needs-unit-tests 2011-02-15T18:29:10Z 2016-12-23T03:10:36Z "We run a blog that deals with programming languages. Today we were creating a post concerning the C programming language and attempted to create a new category for it, called ""C"" (just one character). This angered WordPress; it appeared to create a superfluous ""Uncategorized"" category, but it wound up not actually creating any categories for the post. I've attached a screenie so you can see what this looks like after I attempt to create the category. If it's for some reason forbidden to create categories comprised of a single character, maybe a validation error message of some kind would be in order?" jeffreymcmanus Next Release 16956 Comments Being Pulled from Non-Existent Post Types boonebgorges Posts, Post Types 3.1 normal normal 4.4 defect (bug) closed needs-unit-tests 2011-03-24T01:30:32Z 2016-03-11T11:49:27Z "Originally on: #10461 I'm running standard LAMP on the latest trunk. Just viewing the dashboard with no plugins activated: {{{ Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 918 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 919 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 919 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 922 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 922 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 918 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 919 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 919 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 922 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 922 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 918 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 919 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 919 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 922 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 922 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 918 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 919 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 919 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 922 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 922 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 918 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 919 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 919 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 922 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 922 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 918 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 919 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 919 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 922 Notice: Trying to get property of non-object in /Users/grok/Projects/Local Development/wordpress/trunk/wp-includes/capabilities.php on line 922 }}} It's not recognizing ""$post_type->cap"" as valid. And...here's why - I added this (/wp-includes/capabilities.php): {{{ 918 echo ""POST TYPE: Y U NO OBJECT?\n""; 919 var_dump($post_type); }}} And got: {{{ POST TYPE: Y U NO OBJECT? NULL }}} So in this context...the post type is null and the code was not expecting that. Opening the actual $post object: {{{ stdClass Object ( [ID] => 60 [post_author] => 1 [post_date] => 2011-01-28 19:46:23 [post_date_gmt] => 2011-01-28 19:46:23 [post_content] => CONTENT! [post_title] => I have it all! [post_excerpt] => [post_status] => publish [comment_status] => open [ping_status] => open [post_password] => [post_name] => i-have-it-all [to_ping] => [pinged] => [post_modified] => 2011-01-28 19:46:28 [post_modified_gmt] => 2011-01-28 19:46:28 [post_content_filtered] => [post_parent] => 0 [guid] => http://dev.wordpress.local/?post_type=staff_listing&p=60 [menu_order] => 0 [post_type] => staff_listing [post_mime_type] => [comment_count] => 6 [ancestors] => Array ( ) [filter] => raw ) }}} I think the problem might be custom post types or custom taxonomies... So my custom post type in another plugin is creating: ""?post_type=staff_listing"". And this post does show ""[post_type] => staff_listing"". BUT the plugin that had created these comments...is de-activated. Activating the plugin resolves this issue. So, whats a viable solution? Telling a developer to clean up after the plugin (removing content just because of deactivation), OR having WordPress not pull data (e.g. comments) that are assigned to other data (e.g. post types) that don't exist? Old Code: Give me all comments. New Code: Give me all comments that are tied to existing objects." sterlo Next Release 21963 Consolidate post insertion APIs wonderboymusic Posts, Post Types normal normal 4.0 defect (bug) closed needs-unit-tests 2012-09-22T03:46:24Z 2014-07-15T19:40:06Z "In wp-includes, we have: * wp_insert_post() * wp_insert_attachment() * wp_update_post() * wp_publish_post() For saving from the admin, we have: * edit_post() * wp_write_post() * write_post() '''wp_publish_post()''' is, as of [21942], now wraps wp_insert_post(). '''wp_update_post()''' is a fairly mundane wrapper of wp_insert_post(), but we really should eliminate the differences between the two functions and make it a straight-up wrapper. '''wp_insert_attachment()''' was a fork of wp_insert_post(), and wp_insert_post() has gotten a lot of improvements that haven't reached wp_insert_attachment(). It doesn't take much to merge these two, though, and make wp_insert_attachment() a wrapper. '''wp_write_post()''' calls edit_post() if it has a post ID. And since we have had a post ID since the days of auto-drafts, this function is dead code. It's wrapper, '''write_post()''', can also be deprecated. I'm attaching a patch that takes care of wp_insert_post(), wp_write_post(), and write_post(). wp_update_post() will require a bit more concentration. Needs testing and unit tests." nacin Next Release 27578 Editing a draft does not set `post_date_gmt`, but quick editing a draft does Posts, Post Types 3.9 normal normal defect (bug) closed needs-unit-tests 2014-03-29T08:12:13Z 2014-03-29T11:52:26Z (It's all in the title…) Denis-de-Bernardy Next Release 38341 Hide 'Empty Trash' button when trash is already empty swissspidy Posts, Post Types normal normal 4.8 defect (bug) closed needs-unit-tests 2016-10-18T13:50:00Z 2017-03-17T16:53:08Z "Noticed while working on #37407. Here's a screenshot: [[Image(https://cldup.com/TxxKy9pM0E.png)]]" swissspidy Next Release 30339 Infinite loop while checking for post slug uniqueness johnbillion Posts, Post Types 4.1 normal major 4.1 defect (bug) closed needs-unit-tests 2014-11-14T05:36:46Z 2014-11-20T16:45:51Z "When inserting a new hierarchical post of any type using `wp_insert_post()`, the `wp_unique_post_slug()` function creates an infinite loop when checking for already existing posts with the same slug. In `wp_unique_post_slug()`, when entering the case of `is_post_type_hierarchical()` (line 3698 in the trunk as of today), the query is missing the `$post_type` variable when being prepared. The query set in `$check_sql` contains 4 parameters but only 3 are given in `$wpdb->prepare()` (line 3723) while looping in the post slugs. As a result, `$wpdb->prepare()` returns `false` because of the last argument (`post_parent`) not being given, and no SQL query is run at all. `$wpdb->get_var()` then returns the last cached result." julien731 Next Release 27071 Invalid HTML produced by get_the_password_form SergeyBiryukov Posts, Post Types 3.7 normal normal 3.8.2 defect (bug) closed needs-unit-tests 2014-02-08T12:15:43Z 2014-03-31T20:48:38Z "There seems to be a bug with the HTML returned by get_the_password_form (post-template.php). There's a line break between lines 1251 and 1252 (the closing

tag surrounding the input and the closing tag). This causes an extra

to be generated by the browser. So the output on a password-proteced post looks like this: {{{

This content is password protected. To view it please enter your password below:

}}} Simple fix - just need to remove this line break and it works fine. " andykeith Next Release 48653 PHP Notices when requesting a post with an unregistered status SergeyBiryukov Posts, Post Types 3.0 normal normal 5.4 defect (bug) closed needs-unit-tests 2019-11-15T11:07:37Z 2020-02-05T19:19:03Z "Plugins can register new post statuses using {{{register_post_status}}}. When such a plugin is then disabled, it is possible that posts remain in the database with a post status that is no longer registered. In such cases, {{{get_post_status_object}}} will return {{{null}}}. This return value is not handled correctly in {{{map_meta_cap}}} and the WP_Query class, causing PHP notices. Step to reproduce: * Set WP_DEBUG to true in wp-config.php. * Create posts with {{{post_status}}} that is not native to WordPress (I use ""bogus""). The quickest way to fake this is to edit the database directly. * Request the post using the REST API, or by calling its guid/permalink in the browser. * PHP Notices will be shown, saying something like ""Notice: Trying to get property 'public' of non-object"". This can be fixed by adding some defensive programming in the map_meta_cap function, and the WP_Query class. I'll attach a patch that suggests a way to do this." roytanck Next Release 33763 Post types with show_ui set to false should not be accessible via the admin area johnbillion Posts, Post Types 2.9 normal normal 4.4 defect (bug) closed needs-unit-tests 2015-09-07T08:19:15Z 2015-11-19T16:24:36Z "This might be a contentious issue. It's certainly not expected behaviour, but I suspect there are sites which rely on its behaviour. If a custom post type is registered with `show_ui` set to `false`, it's still possible to see the post type listing screen for the post type by manually navigating to the correct URL (eg. `example.com/wp-admin/edit.php?post_type=my_hidden_post_type`). From there you can access the post editing screen for the posts and update them. If I register a post type without a UI, I do not expect to be able to access a UI for the post type simply by hacking the URL. The post type listing UI and post editing UI for such a post type should be disabled. In order to disable this UI currently, you need to set the post type's capabilities to a capability which your users don't have, which has the side effect of preventing posts from being created/edited via other means, such as XML-RPC." johnbillion Next Release 32585 Programmatically using wp_insert_post with post_author=0 does not work when user is logged in wonderboymusic Posts, Post Types normal normal 4.4 defect (bug) closed needs-unit-tests 2015-06-08T12:07:17Z 2015-09-14T15:52:41Z "Passing a `post_author` of 0 to `wp_insert_post` does not work if the user is logged in. Reproducible with: {{{ add_action( 'init', function() { $args = array( 'post_title' => 'test', 'post_author' => 0 ); $post_id = wp_insert_post( $args ); echo get_post_field( 'post_author', $post_id ); // post_author is 1 }); }}} `post_author` returns 1, despite `post_author` being set explicitly to 0. " ericdaams Next Release 31034 delete_post capability issue in Trash Posts, Post Types 4.1 normal normal defect (bug) closed needs-unit-tests 2015-01-16T07:36:03Z 2017-07-27T15:16:25Z "There is a issue with capability 'delete_post' in Trash when a post with status other than 'publish' was trashed. When you registered this post type with map_meta_cap => true and disabled capability 'delete_post' using 'user_has_cap' you will see that in posts (view All) table there is no trash link in post row actions but you can select this post and bulk remove. Post will be moved to trash and voila in view Trash you can permanently remove this post. I've checked the source and found that te problem is map_meta_cap() function {{{ } elseif ( 'trash' == $post->post_status ) { if ( 'publish' == get_post_meta( $post->ID, '_wp_trash_meta_status', true ) ) { $caps[] = $post_type->cap->delete_published_posts; } } }}} there is a check for 'publish' status so when my post was 'pending' map_meta_cap() returned empty array()." szaqal21 Next Release 22882 get_post_ancestors() now returns false in addition to array() nacin Posts, Post Types 3.5 normal normal 3.5.1 defect (bug) closed needs-unit-tests 2012-12-12T11:43:49Z 2013-01-15T19:14:08Z "Under [http://core.trac.wordpress.org/browser/branches/3.4/wp-includes/post.php#L428 3.4, get_post_ancestors()] would always return an array, in error conditions, it would return an empty array.[[BR]] Under [http://core.trac.wordpress.org/browser/trunk/wp-includes/post.php#L675 3.5, get_post_ancestors()] returns an array of ancestors, as in 3.4, except, in the case where the $post passed in is NULL/FALSE/0/empty, then it now returns false. This results in warning such as this: `Warning: Invalid argument supplied for foreach() ` when the result of get_post_ancestors() was used directly in a loop, Admitably, it's bad code which triggers this, calling get_post_ancestors() with the global `$post` object before it's set up in this case, but it's still a chance in behaviour which I felt needs documenting on trac. This is either a instant 'We should just return an array()' or 'wontfix: Plugins are doing it wrong and should fix their code' ticket. This was found by debugging http://wordpress.org/support/topic/does-wordpress-35-still-support-is_tree?" dd32 Next Release 54736 get_sample_permalink unsets $post->filter even though this is a public property. hellofromTonya Posts, Post Types 2.7.1 normal normal 6.1 defect (bug) closed needs-unit-tests 2022-01-04T12:43:19Z 2022-09-20T04:34:05Z "The property should be set to `null` rather than being `unset`. Unsetting it removes it entirely which means if it's later requested ( such as in `WP_Post::__get` ) this causes a notice to be thrown that the property doesn't exist." herregroen Next Release 52144 the $term_ids in function wp_queue_posts_for_term_meta_lazyload is index array SergeyBiryukov Posts, Post Types 4.5 normal normal 5.7 defect (bug) closed needs-unit-tests 2020-12-22T03:11:29Z 2020-12-24T11:19:31Z "the $term_ids in function wp_queue_posts_for_term_meta_lazyload is index array, {{{ if ( ! isset( $term_ids[ $term->term_id ] ) ) { }}} should change to {{{ if ( ! in_array( $term->term_id, $term_ids ) ) { }}} " denishua Next Release 55877 wp_insert_post() should check that a post type exists before using it SergeyBiryukov Posts, Post Types 5.1 normal normal 6.1 defect (bug) closed needs-unit-tests 2022-05-30T16:17:25Z 2022-07-24T13:24:45Z "In #27335 it was accepted that `wp_insert_post()` can insert a post from an unknown post type - although not consistent with `wp_insert_term()` which returns a `WP_Error` for an invalid taxonomy but that's another issue. Later, [changeset:""42380""] introduced some usage of the post type object inside `wp_insert_post()`, still without checking that the post type exists. Thus writing a test including: {{{#!php 'My post', 'post_type' => 'unregistered', 'post_status' => 'pending' ) $post_id = wp_insert_post( $args ); }}} will fire the error `Trying to get property 'cap' of non-object`." Chouby Next Release 17455 Add $post_type argument to get_lastpostdate/get_lastpostmodified/_get_last_post_time SergeyBiryukov Posts, Post Types normal normal 4.4 enhancement closed needs-unit-tests 2011-05-16T15:05:59Z 2015-09-16T15:28:13Z As title says. You can currently use these functions to only get the latest [modification] date of all publicly queryable content types. duck_ Next Release 12976 Add get_post_content()/get_post_excerpt() and save_postdata()/restore_postdata() for support. Posts, Post Types 3.0 normal normal enhancement closed needs-unit-tests 2010-04-12T16:05:25Z 2017-02-06T12:51:40Z "Currently the {{{get_the_content()}}} and {{{get_the_excerpt()}}} functions return the values from the loop but do not allow a Post object to be passed. These functions in the patch ({{{get_post_content()}}} and {{{get_post_excerpt()}}}) save and then restore the global variables assigned by {{{setup_postdata()}}} so that {{{get_the_content()}}} can be called for a specific post. The functions to save and restore the postdata are {{{save_postdata()}}} and {{{restore_postdata()}}} respectively, and they simply capture the values of the global variables set in {{{setup_postdata()}}} into an array and then restore them back from the array. This is the first of a broader patch I hope to supply with functions for {{{get_post_*()}}} and {{{the_post_*()}}} that would each receive as their first parameter a Post object/post ID/post array and as a second an array of {{{$args}}} so that robust code can be written related to posts and so that there will be a set of functions for this with a ''consistent'' set of parameters." mikeschinkel Next Release 32077 get_pages re-factor to reduce line-count, DRY up code & give more specific functions for some of it's main processes Posts, Post Types 1.5 normal normal enhancement closed needs-unit-tests 2015-04-23T14:56:33Z 2015-06-03T13:18:44Z "While investigating another bug report, I noticed get_pages was more than a little unweildy & required significant screen scrolling, and had everything thrown into the function. Really the whole thing needs a rewrite or to be chopped up into smaller functions for readibility and sandboxing some effects of code, which also increases adaptability. I also noticed the caching seemed to be adding overhead where it was unnecesarry, and checks on caching seemed to be in the wrong order." LewisCowles Next Release 30970 setup_postdata should be able to accept a Post ID, currently requires full WP Post object boonebgorges Posts, Post Types 1.5 normal normal 4.4 enhancement closed needs-unit-tests 2015-01-10T01:57:58Z 2015-09-12T20:57:07Z "You should have to get_post before calling setup_postdata, the function (and by extension $wp_query->setup_postdata) should be able to accept an ID. Currently, setup_postdata() expects a full WP_Post (or faux standard post) object. Something as easy as this could allow for this to function: {{{ public function setup_postdata( $post ) { global $id, $authordata, $currentday, $currentmonth, $page, $pages, $multipage, $more, $numpages; if ( ! is_object( $post ) ) { $post = get_post( $post ); if ( ! $post ) { return false; } } $id = (int) $post->ID; }}} This also has a fallback with a return false, which sticks with the bool typed return already documented. It solves cases where you may want to use WP template tags but all you have is a Post ID from another variable or from an option / transient / cached object. This can allow for 3 additional tests to be added to test setup_postdata( $post_id ) will return true and setup the post, setup_postdata( $null_or_anything_invalid ) will return false, and setup_postdata( $post ) will return true and setup the post as normal with little to no overhead or ill effects." sc0ttkclark Future Releases 47279 $post object passed to clean_post_cache action can contain outdated values Posts, Post Types normal normal Future Release defect (bug) new needs-unit-tests 2019-05-15T14:28:45Z 2019-05-15T21:57:01Z "This occurs when publishing or deleting a post. In the `clean_post_cache()` function, `get_post( $post )` is called and assigned to `$post`. At that moment, the value of the `$post` parameter `post_status` = `draft` if publishing, `publish` if deleting the post. There is then a call to `wp_cache_delete( $post->ID, 'post_meta' );`, which correctly updates the value of post_status, if you perform another `get_post()` right after. But, the `$post` object is then passed to the action `clean_post_cache`, with the outdated values instead. So if someone hooks a function on `clean_post_cache`, and uses the `$post` object passed, it's going to receive incorrect values compared to what would be expected. But if you perform a `get_post()` inside that function, you will get the correct values. I only tested this with the `post_status` parameter, but this might be affecting others too. I would expect that the `$post` object passed to the `clean_post_cache` action contains up-to-date values." tabrisrp Future Releases 39939 A Contributor cannot preview their own post if it's scheduled Posts, Post Types normal minor Awaiting Review defect (bug) new needs-unit-tests 2017-02-22T12:52:02Z 2017-02-23T05:36:25Z "Steps to reproduce: 1. A Contributor writes a post and submits it for review. At this point they can preview their post. 2. An Editor or Administrator approves the post and schedules it for publication at a later date. 3. The contributor viewing the Posts listing table can no longer preview their post. Previously: #33694 " johnbillion Future Releases 41448 Contributors shouldn't be able to change the date of their drafts Posts, Post Types 2.7 low normal Future Release defect (bug) new needs-unit-tests 2017-07-26T12:33:48Z 2017-08-04T13:24:10Z "(I'm guessing that) contributors shouldn't be able to change a post's publication date—that's why the ''Publish'' box doesn't include the date when logged in as a contributor in the first place. However, if a contributor quick edits a post in the ''All Posts'' screen, they'll be able to change the post's date. We should remove the date field from the ''Quick Edit'' form. Or, alternatively, we should allow contributors to edit this date while they're editing a post. Either way, both screens should be consistent." davilera Future Releases 50002 Hack in get_sample_permalink() can cause filters like post_link, and pre_post_link to have inaccurate post_status in admin Posts, Post Types 5.4 normal normal Awaiting Review defect (bug) new needs-unit-tests 2020-04-24T20:07:13Z 2020-04-26T12:35:32Z "For context: https://github.com/aubreypwd/WordPress/issues/5 When editing a post (that is a draft) in the admin, add a filter to `post_link` you'll notice that the pass for `get_sample_permalink()` shows that `$post->post_status` is set incorrectly (un-truthfully) to `publish`. This is because of a 12 year old block of code in `get_sample_permalink()`: {{{ // Hack: get_permalink() would return ugly permalink for drafts, so we will fake that our post is published. if ( in_array( $post->post_status, array( 'draft', 'pending', 'future' ) ) ) { $post->post_status = 'publish'; $post->post_name = sanitize_title( $post->post_name ? $post->post_name : $post->post_title, $post->ID ); } }}} In order for `post_link` and even `pre_post_link` filters to pass accurate info about a post, the patch I have attached is my first attempt at ensuring `get_sample_permalink()` still gets the same result, while not affecting `post_status`. Obviously I tested this, but I still feel some more testing will need to be done. " aubreypwd Future Releases 43752 ID, post_parent, menu_order on global $post object is a string in edit context; expecting int Posts, Post Types 4.9.5 normal normal Awaiting Review defect (bug) new needs-unit-tests 2018-04-12T23:34:08Z 2018-04-19T00:27:16Z "When I'm on an edit post screen, the ID, post_parent, menu_order attributes on the global $post object are strings. I expect them to be integers. To quickly check, put this in a plugin: {{{#!php ID); }); }); }}} Here's what's happening: 1. in wp-admin/post.php the edit case happens, and within that the post gets reloaded here: https://github.com/WordPress/WordPress/blob/4.9.5/wp-admin/post.php#L167 2. that function will run the post object through its own filter with filter edit here: https://github.com/WordPress/WordPress/blob/4.9.5/wp-includes/post.php#L552 3. because at the time $this->filter = ""raw"", and the $filter is edit, that will run the object through sanitize_post here https://github.com/WordPress/WordPress/blob/4.9.5/wp-includes/class-wp-post.php#L354 4. sanitize_post will, in turn, run all the fields through sanitize_post_field here: https://github.com/WordPress/WordPress/blob/4.9.5/wp-includes/post.php#L1940 5. and even though we have 3 fields set as int (https://github.com/WordPress/WordPress/blob/4.9.5/wp-includes/post.php#L1973), by the time we get to this part (https://github.com/WordPress/WordPress/blob/4.9.5/wp-includes/post.php#L2027-L2034), those three will be ran through esc_attr 6. esc_attr will feed it through _wp_specialchars here https://github.com/WordPress/WordPress/blob/4.9.5/wp-includes/formatting.php#L3978 7. which begins with $string = (string) $string; here https://github.com/WordPress/WordPress/blob/4.9.5/wp-includes/formatting.php#L912 The part that throws me off is that `sanitize_post_field` declares these three properties to be integers at the beginning of the function, so I sort of expected them to come out as integers on the other end." javorszky Future Releases 41471 Page dropdown walker must check selected against value field Posts, Post Types 4.9 normal normal Future Release defect (bug) new needs-unit-tests 2017-07-28T03:36:18Z 2019-02-20T21:18:08Z `Walker_PageDropdown` only checks `selected` with the page `ID` and ignores `value_field` option. geminorum Future Releases 11235 "Pages whose ancestors are not all ""published"" cannot be used as parents for other pages." Posts, Post Types 2.9 normal normal Future Release defect (bug) new needs-unit-tests 2009-11-23T01:04:01Z 2019-06-04T18:12:41Z Pages with trashed parents cannot be used as parents for other pages (they do not appear on the list). caesarsgrunt Future Releases 42323 Posts vs CPT user permissions issue Posts, Post Types 4.9 normal normal Awaiting Review defect (bug) assigned needs-unit-tests 2017-10-24T14:51:56Z 2017-10-24T15:10:29Z "We have the following use case: 1. User does not have access to create new ""Posts"" 2. User does have access to create new Product Submissions (CPT post type) With these prerequisites, when the user clicks on ""New Product Submission"" from the list view (or the edit view), they get the No access message. This happens because in core we check for `edit.php` no_priv instead of `edit.php?post_type=product_submission`." bor0 Future Releases 3670 Removing CDATA close tag ( ]]> ) unbalances the CDATA block andy Posts, Post Types 2.1 normal minor Future Release defect (bug) new needs-unit-tests 2007-01-25T05:55:47Z 2023-02-10T03:00:14Z "I'm not sure if this is a bug per se, but it breaks included JS in my posts that are escaped with a CDATA section. I've basically commented out the following line in the_content() every time I upgrade: //$content = str_replace(']]>', ']]>', $content); A user on the wp-testers list indicated that this was part of making sure that included CDATA blocks didn't break RSS feeds. I don't use CDATA sections directly in my RSS feeds, so I haven't tested this. In my particular case, the JS is used to embed Flash movies (e.g. YouTube videos) in an XHTML compliant way (without embed tags). I have a custom plugin I've written that strips out the JS and replaces it with the embed tag in the RSS feed. Perhaps we should use a flag to activate this when the app is going through a feed. Ideally, though, it would simply be removed. Odds are that the CDATA block is being used for a JS block in a post body, and since most RSS aggregators don't allow JS by default, it would be safe to simply remove CDATA blogs if is_feed() is set." scenic Future Releases 41226 "Static ""posts page"" preview not working" Posts, Post Types normal normal Awaiting Review defect (bug) reopened needs-unit-tests 2017-07-03T09:41:05Z 2019-02-17T13:21:59Z "My site has both a static front page and a static posts page. The former is intended to be the site's home page, the latter the blog section home page. The static posts page is a regular page, created through the admin interface. Some parts of it are editable by admin - this is a design choice driven by project needs. Whenever I update the static posts page through the editor, the preview doesn't work: '''clicking on the ""preview"" shows the preview of the ""front page"" instead.''' Apart from that, everything works on the front-end side, and I can edit and save the posts page as needed. Unfortunately, as the project is being currently developed, I can't publicly publish urls or screenshots at the time." emross Future Releases 40588 Trashing and restoring a draft post replaces the slug Posts, Post Types 4.5 normal normal Awaiting Review defect (bug) new needs-unit-tests 2017-04-27T20:39:43Z 2018-07-31T14:57:32Z "Using the latest version of WordPress, if you create a draft post with a slug, lets say 'test-post', then trash it and restore it, the slug becomes {{{__trashed-xxx}}}, where xxx is a number Related to https://core.trac.wordpress.org/ticket/11863" TJNowell Future Releases 59354 Unnecessary queries performed when updating a post without providing categories or tags Posts, Post Types normal normal Awaiting Review defect (bug) new needs-unit-tests 2023-09-14T22:43:53Z 2023-09-14T22:43:53Z "Given an existing post with at least some categories or tags present, updating the post via `wp_update_post()` (which calls `wp_insert_post()`) with data that does not include categories or tags, many unnecessary taxonomy-related database queries are performed. This slows down the saving significantly. * If `$postarr` doesn't contain a `post_category` element, there's no point in calling `wp_set_post_categories()`. * If `$postarr` doesn't contain a `tags_input` element, there's no point in calling `wp_set_post_tags()` == Todo == * Need tests to verify the above is correct * Need a list of queries that are performed before and after the change == To reproduce == 1. Publish a post with at least one category 2. Update the post via: {{{#!php $id, 'post_content' => 'Hello, World!', ] ); }}} 3. Observe that a significant number of unnecessary taxonomy queries are performed" johnbillion Future Releases 59027 Weekly wp_get_archives has invalid link (link for month instead of year) Posts, Post Types 0.71 normal normal 6.6 defect (bug) new needs-unit-tests 2023-08-09T13:43:54Z 2024-02-05T20:34:38Z "If you call `wp_get_archives` function with `type` set to weekly, the resulted link contains two parameters: m => year, w => week. This results in unwanted behaviour, as you get a month like `2023` which is invalid. The link should contain ?y={year}&w={week}. " filipac Future Releases 37671 Emptying Bin with large amount of posts results in whitescreen Posts, Post Types normal normal Future Release enhancement new needs-unit-tests 2016-08-15T16:01:56Z 2017-08-06T00:31:10Z "When the Bin has a large amount of posts, e.g over 1,500, clicking Empty takes a long time to load, several minutes. After it finishes, it loads a blank white page and has only deleted about 75% of the posts. There's ~500 remaining." atomicjack Future Releases 41674 More granular capabilities for restoring and permanently deleting trashed posts Posts, Post Types normal normal Awaiting Review enhancement new needs-unit-tests 2017-08-19T16:00:27Z 2017-08-19T16:00:27Z "Currently the user capability required for restoring a trashed post or permanently deleting a trashed post is `delete_post`, which maps to `delete_posts`. There should be a separate capability for each of these actions. Suggestion: * `restore_trashed_post` which maps to `restore_trashed_posts` which maps to `delete_posts`. * `delete_trashed_post` which maps to `delete_trashed_posts` which maps to `delete_posts`. Emptying the trash should use the `delete_trashed_posts` capability. This allows for more granular control over which users can or cannot restore or permanently delete posts." johnbillion Future Releases 14017 "New template ""tag"": get_custom_field()" obenland Posts, Post Types 3.0 normal normal Future Release enhancement assigned needs-unit-tests 2010-06-21T04:13:03Z 2022-08-14T14:59:34Z "It would be helpful to have a way to retrieve a custom field value that is somewhat agnostic of current context. '''Current way to do this''' In the header (i.e., before the Loop), one has to access the currently-queried object to get a custom value, with something like this: `$value = get_post_meta($GLOBALS['wp_query']->get_queried_object_id(), 'field', true);` In the Loop: `$value = get_post_meta(get_the_ID(), 'field', true);` And, lots of tutorials out there tell people to do things like the following, with varying degrees of success (depending on variable scope): `$value = get_post_meta($id, 'field', true);` or `$value = get_post_meta($post->ID, 'field', true);` '''My proposed function (or ""template tag"")''' mixed '''get_custom_field''' ( string ''$fieldname'' [, int ''$post_id'' ] ) `$value = get_custom_field('field');` It picks the current object like so: {{{ Passed post object ID? / \ yes no | | use it | | within Loop? / \ yes no | | use current | Loop ID | | currently queried object is singular? / \ yes no | | use its ID ID = 0 }}}" filosofo Future Releases 28172 edit_post() should call {un}stick_post() before calling wp_update_post() Posts, Post Types 4.0 normal normal Future Release enhancement new needs-unit-tests 2014-05-08T01:37:34Z 2023-01-26T17:48:29Z "In a plugin I'm writing I have a need to hook into the `save_post` action and decide whether to allow a given post to be sticky based on postmeta associated with that post (and possibly other posts). However, if the function I attach to the `save_post` action calls `{un}stick_post()` it doesn't have the desired effect because of the way `edit_post()` is written. In particular, lines 320-332 of [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/post.php#L320] are: {{{ wp_update_post( $post_data ); // Now that we have an ID we can fix any attachment anchor hrefs _fix_attachment_links( $post_ID ); wp_set_post_lock( $post_ID ); if ( current_user_can( $ptype->cap->edit_others_posts ) ) { if ( ! empty( $post_data['sticky'] ) ) stick_post( $post_ID ); else unstick_post( $post_ID ); } }}} The `save_post` action is fired within `wp_update_post()` (technically, it is fired by `wp_insert_post()` which is called by `wp_update_post()`). Since `edit_post()` calls `{un}stick_post()` '''after''' it calls `wp_update_post()`, anything I do in my `save_post` function with regard to whether the post should be sticky is undone! Hence, I suggest changing the relevant portion of `edit_post()` to {{{ if ( current_user_can( $ptype->cap->edit_others_posts ) ) { if ( ! empty( $post_data['sticky'] ) ) stick_post( $post_ID ); else unstick_post( $post_ID ); } wp_update_post( $post_data ); // Now that we have an ID we can fix any attachment anchor hrefs _fix_attachment_links( $post_ID ); wp_set_post_lock( $post_ID ); }}} Is there a specific reason why `edit_post()` currently calls `wp_update_post()` before `{un}stick_post()`? (it isn't apparent to me) Another option I investigated was whether it was possible to have my plugin change `$post_data` via a filter but I couldn't find one. If others agree that this change would be good and wouldn't break anything else, I'll submit a patch. [Note: I went back and forth on whether to call this a bug or an enhancement. It's a bug in the sense that there is certainly an unexpected result ({un}sticking a post in a `save_post` action is undone...I lost about an hour trying to figure out why my `save_post` function wasn't doing the right thing); But it is an enhancement in the sense that core, itself, is not broken]." pbiron Future Releases 37376 Make it possible for custom post type to have an archive but no single Posts, Post Types 4.6 normal normal Awaiting Review feature request new needs-unit-tests 2016-07-15T17:55:34Z 2021-08-24T05:07:13Z "Very commonly we'll have testimonials, faqs, and such custom post types, which warrant an archive, but don't make sense to have a single. It's possible to have a post type with no archive and a single, but not the other way around. Funnily enough, I find that we far more often could use what isn't available versus what is. There are workarounds. One option is to make it a non-publicly-queryable post type and use a page template or something to display the results. Another option I've seen around is to hook into template_redirect on the single and redirect the user. Chances are there's no links on the front-end, so this really only occurs when users click on the link from edit-post admin-side. Another thing to consider here is SEO plugins and the like which look to the definition of the CPT to build the sitemap. The redirect method ends up putting useless links in the sitemap. The page template method works fine, but obviously means the CPT has to be queried separately. Would there be a downside to adding a sibling `has_single` option? If it's true by default then it's backwards compatible, and the single rewrites simply reflect the option." jason_the_adams Future Releases 12706 Custom post status bugs Posts, Post Types 3.0 normal normal Future Release task (blessed) reopened needs-unit-tests 2010-03-25T14:41:39Z 2022-06-02T13:42:36Z "A developer should be able to register a custom post status using `register_post_status()`. The admin UI (including post submit box and quick edit) should reflect this new custom post status. Furthermore, there are many hard-coded references to 'draft' and 'pending' statuses in core that should properly use the post status API. All existing arguments to `register_post_status()` should be fully implemented, should also support per-post-type arguments. As things get implemented across core, there will likely be a need for supporting capabilities and bits of API. Related: #23169 (register_post_status_for_object_type), #23168 (unregister_post_status)." ptahdunbar Future Releases 25798 Certain single CPT items result in 404 since 3.7 Posts, Post Types 3.7 normal normal defect (bug) new needs-unit-tests 2013-11-01T14:58:10Z 2019-06-04T20:45:08Z "Related: #25749 The changes in [25182] to the query_var mapping of hierarchical post types have broken single permalinks in some cases, when Permalink setting is set to ""Post name"". To reproduce: 1. Register a post type as follows: {{{ register_post_type( 'bbg_test', array( // ... 'hierarchical' => true, 'public' => true, 'rewrite' => true, // any value other than false 'query_var' => false, // ... ) ); }}} 2. Set permalink settings to ""Post name"" (and flush) 3. Create a new post of the type above, and attempt to visit at the url `http://example.com/bbg_test/foo` (or whatever). Result: 404. 4. Change to any other permalink setting. Result: page loads as expected. Cause: When the CPT is registered with `'rewrite'` other than `false`, it passes the test at http://core.trac.wordpress.org/browser/tags/3.7/src/wp-includes/post.php#L1275. When it's hierarchical, it passes the test at line 1293. When, because `'query_var'` is set to `false`, the rewrite tag set on line 1294 is of the form 'post_type=bbg_test&pagename=foo' (instead of 'bbg_test=foo'). Then, when an item is loaded, during `WP::parse_request()`, it passes the `preg_match()` test here http://core.trac.wordpress.org/browser/tags/3.7/src/wp-includes/class-wp.php#L198, but a page (ie, an item with `post_type` 'page') is not found by `get_page_by_path()`, and as a result the correct rewrite rule is not matched. As noted, this is a regression in 3.7 [25182], before which `preg_match( '/pagename=\$matches...` wouldn't have matched. Obviously it's an edge case that (a) a post type is hierarchical AND has query_var set to false, and also (b) permalinks are set to ""Post name"", but it is a change in behavior that broke one of my plugins, and has been a bit of a bear to track down :) I'm going to set `query_var` to true for my purposes (no harm done on my end) but that may not be possible for others." boonebgorges Future Releases 33547 Smilies are served over http instead of https and create mixed content when logged in johnbillion Posts, Post Types normal normal defect (bug) closed needs-unit-tests 2015-08-25T20:24:53Z 2019-06-04T20:51:13Z When I'm logged in into admin panel and view my website, the smilies are served over http instead of https which causes that there is mixed content and no graphics are displayed on the website at all. Strzyga Future Releases 16843 wp_unique_post_slug() doesn't check pagination base when CPT has archive Posts, Post Types 3.1 normal minor defect (bug) new needs-unit-tests 2011-03-13T06:22:22Z 2019-06-04T20:41:56Z Title says it all. scribu Future Releases 36314 If orderby undefined, alter get_posts to defer to WP_Query's default Posts, Post Types normal normal enhancement new needs-unit-tests 2016-03-23T22:22:46Z 2019-06-04T20:56:15Z "If the argument is undefined, defer `get_posts` orderby & order to that of WP_Query's. For search strings, this will order posts by relevance. In other cases it will have no effect." peterwilsoncc Future Releases 16784 Introduce post_type_archive_description() Posts, Post Types 3.1 normal normal enhancement new needs-unit-tests 2011-03-07T10:36:40Z 2021-04-24T16:12:27Z "if using the standard archive.php page, the common function for getting archive page name (e.g. single_tag_title) or description (e.g. tag_description) do not work - the best now is to use get_queried_object()->name resp. get_queried_object()->description Also it is not obvious, that when you create a custom post type and taxonomy (with public=true) they are not visible on menu navigation page - you must make them visible using the top View menu (it took me a while to realize it) " thomask Future Releases 38218 Make post type labels work during locale switching Posts, Post Types normal normal enhancement closed needs-unit-tests 2016-10-03T09:49:45Z 2018-10-18T17:47:25Z "This came up while working on #38157 and #26511. Moving the logic from `get_post_type_labels()` into its own class would greatly benefit the efforts made to switch locales. It essentially replaces the post type labels object with a new class that returns the labels on the fly (note: includes tests from #38157). The downside is that labels are never stored in an array but always translated upon request (performance problems?). What's needed for just-in-time translation (in addition to the current patch) is probably allowing passing a callback instead of an array of labels to the function. The same would need to be done for custom taxonomies and perhaps post statuses." swissspidy Future Releases 39089 Setting the Object Relationship Between Post Type Objects and Taxonomy Objects Posts, Post Types 2.9 normal normal enhancement closed needs-unit-tests 2016-12-05T17:34:57Z 2022-01-30T16:50:24Z "'''Does it matter which is object is created first when setting the object relationship between Post Type Objects and Taxonomy Objects?''' ---------- > Are you supposed to register Post Types **FIRST**, and Taxonomies required by that Post Type **SECOND**? OR > Are you supposed to register the Taxonomies **FIRST**, and the Post Types which use those Taxonomies **SECOND**? ---------- **The way I look at it is:** Taxonomy Objects should be created first before the Post Type Objects, since they're ultimately the bond between Post Objects and Post Type Objects; Taxonomies can be used across multiple Post Types objects. The reason I ask this is: because the WordPress Codex seems to outline it as register the Post Types FIRSTLY, and then register the Taxonomies SECONDLY. **I get this vibe by looking at two functions in the WordPress Codex:** 1. [`register_post_type();`](https://codex.wordpress.org/Function_Reference/register_post_type#Arguments) - If you look at the arguments section, there's an argument for Taxonomies (**Notice:** This is ''plural''). 2. [`register_taxonomy();`](https://codex.wordpress.org/Function_Reference/register_taxonomy#Parameters) - If you look at the parameters section, there's an parameter for specifying a single Object Type or Multiple Object Types. However, the actual parameter is called `$object_type`. (**Notice:** this is ''singular''). Now, where I'm confused is: PHP loads things in a procedural order. So there for one event needs to happen before the next. Both of the above functions have the capability of specifying multiple object types as a relationship. So to conclude my final question. What makes the most sense? Register Post Types first and Taxonomies second, or visa-versa? I also ask this because when you are dealing with the Post Type Objects and Taxonomy Objects in a programmatic way. Each object has a property which contains an array of related objects. Look at [`get_post_type_object();`](https://codex.wordpress.org/Function_Reference/get_post_type_object#Examples) and [`get_taxonomy();`](https://codex.wordpress.org/Function_Reference/get_taxonomy#Examples) It's kind of misleading having one object say there's no relationship. Then have the other object say there definitely is a relationship. So for my own sanity and keeping things consistent, I've been creating my Taxonomies first and Post Types second. I set the parameter (`$object_type`) to `null` in `register_taxonomy();` and then I specify the desired Taxonomies in the Taxonomies argument when using `register_post_type();`. I then follow up with my consistency of using: [`register_taxonomy_for_object_type( $taxonomy, $object_type );`](https://codex.wordpress.org/Function_Reference/register_taxonomy_for_object_type) That way, the relationship is clear when dealing with either object. Could this happen automatically? So that no matter which object you're dealing with, upon inspection, the relationship is clear. " michael.ecklund Future Releases 18848 Filter post listing screen by post parent johnbillion Posts, Post Types 3.3 normal normal feature request closed needs-unit-tests 2011-10-03T16:19:10Z 2020-09-20T12:56:01Z "It's not possible to filter a post listing screen by post_parent. This would be super handy for hierarchical post types (eg. Pages) where you may have several levels of hierarchy and want to view only the descendants of a particular page. I'm not sure that we need a UI (eg. dropdown menu) for it, but a working URL query var would be great. I made an attempt at patching this a while ago using the child_of parameter but it got complicated quite quickly, so I'm putting it out there as a feature request in case anyone feels like tackling it." johnbillion Next Release 18855 get_attached_file( $post_id ) wrongly(?) returns the uploads directory when $post_id is not a valid attachment nacin Post Thumbnails 3.2.1 normal normal 3.4 defect (bug) closed needs-unit-tests 2011-10-04T05:46:41Z 2012-04-27T16:09:10Z "The function `get_attached_file( $post_id )` wrongly(?) returns the uploads directory when `$post_id` is not a valid attachment. For example, if I run the following code: {{{ $attached_file = get_attached_file(0); }}} It might return the following on my machine: {{{ /Users/mikeschinkel/Sites/mysite/public_html/wp-content/uploads/ }}} I would instead expect it to simply return `false` indicating that no attached file was found: {{{ false }}} Here is the code I wrote that caused me to recognize the problem: {{{ function has_valid_file_attached( $attachment_id ) { return file_exists( get_attached_file( $attachment_id, true ) ) ); } }}} Here's the hack I had to write instead: {{{ function has_valid_file_attached( $attachment_id ) { $attached_file = get_attached_file( $attachment_id, true ); if ( '/' == substr( $attached_file, -1, 1 ) ) return false; if ( ! file_exists( $attached_file ) ) return false; return true; } }}} I have attached a patch that simply returns `false` when the value returned by the internal call to `get_post_meta( $attachment_id, '_wp_attached_file', true )` is an empty string. I would be surprised to find it many people (anyone?) used this function for it's side-effect to return the root upload path so I doubt using this path would break anything. It's not a critical patch because there is an easy workaround, but it cost me extra time to figure out why my `has_valid_file_attached()` function wasn't reporting `false` when the attachment was missing, so it would be nice to keep someone else from having to waste the same time in the future." mikeschinkel Next Release 23572 Add functions to parse Audio / Video data out of arbitrary content or a post markjaquith Post Formats normal normal 3.6 enhancement closed needs-unit-tests 2013-02-21T06:34:57Z 2013-04-12T18:02:53Z "= Scenarios == Audio After realizing that a post has a format of audio but no metadata for audio: - Theme does not support Audio, but the content contains an