__group__ ticket summary owner component _version priority severity milestone type _status workflow _created modified _description _reporter
Future Releases 16980 Empty Values are ignored by class-ixr.php XML-RPC 3.1 normal normal Future Release defect (bug) assigned 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 dev-feedback 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
Future Releases 35574 Add REST API JSON schema information to WP_Widget Widgets 2.8 normal normal Future Release enhancement new 2016-01-22T12:24:06Z 2017-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 dev-feedback 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 has-patch 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 has-patch 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 has-patch 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 has-patch 2020-03-06T18:02:23Z 2020-03-07T19:52:07Z "I cannot remove wrapping class in html widget:
...
It is defined here: https://github.com/WordPress/WordPress/blob/master/wp-includes/widgets/class-wp-widget-custom-html.php
I think it is job for some `apply_filters`.
Do we really need another `
';
} else {
$thelist .= implode( $separator, $links );
}
/**
* Filter the category or list of categories.
*
* @since 1.2.0
*
* @param array $thelist List of categories for the current post.
* @param string $separator Separator used between the categories.
* @param string $parents How to display the category parents. Accepts 'multiple',
* 'single', or empty.
*/
return apply_filters( 'the_category', $thelist, $separator, $parents );
}
}}}" pietergoosen
Future Releases 29586 Sync get_the_category_list with get_the_term_list Taxonomy 2.5 normal normal enhancement new 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
Future Releases 48153 Allow the admin email verification capability to be filtered Site Health 5.3 normal normal Future Release defect (bug) assigned has-patch 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 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 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
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 has-patch 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 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 dev-feedback 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 dev-feedback 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 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
Future Releases 50027 Retire Phpass and use PHP native password hashing Security normal normal Awaiting Review defect (bug) new dev-feedback 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 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 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 37756 Allow inline scripts on script aliases Script Loader 4.5 normal normal Future Release defect (bug) new 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 reporter-feedback 2015-11-05T11:01:37Z 2017-02-05T09:08:07Z "Current code in `do_item()` of class.wp-script.php on line 172:
{{{
$src = $this->base_url . $src;
}}}
may produce duplicate slashes `""//""`, resulting in problems.
This might be fixed with code:
{{{
$src = $this->base_url . $src;
}}}
Currently:
* WP_Scripts contains: `""public $base_url; // Full URL with trailing slash""` and
* script-loader.php contains calls `$scripts->add()` with initial `""/""` in relative paths
Together this produces doubled slashes `""//""`. For example:
http://www.ocelovehaly.cz/ll//wp-includes/js/jquery/jquery.js?ver=1.11.3
This makes W3TC include script in minified version, but not to remove it from the original HTML.
Including jQuery twice makes LayerSlider not to work.
Please, could you bugfix class.wp-script.php on line 172?
Thank you :-)" jan.mazanek
Future Releases 46089 Memory exhaustion when setting script translations on `wp-i18n` Script Loader normal normal Future Release defect (bug) new has-patch 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 dev-feedback 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 early 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 has-patch 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 has-patch 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 40340 """Attach to existing content"" modal shows posts and pages of other users" Role/Capability normal normal Awaiting Review defect (bug) reopened 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 has-patch 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 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 has-patch 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 dev-feedback 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 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 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 has-patch 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 has-patch 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 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 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 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 has-patch 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 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 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 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 has-patch 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 16839 Category Base Should be Slugified SergeyBiryukov* Rewrite Rules 3.1 normal normal Future Release defect (bug) accepted early 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 dev-feedback 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 has-patch 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 dev-feedback 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 has-patch 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 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 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 dev-feedback 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 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 reporter-feedback 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 16830 url_to_postid() doesn't resolve attachments when rewrite rules are disabled Rewrite Rules 1.2 normal normal enhancement reopened dev-feedback 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 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
Future Releases 40577 Introduce a capability for viewing the revisions of a post adamsilverstein Revisions 2.6 normal normal Future Release enhancement assigned 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
Future Releases 52925 Autosaves controller: Post checks will never catch invalid IDs REST API 5.8 normal normal Future Release defect (bug) new 2021-03-27T00:28:03Z 2021-06-08T22:56:03Z "The `create_item` and `create_post_autosave` methods both try to check if the id parameter in a request is for a valid post, by calling the get_post function. The problem is that both methods expect that if it's not a valid post, it will return a WP_Error object, when in fact get_post only returns null on failure.
The Posts controller has a protected get_post method that will generate an appropriate WP_Error for this case, but neither the Autosaves, nor its parent Revisions controller has a similar method. Copying that method to the Revisions controller, and then using it in the `create_*` methods seems like the best approach here." coreymckrill
Future Releases 54516 Full site editing/REST-API: modify permission checks to use post type. REST API 5.9 normal normal Future Release defect (bug) assigned has-patch 2021-11-25T23:39:15Z 2024-02-19T20:33:19Z "The new `wp_global_styles` post type is registered to use `edit_theme_options` in the capability settings.
The `WP_REST_Global_Styles_Controller` class's permission checks methods use the capability in a hard coded form rather than using `$post_type->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 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 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 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 has-patch 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 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 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 dev-feedback 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 has-patch 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 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 has-patch 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 has-patch 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 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 has-patch 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 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 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 dev-feedback 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 dev-feedback 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 dev-feedback 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 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 has-patch 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
Future Releases 51852 """any"" value in ""post_type"" param in ""get_posts"" by default ignore attachments" Query normal normal Future Release defect (bug) assigned early 2020-11-23T09:45:48Z 2021-02-18T00:24:52Z "When creating a simple call to get all posts for all post types by default to the parameters are adding `post_status` parameter with `publish` value.
{{{#!php
'any']);
}}}
To the `WP_Query` instance are supplied followed arguments:
{{{#!php
5
""category"" => 0
""orderby"" => ""date""
""order"" => ""DESC""
""include"" => []
""exclude"" => []
""meta_key"" => """"
""meta_value"" => """"
""post_type"" => ""any""
""suppress_filters"" => true
""post_status"" => ""publish""
""posts_per_page"" => 5
""ignore_sticky_posts"" => true
""no_found_rows"" => true
]
}}}
All attachment posts have `inherit` post status so by default are ignored in this query.
To actually get all post types the first function parameters should be expended by `post_status` parameter with `['publish', 'inherit']` value.
{{{#!php
'any', 'post_status' => ['publish', 'inherit']]);
}}}" dam6pl
Future Releases 18408 Can't wp_reset_postdata after custom WP_Query in an admin edit page audrasjb Query 4.7.2 normal normal Future Release defect (bug) assigned has-patch 2011-08-15T02:38:07Z 2024-02-19T22:14:25Z "While on an edit post page (or any post type), if you create a custom WP_Query object before the editor has been output, the post data from the custom WP_Query will fill out the edit post form, not the original content of the post that is actually trying to be edited.
I found this out when trying to create a custom metabox in the 'side' context. You can reproduce this by inserting this code into a plugin:
{{{
add_action( 'add_meta_boxes', 'myplugin_add_custom_box' );
function myplugin_add_custom_box() {
add_meta_box(
'myplugin_sectionid',
__( 'My Post Section Title', 'myplugin_textdomain' ),
'myplugin_inner_custom_box',
'post',
'side'
);
}
function myplugin_inner_custom_box() {
global $post;
$a = new WP_Query('post_type=page');
while($a->have_posts() ) : $a->the_post();
endwhile;
wp_reset_postdata();
}
}}}
This happens because $wp_query->post is never defined in the admin load, which wp_reset_postdata relies on to reset the original post data.
I am attaching a patch that defines $wp_query->post after the $post global has been defined. " ericlewis
Future Releases 42164 Conditional Tags not working when using ugly URL Query 4.8.2 normal normal Awaiting Review defect (bug) new 2017-10-10T10:23:14Z 2017-10-10T13:54:21Z "When accessing a category archive via its pretty URL e.g.
{{{
example.com/category/whatever
}}}
the conditional tag
{{{
is_category()
}}}
returns '''true'''.
Accessing the same category archive via its ugly URL
{{{
example.com?cat=whatever
}}}
the conditional tag
{{{
is_category()
}}}
returns '''false'''.
I'm pretty sure this concerns other conditional tags too. This is not only a cosmetic flaw because it causes WP to use the wrong template. I've tested it with Twenty Seventeen and the homepage template was used in case of using an ugly URL.
Due tue the ugly URL always work independently of permalink settings this is a bug in my opinion." petersplugins
Future Releases 39540 NOT EXISTS meta condition doesn't work if meta has NULL value. Query 4.7 normal normal Future Release defect (bug) new 2017-01-10T16:42:19Z 2020-07-14T05:36:51Z "It seems problem exists since meta query class release.
Right now NOT EXISTS works only if meta doesn't exist at all, but if it has NULL value we got incorrect result. I understand that better not use NULL values with metas at all, but you allow to write NULL as meta value, so please add possibility to check it.
Just need to change string in class-wp-meta-query.php:
{{{
$sql_chunks['where'][] = $alias . '.' . $this->meta_id_column . ' IS NULL';
}}}
For example on:
{{{
$sql_chunks['where'][] = ""$alias.meta_value IS NULL"";
}}}
And both cases will be covered.
Thank you in advance.
" avahura
Future Releases 56992 The Loop displays incorrect data for queries started with `fields => 'id=>parent'`. Query 3.1 normal normal Awaiting Review defect (bug) new 2022-11-04T01:17:36Z 2022-11-04T01:17:36Z "Using the Loop on custom `WP_Query` objects started with `fields => 'id=>parent'` will set the global post object incorrectly. Instead of containing all data, the global post object will only contain the post's ID and parent fields. All other fields are the default value.
The following test demonstrates the issue:
{{{#!php
post->create( array( 'post_type' => 'page' ) );
$child = self::factory()->post->create( array( 'post_type' => 'page', 'post_parent' => $parent ) );
$query = new WP_Query(
array(
'fields' => 'id=>parent',
'post_type' => 'page',
'page_id' => $child,
)
);
$query->the_post();
$global_post = get_post( null, ARRAY_A );
$specific_post = get_post( $child, ARRAY_A );
$this->assertEqualSetsWithIndex( $global_post, $specific_post );
}
}}}
The cause of the error is within `WP_Query::next_post()` which assumes the `WP_Query::$posts` property contains full post objects which isn't nessesarily the cause if a sub-set of fields is requested. See the [https://core.trac.wordpress.org/browser/tags/6.0.3/src/wp-includes/class-wp-query.php?marks=3447-3449#L3447 source code].
Due to #56948 the test above will currently throw an error on trunk but it will demonstrate the problem if you check out the 6.0 branch.
I suspect this has been an issue since the fields parameter was introduced in #14777 for version 3.1 but I am unable to test that far back due to PHP versions I have available on my local config." peterwilsoncc
Future Releases 51094 WP_Query.query with invalid post_status will return all metalandcoffee* Query 3.9 normal critical Future Release defect (bug) accepted dev-feedback 2020-08-21T12:18:59Z 2022-06-14T20:01:36Z "Hello, I noticed an issue with WooCommerce method {{{ wc_get_products }}} and dove into the issue.
The problem was {{{ wc_get_products(array('status' => 'published')); }}} would return **ALL** posts, even trashed ones because of the ""published"" status is not a valid post status.
I believe that behavior is unexpected that it should return **NO** posts.
The issue appears to be this portion of {{{WP_Query.get_posts}}} that only known post statuses are added to the query:
{{{#!php
posts}.post_status = '$status'"";
} else {
$r_status[] = ""{$wpdb->posts}.post_status = '$status'"";
}
}
}
}}}
I believe it would best if this method checks for any unrequested post status supplied in the query and either applies them to the query or produces an error. I would imagine this is a pretty major change." carsonreinke
Future Releases 27015 WP_Query::get_queried_object() does not always work in 'pre_get_posts' Query 3.8 normal normal Future Release defect (bug) new has-patch 2014-02-05T00:58:42Z 2021-07-10T07:37:03Z "Related: #26627
The referenced ticket fixes the situation for categories. Inline docs indicate the method returns objects for the following query types: '''category, tag, taxonomy, posts page, single post, page, author'''.
Some of these work, some do not. This became apparent from the forums:
http://wordpress.org/support/topic/get_queried_object-no-longer-working-with-pre_get_posts-and-pretty-permalinks/
Props jeich
Test setup.
Trunk at r27067 used. (and 3.7 for regression check)
Default setup of fresh install except for the following as plugin:
* Hook 'pre_get_posts' and dump get_queried_object return if it is_main_query
* Add custom taxonomy and associate with posts
* Register CPT
Change permalink setting to complete CPT rewrite registration
Also modify the DB as follows to test various query types:
* Add a tag to the Hello World post.
* Add a custom taxonomy term to the Hello World post.
* Add a CPT post
The site was browsed through various pages using the default (none) permalink, then the month and name permalink. The result of getting a queried object was recorded:
|| ||=no permalink =||=month and name=||
||uncategorized category ||stdClass object ||stdClass object||
||tag archive ||NULL ||NULL||
||taxonomy term archive ||stdClass object ||stdClass object||
||CPT archive ||stdClass object ||stdClass object||
||single post ||NULL ||NULL||
||single CPT ||NULL ||NULL||
||page ||NULL ||WP_Post object||
||author archive ||WP_User object ||False||
||posts page ||WP_Post object ||WP_Post object||
NULLs indicate failure of `get_queried_object()`. Except for tag archive, all NULLs returned are due to regression prior to 3.7. Why the tag archive failed in 3.8 is unclear, but the proposed patch addresses this issue as well as all other NULL returns.
For those that don't know, the reason for different results with pretty permalinks enabled is different query vars are defined when rewrite rules are applied. The default no pretty permalinks does not use rewrite rules and the query vars can only be what is parsed from the request.
" bcworkz
Future Releases 44695 WP_Term_Query unexpected 'orderby' behaviour. Query 4.9.7 normal normal Awaiting Review defect (bug) new 2018-08-01T21:19:14Z 2019-08-27T18:33:22Z "I expected that `orderby` would behave in a similar way with `WP_Term_Query` as it does on other `*_Query` classes but it seems that `meta_value_date` and possibly some others is unsupported. Additionally `meta_type` doesn't function as expected either.
These args:
{{{
$args = array(
'taxonomy' => 'issues',
'number' => 5,
'meta_key' => 'issue_date',
'meta_type' => 'DATE',
'orderby' => 'meta_value_date',
);
}}}
Result in this query that has disregarded both `meta_type` and `orderby` in it's generation:
{{{
SELECT DISTINCT t.*, tt.* FROM wp_terms AS t INNER JOIN wp_termmeta ON ( t.term_id = wp_termmeta.term_id ) INNER JOIN wp_term_taxonomy AS tt ON t.term_id = tt.term_id WHERE tt.taxonomy IN ('issues') AND tt.count > 0 AND ( wp_termmeta.meta_key = 'issue_date' ) ORDER BY t.name ASC LIMIT 5
}}}
Could we get similar support for same named keys in `WP_Term_Query` as we have in other queries?" williampatton
Future Releases 52559 When doing JOINs for meta queries the meta_key should be in the ON clause whenever possible. Query normal normal Awaiting Review defect (bug) new 2021-02-17T17:17:35Z 2021-04-26T07:45:57Z "Currently when doing `JOIN`s for meta queries the meta_key is only included in the `ON` clause if the meta compare is `NOT EXISTS`. In all other cases only the `post_id` is included.
This means that the meta key is only filtered after the JOIN is done.
Case in point, a meta_query that with 5 different keys generates the following query:
{{{#!sql
SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts
LEFT JOIN wp_postmeta ON ( wp_posts.ID = wp_postmeta.post_id )
LEFT JOIN wp_postmeta AS mt1 ON ( wp_posts.ID = mt1.post_id )
LEFT JOIN wp_postmeta AS mt2 ON ( wp_posts.ID = mt2.post_id )
LEFT JOIN wp_postmeta AS mt3 ON ( wp_posts.ID = mt3.post_id )
LEFT JOIN wp_postmeta AS mt4 ON (wp_posts.ID = mt4.post_id AND mt4.meta_key = 'events_time_frame_end' )
WHERE 1=1 AND (
( wp_postmeta.meta_key = 'events_date_till' AND wp_postmeta.meta_value >= '20210217' )
AND
(
( mt1.meta_key = 'events_date_till' AND mt1.meta_value > '20210217' )
OR
(
( mt2.meta_key = 'events_date_till' AND mt2.meta_value = '20210217' )
AND
( mt3.meta_key = 'events_time_frame_end' AND mt3.meta_value >= '14:59:19' )
)
OR
mt4.post_id IS NULL
)
) AND wp_posts.post_type = 'events' AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'acf-disabled' OR wp_posts.post_status = 'dp-rewrite-republish') GROUP BY wp_posts.ID ORDER BY wp_postmeta.meta_value ASC LIMIT 0, 10;
}}}
This query takes 60 seconds on very well provisioned database with posts that each have 50 postmeta rows in a database with 50 million total postmeta rows.
In contrast the following query:
{{{#!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 = 'events_date_till' )
LEFT JOIN wp_postmeta AS mt1 ON ( wp_posts.ID = mt1.post_id AND mt1.meta_key = 'events_date_till' )
LEFT JOIN wp_postmeta AS mt2 ON ( wp_posts.ID = mt2.post_id AND mt2.meta_key = 'events_date_till' )
LEFT JOIN wp_postmeta AS mt3 ON ( wp_posts.ID = mt3.post_id AND mt3.meta_key = 'events_time_frame_end' )
LEFT JOIN wp_postmeta AS mt4 ON (wp_posts.ID = mt4.post_id AND mt4.meta_key = 'events_time_frame_end' )
WHERE 1=1 AND (
( wp_postmeta.meta_value >= '20210217' )
AND
(
( mt1.meta_value > '20210217' )
OR
(
( mt2.meta_value = '20210217' )
AND
( mt3.meta_value >= '14:59:19' )
)
OR
mt4.post_id IS NULL
)
) AND wp_posts.post_type = 'events' AND (wp_posts.post_status = 'publish' OR wp_posts.post_status = 'acf-disabled' OR wp_posts.post_status = 'dp-rewrite-republish') GROUP BY wp_posts.ID ORDER BY wp_postmeta.meta_value ASC LIMIT 0, 10;
}}}
Takes 400ms and returns identical results.
I believe the cause here is that because in the first query filtering is only done after the join and each event has 50 postmeta fields MySQL is first creating a virtual table with 50^4^ ( 4 because the last JOIN does include the meta_key ) rows joined resulting in 60.000.000 total that are then filtered back down.
Adding the meta_key condition to the `ON` clause means we're only joining 1 ( or a small number in the case of the meta_key existing in multiple rows ) rows for each JOIN meaning the virtual table being created is significantly smaller thus having much better query performance.
At the very least when there is any LEFT JOIN occurring then ALL `meta_key` conditions should be moved in the `ON` clause. Although it may be simpler to always have the `meta_key` condition in the `ON` clause." herregroen
Future Releases 44964 `redirect_guess_404_permalink` doesn't support array in `post_type` var Query 4.9 normal normal Awaiting Review defect (bug) new dev-feedback 2018-09-19T09:35:59Z 2018-10-01T12:37:02Z `redirect_guess_404_permalink` doesn't support array in post_type var, but other core WordPress parts support it. viliamkopecky
Future Releases 37530 is_front_page() is based on wrong data -> gives wrong results Query 4.5.3 normal normal Future Release defect (bug) new has-patch 2016-07-31T14:28:49Z 2020-01-07T20:25:04Z "1) is_front_page() is based on the SQL query, so it always gives back false when you try to use it eg at pre_get_posts. If it has no way to figure it out if it's the front page or not, it should return null instead
2) is_front_page() in themes gives the wrong result false back when you set an static page for the front page and then modify the main query on start page to posts or any other custom post type except page. This forces you to make an additionally SQL query instead of using the main query to build a custom front page.
Both is because of this: https://core.trac.wordpress.org/browser/tags/4.5.3/src/wp-includes/query.php#L4458 . This does not really make sense to get the front page." TheInfinity
Future Releases 58234 sanitize_title_with_dashes fatal error when query var value is an array in php 8 Query normal normal Awaiting Review defect (bug) new reporter-feedback 2023-05-02T13:38:13Z 2023-08-08T23:23:11Z "Using latest WordPress development version 6.3-alpha-55505-src, when submitting a form with field values that are array, and the array key is one of WordPress query vars, that causing sanitize error for 'post_name' parameter in get_posts function.
Example to replicate:
- make sure to register custom post type E.g custom_post_type.
- submit the following form on your test WordPress website.
{{{
}}}
" mouhdev
Future Releases 56105 Call update_post_parent_caches in the_post function in WP_Query class Query normal normal Awaiting Review enhancement new 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 dev-feedback 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 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 dev-feedback 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 has-patch 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 has-patch 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 has-patch 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 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 has-patch 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 early 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 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 has-patch 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 dev-feedback 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 has-patch 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 15249 Filtering get_search_sql for advanced queries Query 3.1 normal normal enhancement assigned 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 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 has-patch 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 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 20352 Use str_getcsv() to parse search terms in WP_Query Query normal normal enhancement new has-patch 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 has-patch 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
Future Releases 44236 Maintain consistency between privacy export report and archive filenames GripsArt Privacy 4.9.6 low minor Future Release defect (bug) assigned has-patch 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 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 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 dev-feedback 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 dev-feedback 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 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 has-patch 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 47279 $post object passed to clean_post_cache action can contain outdated values Posts, Post Types normal normal Future Release defect (bug) new 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 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 has-patch 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 has-patch 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 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 has-patch 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 dev-feedback 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 has-patch 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 has-patch 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 has-patch 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 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 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 dev-feedback 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 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 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 dev-feedback 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 changes-requested 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 has-patch 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 has-patch 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 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 16843 wp_unique_post_slug() doesn't check pagination base when CPT has archive Posts, Post Types 3.1 normal minor defect (bug) new has-patch 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 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 has-patch 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 36406 $network_wide is unreliable Plugins 3.0 normal critical Future Release defect (bug) reviewing has-patch 2016-04-03T09:20:33Z 2019-07-09T10:20:39Z "This issue may be related to ticket #31104
Scenario:
In a WordPress network an admin decides a plugin must not be network activated. Only a per site or even a site specific activation shall be allowed.
Idea:
Conditional check during plugin activation and die with an error message if $network_wide is true.
Result:
Plugin does not get activated but the custom error message is not displayed
Assume the following function run during activation (it is simplified and the real activation sequence does not have echos!)
{{{
function test_activation_hook( $network_wide ) {
echo '1 | ';
// exit( 1 );
if ( is_multisite() ) {
echo '2: | ';
// exit( 2 );
if ( $network_wide ) {
echo '3: | ';
// exit( 3 );
} else {
echo '4: | ';
// exit( 4 );
}
} else {
echo '5: | ';
// exit( 5 );
}
echo '6: | ';
exit( 6 );
}
}}}
If you exit after if(is_multisite) the message displayed will be '1 | 2 |'
If you exit after if($network_wide) during a networkwide activation the message displayed is '1 | 2 | 4 | 6' instead of '1 | 2| 3|'
Exiting at 4, 5, or 6 will display '1 | 2| 4|', '1 | 2| 5|' and '1 | 2| 6|' as expected.
After many hours of debuging I realized the function (the action filter 'activate_' . $plugin) gets executed 3 times if you exit it early. And only the first call has the argument $network_wide set to true if it is an network_wide activation.
If you like to exit at 3, that is you do not want a network activation, the flow is therefore as follows:
- The first run (click on network activate) has $network_wide set to true and will exit at 3
- the second run (no idea why) has $network_wide set to false and will pass 1 | 2 | 4 | 6
- the third run (no idea why) has $network_wide set to false and will pass 1 | 2 | 4 | 6
Imho calling the activation function (or the code) three times in case you exit it (better say terminate because you cant end a plugin installiton clean) is wrong at all. However if this is by design then $network_wide must be reliably set to true if it originally was.
" mensmaximus
Future Releases 43489 Strengthen resilience of wp_register_plugin_realpath to support Gutenberg Plugins normal normal Awaiting Review defect (bug) new 2018-03-07T18:25:25Z 2020-12-01T05:24:00Z "For many years now I've been working in a Windows development environment with multiple subdirectory installs referencing plugins using symlinks.
Every now and then I get problems due to plugin files apparently not being present when they quite clearly are. I have not been able to track it down. I think it's a bug in PHP associated with OpCache.
Anyway, the bottom line is that sometimes this problem, or something similar, results in the `$wp_plugin_paths` array containing entries with a null value for `$realdir`.
This can lead to the following:
`Warning: strpos(): Empty needle in C:\apache\htdocs\hm\wp-includes\plugin.php on line 658.`
This message has the uncanny knack of happening at the most inappropriate times.
Now, with Gutenberg looming, the problem is further reducing my ability to create content locally; Gutenberg can't handle the unexpected Warnings and Notices from a development server and fails. See https://github.com/WordPress/gutenberg/issues/5439
To reduce the likelihood of the problem I'd like to propose a change to `wp_register_plugin_path()` to cater for a false value being returned from the `realpath()` PHP function.
The proposal being that if `$plugin_realpath` does appear to be null, then don't add an entry in `$wp_plugin_paths`.
This change will prevent the warning message being issued from plugin_basename()'s test
{{{
if ( strpos( $file, $realdir ) === 0 ) {
}}}
and therefore increases the robustness of the system.
Bottom line.
- `realpath()` may return false.
- This should be catered for.
" bobbingwide
Future Releases 45374 apply_filters_ref_array() no longer passes arguments by reference Plugins 4.7 normal normal Awaiting Review defect (bug) new 2018-11-19T10:58:35Z 2019-01-25T13:54:36Z "It appears that since the introduction of the `WP_Hook` class in WordPress 4.7 (#17817), `apply_filters_ref_array()` no longer passes its arguments by reference.
Example:
{{{
add_filter( 'posts_clauses', function( $clauses, &$query ) {
return $clauses;
}, 10, 2 );
}}}
The above code will trigger the following PHP warning:
{{{
Parameter 2 to {closure}() expected to be a reference, value given
}}}
cc @jbrinley FYI" johnbillion
Future Releases 9968 dynamically adding/removing filters breaks plugins Plugins low normal Awaiting Review defect (bug) reopened 2009-05-28T23:43:11Z 2020-03-02T15:43:22Z "noticed this while doing something similar to this:
{{{
add_action('foo', 'bar1', 10);
add_action('foo', 'bar2', 20);
function bar1() {
remove_filter('foo', 'bar1', 10);
}
}}}
in the above, bar2() doesn't get called. it is because of the usage of next()/current() to loop through filters.
attached patch uses a foreach loop instead, to make it work." Denis-de-Bernardy
Future Releases 34358 plugin_dir_url( __FILE__ ) returns plugins directory when plugin symlinked to mu-plugins Plugins 4.3.1 normal normal Future Release defect (bug) new has-patch 2015-10-19T17:53:00Z 2017-10-02T15:02:25Z "With a plugin symlinked to the mu-plugins folder, paths to find assets via the URL are broken if using `plugin_dir_url()`. This does not happen when using the `WPMU_PLUGIN_URL` constant. However, if using the constant then the plugin is not portable to the normal `plugins` directory without additional checks.
{{{#!php
without losing your data, see the details at http://example.com/plugin-uninstall.
Notes:
- Such a string should of course be optional to preserve backward compatibility.
- Appropriate filtering and length checks should be done on the string to ensure that the uninstall plugin UI isn't easily broken or disturbed. This avoids the plugin author filling the field with a string that stops the user from being unable to uninstall the plugin." cefiar
Future Releases 20241 make it possible for plugins to activate other plugins Plugins normal normal Future Release enhancement assigned has-patch 2012-03-15T12:48:59Z 2022-08-05T22:43:52Z "When creating a plugin that depends on other plugins, i would like to enable those plugins during activation of the main plugin.
This is currently not possible, as updates to active_plugins done by the other plugins get overwritten.
Please apply the attached patch to fix this." magnus78
Future Releases 19388 plugin_basename returns full directory in URL Plugins 3.3 normal normal enhancement new has-patch 2011-11-29T00:36:36Z 2019-06-04T20:42:35Z "If a trailing slash is specified on either then WP_PLUGIN_DIR or WPMU_PLUGIN_DIR settings, the plugin_basename function returns the whole directory path in the URL.
The documentation does state not to use a trailing slash, however I think this function could be improved.
By removing the explicit / in the preg_replace the correct plugin name will be returned even if a trailing slash is specified on the WP_PLUGIN_DIR or WPMU_PLUGIN_DIR constants.
This should not affect the relative path as the trim before the return takes care of stripping off the first slash if it exists (effectively duplicating the remove in this case).
While this is a very trivial change that won't affect most people (who read the docs properly) it was quite annoying to track down.
Please see the attached diff." damianzaremba
Future Releases 5130 Linking to multiple posts on your site breaks pingback due to comment flooding Pings/Trackbacks 2.3 normal normal Future Release defect (bug) new has-patch 2007-10-01T17:36:13Z 2023-03-22T11:30:42Z "http://scott.sherrillmix.com/blog/programmer/web/wp_pingpreserver/
is this useful in WP 2.3?" Denis-de-Bernardy
Future Releases 45389 trackback_url_list() trackback excerpt for multibyte correspondence SergeyBiryukov Pings/Trackbacks normal normal Future Release defect (bug) reviewing dev-feedback 2018-11-21T08:15:18Z 2019-01-16T02:57:17Z In the case of multibyte, the last letter of the trackback excerpt may be garbled. ishitaka
Future Releases 37938 Make existing HTML parsing functionality from REST API and Press This reusable kraftbj* Pings/Trackbacks 4.2 low minor Future Release enhancement accepted 2016-09-03T17:08:26Z 2023-05-30T11:34:09Z "WordPress already has an HTML parsing function in the form of WP_Press_This::source_data_fetch_fallback and its private called functions.
Suggesting this be split off so it can be used elsewhere. Specifically, my use case is over on the Ping and Trackbacks component. One of the proposals I keep advocating for is improving the presentation.
As we already have this code in WordPress that allows for parsing of HTML for images, embeds, meta tags, etc, it should be used over writing new code to do the same.
But if it were to be called right now, it would reretrieve source HTML already retrieved by the Pingback code and passed into the comment array." dshanske
Future Releases 35435 Support Webmentions Pings/Trackbacks normal normal Future Release feature request new 2016-01-13T05:25:25Z 2018-02-19T11:52:22Z "Webmention is now a W3C Recommendation as of January 12, 2017. https://www.w3.org/TR/webmention/ . Previous linkback protocols(trackback and pingback) did not achieve this status.
The Webmention is a simplified evolution of the Pingback. It drops XML-RPC in favor of simple form encoding. The recommendation calls for asynchronous processing to prevent DoS attacks.
There is already a webmention plugin for WordPress in the repository. https://wordpress.org/plugins/webmention/ and this could be used as a basis for a feature plugin to merge into core.
Trackbacks and Pingbacks both have their unique problems. The idea of linkbacks in general remains a good one, spoiled by less robust implementations. To go to the logical extreme, suggesting that adoption of webmentions be concurrent with the disabling by default of the earlier and less secure protocols.
Finally, no feature should be adopted in WordPress unless it has users...the pingback implementation in WordPress displays pingbacks in a way that does not convey useful meaning.
Current implementations of Webmention parse the HTML to generate a comment or other richer forms of response that are more useful to a site than what is currently available. The proof of concept for this is in the Semantic Linkbacks plugin https://wordpress.org/plugins/semantic-linkbacks . " dshanske
Future Releases 31384 Pingback does not work for schemeless URLs Pings/Trackbacks 1.5 normal normal defect (bug) new has-patch 2015-02-19T17:03:29Z 2019-06-04T20:49:17Z "I noticed that a pingback will not be send if the target URL is given as a schemeless URL (like {{{//www.example.com/path/file.ext}}}.
This is because discover_pingback_server_uri() in comment.php is using the PHP function parse_url() which cannot handle schemeless URLs correctly." tobiaskochsonlinenet
Future Releases 36765 Remove Legacy Code from pingback_ping Pings/Trackbacks 4.1 normal normal defect (bug) new dev-feedback 2016-05-05T14:59:53Z 2019-06-04T20:58:45Z "Proposing we remove the legacy conditional url_to_postid and //$way debugging line leftover from [30139].
{{{
/ let's find which post is linked to
// FIXME: does url_to_postid() cover all these cases already?
// if so, then let's use it and drop the old code.
}}}
Related: #34419
" dshanske
Future Releases 23915 discover_pingback_server_uri cases an error when discovery URI sets multiple Content-type headers dd32 Pings/Trackbacks 2.7 normal normal defect (bug) assigned 2013-04-01T14:25:25Z 2019-06-04T20:44:00Z "Line 1673 in wp-includes/comment.php uses preg_match() on the output of wp_remote_retrieve_header(). When multiple headers are set of the same name, wp_remote_retrieve_header() returns an array.
Thus occasionally the following error occurs:
PHP Warning: preg_match() expects parameter 2 to be string, array given in xxxxxxx/wp-includes/comment.php on line 1673
I have no idea how to make pingbacks happen so to reproduce, add this line to functions.php: discover_pingback_server_uri('http://localhost:8080/');
And in a terminal window run this (you may need to install the netcat-openbsd package in Debuntu):
`while true; do echo -en 'HTTP/1.1 200 OK\r\nContent-type: text/html\r\nContent-type: text/plain\r\n\r\n' | nc -lp 8080; done`
Then visit your WP installation and you shall get the aforementioned error message." tomdxw
Future Releases 27158 do_enclose() throws warnings when content_type is text/html and not audio or video Pings/Trackbacks 3.8.1 normal normal defect (bug) new 2014-02-19T17:25:58Z 2019-06-04T20:45:45Z "cron calls do_pings()/do_all_pings() which in turn goes on to do_enclose().
PHP Warning: strpos() expects parameter 1 to be string, array given in /var/vhost/site/wp-includes/functions.php on line 505
$url is valid, $type is ""text/html; charset=UTF-8"", $len is valid as well.
$allowed_types is array(0=>video, 1=>audio)
server environment:
PHP 5.5.3-1ubuntu2.1
Apache 2.4.6
running WP 3.8.1, no multisite
" tamas_dxw
Future Releases 34419 Update Pingback Processing Code Pings/Trackbacks normal minor enhancement new 2015-10-23T21:36:25Z 2019-06-04T20:52:31Z "Related to #34141, which would pass the retrieved pingback source to preprocess_comment and comment_post for additional processing, pingback_ping currently strips all content from the source as part of its processing.
Suggesting that specifically:
1. Sanitization be done using core sanitization functions(wp_kses, etc)
2. The code that returns relevant errors(URL not found, etc), be processed ahead of anything else.
3. The older code that duplicates the functionality of url_to_postid noted as FIXME be removed. If there really is another difference, that should be an enhancement to url_to_postid.
This, combined with the enhancements in #34141, would allow moving toward improving linkback presentation(#32653), which is a long term goal." dshanske
Future Releases 37812 404 when using a numeric slug and /%category%/ base Permalinks normal normal Future Release defect (bug) new 2016-08-24T15:29:53Z 2023-03-11T11:36:36Z "To reproduce:
1. Create a top and sublevel category. Lets say Parent > Child
2. In permalink settings, set custom permalink structure /%category%/%postname%/
3. Create a post with slug 12345 and assign to category ""child""
4. View post.
There is a 404.
Tested in 4.6 only. No other plugins active." mikejolley
Future Releases 55189 "Automatic removal of ""Zero-width non-joiner"" in URL" Permalinks 5.9 normal critical Future Release defect (bug) new dev-feedback 2022-02-17T14:30:25Z 2023-02-23T23:37:32Z "There is a big problem in recent version of WordPress, ""[https://en.wikipedia.org/wiki/Zero-width_non-joiner Zero-width non-joiner]"" in the URLs is removed automatically.
This will have a very bad effect on SEO (and has affected many sites) because the page with ""Zero-width non-joiner"" in their URL will goes to be 404.
" man4toman
Future Releases 9102 Inverse proxy breaks permalinks Permalinks 2.7 normal normal Future Release defect (bug) assigned has-patch 2009-02-12T01:58:37Z 2024-03-19T19:43:03Z "I have a WP installation at my university's webspace (on an apache server), say http://myuni.ac.at/mydir/wordpress/ , and an inverse proxy domain http://mydomain.at/ for it.
This means that any request to the latter, eg for http://mydomain.at/2009/02/12/inverse-proxy-trouble/ , is forwarded to http://myuni.ac.at/mydir/wordpress/ , which in turn means that the REQUEST_URI there becomes /mydir/wordpress/2009/02/inverse-proxy-trouble/ . My ''home'' variable is of course set to http://mydomain.at/ (''siteurl'' is set to http://myuni.ac.at/mydir/wordpress/ -- otherwise I wouldn't be able to login to WP).
Unfortunately, when analyzing REQUEST_URI, wordpress chops off the ''home'' path, not the ''siteurl'' one. This may be okay for some purposes, but in the inverse proxy case, permalinks break. For a fix, I had to hack two wordpress core files, namely
wp-includes/classes.php
in function parse_request: change line 162 from
{{{
$home_path = parse_url(get_option('home'));
}}}
to
{{{
$home_path = parse_url(get_option('siteurl'));
}}}
and wp-includes/rewrite.php, in function get_pagenum_link, line 987, same modification.
This is a dirty hack, of course; so I wonder if in general, using the ''siteurl'' path is valid in any case where the ''home'' host differs from the ''siteurl'' host. If so, I suggest changing the affected files in such a manner." Bernhard Reiter
Future Releases 3329 Need to strip % from the auto-permalink in the editor. pishmishy* Permalinks 2.0 normal normal Future Release defect (bug) accepted dev-feedback 2006-11-04T20:41:06Z 2023-02-02T12:43:17Z "I made an article with ""x = 18,98 * y - %10"" as title, and this generated http://www.example.com/blog/2006/11/03/x-1898-y-%10/ which doesn't work." Heyneken
Future Releases 10249 Page slug in cyrillic = Error 404 - Not Found! westi Permalinks 4.9.5 normal normal Future Release defect (bug) reopened has-patch 2009-06-23T19:44:34Z 2022-06-22T01:20:33Z "When I create a page with page slug for example ""киро""
then when I try to open domain/киро - Error 404 - Not Found
The permalinks are %postname%
Post slug with this slug is working just fine, the same BUG exists in 2.7, 2.7.1 and 2.8" kalifi
Future Releases 34972 Permalink for unattached media same as a post Permalinks 4.4 normal normal Future Release defect (bug) new 2015-12-10T11:53:16Z 2018-12-17T21:55:36Z "First step - upload media ""tralala.jpg"" I got pretty link example.com/tralala/
Second step - create a post with Title ""Tralala"" it creates post with slug example.com/tralala/ this works.
So post with the same title as unattached media filename creates the same permalink - slug as already exists for unattached media.
In this case, unattached media is unreachable as permalink point to new post with the same slug." petercralen
Future Releases 44847 Redirect old date-based permalinks on structure changes Permalinks normal normal Awaiting Review defect (bug) new 2018-08-27T13:43:48Z 2019-01-08T07:14:12Z "If someone switches from `/%year%/%monthnum%/%day%/%postname%/` to `/%postname%/`:
* `/%year%/%postname%/` redirects to the correct URL.
* `/%year%/%monthnum%/%postname%/` shows a 404 error.
* `/%year%/%monthnum%/%day%/%postname%/` shows a 404 error.
All of these URLs should redirect to the correct one." SergeyBiryukov
Future Releases 43789 the_posts_pagination() outputs the slash at the first link Permalinks 4.9.5 normal normal Future Release defect (bug) new 2018-04-17T19:25:04Z 2021-09-17T12:21:50Z "Hello.
Permanent link settings: `http://wp-test.ru/%postname%` (without a slash on the end)
On the second and other pages of pagination, any category has a link to the first page with a slash on the end.
{{{
http://wp-test.ru/category/bez-rubriki/ (with a slash on the end, why?)
http://wp-test.ru/category/bez-rubriki/page/2
http://wp-test.ru/category/bez-rubriki/page/3 (current page)
.....
}}}
" campusboy1987
Future Releases 42148 url_to_postid plain permalinks for CPTs Permalinks 1.0 normal normal Awaiting Review enhancement new 2017-10-08T11:42:20Z 2017-10-08T11:46:15Z "Would be nice to have {{{url_to_postid}}} working with plain permalinks for custom post types.
There's are currently some issues in {{{url_to_postid}}} where the wrong ID is returned for custom post type plain permalinks (query-based).
{{{
true
) );
/** Create a post */
$post_id = wp_insert_post( array( 'post_type' => 'findme', 'post_status' => 'publish' ) );
$findme = get_permalink( $post_id );
$found = url_to_postid( $findme );
/** Guess it */
printf( ""%s (%s) == %s (%s)"", $post_id, $findme, $found, get_permalink( $found ) );
exit;
} );
}}}
{{{30 (http://localhost:8080/?findme=30) == 0 ()}}} and {{{30 (http://localhost:8080/?findme=30) == 2 (http://localhost:8080/)}}} if the frontpage is setup to point ot a post.
Why is it not working? Why is the frontpage post being returned? Let's see how the {{url_to_postid}} function works:
{{{
// First, check to see if there is a 'p=N' or 'page_id=N' to match against
if ( preg_match('#[?&](p|page_id|attachment_id)=(\d+)#', $url, $values) ) {
$id = absint($values[2]);
if ( $id )
return $id;
}
}}}
Then?
{{{
if ( trim( $url, '/' ) === home_url() && 'page' == get_option( 'show_on_front' ) ) {
$page_on_front = get_option( 'page_on_front' );
if ( $page_on_front && get_post( $page_on_front ) instanceof WP_Post ) {
return (int) $page_on_front;
}
}
}}}
Uh, wait what... already? So a short-circuit without checking the custom post types. And that's understandable, since there is inherently no support for custom post type ID mappings as pointed out by:
{{{
// Check to see if we are using rewrite rules
$rewrite = $wp_rewrite->wp_rewrite_rules();
// Not using rewrite rules, and 'p=N' and 'page_id=N' methods failed, so we're out of options
if ( empty($rewrite) )
return 0;
}}}
What stands in our way to find the URL earlier?
1. The query var is not one of p, page_id, attachment_id
2. The query var value for CPTs is not necessarily, and most often not numeric (the post_title)
A proposed solution would be to look at the query parameters much higher, maybe by injecting the custom ones, ones that support slugs as well, since WordPress sets the {{{page_title}}} for a CPT itself, so that {{{\d+}}} check would fail.
Use case? Well, this was encountered when trying to paste plain oEmbed URLs for a custom post type (https://github.com/gravityview/GravityView/issues/927)." soulseekah
Future Releases 17450 Almost pretty permalinks with non-ASCII characters do not work in Apache westi Permalinks 3.1 normal normal defect (bug) reopened 2011-05-16T05:53:14Z 2019-06-04T20:42:05Z Almost pretty permalinks (using PATH_INFO) with non-ASCII characters do not work in Apache; a not found error is returned. The same permalink works in IIS when UTF-8 is used for server variables. It also works when mod_rewrite is used. peaceablewhale
Future Releases 28156 In date-containing permalink structures, /dddd/dd/comment-page-d/ urls don't work Permalinks 3.9 normal normal defect (bug) new dev-feedback 2014-05-06T22:42:17Z 2019-06-04T20:46:56Z "I was in the process of writing a plugin to allow people to test their rewrite rules as they develop a site, and when I setup examples of core rewrite rules, one of them was failing.
If you set your permalink structure to one containing dates, e.g. ""Day and Name"", one of the generated rewrite rules for posts is:
{{{
'([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/([^/]+)(/[0-9]+)?/?$' => 'index.php?year=$matches[1]&monthnum=$matches[2]&day=$matches[3]&name=$matches[4]&page=$matches[5]'
}}}
And later on, another rule is:
{{{
'([0-9]{4})/([0-9]{1,2})/([0-9]{1,2})/comment-page-([0-9]{1,})/?$' => 'index.php?year=$matches[1]&monthnum=$matches[2]&day=$matches[3]&cpage=$matches[4]'
}}}
The URI /2014/5/6/comment-page-2/ would end up matching the earlier rule, looking for a post named ""comment-page-2"" published on 2014-05-06, instead of looking for comment page 2 in the... I actually don't even know what the comment-page URLs do. For me, the ones that work just redirect to the date archive.
I'm happy to patch this, but would like to hear from someone else on what exactly should be done done. Do the comment-page-n rules do anything? Can they just be removed?" mboynes
Future Releases 36157 Permalink UI shown without typing a title Permalinks 2.5 normal normal defect (bug) new has-patch 2016-03-07T15:11:15Z 2019-06-04T20:55:42Z "When creating a new post and jumping straight to the content to write a post the permalink UI will still be shown.
'''Steps to reproduce:'''
* 'Add New' post in the admin
* Type content inside the post content field.
* Wait until an autosave triggers and finishes. This step can also be achieved by putting `wp.autosave.server.triggerSave();` inside the console.
'''Expected behaviour:'''
The permalink UI isn't shown because no title has been set yet.
'''Actual behaviour:'''
The permalink UI is shown with a post ID as the slug." atimmer
Future Releases 17183 previous_comments_link and next_comments_link return wrong url with PATHINFO permalinks Permalinks 1.5 normal normal defect (bug) new dev-feedback 2011-04-19T20:13:15Z 2019-06-04T20:42:01Z "When using PATHINFO permalinks, previous_comments_link() and next_comments_link() return a wrong link, which renders paged comments useless.
Steps to reproduce:
Set permalinks to: /index.php/%post_id%/%postname%/
The functions return URLs similar to: /comments-page-1/#comments
This URL results in a file not found (if no rewrite rules are available, which should not be necessary if the PATHINFO permalink structure is used).
Expected URL: /index.php/comments-page-1/#comments
Manual opening the URL results in the expected/correct paged comments page." FireMotion
Future Releases 9825 Enforce permalink history, outright Permalinks 2.8 normal normal enhancement assigned dev-feedback 2009-05-15T01:06:37Z 2019-06-04T20:40:43Z "currently, we enforce old slugs and www pref (not even sure that works, since I ended up fixing it in a plugin). canonical doesn't work for pages, or hardly.
we should enforce permalink history, outright. store it in a a db field, and query against it to optimize url2post()." Denis-de-Bernardy
Future Releases 52723 Admin options.php default value to NULL for option_value may lead to MySQL Integrity constraint violation error, potential other bugs Options, Meta APIs 2.7 normal normal 6.6 defect (bug) new has-patch 2021-03-05T14:26:35Z 2024-02-27T12:01:48Z "It looks like `wp-admin/options.php` set a `null` value by default for any unchecked option:
https://core.trac.wordpress.org/browser/trunk/src/wp-admin/options.php#L306
Now, this leads to execute queries like this by `update_option`:
UPDATE `wp_options` SET `option_value` = NULL WHERE `option_name` = 'default_pingback_flag'
Which is wrong, given the schema explicitly set `option_value` to `NOT NULL`:
https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/schema.php#L144
This would trigger an integrity constraint violation error by MySQL when in (default) strict mode:
Error! SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'option_value' cannot be null
To get around this (and for other reasons too, I presume), WordPress currently tries to disable any MySQL strict mode in the `$wpdb` class, with the effect that MySQL silently ""fix"" the error itself:
https://core.trac.wordpress.org/browser/trunk/src/wp-includes/wp-db.php#L567
https://core.trac.wordpress.org/browser/trunk/src/wp-includes/wp-db.php#L826
But **not every environment support this**, so there are people out there who cannot save options and they are confused about the reason why, for example:
https://www.reddit.com/r/Wordpress/comments/l61rvs/cannot_disable_avatars/
https://wordpress.org/support/topic/discussion-comment-settings-saved-changes-are-not-taking-effect-at-all/
https://wordpress.org/support/topic/wordpress-database-error-column-option_value-cannot-be-null/
A simple solution would be to set a different default value (`0` or even an empty string) in `wp-admin/options.php` and, ''better yet'', **cast any `NULL` value to the same different default value in both `update_option` and `add_option`**.
Please note that, without a fix, **this bug may also lead to other nasty side effects**.
As a quick fix/test, I successful got around this with this simple filter:
{{{#!php
ID )` will return:
{{{
Array
(
[0] => foo
[1] => bar
)
}}}
while the following, with the `meta_id` as array key, would be helpful imho:
{{{
Array
(
[1022] => foo
[1029] => bar
)
}}}
The modification is trivial in `update_meta_cache()`, and some other functions would only need something like `metas[0]` => `reset( metas )`." GregLone
Future Releases 51926 Network Site Search should search more than just wp_blogs.path Networks and Sites normal normal Future Release defect (bug) new has-patch 2020-12-03T18:21:59Z 2022-10-07T21:53:14Z "From /wp-admin/network/sites.php, searching sites for 'foo' looks to only search the wp_blogs.path column. This was fine up until WordPress let you put sites any any domain.
Now searching for 'foo' would show me sites such as this:
https://mysite.com/foo
https://mysite.com/foodsite
but does NOT show me sites such as
https://foo.com
https://foo.mysite.com
I believe the search should include the domain for the site as well as the path.
" MadtownLems
Future Releases 52464 The value of argument passed to the update_option_new_admin_email() is not a valid email. SergeyBiryukov Networks and Sites normal normal Awaiting Review defect (bug) reviewing reporter-feedback 2021-02-07T12:08:54Z 2022-09-29T17:38:21Z "While creating a patch for ticket #43706, I found out that the function `update_option_new_admin_email()` is responsible for the template. It does accept two parameters, however, the first parameter `$old_value` does not seem to get the correct value.
When checking the value, it holds the value `new_admin_email` instead of the old email address.
Thanks!" tremidkhar
Future Releases 41771 Global configuration table Networks and Sites 4.9 normal normal Awaiting Review enhancement new 2017-08-31T22:19:51Z 2017-09-19T16:37:54Z "In multisite, there is no way to have settings or configuration what goes applies to all networks. There are network level settings (Network options) and site levels settings (Options) but nothing global.
In #37923 the need for global configuration arose, as storing data the network level ends up with the same data in every network. Also having a global config table, would help rid ourselves of our dependence on PHP defines for configuration. If this config table was installed on single site as well, the following defines, could be moved the config table.
- MULTISITE
- SUBDOMAIN_INSTALL
- WP_CACHE
- FORCE_SSL_ADMIN
- WP_DEFAULT_THEME
This could make the process of installing multisite, much easier.
A number of feature flag that are currently store in options / network options could be moved to the global store. Features such as.
- link_manager - enabled / disabled
- global_terms - enabled / disabled
- use blog_versions - enabled / disabled
- site meta - enabled / disabled
- ms_files_rewriting - enabled / disabled
This global table could also store multi network wide settings such as
- Global super admin
- Global user roles
- Global plugins (Not mu plugins)
- Global database version
- Default Language
" spacedmonkey
Future Releases 40646 Move code from `ms-settings.php` into functions Networks and Sites normal normal Future Release enhancement new has-patch 2017-05-03T10:03:16Z 2017-08-29T16:16:58Z "As briefly discussed during yesterday's office-hours, it would be a good idea to move most of the bootstrap code from `ms-settings.php` into separate functions. `ms_load_current_site_and_network()` which was added in [37475] was a good first step in that direction. Let's introduce further functions (possibly small units) to make `ms-settings.php` less complex and more functionality testable.
Once `ms-settings.php` becomes more lightweight, we may even think about removing that file and handling all of it in `wp-settings.php`, as this would give a better overview of the entire core bootstrapping process.
This ticket is a subticket for #40623." flixos90
Future Releases 45640 get_blogs_of_user improvements alexstine Networks and Sites 3.0 normal minor Awaiting Review enhancement assigned has-patch 2018-12-14T11:59:18Z 2021-11-16T13:59:24Z "get_blogs_of_user function is often pulling more data than it needs. This often won't cause any issues but in some cases when user is attached to big number of blogs, it may lead to out of memory error.
Attached patch has changes that can lead to more improvements like pagination for ""My Sites"" admin page, limitation of listed sites in admin bar and on ""access denied"" page." maniu
Future Releases 40513 switch_to_blog should accept a WP_site as param Networks and Sites 3.0 normal normal Future Release enhancement new has-patch 2017-04-21T10:52:30Z 2022-02-01T13:18:39Z The switch_to_blog function currently only accepts a blog id. By passing a WP_Site object where available, it means switch has more context. The WP_site object has all the site information, including the network id. spacedmonkey
Future Releases 15691 Network admin should have its own settings API Networks and Sites 3.0 normal normal Future Release feature request new dev-feedback 2010-12-05T19:31:17Z 2017-09-07T10:27:33Z preferably using options.php and the same API as normal admin, this way making a plugin multisite compatible (ie. adding a Network admin screen to it) would be much easier. joostdevalk
Future Releases 27287 siteurl is missing WordPress path when creating a new site Networks and Sites normal normal defect (bug) new 2014-03-06T00:03:35Z 2019-06-04T20:06:59Z "Our setup is a single subdomain network. WordPress is installed to `/wp`, and we don't have rewrites configured to mask the subdirectory.
On the initial install, `wp_install()` sets the value of `siteurl`based on `wp_guess_url()`. The main site ends up with these expected values:
* `siteurl`: domain.com/wp
* `home`: domain.com
On subsequent creation of a new site, `install_blog()` incorrectly sets the option values for the new site to:
* `siteurl`: domain.com
* `home`: domain.com
This means the admin loads, but CSS and resources are broken, until I update the `siteurl` option value to be ""domain.com/wp"".
I'd expect `install_blog()` to follow the same behavior as `wp_install_blog()`.
#23221 is related, although this suggested fix doesn't also fix that." danielbachhuber
Future Releases 37344 Side effects on 'nav_menu_item_args' filter when appending to arguments Menus 4.4 normal normal Future Release defect (bug) new has-patch 2016-07-12T16:25:52Z 2021-10-10T23:08:44Z "The 'nav_menu_item_args' filter allows you to filter the arguments for a single nav menu item which works well when you are '''overwriting''' arguments.
When you try to '''append''' an argument the original arguments object is updated. This means that the next menu item passes in the updated object to the 'nav_menu_item_args' filter which leads to unexpected side effects.
For demonstration purposes here's how to reproduce the issue.
{{{
function format_menu_item_args( $args, $item, $depth ) {
$args->before .= rand(0,9);
return $args;
}
add_filter( 'nav_menu_item_args', 'format_menu_item_args', 10, 3);
}}}
What you should see before every menu item is a random integer between 0-9. What happens instead is the integer from the previous menu item is passed into the next. So by the time the 'nth' menu item is processed you get 'n' integers outputted whereas only one integer per menu item should be outputted.
I have added a patch to solve this by casting the $args object to an array early in start_el(). If left as an array this would break code already using the 'nav_menu_item_args' filter as an '''$args object''' is passed into the filter. Also code further down start_el() would need updating to use array rather than object notation. So, to get around this I've casted $args to an object again.
This is a new object and so there won't be any issues with referencing the original nav menu args object. Plus, existing code using the 'nav_menu_item_args' filter will still work fine.
See attached screenshots for views of a nav menus before and after the patch is applied.
''Note: The default type for $args in start_el() is already specified as an empty array but it's actually an object that's being passed in.''" dgwyer
Future Releases 38486 current_page_parent class wrongly added to menu item williampatton Menus 4.6.1 normal normal Awaiting Review defect (bug) assigned has-patch 2016-10-25T15:46:20Z 2020-07-31T16:06:44Z "If the current page being viewed is either of the following:
- a custom post type archive
- a custom post type single item
a {{{current_page_parent}}} class is added to the menu item assigned as the {{{page_for_posts}}}.
I believe this is wrong because the page assigned as the {{{page_for_posts}}} is associated with ''posts'' only. It has nothing to do with CPTs." henry.wright
Future Releases 36012 Add .current-ancestor class to any relative menu item ancestor SergeyBiryukov Menus 4.4.2 normal normal Future Release enhancement assigned has-patch 2016-02-29T16:52:22Z 2023-04-28T18:17:43Z "Right now there is .current-page-ancestor and .current-post-ancestor for pages and posts and no any class for archives, category, taxonomy or custom post types ancestors added to items in nav-menu.
I think it will be usefull, for indication navigation depth purposes, to add .current-ancestor class to ANY menu item if ""current page"" is child/successor to anything in menu (parents, archive, category, taxonomy etc. menu items)." vovkasolovev
Future Releases 29213 Introduce capability for access to nav-menus.php johnbillion Menus 3.0 normal normal Future Release enhancement assigned dev-feedback 2014-08-14T16:22:16Z 2022-01-30T16:44:01Z "Management of the nav menus 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 `edit_nav_menus` just for managing menus, 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.
For introducing a `manage_widgets` capability, see #31020." westonruter
Future Releases 35384 Archive for post in Menu Editor Menus normal normal enhancement new has-patch 2016-01-09T09:50:03Z 2019-06-04T20:20:36Z In menu edit in posts meta box I suggest add Archive for Posts sebastian.pisula
Future Releases 31391 Make the list of registered nav menus filterable Menus 3.6 normal normal enhancement new has-patch 2015-02-20T05:33:50Z 2019-06-04T20:11:26Z Adding a filter to the list of registered menu locations before they are displayed in the admin section allows for easy reordering and/or selectively hiding menu locations to none admin users. csschris
Future Releases 48522 Attachment size not generated when large images uploaded Media 5.3 normal normal Future Release defect (bug) new dev-feedback 2019-11-07T01:33:39Z 2020-10-16T20:03:30Z "I've noticed that some images during upload do not generate attachment sizes at all, or generate the sizes partially. An example of such an image: https://upload.wikimedia.org/wikipedia/commons/f/ff/Pizigani_1367_Chart_10MB.jpg
Upload is successful, but there's no scaled image, as well as no attachments. " vanyukov
Future Releases 48489 Big image size threshold should take into account registered image sizes. Media 5.3 normal normal Future Release defect (bug) new has-patch 2019-11-03T20:22:54Z 2023-11-16T11:42:00Z "The ""big image"" upper size threshold is set to `2560`. If an image size is registered that has a width or height larger than this, then the image will be unexpectedly cropped to `2560`.
The value that gets passed through to the `big_image_size_threshold` filter should be set to the maximum value of either `2560` or the largest width or height from all registered image sizes.
" johnbillion
Future Releases 39422 Consistency for returned value of attachment meta : mime_type VS mime-type Media 4.6.1 normal normal Future Release defect (bug) new 2016-12-29T22:55:29Z 2017-10-31T10:14:23Z "Hello here,
While using the function wp_get_attachment_metadata, the returned associative array is not consistent.
For video attachment it will give mime_type key with a ""_"" and for images it will return mime-type key with a ""-"".
The returned mime type key should either be ""mime_type"" or ""mime-type"", but should be the same for any type of media attachment.
Thanks for the great job !
" gabrielstuff
Future Releases 55290 Not all image edits are applied to all subsizes joedolson* Media normal normal Future Release defect (bug) accepted has-patch 2022-03-01T22:05:28Z 2024-02-05T20:24:32Z "When editing an image using the admin editor, not all edits are applied correctly to all image subsizes. Specifically, the problem occurs when an edit results in a smaller size than the defined image size. Given the following image subsizes, and the attached image.
{{{
=> array(6) {
[""thumbnail""]=>
array(3) {
[""width""]=>
int(150)
[""height""]=>
int(150)
[""crop""]=>
bool(true)
}
[""medium""]=>
array(3) {
[""width""]=>
int(300)
[""height""]=>
int(300)
[""crop""]=>
bool(false)
}
[""medium_large""]=>
array(3) {
[""width""]=>
int(768)
[""height""]=>
int(0)
[""crop""]=>
bool(false)
}
[""large""]=>
array(3) {
[""width""]=>
int(1024)
[""height""]=>
int(1024)
[""crop""]=>
bool(false)
}
[""1536x1536""]=>
array(3) {
[""width""]=>
int(1536)
[""height""]=>
int(1536)
[""crop""]=>
bool(false)
}
[""2048x2048""]=>
array(3) {
[""width""]=>
int(2048)
[""height""]=>
int(2048)
[""crop""]=>
bool(false)
}
}
}}}
''The defined sizes above are the ones coming by default with the setting provided below.
''
== Steps to replicate the problem:
1. Upload the image into your installation.
2. After the image is uploaded, click on edit to open the image editor or go to the image editor from within the media library.
3. Click on Edit image
4. Click on rotate image (either right or left) only once.
5. Make sure the changes are applied to all images by checking that the setting Apply changes to: All image sizes is set
6. Click on save
After the image is saved observe the changes were applied only to the following image sizes:
- `thumbnail`
- `medium`
- `large`
- `full`
The only size that was not updated as expected was:
- `medium_large`
== Setup
{{{
### wp-core ###
version: 5.9.1
site_language: en_US
user_language: en_US
timezone: +00:00
permalink: /%year%/%monthnum%/%day%/%postname%/
https_status: true
multisite: false
user_registration: 0
blog_public: 1
default_comment_status: open
environment_type: production
user_count: 1
dotorg_communication: true
### wp-paths-sizes ###
wordpress_path: /app
wordpress_size: 152.90 MB (160327567 bytes)
uploads_path: /app/wp-content/uploads
uploads_size: 22.75 MB (23851112 bytes)
themes_path: /app/wp-content/themes
themes_size: 6.47 MB (6780262 bytes)
plugins_path: /app/wp-content/plugins
plugins_size: 208.42 MB (218539593 bytes)
database_size: 3.96 MB (4149380 bytes)
total_size: 394.49 MB (413647914 bytes)
### wp-active-theme ###
name: Twenty Twenty-Two (twentytwentytwo)
version: 1.0 (latest version: 1.1)
author: the WordPress team
author_website: https://wordpress.org/
parent_theme: none
theme_features: core-block-patterns, post-thumbnails, responsive-embeds, editor-styles, html5, automatic-feed-links, block-templates, widgets-block-editor, wp-block-styles, editor-style
theme_path: /app/wp-content/themes/twentytwentytwo
auto_update: Disabled
### wp-themes-inactive (3) ###
Twenty Nineteen: version: 2.2, author: the WordPress team, Auto-updates disabled
Twenty Twenty: version: 1.9, author: the WordPress team, Auto-updates disabled
Twenty Twenty-One: version: 1.5, author: the WordPress team, Auto-updates disabled
### wp-plugins-inactive (1) ###
Performance Lab: version: 1.0.0-beta.1, author: WordPress Performance Group, Auto-updates disabled
### wp-media ###
image_editor: WP_Image_Editor_Imagick
imagick_module_version: 1691
imagemagick_version: ImageMagick 6.9.11-60 Q16 x86_64 2021-01-25 https://imagemagick.org
imagick_version: 3.7.0
file_uploads: File uploads is turned off
post_max_size: 100M
upload_max_filesize: 100M
max_effective_size: 100 MB
max_file_uploads: 20
imagick_limits:
imagick::RESOURCETYPE_AREA: 122 MB
imagick::RESOURCETYPE_DISK: 1073741824
imagick::RESOURCETYPE_FILE: 786432
imagick::RESOURCETYPE_MAP: 512 MB
imagick::RESOURCETYPE_MEMORY: 256 MB
imagick::RESOURCETYPE_THREAD: 1
imagemagick_file_formats: 3FR, 3G2, 3GP, AAI, AI, APNG, ART, ARW, AVI, AVIF, AVS, BGR, BGRA, BGRO, BIE, BMP, BMP2, BMP3, BRF, CAL, CALS, CANVAS, CAPTION, CIN, CIP, CLIP, CMYK, CMYKA, CR2, CR3, CRW, CUR, CUT, DATA, DCM, DCR, DCX, DDS, DFONT, DJVU, DNG, DOT, DPX, DXT1, DXT5, EPDF, EPI, EPS, EPS2, EPS3, EPSF, EPSI, EPT, EPT2, EPT3, ERF, EXR, FAX, FILE, FITS, FRACTAL, FTP, FTS, G3, G4, GIF, GIF87, GRADIENT, GRAY, GRAYA, GROUP4, GV, H, HALD, HDR, HEIC, HISTOGRAM, HRZ, HTM, HTML, HTTP, HTTPS, ICB, ICO, ICON, IIQ, INFO, INLINE, IPL, ISOBRL, ISOBRL6, J2C, J2K, JBG, JBIG, JNG, JNX, JP2, JPC, JPE, JPEG, JPG, JPM, JPS, JPT, JSON, K25, KDC, LABEL, M2V, M4V, MAC, MAGICK, MAP, MASK, MAT, MATTE, MEF, MIFF, MKV, MNG, MONO, MOV, MP4, MPC, MPG, MRW, MSL, MSVG, MTV, MVG, NEF, NRW, NULL, ORF, OTB, OTF, PAL, PALM, PAM, PANGO, PATTERN, PBM, PCD, PCDS, PCL, PCT, PCX, PDB, PDF, PDFA, PEF, PES, PFA, PFB, PFM, PGM, PGX, PICON, PICT, PIX, PJPEG, PLASMA, PNG, PNG00, PNG24, PNG32, PNG48, PNG64, PNG8, PNM, POCKETMOD, PPM, PREVIEW, PS, PS2, PS3, PSB, PSD, PTIF, PWP, RADIAL-GRADIENT, RAF, RAS, RAW, RGB, RGBA, RGBO, RGF, RLA, RLE, RMF, RW2, SCR, SCT, SFW, SGI, SHTML, SIX, SIXEL, SPARSE-COLOR, SR2, SRF, STEGANO, SUN, SVG, SVGZ, TEXT, TGA, THUMBNAIL, TIFF, TIFF64, TILE, TIM, TTC, TTF, TXT, UBRL, UBRL6, UIL, UYVY, VDA, VICAR, VID, VIDEO, VIFF, VIPS, VST, WBMP, WEBM, WEBP, WMF, WMV, WMZ, WPG, X, X3F, XBM, XC, XCF, XPM, XPS, XV, XWD, YCbCr, YCbCrA, YUV
gd_version: bundled (2.1.0 compatible)
gd_formats: GIF, JPEG, PNG, WebP, BMP
ghostscript_version: 9.53.3
### wp-server ###
server_architecture: Linux 5.15.12-1-MANJARO x86_64
httpd_software: nginx/1.17.10
php_version: 7.4.28 64bit
php_sapi: fpm-fcgi
max_input_variables: 10000
time_limit: 3
memory_limit: 1G
max_input_time: 900
upload_max_filesize: 100M
php_post_max_size: 100M
curl_version: 7.74.0 OpenSSL/1.1.1k
suhosin: false
imagick_availability: true
pretty_permalinks: true
### wp-database ###
extension: mysqli
server_version: 10.3.27-MariaDB
client_version: mysqlnd 7.4.28
max_allowed_packet: 33554432
max_connections: 151
### wp-constants ###
WP_HOME: undefined
WP_SITEURL: undefined
WP_CONTENT_DIR: /app/wp-content
WP_PLUGIN_DIR: /app/wp-content/plugins
WP_MEMORY_LIMIT: 40M
WP_MAX_MEMORY_LIMIT: 1G
WP_DEBUG: true
WP_DEBUG_DISPLAY: true
WP_DEBUG_LOG: true
SCRIPT_DEBUG: false
WP_CACHE: false
CONCATENATE_SCRIPTS: undefined
COMPRESS_SCRIPTS: undefined
COMPRESS_CSS: undefined
WP_ENVIRONMENT_TYPE: Undefined
DB_CHARSET: utf8mb4
DB_COLLATE: undefined
### wp-filesystem ###
wordpress: writable
wp-content: writable
uploads: writable
plugins: writable
themes: writable
mu-plugins: writable
}}}
" mitogh
Future Releases 36477 Responsive images (srcset) can include images larger than the full size Media 4.4.2 normal normal Future Release defect (bug) assigned dev-feedback 2016-04-11T13:27:58Z 2023-09-01T15:35:00Z "In many cases, I saw the resized and smaller images are much larger than the origin image, especially for the optimized images, it will make no sense to do that resize in this case, the worst case I've seen is about 13x larger than the origin and bigger image.
If an example can help to explain the problem, please take this picture:
https://cdn2.peterdavehello.org/wp-content/uploads/2016/04/status.png
Many thanks!" peterdavehello
Future Releases 60291 Support Lossless WebP in WP_Image_Editor_GD Media 5.8 normal normal 6.6 defect (bug) new has-patch 2024-01-19T01:08:14Z 2024-02-19T17:09:20Z "While WordPress has supported WebP lossless since WebP support was introduced in WP 5.8 (https://make.wordpress.org/core/2021/06/07/wordpress-5-8-adds-webp-support/) - outputting lossless sub-size image when you upload a lossless WebP - this only worked correctly when Imagick was installed as at the time lossless was not supported in PHP's bundled GD.
PHP's bundled GD supports lossless output for WebP images since PHP 8.1, see see php.watch/versions/8.1/gd-webp-lossless.
The capability to handle lossless WebPs can be detected in GD by the presence of the `IMG_WEBP_LOSSLESS` constant.
To fix this - similar to Imagick, GD should output WebP lossless images when lossless WebP images are uploaded.
" adamsilverstein
Future Releases 60158 The description field for media doesn't automatically make paragraphs in the generated code joedolson* Media normal normal 6.6 defect (bug) accepted changes-requested 2023-12-27T11:47:53Z 2024-03-19T15:20:16Z "There are two ways to edit a media:
- via a modal window where all the contribution fields are only simple textareas;
- via a dedicated web page where ""alternative text"" and ""caption"" fields are simple textareas and the ""description"" field is a WYSIWYG editor in text mode where TinyMCE is deactivated.
For some media, you can need to add a long description just like a transcript (for videos, audios, complex images like infographic, etc.).
So, in these cases, the description field can be used because it's totally appropriate.
But, there is a problem: usually, in editor fields, the paragraphs (
elements) are automatically added when you display the web page (in the front view). In this field, they are not.
For accessibility reason, paragraphs need to be HTML paragraphs ([https://www.w3.org/WAI/WCAG21/Understanding/info-and-relationships.html WCAG Success Criterion 1.3.1: Info and Relationships (level A)]).
I've tried to modify the code in the core to add TinyMCE that is explicitly deactivated and this is fixing the problem.
It's in wp-admin/includes/media.php, on line 3261 where you can just change ""false"" to ""true"" for ""tinymce"":
{{{#!php
'strong,em,link,block,del,ins,img,ul,ol,li,code,close' );
$editor_args = array(
'textarea_name' => 'content',
'textarea_rows' => 5,
'media_buttons' => false,
'tinymce' => false,
'quicktags' => $quicktags_settings,
);
}}}
So, is it possible to activate TinyMCE for this field? Why is it deactivated?
Or, if it's not possible, is it possible to make this option hookable?
Thank you
" juliemoynat
Future Releases 44801 `image_constrain_size_for_editor()` forcing the `$content_width` messes up dimensions Media normal normal Future Release defect (bug) new has-patch 2018-08-15T09:27:19Z 2019-04-15T21:58:52Z "The `image_constrain_size_for_editor()` currently looks at the `$content_width` global that themes may define. For `medium_large`, `large` and any custom image sizes, the actual image size's width will be evaluated against the `$content_width`, and the minimum will be used.
This results in the following (example):
* Let's say `$content_width` is 640.
* Let's say your `large` image size constraints are 1280x1280.
* Let's say your image in `large` size is 1280x960.
* Instead of using the image size width (1280), it will use the `$content_width` since it's smaller (640), resulting in 640x480 being used for the dimension of the image in `large` size.
This makes sense for the default behavior, but that computed size is used in many different areas, including `wp_prepare_attachment_for_js()`, where the `sizes` property then would show something like this for the `large` size (continuing the above example):
```js
{ width: 640, height: 480, url: '.../my-image-1280x960.jpg', orientation: 'landscape' }
```
Regarding what I want to accomplish with the custom image sizes, this results in unexpected behavior. For example in my case, I was looking into dynamically generating media queries for a background image, using the sizes. I was expecting for my code to generate `@media (max-width: 1280px) ...` for the image, but it would generate `@media (max-width: 640px) ...` due to the changed size.
As I already said, the `$content_width` global makes sense to take into account by default. However, it is currently hardcoded into the function. I think it should be moved into a filter (we already have `editor_max_image_size` which is perfect for that), so that someone could temporarily unhook that behavior for custom use-cases." flixos90
Future Releases 35390 image_constrain_size_for_editor() should not affect images generated on the front end when `large` size is used. joemcgill* Media 4.4 normal normal Future Release defect (bug) accepted 2016-01-10T04:01:24Z 2017-05-31T21:17:47Z "{{{
}}}
I am using Twenty Fifteen theme, WordPress version 4.4. `post-thumbnail` size is `825x510`. Original image size is `1600x1200`. But I am not getting expected image. After some testing I found that this problem arises if post thumbnail `large` is used. I could not understand how width and height is set to 680 and 510 respectively.
I am not sure this is related to https://core.trac.wordpress.org/ticket/35108" rabmalin
Future Releases 47713 image_get_intermediate_size does not return size if it equals original size SergeyBiryukov Media 5.2.2 normal major Future Release defect (bug) reviewing has-patch 2019-07-16T12:44:11Z 2020-09-10T14:45:20Z "Function `image_get_intermediate_size` does not return size if it equal original size.
1. WordPress itself doesn't generate `sizes` metadata item for size equal original image size.
2. `image_get_intermediate_size` looks throught `sizes` metadata and doesn't see necessary size.
3. It doesn't check original image size.
More details here: https://github.com/Yoast/wordpress-seo/issues/10863" mahnunchik
Future Releases 54943 image_get_intermediate_size(): size data is a bool, not an array throws notice / warning Media 5.9 normal normal Awaiting Review defect (bug) new reporter-feedback 2022-01-27T08:03:50Z 2023-08-07T19:20:26Z "While testing my website on PHP 8.0 (in my example opening the blog page), I noticed the following two warnings in the error log:
{{{
[27-Jan-2022 08:56:34] WARNING: [pool xxx] child 1031078 said into stderr: ""PHP message: PHP Warning: Trying to access array offset on value of type bool in /var/www/xxx/wp-includes/media.php on line 779""
[27-Jan-2022 08:56:34] WARNING: [pool xxx] child 1031078 said into stderr: ""PHP message: PHP Warning: Trying to access array offset on value of type bool in /var/www/xxx/wp-includes/media.php on line 785""
}}}
PHP 7.4 throws a Notice.
I also noticed with a fresh install of wordpress. " fhwebdesign
Future Releases 41445 post_parent can prevent media from embedding correctly adamsilverstein Media 4.9.4 normal normal Future Release defect (bug) reopened dev-feedback 2017-07-26T06:29:28Z 2024-01-26T07:46:47Z "If media is uploaded for a post, then used as a featured image on another post, and the original parent is not accessible via the REST API (e.g. because it's in the trash, not published etc), then it cannot be embedded on the post that ''is'' accessible.
To reproduce
* make a new post with a featured image
* trash the post
* make a new post, using the first image as the featured image
* request the second post over the rest API with media embedding enabled
The media will not be embedded, instead a forbidden result will be embedded error
{{{#!json
{
""wp:featuredmedia"":[
{
""code"":""rest_forbidden"",
""message"":""You don't have permission to do this."",
""data"":{
""status"":403
}
}
]
}
}}}
See https://github.com/WP-API/WP-API/issues/2596 for the original issue. Also related is https://core.trac.wordpress.org/ticket/30691.
" loboyle
Future Releases 36273 update_attached_file() on Windows will result in invalid image path when using native Windows directory separators Media 4.4.2 normal normal Awaiting Review defect (bug) new 2016-03-18T10:48:16Z 2018-04-30T23:34:09Z "Calling ''update_attached_file( $image->ID, $file );'' on platforms like Windows can be really bad if ''$file'' was normalized/validated using PHP's ''realpath()'' function:
{{{#!php
ID );
// Well, in real world you could have created the path manually...
// The only important thing to know is, that we call ""realpath()"" which will
// convert any directory separator into the native directory separator:
// Linux will end with /dir/subdir/basename.jpg
// Windows will end with C:\Dir\Subdir\basename.jpg
$file = realpath( $file );
// Again, this is just a demo, for real world cases see plugins like ""Force Regenerate Thumbnails""
// But this is a valid API call:
update_attached_file( $image->ID, $file );
// On Windows this will result in an update statement like
// UPDATE `postmeta` SET `meta_value` = 'C:WWWSitesdemohtdocswordpresswp-contentuploads201603example.jpg' WHERE `post_id` = 123 AND `meta_key` = '_wp_attached_file'
// when $file was set to ""C:\WWW\Sites\demo\htdocs\wordpress\wp-content\uploads\2016\03\example.jpg""
// Now imagine a plugin which is re-generating thumbnails :]
// The problem is
// $meta_value = wp_unslash($meta_value);
// in wp-includes/meta.php update_metadata().
}}}
When using ''update_attached_file()'' we should make sure that ''update_metadata()'' don't update the path value to an invalid value...
PS: After you updated all image paths to an invalid value, the media library won't work anymore:
{{{
[18-Mar-2016 07:31:10 UTC] PHP Warning: file_exists() expects parameter 1 to be a valid path, string given in C:\WWW\Sites\demo\htdocs\wordpress\wp-includes\media.php on line 3063
}}}
" Whissi
Future Releases 36437 wp_delete_attachment causes warning Media 2.0 normal normal Awaiting Review defect (bug) new has-patch 2016-04-07T06:24:34Z 2017-07-27T16:26:17Z wp_delete_attachment assumes that attachments uses category and post_tag taxonomies. This causes a warning in wp_delete_object_term_relationships when post type attachment is not using category or post_tag taxonomies. thorbrink
Future Releases 42920 Add support for the picture element adamsilverstein Media normal normal Awaiting Review enhancement assigned dev-feedback 2017-12-17T06:10:52Z 2024-02-26T18:25:22Z "The `