__group__ ticket summary owner component _version priority severity milestone type _status workflow _created modified _description _reporter
Untriaged tickets (that need a patch) 33940 Double spaces in term names can cause problems XML-RPC normal normal Awaiting Review defect (bug) assigned 2015-09-20T22:56:04Z 2019-08-15T06:46:02Z "Create a tag called 'test term'.
Use XML-RPC to create a post with a tag of:
{{{
test term
}}}
(two spaces). You'll get an error thrown, with the post not created:
{{{
A term with the name already exists in this taxonomy
}}}
This appears to be due to the `_insert_post` function in XML-RPC using `get_term_by( 'name', $term_name, $taxonomy );`, which is returning false - thus it tries to create the term as new, and fails.
Most other aspects of WP seem to filter the term name to strip double spaces first - is that what is necessary here? Or could the issue affect more than just XML-RPC?" smerriman
Untriaged tickets (that need a patch) 51891 Multiple xmlrpc attacks after last update XML-RPC 5.5.3 normal major Awaiting Review defect (bug) new 2020-11-28T14:23:16Z 2021-01-07T18:17:13Z "Hello,
After the latest WP update, I have began noticing an increasing amount of xmlrpc attacks for exploits that reached new peaks some 20 hours ago and without signs of slowing down.
With each attack I am getting the following entry in the error.log :
PHP Warning: call_user_func_array() expects parameter 1 to be a valid callback, array must have exactly two members in /home/.../public_html/wp-includes/class-wp-hook.php on line 289
I have de-activated the majority of the plugins and specifically those updated during the last week but that didn't change the scenery.
I am not a developer, I am a power WP user operating a multisite for a couple of years now and this is the first time I am noticing this aggressive hacking activity (hundreds of different IPs per hour just as to avoid immediate blacklisting). Also this is the first time I am opening a ticket in WP.org
Thank you for your attention.
" attunist
Future Releases 20070 Deprecate Blogger XML-RPC Methods XML-RPC 3.3 normal normal Future Release enhancement new dev-feedback 2012-02-18T18:32:26Z 2020-09-21T19:41:58Z "The XML-RPC API supports the legacy Blogger API methods, but these methods have apparently not been very well tested or maintained.
Given that the `wp.*` XML-RPC namespace now covers everything that the Blogger API does, I suggest the blogger methods be officially deprecated with an eye towards removing them in a future version.
At the very least, the MetaWeblog API should be used by clients instead, as it was explicitly designed to enhance and supersede the Blogger API." maxcutler
Future Releases 59414 XML-RPC - add updateMedia endpoint XML-RPC normal normal Future Release enhancement new 2023-09-20T19:33:26Z 2024-03-05T15:53:56Z "In #58582, @thomashorta reported on alt attributes missing from the XML RPC endpoints. Fetching that data was fixed in [56637], but adding an endpoint to update media that specifically handles media data like alt attributes requires a more substantial enhancement.
From #58582:
Updating MediaItems through the XML-RPC API is also done directly by the Posts API, more specifically through wp.editPost (codex), which also doesn't support an alt field. This makes sense, as this API is more generic, but at the same time, there are no specific updateMedia methods in the Media API.
Suggestion for updating
I'm not sure about this one, but I think a new method in the Media API would be needed (e.g.: wp.updateMediaItem) to properly manipulate a specific input struct and call the Post update functions internally." joedolson
Future Releases 25037 XML-RPC : Can't remove all the categories from a post by using metaWeblog.editPost XML-RPC 3.6 normal normal defect (bug) assigned 2013-08-14T17:41:00Z 2019-06-05T06:39:22Z "Seems that you can't remove all the categories from a post by calling mw_editPost.
I tried both passing an empty array, or skipping the entry 'categories', in the content struct, but none of them worked. The post still has the previous categories attached to it." daniloercoli
Future Releases 25016 "XMLRPC method ""wp.getUsers"" not working correctly in Multisite" XML-RPC 3.5 normal normal defect (bug) assigned 2013-08-12T18:53:13Z 2019-06-05T06:39:20Z "Hi,
I have been testing some functionality in our app which uses XMLRPC, and it appears that I've found a bug with how the ""wp.getUsers"" method works on WordPress.com blogs.
Basically, the blog I'm testing this on has 3 administrators. Regardless of which one of those administrators' credentials I use, whenever we call the ""wp.getUsers"" method we ONLY get details for the SAME user back. So, if we have 3 admins ('admin1', 'admin2', 'admin2'), whenever 'admin1' queries for all users, they only get back 'admin1'.
I also tried adding a different type of user, specifically an author, and then used any of the above-mentioned administrator credentials to try and retrieve info on that author, but nothing is returned.
It should be noted that all the above functionality works as it should on self-hosted blog, just NOT on WordPress.com blogs.
" dinomic
Future Releases 17382 XMLRPC wp_getUsersBlogs Scalability XML-RPC 3.0 normal normal defect (bug) new 2011-05-11T20:32:15Z 2019-06-05T06:38:07Z "If there is a root blog with many sub blogs on it and a user that is an admin on each sub blog, then when the when the XML RPC method wp_getUsersBlogs() is called it does not scale very well. My PHP memory_limit setting was 128MB, and the XML RPC request died when a user was a member of 230+ blogs. I noticed that the number of queries made to the database for a single user that has many blogs that they are an admin is very high.
Affected line: http://core.trac.wordpress.org/browser/tags/3.0.1/xmlrpc.php#L443
I don't know exactly how the code would have to change so I am not providing a patch." bmorneau
Untriaged tickets (that need a patch) 49044 Links in the text widget now require quotes audrasjb Widgets 5.3.1 normal normal Awaiting Review defect (bug) reviewing 2019-12-19T15:12:09Z 2020-01-07T19:37:52Z "Up until this release, if I had a link a text widget like this it would work.
New Patient Packet
the recent updated made the same link format like this when you click on it:
https://www.aspirefamilydental.com/%22/wp-content/uploads/NT-transfer-records-to-sister-office-form.pdf/%22
I had to go in and change the text to this in order to make it work.
New Patient Packet
I manage over 200 sites. I have easy way of finding every link in every widget on all the sites I manage. Please fix the text widget to accept links without quotes like it used to.
" spherman
Untriaged tickets (that need a patch) 52730 Mixed content error with RSS widget Widgets 5.6.2 normal normal Awaiting Review defect (bug) new reporter-feedback 2021-03-07T20:06:37Z 2021-03-12T19:27:36Z To avoid SSL Mixed content warning, it is needed to force the RSS icon to load with https gregmagn1
Untriaged tickets (that need a patch) 52877 The Widget's Callback Array Stores Wrong Values Widgets 5.7 normal major Awaiting Review defect (bug) new 2021-03-21T12:45:09Z 2022-12-05T07:12:37Z "While trying to get Widget's saved settings I stuck a very weird issue, The objects [number] and [id] in the Widget's Object [callback][0] always refer to the last widget created.
Create **Two or more of the same Widget**, Then print out the settings, You will notice that the [number] and [id] inside the [callback] array different than the main [id] and [number] inside the [params] array, So when use the [number] from the callback array it refers to a wrong index which is the last created widget's index not the current.
{{{
add_action( 'wp', 'test_widgets' );
function test_widgets() {
global $wp_registered_widgets;
$widgets_ids = retrieve_widgets( FALSE );
foreach( $widgets_ids as $sb_id => $widgets ) {
if( 'wp_inactive_widgets' === (string) $sb_id ) {
continue;
}
foreach( $widgets as $active_widget_id ) {
if( ! isset( $wp_registered_widgets[ $active_widget_id ] ) ) {
continue;
}
echo print_r( $wp_registered_widgets[ $active_widget_id ] );
/**
* Widget Object
* @var \WP_Widget
* */
$obj_widget = $wp_registered_widgets[ $active_widget_id ]['callback'][0];
/* If you use the callback object to get the Widget's index it'll refer to a wrong index */
/* TRY: echo $obj_widget->number; */
}
}
}
}}}
**Output:**
{{{
Array
(
[name] => Meta
[id] => meta-4
[callback] => Array
(
[0] => WP_Widget_Meta Object
(
[id_base] => meta
[name] => Meta
[option_name] => widget_meta
[alt_option_name] =>
[widget_options] => Array
(
[classname] => widget_meta
[customize_selective_refresh] => 1
[description] => Login, RSS, & WordPress.org links.
)
[control_options] => Array
(
[id_base] => meta
)
[number] => 4
[id] => meta-4
[updated] =>
)
[1] => display_callback
)
[params] => Array
(
[0] => Array
(
[number] => 4
)
)
[classname] => widget_meta
[customize_selective_refresh] => 1
[description] => Login, RSS, & WordPress.org links.
)
1Array
(
[name] => Meta
[id] => meta-3
[callback] => Array
(
[0] => WP_Widget_Meta Object
(
[id_base] => meta
[name] => Meta
[option_name] => widget_meta
[alt_option_name] =>
[widget_options] => Array
(
[classname] => widget_meta
[customize_selective_refresh] => 1
[description] => Login, RSS, & WordPress.org links.
)
[control_options] => Array
(
[id_base] => meta
)
[number] => 4
[id] => meta-4
[updated] =>
)
[1] => display_callback
)
[params] => Array
(
[0] => Array
(
[number] => 3
)
)
[classname] => widget_meta
[customize_selective_refresh] => 1
[description] => Login, RSS, & WordPress.org links.
)
}}}
" oxibug
Untriaged tickets (that need a patch) 42568 Text Widget: Media Uploader Button Label Widgets normal normal Awaiting Review enhancement new 2017-11-16T06:03:35Z 2021-06-14T15:50:14Z I was wondering if the '''Media Uploader''' in the new '''Text Widget''' has a button with label '''Insert Into Widget''' instead of '''Insert Into Post''' as shown here: http://prntscr.com/hb38jv . It would be more meaningful I guess :) saurav.rox
Untriaged tickets (that need a patch) 27405 Widget Customizer: Fade out sidebar sections that lack any rendered widgets Widgets 3.9 normal normal Awaiting Review enhancement new 2014-03-13T21:44:19Z 2017-06-07T00:24:28Z "Currently when there is a widget that is not rendered in the current URL being previewed (e.g. via Widget Visibility), the widget control in the customizer will become semi-transparent to indicate it is not being rendered. The same semi-transparent indicator would be useful for sidebars that are empty or which lack any rendered widgets.
Originally reported in https://github.com/x-team/wp-widget-customizer/issues/76" westonruter
Future Releases 53693 Block icons too big on 5.8 widgets page Widgets 5.8 normal normal Future Release defect (bug) new 2021-07-19T17:23:22Z 2021-11-01T21:51:21Z "[https://en-ca.wordpress.org/plugins/yet-another-related-posts-plugin/ Our plugin] adds a block using an SVG image which still looks fine on the blocks page. But on the widgets page introduced in WP 5.8, our block's icon is way too big and spills into the surrounding areas.
See [[Image(https://i.imgur.com/ut0vOSv.png)]]
On the post editing page, where the icon still looks fine, I see this critical CSS:
{{{
.block-editor__container img {
max-width: 100%;
height: auto;
}
}}}
It seems on the widgets page there is no `block-editor__container` so the styles don't apply, and icons like ours are unstyled.
" mnelson4
Future Releases 42822 CodeMirror: HTML attributes values hints not fully operable with a keyboard Widgets 4.9 normal normal Future Release defect (bug) new 2017-12-07T09:38:16Z 2018-09-26T14:43:42Z "To reproduce, add an HTML widget either in the Widgets screen or in the Customizer:
- start typing a HTML tag, for example ""
Custom HTML
Custom HTML Content
}}}
Text Widget - The widget-wrap div has only that class.
{{{
Text Widget
Text Widget Content
}}}
As a result, any theme that has styled widget_text may have unintended styling issues.
" dreamwhisper
Future Releases 53552 Inactive Widgets prevent placement of new widget if `multiple` is false Widgets 5.8 normal normal Future Release defect (bug) new 2021-06-29T16:03:42Z 2021-11-01T22:05:49Z In the new Widget page, moving a Widget to Inactive stops placement of a new copy of that widget is 'multiple' is defined as false in the block code. MattyRob
Future Releases 55220 Legacy widgets lack access to some usual server-side globals Widgets normal normal Future Release defect (bug) new 2022-02-22T00:59:03Z 2022-03-02T13:21:05Z "Copied from https://github.com/WordPress/gutenberg/issues/33404.
---
## Description
Legacy widgets whose behavior depends on the `$pagenow` global might not render as expected via the new `/wp/v2/widget-types/fm-demo/encode` REST API endpoint because `$pagenow` during these requests is `index.php`, not `widget.php`.
Additionally, legacy widgets are no longer able to rely on the `$_POST['action']` variable during requests to save widget data, which is usually set to `save-widget`, and these widgets might not be able to save data as expected.
Similarly, legacy widgets are no longer able to rely on `DOING_AJAX` or `wp_doing_ajax()`, although that is typical of the REST API.
## Step-by-step reproduction instructions
The easiest way to observe this behavior is to observe `$pagenow` and `$_POST` using Xdebug with a breakpoint inside of `WP_REST_Widget_Types_Controller::encode_form_data()`.
To see the effect of the behavior on a real-world library:
1. Clone and include the Fieldmanager library: https://github.com/alleyinteractive/wordpress-fieldmanager
2. Clone and include the Fieldmanager Widgets extension: https://github.com/alleyinteractive/fm-widgets/
3. Load the demo widget included in the README: https://github.com/alleyinteractive/fm-widgets/blob/296d5aef0585f3ff9bcf223e30867e069c13e2ca/README.md
4. Step through the `\fm_widgets_calculated_context()` function, which relies on all of the signals mentioned in the description.
## Expected behaviour
With respect to legacy widgets, `$pagenow` will be `widgets.php` during form rendering, and `$_POST['action']` will be `save-widget` during saving.
## Actual behaviour
`$pagenow` is `index.php`, and `$_POST['action']` is unset.
## Code snippet (optional)
See README link above.
## WordPress information
- WordPress version: 5.8-RC2
- Gutenberg version: Not installed
- Are all plugins except Gutenberg deactivated? No, see repro steps.
- Are you using a default theme (e.g. Twenty Twenty-One)? Yes
## Device information
- Device: Desktop
- Operating system: macOS 10.14
- Browser: Chrome 91" noisysocks
Future Releases 53920 "Missing ""Title"" Field for Category / Latest Posts / Custom HTML Block Widgets" Widgets 5.8 normal normal Future Release defect (bug) new 2021-08-12T18:11:53Z 2021-11-02T15:21:03Z "The ""Title"" field is missing in block widget area for ""Category"" widgets (both products & pages), missing from ""Latest Post"" widget, AND missing from ""Custom HTML"" widget. Other widgets still have the ""Title"" field. Not sure if this was intentional or got overlooked... : (" lynaeash
Future Releases 32183 Widget ID auto-increments conflict for concurrent users westonruter* Widgets 2.8 normal normal Future Release defect (bug) accepted 2015-04-29T09:20:46Z 2017-06-07T00:20:40Z "Each WP_Widget 2.0 “multi-widget” gets an index number associated with each instance of a give type. When you add a widget, this number gets incremented (`widget.set( 'multi_number', widget.get( 'multi_number' ) + 1 );`). The initial multi-number is calculated from the `next_widget_id_number()` function which takes the max number currently used, and increments it by one. The same approach is used in the widgets admin page and the Widget Customizer.
For frequently-used widgets, the above problem will happen frequently where two users will try to add the same widget at the same time, and thus they will start out with the same initial `multi_number`, resulting in the same widget ID. When they both save their changes, one user's widget will override the other user's widget: whoever saves last. Likewise, it is possible for multiple widgets to be deleted in one session (from the widgets admin page, since Customizer only removes widgets by moving them to the Inactive Widgets sidebar) then new ones added back in other sessions and the initial `multi_number` will not be consistent. In other words, the `multi_number` for each widget type needs to be synced across each Customizer session along with the actual setting values.
For concurrent editing of widgets, see:
#31436: Handle conflicts in concurrent Customizer sessions
#12722: Concurrent editing of widgets (on admin page)" westonruter
Future Releases 36851 Widgets don't remove hooks after being unregistered Widgets 2.8 normal normal Future Release defect (bug) new 2016-05-16T15:28:57Z 2017-06-28T16:29:44Z "In `WP_Widget_Recent_Comments::__construct()`, there is this bit of code:
{{{#!php
id_base ) || is_customize_preview() ) {
add_action( 'wp_head', array( $this, 'recent_comments_style' ) );
}
}}}
If `unregister_widget( 'WP_Widget_Recent_Comments' )` is called, this added `wp_head` action is still going to persist unexpectedly. At the moment, I believe the only way to remedy this inside such widgets themselves would be to check to see if the widget is still among `$wp_widget_factory->widgets` when the action callback is called (here the `recent_comments_style` method). From outside the widget, the alternative is would be to do:
{{{#!php
widgets['WP_Widget_Recent_Comments'];
unregister_widget( get_class( $widget ) );
remove_action( 'wp_head', array( $widget, 'recent_comments_style' ) );
}}}
Neither of these options are great.
Perhaps there should be new `widget_registered` and `widget_unregistered` actions that widgets could listen to to do this cleanup? Or there could be a new `unregister` method on `WP_Widget` that a subclass could have this logic inside of. (We wouldn't be able to use the PHP destructor since it would never be called since the reference to the class would be still captured among the registered hooks.) Likewise, instead of adding the hooks inside of the constructor, perhaps there should also be a `WP_Widget::register()` method that gets called inside of the faux-private `WP_Widget::_register()` (and `_register` should be `final`, no?)" westonruter
Future Releases 42965 Widgets not restored to previous widget area after switching back to previous theme Widgets 4.9 normal normal Future Release defect (bug) reopened 2017-12-22T15:06:13Z 2020-11-04T01:59:08Z There's a bug in widgets when switching themes. Before, on version 4.8.4, if you switch themes and return it back to previous, widget will retain on its widget column. In the latest version 4.9.1, every time you switch themes and return it back to previous one, all widgets will automatically placed to Inactive widgets. probewise
Future Releases 42987 is_active_sidebar returns true on after plugin deactivation Widgets 2.8 normal normal Future Release defect (bug) new 2017-12-27T12:44:45Z 2018-01-26T21:12:12Z "Hi,
Steps to reproduce:
code:
{{{#!php
Sidebar is active, and it contains widget(s).
Sidebar doesn't contain any widget.
}}}
1. Add a widget plugin to the `custom-sidebar`
2. Disable the widget plugin
3. Reload the page
The page is still showing sidebar is active. and `wp_get_sidebars_widgets()` still contains the disabled plugin's widget info.
Is this something intended? Or is it a bug? " tpaksu
Future Releases 52399 Remove widget accessibility mode joedolson* Widgets normal normal Future Release enhancement accepted 2021-01-29T16:44:29Z 2021-10-30T19:51:07Z "With the introduction of the new block editing experience for widgets management, WordPress will have four separate interfaces for managing widgets: block editing, customizer, classic widgets, and accessbility mode.
The accessibility team would like to explore merging the characteristics that accessibility mode uses for better accessibility into the classic widget screen, to cut down to only three modes of operation for widgets.
This will require identifying the characteristics of accessibility mode and finding ways to reproduce those characteristics within the existing widget UI.
The key differences that are obvious are:
1) Use of a text link to 'Add' or 'Edit'
2) Links target each widget via a URL to manage independently.
3) Selection options to choose which sidebar and position will be used for a widget.
These characteristics allow a single widget to be edited in isolation, the ability to assign a location without drag and drop, and visible text tools for handling widgets.
One possibility to explore is having an add/edit option that opens a given widget in a modal that includes the location selection tools provided in accessibility mode.
" joedolson
Future Releases 43045 Trigger events equivalent to editor:image-edit and editor:image-update in media-image-widget.js Widgets normal normal Future Release enhancement new 2018-01-08T20:51:24Z 2020-06-17T04:22:54Z "The `wpeditimage` TinyMCE plugin has helpful `editor:image-edit` and `editor:image-update` events for hooking additional metadata onto the Image object. Here's an example:
{{{
wp.media.events.on('editor:image-edit',function(event){
event.metadata.pinterest_text = event.editor.$(event.image).attr('data-pin-description');
});
wp.media.events.on('editor:image-update',function(event){
event.editor.$(event.image).attr('data-pin-description', event.metadata.pinterest_text);
});
}}}
Although the new Image Widget reuses the `image-details` frame, it doesn't fire these equivalent events, making integration difficult. It would be helpful if the `ImageWidgetControl` implemented equivalent events." danielbachhuber
Future Releases 28747 $.wpColorPicker cannot duplicate elements Widgets 3.9.1 normal normal defect (bug) new 2014-07-04T09:26:00Z 2019-06-05T06:40:07Z "I can't `clone()` wrap `div` when I use with `wpColorPicker`. If I just running the `$.wpColorPicker` method again, I see two instance about this.
What I can to do for duplicate?" KingYes
Future Releases 21396 Categories widget reports categories without posts when they have custom posts Widgets 3.4 normal normal defect (bug) new 2012-07-27T02:36:46Z 2019-06-05T06:38:44Z "This problem may be related to #14084, but this report is specific to the behaviour of the Categories Widget.
- Create a custom post type eg. ""Products""
- Create a category eg. ""Photographs""
- Add some posts of type Products, assign them to category Photographs
- go to the blog page and the Categories widget lists Photographs as a category
- click on Photographs
- the ""Nothing Found"" post is shown.
There are no normal posts of category Photographs, but the widget lists a category that returns nothing. I would have expected the widget not to list a category that has no normal posts.
" pkwooster
Future Releases 27236 Custom Widgets lost when theme is re-activated while the widget plugin is inactive Widgets 3.8.1 normal normal defect (bug) new 2014-02-28T15:27:29Z 2019-06-05T06:39:46Z "It could be a rare issue for others, but it's a regular process for my use-case.
Custom Widgets are no longer shown in the widget area when theme is de-activated and re-activated while the plugin that provided one of the widgets is inactive.
Steps: (Assumes, twenty fourteen is active)
1. Install Slim Jetpack plugin (or any other plugin that provides a widget). I enabled the Extra Sidebar Widgets from Settings > Slim Jetpack.
2. Add one of the Slim Jetpack widgets to the ""Primary Sidebar"" for example ""Gravatar Profile (Jetpack)"".
3. De-active Slim Jetpack.
4. Activate ""Twenty Thirteen"" theme.
5. Activate ""Twenty Fourteen"" theme.
6. Activate ""Slim Jetpack"". Unfortunately, the custom widget is lost.
If you had normally de-activated and re-activated Slim Jetpacks, the Primary Sidebar would be fine. If you had done 4 and 5 without 3, everything would be good.
But doing the steps as above, the widget is no longer in the sidebar - not even under Inactive Widgets.
" asadkn
Future Releases 27180 Remove Hidden Widget UI Widgets 3.8 normal normal defect (bug) new 2014-02-21T22:09:25Z 2019-06-05T06:39:44Z "I have come up with a issue with the new widget enhancements.
The fact that we have to drag the widget a long way to move it to inactive status. On most screens this is below the visual area of the screen. Yet the only UI to collapse and expand the available widget area is hidden and you don't see it until your hover over text that doesn't appear or look like something you would hover over to see a user interaction. This makes it hard to us or even know it is their or available.
The other UI issue also have to do with the widget placement as well.
When you go to add a widget it asks you if which area do you want it added to. (For example: Main Widget Area or Secondary Widget Area) But when removing the widget the only options you have (without dragging them) is close and delete. There is no ""Move to Inactive""
Once a widget is in the Inactive Widgets area you can't add the widget via the button you once could in the new widget area. Can we have just one experience for both New and Inactive Widgets?
I also have a Screencast which you can see here: http://f.cl.ly/items/0a293y0P363W1p0V2A11/Widget-Screen-Recording.mov
" RDall
Future Releases 31189 Widgets editing screen don't handle expired nonces gracefully Widgets normal normal defect (bug) new 2015-01-31T02:12:19Z 2019-06-05T06:40:38Z "The Widgets screen doesn't handle an expired nonce gracefully, and can result in the user thinking something saved, when in actual fact it was silently discarded.
For example
- Adding/Removing Widgets appears to work, doesn't take effect
- Editing a Text Widget (or any titles of other widgets) and hitting save will result in a spinner, and then disappear the same way a successful save operates, even though the ajax calls returned `-1` to signify a nonce error / not logged in error
" dd32
Future Releases 23909 Widgets settings loaded and instances registered unnecessarily Widgets 3.5.1 normal normal defect (bug) new 2013-03-30T16:02:05Z 2019-06-05T06:39:14Z "The settings for all registered multi-widgets get loaded with each request in `widgets_init`, and all widgets get registered even if they are never used (e.g. inactive ones). As the total number of inactive widgets tend to grow over time, the result is slower and slower page loads across all of a WordPress install.
Ideally only the widgets returned by `wp_get_sidebars_widget()` would only get loaded and registered, though this would have an impact on how the widgets in the Customizer work." alex-ye
Future Releases 14876 wp_get_sidebars_widgets() assumes that widgets are enabled Widgets lowest minor defect (bug) reopened 2010-09-15T02:05:43Z 2019-06-05T06:45:15Z "When a theme does not have any sidebars defined, wp_get_sidebars_widgets() will return the database option anyway.
This reveals a bug where a theme that does not have any widgets may still get the recent comments CSS injected into it. is_active_widget() is returning true because that widget was active when the sidebar option was last used." nacin
Future Releases 23008 Add a Hook To Hide Inactive Widgets Widgets 3.5 normal normal enhancement new dev-feedback 2012-12-19T19:59:12Z 2019-06-05T06:38:58Z "Hello,
This is my first feature request so hopefully I'm going through the process correctly. Onto the request...
Adding a hook to remove or hide the Inactive Widgets sidebar on the WordPress Admin Widgets page would be very useful for developers who don't use the area and want to be able to hide it for better UX.
If this is approved I would love to submit a patch. :)" BFTrick
Future Releases 20596 Adding more actions to a widget Widgets normal normal enhancement new dev-feedback 2012-05-02T00:14:28Z 2019-06-05T06:38:33Z "On the Widget UI, there is a ""Close"" button, aside with the ""Delete"" button, and I that developers should have a way to add more of those.
For exemple, I would see as a good use case when you have a way of previewing the widget.
Because right now the only way is by JS which is kinda of lame.
Thanks," webord
Future Releases 36532 Allow Reordering of Available Widgets Widgets normal normal enhancement new 2016-04-14T21:12:22Z 2019-06-05T06:44:15Z "It's common to see sites with 20 or even 30 widgets, even when the site user only needs a few of them:
- Example 1: Core still ships with Tag Cloud and Meta widgets that I'd guess are barely ever used.
- Example 2: It's always a bummer that the Text widget starts with ""T""...
- Example 3: Jetpack adds a bunch of widgets, but I often only need one.
Yesterday, I observed a client trying to drag-and-drop reorder the list of Available Widgets. I thought that was a perfectly reasonable thing to try, and realized I would love to do that on every site. This seems even more reasonable considering that a user can already reorder Inactive Widgets.
I considered requesting that each widget be togglable via Screen Options, but I realize this wouldn't quite make sense given that a user could then hide an existing widget type. So among the options I can think of, I think the ability to reorder Available Widgets would be a relatively minor UI change with a potentially large UX improvement!" mrwweb
Future Releases 26112 Available widgets drag-and-drop causes trouble on touch devices Widgets normal normal enhancement new 2013-11-19T15:57:32Z 2019-06-05T06:39:35Z "Now that we have click-to-add for available widgets, I think it makes sense to disable the drag-and-drop for available widgets on touch devices. The interaction tends to cause troubles on touch devices when you intend to scroll through the list of widgets, and instead initiate the draggable.
Since active and inactive widgets don't have any alternative for reordering, we can keep the draggable interaction there on touch devices — but maybe we should think of a new way of reordering these widgets without requiring drag-and-drop." shaunandrews
Future Releases 16613 Extend Widget API to allow sidebar/widget manipulation Widgets 3.1 normal normal enhancement new 2011-02-21T22:55:17Z 2019-06-05T06:37:51Z "There is currently no easy way to add a widget to a sidebar using code. We should add methods of doing this.
A good example usage of such an API could be when a new theme is activated, it could add it's custom widgets to it's sidebar.
API should provide support for adding widget X to sidebar Y (or even just the first sidebar) along with setting some options for the widget and where in the sidebar to add it (top vs. bottom)." Viper007Bond
Future Releases 28188 Make Natively-Outputted .widget_rss CSS Selector HTML5-Appropriate Widgets 3.9 normal normal enhancement new 2014-05-09T05:57:31Z 2019-06-05T06:40:00Z "In regards to the natively outputted RSS Widget entitled `.widget_rss`, the post Author's name is currently outputted as wrapped in a `` tag.
An example of a natively outputted RSS feed block looks something like this for reference:
`Example RSSed PostApril 14, 2014
This is the space where the RSSed information appears. […]
Author`
Please note that the author of the RSSed post is being natively outputted as wrapped in the `` tag.
As per #27944 (ocean90's comment in particular) which references #24522 (re: proper way to tag comment authors), the natively outputted CSS selectors for the `.widget_rss` widget probably ought to be wrapped in something like: `` as opposed to ``.
Reiterating what ocean90 said: The `` tag is supposed to be used for a cited block of text (like a citation) rather than used to tag the/an author.
Additionally, changing the `` to `` will provide additional sitewide code uniformity (there's a word or phrase I am looking for and I can't remember it!) for a natively/vanilla outputted WordPress site (and especially if using a default WordPress theme) re: how author names are wrapped in tags.
Thanks!" EMG
Future Releases 29155 Widgets: is_active_widget returns true even when the widget is not displayed on specific page Widgets 2.3 normal normal enhancement new 2014-08-08T17:51:22Z 2021-11-23T15:55:22Z "Steps to reproduce:
1. Activate Twenty Eleven
2. In Appearance > Widgets, add a widget to the Showcase widget area (only displayed on pages using the Showcase Page Template)
3. Load your home page. {{{is_active_widget}}} will return true for that widget, even if it is not displayed on the home page.
It seems like it would be nice if {{{is_active_widget}}} only returned true when the widget was actually displayed on the page. I'm not sure how to do that, though." jeherve
Untriaged tickets (that need a patch) 59746 Adding User Biographical Info without space breaks the container and adds horizontal scroll Users 6.3.2 normal normal Awaiting Review defect (bug) new 2023-10-26T10:43:35Z 2023-10-27T04:30:09Z "I found one issue in User Biographical Info module.
Whenever I am adding bio without spacing, it breaks the container and adds horizontal scroll !
- Environment: fresh WordPress with no additional plugins
- Theme: Twenty Twenty-One ( 1.9 )
- Screen recording: https://screenrec.com/share/H6zALe1fXd" mihirdev21
Untriaged tickets (that need a patch) 51781 Code not pulling website URL Users 5.5.3 normal normal Awaiting Review defect (bug) new 2020-11-15T18:45:42Z 2021-09-23T08:06:20Z "Hello people,
I have activated the multisite network. And when a user signs up on one of the network’s sites (main site or subsite), that user receives an email with a confirmation link. After the user clicks on the confirmation link, he receives another email stating that his account is ok, and the signature of that email shows the code (###SITEURL###) that should call the URL of my site: https://prnt.sc/vjjaxz
Thank you!" vejapixel
Untriaged tickets (that need a patch) 47618 Email sent to blank address on email change for user with no previous email address Users normal minor Awaiting Review defect (bug) new 2019-06-27T14:24:25Z 2019-06-27T20:05:07Z "1. Install/active some email logger og logging functionality for outgoing emails
2. Import some content from other WP site
3. Let importer create a new username for some of that content, when prompted
4. Edit the newly created user and add an email address
5. Observe the email log: ""To:"" field is empty
Expected: No email (attempted to be) sent when previous email is blank." knutsp
Untriaged tickets (that need a patch) 38898 Lost password form not working with plugins that rename login URL Users 4.6.1 normal normal Awaiting Review defect (bug) reopened 2016-11-22T02:13:12Z 2017-07-19T08:20:43Z "When any given user, belonging to any given site, within a Multisite environment, try to recover its password, AND IF any security plugin which renamed the login URL is in place, the submission of that lost password form will fail because the action form has the wp-login.php URL hardcoded within. It should submit the form to the same URL you are currently on.
You can refer to this support thread to learn more:
https://wordpress.org/support/topic/bug-found-lost-password-form-outputting-incorrect-action-url-under-multisite/
So, the submit form URL at wp-login.php file should be outputted programatically rather than hardcoded.
Best regards
Marcelo
" Kent Brockman
Untriaged tickets (that need a patch) 38037 Maximum User ID Issue Users lowest normal Awaiting Review defect (bug) new 2016-09-13T10:46:57Z 2019-04-10T07:47:18Z "Hi,
We found that if you set the AUTO_INCREMENT value to 18446744073709551614 (which is 1 less than the maximum value of BIGINT), it creates a blank user in the admin user table. upon checking the mySQL database details, we found that the ID (_users) is 18446744073709551614 and the user_id (_usermeta) is 9223372036854775807. the reason for the test is, we have created a plugin that allows an admin to change the user ID of any user, so we where testing the maximum upper limits of. The only way to delete this user is manually, the delete option fails.
it would seem the ID (_users) supports 0 to 18446744073709551615
and
it would seem the user_id (_usermeta) supports -9223372036854775808 to 9223372036854775807
this can be checked in https://dev.mysql.com/doc/refman/5.5/en/integer-types.html
thanks" akaracing
Untriaged tickets (that need a patch) 40835 Password and email change emails should not contain site-specific wording on multisite Users normal normal Awaiting Review defect (bug) new dev-feedback 2017-05-22T12:20:14Z 2017-05-22T12:20:14Z "With multisite enabled, the following three actions (there may be more) result in an email being sent to the user which contains wording specific to the site that the user happens to be on when they perform the action:
* Attempt to change their email address.
* Confirmed change of email address.
* Changed password.
As an example, here's the text from the ""Notice of Password Change"" email:
{{{
Hi john,
This notice confirms that your password was changed on Site B.
If you did not change your password, please contact the Site Administrator at
siteb@example.com
This email has been sent to john@example.com
Regards,
All at Site B
http://mtrunk.wp/siteb
}}}
This is misleading because it's not immediately clear whether my password was changed on all the sites on the network, or whether the change was specific to ""Site B"".
In addition, the email address shown is the email address of the site administrator, not the network administrator. The site administrator does not necessarily have the ability to manage users.
There may be similar considerations to those raised in #21352 regarding a user's awareness of the site being part of a network of sites." johnbillion
Untriaged tickets (that need a patch) 44374 Remove deprecated contact methods Users 4.9.6 normal normal Awaiting Review defect (bug) new 2018-06-15T15:32:17Z 2020-06-01T16:14:10Z "AIM is dead (December 15, 2017), Yahoo Messenger will be shut down on July 17, 2018. I'm not sure about Google Talk, I think it's been retired a long time ago. In May 2013, Hangouts replaced Google Talk.
The way people are managing the contact methods nowadays is:
{{{#!php
user_email || $user_pass !== $old_user_data->user_pass ) {
$data['user_activation_key'] = '';
}
}}}
In the above code the variable $user_email is **daniel.o'brian@gmail.com**, but the $old_user_data->user_email is escaped and appears to be **daniel.o\'brian@gmail.com**, so there isn't the match and user activation key is cleared.
Can you confirm and provide a fix?
In the meantime, I can change this behavior by escaping the $user_email myself in the filter wp_pre_insert_user_data which is a few lines above the checking, I guess.
Thanks!" daniele.perilli
Untriaged tickets (that need a patch) 54310 WP_User_Query does not return results in the same format if fields set to all_with_meta and doesn't return any metadata Users normal normal Awaiting Review defect (bug) new needs-unit-tests 2021-10-22T17:54:26Z 2021-10-25T23:32:25Z "Digging into WP_User_Query if you set the fields to all_with_meta it returns an array index by the user_ID veers a keyed list for all other results
this is the
{{{
if ( 'all_with_meta' === $qv['fields'] ) {
cache_users( $this->results );
$r = array();
foreach ( $this->results as $userid ) {
$r[ $userid ] = new WP_User( $userid, '', $qv['blog_id'] );
}
$this->results = $r;
} elseif ( 'all' === $qv['fields'] ) {
foreach ( $this->results as $key => $user ) {
$this->results[ $key ] = new WP_User( $user, '', $qv['blog_id'] );
}
}
}}}
I feel we should return the same shape array for both so propose to set the all to array index to the User_ID's
with a change like this
{{{
if ( 'all_with_meta' === $qv['fields'] ) {
cache_users( $this->results );
$r = array();
foreach ( $this->results as $userid ) {
$r[ $userid ] = new WP_User( $userid, '', $qv['blog_id'] );
}
$this->results = $r;
} elseif ( 'all' === $qv['fields'] ) {
foreach ( $this->results as $user ) {
$this->results[ $user->ID ] = new WP_User( $user, '', $qv['blog_id'] );
}
}
}}}
And better still it doesn't return the meta values !!!
So let's add this as well
{{{
if ( 'all_with_meta' === $qv['fields'] ) {
cache_users( $this->results );
$r = array();
foreach ( $this->results as $userid ) {
$r[ $userid ] = new WP_User( $userid, '', $qv['blog_id'] );
$r[ $userid ]->meta = get_user_meta( $userid );
}
$this->results = $r;
} elseif ( 'all' === $qv['fields'] ) {
foreach ( $this->results as $key => $user ) {
$this->results[ $key ] = new WP_User( $user, '', $qv['blog_id'] );
}
}
}}}
" pbearne
Untriaged tickets (that need a patch) 55413 on user save apostrophes cause wp_mail error Users 5.9.2 normal normal Awaiting Review defect (bug) new 2022-03-17T16:22:40Z 2022-05-30T10:54:28Z "This is a follow-up to #18039.
On user save from the admin the input is not unslashed and so the
1. wordpress thinks that the email has changed, has it is compared against a unslashed value
2. it uses the slashed input which isn't a valid email address to send the email was changed message
Can we unslash the email input in the wp_insert_user and wp_update_user functions" dg12345
Untriaged tickets (that need a patch) 53109 wp_insert_user should return a WP_Error when passing a too long first_name parameter audrasjb Users normal normal Awaiting Review defect (bug) reviewing 2021-04-29T09:01:21Z 2021-04-29T22:55:35Z "When I call the wp_insert_user function to which I pass too long first_name, I do not get an error, but I get a 0-integer. Although the documentation says, either wp_error or integer-ok.
P.S. I create user with this function .." superpuperlesha
Untriaged tickets (that need a patch) 46035 Add set_display_name method to WP_Roles class Users normal normal Awaiting Review enhancement new dev-feedback 2019-01-18T13:44:45Z 2019-02-01T05:29:27Z "Currently, people are following tutorials on line on how to 'change' the display name of certain user roles in WordPress, by basically overwriting the name property every time on either `init` or `admin_init` hook.
This is total overkill, and a hacky way to change the role display name (not role name which governs the capabilities stored in the database).
If there was a method `set_display_name` (and a corresponding getter `get_display_name`) this cosmetic change could be done only once on plugin activation - this change would then be permanent in the database and you wouldn't need to run the 'rewrite' all the time just to change name (Editor to Blog Editor for instance, or Administrator to Operations).
Only way, to do this now is to copy the entire `WP_Role` object, then remove the original one, change one property and add a 'new' role.
This feels super hacky to me.
Thoughts, opinions, suggestions?" dingo_d
Untriaged tickets (that need a patch) 57508 Redirect after clicking reset password link does not return to original users table display page position Users 6.1.1 normal normal Awaiting Review enhancement new 2023-01-19T20:31:52Z 2023-01-31T15:13:34Z "It looks like the redirect does not pick up the search and paged variables in effect at the time the link is clicked. This resets the display of users back to the beginning.
in users.php
line 250:
$redirect = add_query_arg(
array(
'reset_count' => $reset_count,
'update' => 'resetpassword',
),
My end users find this an annoyance and so bring it to your attention. For destructive actions, this is less of an issue as the display changes." mjdewitt
Untriaged tickets (that need a patch) 34316 User status inconsistent between single-site & multisite Users 1.5 normal normal Awaiting Review enhancement new needs-unit-tests 2015-10-15T19:00:15Z 2017-09-27T15:30:10Z "The way a user's status is defined in WordPress differs between single-site and multisite:
* In single-site, the `user_status` column is used
* In multisite, there are two additional columns for `spam` and `deleted`
Not only this, but the `update_user_status()` function is multisite only, and the `user_status` column is an integer without an API to help announce what values equate to what results.
On the plus side, user statuses aren't really ever used in core. Marking users as spammers in multisite installations is the only real benefit of this feature as it exists today. I'd like to propose the following:
* Stop creating the the `spam` and `deleted` columns in `wp_users` on new installations
* ALTER the `user_status` column from `INT(11)` to `VARCHAR(20)` ala `wp_posts`
* A bevy of `wp_register_user_status()` like functions to introduce bonafide support for them
* A database upgrade routine to move user status `0` to `active` and `1` to `spammer`
* A new index on the `wp_users` table for the updated `user_status` column type. We may need a few, based on how users are commonly queried in core, BuddyPress, etc...
* Update the `WP_User` and `WP_User_Query` classes to suss out any `user_status` inconsistencies
A few considerations worth noting:
* Large installations would need to manually perform these DB upgrades. I'm embarrassed to say I've personally frozen WordPress.org for several minutes years ago by missing a `DO_NOT_UPGRADE_GLOBAL_TABLES` check on the `wp_users` table
* Several plugins use their own values in the `users_status` column, assuming their numeric ID is unique and special. The authors of these plugins would need notifying, and their code updating to support the above ideas
* This work *could* parlay into the Post Status API that's on infinite back-burner. There are some really excellent ideas floating around about how `post_status` could work that would translate nicely to users, too" johnjamesjacoby
Untriaged tickets (that need a patch) 53405 short circuit before current filters for get_edit_user_link Users normal normal Awaiting Review enhancement new 2021-06-15T07:50:14Z 2021-06-29T05:37:24Z "currently the function get_edit_user_link can be filtered BUT it is only after it has gone searching for an appropriate value.
This is problematic as on multisite this search may call get_edit_profile_url and then get_dashboard_url which in turn then runs get_blogs_of_user which pulls all the options for every site that the user is a member of into memory. This can be huge and completely unnecessary!!
There needs to be a way to short cicuit this function at the start before all this occurs.
" shawfactor
Future Releases 17370 Screen options and meta box settings can lose per-blog meta box positions Users 3.1 normal normal Future Release defect (bug) new 2011-05-10T21:13:37Z 2022-10-03T12:10:08Z "User preferences for admin interface appearance of the Dashboard and the Edit/Add New pages are stored in per-user options in `wp_usermeta`: `closedpostboxes_$page`, `metaboxhidden_$page`, `meta-box-order_$page`, and `screen_layout_$page`, where `$page` is one of 'post', 'page', or 'dashboard'. Users can customize the order of the Dashboard and editing meta boxes to better suit their workflow using the drag-and-drop AJAX interface to move the meta boxes into ordered columns and the Screen Options tab to show and hide the boxes. Many plugins add custom meta boxes to the Edit/Add New Post page.
In a multisite installation, with different plugins active on different blogs, users who rearrange an Add New Post page on a blog with a custom meta box and then rearrange it on a different blog without that meta box will lose the position of the custom meta box. Blogs can have different features and workflows implemented, and having per user options for the appearance instead of per user, per blog options limits the ability of a user to customize the interface.
The expected behavior for moving things around is that it changes on one blog, not on all blogs." jmdodd
Future Releases 38851 WP_User_Query cannot retrieve multisite users who have not been assigned a role on a site Users normal normal Future Release defect (bug) new needs-unit-tests 2016-11-18T15:11:32Z 2017-12-01T05:20:30Z "If you add a user to a multisite at network level, but do not proceed to assign them a role on a site within the network, `WP_User_Query` cannot retrieve those users (even if the query is run at network level), as they have no associated `wp_capabilities` meta_key.
To reproduce the problem:
1) Add a user to a multisite via Network Admin > Users > Add New.
2) Run a WP_User_Query at network level (e.g. by doing something like:
{{{
add_action('load-users.php', 'myAction');
function myAction()
{
$screen = get_current_screen();
if( $screen->base === 'users-network' {
$query = new WP_User_Query();
$users = $query->results;
}
}
}}}
The returned results will not include the user added in step 1. In fact, it will only return users who have capabilities set on the first site in the network, even though this query is not occurring at site level.
This could be fixed by allowing something like `'blog_id' => 'all'` in a `WP_User_Query`." robdxw
Future Releases 18161 Bulk action: Add user to multiple sites Users 3.2 normal normal Future Release feature request reopened 2011-07-18T19:07:04Z 2021-04-27T20:01:18Z "Currently, to add a single user to multiple sites, the super admin has to edit each site, add the user to the site, and then go on to the next site.
To improve this workflow, it would tremendously useful to be able to add a single user to multiple sites in the network admin.
This ticket could have scaling problems to solve." danielbachhuber
Future Releases 12720 Delete user and hook confusion when deleting users in Multisite Users 3.0 normal normal defect (bug) new 2010-03-26T12:42:59Z 2019-06-05T06:37:23Z "Currently:
The hook ''wpmu_delete_user'' fires when deleting user in Super Admin->Users.
The hook ''remove_user_from_blog'' when deleting user under site Users->Authors & Users.
In standard WP:
The hook ''delete_user'' is called when deleting users it should be the same in MultiSite when deleting from Super Admin->Users.
Or add new hooks and deprecate previous.
''delete_user_from_network'' for when deleting a user totally.
''delete_user_from_site'' for when deleting a user from a specific site. This is hook also then fires in non-MultiSite mode since that then corresponds to one site." andreasnrb
Future Releases 36405 User creation fails for users with long names. Users normal normal defect (bug) new 2016-04-03T05:49:00Z 2023-05-28T11:52:50Z "Summary: When creating a user with a long first or last name, the query that inserts the user into the DB is assumed to have succeeded, but that fact is never verified.
Sign in as an admin and create a new user, giving it the first name `ABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQRSTUVWXYZABCDEFGHIJKLMNOPQ` (or any 251-byte string). After submitting the form, you'll see a handful of error messages (line numbers are from trunk just now, but I can reproduce the bug as far back as 4.2.1):
{{{
Notice: Trying to get property of non-object in wp-includes/pluggable.php on line 1716
Notice: Trying to get property of non-object in wp-includes/pluggable.php on line 1717
Notice: Trying to get property of non-object in wp-includes/pluggable.php on line 1730
Notice: Trying to get property of non-object in wp-includes/pluggable.php on line 1738
Notice: Trying to get property of non-object in wp-includes/pluggable.php on line 1740
Notice: Trying to get property of non-object in wp-includes/pluggable.php on line 1742
Notice: Trying to get property of non-object in wp-includes/pluggable.php on line 1746
Warning: Cannot modify header information - headers already sent by (output started at wp-includes/pluggable.php:1716) in wp-includes/pluggable.php on line 1171
}}}
What happens is that the `$wpdb->insert( $wpdb->users, $data + compact( 'user_login' ) );` call in `wp_insert_user()` fails, but there's no check to ensure that it succeeded, so the code proceeds to try and create a new `WP_User` with ID `0`. This results in unexpected behavior, like sending a ""New User Registration"" email to the admin with blank ""Username"" and ""Email"" values.
The failure is due to `$wpdb->process_fields()` calling `$wpdb->strip_invalid_text()`, which truncates the `display_name` field (because the `display_name` field only allows 250 bytes), and because it then doesn't match the value passed into `$wpdb->process_fields()`, it returns `false`. So this isn't so much a bug about a text string that's too long, it's really a bug about not checking the return value of `$wpdb->insert()`.
I think the resolution of #10377 is probably the same kind of approach that could be taken here, since the problems seem similar." cfinke
Future Releases 23857 Delete User Should Delete Comments Users 3.5 normal normal enhancement new 2013-03-25T07:10:55Z 2019-06-05T06:39:10Z The delete user function should also delete that user's comments or attribute that users comments to the person specified. That way, deletion of accounts goes a lot smoother. jamcat22
Future Releases 26962 in wp-admin/profile.php no restoration filled if an error occurs fields. Users 2.0 normal normal enhancement new 2014-01-30T11:55:59Z 2019-06-05T06:39:41Z "I just saw that if the fields are filled and that we delete such a required fields (or causing an error in the syntax of email for example), no mechanism is in place to restore the information specified by the user, everything is reset.
This mechanism is however in place in the ""wp-admin/user-new.php"" when we disable javascript." QuarkSEO
Future Releases 21910 wpmu_create_user() standardization Users 3.0 normal normal enhancement new 2012-09-17T18:03:24Z 2019-06-05T06:38:47Z "There seems to be some inconsistencies between wpmu_create_user(), create_user(), and wp_insert_user(). The former two are wrappers, and do different things but potential to consolidate and clean up some old code.
Per Nacin:
>nacin: wpmu_create_user() should probably just go away.
>nacin: fairly useless function
>nacin: by default, it looks like wp_insert_user() would create a role-less user.
>nacin: as would wp_create_user()
Looking at wp_insert_user() it sets the default role if none is provided, where wpmu_create_user() would actually delete the default roles and caps.
Although, I'm not really sure there's a use case where you'd be using both the wpmu_new_user and user_register hooks simultaneously so possibly depreciate the former in favor of the latter.
One real issue with wpmu_create_user is that it returns false instead of the WP_Error object which is probably not desired since the error could be useful. The false return is used in wpmu_activate_signup() to either set the returned ID or create it's own WP_Error.
Lastly... documentation for create_user says it returns the ID, but it looks like it could potentially also return a WP_Error object. Didn't test, but possible documentation fix there.
" ryanduff
Untriaged tickets (that need a patch) 50098 CSVs that contain HTML fail upload test Upload normal normal Awaiting Review defect (bug) new 2020-05-06T06:42:45Z 2020-05-06T06:42:45Z "WordPress 5.0.1 (I believe) introduced file type checking so that uploaded files needed to be the correct MIME type for its extension. This caused CSVs detected as `text/plain` to fail the upload test. WordPress 5.0.3 fixed this so that .csv files can be uploaded if detected as `text/plain` (#45615, [44443]).
However, in trying to uploaded CSVs exported from WooCommerce, I have encountered CSVs that are detected as `text/html` if they have enough HTML in the product descriptions. So these files exported from WooCommerce cannot be re-uploaded to WooCommerce.
I have worked around the issue using the `wp_check_filetype_and_ext` filter, but ideally a similar carve-out for `text/plain` would be made for `text/html`.
I don't have time to write a patch right now, but I might be able to take a crack at it later this week/next week if no one else can.
For reference, this is how I bypassed the issue with the filter:
{{{
add_filter(
'wp_check_filetype_and_ext',
function( $wp_check_filetype_and_ext, $file, $filename, $mimes, $real_mime ) {
$wp_filetype = wp_check_filetype( $filename );
if ( 'text/html' === $real_mime && 'text/csv' === $wp_filetype['type'] ) {
$wp_check_filetype_and_ext = [
'ext' => $wp_filetype['ext'],
'type' => $wp_filetype['type'],
'proper_filename' => $filename,
];
}
return $wp_check_filetype_and_ext;
},
10,
5,
);
}}}" JakePT
Untriaged tickets (that need a patch) 22150 Customizer: Remove Image doesn't remove from Media Library Upload 3.4 normal normal Awaiting Review defect (bug) new 2012-10-10T05:35:15Z 2019-05-15T21:12:16Z "After uploading an image using the Theme Customizer, a ""Remove Image"" link appears - this seems to imply that clicking it will cause the image to be deleted entirely, rather than just hidden from the current view.
" pento
Untriaged tickets (that need a patch) 23188 Hardcoded relative url 'async-upload.php' in plupload/handlers.js Upload 3.5 normal normal Awaiting Review defect (bug) new 2013-01-12T11:47:48Z 2018-01-18T20:34:04Z "On line 127 in plupload/handlers.js you can find relative path to 'async-upload.php'.
It rather should use wpUploaderInit.url (or something like that), so you could use WP Plupload in front-end for example or with your custom uploading scripts.
Now you can write your custom uploader script and provide it via wpUploaderInit, but on that line in handlers.js it is ignored (and if you run it in front-end, bad request to ./async-upload.php is made)." drozdz
Untriaged tickets (that need a patch) 23483 Incorrect image URL for subsites when using UPLOADS constant on multisite subdirectory installation Upload 3.5.1 normal normal Awaiting Review defect (bug) new 2013-02-15T18:56:54Z 2017-07-08T00:41:31Z "If the UPLOADS constant is used on a Wordpress Multisite installed to subdirectory, using subdirectory mode, then image URLs for subsites are incorrect.
Example:
* WP MS installed to www.domain.com/wordpress, subdirectory not subdomain
* UPLOADS set to 'assets'
Main site uploads images to /wordpress/assets/... [[BR]]
Main site image URL is www.domain.com/wordpress/assets/...
1. Create subsite called 'subsite';
2. Subsite uploads images to /wordpress/assets/sites/2/...
3. Subsite image URL is www.domain.com/subsite/assets/sites/2/... when it should be www.domain.com/assets/sites/2/...
This is because wp_upload_dir() uses get_option('siteurl') to derive the URL. It is probably right for subdomain multisite but wrong in this use case." creativeinfusion
Untriaged tickets (that need a patch) 46775 Cannot allow multiple MIME for same file extension Upload 5.1 normal major Awaiting Review enhancement new 2019-04-02T15:55:20Z 2023-08-27T08:06:45Z "Using 5.1.1, .zip are being detected as application/zip on my PC, but the same file (exact same) is being detected as application/x-zip-compressed on another PC. I've attempted to DISABLE_UNFILTERED_UPLOADS and temporarily removed the is_super_admin constraint from wp-includes/functions.php but still no luck. I also wasn't able to add this as an array without throwing a PHP exception.
This prevents me from allowing users to upload .zip from their PC. It's not appropriate for me to ask the user to make any changes to their PC.
Any advice?" thedanhealy
Untriaged tickets (that need a patch) 30384 Cannot hook plupload's JavaScript consistently Upload 4.0 normal normal Awaiting Review enhancement new 2014-11-18T16:03:56Z 2019-05-15T21:15:59Z "Visit /wp-admin/media-new.php and enter the following into the console:
window.uploader.bind('FileUploaded', function (){alert(1)})
Upload a file and once that's complete your function will be executed.
However if you visit /wp-admin/upload.php or /wp-admin/post-new.php and run that JavaScript you'll find that window.uploader is undefined.
I'm trying to prompt users to add additional information about the images they upload, but without access to the Uploader object that appears to be impossible." tomdxw
Future Releases 44868 Upload plugin and theme functionalities do not check on PATHINFO_EXTENSION before upload. Upload normal normal Future Release enhancement new 2018-08-30T13:18:42Z 2018-08-31T06:39:52Z If you go to /wp-admin/plugins.php click the button **Add new** and you upload a .sql file or whatever file then this is possible. The fille end-up in the wp-uploads/ folder and will not be removed. There should which will check the extension and removes it if it is not a .zip file. csorbamedia
Future Releases 27860 Media Upload: Incorrect renaming increment for retina files Upload 3.9 normal normal Future Release feature request new 2014-04-17T12:23:40Z 2019-05-15T21:14:35Z "If a file is uploaded `myimgage.png` and then a second image is uploaded with the same name the file is renames `myimgage.png` to `myimgage1.png` this is fine.
However if a Retina image is uploaded using the Apple retina standard @2x i.e. `myimage@2x.png`
The increment is `myimage@2x1.png` this is not correct and should be `myimage1@2x.png`
Should be `myimage[[prefex]]@2x.png` NOT `myimage@2x[[prefex]].png` " phillbooth
Untriaged tickets (that need a patch) 53298 Checking if wp-config-sample.php file exists before checking if wp-config.php exists Upgrade/Install 5.7.2 normal trivial Awaiting Review defect (bug) new dev-feedback 2021-05-29T20:34:43Z 2023-07-12T06:17:11Z "Currently in WordPress core, wp-admin/setup-config.php checks if wp-config-sample.php file exists before checking if wp-config.php exists. If the sample file exists, it then checks if the wp-config.php file exists, and if so, suggests deletion if necessary. For security, some WordPress users may delete the sample file, and restrict open_basedir for directory above that of the web root directory. Because of these two cases, the current order produces the follow error:
`PHP message: PHP Warning: file_exists(): open_basedir restriction in effect. File(/var/www/example/wp-config-sample.php) is not within the allowed path(s): (/var/www/example/web:/var/www/example/private:/var/www/example/tmp:/tmp:...) in /var/www/example/web/wp-admin/setup-config.php on line 46`
If the check for existence of sample file could be moved after checking if wp-config.php exists, we could avoid this error and avoid checking if sample file exists if wp-config.php does and not checking both if they both do.
i.e. Moving the section commented `Support wp-config-sample.php one level up, for the develop repo.` to after the section commented `Check if wp-config.php exists above the root directory but is not part of another installation.` in `wp-admin/setup-config.php`" machineitsvcs
Untriaged tickets (that need a patch) 60397 Invalidate opcache after theme / plugin updates seebeen Upgrade/Install 6.4.2 normal normal Awaiting Review defect (bug) assigned dev-feedback 2024-01-31T10:10:01Z 2024-01-31T12:29:13Z "Depending on the server opcache configuration, there is a high possibility of getting an Internal Server Error, or similar after updating a plugin / theme.
Specific opchache settings I've verified that trigger the error are:
{{{
[opcache]
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=24
opcache.max_accelerated_files=130987
opcache.max_wasted_percentage=2
opcache.use_cwd=1
opcache.validate_timestamps=1
opcache.revalidate_freq=5
opcache.revalidate_path=0
opcache.save_comments=1
opcache.enable_file_override=1
}}}
Error happens because validate_timestamps is set to 1 and revalidate_freq is greater than 0. This means that after plugin update, error 500 will stay for up to revalidate_freq seconds due to invalid opcache.
This can be mitigated by adding a opcache_invalidate or opcache_reset call upon successful update." seebeen
Untriaged tickets (that need a patch) 49014 Silence set_time_limit() call in wp-admin/includes/class-wp-upgrader.php Upgrade/Install normal trivial Awaiting Review defect (bug) reopened 2019-12-17T15:39:09Z 2019-12-24T04:03:22Z "Aggiornamento delle traduzioni per Twenty Twenty (it_IT)…
Warning: scandir(/home/.dummy/temp/): failed to open dir: Permission denied in /home/user/wp/wp-includes/functions.php on line 2479
Warning: scandir(): (errno 13): Permission denied in /home/user/wp/wp-includes/functions.php on line 2479
Warning: array_diff(): Argument #1 is not an array in /home/user/wp-includes/functions.php on line 2479
Notice: set_time_limit() has been disabled for security reasons in /home/user/wp-admin/includes/class-wp-upgrader.php on line 468
Le traduzioni sono state aggiornate con successo.
Tutti gli aggiornamenti sono stati completati.
{{{#!php
support forums.' ) . ' ' . __( '(WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.)' ), headers_sent() || WP_DEBUG ? E_USER_WARNING : E_USER_NOTICE );
$response = wp_remote_post( $http_url, $options );
}
}}}
The message ""Something may be wrong with WordPress.org or this server's configuration. If you continue to have problems, please try the support forums"" could be better. Right now if wordpress.org is up (which code can check?) then the problem is with their host. If they post to the Support forums there is no easy answer there.
While there is a solution to this mentioned in #27091 that solution is not suitable for most users.
I would suggest a longer timeout and a message that they could copy to their webhost to assist the host if a connection is being blocked." podz
Untriaged tickets (that need a patch) 58808 Proposal: track object cache type in update checks Upgrade/Install normal normal Awaiting Review enhancement new dev-feedback 2023-07-14T10:54:07Z 2023-07-14T16:49:23Z "Related: #56751, #48116
I think it would be helpful to send the `wp_using_ext_object_cache()` value as part of the update requests.
We already send the list of installed PHP extensions, so it's possible to know whether e.g. redis or memcached are installed, but not if they are actually used.
Ideally we would also know the exact type of object cache that is being used (e.g. if it's actually redis or memcached or something else). That would be also very useful for the `wp cache type` command, [https://github.com/wp-cli/cache-command/issues/68#issuecomment-1433755427 as suggested here].
This could be done via `WP_Object_Cache::get_type()` and a `wp_cache_type()` function for example." swissspidy
Untriaged tickets (that need a patch) 51496 Scroll to the first plugin which is going to be updated after clicking on 'Apply' while Bulk actions 'Update' is selected to show that process is in a progress. audrasjb Upgrade/Install 5.5 normal normal Awaiting Review enhancement assigned 2020-10-11T18:54:23Z 2023-06-08T08:35:51Z "If you are clicking on 'Apply' while Bulk actions 'Update' it looks like nothing is happening and it's why you want to click several times in a row.
This functionality can be combined with an improvement according to #40966 ticket. If this multiple update issue is hard to fix, possibly to add a scroll to the first plugin which is going to be updated can be easier." oglekler
Untriaged tickets (that need a patch) 43916 Auto update translations when the respective plugin/theme is updated Upgrade/Install normal normal Awaiting Review feature request new dev-feedback 2018-05-01T13:41:41Z 2019-01-06T02:23:13Z "I find updating translations a bit of a pain because they only seem to appear (rightly so though) once you've updated a plugin or a theme. It'd be great if translations could be automatically updated after the respective plugin or theme has been updated removing the need to check if there are any translations waiting.
Most often I find myself updating a plugin and then committing the update into version control and it's not until the commit has gone through that I reload the page to see that I now have new translation strings waiting. They really should be bundled with the main update of the plugin/theme." danieltj
Untriaged tickets (that need a patch) 49515 SSL requirement during installation with SQL command through admin if mixed content Upgrade/Install normal normal Awaiting Review feature request new dev-feedback 2020-02-26T14:08:12Z 2021-05-11T07:07:35Z "Would it not be a good idea to highlight / warn the user if they try to use http instead of https?
Furthermore, it would be very beneficial if wp admin offered a solution in terms of a SQL command for fixing mixed content if SSL is added after the fact.
This might already be in the pipeline?" bjornenio
Untriaged tickets (that need a patch) 20947 feature request: one-click update for core, themes and plugins (all in one) Upgrade/Install normal normal Awaiting Review feature request new dev-feedback 2012-06-13T22:48:50Z 2018-08-13T17:00:35Z I'd love to have the one-click update be truly one-click so that you can click once and update core, themes and plugins all at once as opposed to having to initiate three different updates. jkudish
Future Releases 36887 Database upgrades should fail gracefully Upgrade/Install low normal Future Release defect (bug) new 2016-05-19T03:48:30Z 2022-07-07T14:19:10Z "Currently, `wp-admin/upgrade.php` and `wp_upgrade()` don't check that the database has actually upgraded properly, before returning a success message.
Making them fail gracefully would be nice." pento
Future Releases 47315 Download authenticity message has no actionability Upgrade/Install 5.2 normal normal Future Release defect (bug) new 2019-05-18T11:11:24Z 2023-08-22T01:57:18Z "== Problem
While testing some upgrades of themes I noticed the following message:
The authenticity of twentynineteen.1.4.zip could not be verified as no signature was found.
As a user I have no idea what this means and more importantly, what I can do about it.
== Proposed solution
Add more context about what it means, why it is a not a blocker (soft-fail) when this is the case.
This could be a page on WordPress.org or explained in-line.
Provide a context on where this should be solved, locally/server/WordPress.org
=== Expectations
I would have expected the theme update to be verified as it is downloaded from WordPress.org directly.
" jipmoors
Future Releases 24579 Add Drag'n'Drop UI to plugin and theme manual uploaders Upgrade/Install normal normal Future Release enhancement new 2013-06-14T17:03:38Z 2023-12-18T16:24:54Z "We have this nice looking easy to use drag-n-drop UI for our media, is there anything stopping us from having it for our plugin and theme uploaders? I know most people use the search that goes through the .org repo, but it's foolish to think that's the only place people ever get their products. This would help facilitate a consistent user experience throughout the entire WP Admin.
Edit:
If possible, support multiple uploads too." tw2113
Future Releases 44894 Add support for an optional `$roles` parameter to `populate_roles()` flixos90 Upgrade/Install normal normal Future Release enhancement assigned needs-unit-tests 2018-09-05T08:05:50Z 2019-01-23T23:22:19Z It should be possible to provide custom roles (and capabilities) to `populate_roles()` when populating a new site with its roles. This came up during work on #41333. flixos90
Future Releases 37130 Auto-download language packs when installing manually Upgrade/Install normal normal Future Release enhancement new 2016-06-20T09:08:17Z 2020-09-23T20:45:03Z "Themes and plugins can be downloaded from Rosetta sites (locale.wordpress.org). When they're downloaded, they are only available in English and whatever locale packages a theme/plugin author has decided to ship. They do not include language packs made available from translate.wordpress.org.
As a result, if I download a plugin from the German plugin directory and manually install it, even if it's fully translated into German and a language pack is available, I won't see the interface in German. Thus, this ticket.
On manual install, we should check for an available language pack and auto-download the language pack." samuelsidler
Future Releases 51695 Include Upgrade Notice in post-auto-update emails Upgrade/Install 5.5 normal normal Future Release enhancement new 2020-11-02T01:22:59Z 2021-06-05T13:58:46Z "When a plugin update is released, an optional `Upgrade Notice` is visible on the Updates page explaining anything important about a plugin release.
In the current age of automatic updates for plugins, those messages are not seen.
I'm proposing that the Upgrade Notice field should be included in the post-auto-update emails related to the plugin - if the author has set the field that is.
This would also be of benefit where a plugin receives a pushed force fix from WordPress.org for a security reason, a recent example was where someone who had not opt'd in to plugin auto updates received the update and was confused/concerned there was a bug.
In that case, had the upgrade notice been included the end-user would've seen a pretty generic, but helpful text of `Version %s contains security fixes and is highly recommended for all users.`
" dd32
Future Releases 12671 Installer page doesn't check if MySQL tables were created successfully Upgrade/Install 2.9.2 normal normal Future Release enhancement assigned 2010-03-22T17:47:33Z 2018-12-15T22:52:14Z "When running the web-based setup script - My Mysql user didn't have create permissions so no tables were created but the message (underneath all the MySQL errors) said setup was successful.
I think it would be worth doing a check for no MySQL errors before proclaiming the installation a success." thedotproduct
Future Releases 14393 Maintenance mode overkill. Please refine usage of it Upgrade/Install normal normal Future Release enhancement new 2010-07-22T22:12:14Z 2017-03-18T14:52:11Z "Though many tickets have been posted about the Maintenance Mode not resolving, I think that the problem is on a different level.
It is unacceptable that even a failed upgrade of an inactive theme can break a complete Site or even Network. Case in point: I just followed the upgrade alert for an inactive theme, hosted on the WordPRess theme repository.
(Apparently it had an error (Incompatible Archive. PCLZIP_ERR_BAD_FORMAT (-10) : Unable to find End of Central Dir Record signature.) But the point is, this should not have put the entire network in maintenance mode for 10 minutes.
Maybe a check can be done for plugins, themes etc: if they are active, then maintenance mode can be used (though I am definitely not a fan of it anyway)." bike
Future Releases 50674 Plugin and Theme Update Hooks pbiron* Upgrade/Install normal normal Future Release enhancement accepted dev-feedback 2020-07-15T22:48:19Z 2020-10-19T18:10:59Z With plugin and theme auto-updates shipping with core in 5.5, I think it's worth considering adding some more hooks around the plugin and theme process to perhaps run prior to and after a particular update is run. Hooks like `plugin_updated` and `theme_updated`, and maybe some `pre_*` versions of those. davidbaumwald
Future Releases 58380 Setting time limit for updates doesn't always work. pbiron* Upgrade/Install normal normal 6.6 enhancement accepted dev-feedback 2023-05-23T13:34:30Z 2024-02-12T09:05:39Z "Warning: set_time_limit(): Cannot set max execution time limit due to system policy in /customers/7/5/e/lucasgent.be/httpd.www/***/wp-admin/includes/class-wp-upgrader.php on line 475
I usually comment out these lines since on my host one.com I ALWAYS get this additional warning line after succesfull updates.
Is there something that can be done, so I don't have to do this for each new WP site...? Maybe a sort of option where you can enable/disable this? " NekoJonez
Future Releases 26822 During upgrade, no errors thrown when file permissions are wrong Upgrade/Install normal normal defect (bug) new 2014-01-13T10:58:08Z 2019-06-04T21:10:10Z "I am, for the first time, attempting a Wordpress auto-upgrade.
I was quite shocked to immediately see an FTP credentials dialog, as these credentials I treat as secret and do not wish to randomly spew them into the system that theoretically should simply be able to modify itself -- if filesystem permissions were proper.
I wish to see an error message ""tried X, failed, exact failure error message, now trying FTP""
A number of current chatters in #wordpress on FreeNode state that this is actually not an error -- a position I vehemently disagree with.
If _any_ operation fails, in the due-course of a program, SOMETHING should elaborate this within the normal course of execution for the task, especially the app itself that cannot write its own files.
I would much rather like to see this from within the app updating itself, and not have to deduce it via any number of other, less-obvious methods, such as error logs on the server, filesystem access denial audits, etc. " mystica555
Future Releases 28300 Two issues in the code for auto-uploading to subfolders Upgrade/Install 3.9.1 normal normal defect (bug) new 2014-05-18T17:05:26Z 2023-03-15T18:21:55Z "There are two issues in the code for auto-uploading to subfolders within a change rooted FTP (wp-admin/includes/class-wp-filesystem-base.php).
First, it adds a ""/"" to the replacement expression when the source replacement already contains a ""/"" (Note that ABSPATH has a trailing slash):
{{{
$potential_folder = preg_replace( '#^' . preg_quote( $dir, '#' ) . '/#i', trailingslashit( constant( $constant ) ), $folder );
}}}
This should be:
{{{
$potential_folder = preg_replace( '#^' . preg_quote( trailingslashit($dir), '#' ) . '#i', trailingslashit( constant( $constant ) ), $folder );
}}}
Second, it checks that the directory exists. This is not the case during theme and plugin installs, where the not existing directory is specified. Instead, only the parent should be checked.
After:
{{{
if ( $this->is_dir( $potential_folder ) ) {
$this->cache[ $folder ] = $potential_folder;
return $potential_folder;
}
}}}
Adding:
{{{
else {
$potential_parent_folder = trailingslashit(preg_replace('#[^/]*/$#', '', $potential_folder));
if ( $this->is_dir( $potential_parent_folder ) ) {
$this->cache[ $folder ] = $potential_folder;
return $potential_folder;
}
}
}}}
Would test for a valid parent, instead. (E.g. wp-content/themes instead of wp-content/themes/newtheme)" wiziapp
Future Releases 32652 Use `ignore_user_abort()` to avoid some update failures Upgrade/Install normal normal defect (bug) new 2015-06-15T05:50:51Z 2023-03-15T18:42:39Z "As mentioned in [comment:5:ticket:16066] and [comment:5:ticket:29679] we should consider using `ignore_user_abort()` to prevent the potential issue of an upgrade process being aborted mid-way due to a browser cancellation.
This could be called before any update activity starts, or perhaps only after actual changes start happening (ie. after the zipfile download, before the file alterations)." dd32
Future Releases 27758 WP_Error data is false in _unzip_file_ziparchive Upgrade/Install 3.7 normal normal defect (bug) new 2014-04-11T14:25:07Z 2019-06-04T21:10:49Z "This is a follow-up to #22704, and the short version because after my long version crashed on 'continue to preview' :(
{{{
return new WP_Error( 'mkdir_failed_ziparchive', __( 'Could not create directory.' ), substr( $_dir, strlen( $to ) ) );
}}}
`substr( $_dir, strlen( $to ) )` results in false for the 'upgrade' folder and the zipfile folder itself. For the other folders the 'data' is simply not very informative and could be even confusing.
Before [25780], it used to be just `$_dir`; isn't that a much more informative feedback?
" ruud@…
Future Releases 35536 WP_Upgrader goes too far up when enumerating parent paths on a network share Upgrade/Install 3.7 normal normal defect (bug) new 2016-01-19T22:43:29Z 2019-06-05T06:43:16Z "In `/wp-admin/includes/class-wp-upgrader.php`:
When `is_vcs_checkout()` is walking up parent folders, the behavior of `dirname()` causes WordPress to check for folders that couldn't possibly exist. For example, if ""inetpub-share"" was the name of a share on machine ""myserver"", the following folders might be searched for source control folders:
* `\\myserver\inetpub-share\wwwroot\.git`
* `\\myserver\inetpub-share\.git`
* `\\myserver\.git`
* `\.git`
Note that the last two are not even subfolders of `""inetpub-share"".` That is, the search should stop at `""\\myserver\inetpub-share\.git""` because `""inetpub-share""` should be considered a top-level folder.
Even more concerning is that checking for `""\\myserver\.git""` and `""\.git""` are very expensive operations in a network environment, which means that the upgrade logic takes a very long time or will time out.
My proposed remedy is to change this line:
{{{#!php
if ( $context_dir == dirname( $context_dir ) )
}}}
to
{{{#!php
if ( $context_dir == dirname( $context_dir )
|| (substr($context_dir , 0, 2)=='\\\\' && strpos(dirname( $context_dir ), '\\', 2)===false)
}}}
Thoughts?" vfs_hobbes
Future Releases 36428 Weird default value of option 'default_link_category' Upgrade/Install 3.5 normal normal defect (bug) new needs-unit-tests 2016-04-06T15:15:19Z 2020-06-05T06:22:07Z "The option `default_link_category` has value `2` after installing WordPress. It makes no sense since 3.5.
Generally, it's not a big problem, but we check referential integrity in our plugin and this fails because there's no `term_taxonomy` with ID `2`.
" JanVoracek
Future Releases 26710 Wrong redirect URL after core update when WP is in subdirectory Upgrade/Install 3.8 normal normal defect (bug) new 2013-12-24T11:05:58Z 2019-06-04T21:10:06Z "When updating WP 3.7.1 to 3.8 on a WP install that is located in a subdirectory (using the ""Giving WordPress Its Own Directory"" method), after the update, the browser forwards to a non-existing URL which causes a 404 error.
In this configuration, in the wp-config file, WP_SITEURL is set to example.com/wp and WP_HOME to example.com.
The update is triggered from the admin area located at example.com/wp/wp-admin/update-core.php
When the update finishes, instead of forwarding to example.com/wp/wp-admin/about.php?updated, it sends the user to example.com/wp-admin/about.php?updated. Because of the missing subdirectory, this displays a 404 error.
Upon returning to the dashboard, the user will notice that the update has been correctly applied, but he won't ever see the ""Welcome to 3.8"" page." tar.gz
Future Releases 23487 is_blog_installed gives erroneous result on moved database Upgrade/Install 3.0 normal normal defect (bug) new dev-feedback 2013-02-16T13:11:37Z 2021-03-30T14:02:15Z "I resently moved my blogs to a new database, but when I tried it out, on of the blogs wanted a new install. Of course I did not want to do an install and overwrite my blog.
I indirectly found the reason in is_blog_installed, which suppresses database errors. Thus I did not see this error.
SELECT command denied to user 'techblog'@'localhost' for table 'wp_options'
Of course it was my fault, but I virtually had to take the wordpress code apart to find out why my migration failed.
Of course this is not a big problem on new installs, but very likely to happen on moving databases.
" Kjeld Flarup
Future Releases 28630 "wordpress ""check for updates"" fails silently behind proxy server with https POST 501 Error" Upgrade/Install 3.8.1 normal major defect (bug) new 2014-06-25T14:58:24Z 2019-10-18T14:01:46Z "I was running wordpress 3.8.1 on a webserver inside a LAN where wordpress needs to use a proxy to access the web. This is taken care of by defining WP_PROXY_HOST and WP_PROXY_PORT in wp-config.php, so Wordpress and plugins worked correctly.
When checking the dashboard for updates, Wordpress and all plugins were always shown as up-to-date even as WP 3.9 and 3.9.1 were out.
I checked the network traffic when forcing an update check, and it turns out that in wp-includes/update.php, if ssl is available, the url used to check for updates is transformed from http url to https url. This happens in three places, e.g. :
{{{
$url = $http_url = 'http://api.wordpress.org/themes/update-check/1.1/';
if ( $ssl = wp_http_supports( array( 'ssl' ) ) )
$url = set_url_scheme( $url, 'https' );
}}}
Thus a HTTPS POST request is sent, and the proxy we have here (Squid) answers with an error 501 “Unsupported Request Method and Protocol”
It seems HTTP GET and POST works, I know HTTPS GET works with the proxy, but not HTTPS POST from WP.
After that, WP display that everything is up-to-date, no error message, even with WP_DEBUG set to true.
I commented the lines that switch to ssl if it is available, and everything worked fine : the updates were detected and installed with no further problem.
Unfortunately my 'fix' isn't one as I will have to do it again after each WP update.
Fixing this:
- At the minimum : If the update check fails (error 501 here) WP should NOT say there is no update, but display an error message to let the user know there may be updates available but that it could not check for it (displaying the error itself would be even better).
- Better :
Maybe this is due to the way WP connects to the server using the proxy, as SQUID should work with HTTPS POST (at least it does from my browser). It seems a similar problem is described in [http://www.perlmonks.org/?node_id=78114] and is due to the connection : apparently it should be : ''create TCP connection to proxy, send ""CONNECT xyz\r\n"", and only then establish SSL connection.''. If this can be fixed in proxy support for https (not sure this is the problem), that's the best solution.
- fast and unsecure fix: There could be a way (a wp-config var ?) to disable SSL when checking for updates but there are security implications as I assume SSL is used to confirm that the server is getting the updates from a legitimate WP server.
" manikb
Future Releases 27814 Automatic updates should not be silently disabled if I have .hg in file system root Upgrade/Install 3.7 normal normal enhancement new 2014-04-15T09:17:56Z 2019-06-04T21:10:55Z "My WordPress does not apply updates automatically, although it is told to via define('WP_AUTO_UPDATE_CORE', 'minor');. WordPress did not send any mail with an error report, so I had no idea how to debug that issue. I then found http://wordpress.org/plugins/background-update-tester/ which told me that all conditions pass except for
{{{
FAIL: The folder / was detected as being under version control (.hg).
}}}
'''What?''' Yes, indeed, I am managing system configuration files via Mercurial. The repo is placed in the root of my file system. This is *'''completely'''* unrelated to my WordPress installation.
I see the rational (http://make.wordpress.org/core/2013/09/24/automatic-core-updates/):
{{{
If the install is running as a SVN or GIT checkout, automatic updates are disabled
}}}
But the way it is currently detected is in my opinion strongly over-generalized:
{{{
It looks for .svn, .git, .hg, and .bzr folders in ABSPATH, and every directory above that up to /
}}}
It is fine if WordPress makes assumptions about its own eco system. However, the current implementation assumes that any DVCS placed in any directory when going up the file system hierarchy up to the root is controlling WordPress. What is this assumption based on? That WordPress should be the only thing running on a Linux box? :-) Seriously, this is not a good way to detect if the current ""''install is running as a SVN or GIT checkout''"".
I think everybody agrees that I should not be forced to get rid of my system configuration repository in order to make automatic updates work again. I think WordPress should change this behavior.
What are other good ways of determining ""if the install is running as a SVN or GIT checkout""? One could also question the rational behind this: ''If it is a SVN/GIT/... checkout then *'''most likely'''* it is a development version and the developer *'''most likely'''* does not want automatic updates to be enabled?'' Too many assumptions in this for my taste, even if we could reliably determine whether the current WP installation is a DVCS checkout.
Could that whole thing be done more explicitly?
What would be a quick workaround for me, if I really want to have automatic updates without getting rid of /.hg?
" jgehrcke
Future Releases 28845 Better error messages when uploading theme as plugin and vice versa pbiron Upgrade/Install normal normal enhancement assigned 2014-07-11T22:36:14Z 2023-03-15T18:29:52Z "When uploading a plugin package in the theme upload section, you will get an error message like:
{{{
Unpacking the package…
Installing the theme…
The package could not be installed. The theme is missing the style.css stylesheet.
Theme install failed.
}}}
You get a similar message when you try uploading a theme as a plugin.
Because a plugin or a theme package is detectable, the error message should be more helpful. It should point the user where to go to upload the package.
Ideally, we could just detect have the package installed anyone as the correct package type; however, for now, improved messaging could be really helpful." tollmanz
Future Releases 31902 Shiny Updates: Language packs updates Upgrade/Install 4.2 normal normal enhancement new 2015-04-06T10:25:26Z 2023-07-09T16:13:52Z "Installing or updating plugin
WP 4.1: There is also language packs update triggered and users are notified what was updated.
Current trunk: There is only message ""Updated!"" and nobody knows if language packs update was also triggered and which languages were updated?" pavelevap
Future Releases 34649 Support for filtering constants and .htaccess message in network setup Upgrade/Install normal normal enhancement new 2015-11-10T18:18:41Z 2023-03-15T18:42:10Z "It would be helpful if there were filters to modify the suggested constants and .htaccess message in network setup.
For instance, I'd like to be able to include a switch statement to define `DOMAIN_CURRENT_SITE` based on an environment variable. Similarly, I'd like to be able to disable the .htaccess message when WordPress is running on a Nginx / PHP-FPM setup." danielbachhuber
Future Releases 29260 Update site transients response differences Upgrade/Install 2.8 lowest normal enhancement new 2014-08-19T06:18:59Z 2019-06-05T06:45:21Z "Why do the update_themes and update_plugins have a different response type, one is an stdObject another is a simple array.
That being said the plugin and theme upgrader have the same discordance. Please make them so they are consistent with one another. " krotz
Future Releases 22076 WP Upgrader: update_bulk_plugins_complete_actions and update_bulk_theme_complete_actions should pass information about all plugins/themes to the filter Upgrade/Install 3.0 normal normal enhancement new 2012-10-02T07:56:19Z 2019-06-04T21:07:48Z "In class-wp-upgrader.php, line 1214 there is this line:
{{{
$update_actions = apply_filters('update_plugin_complete_actions', $update_actions, $this->plugin);
}}}
When adding a filter to it like this:
{{{
add_filter('update_bulk_plugins_complete_actions','test_filter',99,2);
function test_filter( $update_actions, $plugins ) {
echo print_r( $plugins, 1);
return $update_actions;
}
}}}
Only the last updated plugin info will be printed. However, it should contain information about all the plugins that were updated (since we are dealing with a bulk upgrade here)." ragulka
Untriaged tickets (that need a patch) 33574 Add ability to scroll through long toolbar menu items morganestes Toolbar 4.4 normal normal Awaiting Review enhancement assigned 2015-08-27T17:45:49Z 2022-06-24T11:55:06Z "Related to #15317, when a toolbar menu has many items, it cuts off at the window height.
We should make long menus in the toolbar (like the New... menu) scrollable by default to enhance UX." morganestes
Untriaged tickets (that need a patch) 53184 Toolbar Enhancements: turn off labels / disable plugins / auto-hiding Toolbar normal normal Awaiting Review feature request new dev-feedback 2021-05-11T16:48:44Z 2021-07-14T00:10:19Z "Something that can get pretty crowded quickly is the Toolbar. I have three suggestions for improving this:
- The option to turn on/off text labels next to the icons
- The option to disable / enable certain plugins to add things to the toolbar
- The option to enable / disable auto-hiding, where the toolbar hides until you move your mouse up (similar to what lots of people use with their Mac's dock)
I'd love to hear your thoughts." tomjdevisser
Future Releases 22660 "Admin bar in multisite: mobile tap on ""My Sites"" dropdown in back-end doesn't work" Toolbar 3.4.2 normal normal Future Release defect (bug) new 2012-11-30T20:40:17Z 2021-06-14T20:50:25Z "Quick steps here to reproduce an issue where the ""My Sites"" dropdown (multisite networks) will drop down and show the ""Network Admin"" link and the list of your sites. But, clicking on a site (to expand and see ""Dashboard"", ""New Post"", etc.) does not happen. Tapping the blog name just closes the dropdown.
I'm not sure what's different but I can consistently reproduce this when in the admin back-end (but works OK on front-end admin bar when viewing a site):
From /wp-admin/ on a mobile device (tested on iOS 6, iPhone 5, iPad) with a multisite network:
1. Tap ""My Sites"" in admin bar
2. See ""Network Admin"" and list of sites below
3. Tap one one of the site names
Expected: Site name expands to show ""Dashboard"", ""New Post"", etc. (same behavior as front-end when viewing site). Screenshot: http://d.pr/i/reOi
Actual: Tapping site name simply closes the ""My Sites"" dropdown, does not browse anywhere nor expand menu" devinreams
Future Releases 60685 Keyboard focus order mismatch in adminbar in front-end joedolson Toolbar 3.3 normal normal 6.6 defect (bug) assigned 2024-03-04T21:10:29Z 2024-03-05T15:38:45Z "When viewing the Admin bar on the front-end, the search tool is added visually in the far right corner, after the profile menu. In the DOM, however, the search bar is located before the profile menu.
These should be reversed in the DOM so that keyboard order matches visual order.
See r19518." joedolson
Future Releases 46003 Improve toolbar CSS Toolbar normal normal Future Release enhancement new 2019-01-16T10:42:03Z 2020-03-04T06:42:01Z "The admin toolbar has been around for years and has been iterated on many times. Its [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/css/admin-bar.css?rev=44544 CSS file] is now over 1000 lines long and weighs 24 KB. Even minified it's still over 20 KB, which I think is way too much. Given that the admin bar is loaded most of the time for many users, this just slows things down unnecessarily.
I believe there's an opportunity to clean up the CSS file, get rid of legacy selectors targeting things like IE 7 and IE 8, and perhaps even make it DRY by leveraging Sass.
It should be possible to reduce the size of the admin bar CSS without reducing functionality or usability." swissspidy
Untriaged tickets (that need a patch) 54109 Classic Editor - Image edit popup toolbar no longer appears when image has link TinyMCE 5.8 normal normal Awaiting Review defect (bug) new 2021-09-11T07:55:44Z 2021-09-21T13:29:02Z "After inserting an image into the Classic Editor, you can click on it and a small popup toolbar will appear with several alignment buttons and an Edit button.
Image without link, showing popup toolbar after being clicked:
[[Image(https://p377.p0.n0.cdn.getcloudapp.com/items/o0uPJNdL/c547caaf-3ab0-4d26-9f4a-f413da275bbf.png?source=viewer&v=7d5ba87b66148f1b317100ac3baa1cf0)]]
After you add a link to the image, or if you add a link while inserting the image, this popup toolbar no longer displays when clicking on the image. The popup will flash and then disappear.
Vid: https://share.getcloudapp.com/8Lu5YGzD
macOS Big Sur 11.5.2
Firefox 92.0
WP 5.8.1
TwentyTwenty
Classic Editor (No other plugins)
" ahortin
Untriaged tickets (that need a patch) 58486 Using WordPress 5.7.8 (but also all other more recent branches) - characters are stripped through TinyMCE Copy paste from Word TinyMCE 5.7.2 normal normal Awaiting Review defect (bug) new 2023-06-08T09:44:51Z 2023-06-08T09:44:51Z "Hi
Using WordPress 5.7.8 (but also all other more recent branches) - characters are stripped through TinyMCE Copy paste from Word.
Under conditions: Bulleted list, from word, pasted, containing a dot at the end of the word.
Detailed descpription with fix here:
https://github.com/tinymce/tinymce/issues/3480
https://github.com/aautio/tinymce/commit/b5f4db5a8377d2beb9ca3a1a7164587b280acbf4
Seems implemented in TinyMCE since March 31 2021, however the update of TinyMCE editor has not yet been included in current WordPress versions.
Can this still be applied?
Kind regards,
Ralph Gortzen
Application manager Atos.net Group site.
" rgortzen
Future Releases 50817 TinyMCE: default_link_target is ignored TinyMCE normal minor Future Release enhancement new 2020-07-30T10:56:21Z 2021-06-02T23:49:28Z "I use the following filter, to set the default_link_target for TinyMCE to _blank:
{{{#!php
{
console.log(editor.getParam('default_link_target'))
})
// output is: ‘_blank’
}}}
The problem is, that the default_link_target-setting is never taken into account inside the wplink-Plugin of WordPress:
{{{
src/wp-includes/js/tinymce/plugins/wplink/plugin.js
}}}
I have a Bugfix ready on a cloned repository of https://github.com/WordPress/wordpress-develop
Unfortunately there is the following inside the .gitignore-file of the repository:
{{{
/src/wp-includes/js
}}}
Is there any other place, where I could commit changes to the JavaScript code? Did I miss something? How could I create a pull-request on the github-repository with changed JS-Code?
" utoppo
Untriaged tickets (that need a patch) 55902 Block theme rendering issue Themes normal blocker Awaiting Review defect (bug) new 2022-06-02T11:27:45Z 2022-08-03T16:50:28Z "Hi,
I am from Pagelayer team.
And we have checked and found that in the `wp-includes/template-canvas.php` file, you have called the function `get_the_block_template_html()` above the header that breaks the flow of the calling hooks like (`get_header`, `wp_enqueue_scripts`, `wp_header`).
For example, If we add any `the_content` hook inside the `wp_enqueue_scripts` hook, then the `the_content` hook not working properly.
Please check and try fix the issue ASAP if possible.
" jivansoft
Untriaged tickets (that need a patch) 57246 Duotone SVG function does not check for CSS variable color format Themes normal normal Awaiting Review defect (bug) new 2022-12-01T15:12:35Z 2022-12-02T23:03:27Z "The function `wp_get_duotone_filter_svg` and/or `wp_tinycolor_string_to_rgb` do not verify the format of the color code passed to it. My theme uses a CSS variable `var(--nv-text-dark-bg)`. After getting `$color` from `wp_tinycolor_string_to_rgb`, it assumes the color array has valid values. Since the original color is not one of the expected formats, this generates the following warnings:
{{{
PHP Warning: Trying to access array offset on value of type null in /wp-includes/block-supports/duotone.php on line 422
PHP message: PHP Warning: Trying to access array offset on value of type null in /wp-includes/block-supports/duotone.php on line 423
PHP message: PHP Warning: Trying to access array offset on value of type null in /wp-includes/block-supports/duotone.php on line 424
PHP message: PHP Warning: Trying to access array offset on value of type null in /wp-includes/block-supports/duotone.php on line 425
}}}
Please change one or the other method to check for CSS variables before using values from `$color` array." mattf10
Untriaged tickets (that need a patch) 57817 Navigation block frame responsive issue Themes 6.1.1 normal normal Awaiting Review defect (bug) new 2023-02-28T07:21:31Z 2023-02-28T07:21:31Z I was editing header template part. As I added a navigation block and reduced the width size of the frame screen, the mobile view was showed. Then I clicked on the hamburger icon and opened the menu. Now, when I increased the size of the frame screen, the layout didn't change, and I couldn't close the menu even when I reduce the frame screen. amitpomu
Untriaged tickets (that need a patch) 56762 PHP file being ignored in block theme hierarchy Themes 6.0.2 normal major Awaiting Review defect (bug) new 2022-10-07T21:00:26Z 2022-10-20T15:05:54Z "Hi
I've tried the following in WP 6.0 and 6.1 as well as the TwentyTwentyTwo and TwentyTwentyThree themes.
Issue:
When using the ""Default Template"" option on a Page, the page.php file is ignored but page.html will work. You will see in admin that it is set to Index as it is ignoring the page.php file but if you have both .html and .php the .html will take precedence.
Admin + File structure: https://monosnap.com/file/0IwMr0nBwtXDkd8SEIb0QjUGTn7Qsb
It looks like the problem comes from the code below in this file `wp-includes/block-template-utils.php` line 313
{{{
$template_slug = substr(
$template_file,
// Starting position of slug.
strpos( $template_file, $template_base_path . DIRECTORY_SEPARATOR ) + 1 + strlen( $template_base_path ),
// Subtract ending '.html'.
-5
);
}}}
I'm not certain but I also found this in the Gutenberg side and wondering if it didn't make it across (unless I'm mistaken).
https://github.com/WordPress/gutenberg/pull/31478/files
It's been driving me mad!
" ryanpluckrose
Untriaged tickets (that need a patch) 57390 [ wp-includes/template.php - get_archive_template() ] - archive for post doesn't load the correct template Themes 1.5 normal normal Awaiting Review defect (bug) new 2022-12-28T09:41:31Z 2022-12-28T10:10:02Z "Good morning everyone, while making templates for the post-type 'post' I discovered that:
The get_archive_template() function ( in wp-includes/template.php line 150 ) for a post archive returns archive.php instead of archive-post.php while the get_single_template() function for a post returns single-post.php.
In my opinion, the two results don't agree each other and the first function should work for posts as well.
Thanks in advance.
" riccardodicurti
Untriaged tickets (that need a patch) 40221 switch_theme action + Live Preview = confusion Themes 4.7.3 normal normal Awaiting Review defect (bug) new 2017-03-21T17:09:49Z 2019-03-13T04:04:10Z "The switch_theme function has inside a hook named the same: switch_theme, it is used for theme deactivation actions, but the problem is that after you activate the theme via Live Preview - this action is executed, so can create confusion.
(switch_theme hook is for theme deactivation functions - https://codex.wordpress.org/Plugin_API/Action_Reference/switch_theme)
When we activate a theme (not via Live Preview) - then this hook is executed together with old theme, not with new theme, but when we have a Live Preview with a new theme, then this hook will be used with the theme that is inside the Live Preview, with it's files. That's why this hook is called incorrectly.
So if this is not by design and it is a bug then the fix would be to skip this hook after a theme activation via Live Preview.
" alexvorn2
Untriaged tickets (that need a patch) 32326 Improve Support for Structured Data Themes normal normal Awaiting Review enhancement new 2015-05-09T14:50:00Z 2019-10-13T00:52:06Z "There has been discussion before on various types of structured data. WordPress has limited support for microformats and it is a long-standing part of WordPress.
New standards for structured data continue to appear, and there have been some proposals in support. However, different people want support for different things. I think there is a solution with more general appeal.
body_class and post_class add classes to the body and post containers.
What if they were superseded by two new functions with a broader scope?
body_attributes and post_attributes which could add any attribute from a provided array into the body and post containers? Most of the structured data works on an attribute of the tags it is attached to, be it class or property or otherwise.
The body_class and post_classes continue to work as they always have.
Newer themes could use the attributes function, which could remove hentry adding by default, for example, and transfer control of structured data back to the theme.
There is also the possibility, if it isn't going too far, of adding a similar function for the content container.
" dshanske
Untriaged tickets (that need a patch) 51726 proposal: make specialized header name available inside header.php Themes 5.5.2 normal normal Awaiting Review enhancement new 2020-11-07T15:23:26Z 2020-11-08T08:26:43Z "You can call `get_header()` with an extra argument. For example: `get_header('wp-signup')`. This allows theme authors to create a specific header: `header-wp-signup.php`.
But it would be nice to also this name inside the regular `header.php` file, to allow for a small tweak instead of completely duplicating the header.php file.
My proposal is to modify this function in `wp-includes/general-template.php` line 27:
{{{#!php
$name ]) )
}}}
Then, inside `header.php` it would be possible to access the header name like this:
`$header_name = $args['__name']`" Jules Colle
Untriaged tickets (that need a patch) 21256 New theme feature - add_theme_support( 'content-width', $defaults ) chriscct7 Themes 3.4.1 normal normal Awaiting Review feature request assigned dev-feedback 2012-07-13T10:08:34Z 2018-11-22T22:16:27Z "Themes use '''$content_width''' variable to set the content area width, they use:
{{{
if ( ! isset( $content_width ) )
$content_width = 500;
}}}
This method has two flaws, it's not flexible and it does not support different sizes for different post-types.
WordPress has to make the content-width to be a builtin theme feature using '''add_theme_support()''', and make it more flexible and easy to update. I want to update this value using the Theme Customizer rather editing the function.php file.
The code needs to be easy to set and to support CPT, some thing like this:
{{{
$defaults = array(
'post' => '500',
'page' => '500',
'attachment' => '650',
'artist' => '300',
'movie' => '400'
);
add_theme_support( 'content-width', $defaults );
}}}
Just an idea for 3.5." ramiy
Future Releases 59464 Images hard-coded in block theme templates lack `width` and `height` attributes Themes 6.4 normal normal 6.6 defect (bug) new 2023-09-26T17:10:25Z 2024-03-13T15:33:21Z "All images hard coded into block templates and patterns should have height and width attributes (applies e.g. to the TT4 theme).
It also prevents loading optimization attributes from being added to these images, so effectively this harms both load time performance and leads to layout shifts." spacedmonkey
Future Releases 39083 Introduce singular capabilities for managing individual themes Themes normal normal Future Release enhancement new needs-unit-tests 2016-12-04T22:12:26Z 2017-07-14T19:41:15Z "As we did in #35614 for taxonomy terms, singular capabilities should be introduced for switching, editing, deleting, and updating individual themes.
This would allow fine-grained cap checks such as `current_user_can( 'switch_theme', $theme )` and `current_user_can( 'delete_theme', $theme )`." johnbillion
Future Releases 53356 Themes admin page: make theme details, active, and preview links always visible Travel_girl Themes normal normal Future Release enhancement assigned 2021-06-07T23:21:42Z 2024-01-29T20:21:48Z "Follow up from #52649
In ticket 52649, we fixed a number of accessibility issues in the theme navigation. In the course of discussing that, there was a proposal to modify the layout so that the three action buttons for a theme were always visible, without obscuring the theme screenshot.
Since it was beyond the scope of the original ticket, we opted to complete that ticket and open the design issue as a new ticket.
See:
https://core.trac.wordpress.org/ticket/52649#comment:15
https://core.trac.wordpress.org/ticket/52649#comment:27
" joedolson
Future Releases 12839 Themes should be sandboxed on activation to prevent fatal errors Themes 3.0 normal normal Future Release enhancement new 2010-04-04T06:16:25Z 2021-01-02T20:23:28Z "I've just made a child theme of TwentyTen by copying the folder over, renaming, and adding a Template: header to the style.css file.
Upon activation, I've been thrown to a page with a fatal error due to redefining a twentyten function.
Ideally, theme activations should be passed through a sandbox style activation the same as plugins." dd32
Future Releases 60644 When theme installation fails, add a link to return to theme installer page Themes normal normal Future Release enhancement reopened 2024-02-27T05:51:47Z 2024-02-27T10:52:28Z "When for any reason a theme installation fails (If the user uploads a zip file other than the theme zip file) you will be confronted with an error and there is no way out.
Screenshot: https://nimb.ws/OK9mRU1
Of course, you can use the browser's built-in back button, but still it would be nice to offer an additional link ""Go to Theme Installer"" (leading to wp-admin/theme-install.php)" pmbaldha
Future Releases 51072 Add action hook after theme skip links sarahricker Themes 5.5 normal normal Future Release feature request assigned 2020-08-20T01:48:13Z 2020-10-16T14:42:38Z "Not sure if this is the right place. My feature request is to add a default hook in themes that is after skip links. I was recently working on a code project where I had a widget loaded in wp_footer but had no idea how to dynamically add a trigger link in the header for screen readers. If I used jQuery to add it before the first link, it could come before skip links and this is bad UX. If I added it after the first link, there could be multiple skip links creating a mess or maybe the theme doesn't have skip links, it could insert after a logo. There are also themes with top navigation, etc. that makes this rather difficult to figure out how to dynamically insert a trigger link.
If theme guidelines were updated to require a hook after skip links, I could simply add my trigger link like this.
{{{#!php
Trigger Link';
}); ?>
}}}
In the header.php file, it might look something like this.
{{{#!php
Skip to main content';
do_action( 'theme_after_skip_links' );
?>
}}}
Hopefully others will agree that there are situations this could be really useful to plugin and even child theme developers.
Thanks." alexstine
Future Releases 28734 Back button doesn't work when in the theme previewer Themes 3.9 normal normal defect (bug) new 2014-07-03T15:35:53Z 2019-06-04T21:11:44Z "To reproduce:
* Go to theme-install.php;
* Go to ""popular"", then to ""featured"" (clicking the back button here works);
* Click on ""Details and Preview"" for a theme;
* Click next;
* Click the browser's back button and you'll be pointed to theme-install.php." iseulde
Future Releases 24026 No /themes/ folder causes strange behaviour Themes 3.1 normal normal defect (bug) new 2013-04-10T07:05:04Z 2019-06-04T21:08:29Z "I know, that it's a tricky behaviour, but the problem exists.
1. Unzip WordPress files to appropriate place
2. Go to /wp-content/ and delete /themes/ folder
3. Install WordPress using it's wizard (ignore error in Dashboard that no theme activated)
4. Go to Plugins page in admin area
5. Install BuddyPress (this plugin register the theme BP Default that is situated in plugin folder - '''this is very important''')
6. Activate BuddyPress and complete its wizard to make BP functional
7. Go to Themes page in wp-admin
8. You will now see BP Default Theme. Try to activate it
9. Ta-da! You've just unlocked a new badge for catching an error." slaFFik
Future Releases 35280 Should feed_links_extra run when current theme doesn't support automatic-feed-links ? Themes 4.4 normal normal defect (bug) new 2016-01-01T19:31:10Z 2019-06-20T09:43:05Z `feed_links()` will return early if the current theme doesn't support `automatic-feed-links`, shouldn't `feed_links_extra()` do the same? tiqbiz
Future Releases 20859 Theme Installer: Preview should be scrollable on iPad and Kindle Fire Themes 3.4 normal normal defect (bug) new 2012-06-06T21:51:09Z 2019-06-04T21:07:35Z "Related to #20805. We've added techniques for smoothly scrolling iframes when they're the only frame on the page, but the theme installer still uses the overlay technique.
We may be able to iron this out in a similar fashion. Given that the old installer also used an overlay technique, this is not a regression." koopersmith
Future Releases 29555 Theme details allowed HTML Themes 3.9 normal normal defect (bug) new dev-feedback 2014-09-06T11:50:17Z 2019-06-04T21:12:13Z "Theme authors can use some HTML in their theme's style.css Description (and Theme Name and Author). If I'm not wrong, sanitize_header() in WP_Theme class sets the allowed HTML tags and attributes and for Description they are:
{{{
'a' => array( 'href' => true, 'title' => true ),
'abbr' => array( 'title' => true ),
'acronym' => array( 'title' => true ),
'code' => true,
'em' => true,
'strong' => true,
}}}
This works in the installed themes browser, where theme details are grabbed from the theme's style.css. But in the theme install views, where theme details come from WordPress.org API, some HTML tags (for example ""a"") are completely stripped out (don't know if this is intentional) while others (for example ""abbr"") are not unencoded before being used as HTML in the view and they end up being displayed as plain text, even in the WordPress.org site (see the last two screenshot).
I've found the someway related #27641 but please notice HTML is returned by the API already encoded so even using triple braces `>` etc. will still be `>`
Installed themes browser:
[[Image(http://i.imgur.com/B9TdIUa.png)]]
Themes install:
[[Image(http://i.imgur.com/JoP1yjp.png)]]
WordPress.org themes site:
[[Image(http://i.imgur.com/fyYmdeK.png)]]" afercia
Future Releases 14824 WordPress is not updating Theme option after making a theme a child theme by adding the line 'Template' to the child`s css without refreshing Theem activation Themes 3.1 normal normal defect (bug) new 2010-09-09T23:27:35Z 2019-06-04T21:05:56Z "Situation:
If you have 2 Themes on a 2 sites MultiSite install (each site is using one theme) and want to make one of them a child Theme of the other, you will go to one of them and add the line 'Template: NAME OF THE PARENT THEME' and save it.
After doing so the Child Theme will not inherit any Template Files from the parent until you deactivate/activate the Child Theme again.
Although it says in the ""Themes/Appereance"" section of the Child Themes backend 'CHILD THEME NAME uses templates from PARENT THEME NAME. Changes made to the templates will affect both themes.' even before deactivating/activating the Child Theme.
Looks like the template page might be checking the style.css and not update the option." drale2k
Future Releases 22414 validate_current_theme() should validate cached theme roots Themes normal normal defect (bug) new 2012-11-11T21:57:54Z 2019-06-04T21:07:55Z See ticket:22252#comment:14. To handle edge cases like the same theme being in multiple roots, validate_current_theme() should validate the cached theme roots, and update or delete them as appropriate. nacin
Future Releases 16883 "Add check for ""Template Version"" on theme activation" Themes 3.1 normal normal enhancement new dev-feedback 2011-03-18T03:28:36Z 2019-06-04T21:06:36Z "Related: #16395
In addition to adding Template Version to the standard meta information extracted from style.css in `get_theme_data()`, I think that for this information to be useful, a child theme shouldn't be able to be activated unless the template template the child theme uses (parent theme) meets the minimum version requirement identified in ""Template Version"".
A polite and graceful failure, with an error notice, would be preferable :-)
Reason: many times child themes utilize functionality that only exists in the latest version of a parent theme. They're stuck either writing backward compatibility into into their code, or risking whitescreens.
This not only prevents that, but it could be used to gently encourage the user to update the parent theme.
Certainly not a candidate for 3.1.1, but perhaps 3.2?" nathanrice
Untriaged tickets (that need a patch) 45076 Category counter is not updated Taxonomy normal normal Awaiting Review defect (bug) new dev-feedback 2018-10-11T06:08:01Z 2018-12-09T21:13:46Z "When we create new category from admin panel category successfully added in right category panel but it's counter is not updated.
Suppose i have create five category like !''Category 1!'', !''Category 1.1!'', !''Category 2!'', !''Category 2.1!'', !''Uncategorized!'' system show counter as 5 items but when i create new category called !''Category 3!'' it will added successfully in category list but total counter still show 5 items it should show 6 items but when i refresh that page it show counter as 6 items.
Check video https://youtu.be/rBmziC5_0XQ" mukesh27
Untriaged tickets (that need a patch) 52904 WP_Term_Query does not return deeper descendants of child_of when direct children of child_of are not part of the results Taxonomy normal major Awaiting Review defect (bug) new 2021-03-24T22:38:31Z 2021-03-24T22:38:31Z "Let's say for the hierarchical taxonomy `mytax` we have the following terms and term ids(in parentheses):
{{{
- A (1)
-- AB (2)
--- ABC (3)
- B (4)
-- BD (5)
-- ABC (6)
}}}
The following query works fine and it returns both terms with ID 2 and 3
{{{
print_r(
get_terms(
[
'taxonomy' => 'mytax',
'name__like' => 'AB',
'child_of' => 1,
'hide_empty' => false
]
)
);
}}}
However, the following query returns an empty array (since term_id=2 will no longer be in the results):
{{{
print_r(
get_terms(
[
'taxonomy' => 'mytax',
'name__like' => 'ABC',
'child_of' => 1,
'hide_empty' => false
]
)
);
}}}
but it is expected that it returns the term ABC with term_id=3.
This seems to be a bug with the logic in `_get_term_children()` where if direct children of the asking ancestor are not within the initial set of the terms, the recursion will never happen and deeper descendants are then removed from the query results." xParham
Untriaged tickets (that need a patch) 33585 Improve wp_list_categories to support multiple taxonomies Taxonomy 2.3 normal normal Awaiting Review enhancement new 2015-08-28T09:43:16Z 2020-06-04T10:31:18Z "Hi folks, I was working on a plugin feature request and from what I see it's not possible to pass an array on the `taxonomy` param from `wp_list_categories`, which prevents multiple taxonomies to be fetched at once.
I wanted to know if I can work on this ""enhancement"" for version 4.4, should be an easy modification since `get_terms` is an easy replacement for `get_categories`." bordoni
Untriaged tickets (that need a patch) 38278 Only query taxonomies assigned to the post types being queried Taxonomy 4.7 normal normal Awaiting Review enhancement new dev-feedback 2016-10-10T20:28:53Z 2017-04-20T03:02:26Z "While working on #31383 (Add `WP_Tax_Query` support to `WP_User_Query`), it was brought up that taxonomy queries do not check to see whether the requested taxonomies are registered to the requested post type.
Opening this ticket to discuss further. Should taxonomies always match the queried `post_type`?
From @boonebgorges on the other ticket:
Here's a way to frame the issue: are we likely to confuse developers if we allow (ie, don't throw errors for) queries like `get_users( ... 'tax_query' => ... 'taxonomy=post_tag' )`? Or `get_posts( ... 'tax_query' => ... 'taxonomy=some_user_taxonomy' )`? Or maybe these queries will just always end up empty? We should think through the possible confusions (or, maybe, lack thereof).
" desrosj
Untriaged tickets (that need a patch) 49559 Post Category Restoration Taxonomy 5.3.2 normal normal Awaiting Review enhancement new 2020-03-02T08:09:46Z 2020-03-02T08:36:54Z "Hi,
It is quite expecting nowdays that Post Category can be restored after we delete. Something like Trash Options should be there for it.
Thanks to Core Team.
Tristup" tristup
Untriaged tickets (that need a patch) 44762 Suggested changes to get_cat_name and get_cat_link to provide support for custom taxonomies Taxonomy normal minor Awaiting Review enhancement new 2018-08-09T10:53:19Z 2018-08-09T11:31:32Z "I discovered today that these functions only support the taxonomy 'category'. Can I suggest something along the following lines so that a custom taxonomy can easily be used?:
{{{#!php
name;
}
}}}
{{{#!php
Even if we don't have anything as robust as a ""term status API"", we still have to be sure that, at the very least, term_status != 'publish' terms are excluded from most queries - a change that has the potential for weird back compat issues.
- An internal taxonomy for draft terms, which may be more conservative but also more complex, especially if we want to support things like hierarchy for draft terms.
> It may be easier (maybe more code, but fewer hacks) to do on-the-fly registration of a separate internal taxonomy for each taxonomy that's getting a draft term added via the Customizer.
We'll want a future-proof solution that can support term meta being previewable as well. `auto_draft` posts are the inspiration on the posts end for the customizer approach." celloexpressions
Future Releases 38308 Accept 'meta_query' parameter in `WP_Tax_Query` Taxonomy 4.4 normal normal Future Release feature request new 2016-10-14T08:27:03Z 2017-07-30T15:37:16Z "It would by possible to extend like that?
{{{#!php
'post',
'tax_query' => array(
array(
'taxonomy' => 'people',
'field' => 'meta',
'meta_query' => array(
array(
'key' => 'map',
'compare' => 'EXIST'
)
)
),
),
);
$query = new WP_Query( $args );
?>
}}}
" Hrohh
Future Releases 13816 There should be built-in index pages for taxonomies Taxonomy normal normal Future Release feature request new dev-feedback 2010-06-10T12:20:29Z 2023-01-31T20:36:11Z "By default, if you enable 'pretty' permalinks, you get URLs like this for categories and tags: /category/slug, /tag/slug. The same pattern is used when adding custom taxonomy types.
These URLs often suggest to people that it should be possible to go 'up' one level, and access index pages at /category and /tag which list all of the available categories or tags (or maybe just the top x most popular ones for tags).
I'd suggest that we add a new template type of is_archive_index() which uses, in order of preference, taxononmyname-index.php (eg category-index.php), archive-index.php.
Within these templates, the 'loop' should return taxonomy items rather than posts.
This is all possible already using custom templates and get_terms(), but it'd be handy if it was built-in.
" frankieroberto
Future Releases 27412 Category meta box: cannot see chosen subcategory if many items in subcategory Taxonomy 3.8 normal normal defect (bug) new 2014-03-14T06:34:02Z 2019-06-04T21:10:38Z "Hi there,
if you have many items in a subcategory then you are not able to see that selected item in the meta box in admin unless it's alphabetically in the top 10 (or thereabouts) of the subcategorie items. The meta box only shows the parent, you will have to scroll down a lot to find the child too.
In my eyes it would make sense to move the chosen items in subcategories directly under their parents, ignoring the alphabetical ordering, so that you are able to see what has been chosen.
" landwire
Future Releases 16230 Category slugs not cut at 200 characters as it should under some conditions Taxonomy 3.1 normal normal defect (bug) new 2011-01-14T14:10:23Z 2019-06-04T21:06:22Z "When a category name is longer than 200 characters, it is cut to 200 and so is the slug automatically created upon category creation.
Now, if you edit the category name or slug afterwards, again trying to set a name longer than 200 characters it is cut again.
But, if you edit the name or slug and use a very long string like this one:
%d1%85%d1%80%d0%b0%d0%bd%d0%b0/%d1%80%d0%b5%d1%86%d0%b5%d0%bf%d1%82%d0%b8/%d0%b4%d0%b5%d1%81%d0%b5%d1%80%d1%82%d0%b8-%d1%80%d0%b5%d1%86%d0%b5%d0%bf%d1%82%d0%b8-%d1%85%d1%80%d0%b0%d0%bd%d0%b0/%d1%81%d0%bb%d0%b0%d0%b4%d0%ba%d0%b8%d1%88%d0%b8-%d0%b4%d0%b5%d1%81%d0%b5%d1%80%d1%82%d0%b8-%d1%80%d0%b5%d1%86%d0%b5%d0%bf%d1%82%d0%b8-%d1%85%d1%80%d0%b0%d0%bd%d0%b0-%d1%80%d0%b5%d1%86%d0%b5%d0%bf%d1%/
Then the slug ends up being longer than the 200 chars limit.
Now if on the Categories list dashboard page you have more categories than visible on one page, and the category you edited above is not on page 1, the page it is on will appear empty (while successive pages will be all right if they contain regular categories)
This has been reproduced on 3.1-RC2-17283" paolal
Future Releases 30379 Creating multiple Categories with same name under 1 parent Taxonomy 3.9 normal normal defect (bug) new 2014-11-18T05:50:40Z 2019-06-04T21:12:53Z "At present this structure is allowed:
{{{
Parent
- C (slug: c)
- C++ (slug: c-parent)
}}}
Attempting to add another 'C' category will fail with `A term with the name and slug already exists with this parent.`.
However, you can create this structure:
{{{
Parent
- C (slug: c)
- C++ (slug: c-parent)
Parent2
- C (slug: c-parent2)
}}}
and then move the term:
{{{
Parent
- C (slug: c)
- C (slug: c-parent2)
- C++ (slug: c-parent)
Parent2
}}}
without issue.
The question that remains here, is this what is expected?" dd32
Future Releases 31665 Duplicate slugs in DB, created for hierarchical terms with long, non-latin names, when the default slug already exists Taxonomy 4.1.1 normal normal defect (bug) new needs-unit-tests 2015-03-17T10:43:33Z 2019-06-04T21:14:42Z "When WP automatically generates a slug for a child term, and if the produced slug (which is normally generated just from the term's name) already exists in that taxonomy, it forms a slug by concatenating all the parent terms' slugs hierarchically
For example, in a term structure like:
Parent
-Child
If a term with the name ""Grandchild"" is to be inserted under ""Child"", normally it would get the slug ""grandchild"". However if that slug already exists in the taxonomy, WP generates the slug ""parent-child-grandchild"".
When the slugs have long, non-latin names, they are stored urlencoded in wp_terms, and the stored string's length can easily overflow the field's size ( varchar(200) ). Any terms created under that condition end up having the same slug stored in the DB (the produced urlencoded one, truncated to 200 chars).
To reproduce the issue:
Create a term (e.g. category) with this name (without the quotes): ""Ένα δύο τρία τέσσερα πέντε""
Create another term with the same name, defining the first term as its parent.
Create a third term with the same name, defining the second term as its parent.
The second and third terms end up having duplicate slugs in the DB, a situation which is normally an error.
This issue is also not detected if the same procedure is repeated using wp_insert_term(). Normally an attempt to insert a duplicate slug to the same taxonomy would raise a ""duplicate_term_slug"" WP_Error, which is not the case." nevma
Future Releases 36610 Loss of multibyte category and tag names Taxonomy normal normal defect (bug) new 2016-04-20T22:40:40Z 2019-06-04T21:22:20Z "Some multibyte category and tag names can be lost during creation.
Example: create a category with the name `テテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテAAA`. It is 201 bytes long and will be truncated by `$wpdb->strip_invalid_text_for_column()` to 200 bytes (`テテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテAA`) before the category is created.
However, the category name `AAAテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテテ` is also 201 bytes, but when it is truncated to 200 bytes, it splits a multibyte character, so when `wp_check_invalid_utf8()` gets called, it will truncate the string to zero bytes out of an abundance of caution, since the string ends with something that is not valid utf8.
It's clear that the category creator was not submitting invalid utf8, and the true goal of `$wpdb->strip_invalid_text_for_column()` was to ensure that the text would fit in the DB column without auto-truncation by the DB engine, so the ideal behavior should be that the string is truncated to the longest possible length that remains valid and fits within the column.
One way to get around this data loss would be a wrapper around `wp_check_invalid_utf8()`. If `wp_check_invalid_utf8()` fails, chop a single byte off the end of the string and check it again, up to the point where you have checked the string without the last five bytes (as I believe that the longest a single character can be is six bytes, although I'm not positive about that and I think anything longer than four bytes is mostly theoretical). Or, fix `$wpdb->strip_invalid_text_for_column()` so that it doesn't truncate in the middle of a multibyte character.
There might be a solution lurking in mb_strlen(). If `wp_check_invalid_utf8()` returns an empty string, take bytes off of the original string (up to 5 bytes) until `mb_strlen()` returns a smaller number and then try `wp_check_invalid_utf8()`.
Configuration details: Tested in WordPress trunk (4.5-RC1-37153) and PHP 5.2.17
Here's my `wp_terms` structure:
{{{
CREATE TABLE `wp_terms` (
`term_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(200) NOT NULL DEFAULT '',
`slug` varchar(200) NOT NULL DEFAULT '',
`term_group` bigint(10) NOT NULL DEFAULT '0',
PRIMARY KEY (`term_id`),
KEY `slug` (`slug`(191)),
KEY `name` (`name`(191))
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
}}}
See #36393 for discussion of a similar (but now-fixed) bug." cfinke
Future Releases 14093 Malformed category hidden from edit-tags, but shows in meta box Taxonomy low normal defect (bug) new 2010-06-25T19:11:49Z 2019-06-04T21:26:33Z "Came from a report in IRC by xomp.
In the following example, category 1's parent is category 2, and vice versa.
{{{
mysql> select term_taxonomy_id, term_id, taxonomy, parent from wp_term_taxonomy;
+------------------+---------+---------------+--------+
| term_taxonomy_id | term_id | taxonomy | parent |
+------------------+---------+---------------+--------+
| 1 | 1 | category | 2 |
| 2 | 2 | category | 1 |
| 3 | 3 | category | 0 |
| 4 | 4 | category | 1 |
+------------------+---------+---------------+--------+
4 rows in set (0.00 sec)
mysql> select term_id, name from wp_terms;
+---------+-----------------+
| term_id | name |
+---------+-----------------+
| 1 | Category 1 |
| 2 | Category 2 |
| 3 | Category 3 |
| 4 | Category 4 |
+---------+-----------------+
4 rows in set (0.00 sec)
}}}
On edit-tags, you'll see only Category 3.
In the hierarchical meta box, you'll see:
{{{
Category 3
Category 1
- Category 2
- Category 4
}}}
If we decide to show corrupted data, we should be consistent. At the very least, edit-tags should reveal more than the meta box, not the other way around." nacin
Future Releases 35995 Registering taxonomies for attachment mime types Taxonomy 3.5 normal normal defect (bug) new 2016-02-29T05:13:30Z 2019-06-04T21:20:43Z "I stumbled across [https://core.trac.wordpress.org/browser/trunk/tests/phpunit/tests/query/taxQuery.php#L1008 an interesting unit test] in core that led me down a bit of a rabbit hole.
The test `test_tax_query_taxonomy_with_attachments()` in `phpunit/tests/query/taxQuery.php` calls:
{{{#!php
register_taxonomy_for_object_type( 'post_tag', 'attachment:image' );
}}}
I never knew that you could register a taxonomy to a mime type, so I looked into it, but from what I've found the support seems spotty.
First off, calling `register_taxonomy_for_object_type( 'post_tag', 'attachment:image' );` fails and returns `false`. As best I can tell, this is because `get_post_type_object( 'attachment:image' )` fails, since `$wp_post_types['attachment:image']` is not set. For the purposes of testing the query support, I added a taxonomy to an attachment mime type ""the hard way"" using the following:
{{{#!php
$GLOBALS['wp_taxonomies']['post_tag']->object_type[] = 'attachment:image';
}}}
On the querying side of the equation, support seems much better. The only area that's iffy is if you register a taxonomy to the `'attachment'` post type, but pass the mime type (e.g. `'attachment:image'`) to `get_object_taxonomies()`, you won't get the registered taxonomy. Since `attachment:image` is a subset of attachment, I would expect to get all the ""attachment"" taxonomies as well.
Breaking this all down, the main bug here is that '''it doesn't seem to be possible to register a taxonomy to an attachment mime type, despite there being support for this feature otherwise.'''
Side note, since the unit test `test_tax_query_taxonomy_with_attachments()` fails in registering a taxonomy to an attachment mime type, the rest of this unit test probably should have failed (for a couple of reasons)." mboynes
Future Releases 22511 Taxonomy manage screen checks for manage_terms and edit_terms, instead of just manage_terms. Taxonomy 3.0 normal normal defect (bug) new 2012-11-19T23:13:56Z 2019-06-04T21:07:57Z "I'm trying to set up permissions so the Contributor role can add terms but not edit or delete terms. I setup my taxonomy so it looks like this:
{{{
register_taxonomy( 'custom_taxonomy', array( 'post' ), array(
...
'capabilities' => array (
'manage_terms' => 'edit_posts',
'edit_terms' => 'manage_options',
'delete_terms' => 'manage_options',
'assign_terms' => 'edit_posts'
)
) );
}}}
However, when logged in as a contributor I get the error ""You are not allowed to edit this item."" In edit-tags.php there are two checks for caps, one is for manage_terms and one is for edit_terms. I don't believe the second one should be there, because looking at the other code it should be like this:
* User with manage_terms can access the main taxonomy page
* They can also add terms
* There are checks in WP_Terms_List_Table to restrict showing the Edit/Quick Edit/Delete links for users without those capabilities (edit_terms/delete_terms).
* There is even plenty of other checks on edit_terms in edit-tags.php to include/change the content shown to the user.. if the entire page is restricted for users without edit_terms, why are any of those necessary?
Even if I'm wrong on the fact that roles with edit_terms can't add new terms (it's not completely clear anywhere, it seems like manage_terms should be enough), I still think that this page should be viewable at the very least considering the other code in that page and the list table.
Recommended solution: move the edit_terms check back into case 'edit' (line 121 of edit-tags.php in trunk, currently) as it was before [15491].
This was introduced in: [15441] and [15491]. Related: #14343." andrewryno
Future Releases 32789 Abstract get_category_by_path into get_term_by_path Taxonomy normal normal enhancement new needs-unit-tests 2015-06-25T15:59:01Z 2019-06-04T21:15:41Z "Having a function like `get_term_by_path` would be great as currently you have to fork the `get_category_by_path` function on your own to get a term by path for any other custom taxonomy.
Would there be any opposition to a patch for this? The abstracted function wouldn't house the `_make_cat_compat` usage, which would remain in the backwards compatible `get_category_by_path` function after checking to see if $category is not null." sc0ttkclark
Future Releases 23422 Add query filter argument to register_taxonomy Taxonomy normal normal enhancement new needs-unit-tests 2013-02-08T12:38:35Z 2019-06-04T21:08:16Z "Following on from the #21240 ticket which introduced the show_admin_column functionality I would like to suggest an additional argument to easily add the select list query filter for a taxonomy to the post-type list.
Currently a taxonomy query can be added via the 'restrict_manage_posts' action and 'parse_query' filter.
It would be useful to add an additional register_taxonomy argument of 'show_column_filter' to define a standard select option list of the taxonomy terms. Things like default option and hierarchy could be optional settings is an array is passed instead of boolean.
" tifosi
Future Releases 34173 Edit locking for term management Taxonomy normal normal enhancement new 2015-10-06T18:41:30Z 2020-03-26T17:06:12Z "If you give a WordPress developer term meta, they'll want to add fields to the term edit page.
If there are numerous editable fields on the term edit page, then WordPress should make sure User B's changes don't accidentally override User A's changes.
Related #32202" danielbachhuber
Future Releases 33975 Improve capabilities management when registering custom taxonomy Taxonomy normal normal enhancement new needs-unit-tests 2015-09-23T12:02:12Z 2019-06-04T21:17:04Z "Currently we have such caps when using `register_taxonomy()` [https://codex.wordpress.org/Function_Reference/register_taxonomy#Arguments codex]:
{{{
'manage_terms' - 'manage_categories'
'edit_terms' - 'manage_categories'
'delete_terms' - 'manage_categories'
'assign_terms' - 'edit_posts'
}}}
IMO, setting `manage_terms` to false block access to page (cheating message),
setting `edit_terms` to false displays this message: ""You are not allowed to edit this item."", which is very odd. Editing means editing, So I should not be able to use Quick Edit and Edit links (they should be hidden).
Also, I propose to add a `create_terms` capability maping - for displaying the add term form and giving ability to create them, separately from editing/deleting.
Related: #22511" slaFFik
Future Releases 27079 Very long waiting if we have a lot taxonomy terms. Taxonomy normal normal enhancement new 2014-02-09T20:10:10Z 2019-06-04T21:10:31Z "I've observed a very very long waiting if we have a lot taxonomy terms (8K in my case) when i open a new post, my browser (Chrome 32) froze while 50 sec before to generate all
categories.
Other problem, in my category taxonomy page who lists 20 first items per default (excellent for fast loading) BUT in same time, it generates the parent drop-down with ALL cats ! Same thing above, browser froze a few seconds..
Maybe would be interesting to use ajax instead ?" QuarkSEO
Future Releases 29852 wp_update_term() should use wp_insert_term() internally Taxonomy 2.3 normal normal enhancement new 2014-10-03T16:59:38Z 2019-06-04T21:12:37Z "`wp_update_term()` and `wp_insert_term()` have a large amount of overlapping functionality. Things like argument sanitization, `term_exists()` checks, parent and alias_of validation, and even some hook names are shared between the two. Having the logic separate means twice the unit tests and twice the bug fixes for shared functionality. (See #29848 for an example.) This, in turn, has the potential to hold up future refactoring (#5809).
As much as possible, the duplicate logic should be pulled out of `wp_update_term()`. Update-specific validation should take place there, and then call `wp_insert_term()` with a `term_id` or `term_taxonomy_id` param. (Suggestions for syntax are welcome.) In `wp_insert_term()`, break out the logic specific to the creation of new terms, and only run it when no existing term ID is passed to the function. Then, choose whether to run `$wpdb->update()` or `$wpdb->insert()` as appropriate." boonebgorges
Future Releases 51280 wp_register_sitemap_provider() breaks sitemap functionality if provider name contains a dash (-) pbiron Sitemaps 5.5 normal minor Future Release defect (bug) assigned 2020-09-09T16:32:32Z 2023-07-12T09:47:19Z "The announcement post for the functionality (https://make.wordpress.org/core/2020/07/22/new-xml-sitemaps-functionality-in-wordpress-5-5/) includes the following snippet:
wp_register_sitemap_provider( 'awesome-plugin', $provider );
However, I believe that the name doesn't work in practice. From my experiences, using a dash in the sitemap provider name causes the following:
The map is listed on the index, but when trying to view it, you just view your site's home page (not a 404, and not anything sitemappy).
If you register the provider with the name 'awesome-plugin', render_sitemaps() sees the following data:
$sitemap => 'awesome' (Expected: 'awesome-plugin' )
$object_subtype => 'plugin' (Expected: null )
and then it returns early due to if ( ! $provider )
As another test, I tried simply changing the name of Core's User Sitemap from 'users' to 'foo-users' and got the same result. The map was listed on the index, but when trying to browse it, you just see your site's home page (not a 404).
Doing some debugging, render_sitemaps sees the following data:
$sitemap => 'foo'
$object_subtype => 'users'
and then it returns early due to if ( ! $provider )
" MadtownLems
Untriaged tickets (that need a patch) 47266 Template of shutdown handler for fatal errors should not be displayed for CLI scripts Site Health 5.2 normal normal Awaiting Review defect (bug) new 2019-05-14T17:27:13Z 2019-06-24T16:10:01Z "When running a CLI script that has a syntax error, the template's raw HTML and CSS are output to the command line.
I don't think that the shutdown handler for fatal errors should be loaded in a CLI context; instead, the default PHP behavior should be used instead.
This should handle the case where the CLI script is being run through WP-CLI, and also older scripts that were built before WP-CLI existed, which just load WP manually (i.e., check `'cli' === php_sapi_name()` rather than `defined( 'WP_CLI' )` )." iandunn
Untriaged tickets (that need a patch) 52945 wp_cache settings not recognized in site health / plugins Site Health 5.7 normal normal Awaiting Review defect (bug) new reporter-feedback 2021-03-30T23:19:14Z 2021-03-31T00:09:12Z "maybe only a false positive message:
wp_cache is set to false (must set to true for wprocket).
and in plugins (drop in): advanced-cache.php inactive (needs wp_cache true in wp-settings.php)
I did manually downgrade to wp 5.6.2 (without changing anything) and the errors disappears." pwallner
Untriaged tickets (that need a patch) 50055 Add more user-actionable information to the timezone health check Site Health 5.3.1 normal normal Awaiting Review enhancement new 2020-05-02T14:17:36Z 2020-06-15T20:14:58Z "The timezone health check added in #48692 is very handy, but it doesn't provide much information for a user to action to remedy the issue.
Other health checks, such as the error display health check, provide a link to more information on the support handbook. It would be great to:
* Get a page added to the support handbook about `date_default_timezone_set()` and how you can go about finding and removing it from your site
* Adding a link to this page in the timezone health check" johnbillion
Untriaged tickets (that need a patch) 57159 Add scheduled events in the site health report. Site Health normal normal Awaiting Review enhancement new dev-feedback 2022-11-21T10:18:15Z 2023-01-31T18:34:13Z "Hello,
Do you think it should be possible to have a list of scheduled events in the Site Health report ?
Having this information may help to debug some ""strange"" behaviour.
Thank you" sebastienserre
Untriaged tickets (that need a patch) 47210 Allow html on site health titles and description Site Health 5.2 normal minor Awaiting Review enhancement new dev-feedback 2019-05-10T07:37:41Z 2022-09-05T20:27:28Z "Hello there,
In /wp-admin/site-health-info.php#L115 we have this:
{{{
}}}
So we don't allow HTML content ? why!?
I propose the usage of wp_kses_* to allow clean html content.
Also line#141 we have this:
{{{
printf( '
%s
', $details['description'] );
}}}
We clearly allow any html, so I propose to sanitize using wp_kses_* too, we don't want embed/iframe/script here right?
Thank you for your feedback." juliobox
Untriaged tickets (that need a patch) 51527 Debugging in Multisite context: list of plugins Site Health normal normal Awaiting Review enhancement new dev-feedback 2020-10-15T06:41:03Z 2020-10-19T16:24:15Z "Hello,
On site Health in Multisite context, it could be cool to know if a plugin is site activated or network activated.
I'm currently debugging a conflict and I've deactivated all plugins. I'm reactivating one by one with the Site Health Active plugin list, but now I have activated all site plugin, several are network only and I have to re-check all one by one because it's not in the report.
Should be good to add in the plugin line ""network activated"" by example as it is in the plugin list" sebastienserre
Untriaged tickets (that need a patch) 59070 child theme should not be counted as additional theme Site Health 6.3 normal normal Awaiting Review enhancement new 2023-08-11T10:45:27Z 2023-10-25T00:28:15Z "Child theme should be notified as sub-theme, and not additional theme. If you have installed 2 theme, like Twenty Twenty-Three and Beelove+Beelove child, WP notified it is 3 theme and in notification is:
👉Your website has 3 themes installed, in the latest versions. Your website has 1 inactive theme besides Twenty Twenty-Three, the original WordPress theme, and Beelove_Custom, your active theme." MMZx
Future Releases 54351 Checking for temp update directories may throw warnings Site Health 6.0 normal normal Future Release defect (bug) new dev-feedback 2021-10-31T15:47:41Z 2022-04-04T05:25:30Z "in [51815] the Site Health function `get_test_update_temp_backup_writable` was introduced, which is meant to check if upgrade directories exist, and are writable.
When visiting the Site Health screen in a scenario where `WP_Filesystem` uses `ftpext` for manipulating the filesystem, this causes multiple warnings as the various calls to check for directories, and if they are writable, are causing PHP's `ftp_*` functions to fire, when there may not be a valid FTP connection available. (see [https://github.com/WordPress/wordpress-develop/blob/07ad6efdf7157d22424496d39d8c5635f28ecfbb/src/wp-admin/includes/class-wp-site-health.php#L1968-L1978 class-wp-site-health.php:1968-1678]
I wonder if the best solution here might be to inject a connection call, which could then be used to determine if any other fields should be checked, or revert to a default value, I'm thinking along these lines:
{{{#!php
$filesystem_is_connected = $wp_filesystem->connect();
$wp_content = ( $filesystem_is_connected ? $wp_filesystem->wp_content_dir() : false );
$upgrade_dir_exists = ( $filesystem_is_connected ? $wp_filesystem->is_dir( ""$wp_content/upgrade"" ) : false );
$upgrade_dir_is_writable = ( $filesystem_is_connected ? $wp_filesystem->is_writable( ""$wp_content/upgrade"" ) : false );
$backup_dir_exists = ( $filesystem_is_connected ? $wp_filesystem->is_dir( ""$wp_content/upgrade/temp-backup"" ) : false );
$backup_dir_is_writable = ( $filesystem_is_connected ? $wp_filesystem->is_writable( ""$wp_content/upgrade/temp-backup"" ) : false );
$plugins_dir_exists = ( $filesystem_is_connected ? $wp_filesystem->is_dir( ""$wp_content/upgrade/temp-backup/plugins"" ) : false );
$plugins_dir_is_writable = ( $filesystem_is_connected ? $wp_filesystem->is_writable( ""$wp_content/upgrade/temp-backup/plugins"" ) : false );
$themes_dir_exists = ( $filesystem_is_connected ? $wp_filesystem->is_dir( ""$wp_content/upgrade/temp-backup/themes"" ) : false );
$themes_dir_is_writable = ( $filesystem_is_connected ? $wp_filesystem->is_writable( ""$wp_content/upgrade/temp-backup/themes"" ) : false );
}}}
It should be noted that by providing `false` as the default value for all fields, we are essentially marking this check as valid, which may not be true at all, because if WordPress can't connect to the filesystem, it should instead be a failed test.
The directories should probably be considered non-writable if they can't even be reached, this needs different logic further into the checks as well?
This may still lead to a warning as well, if the `connect()` function is missing variables, in testing where no information is provided, it only complained about a missing hostname, we'll handle that in a separate ticket for the Filesystem API component." Clorith
Future Releases 53024 List https functionality health check failures as critical Site Health 5.7 normal normal Future Release enhancement assigned 2021-04-12T23:36:30Z 2021-11-10T14:06:47Z "In #52783 site health check https failures were reduced to warnings pending some documentation improvements due to false negatives increasing the load on hosting companies' tech support teams.
This follow up ticket is to return the warning level to critical with the following considerations:
* Fine tune when failures should report warnings or critical errors
* Improve documentation on WordPress.org to avoid overburdening hosting support teams
* Link to WordPress.org documentation as a primary call to action rather than contacting the user's host.
" peterwilsoncc
Future Releases 43989 "Allow plugin searches to be filtered by ""Requires PHP"" version information" Site Health normal normal Future Release task (blessed) new needs-unit-tests 2018-05-07T14:24:41Z 2019-06-24T16:10:01Z "**Note: This ticket is a subtask for the overarching #40934 ticket.**
If plugins now start making use of the ""Requires PHP"" version information in their plugin header, we should make sure that plugin searches can be filtered by their required PHP version.
This might include changes to the indexing infrastructure (indexing that information and allowing indexed queries against it) as well as changes to the UI (giving users the possibility to either use search flags in text form or faceted search mechanisms to communicate such a query." schlessera
Future Releases 47880 Extend unit tests for Site Health component. Site Health 5.2 normal normal Future Release task (blessed) new needs-unit-tests 2019-08-15T00:49:49Z 2020-07-06T23:20:09Z "A file for site health check unit tests has been added in `tests/phpunit/tests/site-health.php`.
At the time of writing it only includes tests for various states of cron, expanding these would help with future development of the component." peterwilsoncc
Untriaged tickets (that need a patch) 57790 Parsing of Shortcode Attributes: bug locating a final attribute Shortcodes 6.1.1 normal normal Awaiting Review defect (bug) reopened dev-feedback 2023-02-22T19:00:16Z 2023-02-28T12:38:15Z "`shortcode_parse_atts()` uses the `get_shortcode_atts_regex()` pattern to return all `attribute=""value""` matches, however the pattern does not account for shortcode strings where the final attribute pair does not have a space between `""` and `]`
\\
\\
{{{
shortcode_parse_atts('[shortcode-name category=""banana-stand"" money=""yes""]'); //no space
}}}
returns
{{{
Array(
[0] => [shortcode-name
[category] => banana-stand
[1] => money=""yes""]
)
}}}
\\
whereas
\\
{{{
shortcode_parse_atts('[shortcode-name category=""banana-stand"" money=""yes"" ]'); //has space
}}}
returns
{{{
Array(
[0] => [shortcode-name
[category] => banana-stand
[money] => yes
[1] => ]
)
}}}
I ran the `get_shortcode_atts_regex()` pattern through a couple regex testers and verified that the issue is the non-capturing group conditional following the end-quote of a value. " lemernbag
Untriaged tickets (that need a patch) 59509 Shortcode attributes named 0 are ignored Shortcodes 6.3.1 normal normal Awaiting Review defect (bug) new needs-unit-tests 2023-09-30T12:14:06Z 2023-10-04T10:02:59Z "Shortcode attributes in the form `0=...` are not picked up during parsing.
This is because the parser checks for an empty name with `empty(..)`, which also returns true for the string `'0'`." ourous
Future Releases 6984 wpautop() formats the the contents of shortcodes Shortcodes 2.6 normal normal Future Release defect (bug) new 2008-05-17T10:34:02Z 2019-04-01T10:04:10Z "`wpautop()`, the bane of my existence as a plugin developer, is at it again.
Here's an example of some PHP wrapped in a valid shortcode in a post of mine:
{{{
[code lang=""php""]$text = str_replace( array('
', '
'), array('
', '
'), $text);[/code]
}}}
The content that gets passed to my shortcode function is this:
{{{
$text = str_replace( array('
', '
'), array('
', '
'), $text);
}}}
Expected result: it shouldn't touch the insides of valid shortcodes (like adding line breaks or anything as it is doing now)." Viper007Bond
Untriaged tickets (that need a patch) 59824 PHP Warning raised in pluggable.php when passing NULL instead of a string Security 6.3.3 normal normal Awaiting Review defect (bug) new 2023-11-07T07:53:48Z 2023-11-07T07:53:48Z "The error message is related to the **hash_equals()**: Expected ''known_string'' to be a string, ''null'' given in /var/www/../wp-includes/pluggable.php on line 2577
Hackers often pass NULL when attempting to trigger a leaked server warning message while accessing **wp-login.php**. This can be easily fixed by introducing type checking in pluggable.php:
{{{
function wp_check_password( $password, $hash, $user_id = '' ) {
global $wp_hasher;
// If the hash is still md5...
if (is_string($hash) && strlen( $hash ) <= 32 ) {
$check = hash_equals( $hash, md5( $password ) ); //$hash is the **known_string** and it must be of type string
//The rest of the function
}}}
" budiony
Untriaged tickets (that need a patch) 50027 Retire Phpass and use PHP native password hashing Security normal normal Awaiting Review defect (bug) new needs-unit-tests 2020-04-29T10:36:12Z 2023-10-13T01:11:52Z "PHP comes with built-in password hashing functions since PHP 5.5. Now that we have updated the minimum requirements to PHP 5.6, we can rely on PHP to provide us with password hashing mechanisms that ensures a cryptographically secure random numbers are are used for salt, and the hashes are backwards compatible.
I created and maintain [https://wordpress.org/plugins/password-hash/ PHP Native Password Hash] plugin to swap WordPress's baked in Phpass with PHPs.
**0.Phpass recommends to use PHP native hashing**
> At this time, if your new project can afford to require PHP 5.5+, which it should, please use PHP's native password_hash() / password_verify() API instead of phpass.
I propose that we upgrade the hashing mechanisms to password_hash()/password_verify/password_needs_rehash() combo.
**1.We do not need to force users to change their passwords.**
Phpass-hashed passwords have the signature `$P`, and the very old MD5 hashes are fewer than 32 characters long. We will inspect the signature first, and if the password is using the old standard, we will validate the password one last-time, and then use password_hash() to rehash it. From this point forward, that user is ""upgraded"" to the new mechanism.
**2.Expose a filter for plugins**
The plugin I maintain supports BCrypt, Argon2I, and Argon2ID for hashing. We can expose a filter that WordPress core emits so plugins can change the hashing algorithm if necessary.
**3.Use BCrypt as the default algorithm**
If a plugin does not take over, WordPress core will use BCrypt. BCrypt is secure, and is available in any PHP version 5.5, 5.6, 7.* and 8.*.
**4.Do not remove Phpass**
We will **not** remove Phpass from WordPress core. This is needed for backwards compatibility to ensure that existing users will eventually be updated.
The end goal is that we seamlessly migrate active users passwords to better mechanisms without breaking functionality for existing users. Frameworks such as Drupal and phpBB (which used phpass in the past) have moved to better mechanisms since the minimum required PHP versions have been updated, and we can easily follow suit.
If the maintainers agree, I would be overjoyed to collaborate on patches.
" ayeshrajans
Untriaged tickets (that need a patch) 57882 User that has capability to create user can make only administrator. Security 6.1.1 normal normal Awaiting Review defect (bug) new reporter-feedback 2023-03-07T20:58:47Z 2023-03-07T23:58:11Z "I have user role ""Manager"" that has capabilities:
add users
create users
delete users
edit users
list users
remove users
That users should be able to create users with different roles except administrators (they doesn't have ""promote users"" capability)
When manager opens Add new user page he doesn't see dropdown with roles and created user becomes administrator." dangerd512
Untriaged tickets (that need a patch) 40237 Educate users about modern password best-practices Security normal normal Awaiting Review enhancement new 2017-03-22T17:00:51Z 2022-06-06T10:10:15Z "We've done several things over the past few years to encourage users to use stronger passwords, but we've never tried to educate them about ''why'' it's important. It's obvious to most of us, but I think it's common for the average user to think things like, ""Why would anybody want to hack into this small site I created for a non-profit?""
If someone doesn't understand ''why'' having a strong password is important, they're not going to be motivated to take any steps in that direction, and they may respond to any attempts to push them in that direction by adopting insecure workarounds to avoid it, like post-it notes stuck to their monitor with the password they reuse on all sites.
It seems like educating users about the risks of weak passwords, and easy ways to follow modern best practices, could be very effective.
My first thought would be something like this:
1. When a user is manually entering a password, if `zxcvbn` detects a low entropy score, then they're shown a message saying something like, `That password won't protect your account from hackers. Automated bots attempt to gain access to all accounts on the Web 24/7, no matter how small. Don't worry, though, there's an easy way to use very strong passwords, and you'll never have to type or remember them. Learn more.`
1. Clicking on `Learn more` would reveal a modal with a brief explanation of how to use password managers, with a link to a longer article (maybe [https://en.support.wordpress.com/selecting-a-strong-password/ similar to WordPress.com's], but more .org-specific).
1. The modal would also have a video embedded, since many people are more willing to watch a video than read a long article. We could put the video on WordPress.tv and subtitle it in all of the locales.
That's just one idea though, does anybody have any others?" iandunn
Future Releases 34041 Tying nonces to sessions breaks when users are switched Security 4.3 normal major Future Release defect (bug) new 2015-09-27T10:09:00Z 2019-06-04T18:12:27Z "Because of the way we have tied nonces to session tokens they are broken if you write code that follows the following pattern:
* Code switches user using wp_set_current_user
* Code generates a nonce
* ...time happens
* Nonce is verified for the switched user.
The underlying issue is that while we are switched to the different user we still generate nonces using the session token from the current logged in users cookie.
This is because wp_get_session_token only checks the cookie and either gives you back a token for the cookie or an empty string.
This also means if you are authenticating by an alternative method and not setting cookies - say OAuth Authorization headers - then your nonces don't get session tokens in them at all." westi
Future Releases 36087 Migration plan from insecure RNG fallback Security normal normal Future Release enhancement reopened 2016-03-04T00:08:44Z 2020-09-30T18:16:11Z "== Where we are today==
WordPress uses paragonie/random_compat to polyfill PHP 7's new CSPRNG functions in PHP 5 projects, (on PHP 7 it just used the new functions directly). However, it currently catches the `Exception` that is thrown when used on an environment in which PHP cannot access the kernel's CSPRNG (usually `/dev/urandom`). If an exception is caught, it then proceeds with the old way of doing things: #28633
After nearly one year into random_compat, we've only just recently received our first complaint about an `Exception` being thrown: https://github.com/paragonie/random_compat/issues/91
(If you note, the resolution was: ""Our host made `/dev/urandom` available to us"".)
== Scott's Proposal ==
Let's transition away from this insecure RNG fallback. Not all at once, of course.
1. Implement a telemetry feature. How many systems will trigger the fallback code in the first place? Is it negligible (i.e. less than 0.0001% of WordPress installs)? Let's call this a 4.5.0 or 4.5.1 feature.
2. If the telemetry identifies *any* systems that cause random_compat to throw an `Exception`, let's identify common points of failure. Are they all from the same webhost? Same operating system?
3. Get in touch with as many of the hosting providers as possible and help them remedy these issues.
4. Finally, once we've done everything we can, remove the fallback code entirely. Let's call this a 4.6.0 or 5.0.0 feature, for the sake of argument.
(Tagging @dd32 since he's my usual point of contact for these discussions.)" sarciszewski
Future Releases 51438 Use CSP directive upgrade-insecure-requests when using HTTPS Security 5.7 normal normal Future Release enhancement new needs-unit-tests 2020-10-02T20:08:07Z 2021-11-09T00:01:22Z "While looking at ways on how to streamline HTTPS support in WordPress core, [https://core.trac.wordpress.org/ticket/47577#comment:4 one suggestion has been to include a `Content-Security-Policy` directive of `upgrade-insecure-requests`] for sites using HTTPS. This directive would ensure that browsers automatically replace (old) insecure requests for inline content (e.g. images) to use HTTPS (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests).
This could be as simple as injecting `` into `wp_head` for sites that use HTTPS (see `wp_is_using_https()` from #47577). Alternatively, since this is mostly beneficial for sites that may still (""accidentally"") have insecure URLs in their content after migrating from HTTP to HTTPS, it might make sense to rely on `wp_should_update_insecure_urls()` from #51437 instead." flixos90
Future Releases 52388 Use HTTPS URL already during installation if supported Security normal normal Future Release enhancement new needs-unit-tests 2021-01-28T03:06:59Z 2021-01-28T03:06:59Z "Following up on #51437, WordPress should try to check already during installation whether the current domain and server can be used over HTTPS. If so, it should suggest to use the HTTPS version of the URL by default.
This was originally brought up by @westonruter in https://core.trac.wordpress.org/ticket/51437#comment:1, but was out of scope for that ticket which focuses on migration from HTTP to HTTPS." flixos90
Untriaged tickets (that need a patch) 34591 "BugFix to WP_Scripts::do_item(), remove doubled ""//""" Script Loader 4.3.1 normal normal Awaiting Review defect (bug) new needs-unit-tests 2015-11-05T11:01:37Z 2017-02-05T09:08:07Z "Current code in `do_item()` of class.wp-script.php on line 172:
{{{
$src = $this->base_url . $src;
}}}
may produce duplicate slashes `""//""`, resulting in problems.
This might be fixed with code:
{{{
$src = $this->base_url . $src;
}}}
Currently:
* WP_Scripts contains: `""public $base_url; // Full URL with trailing slash""` and
* script-loader.php contains calls `$scripts->add()` with initial `""/""` in relative paths
Together this produces doubled slashes `""//""`. For example:
http://www.ocelovehaly.cz/ll//wp-includes/js/jquery/jquery.js?ver=1.11.3
This makes W3TC include script in minified version, but not to remove it from the original HTML.
Including jQuery twice makes LayerSlider not to work.
Please, could you bugfix class.wp-script.php on line 172?
Thank you :-)" jan.mazanek
Untriaged tickets (that need a patch) 54956 "[5.9] wp_block_type args - ""style"" and ""script"" are always loaded on Frontend" Script Loader 5.9 normal normal Awaiting Review defect (bug) new needs-unit-tests 2022-01-27T17:15:29Z 2022-07-19T13:58:22Z "Before 5.9 - `style` and `script` are loaded when the block is added to specific page.
After 5.9 - `style` and `script` are always loaded, on all pages, all the time, everywhere, regardless if the block is displayed on specific page or not.
More info about my use case:
- `style` and `script` both reference a registered script/style, which have multiple dependencies (`wp_register_style` has `$deps` array defined that references more registered styles)
Temporary fix I did to the client code:
- Replacing `style` and `script` with `styles` and `view_script` fixed the issue
However this ""fix"" requires specific WP Core version - 5.8.3 should use `style` and `script`, while 5.9 should use `styles` and `view_script`." pkostadinov
Untriaged tickets (that need a patch) 58075 wp_enqueue_scripts action not firing at the right time with block themes Script Loader 6.2 normal major Awaiting Review defect (bug) new 2023-04-04T05:01:44Z 2023-05-26T09:44:21Z "How to reproduce:
Use this piece of code somewhere in the (child) theme or a plugin
{{{#!php
> This feature only works on the front end, not within the wp-admin area, is this intentional?
>
> It's not. Feel free to add a new ticket to add hooks for the admin." johnbillion
Future Releases 37756 Allow inline scripts on script aliases Script Loader 4.5 normal normal Future Release defect (bug) new needs-unit-tests 2016-08-21T06:46:10Z 2019-12-13T22:21:50Z "It appears if {{{add_inline_script}}} is called on {{{jquery}}} then it gets ignored, and requires to use {{{jquery-core}}}
The same may apply to styles but not tested. Inline scripts should work on both the main script and the aliases.
" pcfreak30
Future Releases 15833 Script concatenation fails to take external dependencies into account. Script Loader 3.0 normal normal Future Release defect (bug) new 2010-12-15T17:35:17Z 2019-05-21T10:42:05Z "Script concatenation places the concatenated script include first, before any scripts loaded separately. If one of the scripts in the concatenation relies on a script outside the concatenation the dependency order is ignored.
When the dependencies are all internal to the concatenation things work fine (for example script4 relies on script3):
* concat=script1,script2,script3,script4,script5
But when script3 is loaded externally, script4 will break:
* concat=script1,script2,script4,script5
* external-script3
This becomes apparent if jQuery is loaded from a non-standard location (via a plugin or the [http://codex.wordpress.org/Function_Reference/wp_enqueue_script#Load_a_default_WordPress_script_from_a_non-default_location code from the Codex]) in that the visual editor fails to function correctly because source:/trunk/wp-admin/js/editor.js uses jQuery (which it fails to register as a dependency, see ticket:15830, but when I fixed that locally the results were the same).
I'm working around this in [http://wordpress.org/extend/plugins/use-google-libraries/ Use Google Libraries] by globally disabling concatenation, but it would be nice if this was fixed.
If possible, it would be nice if the loader was smart enough to do something like:
* concat=script1,script2
* external-script3
* concat=script4,script5
Or at least flagged the script with the dependency as unsafe for concatenation:
* concat=script1,script2,script5
* external-script3
* script4
" jczorkmid
Future Releases 49470 Script loader: simplify maintenance Script Loader 5.0 normal normal Future Release defect (bug) new 2020-02-18T22:11:18Z 2020-07-21T19:03:13Z "The main functionality of script-loader is to provide a list of all WordPress scripts and stylesheets together with their dependencies, translation objects and extra/inline code.
During the WP 5.0 development a few (shorthand) functions were introduced that output hard-coded data used to ""construct"" that list by running several loops instead of the simpler, one-line definitions like in the pre-existing list. This makes it harder to ""see"" and maintain the entries in the list, and doesn't bring any benefits (all data is still hard-coded, but is now in separate places). It also makes it harder to ""dynamically"" extract and construct the scripts list like in #48154.
For best results and easier maintenance the ""helper functions"" introduced in WP 5.0 should be removed and the list of scripts in `wp_default_scripts ()` should include all entries." azaozz
Future Releases 51317 Remove deprecated JavaScript i18n globals Script Loader 5.5.1 normal normal Future Release enhancement new early 2020-09-16T00:35:58Z 2021-05-25T22:55:27Z "Background: #51123
[48923] added backward compatibility for JavaScript i18n globals and properties deprecated in WordPress 5.5.
Per the corresponding [https://make.wordpress.org/core/2020/09/01/deprecated-javascript-globals/ dev note on make/core], the plan is to remove this fallback code in two major versions, so it should be deleted in WordPress 5.7. This gives plugin and theme developers ample time to remove the conflicting code and switch to using `wp.i18n`.
This ticket serves as a reminder to address this in 5.7." SergeyBiryukov
Future Releases 60597 Script Modules API: Allow list of enqueued module data to be exposed Script Loader trunk normal normal 6.6 enhancement new 2024-02-21T23:24:22Z 2024-03-01T12:30:33Z "There's no means for a plugin to fetch a list of registered or enqueued script modules for debugging purposes from the Script Modules API as there is from the existing Scripts Dependencies API.
Most likely the `get_import_map()`, `get_marked_for_enqueue()`, `get_dependencies()`, and `get_versioned_src()` methods of the `WP_Script_Modules` should be made public to facilitate this." johnbillion
Future Releases 26113 Create a WordPress-specific, dependable reference to the WP-bundled jQuery object. Script Loader normal normal defect (bug) new 2013-11-19T16:46:11Z 2019-06-04T21:09:37Z "When enqueueing jQuery for use on the front end of a site in a plugin or theme, a common concern is that the theme or another plugin has injected its own version of jQuery (probably an older version). This causes no end of support headaches for me as a plugin author.
I've recently taken drastic measures in one of my plugins:
I'm hooking in to `wp_enqueue_scripts` at -9999 and starting a buffer, then collecting it at `wp_head` 9999. I'm looking for the WP-included jQuery script tag, and then inserting this immediately after it:
``
Then in my JS, I do:
{{{
;(function (w) {
var jQ = w.jQueryWP || w.jQuery;
// my jQuery code here, using jQ
})(window);
}}}
I think that having a dependable reference to WP's jQuery object would be quite useful. One way to solve it would be to just add the line to our copy of jQuery. But that will cause issues with people who use well-behaved CDN plugins to swap out WP's jQuery for a Google-hosted copy of jQuery (note: THE SAME VERSION). So maybe a better way to do it would be to create a way to append inline JS code immediately after the inclusion of a particular script handle. We could then do what I'm doing in my plugin, but without the nasty PHP output buffers.
" markjaquith
Future Releases 20558 allow wp_localize_script data to be added to existing objects Script Loader 3.3 normal normal enhancement new dev-feedback 2012-04-27T16:44:03Z 2019-06-04T21:07:31Z "Re: WP_Scripts::localize() located in wp-includes/class.wp-scripts.php
Currently when `WP_Scripts::localize()` handles the printing of wp_localize_script data to JavaScript, it starts the string with a `var` declaration, like this:
{{{
$script = ""var $object_name = "" . json_encode($l10n) . ';';
}}}
Because this is printed in the global scope, it becomes a global variable regardless of whether it's preceded by `var`. As far as JavaScript is concerned the above string would be equivalent to:
{{{
$script = $object_name . ' = ' . json_encode($l10n) . ';';
}}}
or
{{{
$script = 'this.' . $object_name . ' = ' . json_encode($l10n) .
';';
}}}
or
{{{
$script = 'window.' . $object_name . ' = ' . json_encode($l10n) .
';';
}}}
But I suppose it's possible thru hooks to make it so that the localization data prints outside of the global scope, in which case you might want the `var` to be there (if it we're wrapped in a closure). So I think the '''overall best solution''' would to check if the `$object_name` contains a period `.` character. If it does, omit the `var`. In other words, make it so that:
{{{
wp_localize_script('myplugin', 'myPluginData', $object )
}}}
would print:
{{{
var myPluginData = {...};
}}}
but that:
{{{
`wp_localize_script('myplugin', 'myPlugin.data', $object )`
}}}
would print:
{{{
myPlugin.data = {...};
}}}
By default the localization data runs before any enqueued scripts, in which case `myPlugin` would not yet be defined, but we should leave that for the JavaScript dev work out. My point is that the flexiblity should be there. Another route would be to apply a filter on that line but I don't think a filter is necessary if the above change is made." ryanve
Untriaged tickets (that need a patch) 50123 Roles & Caps: give anonymous users the `read_post` meta cap for public posts. Role/Capability normal normal Awaiting Review defect (bug) new needs-unit-tests 2020-05-07T23:30:23Z 2024-01-26T07:45:24Z "The meta capability `read_post` is used to determine if a user is permitted to read a post. For public posts (ie, both a public post type and public post status), it returns the `$post_type->cap->read` as the required primitive capability.
As logged out users do not have any primitive capabilities, this causes `current_user_can( 'read_post', $post_id )` to return a false negative for logged out users wishing to read a public post.
**Approach one:**
For public posts the `read_post` meta capability returns an empty array of primitives.
**Approach two:**
Logged out users are given the `$post_type->cap->read` capability for public post types.
**Approach three:**
WP gives logged out users the `read` primitive capability, if a developer uses an alternative primitive for public custom post types, then the developer is responsible for ensuring anonymous users have the capability.
**Notes:**
* ~~Private multisite sites should not allow logged out users to see such posts~~ ''Edit: removed as it's not a core feature of Multisite''
* Many, many unit tests will be required
" peterwilsoncc
Untriaged tickets (that need a patch) 49345 User with admin privileges cannot edit some pages/posts Role/Capability 5.3.2 normal normal Awaiting Review defect (bug) new 2020-02-02T20:05:29Z 2020-02-02T20:05:29Z "It happened to me when I deleted the admin user with ID = 1 and moved all its posts and pages to another user with admin privileges. As soon as I did it, some older pages could not be edited anymore (only seen or deleted).
In order to regain control of those pages, I had to patch wp-includes/capabilities.php as follows:
{{{
function current_user_can( $capability, ...$args ) {
$current_user = wp_get_current_user();
if ( empty( $current_user ) ) {
return false;
}
if ($current_user->has_cap(‘create_users')) return true; // line added
return $current_user->has_cap( $capability, ...$args );
}
}}}
" malamiao
Untriaged tickets (that need a patch) 47338 is_super_admin() should check a different capability Role/Capability normal normal Awaiting Review defect (bug) new 2019-05-21T14:07:18Z 2019-09-23T09:56:35Z "Currently is_super_admin() returns true in case the user has the delete_users cap (in case of a single site).
Since admins may want to delegate users managemente capability, IMHO a more appropriate capability to check is 'activate_plugins' or, better, check more than a single capability." lllor
Untriaged tickets (that need a patch) 43421 The $capabilities argument in the `add_role()` function is incompatible with `user_can` Role/Capability 4.9.4 normal normal Awaiting Review enhancement reopened needs-unit-tests 2018-02-26T17:19:26Z 2018-03-20T17:21:03Z "Reproduce:
Add a role to WP using `add_role()`, and pass it custom capabilities using the third argument. Like:
{{{#!php
add_cap($cap);
}
}}}
And repeat testing, it returns true as expected.
This has to do with how the caps are saved. The first way, when capabilities are retrieved in `WP_User::has_cap()`, they look like this:
{{{#!php
""read"",
[1]=>
""my_cap"",
[""my_new_role""]=>
bool(true)
[""exist""]=>
bool(true)
}
}}}
And when done via `add_cap`, they look like this:
{{{#!php
bool(true)
[""my_cap""]=>
bool(true)
[""my_new_role""]=>
bool(true)
[""exist""]=>
bool(true)
}
}}}
The subsequent `empty` array check is true for the first, and false for the second.
" eclev91
Untriaged tickets (that need a patch) 23391 User in contributor role can add images to post only via the text editor Role/Capability normal normal Awaiting Review enhancement new 2013-02-05T07:34:26Z 2018-10-03T12:18:01Z "1. Create a user with contributor role
2. start new post with it
3. notice there is no ""add media"" button anywhere
4. switch to text editing
5. use the img button to insert a URL to a valid img on the web
6. request approval for the post
7. let admin/editor approve it
8. go the the post's URL and notice that the image is shown
So, it is not that contributors are not allowed to use images, it is just that WP makes it hard to do so.
Either HTML needs to be sanitized and have all img tags removes for contributors, or access to the media library should be allowed for contributors denying only access to uploading. I vote for the second option." mark-k
Future Releases 38997 delete_private_posts capability doesn't prevent user from deleting private posts Role/Capability 4.6.1 normal normal Future Release defect (bug) assigned needs-unit-tests 2016-11-30T21:09:31Z 2019-05-25T14:02:40Z "Attempting to prevent users from deleting a published post works, but if they set a post to 'private' they can delete it even if 'delete_private_posts' capability is set to 0.
{{{#!php
allcaps['delete_published_posts'] = 0;
// doesn't work
$current_user->allcaps['delete_private_posts'] = 0;
}}}
""doesn't work"" means that ""Trash"" link appears on hover over the post in edit.php and ""Move to Trash"" shows up on post.php
" yboris
Future Releases 33240 Introduce a capability for previewing posts Role/Capability normal normal Future Release enhancement assigned needs-unit-tests 2015-08-03T11:36:52Z 2017-07-14T19:41:15Z "In order to preview an unpublished post (ie. draft or pending), a user needs the `edit_posts` capability for that post type ([https://core.trac.wordpress.org/browser/tags/4.2.3/src/wp-includes/capabilities.php#L1174 src]).
There is a valid use case where a site requires a user role which has the capability to preview unpublished posts but not edit them, for example for editorial review/sign-off, layout review, early access, etc.
You can [http://wordpress.stackexchange.com/a/196209/27051 get around this by using a combination of the posts_results and the_posts filters], but this isn't very future-proof because the post results skip a bunch of logic that occurs between those two filters.
A `preview_post` meta capability and a `preview_posts` primitive capability could be introduced and implemented wherever the `edit_posts` capability is used in regard to previewing unpublished posts. By default, it will simply map to the `edit_posts` capability.
Thoughts?" johnbillion
Future Releases 42405 Introduce singular capabilities for enabling individual themes on Multisite Role/Capability normal normal Future Release enhancement new needs-unit-tests 2017-11-01T22:14:24Z 2017-11-01T22:14:24Z "Related: #39083
The ability to enable or disable individual themes for a site from the Network Admin -> Sites -> Edit -> Themes screen should be controlled by singular capabilities.
* `enable_theme`
* `disable_theme`" johnbillion
Future Releases 41701 Introduce singular capabilities for further management of individual plugins Role/Capability normal normal Future Release enhancement new needs-unit-tests 2017-08-22T14:14:11Z 2017-08-22T14:14:28Z "This is a follow-up to #38652 which introduced singular capabilities for activating and deactivating individual plugins.
Singular capabilities should be added for controlling the ability to do the following:
* Edit an individual plugin.
* Delete an individual plugin.
* Update an individual plugin.
Low priority stretch goals which might end up in another follow-up ticket:
* Edit an individual file in a plugin.
* Install an individual new plugin.
* Upload an individual new plugin.
Network activation and deactivation for Multisite will be handled in a separate ticket." johnbillion
Future Releases 41703 Introduce singular capabilities for network activation and deactivation of individual plugins Role/Capability normal normal Future Release enhancement new needs-unit-tests 2017-08-22T14:16:06Z 2020-09-20T12:12:58Z "This is a follow-up to #38652 which introduced singular capabilities for activating and deactivating individual plugins.
Singular capabilities should be added for controlling the ability to network activate and network deactivate individual plugins on Multisite.
See also #41701." johnbillion
Future Releases 39174 Introduce network roles Role/Capability normal normal Future Release feature request new needs-unit-tests 2016-12-08T02:00:45Z 2019-03-15T02:07:55Z "We have been discussing introducing network roles during multisite office-hours several times. The original concept for roles on multisite/multinetwork was the following:
''Site Administrator < Network Administrator (currently also called ""Super Admin"") < Global Administrator < Super Admin (special access via `$super_admins` global, has all capabilities automatically)''
This ticket is about network roles in particular, but we need to figure out the entire concept we'll be going with beforehand.
After the initial discussions which happened several weeks ago, I started playing around with that idea and created a plugin with network roles which is available at https://github.com/felixarntz/wp-network-roles. The details on that plugin are described in this Google doc (and are probably worth reading to understand the following discussion better): https://docs.google.com/document/d/1MWwwKmhBJookr5dEcYga4sBtCwvx-K8uSucBFx6SP9U/edit#
I just had a long conversation with @johnbillion around this topic where we agreed on some ideas, disagreed on others, were entirely unsure about others. The following bullet points sum up what we talked about / which questions we raised.
* The original idea of network roles was that these roles behave similar to regular site roles: They all have a set of capabilities they can perform. These capabilities can apply to either the site or network level. This allows for roles like the current ""Super Admin"" / ""Network Administrator"" that has access to everything a site administrator has, but also to any network admin functionality - however it also allows for roles like a possible ""Network Editor"" which would be the same as if a user had the ""Editor"" role on every site of the network.
* Should we support both of these concepts? Or should network roles only affect the actual network admin area? If the latter, which roles would we even need in Core itself (in addition to the ""Super Admin"" / ""Network Administrator"")? This decision would also affect whether we should support inheritance of network capabilities to site capabilities or whether network roles would just be additional kind of roles for a user. An example to clarify:
* First approach: The ""Super Admin"" / ""Network Administrator"" has all the capabilities a regular site administrator has, plus the network admin area capabilities (like `manage_network` or `manage_network_options`), so they automatically behave as if they were a site administrator on every site in the network.
* Second approach: The ""Super Admin"" / ""Network Administrator"" role only has network admin area capabilities (like `manage_network` or `manage_network_options`), so the user also needs to have the site administrator role for each site they want to access. (probably not?)
* If we support inheritance, can we handle the two kinds of roles together? A ""Network Administrator"" that has access to the network admin area is conceptually a bit different from a ""Network Editor"" who can only access all site admin areas on that network. If we find solid descriptive names, we're probably good here. For example, instead of having a ""Network Administrator"" being the role where one can access the network admin and at the same point be an administrator on all the network's sites, maybe that role should rather be called ""Network Manager"", while ""Network Administrator"" is a different role which basically means that user is an administrator on all the network's sites, but cannot access the network admin area.
* We would certainly need to handle that in a slow migration path: If we introduce a network role system with a predefined set of capabilities in let's say 4.8, we write a dev-note at the same time that tells plugin authors that they now need to add their custom capabilities to the new network role because that role no longer automatically can do anything. At this point however we still keep the current super admin functionality in sync so that the role actually still can do anything. We wait until 2-3 releases later to actually remove the sync thing, which means we get rid of the `site_admin` network option and from that point on use `is_super_admin()` and `get_super_admins()` only to retrieve users specified in the `$super_admins` global.
* Is this the right approach at all? Currently the ""Super Admin"" / ""Network Administrator"" can do ""anything but..."" rather than having a predefined set of capabilities. While we can address that with a migration like described above, we still need to think about whether it ''is'' the right way to do it. Maybe we need a concept like ""Role X can do anything under certain circumstances unless specifically denied"".
* How should we handle Multisite / Multinetwork? Multisite is the ""easy"" thing here - for all of the changes here we need to consider Multinetwork especially, even though it is not really supported by Core at this point.
* What do we think a ""Super Admin"" is? Is that a network administrator with specific capabilities, is it kind of a global administrator or is it a special thing that can do anything, thus not having a predefined set of capabilities? Core itself doesn't really know what a super admin is at this point. In most setups it is a network administrator / network manager as it's stored in a network option. But if you use the `$super_admins` global, it suddenly turns into some kind of a global administrator. Which of the two are we going to stick with for that terminology?
* Can we rename the term ""Super Admin"" at all (in terms of BC)? It would probably become either ""Network Administrator"" or ""Network Manager"" depending on the approach. If we can't rename it and keep the name for the ""network administrator"" role, how are we going to handle the higher role level?
This will likely become a feature project, but this ticket is for more discussion beforehand." flixos90
Future Releases 29594 Basic Cookie Authentication from External Database Role/Capability 4.0 normal normal defect (bug) new 2014-09-09T05:42:46Z 2019-06-04T21:12:21Z "Several bridges (WP plugins) linking different forum software packages rely on the wp_set_auth_cookie($user_id,0,0) to get the user logged into WordPress. With the change in WP 4.0, this single line no longer works. Instead, the user is logged into the site but can no longer publish a post or page, nor update a plugin etc. Whereas the same user would be able to do all those things in 3.9.2 and below.
I've come across this issue for three different bridges.
The change is the addition of the token.
[Suggestion] Maybe there needs to be some instruction in the documents on how WP developers want the external authorization to happen for login plus capabilities to post.
Is this a bug with just the single line (wp_set_auth_cookie) not functioning as intended or do devs expect plugin developers to use other lines of code to get the user logged in .. and authorized to publish, post, etc. ?" LPH2005
Future Releases 27670 Plugin Information tab - inaccesible without install_plugin capability Role/Capability 3.8.1 normal normal defect (bug) new dev-feedback 2014-04-04T14:01:03Z 2019-06-04T21:10:44Z "Hello,
if I understand it correctly through the '''Plugin information tab''' you can also install/update plugins. But if you permit installing plugins with f.e. with add_cap(""install_plugins"", FALSE) to some user, whole '''Plugin information tab''' is '''unusable''' for him, so you cant view details, install update even if you are allowed to.
I suppose the problem is in wp-admin/plugin-install.php where is
{{{
if ( ! current_user_can('install_plugins') )
wp_die(__('You do not have sufficient permissions to install plugins on this site.'));
}}}
so maybe extending the condition above to something like this
{{{
if (( ! current_user_can('install_plugins') ) && plugin_not_installed($plugin_name))
}}}
could help?
Thanks
Jozef Repáň
" FolioVision
Future Releases 14986 Make WordPress roles/capabilities more secure (edit_users related) Role/Capability normal normal enhancement new 2010-09-28T20:39:03Z 2022-12-05T12:09:09Z "We've discussed this before, but after some thought, I think we can do this and make it work.
Right now, the edit_users capability is the key to the kingdom. Anybody with edit_users can change their role to anything, including to something with more capabilities than they already have.
Back in #6908 and #6014, this was thought about in terms of the old user levels system, which of course shouldn't be used and makes no sense.
In #8770, an editable_roles filter was introduced, which allows a plugin to limit the roles that a user can change themselves too. This works for one aspect of the problem, but a) it doesn't solve the passwords problem(1), and b) it assumes that the roles are still only in one chain of command. That is to say, that all the roles have an ordering, where each role has all the capabilities of the role ""below"" it.
To solve these, I think we need a capability comparison system. To wit, code that implements these two rules:
1. No user can change the role of another user to a role that has capabilities that the changing user does not also have.
2. No user can change either the role or the password of another user who has any capability that the changing user does not also have.
For rule 1, this means that if Adam was to try to assign Bob a role, he would only be given the choice of assigning roles that have a subset of the capabilities Adam himself had.
For rule 2, if Adam was to try to change the role or the password of Bob, he would not be able to change either unless Bob already had a subset of Adam's own capabilities.
This makes the roles have a sort of definable hierarchy, where roles with lesser capabilities can be multi-faceted. I can define more than one chain of roles which are ""above"" each other in hierarchy, allowing me to build a tree of groups and users capable of different things.
For things like bbPress-as-a-plugin, this sort of enforcement is going to be a must-have feature.
Note 1: The ""passwords problem"" is that any user who can change another users password can easily change the password of somebody of ""higher"" rank, log in as them, and then have their capabilities. It's detectable, but in some cases, may not be so detectable. Admins who don't log in often, say.
Note 2: We also need role management in core, but that's a topic for a separate day. I'm speaking only of enforcement of a security model here for now." Otto42
Untriaged tickets (that need a patch) 34683 Default .htaccess config creates rewrite infinite loops for path-based multisite installations Rewrite Rules 4.3.1 normal normal Awaiting Review defect (bug) new 2015-11-14T20:16:54Z 2020-03-27T14:11:01Z "Default .htaccess config for path-based multisite installations looks like that:
{{{
RewriteBase /
RewriteRule ^index\.php$ - [L]
# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]
}}}
The problem is in these lines:
{{{
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
}}}
`?` sign makes expression `([_0-9a-zA-Z-]+/)` optional, so rule works also for request like `http://example.com/wp-config/file.png` and basicly try to internal redirect request to the same address. If file does not exist, it creates infinite internal loops that causes internal server errors.
There is no sense create rewrite rules for main site of network and site prefix should no be optional for rewrites. Correct .htaccess content should be:
{{{
RewriteBase /
RewriteRule ^index\.php$ - [L]
# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)(.*\.php)$ $2 [L]
RewriteRule . index.php [L]
}}}
" rob006
Untriaged tickets (that need a patch) 40339 If $home_path=='wp' then WP::parse_request() will remove 'wp' from 'wp-json/wc/v1/products' in $pathinfo Rewrite Rules 4.7.3 normal normal Awaiting Review defect (bug) new 2017-04-02T13:32:06Z 2018-01-12T02:33:28Z "I have installed WordPress in a subdirectory 'wp' so $home_path is 'wp'. The statement
{{{#!php
pathinfo = preg_replace( $home_path_regex, '', $pathinfo );
}}}
is called with arguments
{{{
$home_path_regex = '|^wp|i'
$pathinfo = 'wp-json/wc/v1/products'
}}}
and returns
{{{
$pathinfo = '-json/wc/v1/products'
}}}
Since, $_SERVER[ 'PATH_INFO' ] is the trailing part of the path wouldn't the leading home path be already removed?
Here is the $_SERVER variable:
{{{
$_SERVER=Array
(
[SERVER_SOFTWARE] => PHP 5.6.30 Development Server
[REQUEST_URI] => /wp/wp-json/wc/v1/products
[DOCUMENT_ROOT] => C:\\WWW
[REMOTE_ADDR] => 192.168.1.113
[REMOTE_PORT] => 54207
[SERVER_PROTOCOL] => HTTP/1.1
[SERVER_NAME] => me.local.com
[SERVER_PORT] => 80
[REQUEST_METHOD] => GET
[SCRIPT_NAME] => /wp/index.php
[SCRIPT_FILENAME] => C:\\WWW\\wp\\index.php
[PATH_INFO] => /wp-json/wc/v1/products
[PHP_SELF] => /wp/index.php/wp-json/wc/v1/products
[HTTP_HOST] => me.local.com
[HTTP_CONNECTION] => keep-alive
[HTTP_CACHE_CONTROL] => max-age=0
[HTTP_UPGRADE_INSECURE_REQUESTS] => 1
[HTTP_USER_AGENT] => Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36
[HTTP_ACCEPT] => text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
[HTTP_ACCEPT_ENCODING] => gzip, deflate, sdch
[HTTP_ACCEPT_LANGUAGE] => en-US,en;q=0.8,en-AU;q=0.6
[HTTP_COOKIE] => wp-settings-1=libraryContent%3Dbrowse%26mfold%3Do%26editor%3Dhtml%26posts_list_mode%3Dexcerpt%26widgets_access%3Don%26post_dfw%3Don%26hidetb%3D1; wp-settings-time-1=1489742056; wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_82a92e8b6fd4f1e7bd35e69acfebe645=mc%7C1491295996%7ClSYWOrX5ljiNvjMUuOsdx3Hqd3B4PsyM6sdhaHx3VHB%7C0f85cc8928c44377d339344bd93f970151fb018ad0623b09964e252bc6104127
[REQUEST_TIME_FLOAT] => 1491131923.8711
[REQUEST_TIME] => 1491131923
)
}}}
" Magenta Cuda
Untriaged tickets (that need a patch) 44773 Non Existing Child Page of Custom Post Redirects Instead of 404 Rewrite Rules 4.9.8 normal critical Awaiting Review defect (bug) new dev-feedback 2018-08-10T19:33:17Z 2020-09-11T05:07:03Z "Steps to reproduce:
1. Register Custom Post Type with hierarchical set to true (We'll call it events)
2. Create the following structure in the CPT:
* Test
* Test 2
* Child (Child of Test 2)
3. Go to https://localhost/events/test/child and this will redirect you to https://localhost/events/test-2/child instead of returning a 404.
Extra Step:
If you create a normal page of ""Test"" and try to navigate to https://localhost/test/child, it will redirect to https://localhost/test-2/child.
All this was done on vanilla WordPress on Twenty Seventeen theme.
{{{
function register_my_cpts_events() {
/**
* Post Type: Events.
*/
$labels = array(
""name"" => __( ""Events"", """" ),
""singular_name"" => __( ""Event"", """" ),
);
$args = array(
""label"" => __( ""Events"", """" ),
""labels"" => $labels,
""description"" => ""Event overview and resource pages"",
""public"" => true,
""hierarchical"" => true,
""menu_icon"" => ""dashicons-calendar-alt"",
""supports"" => array( ""title"", ""editor"", ""thumbnail"", ""excerpt"", ""revisions"", ""page-attributes"" ),
);
register_post_type( ""events"", $args );
}
add_action( 'init', 'register_my_cpts_events' );
}}}
" Asitha
Untriaged tickets (that need a patch) 19896 Non-WP rewrites not saved on a multisite install Rewrite Rules 3.0 normal normal Awaiting Review defect (bug) new 2012-01-25T16:14:20Z 2017-08-22T14:29:46Z "The following code adds a rewrite rule which is classed as a non-WP rewrite rule because its redirect doesn't begin with `index.php`, and is stored in the `non_wp_rules` member variable of the `WP_Rewrite` class.
{{{
function my_rewrite() {
add_rewrite_rule( 'login/?$', 'wp-login.php', 'top' );
}
add_action( 'init', 'my_rewrite' );
}}}
On a single site install, this rewrite rule gets saved directly to the .htaccess file rather than being added to WordPress' internal rewrite array.
On a multisite install, this doesn't happen and the rewrite rule has no effect (probably because once a site is multisite-d WordPress no longer writes to .htaccess). The rule has to be manually added to .htaccess.
Likely introduced in 3.0, reproduced in 3.3 and trunk." johnbillion
Untriaged tickets (that need a patch) 50726 Pagination error on 4 digit page when category and year are in the permalink structure Rewrite Rules 5.5 normal minor Awaiting Review defect (bug) new 2020-07-21T17:40:38Z 2020-07-21T17:40:38Z "When looking at a category archive page where the page number has four digits, and the permalink structure has the category and year in it, WordPress lumps together the category name and the ""page"" part of the URL and assumes that the number refers to the year of publication.
Steps to reproduce:
1) Update the permalink structure to /%category%/%year%/%monthnum%/%day%/%postname%/
2) Create a category
3) Create and assign enough posts and/or update posts per page to generate at least 1000 pages.
4) Navigate to page 1000 or greater.
Even though the resulting URL would be /%cat%/page/1000/, WordPress will assume that the category name is ""%cat%/page"" and that the year of publication is 1,000.
The correct behavior is to go to page 1,000 of the specified category, just as it works in page 999.
This issue leads to 404s being generated by the standard pagination component which get flagged on search engine crawls, resulting in lower search rankings for the entire website.
Here is the immediate fix I added to my website:
{{{#!php
is_main_query()
&& is_archive()
&& substr_count($_SERVER['REQUEST_URI'], '/page/')
) {
$year = $query->query_vars['year'] ?? 0;
$page = $query->query_vars['paged'] ?? 0;
if ($year && !$page) {
unset($query->query_vars['year']);
$query->set('paged', $year);
}
if (isset($query->query['category_name'])) {
$query->set('category_name', str_replace('/page', '', $query->query['category_name']));
}
}
});
}}}
" elpadi17
Untriaged tickets (that need a patch) 45970 "in IIS if web.confing section and the site craches with wrong web.config" Rewrite Rules 5.0.3 normal normal Awaiting Review defect (bug) new 2019-01-13T12:12:37Z 2019-01-13T22:34:19Z "in IIS if web.confing section and the site craches with wrong web.config error (2 sections). It happens/triggers by example if you are trying to change the ""Permalink Settings"".
The code responsible for this check is located in \wp-admin\includes\misc.php (line 748)
{{{
// First check if the rule already exists as in that case there is no need to re-add it
$wordpress_rules = $xpath->query('/configuration/system.webServer/rewrite/rules/rule[starts-with(@name,\'wordpress\')] | /configuration/system.webServer/rewrite/rules/rule[starts-with(@name,\'WordPress\')]');
if ( $wordpress_rules->length > 0 )
return true;
}}}
The fix could be to register the namespace:
{{{
$xpath->registerNamespace(""x"", ""http://schemas.microsoft.com/.NetConfiguration/v2.0"");
}}}
and then in `$xpath->query` to check also for `/x:configuration/x:system.webServer/x:rewrite/x:rules/x:rule[starts-with(@name,\'WordPress\')]`
In this way it works without problem and does not break the site." boychev
Untriaged tickets (that need a patch) 19493 post and archive pagination don't work with custom endpoints Rewrite Rules 2.1 normal normal Awaiting Review defect (bug) new 2011-12-09T23:55:09Z 2018-01-25T20:22:02Z "Archive pagination and post pagination are not endpoint-aware, so they break when endpoints are added to them.
The following example code creates an endpoint, and then uses a filter to add that endpoint to various links on the rendered page:
{{{
add_action( 'init', function() {
global $wp_rewrite;
add_rewrite_endpoint( 'foo', EP_ALL );
$wp_rewrite->flush_rules(false);
} );
add_filter( 'post_link', 'gist_add_endpoint_to_url', 99 );
add_filter( 'get_pagenum_link', 'gist_add_endpoint_to_url', 99 );
function gist_add_endpoint_to_url( $url_base ) {
$endpoint = 'foo';
$url_parts = parse_url( $url_base );
$url = ( isset($url_parts['scheme']) && isset($url_parts['host']) ) ? $url_parts['scheme'] . '://' . $url_parts['host'] : '';
$url .= isset($url_parts['path']) ? $url_parts['path'] : '';
$url = user_trailingslashit( $url );
if ( '' === get_option('permalink_structure') ) {
$url .= isset($url_parts['query']) ? '?' . $url_parts['query'] : '';
$url = add_query_arg( $endpoint, 'true', $url );
} else {
$url .= $endpoint . '/true';
$url = user_trailingslashit( $url );
$url .= isset($url_parts['query']) ? '?' . $url_parts['query'] : '';
}
$url .= isset($url_parts['fragment']) ? '#' . $url_parts['fragment'] : '';
return $url;
}
}}}
You'll see that it works perfectly using the theme unit test, except that paginated posts produce URLs like this:
http://example.com/2008/09/layout-test/foo/true/2/
...which doesn't work. The inverse -- http://example.com/2008/09/layout-test/2/foo/true/ -- also doesn't work, and produces a 404 on top of it.
Also, the older posts / newer posts produce this format of link:
http://example.com/page/2/foo/true/
.. .which also doesn't work.
If you change gist_add_endpoint_to_url() to add a querystring param, older posts/newer posts links work fine, but post pagination still breaks:
{{{
function gist_add_endpoint_to_url( $url_base ) {
$endpoint = 'foo';
$url_base = add_query_arg( $endpoint, 'true', $url_base );
return $url_base;
}
}}}
If you don't use a permalink structure at all, it works fine, since the pagination params are passed directly in the URL.
I'm not sure if the fix lies in modifying add_rewrite_endpoint() so that it creates pagination urls in wp_rewrite, or modifying the way _wp_link_page() and get_next_posts_link() work. " mintindeed
Future Releases 20520 Author Page Pagination Broken When Removing /author/ Slug Rewrite Rules 3.3 normal normal defect (bug) new 2012-04-23T04:16:03Z 2019-06-04T21:07:29Z "WP 3.3.1 Multisite
Permalink setup: /author/post-name
- If the request is ""domain.com/authorname"" the authors page pagination link is broken.
- If the request is ""domain.com/author/authorname"" the authors page pagination link works fine." rbaccaro
Future Releases 26885 Path Based Multisite Rewrite rule absolute path without trailing slash Rewrite Rules 3.8 normal normal defect (bug) new 2014-01-20T16:06:31Z 2019-06-04T21:10:12Z "The .htaccess rewrite rules generator output the absolute path to the files, but there is missing a slash at the begining to use it as absolute.
I've seen the same problem at http://wordpress.stackexchange.com/questions/77818/multisite-configuration-fails-with-css-js-files
The solution is to make it relative, or to add a ""/"" at the beggining of the two rewrite rules.
I think the .htaccess code generated can be fixed for future users." skalex
Future Releases 16832 Trouble if the slug of a custom taxonomy is the same as the url of page/post Rewrite Rules 3.1 normal normal defect (bug) new 2011-03-11T11:50:43Z 2019-06-04T21:06:35Z "I got some troubles with the 3.1 version of WordPress concerning the slug of custom taxonomy.
'''An example that work in 3.0.5'''[[BR]]
www.example.com/agency (url of a page)[[BR]]
www.example.com/agency/john-smith (url of a custom type's detail)
Apparently having the same ""folder"" 'agency' only works for one or the other url but not both.
Hope I made myself clear." LucasHantz
Future Releases 20109 Valid htaccess rule causes 404 after upgrade to 3.3.1 Rewrite Rules 3.3.1 normal normal defect (bug) new 2012-02-24T06:26:42Z 2019-06-04T21:07:25Z "On 2/18/2012, I upgraded WP from 3.2.1 to 3.3.1. on www.denverhomevalue.com. I later noticed that Google webmaster tools started reporting 404 errors on lots of pages that were fine before. WP was still returning the proper pages and content, not my custom 404 page, so the issue was not readily apparent except in WMT reports. Running http header response checkers confirmed 404 responses, despite good contents being returned.
Deleting sections of the htaccess file until the problem went away, the issue was isolated to two rules meant to escape following rewrite rules on certain urls:
{{{
RewriteRule ^city(.*) - [L]
RewriteRule ^areas(.*) - [L]
}}}
These were the same family of urls that started returning 404s after 3.3.1 upgrade. These rules were in place since 12/5/2011, with WP 3.2.1 and never caused a problem.
I was able to revert a backup of the site to 3.2.1, on the same exact server environment, and confirm that these same valid htaccess rewrite rules were not a problem in that release." ronnieg
Future Releases 35916 WP_Rewrite::generate_rewrite_rules() ignores boolean $endpoints / $feed parameters for CPT Rewrite Rules normal normal defect (bug) new needs-unit-tests 2016-02-23T08:34:12Z 2019-06-04T21:20:24Z "Hello,
I'm trying to declare custom rewrite rules for a custom post type without endpoints and feeds.
As result, WP ignore the endpoint flag in the WP_Rewrite::generate_rewrite_rules().
What I did is as following.
I created a custom post type called 'event' with the following arguments for register_post_type() :
{{{#!php
array( // Array of WP post type args
'labels' => array(
'name' => 'Events',
'singular_name' => 'Event',
),
'public' => true,
'publicly_queryable' => true,
'show_ui' => true,
'show_in_menu' => true,
'query_var' => false,
'rewrite' => false,
'capability_type' => 'post',
'hierarchical' => false,
'menu_position' => 5,
'menu_icon' => 'dashicons-tickets-alt',
'supports' => array(
'title',
'editor',
'thumbnail',
),
'taxonomies' => array(
'post_tag',
'my_category',
),
);
}}}
Then I called
{{{#!php
$args_post_type = array(
'feed' => false,
'paged' => false,
'ep_mask' => EP_NONE,
'endpoints' => false,
);
add_permastruct('events', 'events/%event%', $args_post_type);
}}}
The resultings rewrite rules are :
{{{
'events/[^/]+/attachment/([^/]+)/?$' => string 'index.php?attachment=$matches[1]' (length=32)
'events/[^/]+/attachment/([^/]+)/trackback/?$' => string 'index.php?attachment=$matches[1]&tb=1' (length=37)
'events/[^/]+/attachment/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$' => string 'index.php?attachment=$matches[1]&feed=$matches[2]' (length=49)
'events/[^/]+/attachment/([^/]+)/(feed|rdf|rss|rss2|atom)/?$' => string 'index.php?attachment=$matches[1]&feed=$matches[2]' (length=49)
'events/[^/]+/attachment/([^/]+)/comment-page-([0-9]{1,})/?$' => string 'index.php?attachment=$matches[1]&cpage=$matches[2]' (length=50)
'events/[^/]+/attachment/([^/]+)/embed/?$' => string 'index.php?attachment=$matches[1]&embed=true' (length=43)
'events/([^/]+)/embed/?$' => string 'index.php?event=$matches[1]&embed=true' (length=38)
'events/([^/]+)/trackback/?$' => string 'index.php?event=$matches[1]&tb=1' (length=32)
'events/([^/]+)(?:/([0-9]+))?/?$' => string 'index.php?event=$matches[1]&page=$matches[2]' (length=44)
'events/[^/]+/([^/]+)/?$' => string 'index.php?attachment=$matches[1]' (length=32)
'events/[^/]+/([^/]+)/trackback/?$' => string 'index.php?attachment=$matches[1]&tb=1' (length=37)
'events/[^/]+/([^/]+)/feed/(feed|rdf|rss|rss2|atom)/?$' => string 'index.php?attachment=$matches[1]&feed=$matches[2]' (length=49)
'events/[^/]+/([^/]+)/(feed|rdf|rss|rss2|atom)/?$' => string 'index.php?attachment=$matches[1]&feed=$matches[2]' (length=49)
'events/[^/]+/([^/]+)/comment-page-([0-9]{1,})/?$' => string 'index.php?attachment=$matches[1]&cpage=$matches[2]' (length=50)
'events/[^/]+/([^/]+)/embed/?$' => string 'index.php?attachment=$matches[1]&embed=true' (length=43)
}}}
Looking at class-wp-rewrite.php, I noticed in generate_rewrite_rules() that piece of code that forces the $post flag for CTP
{{{#!php
if ( ! $post ) {
// For custom post types, we need to add on endpoints as well.
foreach ( get_post_types( array('_builtin' => false ) ) as $ptype ) {
if ( strpos($struct, ""%$ptype%"") !== false ) {
$post = true;
// This is for page style attachment URLs.
$page = is_post_type_hierarchical( $ptype );
break;
}
}
}
}}}
and that piece of code that unconditionnaly add extra endpoints / feeds... for post
{{{#!php
// If we're matching a permalink, add those extras (attachments etc) on.
if ( $post ) {
// Add trackback.
$rewrite = array_merge(array($trackbackmatch => $trackbackquery), $rewrite);
}}}
Could confirm that problem?
Thanks" solo14000
Future Releases 27276 wp_rewrite_rule does not update option when it's empty Rewrite Rules 3.7 normal normal defect (bug) new 2014-03-05T09:18:38Z 2019-06-04T21:10:32Z "This bug report about possible problems with situation when deleted options still present in cache. I'm using memcache so my cache is transistient.
i've been adding rewrite_rule
{{{
function duke_add_endpoints() {
add_rewrite_rule('...','...');
global $wp_rewrite;
$wp_rewrite->flush_rules();
}
add_action( 'init', 'duke_add_endpoints');
}}}
and discovered that i can't get it work because of it completely absence in further $wp_rewrite references.
Intrigued by that fact (especialy with hard flushing) i've been lead to ''parse_request''of class-wp and due to it's
{{{
$rewrite = $wp_rewrite->wp_rewrite_rules();
}}}
i guided to '''wp_rewrite_rules''' method of wp-includes/rewrite.php where discovered that rewrite_rules option is loaded from wp_options but if it's not there - it loaded from cache (bacause of get_option behaviour).
{{{
$alloptions = wp_load_alloptions();
if ( isset( $alloptions[$option] ) ) {
$value = $alloptions[$option];
} else {
$value = wp_cache_get( $option, 'options' );
if ( false === $value ) {
$row = $wpdb->get_row(....
}}}
Wondering why it was not overriden by flush_rules both in wp_options and in cache i've dig into '''flush_rules''' and discovered that it operates the same method
{{{
function flush_rules($hard = true) {
delete_option('rewrite_rules');
$this->wp_rewrite_rules();
.......
}}}
but wait... IF THE REWRITE_RULES IS NOT IN THE WP_OPTION then it still taken from cache with previous value.
{{{
function wp_rewrite_rules() {
$this->rules = get_option('rewrite_rules');
///at this point the value already deleted from table but still remains in cache so get_option returns OLD value till it remain in cache for indefinite time
if ( empty($this->rules) ) {
$this->matches = 'matches';
$this->rewrite_rules();
update_option('rewrite_rules', $this->rules);
}
return $this->rules;
}
}}}
so if your rewrite rules not in table but in cache - they probably stuck there forever till cache gets cleared. i guess it has something to infere with delete_option and situation when cache is not cleared. but i guess it's next bug to catch.
" mainpart
Future Releases 21374 Add core support for letting custom permalink structure for different post types Rewrite Rules 2.9 normal normal enhancement new 2012-07-25T14:42:15Z 2019-06-04T21:07:39Z "By default, custom post types uses only the'' %postname%'' permalink structure (if using pretty links and not default query variables).
Currently there is no native way to easily have different permastructs for different CPT.
This features should be added to the '''register_post_type()''' function, letting different permalink structure be defined to each post_type being registered.
I sugget adding another new key to the '''rewrite''' array that can be passed to the '''register_post_type()''' function.
i.e. -
{{{
register_post_type('event',array(
......
'rewrite' => array('slug' => 'events',
'permastruct' => '%year%/%monthnum%/%event%'
),
.....
));
}}}
The register_post_type function should be changed, a suggestion for such a change may be that instead of this line in the function - (post.php line#1075)
{{{
add_permastruct( $post_type, ""{$args->rewrite['slug']}/%$post_type%"", $args->rewrite );
}}}
This example could be used -
{{{
if ( $args->rewrite['permastruct'] ) {
$perma_structure = $args->rewrite['permastruct'];
$wp_rewrite->add_rewrite_tag(""%{$post_type}%"", '([^/]+)', ""{$post_type}="");
$wp_rewrite->add_permastruct($post_type, $archive_slug.'/'.$perma_structure, false);
}
else {
add_permastruct( $post_type, ""{$args->rewrite['slug']}/%$post_type%"", $args->rewrite );
}
}}}
In order that the structure can interpret the permastruct tags, I added also this function to filter post_type_link, it is adapted from '''get_permalink''' function in ''wp-includes/link-template.php'' -
{{{
add_filter('post_type_link', 'tc_permalink', 10, 3);
function tc_permalink($permalink, $post_id, $leavename) {
$post = get_post($post_id);
$rewritecode = array(
'%year%',
'%monthnum%',
'%day%',
'%hour%',
'%minute%',
'%second%',
$leavename? '' : '%postname%',
'%post_id%',
'%category%',
'%author%',
$leavename? '' : '%pagename%',
);
if ( '' != $permalink && !in_array($post->post_status, array('draft', 'pending', 'auto-draft')) ) {
$unixtime = strtotime($post->post_date);
$category = '';
if ( strpos($permalink, '%category%') !== false ) {
$cats = get_the_category($post->ID);
if ( $cats ) {
usort($cats, '_usort_terms_by_ID'); // order by ID
$category = $cats[0]->slug;
if ( $parent = $cats[0]->parent )
$category = get_category_parents($parent, false, '/', true) . $category;
}
// show default category in permalinks, without
// having to assign it explicitly
if ( empty($category) ) {
$default_category = get_category( get_option( 'default_category' ) );
$category = is_wp_error( $default_category ) ? '' : $default_category->slug;
}
}
$author = '';
if ( strpos($permalink, '%author%') !== false ) {
$authordata = get_userdata($post->post_author);
$author = $authordata->user_nicename;
}
$date = explode("" "",date('Y m d H i s', $unixtime));
$rewritereplace =
array(
$date[0],
$date[1],
$date[2],
$date[3],
$date[4],
$date[5],
$post->post_name,
$post->ID,
$category,
$author,
$post->post_name,
);
$permalink = str_replace($rewritecode, $rewritereplace, $permalink);
} else { // if they're not using the fancy permalink option
}
return $permalink;
}
}}}
On a basic check this seems to be working, but ofcourse needed to be more deubgged.. I will be happy to here if you think such a feature should be added to core." maorb
Future Releases 24853 Add endpoint support to CPT archives Rewrite Rules normal normal enhancement new 2013-07-28T19:25:06Z 2019-06-04T21:08:52Z #16303 aimed to introduce an endpoint mask for CPT archives. However, the way that CPT rewrite rules are set up means that there isn't actually support for endpoints. duck_
Untriaged tickets (that need a patch) 27244 'Restore This Autosave' immediately updates a published post Revisions normal normal Awaiting Review defect (bug) new 2014-02-28T23:43:29Z 2024-02-25T19:29:55Z "The ""Restore This Autosave"" button on the revisions screen immediately replaces the post with the autosave without making it clear that that is the case.
Steps to reproduce:
1. Publish a post.
2. Edit the content of the post and trigger an autosave (either by waiting two minutes or by clicking the 'Preview Changes' button).
3. Navigate away from the post editing screen.
4. Return to the post editing screen and note the message stating ""There is an autosave of this post that is more recent than the version below"". Click ""View the autosave"".
5. On the revisions screen, click ""Restore This Autosave"".
6. Note that the autosave has been published rather than simply being restored to the editing screen." johnbillion
Untriaged tickets (that need a patch) 53417 The revisions endpoints provide an incorrect JSON schema Revisions 4.7 normal normal Awaiting Review defect (bug) new 2021-06-15T23:20:51Z 2021-06-15T23:29:55Z "The schema provided by the REST API endpoints for revisions at `wp/v2/posts/{id}/revisions` and `wp/v2/pages/{id}/revisions` is incorrect. The schema states that `content.protected` and `excerpt.protected` properties exist for each revision, but these properties do not exist.
* [https://github.com/WordPress/wordpress-develop/blob/afee26086fea307c2a5c31c0e2018cb6acd598f7/src/wp-includes/rest-api/endpoints/class-wp-rest-revisions-controller.php#L736 The schema is constructed here] from the parent controller for posts, which does include this property
* [https://github.com/WordPress/wordpress-develop/blob/afee26086fea307c2a5c31c0e2018cb6acd598f7/src/wp-includes/rest-api/endpoints/class-wp-rest-revisions-controller.php#L600-L604 When the content data is prepared here] the `protected` property is not included
* [https://github.com/WordPress/wordpress-develop/blob/afee26086fea307c2a5c31c0e2018cb6acd598f7/src/wp-includes/rest-api/endpoints/class-wp-rest-revisions-controller.php#L608-L611 When the excerpt data is prepared here] the `protected` property is not included
Two options:
1. Remove the `content.protected` and `excerpt.protected` properties from the schema
2. Add the `content.protected` and `excerpt.protected` properties to the response
Here is the `content` property from the schema. Note the `protected.context` property states that the property exists for all three contexts.
{{{
""content"": {
""description"": ""The content for the post."",
""type"": ""object"",
""context"": [
""view"",
""edit""
],
""properties"": {
""raw"": {
""description"": ""Content for the post, as it exists in the database."",
""type"": ""string"",
""context"": [
""edit""
]
},
""rendered"": {
""description"": ""HTML content for the post, transformed for display."",
""type"": ""string"",
""context"": [
""view"",
""edit""
],
""readonly"": true
},
""block_version"": {
""description"": ""Version of the content block format used by the post."",
""type"": ""integer"",
""context"": [
""edit""
],
""readonly"": true
},
""protected"": {
""description"": ""Whether the content is protected with a password."",
""type"": ""boolean"",
""context"": [
""view"",
""edit"",
""embed""
],
""readonly"": true
}
}
},
}}}" johnbillion
Untriaged tickets (that need a patch) 47518 Add an explanatory message to the Revisions screen for locked posts adamsilverstein Revisions normal normal Awaiting Review enhancement assigned 2019-06-10T15:30:43Z 2021-04-30T17:44:27Z "It's possible for a user to navigate to the revisions screen for a post that's locked due to another user editing it, and not be able to restore any revisions due to the fact that the post is locked. In this situation no message is shown on the Revisions screen that explains why the `Restore This Revision` button is disabled.
Under normal operating procedure it's not easy to get to the Revisions screen for a locked post, but it is possible. A workflow related plugin, audit trail, or revisions list can make it possible to navigate directly to a revision without going via the otherwise locked editing screen.
1. User A navigates to the revisions screen for a non-locked post.
2. User B visits the editing screen for the post.
3. User A clicks `Return to editor` on the revisions screen.
4. User A chooses not to take over, and clicks `Go back`.
User A is now shown the revisions screen for a locked post and the `Restore This Revision` button is disabled for all revisions but with no explanatory information." johnbillion
Untriaged tickets (that need a patch) 42086 Option to view condensed diffs for post revisions Revisions normal normal Awaiting Review feature request new 2017-10-04T16:08:37Z 2020-09-01T16:16:59Z "Viewing a revision of a post which has a lot of content in it can result in a very long screen. It would be great if there was a toggle somewhere on the revisions browser so a condensed diff view was shown.
The condensed view would more closely resemble a traditional VCS diff view, which highlights only the changed lines and a handful of lines above and below each change.
I haven't checked to see if the `Text_Diff` library that core uses supports such diff generation, I doubt it does but I'd like to be wrong." johnbillion
Untriaged tickets (that need a patch) 53942 Non-single post meta multiple value update breaks post save through REST API REST API 5.8 normal blocker Awaiting Review defect (bug) assigned 2021-08-17T13:00:31Z 2021-08-17T15:21:25Z "This is a follow-up to #52787.
Same situation as in #52787, but this time while updating **non-single** meta **multiple values at once** like `{ meta: { metaKey: [1, 2, 3] } }`, REST API fires `update_multi_meta_value()`, which tries first to delete old values in the database. When no meta value is present in database, `get_metadata()` returns defaults as `$current_values` and then trying to delete them anyway (non-existent in fact). This causes `update_multi_meta_value()` to return `WP_Error('rest_meta_database_error')` on `delete_metadata()` failure.
BTW, error messages could be more specific from `'Could not update the meta value of %s in database.'` to `'Could not update/delete...'` and `'Could not update/add...'`." iknowsomething
Untriaged tickets (that need a patch) 53622 Query Param status default is a string value, but an array is required rachelbaker* REST API normal minor Awaiting Review defect (bug) accepted needs-unit-tests 2021-07-07T17:24:41Z 2023-02-20T21:33:06Z "The default value in the collection params that is a string. https://github.com/WordPress/wordpress-develop/blob/953e1c5f8313a89d4d3b99ab5996b4660045c976/src/wp-includes/rest-api/endpoints/class-wp-rest-posts-controller.php#L2847
Really, we should make that `['publish']`.
Original commit: https://github.com/WordPress/wordpress-develop/commit/ede099a7047a150a37d43a380e661b99387bce41" austyfrosty
Untriaged tickets (that need a patch) 56668 REST API calls are failed when cookies are cleared from the site REST API 6.0.2 normal normal Awaiting Review defect (bug) new 2022-09-27T14:46:34Z 2022-09-27T14:46:34Z "Hi,
REST API calls are failed when the site cookies are cleared from browser console. Manually logging out and Logging in again will fix the issue but WordPress should automatically prompt for login in such cases right ? Please Ignore if I am wrong.
Response from API:
{{{
{""code"":""rest_cookie_invalid_nonce"",""message"":""Cookie check failed"",""data"":{""status"":403}}
}}}
" sarathgp
Untriaged tickets (that need a patch) 59558 not documented information about changes in embedded data REST API normal normal Awaiting Review defect (bug) new 2023-10-06T11:17:40Z 2023-10-06T14:14:21Z Hello. In latest wordpress become changes,after which embedded data not works properly if in request we havent any fields. I mean rest api issue see #59552 for details. I expected to see this information with detailed examples at https://developer.wordpress.org/rest-api/using-the-rest-api/linking-and-embedding/#embedding or/and at https://developer.wordpress.org/rest-api/using-the-rest-api/global-parameters/#_embed. Please not ignore my issue #59552, because i not understand how to fix this issue. Thanks. sashakozlovskiy
Untriaged tickets (that need a patch) 54293 Expand functionality of themes REST API REST API 4.7 normal normal Awaiting Review enhancement new needs-unit-tests 2021-10-20T09:30:08Z 2022-06-07T11:59:12Z "Current the REST API for themes is extremely limited. It only allows for listing themes and getting the current theme. However, there are lots theme related functions that are not possible to access via this api. This includes ( but it not limited to )
- Installing new themes
- Network activating theme ( multisite only )
- Network deactivating theme ( multisite only )
- Active ( switch to theme )
- Deleting theme
Any themes api should allow the patterns / structure of the plugins REST API, in it's params and responses.
It is also worth noting, that have a multisite element, as themes can be network activated / deactivated." spacedmonkey
Untriaged tickets (that need a patch) 44694 Extra and un-neccessary query when no posts found in Posts Rest Controller REST API 4.9.7 normal normal Awaiting Review enhancement new 2018-08-01T16:46:27Z 2018-08-02T06:15:21Z "In the 'get_items' method in class-wp-rest-posts-controller.php there is some conditional logic that re-executes the query without the 'paged' param if no results are found ( line 317 ).
This seems like poor logic here. The query should only be executed again IF a paged parameter has been specified in the params.
I have a REST request that returns an empty array, but the query is run twice even though the results are the same.
This leads to some errors for me because I'm supplying non-standard parameters and using one time filters to handle them when building the request. After the initial query my filters have been removed so when the query executes again ( un-neccessarily ) my objects in the params end up triggering notices / warnings in the WP_Query class.
Long story short, this extra query should have better logic protecting it.
Something as simple as:
{{{#!php
1 ) {
// Out-of-bounds, run the query again without LIMIT for total count.
unset( $query_args['paged'] );
$count_query = new WP_Query();
$count_query->query( $query_args );
$total_posts = $count_query->found_posts;
}
}}}
" pat@…
Untriaged tickets (that need a patch) 60426 Update WP_Test_REST_TestCase::assertErrorResponse() to allow custom failure messages REST API normal trivial Awaiting Review enhancement new 2024-02-02T12:21:08Z 2024-02-23T13:31:59Z "According to the WordPress coding standards, it is recommended that if there are more than 2 assertions in a single test method, these assertions should include custom failure messages to explain the nature of any failed assertions.
However, in the current state of the `WP_Test_REST_TestCase::assertErrorResponse()` helper method, it contains 2 assertions, making it impossible to add a custom message explaining the error.
To align with coding standards and improve the clarity of test failures, I propose updating the method's signature as follows:
{{{
protected function assertErrorResponse($code, $response, $status = null, $failure_message)
}}}
This change will allow developers to include a custom message when using the `WP_Test_REST_TestCase::assertErrorResponse()` method, improving the ability to diagnose issues during testing.
Furthermore, all the instances where this method is being used across the codebase need to be refactored to include the new `$failure_message` parameter, ensuring consistency." antonvlasenko
Untriaged tickets (that need a patch) 58034 Post API can't get image URL on Endpoint REST API 6.2 normal normal Awaiting Review feature request new dev-feedback 2023-03-31T11:05:42Z 2023-04-06T10:09:15Z "We need to add the featured image URL to the endpoint of the POST API
Instead of getting the featured_media id, we should get the attachment URL, which will be better for everyone" nodeweb
Future Releases 52925 Autosaves controller: Post checks will never catch invalid IDs REST API 5.8 normal normal Future Release defect (bug) new needs-unit-tests 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 57048 Handle trailing slashes in rest_preload_api_request REST API 4.7 normal normal Future Release defect (bug) new 2022-11-09T16:36:35Z 2022-11-09T16:36:35Z When passing a path to `rest_preload_api_request` that ends in query string, ensure that the parsed path also is untrailingslashit. Follow up to #51636 spacedmonkey
Future Releases 39889 Improve/Fix REST Response on Multisite when an endpoint for a non-existent site is hit. REST API 4.7 normal normal Future Release defect (bug) new needs-unit-tests 2017-02-16T15:52:54Z 2019-07-09T18:42:18Z "Currently if you hit the endpoint for a domain on a site that doesn't exist it will behave the same as on a normal request.
- visit https://nonexistentsubdomain.eventsmart.com/wp-json in a REST client.
- Take note of the ""Location"" header in the response: https://eventsmart.com/wp-signup.php?new=nonexistentsite. It's also returned with a HTTP 302
Granted this is kind of edgecase, but I think it'd be better to handle things a bit better on REST requests. The question is how? I think from the standpoint of the REST client it'd be better to just return a 404 and a ""site doesnt' exist"" message (or something to that affect)." nerrad
Future Releases 48257 REST API: post-process endpoint cannot be discovered from media creation endpoint REST API 5.3 normal normal Future Release defect (bug) new 2019-10-08T14:24:14Z 2019-10-08T14:24:14Z "Split out from #47987:
In #47987 we introduced a new `/wp/v2/media/{id}/post-process` endpoint, which may be hit with a POST to resume media processing in the event the initial POST to `/wp/v2/media` fails. Clients may know to utilize this new endpoint through the presence of a new non-standard header `X-WP-Upload-Attachment-ID`, but @rmccue caught that we do not provide any Link-based method of discovering the existence of this endpoint from the initial media collection. @TimothyBlynJacobs proposes using the `edit-media` relation for this link.
We should add an additional `Link` to the header of the failing POST response (or any POST response, potentially, with the understanding a link is only necessary in the event of failure). Implementing this Link was punted from 5.3 because the `$response` object on which we can call add_link was not available at the time we set the initial X-header, which we can work around but did not have time to resolve before the final 5.3 beta.
''Aside:'' If we're able to resolve the order-of-operations issue, it's possible that the Link could become the preferred method of signalling that post-processing should occur, rather than the non-standard header. However the X-header is more appropriate for the other media paths in `media.php` and `admin-ajax.php`, so this may not be feasible." kadamwhite
Future Releases 40410 Add chunked upload support to the REST API REST API 4.7 normal normal Future Release enhancement new 2017-04-11T05:57:29Z 2021-03-03T17:22:09Z "Split from #39553. Having support for chunked (partial) uploads would be super useful, and provide additional functionality not possible with the current upload API. This would be built off the existing upload endpoints.
This needs a detailed proposal." rmccue
Future Releases 58849 Document supported $args for register_rest_route() REST API normal normal Future Release enhancement new 2023-07-19T11:53:01Z 2023-07-19T17:00:04Z "`$args` seems awfully sparse for how important it is:
[[Image(https://github.com/WordPress/gutenberg/assets/36432/3d6f6ef2-3e15-4c0a-9bb9-9c3b4822c118)]]
It would be nice if all of the supported values were documented." danielbachhuber
Future Releases 53603 Expose block data directly through REST API endpoints REST API 5.8 normal normal Future Release enhancement new dev-feedback 2021-07-06T10:05:57Z 2021-08-01T11:53:50Z "Part of ""PHP APIs Overview"" in Gutenberg: https://github.com/WordPress/gutenberg/issues/8352.
Originally reported in https://github.com/WordPress/gutenberg/issues/4763 by @adamsilverstein.
> Consider adding Gutenberg block data to the post endpoints - so when retrieving a post via the REST API you could get the block data as part of the content object.
>
> This provides a way to get the data/content of each block of a Gutenberg-built page from the front end. This would be very useful for building component based front ends, because the components could map one-to-one with gutenberg blocks. With these endpoints, an App could easily get the data it needs to render each component. This might also provide a patch for a standard component library matching Gutenberg blocks.
>
> POC PR for this: https://github.com/WordPress/gutenberg/pull/2649
Related ticket with changes proposed to `get_posts` function: #53602." gziolo
Future Releases 47194 Posts endpoint: Enable collection parameters for querying by custom field REST API 4.7 normal normal Future Release enhancement new 2019-05-08T20:40:35Z 2020-10-25T03:29:27Z "Before the REST API was merged into Core, meta queries were possible via a filter parameter:
{{{
posts?filter[meta_key]=foo&filter[meta_value]=bar
}}}
This was [ticket:38378 removed] when the API was merged. In a [https://wordpress.slack.com/archives/C02RQC26G/p1557261445107000 recent Slack discussion] @kadamwhite mentioned this was due to the potential for very expensive DB queries, but that improvements to meta registration in subsequent versions of WP may have made this more possible.
There are abundant use cases for being able to query posts via the API based on postmeta values, but I haven't been able to find any other Trac tickets about this. So I'm asking the question: would this be feasible now?" coreymckrill
Future Releases 45140 REST API: Increase upper bound allowed on per_page argument REST API normal normal Future Release enhancement new needs-unit-tests 2018-10-21T17:16:19Z 2018-10-31T11:38:29Z "In contexts where a REST API client needs to fetch ''all'' entries for a resource, it would be more practical to fetch entries in sets of 200, 300, or 400, instead of sets of 100. Fetching entries in sets of 100 can cause excessive memory usage because WordPress is loaded over and over again. Increasing the limit will provide a better balance between memory consumption in a single request vs. total memory consumption across all requests.
The original `per_page=100` limit was [https://github.com/WP-API/WP-API/issues/1609#issuecomment-177169125 somewhat arbitrary]; if I recall correctly, we picked `100` as a nice round number that was reasonably certain not to cause performance issues.
Before we pick `per_page=200` vs. `per_page=300` vs. `per_page=400`, we should:
1. Profile memory consumption of each.
2. Identify what amount of memory we can reasonably expect on shared hosting these days.
After we've done this, we can pick the best available option.
Notably, we can't go above `500` as we'll hit `split_the_query` which has negative performance implications.
Previously https://github.com/WordPress/gutenberg/issues/6694" danielbachhuber
Future Releases 49330 REST API: introduce block-editor context REST API 5.4 normal normal Future Release enhancement new 2020-01-30T16:48:59Z 2020-10-01T17:53:05Z "The block editor does not make use of rendered content, and rendering content for complex posts with a large quantity of dynamic blocks can take a non-trivial amount of time. The REST API maintainers and Gutenberg developers have previously discussed the need to be able to ""skip"" rendering of the content if it is not required.
In [46184] we introduced the ability to provide an explicit list of nested fields to include. Specifying `_fields=content.raw` without mentioning `rendered` now causes the posts controller to skip computation of the rendered field, as it has not been requested. Unfortunately, this approach requires a developer to provide a comprehensive list of all fields they _do_ wish to include in the response, and cannot easily be used to specifically exclude one field. Because block editor developers may depend on registered rest fields or other additional properties, it is infeasible to have the block editor request ""all but the rendered content"" using this interface.
A slack conversation ([https://wordpress.slack.com/archives/C02RQC26G/p1574361923322500]) with @aduth and @timothyblynjacobs addressed this problem and discussed two separate options, either providing an `_omit_fields` parameter to complement `_fields` and permit specific exclusions, or alternatively to introduce a new `block-editor` context that does everything that `edit` does except render content.
This trac ticket is intended to move that discussion forward and aim towards introducing a solution that can be used to speed up response times within the block editor." kadamwhite
Untriaged tickets (that need a patch) 29821 bulk_edit_custom_box hook causes tags to display within created fieldset Quick/Bulk Edit 4.0 normal normal Awaiting Review defect (bug) new 2014-10-01T23:04:40Z 2023-02-07T18:53:00Z "I have a custom post type that I am trying to add some fields to for bulk editing. My fieldset displays, but the tags field somehow is getting inserted into the fieldset being generated. It's extremely strange.
Bulk Edit panel without my fieldset:
[[Image(https://www.dropbox.com/s/fg3tcowz25rdqu1/Screenshot%202014-10-01%2018.53.56.png?dl=1)]]
Bulk Edit panel with my fieldset:
[[Image(https://www.dropbox.com/s/mlb4zr6mbvkbnmq/Screenshot%202014-10-01%2018.54.38.png?dl=1)]]
My code to generate the bulk edit custom box:
{{{
/**
* Display the custom bulk edit box
*
* @since 3.0
* @access public
* @action bulk_edit_custom_box
*/
public function bulk_edit_custom_box( $column_name, $post_type ) {
if ( $post_type != MP_Product::get_post_type() || $column_name != 'product_price' ) {
return;
}
?>
}}}
Notice how the tags field is being inserted into my fieldset. It seems as thought the tags field is being inserted via javascript into whatever the last fieldset in the panel is.
Here's the same fields in the quick edit panel:
[[Image(https://www.dropbox.com/s/haju5pkzu4f80ih/Screenshot%202014-10-01%2019.02.36.png?dl=1)]]
This is how it ''should'' show up." webgeekconsulting
Untriaged tickets (that need a patch) 42164 Conditional Tags not working when using ugly URL Query 4.8.2 normal normal Awaiting Review defect (bug) new needs-unit-tests 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
Untriaged tickets (that need a patch) 54853 Search only searching phrases and not searching individual terms Query 5.8.3 normal normal Awaiting Review defect (bug) new 2022-01-19T03:00:51Z 2022-01-19T07:46:09Z "
{{{
get_posts(array(
""post_type"" => ""fruit"",
""s"" => ""apple orange banana""
));
}}}
should search for each term separately, but it does not. It searches the entire string as a phrase.
Issue is within /wp-includes/class-wp-query.php line 1398. It's a simple change:
{{{
$searchand = ' AND ';
to
$searchand = ' OR ';
}}}
" jchang
Untriaged tickets (that need a patch) 56992 The Loop displays incorrect data for queries started with `fields => 'id=>parent'`. Query 3.1 normal normal Awaiting Review defect (bug) new needs-unit-tests 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
Untriaged tickets (that need a patch) 52971 WP_Query's meta_query With Multiple EXISTS keys and OR Relation Doesn't Work Properly Query 5.7 normal critical Awaiting Review defect (bug) new 2021-04-05T12:31:53Z 2021-04-05T12:31:53Z "Hi There!
Another Very Weird Issue :)
Using WP_Query's [meta_query] with **OR relation** and Multiple **EXISTS Keys** generates a very long unnecessary inner joins relation and **stuck in an infinite loop** and **consume the MySQL resources** with high load.
I'm trying to get all post IDs that have one of 50 meta keys to replace with new keys, So I collect all meta keys using foreach statement with **OR relation** and pass it to the [meta_query] in WP_Query .. Very simple but I noticed that there's no result and infinite page load and using high resources of MySQL.
I create the SQL statement with $wpdb and it works very fast, So I create a new WP_MetaQuery object to see the result and I noticed a huge unnecessary INNER JOINs relation.
**Here's a full example:**
1. Insert 100 Test Posts and 50 Metas For Each: Append [?action=insert] in the URL
2. Try to get posts using WP_Query: Append [?action=wp_query_and_meta_query] in URL - **RESULT: Infinite Loop**
3. Try to use $wpdb instead: Append [?action=wpdb_query_get_ids] in URL - **RESULT: Success, Takes few seconds**
4. See the SQL statement generated by WP_MetaQuery: add [?action=show_meta_query_clause] - **RESULT: a Huge unnecessary **INNER JOIN x AS x# ON y** relation**
5. [?action=wpdb_query_delete] to delete all added posts only.
{{{
add_action('wp', 'oxibug_trigger_action');
/**
* Trigger Suitable Function
*
* @return void
*/
function oxibug_trigger_action() {
if( ! isset( $_GET['action'] ) ) {
return;
}
$action = wp_strip_all_tags( $_GET['action'] );
switch( strtolower( $action ) ) {
case 'insert': {
oxibug_insert_posts_and_metas();
} break;
case 'wp_query_and_meta_query': {
oxibug_WP_Query_and_meta_query();
} break;
case 'show_meta_query_clause': {
oxibug_show_meta_query_clause();
} break;
case 'wpdb_query_get_ids': {
oxibug_wpdb_query_get_ids();
} break;
case 'wpdb_query_delete': {
oxibug_wpdb_query_delete();
} break;
}
}
/**
* Return New Meta Key
*
* @param mixed $key
* @return string
*/
function oxibug_get_new_meta_key( $key ) {
return sanitize_text_field( sprintf( 'oxibug_xyz%s', $key ) );
}
/**
* Return Key-Value Pairs array with Old and New meta keys
*
* @return array
*/
function oxibug_legacy_and_new_meta_keys() {
return [
'oxibug_abc_post_main_color' => oxibug_get_new_meta_key('_page_main_color'),
'oxibug_abc_page_layout' => oxibug_get_new_meta_key('_page_layout'),
'oxibug_abc_post_sbwide' => oxibug_get_new_meta_key('_page_sb_wide'),
'oxibug_abc_post_sbnarrow' => oxibug_get_new_meta_key('_page_sb_narrow'),
'oxibug_abc_page_sbwide' => oxibug_get_new_meta_key('_page_sb_wide'),
'oxibug_abc_page_sbnarrow' => oxibug_get_new_meta_key('_page_sb_narrow'),
'oxibug_abc_self_video_m4v_url' => oxibug_get_new_meta_key('_format_video_selfhosted_mp4'),
'oxibug_abc_self_video_ogv_url' => oxibug_get_new_meta_key('_format_video_selfhosted_ogv'),
'oxibug_abc_self_video_webmv_url' => oxibug_get_new_meta_key('_format_video_selfhosted_webmv'),
'oxibug_abc_self_video_poster_url' => oxibug_get_new_meta_key('_format_video_selfhosted_poster'),
/* Audio */
'oxibug_abc_soundcloud_url' => oxibug_get_new_meta_key('_format_audio_oembed'),
'oxibug_abc_self_audio_mp3_url' => oxibug_get_new_meta_key('_format_audio_selfhosted_mp3'),
'oxibug_abc_self_audio_oga_url' => oxibug_get_new_meta_key('_format_audio_selfhosted_ogg'),
'oxibug_abc_self_audio_m4a_url' => oxibug_get_new_meta_key('_format_audio_selfhosted_m4a'),
/* Post Formats: Image | Video */
'oxibug_abc_lightbox_check' => oxibug_get_new_meta_key('_format_image_lighbox_enable'),
'oxibug_abc_post_banner_caption' => oxibug_get_new_meta_key('_format_status_banner_caption'),
'oxibug_abc_quote_text' => oxibug_get_new_meta_key('_format_quote_text'),
'oxibug_abc_quote_author' => oxibug_get_new_meta_key('_format_quote_author_name'),
'oxibug_abc_url_text' => oxibug_get_new_meta_key('_format_link_text'),
'oxibug_abc_url_destination' => oxibug_get_new_meta_key('_format_link_url'),
/*
* Layout Settings - if Old = [hide] turn ON the new option
*
* */
'oxibug_abc_post_breadcrumb' => oxibug_get_new_meta_key('_hide_breadcrumb'),
'oxibug_abc_post_meta_info' => oxibug_get_new_meta_key('_hide_metas'),
'oxibug_abc_post_share_box' => oxibug_get_new_meta_key('_hide_share_icons'),
'oxibug_abc_post_tags' => oxibug_get_new_meta_key('_hide_tags_box'),
'oxibug_abc_post_author_box' => oxibug_get_new_meta_key('_hide_author_box'),
'oxibug_abc_related_posts' => oxibug_get_new_meta_key('_hide_related_posts_box'),
'oxibug_abc_posts_navigation' => oxibug_get_new_meta_key('_hide_nav_box'),
/* Review Items */
'oxibug_abc_post_review_types' => oxibug_get_new_meta_key('_review_type'), /* [disabled] => Add 0 to the new meta [_review_show] */
'oxibug_abc_post_review_position' => oxibug_get_new_meta_key('_review_position'),
'oxibug_abc_post_reviews_summation' => oxibug_get_new_meta_key('_review_items_avg'), /* This field is Dynamic - SUM of all review items */
'oxibug_abc_review_item' => oxibug_get_new_meta_key('_review_items'),
'oxibug_abc_post_review_title' => oxibug_get_new_meta_key('_review_title'),
'oxibug_abc_post_review_desc' => oxibug_get_new_meta_key('_review_desc'),
'oxibug_abc_post_review_summary_title' => oxibug_get_new_meta_key('_review_summary_title'),
'oxibug_abc_post_review_summary_desc' => oxibug_get_new_meta_key('_review_summary_desc'),
'oxibug_abc_post_review_user_rates' => oxibug_get_new_meta_key('_review_user_ratings_status'),
'oxibug_abc_post_review_user_rates_bgcolor' => oxibug_get_new_meta_key('_review_user_ratings_result_bgcolor'),
'oxibug_abc_post_review_btn_text' => oxibug_get_new_meta_key('_review_add_btn_text'),
'oxibug_abc_post_review_btn_icon' => oxibug_get_new_meta_key('_review_add_btn_icon'),
'oxibug_abc_post_review_btn_url' => oxibug_get_new_meta_key('_review_add_btn_url'),
'oxibug_abc_post_review_btn_bgcolor' => oxibug_get_new_meta_key('_review_add_btn_bgcolor'),
'oxibug_abc_post_review_pros_word' => oxibug_get_new_meta_key('_review_pros_word'),
'oxibug_abc_post_review_pros_icon' => oxibug_get_new_meta_key('_review_pros_icon'),
'oxibug_abc_post_review_pros_list' => oxibug_get_new_meta_key('_review_pros_list'),
'oxibug_abc_post_review_cons_word' => oxibug_get_new_meta_key('_review_cons_word'),
'oxibug_abc_post_review_cons_icon' => oxibug_get_new_meta_key('_review_cons_icon'),
'oxibug_abc_post_review_cons_list' => oxibug_get_new_meta_key('_review_cons_list'),
/* Post Views */
'oxibug_abc_post_views_count' => oxibug_get_new_meta_key('_post_views'),
];
}
/**
* Insert 100 Test Posts and some Meta Keys
*
*/
function oxibug_insert_posts_and_metas() {
$legacy_and_new_keys = oxibug_legacy_and_new_meta_keys();
$result = [];
for( $i=0; $i<100; $i++ ) {
$post_id = wp_insert_post( [
'post_type' => 'post',
'post_title' => wp_strip_all_tags( sprintf( 'Test Meta Query Post #:%s', $i ) ),
'post_content' => sprintf( 'Test Meta Query Post Content #:%s', $i ),
'post_content_filtered' => '',
'post_excerpt' => '',
'post_status' => 'publish',
// 'post_author' => 1,
// 'post_category' => [],
'comment_status' => '',
'ping_status' => '',
'post_password' => '',
'to_ping' => '',
'pinged' => '',
'post_parent' => 0,
'menu_order' => 0,
'guid' => '',
'import_id' => 0,
'context' => '',
'post_date' => '',
'post_date_gmt' => '',
], TRUE, TRUE );
if( ! is_wp_error( $post_id ) ) {
$result[ $post_id ] = [];
foreach( (array) array_keys( $legacy_and_new_keys ) as $_legacy_key ) {
$upstatus = update_post_meta( $post_id, $_legacy_key, '' );
$result[ $post_id ][ $_legacy_key ] = $upstatus ? 'Added' : 'Failed';
}
/* Clean Cache */
clean_post_cache( $post_id );
}
else {
echo 'ERROR: Insert Post Failed!';
}
}
/* DEBUG */
echo sprintf( '%d Posts Inserted', count( $result ) );
// echo print_r( $result );
}
/**
* --- DEBUG ---
* Show the Meta Query SQL Statement
*
*/
function oxibug_show_meta_query_clause() {
/**
*
* @var wpdb
* */
global $wpdb;
$legacy_meta_keys = oxibug_legacy_and_new_meta_keys();
$meta_query = [
'relation' => 'OR'
];
foreach( (array) array_keys( $legacy_meta_keys ) as $_legacy_key ) {
$meta_query[] = [
'key' => $_legacy_key,
'compare' => 'EXISTS'
];
}
$objMetaQuery = new WP_Meta_Query( $meta_query );
echo print_r( $objMetaQuery->get_sql( 'post', $wpdb->posts, 'ID', NULL ) );
}
/**
* Query using WP_Query and meta_query key inside it
*
*/
function oxibug_WP_Query_and_meta_query() {
/**
*
* @var wpdb
* */
global $wpdb;
$legacy_meta_keys = oxibug_legacy_and_new_meta_keys();
$meta_query = [
'relation' => 'OR'
];
foreach( (array) array_keys( $legacy_meta_keys ) as $_legacy_key ) {
$meta_query[] = [
'key' => $_legacy_key,
'compare' => 'EXISTS'
];
}
$obj_WP_Query = new WP_Query( [
'numberposts' => -1,
'paged' => null,
'post_type' => 'post',
'post_status' => 'publish',
'meta_query' => $meta_query,
'fields' => 'ids',
'cache_results' => false,
] );
/*
* Stuck in an Infinite Loop Because of the Huge SQL Statement
* generated by [meta_query]
*
* */
if( $obj_WP_Query->have_posts() ) {
echo sprintf( '%d Posts Found', $obj_WP_Query->found_posts );
/* DEBUG - NOT Working - */
// echo print_r( $obj_WP_Query->meta_query->get_sql( 'post', $wpdb->posts, 'ID', NULL ) );
}
else {
echo 'No Posts Found';
}
$obj_WP_Query->reset_postdata();
wp_cache_flush();
}
/**
* Get Posts IDs by one of the meta_key(s) provided
*
*/
function oxibug_wpdb_query_get_ids() {
global $wpdb;
$legacy_meta_keys = oxibug_legacy_and_new_meta_keys();
$qry = ""SELECT DISTINCT tbl_posts.ID FROM {$wpdb->posts} tbl_posts INNER JOIN {$wpdb->postmeta} tbl_metas ON ( tbl_posts.ID = tbl_metas.post_id ) WHERE"";
/* Add [OR] in the second condition */
$where_clause = 0;
foreach( (array) array_keys( $legacy_meta_keys ) as $_legacy_key ) {
$where_clause++;
$qry .= ( $where_clause === 1 ) ?
$wpdb->prepare( ' tbl_metas.meta_key = %s', esc_sql( $_legacy_key ) ) :
$wpdb->prepare( ' OR tbl_metas.meta_key = %s', esc_sql( $_legacy_key ) );
}
$result = $wpdb->get_results( $qry );
$wpdb->flush();
echo print_r( wp_list_pluck( $result, 'ID' ) );
}
/**
* --- DEBUG ---
*
* DELETE all added Posts by meta_key(s)
*
*/
function oxibug_wpdb_query_delete() {
global $wpdb;
$legacy_meta_keys = oxibug_legacy_and_new_meta_keys();
$qry = ""DELETE tbl_posts, tbl_metas FROM {$wpdb->posts} tbl_posts INNER JOIN {$wpdb->postmeta} tbl_metas ON ( tbl_posts.ID = tbl_metas.post_id ) WHERE"";
$where_clause = 0;
foreach( (array) array_keys( $legacy_meta_keys ) as $_legacy_key ) {
$where_clause++;
$qry .= ( $where_clause === 1 ) ?
$wpdb->prepare( ' tbl_metas.meta_key = %s', esc_sql( $_legacy_key ) ) :
$wpdb->prepare( ' OR tbl_metas.meta_key = %s', esc_sql( $_legacy_key ) );
}
$result = $wpdb->get_results( $qry );
$wpdb->flush();
}
}}}
" oxibug
Untriaged tickets (that need a patch) 44695 WP_Term_Query unexpected 'orderby' behaviour. Query 4.9.7 normal normal Awaiting Review defect (bug) new needs-unit-tests 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
Untriaged tickets (that need a patch) 53495 incorrect (and confusing) DocBlock for get_page_by_title() Query 5.3 normal normal Awaiting Review defect (bug) new 2021-06-24T00:41:14Z 2021-06-24T00:42:10Z "The DocBlock of [https://developer.wordpress.org/reference/functions/get_page_by_title/ get_page_by_title()] says:
> If more than one post uses the same title, the post with the smallest ID will be returned. Be careful: in case of more than one post having the same title, it will check the oldest publication date, not the smallest ID.
That description was added in [45779].
Besides the fact that the text after `Be careful:` seems to contradict that the statement that `the post with the smallest ID will be returned`, there actually is no guarentee that if there is more than 1 post with the same title that the one with the smallest ID will be returned.
The query performed by [https://core.trac.wordpress.org/browser/trunk/src/wp-includes/post.php#L5534 get_page_by_title()] is:
{{{#!php
$sql = $wpdb->prepare(
""
SELECT ID
FROM $wpdb->posts
WHERE post_title = %s
AND post_type = %s
"",
$page_title,
$post_type
);
}}}
(with a slight mod if an array of post types is passed).
Since there is no `ORDER BY` clause in that query, if there are more than 1 posts with the same title the order in which they are returned is not defined by SQL (i.e., is implemented dependent).
The SQL-92 spec [http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt explicitly states]:
> General Rules
>
> 1) All General Rules of Subclause 7.10, """", apply
> to the .
>
> 2) Let Q be the result of the .
>
> 3) If Q is empty, then a completion condition is raised: no data.
>
> 4) If an is not specified, then the ordering of
> the rows of Q is implementation-dependent.
As far as I can tell, no later revisions of the SQL spec are available for free on the web, so I don't know if anything has changed in the what the language says happens in the absense of an `ORDER BY` clause
I've looked through the MySQL and Maria DB docs for an explicit statement that says as much and haven't been able to find one.
But I think the DocBlock should be changed to say something like:
> If more than one post uses the same title, which of the multiple posts is returned is not defined.
though I'm not completely happy with that wording, and welcome other suggestions.
" pbiron
Untriaged tickets (that need a patch) 56105 Call update_post_parent_caches in the_post function in WP_Query class Query normal normal Awaiting Review enhancement new needs-unit-tests 2022-06-30T12:01:38Z 2023-04-20T12:55:57Z "Hello Team,
In {{{the_post}}} function {{{class WP_Query}}}, {{{update_post_author_caches}}} is already in use but not {{{update_post_parent_caches}}}.
I am not sure if it is because of {{{update_post_parent_caches}}} calls the private function {{{_prime_post_caches}}} or what." priyankkpatel
Untriaged tickets (that need a patch) 42082 Support compare custom fields in WP_Meta_Query Query 4.9.4 normal normal Awaiting Review enhancement new 2017-10-04T01:30:51Z 2018-02-28T13:32:39Z "The syntax of `WP_Meta_Query` currently is limited to values you already know.
It's not possible to compare between two meta_values:
{{{
SELECT posts WHERE meta_value_one > meta_value_two
}}}
I propose allow compare two meta_fields. For example, the pseudocode above would be represented as a meta_query argument that looks like this:
{{{#!php
'meta_value_one',
'value' => 'meta_value_two',
'compare' => '>',
'type' => 'META_VALUE'
),
}}}
A workaround can be found [https://wordpress.stackexchange.com/a/164041 here] and [https://gist.github.com/mariovalney/e8646d8c64db36e9f239e6d05f2e5923 here] hahaha.
Feedback is welcome." mariovalney
Future Releases 56312 Appending ?name to home URL shows the posts page instead of a static front page Query normal normal Future Release defect (bug) reopened 2022-07-30T10:45:09Z 2023-01-06T09:17:54Z "I found something strange
I installed a WordPress then from setting . Reading I set a sample page as homepage
And when I opened website it was ok and showed content of sample page but when I added query string “?name” it showed latest blog posts
I tried everything as query string nothing did that and all showed sample page content and that was ok
Just just with ?name query string showed different thing
For ex localhost/site/?name show latest posts but
Localhost/site/?everythingyoutype
Was ok and show content of the page
Why ?name query string is like that??? I want to remove it
actually you must test it just on homepage of your site
not another pages
it hurts SEO if you show something else with query string on your site (specially on your homepage) instead of the main content
basically as you said when you enter the url of homepage with /?name you should see the homepage and nothing should change because it’s just a query string
I can show you an example
see this : https://amepro.at/
as you see everything is fine and homepage of website is ok
but please see this one https://amepro.at/?name
here you see the blog posts and it hurts SEO very bad
I got too much errors on search console with these kind of urls
Can you explan the logic behind it why should we show another thing like latest post when someone enter some parameter ?
it’s not normal at all" masimoti
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 needs-unit-tests 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 60566 Posts Page as Draft remains publicly queryable Query normal normal Future Release defect (bug) new 2024-02-17T11:46:03Z 2024-02-19T11:04:08Z "When assigning a Posts Page at ""WP Admin > Settings > Reading"" and afterward setting that page to draft, the page remains publicly queryable. This is possible via the `?page_id=` query (not `?p=`) and the provisioned slug." Cybr
Future Releases 37762 cache_results parameter doesn't prevent queried posts from being added to cache boonebgorges Query 4.6 normal normal Future Release defect (bug) assigned dev-feedback 2016-08-22T09:39:42Z 2022-06-15T13:23:14Z "Even when `cache_results` is set to `false`, the queried posts in `WP_Query` are still mapped to `get_post()` which will always add post instance to cache.
For more info: http://wordpress.stackexchange.com/questions/236653/how-to-prevent-queried-posts-from-being-added-to-cache/236659.
" Dang Vu
Future Releases 46294 wp rest api fails to paginate page requests correctly when ordering on menu_order Query 5.4.1 normal normal Future Release defect (bug) new 2019-02-21T06:00:48Z 2021-04-12T21:58:19Z "**Describe the bug**
Gutenberg and wordpress fails to render the parent page dropdown correctly when there are more than 100 pages and the pages have various menu_order values set.
The problem is that gutenberg calls the wordpress rest api like this, getting 100 items at a time.
http://server/wp-json/wp/v2/pages?per_page=100&exclude=890&parent_exclude=890&orderby=menu_order&order=asc&context=edit&_locale=user
http://server/wp-json/wp/v2/pages?per_page=100&exclude%5B0%5D=890&parent_exclude%5B0%5D=890&orderby=menu_order&order=asc&context=edit&_locale=user&page=2
This results in the following 2 sql queries:
`SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND wp_posts.ID NOT IN (890) AND wp_posts.post_parent NOT IN (890) AND wp_posts.post_type = 'page' AND ((wp_posts.post_status = 'publish')) ORDER BY wp_posts.menu_order ASC LIMIT 0, 100`
`SELECT SQL_CALC_FOUND_ROWS wp_posts.ID FROM wp_posts WHERE 1=1 AND wp_posts.ID NOT IN (890) AND wp_posts.post_parent NOT IN (890) AND wp_posts.post_type = 'page' AND ((wp_posts.post_status = 'publish')) ORDER BY wp_posts.menu_order ASC LIMIT 100, 100`
When ordering on a non unique field like menu_order you need to also add a second unique ordering field like ID ,, See https://bugs.mysql.com/bug.php?id=72076 See the answer from Tor Didriksen.
This is very critical bug because it means that if the current pages parent is missing in the parent page dropdown and you click update it means that the menu order for that page will be reset and this means i cant use gutenberg.
**To Reproduce**
Steps to reproduce the behavior:
1. Create around 200 pages.
2. Set menu_order != on some of the pages.
3. edit any of the pages.
4. the parent page dropdown is missing pages
**Expected behavior**
the rest api should add some unique order by field to prevent the same items from coming on page 1 and 2 of the requests.
" hobzhobz
Future Releases 38173 Meta query creates unecessary multiple left joins when using the same meta key Query 3.2 normal normal Future Release enhancement new 2016-09-27T16:36:27Z 2017-02-17T03:06:46Z "If you specify the below as a meta_query wordpress creates an extremely bad and inefficient query, it seems to unnecessarily create a left join for each array even though they have the same key when it could use the same join
{{{#!php
'OR',
array(
'key' => 'product',
'value' => '1',
'compare' => '!='
),
array(
'key' => 'product',
'compare' => 'NOT EXISTS'
)
);
}}}
{{{
SELECT SQL_CALC_FOUND_ROWS vvc_posts.ID FROM vvc_posts LEFT JOIN vvc_postmeta ON ( vvc_posts.ID = vvc_postmeta.post_id ) LEFT JOIN vvc_postmeta AS mt1 ON (vvc_posts.ID = mt1.post_id AND mt1.meta_key = 'product' ) WHERE 1=1 AND (
( vvc_postmeta.meta_key = 'product' AND CAST(vvc_postmeta.meta_value AS CHAR) != '1' )
OR
mt1.post_id IS NULL
) AND vvc_posts.post_type = 'news' AND ((vvc_posts.post_status = 'publish')) GROUP BY vvc_posts.ID ORDER BY vvc_posts.post_date DESC LIMIT 0, 10
}}}
On my site this query takes a huge 6.640 sec, more than 80% of the page's ttfb.
{{{
SELECT SQL_CALC_FOUND_ROWS vvc_posts.ID
FROM vvc_posts
LEFT JOIN vvc_postmeta ON ( vvc_posts.ID = vvc_postmeta.post_id && vvc_postmeta.meta_key = 'product')
WHERE 1=1
AND (CAST(vvc_postmeta.meta_value AS CHAR) != '1' OR vvc_postmeta.post_id IS NULL )
AND vvc_posts.post_type = 'news'
GROUP BY vvc_posts.ID
ORDER BY vvc_posts.post_date
}}}
whereas an optimized version takes only 0.969 sec." neonWired
Future Releases 23309 Not all WP_Query::query_vars get updated during WP_Query::get_posts() Query normal normal defect (bug) new needs-unit-tests 2013-01-28T15:40:56Z 2019-06-04T20:43:47Z "There is a lot of logic within the WP_Query::get_posts() method that fills in missing query vars with defaults and manipulates others based on the rest of the query. However, some of the final states for many of the variables aren't updated in the WP_Query::query_vars array. For example, the post type is lost as a local variable and post_status is used for building compiling mysql expressions, but never directly updated.
The result is that any plugins that want to recreate the query for another system, (ie, an external search provider) must directly copy much of the business logic that WP_Query::get_posts() has embedded in it in order to fill in for the incomplete query_var array.
" prettyboymp
Future Releases 30911 Overhaul post_status logic in WP_Query Query normal normal defect (bug) new needs-unit-tests 2015-01-05T15:24:11Z 2019-06-04T20:48:22Z "`WP_Query` filters based on post_status in two different places:
1. When building the main SQL query (`SELECT ID FROM $wpdb->posts`...). https://core.trac.wordpress.org/browser/tags/4.1/src/wp-includes/query.php#L2946 This block is responsible for parsing the 'post_status' query var, and rectifying these passed post_statuses with the 'perm' param, the logged-in user's permissions, and whether `is_admin()`. (The ability to query by 'post_status' dates from [5575].)
2. On `single` queries (`is_page()`, `is_single()`), additional filtering happens *after* the query. https://core.trac.wordpress.org/browser/tags/4.1/src/wp-includes/query.php#L3511 The intended purpose of this block is to ensure that Preview works (since posts being previewed generally are not published). The current incarnation of the preview logic (ie, living in `WP_Query`) was introduced in [2523].
These two 'post_status' blocks have two different purposes and two different histories, but they interact in a number of problematic ways. Just a few of the problems:
a. Querying posts with 'fields=ids' means that the post ids are returned before the second filter block gets a chance to run. As a result, certain `WP_Query` objects (eg 'p=123&post_status=trash') can return different post IDs depending on whether you request 'fields=ids'.
b. Values passed to the post_status parameter of `WP_Query` are sometimes overridden forcibly, based on logged-in user status. In an ideal world, `WP_Query` would not make any essential reference to the logged-in user. Realistically, we can't change some of this behavior for reasons having to do with backward compatibility. But there are places where the current user logic could be reworked so that it provides defaults, which can then be overridden by the params passed to `WP_Query`. Some relevant tickets: #28568, #29167
c. Filtering out non-previewable posts after the main query has taken place means doing more SQL queries than necessary in cases where post_status=draft and `is_single()`.
d. Filtering out non-previewable posts after the main query has taken place can result in certain sorts of data leakage. See eg #30910.
e. Having two separate blocks that filter results based on post_status makes unnecessarily complicated to fix post_status bugs. See eg #30530, #22001, #23309.
My initial thought is that the second block should be removed. Preview logic should either be merged with the first block of post_status parsing logic that runs when building the main post query, or it should be moved into a separate query_var, which would then be passed when making a Preview request. In general, the challenge here is to ensure that the default post_status whitelist is properly sensitive to the permissions of the logged-in user - which sometimes means building clauses like `(post_status = 'publish' OR ( post_status = 'private' AND post_author = 123 ))`.
I've started to write some unit tests that describe the (weird and complicated) existing behavior. See #29167 [31047]." boonebgorges
Future Releases 34211 Ability to specify fields WP_Query can search Query 4.4 normal normal enhancement new 2015-10-08T11:59:10Z 2019-06-04T20:52:08Z "Currently the `s` parameter in WP_Query is hardcoded to only search in the `post_title` and `post_content` fields. A decent enhancement would be if you could also specify which postmeta fields it can search into as well.
Also allowing more fine-grained control so that it can search only postmeta fields and ignore `post_title` and `post_content` as well.
Something along the lines of:
{{{
's' => 'foo',
's_fields' =>'title',
's_meta_fields' => array( 'custom_field_1', 'custom_field_2' ),
}}}
`s_fields` can a string/array of either post_title and/or post_content. Setting it to false would disable searching these fields and assume you have set custom meta fields to search for instead. By default it would be `array( 'title', 'content' )`.
`s_meta_fields` can accept a string/array of postmeta field names to search for. By default it would be `false`.
A decent use case would be the [https://wordpress.org/plugins/search-by-sku-for-woocommerce/ Search by SKU for Woocommerce] plugin which resorts to writing a custom query.
I assume the only real concern would be performance." paulwilde
Future Releases 25190 Improve name/pagename query variable mapping Query normal normal enhancement new needs-unit-tests 2013-08-30T08:12:13Z 2019-06-04T20:44:46Z `WP_Query` performs some mappings from custom query variables to `pagename` and `name` for custom post types. This could be improved so that `pagename` is not used for hierarchical post types when a top-level item has been requested. We could also do some mappings between `pagename` and `name` in case the incorrect query variable was used (see #16323). duck_
Future Releases 25180 Make it possible to select only posts with comment_count > 0 Query 3.6 normal normal enhancement new 2013-08-29T17:03:00Z 2019-06-04T20:44:44Z May need this when #11398 goes in. wonderboymusic
Future Releases 29178 Using WP_Query only for result of SQL_CALC_FOUND_ROWS Query normal normal enhancement new 2014-08-11T15:56:32Z 2019-06-04T20:47:33Z "For certain web hosts who reject direct SQL queries and push for use of `WP_Query` everywhere, it would be nice if you could use `WP_Query` only for the result of `SQL_CALC_FOUND_ROWS`
My use case is that I'm added limited faceting support to a search interface. For each facet, I'd like to indicate the number of matching results. Using `update_post_meta_cache => false` and `update_post_term_cache => false` means using `WP_Query` still produces two queries.
Also, it would be interesting to compare the performance of `SQL_CALC_FOUND_ROWS` vs `COUNT(*)` when all you care about is the total count." danielbachhuber
Future Releases 29823 WP_Date_Query across tables boonebgorges* Query normal normal enhancement accepted 2014-10-02T00:29:17Z 2019-06-04T20:47:50Z "The changes proposed in #29822 will make it possible to think about cross-table date queries. Things like: all posts from 2011 that have comments from 2013 or later.
Using this ticket as a placeholder for ideas regarding syntax (do we allow table names to be passed as a param? or perhaps a 'type' argument like `WP_Meta_Query` has, which is then translated into table names?) and other discussion." boonebgorges
Future Releases 15068 merging query objects/arrays Query 3.0 normal normal enhancement new 2010-10-08T04:27:58Z 2019-06-04T20:41:30Z "As multiple post type installations proliferate, I assume more and more people will come across a situation (like me) in which they need to display two (or more) sets of content units, say posts, and post-type ""audio"" in one stream - say on the main blog page. As long as the only condition is the post type itself, that will work fine. However, if those two sets need to be selected using different conditional criteria, say a category in one case, and a custom field in the other, then the current query_posts options will not be sufficient.
While it is possible to retrieve multiple arrays via get_posts and merge them, then sort them using cusomt php, such a solution will break the paged navigation.
If such situations will - as I assume - become more likely as more people use multiple post types and additional variables to specify content, I think it would be useful to be able to combine multiple queries into a meta query that will sort the combined object according to a common sorting variable, say date, and thus preserve the paged navigation.
" youngmicroserf
Future Releases 16910 Lazy evaluation for WP_Query Query normal normal feature request new 2011-03-21T01:04:39Z 2019-06-04T20:41:58Z "Suppose we have a 'city' post type, which is associated with a 'country' post type, such that each 'city' post has a 'country' parent post.
Then the 'country' CPT has a 'language' taxonomy associated to it.
Now, let's say we want to find all the cities which speak a certain language.
Let's assume we already have the `'post_parent__in'` query var: #13927
We could construct a two-step query, like this:
1) Get all the countries with that language:
{{{
$country_ids = get_posts( array(
'fields' => 'ids',
'post_type' => 'country',
'language' => 'french',
'nopaging' => true
) );
}}}
2) Get all the cities belonging to that country:
{{{
$cities = get_posts( array(
'post_type' => 'city',
'post_parent__in' => $country_ids
) );
}}}
No custom SQL queries; fantastic!
But, if you have many many countries (not a good example, I know), you waste a lot of time passing the IDs back and forth from PHP to SQL.
Final query:
{{{
SELECT *
FROM wp_posts
WHERE post_type = 'city'
AND post_parent IN (1, 2, 3, ...)
}}}
It would be a lot more scalable to put the first query into the second, directly, as a subquery.
So, it would now look like this:
1) Get all the countries with that language:
{{{
$country_ids = get_posts( array(
'fields' => 'ids',
'post_type' => 'country',
'language' => 'french',
'nopaging' => true,
'lazy' => true'
) );
}}}
2) Get all the cities belonging to that country:
{{{
$cities = get_posts( array(
'post_type' => 'city',
'post_parent__in' => $country_ids
) );
}}}
$country_ids would now be a WP_Lazy_Query object, which would just contain the subquery SQL. It would be appended to the second query, when needed:
Final query:
{{{
SELECT *
FROM wp_posts
WHERE post_type = 'city'
AND post_parent IN (
SELECT ID
FROM wp_posts
WHERE post_type = 'country'
INNER JOIN wp_terms ...
)
}}}" scribu
Untriaged tickets (that need a patch) 43588 Anonymize commenter IP address once a comment is no longer pending Privacy normal normal Awaiting Review enhancement new needs-unit-tests 2018-03-20T19:06:12Z 2019-01-09T19:17:26Z "A commenter's IP address is stored with each comment. The commenters IP address can often be used to identify a single individual or device at a location.
To enhance commentor's privacy, and to reduce the amount of personal data stored by a WordPress site in preparation for upcoming laws like the GDPR, this issue proposes that once a comment transitions out of pending, core WordPress should zero the commentor's IP address final octet similar to how Google Analytics Anonymizes IP addresses
The rationale for keeping it while a comment is pending is to continue to allow anti-spam access to the IP address which can be used to detect spam.
The rationale for keeping all but the last octet is to still allow statistics to be gathered about the general geographic location of commenters based on the first three octets of the IP address." allendav
Untriaged tickets (that need a patch) 43811 Licence & Policy notice during installation xkon Privacy normal normal Awaiting Review enhancement assigned 2018-04-19T13:56:37Z 2023-08-29T15:33:28Z "This was a thought mentioned in #43492 originally but it deserves it's own ticket at the moment.
We all know about the lovely 5 minute installation process that WordPress provides. I feel like we can create a small placeholder during the installation process ( probably on the first page even ) to notify the users about GPL license and a text on Policy. Yes the license is included in a .txt, but people are more used when installing things to see a license / policy during the installation and then continue to the actual install.
I'm not personally thinking about a full blown page with a wall of text but rather a discreet placeholder to hold just the right the information needed like an excerpt from the GPL and a link refering to the full text for the ease of use etc as well as the connection between WordPress and wp.org during updates and such as stated on other tickets so we can be even more clear and upfront to any given user.
@melchoyce do you think you could check this as well so we can provide a mockup/patch to see how it feels and then we can go forth adding the texts needed here as well just in case this could make it to the release also ?" xkon
Untriaged tickets (that need a patch) 44498 Make `_wp_personal_data_cleanup_requests()` run on cron Privacy 4.9.6 normal normal Awaiting Review enhancement new 2018-07-03T15:17:06Z 2018-07-30T15:56:24Z "When a data export or removal request is created, a user must confirm that request within x days. By default, this is 1 day (24 hours), but it can be changed using the `user_request_key_expiration` filter. If a user does not confirm the request within that time, it is marked as failed, and the request needs to be re-initiated.
Currently, requests are only marked as failed when the Export/Erase Personal Data screens are accessed. By default, only administrators can access this page, and will most likely do so very infrequently. Because of this, a cron may be more appropriate for marking requests as failed.
A `posts_per_page => -1` query arg is also used to fetch expired requests, which could cause issues when a large number of requests have failed. Moving this action to a cron should cut down on the number of requests that need to be transitioned at a time." desrosj
Untriaged tickets (that need a patch) 44001 oEmbed two click / local emoji scripts Privacy 4.9.6 normal major Awaiting Review enhancement new 2018-05-08T06:10:40Z 2019-12-12T20:26:56Z "Hi,
the first beta release 4.9.6 has a few optimziations due to the GDPR, but I think, WordPress is missing two very relevant features. With the latest beta release, WordPress would not be legal for use within the EU - except you´re using WordPress as private notepad!
1) oEmbed two click solution: similar to the shariff plugin, all embedded items via the core WordPress oEmbed function need a two click privacy. Only when the user first clicks on the embedded item, the scripts should be active and the user can view / listen to the embedded item.
2) The emoji script is loaded from Automaticc. There is no possibility to disable this behaviour or the best would be: load all scripts locally. This is one of the relevant of GDPR: you cannot tell your users or lawyers, why it is relevant for using your site, when specific scripts like emoji are loaded from a CDN. There is no need for a CDN.
It would be great, if you could still imagine to implement those both things, because they are rather important than a general privacy policy page, which the most users of WordPress had already created as a single page. And I think not all related core features needs an extra plugin, when it´s time to develop the core further. WordPress should go ahead and implement more features to the core than letting even more plugins used for a proper website.
Thanks and regards," yoursql719
Untriaged tickets (that need a patch) 44370 wp_privacy_delete_old_export_files runs too much on some setups Privacy 4.9.6 normal normal Awaiting Review enhancement new 2018-06-14T14:38:31Z 2019-06-19T12:10:21Z "The `wp_privacy_delete_old_export_files` cron job added in [43046] #43546 runs on an hourly schedule. On large multisite networks, this means that these cleanup are running more or less constantly. Yet they're almost never needed.
It's possible to write a plugin that modifies the behavior, by changing the way that scheduling is done so that it conforms better to the needs of a large network. However, I thought it might be worth considering whether there are changes that WP itself could make that would mitigate the problem for all installations. A few ideas, some of which are mutually compatible:
1. Instead of scheduling the event on 'init', only schedule it when an export file is generated.
2. During the cleanup routine, check for the existence of export files. If none are found, unschedule the recurring event (or don't schedule the next one)
3. In combination with the above, use single events rather than recurring ones
4. Perhaps the cleanup routine itself would be a single event, while a less-frequent (say, daily) recurring event would be to check whether specific cleanup events need to be scheduled (these would be cases missed by 1)
If the team thinks this is too complex, or should be left up to the maintainer of the site in cases where it makes a difference, feel free to close the ticket." boonebgorges
Untriaged tickets (that need a patch) 52903 Consent Management within WordPress Core Privacy normal normal Awaiting Review feature request new 2021-03-24T15:31:29Z 2022-10-14T19:56:55Z "**Website visitor / user Privacy choices:**
a. Users who are not registered on a site, or who choose not to log in when prompted, can set their consent preferences via a simple banner (Gutenberg block) on the front end, which will set a (functional) cookie value for consent.
It should be possible for plugins to filter the banner contents and to change the appearance.
b. Registered users can set their consent preferences via an interface in wp-admin, after logging in.
The interface should extend the ""Edit Profile"" page.
Once a registered user logs out, the consent cookie value should be updated to reflect their preferences as per the database (sync).
**(Sane) Defaults:**
Five default consent categories have been proposed: Functional; Preferences; Anonymous Analytics; Analytics and Marketing.
Website owners / admins should be able to set site-wide defaults by setting a site option value, or by using a plugin to do so.
[An alternative would be to allow them to do so via filter.]
It should be possible for site owners / admins to add additional consent categories, or to add nested sub-categories, or to allow a plugin to do so.
As privacy legislation varies across the globe, I believe that WordPress should default to TRUE for each category, if not overridden, to maintain backwards compatibility and avoid unexpected behaviour.
**Proposed Consent Management hierarchy:**
1. If the user is logged in and has set consent preferences, obtain their preferences via an extension of the REST API.
Using the REST API will allow us to cater for cookies that are set in JavaScript, rather than in PHP.
The basic logic:
{{{#!php
TRUE, ""preferences"" => TRUE, ""anon_stats"" => TRUE, ""stats"" => TRUE, ""marketing"" => TRUE);
return $consent;
}}}
**How to integrate all of this into the Developer community:**
This would require a number of approaches and mechanisms, including:
New functions:
Creating a wp_setcookie(); function in PHP and a corresponding function in JavaScript that checks for consent before placing a cookie;
Use of wp_setcookie(); can then be required for new plugin submissions to the WordPress.org repository.
Updating existing functions:
Updating other functions like wp_mail(); and the HTTP and REST APIs to check for the appropriate consent.
In the case of wp_mail(); for example, this can be done by adding a new parameter variable for $consent_purpose.
We can add a _doing_it_wrong(); if this variable is not present.
In the case of the REST API, consent could possibly be integrated into a permission callback, but that is something we'd need Timothy's (and others) input on.
Education drive:
Voluntary compliance is preferred. By providing documentation, resources and discussing with as many stakeholders as we can (primarily on Slack), we can encourage adoption through education.
**Related tickets:**
I will be closing #51188 in favour of this ticket to make it easier for new contributors to get involved. Please do feel welcome to read the closed ticket if you need / want background.
#51110 deals with the design of a wp-admin interface.
There is not a ticket for the design of a Gutenberg block (as a front end ""interface"") yet." carike
Future Releases 50141 Data erasure/export links should notify the user that the action has already been confirmed Privacy normal normal Future Release defect (bug) new 2020-05-11T02:16:56Z 2020-05-12T05:53:27Z "When a data erasure/export process is started, an email is sent to the email to confirm the action. That email contains only-use-once link that needs to be confirmed for the process to start.
The first request to that url has a nice ""Thanks, you'll be notified when ready"" type message, but clicking the link a second time will just trigger a `wp_die( 'This link has expired.' );` message without any context as to why.
It's also possible that some email scanners (Either on the server, or on an email client) may request the URL on the users behalf to verify if the URL contains any malicious content in which case the email owner would never actually see the success message, and only the expired link message." dd32
Future Releases 44204 Privacy export codebase in 4.9.6 doesn't use WP Filesystem API Privacy 4.9.6 normal normal Future Release defect (bug) new 2018-05-23T13:01:28Z 2020-08-22T21:11:04Z "The codebase added in WP 4.9.6 for privacy was written with low-level file APIs like fopen(), file_exists(), fwrite(), etc. rather than the WP Filesystem API. Quick to see in wp_privacy_generate_personal_data_export_file(). This restricts core parts of the privacy management functionality to only operate on hosts with direct access to the local filesystem.
It is recommended to instead use the WP Filesystem API so that more secure hosts are supported and a broader set of filesystems can be used, e.g. SSH, FTPext, FTPsocket, etc. https://codex.wordpress.org/Filesystem_API" diablodale
Future Releases 44222 Add Archive state to privacy requests garrett-eclipse Privacy 4.9.6 normal normal Future Release enhancement assigned 2018-05-25T06:34:37Z 2020-10-20T19:46:09Z "Hello,
A suggestion for v2 of GDPR is to add an archive/trash state and list view to erasure requests.
Currently, the last state/phase in the erasure process is 'Completed' with the 'Next Steps' action being 'Remove request'.
This automatically prompts the admin to remove and clear the deck. In many if not most cases though the site holds backups which upon site failure will be used to restore the site/content and thus the users PII data. Under GDPR my understanding is the admin is required to re-remove the users data.
Backups are partially safe with GDPR because they are required for site security/integrity, but under retention can only be kept for a reasonable timeframe.
So I was thinking a way to safeguard admins would be to introduce a trash/archive which would have the action for Completed be 'Archive' instead of 'Remove'. This would place the request in the trash and remove from the 'All' view to reduce the clutter. On a new Trash view you're find these requests with the ability to delete permanently.
And I think I heard something about privacy settings at some point in slack which could allow a retention period setting for these archives be set and a cron to auto-remove. So admins would be able to have their database retention and erasure archive retention periods basically match. This would enable them to use the archive list, export it possible, and use it to re-remove users upon database restore.
Most of it is up to the admin to disclose their backup policy and how they'll re-remove users but would definitely help safeguard them from losing requests by running through the workflow too quickly.
Hope that mostly makes sense, mainly just wanted the idea out there.
All the best,
*Note: Most of this is to 'my understanding' so I defer to those more versed in the new regulations." garrett-eclipse
Future Releases 43822 Add UX in the Network Admin for exporting/anonymizing/deleting personal data across the entire network Privacy normal normal Future Release enhancement new 2018-04-20T20:12:18Z 2020-07-06T20:17:20Z "It's not practical for a super admin to hunt down personal data by going to the Dashboard of each site in the network. There should be one centralized place in the Network Admin to receive and process SARs.
This should look similar to the UX in #43546 and #43602, but the underlying functionality for managing the data across the entire network is being discussed in #43738." coreymckrill
Future Releases 44078 Add an email pseudonymization function that preserves first letter and TLD Privacy normal normal Future Release enhancement new 2018-05-14T18:16:11Z 2019-09-20T03:35:24Z "In addition to the existing behavior of wp_privacy_anonymize_data( 'email', $email_address) which returns deleted@site.invalid, it would be useful, e.g. for debug logging to have another type that would return pseudonymized email addresses that retain a little bit of the original address, e.g.
{{{#!php
my-mailbox@mailprovider.com.ca
}}}
could become something like
{{{#!php
m*********@****************.ca
}}}
Where the number of * corresponds to the letters removed, and only the first letter of the email address and the TLD are retained.
See also https://iapp.org/news/a/top-10-operational-impacts-of-the-gdpr-part-8-pseudonymization/" allendav
Future Releases 44320 Inform users when their site's privacy policy is not publicly visible Privacy 4.9.6 normal normal Future Release enhancement new 2018-06-06T19:55:31Z 2019-05-23T19:23:54Z "When a page is selected as the site's privacy policy and is not published, users that can edit the privacy policy should be notified that the page is not publicly visible.
Currently, the only way to know that the selected privacy policy page is unpublished is to go to Pages in the admin and see the page listed with `- Draft` next to its title. #44100 will add `- Draft` to the page titles in the settings dropdown, but that is not visible unless viewing the Settings > Privacy page.
#44131 aims to adjust some of the text on the Settings > Privacy page to indicate the page would be previewed and not viewed, but this is also only seen when on that settings page.
Here are a few ideas that have been thrown tossed around.
== Dashboard Widget
A dashboard widget for Privacy that could indicate any issues with the site's privacy settings. Some examples of what could appear here:
- ""Your site does not have a privacy policy selected.""
- ""The privacy policy page selected is not publicly visible""
- Maybe further down the road, ""Several active plugins on your site do not declare support for data privacy features"" (see #43938, #43750).
== Admin Notice
This admin warning would be dismissible and only show up to users that have the ability to manage the privacy policy. Which pages to show this on and whether ''another'' admin notice should be introduced should be carefully considered.
Related: #44100, #44131." desrosj
Future Releases 44153 Plugin privacy polices and admin notification Privacy 4.9.6 normal normal Future Release enhancement new 2018-05-18T23:14:22Z 2019-04-22T16:54:53Z "If a plugin adds a privacy policy by hooking wp_add_privacy_policy_content(), the information shows up on example.com/wp-admin/tools.php?wp-privacy-policy-guide=1.
However, there's no link on the dashboard menu (esp settings->privacy) regarding that.
Settings->privacy does say ""Need help putting together your new Privacy Policy page? Check out our guide for recommendations on what content to include, along with policies suggested by your plugins and theme."" with a link in the text, but it's quite obscure.
How about a 2nd line: If any plugins or themes have available privacy policies, you'll find them [link]here[/link]. You can them use them on your own privacy policy page." sterndata
Future Releases 44145 Rework Privacy settings page to use the Settings API xkon* Privacy 4.9.6 normal normal Future Release enhancement accepted 2018-05-18T12:23:18Z 2020-09-26T00:04:24Z Now that the Privacy page is under Settings, it should be reworked to utilize the Settings API. desrosj
Untriaged tickets (that need a patch) 49355 """Publishing failed. Error message: Could not update post in the database"" caused by encoding" Posts, Post Types 5.3.2 normal normal Awaiting Review defect (bug) new 2020-02-04T01:30:57Z 2023-07-02T14:44:32Z "I have some text that I am copying into the title of a post. I get the following error:
""Publishing failed. Error message: Could not update post in the database""
The text is:
𝐀 𝐖𝐢𝐧 𝐟𝐨𝐫 𝐚 𝐉𝐮𝐬𝐭𝐢𝐜𝐞 𝐂𝐞𝐧𝐭𝐫𝐞 𝐂𝐥𝐢𝐞𝐧𝐭!
I am having trouble understanding what encoding this text is.
Why is this failing to save to the database? My database is set to utf8mb4. Why WordPress is choking on it?" 1000camels
Untriaged tickets (that need a patch) 39939 A Contributor cannot preview their own post if it's scheduled Posts, Post Types normal minor Awaiting Review defect (bug) new needs-unit-tests 2017-02-22T12:52:02Z 2017-02-23T05:36:25Z "Steps to reproduce:
1. A Contributor writes a post and submits it for review. At this point they can preview their post.
2. An Editor or Administrator approves the post and schedules it for publication at a later date.
3. The contributor viewing the Posts listing table can no longer preview their post.
Previously: #33694
" johnbillion
Untriaged tickets (that need a patch) 53195 Add $post or $post_id to the quick_edit_custom_box hook Posts, Post Types normal normal Awaiting Review defect (bug) new 2021-05-12T11:17:34Z 2021-05-12T11:17:34Z "Right now when you're adding a custom box to quick edit, you can't set an existing value without using JavaScript, cause you don't have acces to the post. For a more elaborate explanation, see the User Contributed Notes, top one by stevenlinx: https://developer.wordpress.org/reference/hooks/quick_edit_custom_box/
It would be more elegant if we could just use the post within the hook I think." tomjdevisser
Untriaged tickets (that need a patch) 47072 Hierarchical post types missing attributes meta box if post type doesn't support 'page-attributes' or have templates Posts, Post Types 5.1.1 normal minor Awaiting Review defect (bug) new 2019-04-29T17:11:09Z 2019-04-29T17:11:09Z Setting the hierarchical argument to true in the register post type function doesn't enable the post parent automatically. In order for this meta box to show up you must also enable post type support for page-attributes or the post type must have templates. I would think the post parent dropdown should be visible by default if the post type is hierarchical. This applies to both the Classic and Gutenberg editor. natereist
Untriaged tickets (that need a patch) 43752 ID, post_parent, menu_order on global $post object is a string in edit context; expecting int Posts, Post Types 4.9.5 normal normal Awaiting Review defect (bug) new needs-unit-tests 2018-04-12T23:34:08Z 2018-04-19T00:27:16Z "When I'm on an edit post screen, the ID, post_parent, menu_order attributes on the global $post object are strings. I expect them to be integers.
To quickly check, put this in a plugin:
{{{#!php
ID);
});
});
}}}
Here's what's happening:
1. in wp-admin/post.php the edit case happens, and within that the post gets reloaded here: https://github.com/WordPress/WordPress/blob/4.9.5/wp-admin/post.php#L167
2. that function will run the post object through its own filter with filter edit here: https://github.com/WordPress/WordPress/blob/4.9.5/wp-includes/post.php#L552
3. because at the time $this->filter = ""raw"", and the $filter is edit, that will run the object through sanitize_post here https://github.com/WordPress/WordPress/blob/4.9.5/wp-includes/class-wp-post.php#L354
4. sanitize_post will, in turn, run all the fields through sanitize_post_field here: https://github.com/WordPress/WordPress/blob/4.9.5/wp-includes/post.php#L1940
5. and even though we have 3 fields set as int (https://github.com/WordPress/WordPress/blob/4.9.5/wp-includes/post.php#L1973), by the time we get to this part (https://github.com/WordPress/WordPress/blob/4.9.5/wp-includes/post.php#L2027-L2034), those three will be ran through esc_attr
6. esc_attr will feed it through _wp_specialchars here https://github.com/WordPress/WordPress/blob/4.9.5/wp-includes/formatting.php#L3978
7. which begins with $string = (string) $string; here https://github.com/WordPress/WordPress/blob/4.9.5/wp-includes/formatting.php#L912
The part that throws me off is that `sanitize_post_field` declares these three properties to be integers at the beginning of the function, so I sort of expected them to come out as integers on the other end." javorszky
Untriaged tickets (that need a patch) 59014 PHP Fatal error in post-template.php Posts, Post Types 6.3 normal minor Awaiting Review defect (bug) new 2023-08-09T03:40:21Z 2023-10-31T00:34:33Z "Hi there,
I hope this email finds you well. Unfortunately, we've recently encountered a critical error that requires immediate attention. This issue pertains to the single page templates, specifically an example like this: https://volunteeringqld.org.au/governance/before-you-join/. The error was not present a week ago, and we're currently grappling to determine its cause. This problem was initially observed on both WP6.22 and WP6.3.
The post https://volunteeringqld.org.au/governance/before-you-join/ connected to a single template php `mytemplate/single-governance-before-you-join.php`, what calls `` what throws error ""There has been a critical error in this website"" and output steam finishes. Log error gives this line:
{{{
""PHP message: PHP Fatal error: Uncaught TypeError: Unsupported operand types: WP_Post - int in /.../wp-includes/post-template.php:330
Stack trace:
#0 /.../wp-includes/post-template.php(247): get_the_content()
#1 /.../wp-content/themes/volunteeringAU/single-governance-before-you-join.php(411): the_content()
#2 /.../wp-includes/template-loader.php(106): include('...')
#3 /.../wp-blog-header.php(19): require_once('...')
#4 /.../index.php(17): require('...')
#5 {main} thrown in /.../wp-includes/post-template.php on line 330', referer: https://volunteeringqld.org.au/governance/""
}}}
To address this, we have applied the following code snippet in `post-template.php` line 330:
{{{
if( ! is_int($page_no)) {
$page_no = 1; // Igor
//echo '';
}
}}}
When echo ancommented it gives
{{{
Array
(
[page] => WP_Post Object
(
[ID] => 5
[post_author] => 7
[post_date] => 2021-10-21 04:24:08
[post_date_gmt] => 2021-10-21 04:24:08
[post_content] =>
[post_title] => Home
[post_excerpt] =>
[post_status] => publish
[comment_status] => closed
[ping_status] => closed
[post_password] =>
[post_name] => home
[to_ping] =>
[pinged] =>
[post_modified] => 2023-05-26 13:50:03
[post_modified_gmt] => 2023-05-26 03:50:03
[post_content_filtered] =>
[post_parent] => 0
[guid] => https://volunteeringqld.org.au/?page_id=5
[menu_order] => 0
[post_type] => page
[post_mime_type] =>
[comment_count] => 0
[filter] => raw
)
[more] => 1
[preview] =>
[pages] => Array
(
[0] =>
Achieving a good transition to the next volunteer who will take over from you has benefits for you, the organisation, and the incoming governance member. Let’s explore things you can do to ensure a good handover.
In this stage of your Governance journey we explore:
)
[multipage] => 0
)
}}}
As you can see, instead of having 1 in `$elements['page']`, it contains a `WP_Post` object of the very first post from the database, even not the one that is displayed.
We are hopeful that this information helps you in resolving the issue and that a solution will be included in an upcoming patch. Please don't hesitate to reach out if you require more details or assistance.
Best regards,
Igor
" volqld
Untriaged tickets (that need a patch) 58062 Positioning of custom post type submenu Posts, Post Types 3.1 normal normal Awaiting Review defect (bug) new 2023-04-02T22:48:57Z 2023-04-12T19:21:47Z "''Current Functionality (since 3.1.0):'' One can add a CPT as a submenu of another CPT by setting the `show_in_menu` argument of the `register_post_type()` function as `edit.php?post_type=CUSTOM_CPT_SLUG`. The submenu is then added into the administration menu by way of the `_add_post_type_submenus()` function. When this occurs, the submenu CPT's are displayed in the order the CPTs were registered.
''Problem:'' The current coding prohibits the ordering of CPT submenu items per the programmer's desires in the event CPT registration is unable to be controlled or in the event other submenu pages are added via the `add_submenu_page()` method. This occurs because the call to [https://developer.wordpress.org/reference/functions/add_submenu_page/#source add_submenu_page()] by [https://developer.wordpress.org/reference/functions/_add_post_type_submenus/#source _add_post_type_submenus()] only passes 5 arguments. (The sixth omitted argument is what handles menu positioning.)
''Solution:'' The `menu_position` argument passed to the `register_post_type()` function already exists, and defines a CPT's positioning within a menu. The solution is to incorporate this argument into the core by modifying line 2079 of [https://core.trac.wordpress.org/browser/tags/6.2/src/wp-includes/post.php#L2079 wp-includes/post.php] as follows:
{{{
add_submenu_page(
$ptype_obj->show_in_menu,
$ptype_obj->labels->name,
$ptype_obj->labels->all_items,
$ptype_obj->cap->edit_posts,
""edit.php?post_type=$ptype"",
isset($ptype_obj->menu_position) ? $ptype_obj->menu_position : NULL
);
}}}
" mort1305
Untriaged tickets (that need a patch) 53418 Post Status Transition missing Hook Posts, Post Types 5.7.2 normal blocker Awaiting Review defect (bug) new dev-feedback 2021-06-15T23:42:17Z 2021-06-15T23:42:17Z "REF: https://codex.wordpress.org/Post_Status_Transitions
So I have been testing this and found there is an issue creating the post type **new to pending**:
{{{#!php
$id,
'post_content' => 'Hello, World!',
] );
}}}
3. Observe that a significant number of unnecessary taxonomy queries are performed" johnbillion
Untriaged tickets (that need a patch) 58134 Use correct plural of status Posts, Post Types normal normal Awaiting Review defect (bug) new 2023-04-15T06:58:24Z 2023-08-18T23:37:30Z "Core uses a variable named **$stati** (10 times to be found, in 3 files), but that's not the correct plural form of '**status**', neither in english, nor in latin or elsewhere. So I plead to change it to **$statuses**. While there seems to be no decent rule for variable names, so technically the variable could be named $stsii or whatever, still we are called to not
{{{
""abbreviate variable names unnecessarily; let the code be unambiguous and self-documenting.""
}}}
see https://developer.wordpress.org/coding-standards/wordpress-coding-standards/php/
Also, as we all know, ""**Code is Poetry**"", isn't it? Now you could argue poetry has some freedoms, but I strongly believe it should use correct grammar, at least in this case.
So I may have convinced you finally of that one, but there's one more issue:
There's also a function
{{{
get_post_stati()
}}}
see https://developer.wordpress.org/reference/functions/get_post_stati/
c'mon, let's rename it to **get_post_statuses**, while we're on it.
You may think this is petty, but it gave me some confusion and after all it's just wrong. Let's get rid of an usage of a plural form which doesn't exist.
" Presskopp
Untriaged tickets (that need a patch) 54964 get_permalink() does not use the correct slug rewrite base Posts, Post Types 5.9 normal blocker Awaiting Review defect (bug) new reporter-feedback 2022-01-27T22:10:49Z 2023-10-04T11:54:50Z "Hello,
get_permalink does not work well for custom posts with slug rewrite.
E.g. I have implemented articles post type:
{{{#!php
array('slug' => _x('articles','slug','mydomain')),...));
}}}
'articles' is translateD to slovak language as 'clanky'. But **get_permalink({id_of_article})** returns '''localhost:10010/articles/my-title'''. It is wrong and i have recieve error 404, because right link is '''localhost:10010/clanky/my-title'''.
It works OK for older WP version.
Thanks a lot for any result.
Kind regards,
Ondrej Jakuba
" jakubaondrej
Untriaged tickets (that need a patch) 60427 "small ""ü"" in page as anchor causes a mistake when try to save (wrong JSON-response)" Posts, Post Types 6.4.3 normal minor Awaiting Review defect (bug) assigned 2024-02-02T19:00:04Z 2024-02-02T19:00:04Z "I tried to make some changes on a page with pre-block content. It contains some anchors and everytime I tried to save the page after some small changes I got the alert ""Aktualisierung fehlgeschlagen. Die Antwort ist keine gültige JSON-Antwort."". The well know answer that there is something wrong with JSON.
I found the reason is that in the anchors where small ""ü"" (a german umlaut). It happened with the anchor target as well as with the anchor link. And at the same time there are some anchors with other umlauts, namely with a big ""Ü"", which do not cause the issue." gregordoehnert
Untriaged tickets (that need a patch) 54376 Add `is_post_publicly_viewable` filter Posts, Post Types normal normal Awaiting Review enhancement new 2021-11-04T22:33:22Z 2022-02-03T20:31:39Z "Related to #49628, #54375.
Add a filter to the is_post_publicly_viewable() function to allow theme and plugin developers to override the default value.
In some circumstances a developer may require the checks use different conditions to the default. " peterwilsoncc
Untriaged tickets (that need a patch) 38599 Allow verbose rewrite rules with custom post types Posts, Post Types normal normal Awaiting Review enhancement new 2016-11-01T00:08:41Z 2021-07-27T05:50:55Z "Every time I create a custom post type (say, Book) I invariably want a structure like this:
/books/ - static page where I can write all sorts of overview content with all of the formatting provided by the theme's page template (not a basic post type archive)
/books/book-1/
/books/book-2/ - custom post type permalinks
This is possible by using a rewrite slug of books.
However, if someone then creates a subpage of books, they'll get a 404 error, full stop.
This has been around a long time, and many workarounds have been provided in trying to get verbose rules triggered, such as: https://gist.github.com/mattberridge/2960966
Rewrite rules underwent some major changes a while ago for improved performance (to get %postname% permastructures working well, then there were pretty attachment URLs, etc), which results in these workarounds no longer working. (Custom post type rules get inserted at a place which isn't easy to reorder and conflicts with other rules).
Instead, I have to keep using unique prefixes which make things look messy and confusing to visitors:
/books/
/book/book-1/ (even though there is no /book/ page on my site)
Having a nicer structure seems like a very common use case (especially given the number of search results you'll find about workarounds).
I'd like to suggest allowing custom post types to trigger verbose rules in a way that will work." smerriman
Untriaged tickets (that need a patch) 49428 Extend get_the_post_pagination() to consider total argument luludak Posts, Post Types normal minor Awaiting Review enhancement assigned 2020-02-13T16:57:34Z 2020-02-13T16:57:34Z "Right now, the usage of the_posts_pagination() is associated directly with the Global query.
By investigating its code in [https://developer.wordpress.org/reference/functions/the_posts_pagination/ documentation], I noticed that, it practically retrieves the pagination arguments expected by {{{paginate_links($args)}}}, but it checks on global query ({{{$GLOBALS['wp_query']}}}) for the maximum number of pages.
However, one of the arguments of {{{paginate_links($args)}}} is {{{total}}}, which, by documentation is:
""The total amount of pages. Default is the value WP_Query's max_num_pages or 1."".
Since this exists as argument, my question is, why don't we check for the {{{total}}} in {{{get_the_posts_pagination()}}}? That way, we can allow its usage on custom queries (they can propagate the number of pages in the {{{total}}} argument), not using the global query at all - as this check can block the use of {{{total}}} as argument.
This fix can be made by changing this code in **link-template.php**:
{{{if ( $GLOBALS['wp_query']->max_num_pages > 1 ) {}}}}
into:
{{{if ( (! empty( $args['total'] ) && $args['total'] > 1 ) || $GLOBALS['wp_query']->max_num_pages > 1 ) {}}}
Note I did not remove the previous check on global query, to ensure backwards compatibility - {{{paginate_links($args)}}} uses global query to retrieve default arguments - so this part of code is useful. I also check for emptiness and then checking for the argument check in order to apply partial evaluation.
Please note I am adding this ticket for further discussion - since I am new to the community. If this is considered of value, I will be happy to work on the patch.
" luludak
Untriaged tickets (that need a patch) 48375 Introduce a separate capability for trashing a post Posts, Post Types normal normal Awaiting Review enhancement new 2019-10-20T20:40:44Z 2020-01-06T20:06:53Z "Related: #41674
It's sometimes desirable to allow users to trash posts but not permanently delete them once trashed, nor empty the trash.
There should be a meta capability, `trash_post|trash_posts`, which by default maps to `delete_post|delete_posts` which is used when a post is trashed instead of deleted. This would allow a plugin to grant a user the ability to trash posts but not permanently delete them." johnbillion
Untriaged tickets (that need a patch) 41674 More granular capabilities for restoring and permanently deleting trashed posts Posts, Post Types normal normal Awaiting Review enhancement new needs-unit-tests 2017-08-19T16:00:27Z 2017-08-19T16:00:27Z "Currently the user capability required for restoring a trashed post or permanently deleting a trashed post is `delete_post`, which maps to `delete_posts`. There should be a separate capability for each of these actions.
Suggestion:
* `restore_trashed_post` which maps to `restore_trashed_posts` which maps to `delete_posts`.
* `delete_trashed_post` which maps to `delete_trashed_posts` which maps to `delete_posts`.
Emptying the trash should use the `delete_trashed_posts` capability.
This allows for more granular control over which users can or cannot restore or permanently delete posts." johnbillion
Untriaged tickets (that need a patch) 41773 Page Templates // Post Type Templates | Any Post Type? Posts, Post Types 4.7 normal normal Awaiting Review enhancement new reporter-feedback 2017-09-01T00:39:03Z 2021-06-07T09:59:55Z "If I add a template like this:
{{{#!php
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 46288 'get_extended' breaks when using 'more' gutenberg block Posts, Post Types 5.0 normal normal Future Release defect (bug) new 2019-02-20T10:21:14Z 2019-04-24T06:21:18Z "'get_extended' returns the closing tag ' in the extended content, which prevents 'the_content' filter from working correctly.
Steps to replicate:
{{{#!php
', '', $post);
}}}
" joewebber
Future Releases 52389 Consistently check for non-empty post ID in attachment functions SergeyBiryukov* Posts, Post Types normal normal Future Release defect (bug) accepted 2021-01-28T10:53:31Z 2021-02-17T23:54:41Z "Background: #50679, #52196.
As a result of the changes in [49084] and [50039], `wp_get_attachment_metadata()` conditionally calls `get_post()` if the attachment ID is not passed:
{{{
$attachment_id = (int) $attachment_id;
if ( ! $attachment_id ) {
$post = get_post();
if ( ! $post ) {
return false;
}
$attachment_id = $post->ID;
}
}}}
This is not really consistent with other attachment functions, which just always call `get_post()` unconditionally:
{{{
$attachment_id = (int) $attachment_id;
$post = get_post( $attachment_id );
}}}
Let's bring some consistency here, there is no reason for these minor differences.
This applies at least to:
* `wp_get_attachment_metadata()`
* `wp_get_attachment_url()`
* `wp_get_attachment_caption()`
* `wp_get_attachment_thumb_file()`
* `wp_get_attachment_thumb_url()`" SergeyBiryukov
Future Releases 47637 Enhance excerpt_remove_blocks to handle more types of group blocks Posts, Post Types 5.2.2 normal normal Future Release defect (bug) reopened 2019-07-02T11:29:15Z 2021-11-22T07:21:00Z "The function excerpt_remove_blocks only considers top-level Blocks in an allowed list for the autogeneration of excerpts. However, since there is now a Group Block in Core (and a lot of self-developed Grouping Blocks out there), this can lead to autogenerated Excerpts being empty although there is plenty of content within the Post.
I propose to add a new filterable ""group blocks"" array, which adds another level to be included in the autogeneration. Additionally, there should be a possibility to register a callback which can be used to generate a custom excerpt dynamically if needed for custom blocks.
Change function excerpt_remove_blocks to this:
{{{
function excerpt_remove_blocks($content){
$allowed_inner_blocks = array(
// Classic blocks have their blockName set to null.
null,
'core/freeform',
'core/heading',
'core/html',
'core/list',
'core/media-text',
'core/paragraph',
'core/preformatted',
'core/pullquote',
'core/quote',
'core/table',
'core/verse',
);
$group_block_excerpt_functions = array(
'core/group' => 'parse_group_block_excerpt',
);
$allowed_blocks = array_merge( $allowed_inner_blocks, array( 'core/columns' ) );
/**
* Filters the list of blocks that can contribute to the excerpt.
*
* If a dynamic block is added to this list, it must not generate another
* excerpt, as this will cause an infinite loop to occur.
*
* @since 4.4.0
*
* @param array $allowed_blocks The list of allowed blocks.
*/
$allowed_blocks = apply_filters( 'excerpt_allowed_blocks', $allowed_blocks );
$group_blocks = apply_filters('excerpt_allowed_group_blocks',$group_block_excerpt_functions);
$blocks = parse_blocks( $content );
$output = '';
foreach ( $blocks as $block ) {
if(in_array($block['blockName'],$group_blocks,true)){
//We have a group Block with no extra excerpt function
$output.= parse_group_block_excerpt($block,$allowed_inner_blocks);
} elseif(in_array($block['blockName'],array_keys($group_blocks),true)){
//The Block registered a custom callback for autogenerating an Excerpt
$output.=call_user_func($group_blocks[$block['blockName']],$block,$allowed_inner_blocks);
} elseif( in_array( $block['blockName'], $allowed_blocks, true ) ) {
if ( ! empty( $block['innerBlocks'] ) ) {
if ( 'core/columns' === $block['blockName'] ) {
$output .= _excerpt_render_inner_columns_blocks( $block, $allowed_inner_blocks );
continue;
}
// Skip the block if it has disallowed or nested inner blocks.
foreach ( $block['innerBlocks'] as $inner_block ) {
if (
! in_array( $inner_block['blockName'], $allowed_inner_blocks, true ) ||
! empty( $inner_block['innerBlocks'] )
) {
continue 2;
}
}
}
$output .= render_block( $block );
}
}
return $output;
}
}}}
Add a function parse_group_block_excerpt
{{{
function parse_group_block_excerpt($block,$allowed_blocks){
$output = """";
if(!empty($block['innerBlocks'])) {
foreach($block['innerBlocks'] as $inner_block){
if('core/columns' === $inner_block['blockName']){
$output .= _excerpt_render_inner_columns_blocks( $inner_block, $allowed_inner_blocks );
continue;
}
// Skip the block if it has disallowed or nested inner blocks.
foreach($inner_block['innerBlocks'] as $inner_inner_block){
if (
! in_array( $inner_inner_block['blockName'], $allowed_inner_blocks, true ) ||
! empty( $inner_inner_block['innerBlocks'] )
){
continue 2;
}
}
}
}
return $output;
}
}}}
After that, a custom block can register itself as an group block just by using
{{{
add_filter('excerpt_allowed_group_blocks','add_my_awesome_group_block_to_excerpt');
function add_my_awesome_group_block_to_excerpt($allowed_blocks=array()){
$allowed_blocks[] = 'my-awesome/groupblock';
return $allowed_blocks;
}
}}}
or even by using a custom excerpt function for dynamic blocks by using
{{{
add_filter('excerpt_allowed_group_blocks','add_my_awesome_group_block_to_excerpt');
function add_my_awesome_group_block_to_excerpt($allowed_blocks=array()){
$allowed_blocks['my-awesome/groupblock'] = 'my_awesome_group_block_custom_excerpt';
return $allowed_blocks;
}
}}}
(I hope i did this right as this is my first ticket)" kuchenundkakao
Future Releases 27494 Posts page appears into search results Posts, Post Types 3.8.1 normal normal Future Release defect (bug) new close 2014-03-23T14:27:23Z 2020-03-03T22:50:07Z "Hi,
if you set a static home page, so then a page for posts, this page is just a virtual page, because it doesn't have any content, just the title. But, if you search on the site for this title, the virtual page will be shown as search result. In my opinion this should be hidden." SGr33n
Future Releases 49969 "Previewing the page designated as ""latest posts"" shows the frontpage" Posts, Post Types normal normal Future Release defect (bug) new 2020-04-21T11:32:13Z 2024-02-21T18:00:31Z "This continues the discussion from https://github.com/WordPress/gutenberg/issues/2409
**The issue**
* Create two pages (let's call them ""My home"" and ""My posts"")
* Go to customizer and set Homepage to be ""My home"" and Posts page to ""My posts""
* Edit ""My posts"" in editor mode
* Press preview
* Confirm you got ""My home"" instead of ""My posts""
**The root cause**
When you click ""Open preview in new tab"" while editing ""My posts"", Gutenberg redirects to a preview URL like this one:
https://mywpsite.com/?page_id=5&preview_id=5&preview_nonce=12bd60d6f4&preview=true
When you visit that URL, WordPress will load the front page instead of the posts page. This is because class-wp-query.php assumes that posts page is also the front page:
https://github.com/WordPress/WordPress/blob/b4373fafe9b87f75bf9d65e808be8049510dff8b/wp-includes/class-wp-query.php#L1032
Then, when rendering a preview, it substitutes the page_id that was requested with the value of get_option( 'page_on_front' ):
https://github.com/WordPress/WordPress/blob/b4373fafe9b87f75bf9d65e808be8049510dff8b/wp-includes/class-wp-query.php#L1904
If I remove the preview parameters and leave only ?page_id=5, it displays the correct page." zieladam
Future Releases 48622 `editable_slug` filter does not pass the correct value Posts, Post Types 5.3 normal normal Future Release defect (bug) new 2019-11-14T05:23:52Z 2019-11-14T15:36:42Z "''Originally reported in https://github.com/WordPress/gutenberg/issues/15802.''
**Describe the bug**
When using the block editor, the 1st param $post_name passed to the editable_slug filter hook is not the same as the classic editor, which is the expected one.
**To reproduce**
1. Install Classic Editor to switch from block to classic
2. Create a draft post with title ""the post title"" and slug ""this-is-the-slug""
3. Create a muplugin with: add_filter( 'editable_slug', function( $post_name ) { wp_die( $post_name ); } );
4. Refresh your edit page
**Expected behavior**
With the classic editor you should have ""this-is-the-slug""
but when using block editor you have ""the-post-title"", sounds like the post_title sanitize with sanitize_title, it should be the real post_,name like classic is doing." noisysocks
Future Releases 37671 Emptying Bin with large amount of posts results in whitescreen Posts, Post Types normal normal Future Release enhancement new needs-unit-tests 2016-08-15T16:01:56Z 2017-08-06T00:31:10Z "When the Bin has a large amount of posts, e.g over 1,500, clicking Empty takes a long time to load, several minutes.
After it finishes, it loads a blank white page and has only deleted about 75% of the posts. There's ~500 remaining." atomicjack
Future Releases 38715 Facilitate posts storing raw JSON in post_content by short-circuiting KSES and other filters Posts, Post Types normal normal Future Release enhancement new dev-feedback 2016-11-08T21:55:55Z 2019-03-26T07:59:01Z "When attempting to store arbitrary JSON in WordPress, the `post_content` field is the logical choice. Using `post_content` to store arbitrary JSON instead of postmeta is more performant and it also means that the JSON content will automatically get support for revisions.
Storing JSON is done in core now for `customize_changeset` posts and it is done in the `widget_instance` post type in the Customize Widgets Plus plugin. In both cases, however, there are challenges when storing the JSON due to filters that may apply on `content_save_pre`. In particular, the KSES filters will apply on the `post_content` and strip out markup that is intended to be contained within JSON strings. The solution taken by changesets is to wrap the updates to the `customize_changeset` post type by the `\WP_Customize_Manager::save_changeset_post()` method. Before this method calls `wp_update_post()`/`wp_insert_post()` it suspends the KSES filters temporarily:
{{{#!php
Array
(
[0] => category
[1] => post_tag
)
[label] => Book
[rewrite_slug] =>
[query_var] =>
[public] =>
[show_ui] => 1
[show_in_nav_menus] => 1
[publicly_queryable] =>
[exclude_from_search] => 1
)
}}}
Even if the post-type is NOT public or NOT publicly_queriable (see above), the counts of the posts in each category still shows, totally ignoring the settings of the post-type.
== Expected Output ==
I would expect the count to be related to the results displayed. If there are no visible results for that category (i.e. the user can't see them due to public settings), I would expect the count to go to zero.
== Actual Output ==
The count of posts in the given category seems to have nothing to do with the visible results.
This is related to this bug: #18950" fireproofsocks
Future Releases 25798 Certain single CPT items result in 404 since 3.7 Posts, Post Types 3.7 normal normal defect (bug) new needs-unit-tests 2013-11-01T14:58:10Z 2019-06-04T20:45:08Z "Related: #25749
The changes in [25182] to the query_var mapping of hierarchical post types have broken single permalinks in some cases, when Permalink setting is set to ""Post name"". To reproduce:
1. Register a post type as follows:
{{{
register_post_type( 'bbg_test', array(
// ...
'hierarchical' => true,
'public' => true,
'rewrite' => true, // any value other than false
'query_var' => false,
// ...
) );
}}}
2. Set permalink settings to ""Post name"" (and flush)
3. Create a new post of the type above, and attempt to visit at the url `http://example.com/bbg_test/foo` (or whatever). Result: 404.
4. Change to any other permalink setting. Result: page loads as expected.
Cause: When the CPT is registered with `'rewrite'` other than `false`, it passes the test at http://core.trac.wordpress.org/browser/tags/3.7/src/wp-includes/post.php#L1275. When it's hierarchical, it passes the test at line 1293. When, because `'query_var'` is set to `false`, the rewrite tag set on line 1294 is of the form 'post_type=bbg_test&pagename=foo' (instead of 'bbg_test=foo'). Then, when an item is loaded, during `WP::parse_request()`, it passes the `preg_match()` test here http://core.trac.wordpress.org/browser/tags/3.7/src/wp-includes/class-wp.php#L198, but a page (ie, an item with `post_type` 'page') is not found by `get_page_by_path()`, and as a result the correct rewrite rule is not matched.
As noted, this is a regression in 3.7 [25182], before which `preg_match( '/pagename=\$matches...` wouldn't have matched.
Obviously it's an edge case that (a) a post type is hierarchical AND has query_var set to false, and also (b) permalinks are set to ""Post name"", but it is a change in behavior that broke one of my plugins, and has been a bit of a bear to track down :) I'm going to set `query_var` to true for my purposes (no harm done on my end) but that may not be possible for others." boonebgorges
Future Releases 21234 Recursive directory creation & get_calendar() for custom post types Posts, Post Types 3.4.1 normal normal defect (bug) new 2012-07-12T12:31:28Z 2019-06-04T20:43:17Z "Hello!
I made two patches, and sent the pull request on githab.
https://github.com/WordPress/WordPress/pull/12
https://github.com/WordPress/WordPress/pull/14
And I want to join to contributers team. How can I do it?
Irc chanel is Terminated :(" avaddon
Future Releases 22003 Saving custom fields goes to post-new.php rather than post.php Posts, Post Types 2.5 normal normal defect (bug) reopened 2012-09-26T15:57:01Z 2019-08-09T00:46:50Z "Create a new post or page.
Add a title and message.
Add a custom field (click ""Add Custom Field"")
The post is saved, but as you are taken to post-new.php rather than post.php, it looks as if your post has disappeared! All is well - it is actually saved - but it's confusing.
Tested on 3.5-alpha-21989" curiousdannii
Future Releases 24415 The 'show_in_admin_all_list' argument for the 'register_post_status' function is ignored when the argument 'public' is set to 'false' Posts, Post Types 3.5.1 normal normal defect (bug) new dev-feedback 2013-05-25T00:06:51Z 2023-05-24T16:08:16Z "Hello,
I stumbled upon a bug in the admin section of WordPress. I'm currently running the latest release (3.5.1) without any third-party plugins.
After creating some custom post statuses via the 'register_post_status' function, I noticed that posts with them do not appear in the default (all) post listing in the admin section, despite me setting the 'show_in_admin_all_list' argument to 'true'.
I narrowed this problem down only to the 'public' argument of the same ('register_post_status') function: if the 'public' argument of custom post status is set to 'true', then everything works as expected and the posts with a custom post status appear in the default (all) post listing in the admin section — but this also makes posts with that custom post status appear to the regular users, making them public, hence the name of the argument.
It's worth noting that the 'public' argument has no such buggy effect on the 'show_in_admin_status_list' argument of the same ('register_post_status') function: it doesn't matter to what the 'public' argument is set — the links to the appropriate post statuses are showed at the top of the post listing only based on the 'show_in_admin_status_list' argument, just like it should." XyntaMan
Future Releases 25113 non-latin CPT rewrite slugs fail `wp_safe_redirect` Posts, Post Types 3.6 normal normal defect (bug) new 2013-08-21T20:37:36Z 2019-06-04T20:44:40Z "If you localize your custom post type rewrite slugs in non-latin language and pass it to `wp_safe_redirect` it will strip all non-latin characters and attempt to redirect to stripped location.
This can be easely reproduced if your custom post type supports comments and you submit a comment from post type single page as `wp_safe_redirect` is called after comment submission." entr
Future Releases 36314 If orderby undefined, alter get_posts to defer to WP_Query's default Posts, Post Types normal normal enhancement new needs-unit-tests 2016-03-23T22:22:46Z 2019-06-04T20:56:15Z "If the argument is undefined, defer `get_posts` orderby & order to that of WP_Query's.
For search strings, this will order posts by relevance. In other cases it will have no effect." peterwilsoncc
Future Releases 20748 Include CPT Posts in Author Count & Archive Page Posts, Post Types normal normal enhancement new 2012-05-25T17:59:48Z 2019-06-04T20:43:09Z "For whatever reason, the default behavior is to only count the number of 'post' that an author has published.
With the advent of custom post types, they should be included as well if the CPT has the 'author' capability.
Currently, the author archive can include CPTs if you manually alter the query - this should be enabled by default if authorship is allowed." iridox
Future Releases 23168 Introduce remove_post_status Posts, Post Types normal normal enhancement new 2013-01-10T08:32:49Z 2019-06-04T20:43:39Z Plugins and themes should be able to remove the default post statuses defined by core. kovshenin
Future Releases 22845 On 32-bit systems, with post IDs higher than PHP_INT_MAX (2147483647) wordpress does not run fine Posts, Post Types 3.4.2 normal normal enhancement assigned 2012-12-10T09:13:01Z 2019-06-04T20:43:30Z "Logging all the MySQL queries I discovered that the queries that should pick my posts were all doing something like this:
SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE post_id IN (2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647,2147483647)
This 2147483647 number clearly has something in it: it's the PHP_INT_MAX value on 32-bit operating systems, while on 64-bit machines it's 9223372036854775807 http://php.net/manual/en/language.types.integer.php
So, the problem is divided in 2 parts: I run on a 32 bit system, and I have my IDs a bit too high.
I know that 2147483647 is a bit high for a post ID, but I discovered this the hard way.
Now, I would have preferred an error message in the administrator interface. Do you think it's a good idea?" copesc
Untriaged tickets (that need a patch) 50847 update_post_thumbnail_cache returns notice when get_the_post_thumbnail used with ID after setup_postdata() Post Thumbnails 5.4.2 normal normal Awaiting Review defect (bug) new 2020-08-04T17:23:43Z 2020-08-21T10:55:00Z "**Situation:**
- Inside main loop
- foreach over array of (related) post_id's,
- use ''setup_postdata($post)'' for each item
- Items call get_template_part(something)
- Template parts uses ''get_the_post_thumbnail'' which allow a post_ID
- ''get_the_post_thumbnail'' calls ''update_post_thumbnail_cache'' (because in_the_loop)
- ''update_post_thumbnail_cache'' gives **notice on line 101: Trying to get property 'ID' of non-object**
- Restore main loop with wp_reset_postdata()
**Possible fix:**
Change this
{{{#!php
posts as $post ) {
$id = get_post_thumbnail_id( $post->ID );
if ( $id ) {
$thumb_ids[] = $id;
}
}
}}}
To this
{{{#!php
posts as $post ) {
if (is_object($post)) {
$post = $post->ID;
}
$id = get_post_thumbnail_id( $post );
if ( $id ) {
$thumb_ids[] = $id;
}
}
}}}
in /wp-includes/post-thumbnail-template.php line 101
" tomcent
Untriaged tickets (that need a patch) 56056 Specify a Custom Array of $sizes for `wp_get_attachment_image` to Reduce HTML Bloat Post Thumbnails normal normal Awaiting Review enhancement new 2022-06-23T15:44:50Z 2022-10-12T18:04:54Z "Plugins and the theme can specify multiple thumbnail sizes. Using `wp_get_attachment_image` provides a modern solution to responsive image sizes, however, it does not currently account for reducing the bloat to all the registered thumbnail sizes that are added by plugins / theme.
Therefore a proposal is to allow a custom list of thumbnails to use, this can, for example, be specified as:
{{{#!php
}}}
This should either embed the video or at the least display a link to the video.
Here's an example plugin for reference: https://wordpress.org/plugins/simple-icons/" thememason
Untriaged tickets (that need a patch) 48656 Views details blocked by SAMEORIGIN Plugins 5.3 normal major Awaiting Review defect (bug) new 2019-11-15T19:43:41Z 2019-11-17T17:19:12Z "Hello,
On multisite, the ""view detail"" link on this page /wp-admin/plugins.php (in each plugin) is bloked by an error
{{{
Chargement refusé par X-Frame-Options : « SAMEORIGIN » à l’adresse « https://example.com/wp-admin/network/plugin-install.php?tab=plugin-information&plugin=loco-translate& », le site ne permet pas l’utilisation de cadres multiorigines depuis « https://example.com/wp-admin/plugins.php ».
}}}
" sebastienserre
Untriaged tickets (that need a patch) 53255 WordPress multisite allows you to delete plugins which are active on some subdomains Plugins 4.6 normal critical Awaiting Review defect (bug) reopened 2021-05-21T22:40:52Z 2021-05-22T14:56:21Z "Hello,
I remember in the past, WordPress was not allowing you to delete a plugin that is active at least on one website. " denisflorin197
Untriaged tickets (that need a patch) 49599 Wrong PHPDoc wp_get_active_and_valid_plugins Plugins 5.3.2 normal normal Awaiting Review defect (bug) new dev-feedback 2020-03-08T14:08:07Z 2022-02-13T17:22:28Z "I found a misleading error in the documentation of wp_get_active_and_valid_plugins (in wp-includes/load.php):
{{{#!php
hooks();
}
static public function uninstall()
{
error_log('uninstall method was called on ' . date('Y-m-d H:i:s'));
}
}
$ATest = new \ATest();
$ATest->run();
}}}
When I click on delete plugin (the plugin is already deactivated), the `pre_set_site_transient_update_plugins` hook was called.
To reproduce.
1. Copy and paste the sample code above to new plugin file. For example test.php
2. Go to your WordPress > admin > plugins.
3. Activate this plugin.
4. Go to your DB, delete `_site_transient_update_plugins` option name in `options` table to make sure that this hook will be call next time.
5. Reload admin plugins page. This hook will be called as normal process because plugin is activated. The error log will be write to **wp-contents/debug.log** file.
6. Deactive this plugin.
7. Maybe try to reload plugins admin page again. The hook will not called from this plugin, no error log were write. This is correct.
8. Click on delete this plugin.
9. The error log were write because this hook is called while it is on uninstall process. This is incorrect!! It should not be called.
WordPress 6.0-alpha-52682" okvee
Untriaged tickets (that need a patch) 51731 Add the reason for deactivation to the 'deactivate_plugin' hook. Plugins normal normal Awaiting Review feature request new 2020-11-09T14:28:12Z 2020-11-09T14:38:20Z To be able to check if a plugins was disabled by a user action or because of the 'validate_active_plugins' check that is done on when visiting the plugins.php page would be great from a management perspective. Many WordPress installations have some required plugins which are not necessary for the site to work but do need to be active for one reason or another. This enables the option to notify the admin when a plugin gets disabled by accident because of a failed updated or any other reason. merlijnvanlent
Future Releases 47160 Backport blocking of plugin updates if required PHP version is not supported Plugins 5.2 normal normal Future Release defect (bug) new dev-feedback 2019-05-06T21:46:08Z 2019-10-07T23:38:51Z "Follow-up from #43987 and #44350. Description from https://core.trac.wordpress.org/ticket/43987?cnum_edit=46#comment:41
With WordPress 5.2 requiring at least PHP 5.6, many plugin authors will start updating their plugins to also require PHP 5.6. This is fine for users running WordPress 5.2, but for users on older versions of WordPress they'll start receiving update notifications for plugins that they may no longer be able to run if they're using a version of PHP older than 5.6. If the user updates such a the plugin then they'll likely start seeing fatal errors.
Backporting the changes that prevent updates from being served to sites that don't meet the plugin's minimum PHP version will help avoid users on older branches finding themselves updating a plugin to a version that no longer works.
" azaozz
Future Releases 30963 Wrong error message when uploading non-zip files on the plugin upload page Plugins normal normal Future Release defect (bug) new 2015-01-09T09:54:54Z 2020-07-02T18:23:00Z "If you go to plugins -> upload plugin and you try to insall a .php file instead of a zip file you get this error message: Abort class-pclzip.php : Missing zlib extensions.
This error message is bad, zlib extensions are not missing, the file type is wrong.
Also this message is missing translation support (I might be wrong on this)." jnhghy
Future Releases 60783 plugins_api() and parameters audrasjb* Plugins normal normal 6.6 defect (bug) accepted 2024-03-15T13:57:13Z 2024-03-18T04:04:23Z "Hello there, (running WP6.5+, might be useless to say)
By reading the doc for `plugins_api()` you can read that some fields are included or not in the response, the doc says ''""$fields: Array of fields which should or should not be returned.""'' and then you have a list of fields, some true some false by default.
Let's try it, this is my simple request on my plugin on repo:
{{{#!php
'secupress',
'fields' => []
)
);
}}}
Since the doc says ''""@type bool $contributors Whether to return the list of contributors. **Default false**.""'' I should not receive this field.
Let see the response:
{{{#!php
string(37) ""SecuPress Free — WordPress Security""
[""slug""]=>
string(9) ""secupress""
[""version""]=>
string(7) ""2.2.5.1""
[""author""]=>
string(44) ""SecuPress""
[""author_profile""]=>
string(41) ""https://profiles.wordpress.org/secupress/""
[""contributors""]=>
array(4) {
...
}}}
There is. Same for those params that are ""false"" by default but still included: ""sections"", ""versions"", ""reviews"", ""banners"", ""active_installs"" (I don't know for ""group"", can't get the thing).
Also there is one param that is not affected by the arguments passed and always returned: ""num_ratings"".
Finally there is some fields that are always returned where the doc can't help, I tried to use they array keys to cancel them, no chance, this is : ""author', ""author_profile"" (those 2 may be forced, that's ok), ""support_threads"", ""support_threads_resolved"", ""upgrade_notice"", and ""requires_plugin"" (I know it's new, but don't forget it)
The patch may have to be done on w.org since this is the site that add too much data and to not respect the passed parameters.
Thanks for your time" juliobox
Future Releases 38183 Add hooks to be run before and after each callback Plugins normal normal Future Release enhancement new needs-unit-tests 2016-09-28T23:41:23Z 2017-08-25T21:15:07Z "Since before the dawn of time, debugging tools have relied on the `all` hook to collect information about how long hooks take to run, and which callbacks are registered to that hook.
This has a few drawbacks. Primarily, it's not possible to collect timing information about individual callbacks, and it's quite difficult to manage recursive hook behaviour.
With that in mind, hooks that run before and after each callback would be quite valuable, but they do need to be considered carefully.
* What kind of performance impact would they have? If there are no callbacks registered to these hooks, there should ideally be no performance impact.
* Should they be `WP_DEBUG` only? This would discourage plugins from abusing them on production systems - they would only be used if the site admin explicitly sets the site to debugging mode.
* Dealing with recursion is fun, should they provide any helpers for indicating recursion level, or is it up to the code hooking into them to handle that?" pento
Future Releases 60495 "Following ""plugins_list"": Add a filter in get_views() in class-wp-plugins-list-table" Plugins 6.3 normal normal 6.6 enhancement new 2024-02-11T23:21:34Z 2024-02-13T12:55:21Z "Since WP 6.3 there is a new filter named ""**plugins_list**"" added in #57278
Using this filter, we can now add a new array key like ""''my_plugins''"" and set some plugins in here.
""''my_plugins''"" is now considered as a ""''status''"" by the WP behavior, like ""''all''"", ""''recently_activated''"", etc, the whole list is here : https://github.com/WordPress/WordPress/blob/master/wp-admin/includes/class-wp-plugins-list-table.php#L49
We can also delete (unset()) one of them if we want too, (like hide the must-use plugins or the ""''upgraded''"" tab)
So now WordPress will go through each iteration of the array keys (aka statuses) and create a tab link to get a new view, here : https://github.com/WordPress/WordPress/blob/master/wp-admin/includes/class-wp-plugins-list-table.php#L495
**What's the issue here.**
WP will try to display a ""text"" for each iteration, if there is no case in the switch, it will still display the $text var, and indeed the last used value, aka incorrect value.
But remember line 49, WP sets a list of allowed statuses, this shouldn't be there anymore since the new filter '''plugins_list''' allow us to add ANY status using an array key. We have to remove line 49 and modify line 52 to remove the in_array() stuff.
Still need a check to keep the same behavior when a wrong status is loaded? it's already done line 315: https://github.com/WordPress/WordPress/blob/master/wp-admin/includes/class-wp-plugins-list-table.php#L315
Now to get the correct translated label in get_views() we need a hook line 586 like:
{{{#!php
(%s)';
break;
}
}}}
Now please test in WP 6.3.x, using this:
{{{#!php
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 37754 Support Receiving Pings for Non Post-Type Permalinks Pings/Trackbacks 1.0 normal normal enhancement new 2016-08-20T23:57:21Z 2019-06-04T21:03:23Z "Related: #2700
Ten years ago, it was proposed that the ability to ping the homepage(often linked in the author_url of a comment).
After a year, the issue was closed and turned over as a plugin issue. While the idea of pinging comments is certainly one that can be added as a plugin, the infrastructure to support receipt on arbitrary pages is not.
This enhancement is specifically about making it possible for Core or a plugin to receive and direct these pingbacks, separate from the issue of what to do with them once received.
After the changes are made, that could be explored as plugin territory. However, the only way to do this now is to completely replace the pingback handler with a custom one.
Probably the easiest way to do this is to expand url_to_postid to allow it to return an arbitrary post_ID(using a filter) if it detects that the URL in question is a valid URL on the site, but does not refer to a post_type.
" dshanske
Untriaged tickets (that need a patch) 45331 'rest_url_prefix' filter fails to impact flush_rewrite_rules() on plugin activation Permalinks 4.9.8 normal major Awaiting Review defect (bug) new reporter-feedback 2018-11-12T14:39:16Z 2020-10-25T04:25:29Z "'rest_url_prefix' filter fails to impact flush_rewrite_rules() on plugin activation
=========================================================================
So here is the bug - 'flush_rewrite_rules' is called on plugin activation after 'rest_url_prefix' filter added with new API ENDPOINT,
but if I go to '//' it gives me 404 error. And if I access '/wp-json/' on Firefox Developer Edition in 'Header' section I see:\\
`Link //>; rel=""https://api.w.org/""`\\
So the header is correct here. And it will fix the issue if I go to WP Settings -> Permalinks -> Save.\\
But that is a bug. As you won't have to instruct that to your plugin user, after his activation he will see that API is not working.\\
\\
Install Controller class - 'flush_rewrite_rules' is called on plugin activation after 'rest_url_prefix' filter added with new API ENDPOINT:
{{{#!php
public function setCustomWP_RestAPI_Prefix()
{
// NOTE: Do not forget to do the same on install with flush_rewrite_rules(); after it.
add_filter('rest_url_prefix', function() { return ConfigurationInterface::WP_REST_API_PREFIX; }, 10, 1);
// NOTE: As there is no custom post types or custom taxonomies registration later, we perform rewrite rules flush right now
flush_rewrite_rules();
}
<...>
}
}}}
\\
Main Controller class:
{{{#!php
final class MainController
{
<...>
public function __construct(ConfigurationInterface $paramConfWithoutRouting)
{
<...>
if(!is_null($this->confWithoutRouting))
{
register_activation_hook($this->confWithoutRouting->getPluginPathWithFilename(), array(&$this, 'networkOrSingleActivate'));
register_deactivation_hook($this->confWithoutRouting->getPluginPathWithFilename(), array(&$this, 'networkDeactivate'));
<...>
}
}
/**
* Activate (enable+install or enable only) plugin for across the whole network
* @note - 'get_sites' function requires WordPress 4.6 or newer!
*/
public function networkOrSingleActivate()
{
if(is_multisite())
{
// A workaround until WP will get fixed
// SHOULD be 'networkActivate' but WordPress does not yet support that feature,
// so this means as long as the 'MULTISITE' constant is defined in wp-config, we use that method
$this->multisiteActivate();
} else
{
// A workaround until WP will get fixed
$this->activate();
}
}
public function activate()
{
try
{
<...>
// Install plugin for single site
$objInstaller = new \GreatestEverManager\Controllers\Admin\InstallController($conf, $lang, $conf->getBlogId());
// Install
<...>
$objInstaller->setCustomWP_RestAPI_Prefix();
<...>
} catch (\Exception $e)
{
if(StaticValidator::inWPDebug())
{
// In WP activation we can kill the install only via 'trigger_error' with 'E_USER_ERROR' param
$error = sprintf(static::LANG_ERROR_IN_METHOD_TEXT, __FUNCTION__, $e->getMessage());
trigger_error($error, E_USER_ERROR);
}
}
}
public function run()
{
if($this->canProcess)
{
<...>
add_filter('rest_url_prefix', function() { return ConfigurationInterface::WP_REST_API_PREFIX; }, 10, 1);
add_action('rest_api_init', array(&$this, 'frontEndAPI_Callback'), 0);
<...>
}
}
<...>
}
}}}
\\
Plugin main file (wp-content/plugins/GreatestEverManager/GreatestEverManager.php):
{{{#!php
*/
namespace GreatestEverManager;
require_once 'Models/Configuration/ConfigurationInterface.php';
require_once 'Models/Configuration/Configuration.php';
require_once 'Controllers/MainController.php';
<...>
use GreatestEverManager\Models\Configuration\Configuration;
use GreatestEverManager\Controllers\MainController;
if(!class_exists('GreatestEverManager\GreatestEverManager'))
{
final class GreatestEverManager
{
// Configuration
const REQUIRED_PHP_VERSION = '5.4.0';
const REQUIRED_WP_VERSION = 4.6;
const OLDEST_COMPATIBLE_PLUGIN_VERSION = 6.0;
const PLUGIN_VERSION = 6.0;
// Settings
private static $params = array(
'plugin_id' => 0,
'plugin_prefix' => 'greatest_ever_manager_',
'plugin_api_namespace' => 'gem/v1',
'plugin_handle_prefix' => 'greatest-ever-manager-',
<...>
);
private static $objConfiguration = NULL;
private static $objMainController = NULL;
<...>
/**
* @return Configuration
*/
public static function getConfiguration()
{
if(is_null(static::$objConfiguration) || !(static::$objConfiguration instanceof Configuration))
{
// Create an instance of plugin configuration model
static::$objConfiguration = new Configuration(
$GLOBALS['wpdb'],
get_current_blog_id(),
static::REQUIRED_PHP_VERSION, phpversion(),
static::REQUIRED_WP_VERSION, $GLOBALS['wp_version'],
static::OLDEST_COMPATIBLE_PLUGIN_VERSION, static::PLUGIN_VERSION,
__FILE__,
static::$params
);
}
return static::$objConfiguration;
}
/**
* Creates new or returns existing instance of plugin main controller
* @return MainController
*/
public static function getMainController()
{
if(is_null(static::$objMainController) || !(static::$objMainController instanceof MainController))
{
// NOTE: This is not passing by reference!
static::$objMainController = new MainController(static::getConfiguration());
}
return static::$objMainController;
}
<...>
}
<...>
// Run the plugin
GreatestEverManager::getMainController()->run();
}
}}}
\\
The coding pattern is S.O.L.I.D. MVC, Version 6, based on PSR-4 Autoloaders and PSR-2 Coding Standards.
To deeply inspect load process (without the REST_API part), you can inspect 'Expadandable FAQ' - SolidMVC boiler-plate plugin:
[https://wordpress.org/plugins/expandable-faq/]" KestutisIT
Untriaged tickets (that need a patch) 48365 No 301 redirection for Numeric style permalink structure Permalinks normal normal Awaiting Review defect (bug) new 2019-10-18T02:43:11Z 2019-11-11T22:34:52Z "
Hi :)
If permalink structure is **Post name** style and I changed it to **Numeric**.
the post get a 301 redirect from
http://newwp.local/hello-world/ to http://newwp.local/archives/1
but not so happen with permalink structure **Numeric**.
when the current permalink structure is **Numeric** and I changed it to **Post name** or anything else.
ideally, the post should get 301 redirection from
http://newwp.local/archives/1 to http://newwp.local/hello-world/ but this is not happening.
post giving 404 error instead of 301 redirecting to the correct URL format. when I try to access the post with http://newwp.local/archives/1
Thanks
Naveen Giri
" 1naveengiri
Untriaged tickets (that need a patch) 50439 Post name permalinks htaccess directives do not consider subdirectory installation Permalinks 5.4.2 normal normal Awaiting Review defect (bug) assigned 2020-06-20T12:40:36Z 2020-06-20T12:40:36Z "Having wordpress installed in /wordpress/ subdirectory, and site address as root (following [https://wordpress.org/support/article/giving-wordpress-its-own-directory/#method-i-without-url-change method I in guide]), enabling post name permalinks gives 500 error on any page other than homepage or admin panel pages. This seems to be due to wordpress adding rewrite driectives to root .htaccess file, that seem to override the rewrite rules from method I. Changing permalinks to plain, making root .htaccess read-only (with no wp directives), or disabling them by putting an ifmodule with false condition around them fixes this.
I think that wordpress should consider subdirectory installation when writing htaccess directives." filatovdanyl
Untriaged tickets (that need a patch) 44847 Redirect old date-based permalinks on structure changes Permalinks normal normal Awaiting Review defect (bug) new needs-unit-tests 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
Untriaged tickets (that need a patch) 55401 Subpages of a web page can be called twice Permalinks 5.9.3 normal major Awaiting Review defect (bug) new dev-feedback 2022-03-16T15:48:12Z 2023-07-20T18:41:13Z "Subpages of any website created with WordPress can be accessed twice.
If you add a /0/ to the end of the regular URL, the same page can be called again.
This page with /0/ at the end of the URL will also be indexed in Google.
Example:
https://wordpress.org/news/2022/03/wordpress-5-9-2-security-maintenance-release/
https://wordpress.org/news/2022/03/wordpress-5-9-2-security-maintenance-release/0/" manuel10503
Untriaged tickets (that need a patch) 55597 WordPress 6.0-beta2-53224 not creating .htaccess Permalinks 6.0 normal critical Awaiting Review defect (bug) assigned 2022-04-21T10:58:53Z 2022-05-24T18:46:49Z "on my development site (Plesk Obsidian, Centos 7.9) a fresh installed latest WP 6.0 beta2 does not create an .htaccess file at all.
Steps:
- wordpress-6.0-beta2.zip does not contain .htaccess
- unzipped and uploaded to site
- domain opened in browser
- run set up process until login
- no .htaccess created
- table wp_options 'permalink_structure' contains ""/index.php/%year%/%monthnum%/%day%/%postname%/""
- login as admin
- selecting a permalink structure and saving on /wp-admin/options-permalink.php
- table wp_options 'permalink_structure' contains ""/%postname%/"" as expected
- no .htaccess created
- repeated saving of permalink structure does not help to create .htaccess
- no entry in debug.log
- as to be expected: permalinks not working in front end
- only solution: create a basic .htaccess manually
To me this seems a severe bug.
Found this while testing one of my plugins on WP 6.0 before updating it to plugin repository
Chris
PS: no answer required
" campation
Untriaged tickets (that need a patch) 42148 url_to_postid plain permalinks for CPTs Permalinks 1.0 normal normal Awaiting Review enhancement new needs-unit-tests 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 37812 404 when using a numeric slug and /%category%/ base Permalinks normal normal Future Release defect (bug) new needs-unit-tests 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 8905 Category pagination broken with certain permalink structures Permalinks 2.7 normal normal Future Release defect (bug) assigned 2009-01-21T07:26:31Z 2021-01-27T10:17:49Z "If one uses a permalink structure with %category% followed by %postname%, accessing pagination can cause a 404, as WordPress attempts to look for a post called ""page"".
As per http://barefootdevelopment.blogspot.com/2007/11/fix-for-wordpress-paging-problem.html
Presumably can occur with other permalink structures too." rmccue
Future Releases 34972 Permalink for unattached media same as a post Permalinks 4.4 normal normal Future Release defect (bug) new needs-unit-tests 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 30784 Subsites won't show 404 with default permalink structure Permalinks normal normal Future Release defect (bug) new 2014-12-19T17:10:49Z 2020-07-02T14:20:26Z "On my Multisite (subfolder) installation, I have every site set to use the default (ugly) permalinks. If I go to a subsite and add extra invalid characters after the site name, it displays the site, not a 404 error page.
Example: If I type in domain.tld/sitename/EXTRACHARS it displays the content from domain.tld/sitename, yet keeps the /EXTRACHARS in all the links.
I spoke with Andrea Rennick and she said that this happens because WordPress ignores anything after the sitename because pretty permalinks are not enabled.
This all came up because our Google appliances were crawling millions of invalid URLs because .tld/sitename/EXTRACHARS returns a 200, instead of a 404.
Would it be possible to make it so that an invalid URL would return a 404 instead of ignoring characters beyond the sitename when permalinks are set to default?" danhgilmore
Future Releases 18672 "Implement rel=""prev"" and rel=""next"" for archives" joostdevalk Permalinks 3.3 normal normal Future Release enhancement new 2011-09-15T12:37:23Z 2020-02-29T17:21:40Z "As can be seen here:
http://googlewebmastercentral.blogspot.com/2011/09/pagination-with-relnext-and-relprev.html
Google now uses rel=""prev"" and rel=""next"" to navigate paginated archives. As we already do a lot of these types of links (rel=""index"", rel=""start"" etc.) I think we should add these. I'll come up with a first version of a patch." joostdevalk
Future Releases 34542 Permalink settings page should offer a filesystem API based way to save .htaccess Permalinks normal normal Future Release enhancement new 2015-11-01T10:06:30Z 2020-07-02T17:50:02Z Right now if .htaccess is not writable from PHP, the user is presented with the rules he should manually copy&paste into the file. There is no real reason to sent the user at that point to launch his FTP software to do something that in most cases can be done via the filesystem API. The filesystem API is both faster and most likely less prone to user mistakes. mark-k
Future Releases 29669 Static base in permalink_structure unexpectedly sets $wp_rewrite->front value Permalinks normal normal Future Release enhancement new 2014-09-14T17:44:11Z 2020-07-02T17:46:14Z "When I use a permalink structure like `/story/%post_id%/%postname%/`, the author and date URLs inherit the same `/story/` base (e.g. `/story/author/danielbachhuber/`). I'd expect my author and date URLs to remain unchanged, unless I explicitly specify a base.
There appears to be some crude `%post_id%` conflict resolution for date which forces this. It's not clear why the `front` value is applied to `author_structure`.
This code is 9 years young (#2433), so probably too late to make a breaking change. It would be nice to have a filter around `$wp_rewrite->front` in `$wp_rewrite->init()` so I don't have filter both rewrite rules and links." danielbachhuber
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 needs-unit-tests 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 16126 Multisite name conflict check doesn't check for pages. Permalinks 3.0 normal normal defect (bug) new 2011-01-06T19:11:19Z 2019-06-04T20:41:45Z "Running WP 3.1-RC2 I made a page off my main site called foobar.
Then I went in and made a sub-site (using SubFOLDERS) called foobar.
The subsite took precedence and there was NO check or warning.
I was able to reproduce this on 3.0.4
Then I went the otherway. I have a subsite called camels (don't ask). I went to make a PAGE called camels and it also let me. No conflict check.
Basically you have to add the main blog page names into the banned names list manually, which strikes me as a bit odd. I can see why checking that would be onerous if someone had 600 million pages (and we all know they do) but forcing people to do it manually seems like a gap.
Need love! :D
This is minor, since not a lot of people have bitched, so clearly we're not running into it YET." Ipstenu
Future Releases 27019 Redirect by page slug does not work in permalink structure /%category%/%postname%/ Permalinks 3.8.1 normal normal defect (bug) new 2014-02-05T08:44:36Z 2019-06-04T20:45:36Z "Wordpress has a feature to redirect by page slug. For ex. site with two pages:
{{{
yoursite.com/pageone/pagetwo
}}}
With default permalink settings redirect works like this:
{{{
yoursite.com/pagetwo -> yoursite.com/pageone/pagetwo
yoursite.com/randomtext/pagetwo -> yoursite.com/pageone/pagetwo
}}}
With permalink structure '''/%category%/%postname%/''' redirection from root stops working:
{{{
yoursite.com/pagetwo - 404 error
}}}
, but from non root ok:
{{{
yoursite.com/randomtext/pagetwo -> yoursite.com/pageone/pagetwo
}}}
How to reproduce. Clean wordpress install. Create pages: ""pageone"", ""pagetwo"" with parent page ""pageone"". Try to open url:
{{{
yoursite.com/pagetwo - 301 moved
}}}
Set custom permalink structure to '''/%category%/%postname%/'''. Try to open url:
{{{
yoursite.com/pagetwo - 404 error, but 301 expected
}}}
I think, permalink structure is for post, not for pages. Am I right?
After investigations I found, ""pagetwo"" in url ""yoursite.com/pagetwo"" detected as category name in class-wp.php/'''parse_request()'''. And later canonical.php/'''redirect_guess_404_permalink()''' does not try to find page by category name, only by get_query_var('name'), that is blank." dimagsv
Future Releases 32705 `includes_url` shouldn't use `site_url()` on the frontend Permalinks normal normal defect (bug) new dev-feedback 2015-06-18T15:18:09Z 2019-06-04T20:50:36Z "Multisite / Domain Mapping
1. `site_url()` is your admin, `home_url()` is your frontend
1. The site url is blocked behind a firewall
1. You call `includes_url()` for a script on the frontend: your script is blocked, because it loads your admin domain on the frontend
I noticed this because we are trying to upgrade the NYT to 4.2.* and emoji scripts are showing up everywhere.
I can remove the action for now." wonderboymusic
Future Releases 23117 permalink failed on IIS7 and Reserved Proxy for wordpress 3.5 Permalinks 3.5 normal normal defect (bug) new 2013-01-04T06:30:33Z 2019-06-04T20:43:38Z "it seems to work fine on local but get into a canonical redirect loop when we deploy to production after we upgrade to wordpress 3.5. We did a little debug and found the issue with permalink in file .\wp-includes\canonical.php at line 42 with new coded ""&& !iis7_supports_permalinks()"" added in 3.5.
the issue is iis7 does support permalink and so it go into create and redirect to pretty link which use the website URL in wp-admin settings which is the site URL. when it hits the site URL, our reserved proxy write back to the wordpress site on diff server with port and canonical.php think that's incorrect, so it redirect back to the website URL and the loop go on and on.
we found a temp workaround but not desirable, add this ""remove_filter('template_redirect', 'redirect_canonical');"" in the function.php file in the theme folder you are using. or add a wordpress plugin or simply remove the additional codes in canonical.php file that was added in 3.5. but may cause issue in future upgrade." romeoqngo
Future Releases 34118 Allow permalinks to spell out when certain symbols are used Permalinks normal normal enhancement new 2015-10-01T16:37:15Z 2019-06-04T20:51:58Z "Someone just pasted this link to me in IRC:
http://www.rawstory.com/2015/10/alabama-to-stop-issuing-drivers-licenses-in-counties-with-75-black-registered-voters/
whereas a more accurate URL would be:
http://www.rawstory.com/2015/10/alabama-to-stop-issuing-drivers-licenses-in-counties-with-75-percent-black-registered-voters/
Give the propensity of people to skim read things online, this would be very useful." mattlee
Future Releases 9825 Enforce permalink history, outright Permalinks 2.8 normal normal enhancement assigned needs-unit-tests 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 25006 Display date pages from categories with permalinks Permalinks normal normal feature request new close 2013-08-10T00:46:10Z 2019-06-04T20:44:39Z "When permalinks are not set up we can view posts from a specific category from a specific year (date), but if the permalinks are set up we can view only date pages or category pages.
This works:
`site.com/?cat=1&m=201307` (works)
This does not work:
`site.com/category/uncategorized/2013/07` (does not work)" alexvorn2
Untriaged tickets (that need a patch) 49432 Need of maximum character limit for Site Title Options, Meta APIs low minor Awaiting Review defect (bug) new close 2020-02-14T11:03:40Z 2021-12-14T21:49:41Z "1. There should be a maximum limit of characters for setting up the site title in Admin Dashboard -> Settings -> General. The limit should also be there at time of site setup.
2. Currently, the site title has no limit of characters. This may break the site UI on the frontend.
3. Site title allows to add spaces only, but gets saved as empty." sharduld
Untriaged tickets (that need a patch) 44977 Transient fill fail delete to itself if it's timeout option is missing Options, Meta APIs normal normal Awaiting Review defect (bug) new 2018-09-21T11:25:44Z 2018-09-23T12:47:02Z "Just faced this issue - for some reason, the transient was not deleting itself. While checking the DB, the option with the transient was there, while the timeout option was missing (probably a glitch while saving to DB).
Now, if you check get_transient() in option.php (quick link https://core.trac.wordpress.org/browser/tags/4.9.8/src/wp-includes/option.php#L0 ) you can see that these are deleted only if both exist and both pass the test:
{{{
[...]
if ( false !== $timeout && $timeout < time() ) { DELETING TRANSIENT}
[...]
}}}
Otherwise transient will hang... forever. This should be tuned up so it also checks that these options exist, and delete transient if timeout is absolete." nlozovan
Untriaged tickets (that need a patch) 54805 When on the /wp-admin/network/site-settings.php network settings page, calling the update_option() always add the setting Options, Meta APIs 5.8.3 normal minor Awaiting Review defect (bug) new 2022-01-13T00:03:48Z 2022-01-13T00:03:48Z "When on the network settings (/wp-admin/network/site-settings.php), the udpate_option() used to update the changed settings always adds the settings whenever the form is submitted. So instead of firing the ""update_option"" action hook after the settings are updated, it still fires the **add_option** action hook every time!
Obviously, this should give an error but because there's a bailer when adding option using **ON DUPLICATE KEY UPDATE**, no error is shown." zenithcity
Untriaged tickets (that need a patch) 45505 get_post_custom() doesn't pull values Options, Meta APIs 5.0 normal normal Awaiting Review defect (bug) new 2018-12-06T21:37:29Z 2018-12-06T22:07:14Z "When you are on a post or page and change the content and reload, so that the autosave post pops up at the top, the get_post_custom() values in custom metaboxes aren't being pulled in.
get_post_meta() values however still works in that scenario." dryane
Untriaged tickets (that need a patch) 48478 Allow omitting meta keys from the REST API response if they do not exist Options, Meta APIs 4.7 normal normal Awaiting Review enhancement new 2019-10-31T22:54:18Z 2019-10-31T22:54:18Z "Currently, the REST API will include all `show_in_rest` registered meta keys in a response, even if that meta key has no value. When the meta key has no value, either the empty value or a custom default in `show_in_rest.schema.default` is used.
If an API client PUTs back this response, the meta key will be created with this default value. This may be undesirable if a user hasn't actually interacted with that meta key.
This could be addressed by allowing the user to specify that the meta key should not be included in the REST API if it does not exist. For instance, `show_in_rest.omit_if_not_exists`.
Related Gutenberg ticket: https://github.com/WordPress/gutenberg/issues/17864" TimothyBlynJacobs
Untriaged tickets (that need a patch) 56548 Introduce `get_option` action Options, Meta APIs normal normal Awaiting Review enhancement new needs-unit-tests 2022-09-11T19:00:11Z 2022-09-11T20:14:00Z "There has been the `option_{$option}` filter for a long time, and it makes sense that this filter should be used to tweak options when reading them.
However, there is sometimes a need for running certain logic for when an option is being read. For example, the WordPress performance team is currently working on a feature to optimize the autoloaded options list.
For such purposes, we would like to add a new `get_option` action:
* The reasoning for making it an action is to not falsely encourage developers to think they could use this to filter an option value (which would be excessive since it would be running for every option read).
* The action would get parameters for the option name, the value, and whether the value is based on the default (rather than being looked up from the database).
* The action name would be aligned with the existing actions `add_option`, `update_option`, and `delete_option`.
* It would be documented so that it should only be used for special cases (similar to e.g. the `all` filter)." flixos90
Untriaged tickets (that need a patch) 38690 Introduce classes for settings Options, Meta APIs normal normal Awaiting Review enhancement new dev-feedback 2016-11-07T08:53:14Z 2019-03-26T13:14:34Z "Let's add classes surrounding settings to provide a better structure for dealing with them. It will also allow us to get rid of some globals if we are in a position to remove them (in terms of BC).
Here is what I have in mind:
* A `WP_Settings` class should be introduced that contains `get()`, `update()`, `add()` and `delete()` methods. This will mostly be copy-paste from the related functions. The functions themselves will become wrappers.
* A `WP_Settings_Registry` will be introduced. It should contain all methods that handle registered settings (mostly introduced in 4.7). Again, the functions would become wrappers. We could get rid of the `$wp_registered_settings` global here and store these in a class property instead.
* The `WP_Settings_Registry` instance will be contained by the `WP_Settings` instance as a public property.
* A function `wp_settings()` will be introduced to access the `WP_Settings` instance or generate it if it does not exist yet. I'm not sure yet how to store the instance: The easy way is a global, but I was wondering where we're at with plans like a `WP::get( 'settings' )` so that we could do it differently. Anyway, let's assume a global first.
I think it would be a good pattern to build the class in a flexible way, so that the registry instance and database instance are passed to the class constructor. The following is how I would envision the `wp_settings()` function:
{{{
function wp_settings() {
global $wp_settings;
if ( ! isset( $wp_settings ) ) {
$wp_settings = new WP_Settings( new WP_Settings_Registry(), $GLOBALS['wpdb'] );
}
return $wp_settings;
}
}}}
I think once we agree on an approach, we should do something similar for metadata. But let's have the discussion in here first and open the other ticket afterwards." flixos90
Untriaged tickets (that need a patch) 43818 Invalidate query caches less aggressively by using a `last_changed` key specific to metadata Options, Meta APIs normal normal Awaiting Review enhancement new needs-unit-tests 2018-04-20T08:13:55Z 2018-04-20T08:13:55Z "Currently, the meta implementations for posts, terms, comments and sites (in multisite) invalidate all respective query caches when any value is changed (via setting the `last_changed` key). This is a really aggressive method of cache invalidation and causes in query caches being too frequently invalidated, resulting in lots of unnecessary cache misses.
Most queries (or at least many queries) do not make use of meta queries, and those should stay unaffected by when a meta value changes. Therefore I suggest introducing a specific `meta_last_changed` cache key, and have the meta functions set that one instead of the generic `last_changed`. In the query classes, we can then check if a meta query is present, and only then make use of the `meta_last_changed` key - otherwise we can ignore it and use the regular `last_changed` key.
Regarding the initial implementation, we should think about whether we would wanna roll this out to all the above object types immediately, or whether we should rather start with an object type less popular for metadata (i.e. ''not'' posts). Related to this is #43813." flixos90
Untriaged tickets (that need a patch) 43209 REST API should take settings errors into account Options, Meta APIs normal normal Awaiting Review enhancement new dev-feedback 2018-02-01T23:59:10Z 2018-02-01T23:59:10Z "The `WP_REST_Settings_Controller` should notify the client when updating a setting fails due to an invalid value provided per the setting's `sanitize_callback` (should actually be validation, see related #43208). Currently this goes completely unnoticed.
While `update_option()` doesn't return any information like that, it may be possible to use the information passed to `add_settings_error()` in case of a validity issue, and forward that to the client by returning a `WP_Error` with the message." flixos90
Untriaged tickets (that need a patch) 55969 The function set_transient should have the autoload argument Options, Meta APIs 6.0 normal normal Awaiting Review enhancement new 2022-06-12T14:28:53Z 2023-11-26T23:10:03Z "The function set_transient should have an argument to decide if a specific transient should be autoloaded or not so.
At the moment every transient that is set with the function set_transient is autoloaded.
Not all the transients have the need to be autoloaded. For example, many times transients that are used only in the backend don't need the autoload, but they slow down the frontend in some cases." giuse
Untriaged tickets (that need a patch) 56821 meta_query late row lookup for performance improvement Options, Meta APIs normal normal Awaiting Review enhancement new 2022-10-13T20:46:34Z 2022-10-14T11:59:24Z "Is it possible to do a late row lookup for meta_query to make large postmeta sets run much faster?
In some benchmarking I've done with load testing, queries that would take 8s to load with the current meta_query ended up loading in 500ms after implementing late row lookup.
My suggestion would be to modify the get_posts function in the WP_Query class to have a flag pass through to use late lookup, like passing through `""meta_late_lookup""=>true`:
{{{#!php
meta_query->queries ) ) {
$clauses = $this->meta_query->get_sql( 'post', $wpdb->posts, 'ID', $this );
if(isset($q['meta_query_late_lookup']) && $q['meta_query_late_lookup']){
// perform a late lookup instead of a join
$clauses['where'] = ' AND ID in (SELECT post_id FROM '.$wpdb->postmeta.' WHERE 1=1 '.$clauses['where'].')';
} else {
$join .= $clauses['join'];
}
$where .= $clauses['where'];
}
}}}
At the moment, this can be accomplished with a filter like so:
{{{#!php
' AND ID in (SELECT post_id FROM '.$meta_table.' WHERE 1=1 '.$sql['where'].')');
return $sql;
}
}}}
" brmoore252
Future Releases 59871 Prime further options in `wp_load_core_site_options()` Options, Meta APIs normal normal Future Release defect (bug) new 2023-11-10T02:00:57Z 2024-01-11T17:43:33Z "In Multisite, individual database queries are made to query a number of commonly used options.
On each request:
* WPLANG
* nonce_key
* nonce_salt
On each authenticated request:
* auth_key
* auth_salt
The *_(salt|key) requests are only made if the constant is not defined or uses the default phrase `put your unique phrase here`.
Follow up to #56913." peterwilsoncc
Future Releases 59361 update_post_meta() strict checks can cause false negatives Options, Meta APIs normal normal Future Release defect (bug) new needs-unit-tests 2023-09-15T07:47:12Z 2023-09-15T07:47:12Z "Follow up: #22192
{{{
add_post_meta( $post_id, 'key', 1 );
update_post_meta( $post_id, 'key', 1 );
}}}
The update should not work, because they are the same. However, the meta meta cache will have ""1"" as a string, and then it will strict compare it to 1 as an integer. Thus, an unnecessary update will run.
It is quite common to use integers and booleans directly into these functions. They should be smart enough to recognize that ""1"" == 1 == true and ""0"" == 0 == false, and that any numeric string is also equal to a properly cast integer.
The new changes need unit tests.
Ticket from which this was spun: #22189, saving navigation menus is slow.
cc. @flixos90 @spacedmonkey @joemcgill" mukesh27
Future Releases 37702 Accept array of IDs in `delete_metadata_by_mid` Options, Meta APIs normal normal Future Release enhancement new needs-unit-tests 2016-08-18T01:23:21Z 2019-12-13T19:00:51Z "When deleting meta data in bulk (for example when an object is deleted), improve performance of meta deletion by accepting an array for `delete_metadata_by_mid` and related functions.
Related #37671." peterwilsoncc
Future Releases 48393 Fix from #38903 prevents options autoload parameter update SergeyBiryukov* Options, Meta APIs normal major Future Release enhancement accepted dev-feedback 2019-10-22T07:46:00Z 2023-08-28T21:00:43Z "This is a follow-up to #38903.
3 years ago fix for not * If the new and old values are the same, no need to update. * But this condition does not check if method call intention was to update autoload field of the option.
Currently the issue can be resolved by force update options when update_option method is called with autoload != null and check * If the new and old values are the same, no need to update. * should be skipped." anonymized_16833402
Future Releases 28454 Inconsistent front page option behavior Options, Meta APIs 3.4 normal normal defect (bug) new 2014-06-04T16:44:57Z 2019-06-04T20:47:09Z "'''Correct/expected behaviour:'''
If you change your settings in ''Settings'' > ''Reading'' > ''Front page displays'' as follows:
''From:''
A static page (select below)
-- Front page: home
-- Posts page: blog
''To:''
Your latest posts
then the `Show_on_front` setting is correctly changed to `posts` and the `Page_on_front` setting correctly gets reset to `0`.
'''Incorrect behaviour:'''
If instead you change the same settings from ''Appearance'' > ''Customize'', the `Show_on_front` setting is correctly changed to `posts`, but the `Page_on_front` setting is not reset and remains set to the previous setting's page ID.
'''Testing done:'''
I replicated this behaviour with several themes, including twenty fourteen, with all plugins deactivated.
'''Why this is a problem:'''
This is inconsistent and may cause errors--e.g. if a theme or plugin author checks the `Page_on_front` setting without also checking the `Show_on_front` setting. This is how I encountered it, in Polylang; plugin author had to work around it; details here: http://wordpress.org/support/topic/wrong-front-page-showing-in-appearance-customize-with-polylang-loaded).
'''Solution (indicative; I'm not an expert):'''
Re-use the ""Settings > Reading > Front page displays"" code in the ""Appearance > Customize"" functions. " ElectricFeet
Future Releases 36760 Intermittent empty returns from get_post_meta function after 4.5 upgrade Options, Meta APIs 4.5 normal normal defect (bug) new 2016-05-05T02:45:08Z 2019-06-04T20:58:39Z "I've seen this reported several times, but the reporters failed to properly explain the issue and the tickets were closed.
Since the 4.5 upgrade I am seeing intermittent issues in my custom plugin (which has worked for years and hasn't changed) where the get_post_meta function is used if the request is made via ajax or by calling a custom endpoint. Rolling back the 4.5 upgrade has resolved these issues.
The same function called with exactly the same arguments will return the meta data value one minute and return an empty string the next (with single on). The data in the database is unchanged. Logging shows the post id and meta key are the same, only the return value is different. It always seems to work as part of a regular page request (not ajax, not custom endpoint).
Sometimes the function works correctly for 24 hours, then fails several times. I can't identify any pattern but suspect the meta cache / session. I tried doing a meta cache update for the object before calling get_post_meta, but the problem still occurred.
In Googling I've found several people reporting issues related to get_post_meta after the 4.5 update. Please take a look!" amberau
Future Releases 36655 Enhancement: Add datetime column to options table. Options, Meta APIs normal normal enhancement new needs-unit-tests 2016-04-24T15:04:51Z 2019-06-04T20:57:35Z "== Proposal ==
The options table in WordPress is a great key/value storage option for a wide variety of different data used by core and plugins. One improvement that would increase its utility for faster time based queries on data stored there is to add a DATETIME column.
== Some examples where this benefit could be realized: ==
=== Example 1: Transient storage. ===
Currently, when there is no object-cache in use, transients are stored to the wp_options table. However, for each transient there are two records. One for the actual key/value pair and then one for any timestamp set as the transient expiry. Having a datetime column would allow the transient to always only consist of one record and thus make any queries interacting with transients much simpler.
=== Example 2: Arbitrary plugin data using the options table for its own scheduled tasks. ===
A lot of plugins are using the transient system wrong because it's not intended for indicating minimum age. Having a datetime column would provide the database schema in WordPress core that allows for plugins to implement their own ""minimum/maximum age"" apis.
=== Example 3: Tracking creation/modification times. ===
Having a datetime column would allow for indicating when a key/value pair was created and/or modified which could be useful for plugins that have need to do so.
=== Example 4: Scheduled settings/options. ===
Having a datetime column could allow for scheduled changes with a sites configuration and thus more advanced previews/site preparation, (think adding scheduled changes to site title, or site description via the customizer). Having a datetime column makes such schedules simpler to implement.
== Implementation ==
=== Schema ===
{{{
option_date datetime NOT NULL default '0000-00-00 00:00:00'
}}}
=== Iterations: ===
1. Add the column and modify options api to expose the new column to queries (get_option, update_option, site option functions etc).
2. Convert transient API to implement new option_date column for setting expiries when object-cache is not in use.
== Who and When ==
I'd be willing to spearhead putting some patches together and getting the initial code going but before I invest some time in this I'm just testing the waters to see if this is even something that would be considered/welcomed for core. I'm not aware of any potential conflicts this may pose with the purpose for the option table but if there are any I'm sure I'll find out!
I definitely don't see this as going in 4.6 but it might have potential for 4.7 if work begins fairly soon.
" nerrad
Future Releases 33884 Move meta functions to their own files Options, Meta APIs 4.4 normal normal enhancement new 2015-09-15T17:51:10Z 2019-06-04T20:51:37Z "All the meta functions should be in their own file. Like this.
post-meta.php
comment-meta.php
user-meta.php
Related tickets: #10142 #28290" spacedmonkey
Future Releases 30995 Pass meta_id when retrieving multiple metas Options, Meta APIs 2.9 normal normal enhancement new needs-unit-tests 2015-01-12T20:18:50Z 2019-06-04T20:48:39Z "Hello.
In some (edge?) cases we would need a unique identifier when we retrieve metas. For example, `get_post_custom_values( '_yolo', $post->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 29786 read_post_meta should be a meta capability Options, Meta APIs normal normal enhancement new 2014-09-29T11:19:31Z 2019-06-04T20:47:44Z "Right now, we have `edit_post_meta`, `delete_post_meta`, and `add_post_meta`. In order to be able to expose metadata publicly, we need to be able to check if we can access individual keys.
`is_protected_meta` only controls whether it's prefixed and should default to being protected (by default, prefixed with `_`). This isn't adequate to check for read permission on a key, because it's not filterable." rmccue
Future Releases 23616 General Handler for Whitelisted Options' Submissions Options, Meta APIs normal normal feature request new 2013-02-26T03:06:55Z 2019-06-04T20:43:51Z As stated over on #18285 WordPress should move away from posting to options.php. In order to do that, the Settings API needs a general purpose function that can be safely called on all Settings Pages that can handle posts to itself (generally referred to as 'take_action' in various places) and can handle what options.php currently does. WraithKenny
Untriaged tickets (that need a patch) 27832 All sites automatically marked as archived after upgrade Networks and Sites 3.7 normal normal Awaiting Review defect (bug) new 2014-04-16T10:47:37Z 2018-12-08T15:08:06Z "Strange thing, all sites were automatically marked as archived after automatic upgrade to 3.8.3. Maybe it is not related, but it was the last thing which is time-related to this problem.
I checked database tables and all sites had archived = 1 in wp_blogs, but last_update column was not changed. So, it suggests, that it was not done by administrator. Administrator can archive primary site? Then it is not possible to access administration...
I repaired it by setting 0 for all sites, but I am not sure, how could it happen? Do you have any ideas? There are no plugins which could cause it. I searched code and did not find any clue. Also hosting company is used for many other Multisite installations without problems.
There are also some posts from different forums (usually somehow related to WordPress upgrade), but they are only talking about fixing problem and not about finding why...
http://wordpress.org/support/topic/site-automagically-archived-or-suspended-on-multisite
http://wordpress.org/support/topic/after-install-site-has-been-suspended-or-archived
http://wpgarage.com/tips/unarchive-archived-suspended-site-wordpress-multisite/
Not sure, if it is some kind of bug, incompatibility or security hole..." pavelevap
Untriaged tickets (that need a patch) 54086 bloginfo language issue Networks and Sites 3.0 normal normal Awaiting Review defect (bug) new reporter-feedback 2021-09-08T16:50:55Z 2021-09-23T22:06:39Z "hi,
the code snippet below only returns the name of the blog well, not the language, it is always the same.
even though the language is changed in the site admin settings.
{{{#!php
blog_id );
echo get_bloginfo( 'name' );
echo get_bloginfo( 'language' );
restore_current_blog();
}
}}}
" kukac7
Untriaged tickets (that need a patch) 45761 consistency between $wpdb->blogid and get_current_blog_id() Networks and Sites 3.0 normal normal Awaiting Review defect (bug) new dev-feedback 2018-12-24T20:52:41Z 2019-03-15T13:31:35Z "On a single install (not multisite),
you have
$wpdb->blogid => 0
get_current_blog_id() => 1
Must be a very old one !!!" arena
Untriaged tickets (that need a patch) 43251 editable_roles filter doesn't exclude role on multisite Networks and Sites 4.9.4 normal normal Awaiting Review defect (bug) new 2018-02-07T19:15:54Z 2019-12-06T16:48:21Z "On a multisite installation I am trying to exclude a role using editable_roles filter.
The role is removed from the dropdown but if I change the role value in the DOM using the inspector I can successfully add the excluded role.
This happens only on multisite installations. On single installations if I try to add an excluded role I get the message “Sorry, you are not allowed to give users that role.”
'''How to reproduce the issue:'''
1. Unset a role using editable_roles filter.
2. Login with any role that has the capability create_user.
3. Add a new user changing any role value with the excluded role (using inspector)." eArtboard
Untriaged tickets (that need a patch) 40682 get_current_blog_id() and get_current_network_id() are loaded before absint() Networks and Sites 3.5 normal normal Awaiting Review defect (bug) new 2017-05-06T06:41:04Z 2019-02-23T15:35:39Z In r21484, these functions were moved to `wp-includes/load.php`. Regardless of when they are *supposed* to be called, they are available to be called by cache plugins before `absint()` exists in the ether. If caching plugins are indeed accessing `global $blog_id` this early, seems like a race condition somewhere. wonderboymusic
Untriaged tickets (that need a patch) 56909 pre_recurse_dirsize filter cannot be used to fill up dirsize_cache and thus breaks performance Networks and Sites 5.6 normal normal Awaiting Review defect (bug) new dev-feedback 2022-10-26T06:09:29Z 2022-10-26T06:09:29Z "In 5.6.0 a new filter was introduced to the dirsize calculation `pre_recurse_dirsize`. After that filter was introduced the dirsize cache was modified to store each folders size separately for a massive performance increase ( part of https://core.trac.wordpress.org/ticket/19879 ).
https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/functions.php#L8287
This second change lead to a state where the `pre_recurse_dirsize` filter is kind of useless. One cannot access or modify the dirsize cache within the filter as the `$dirsize_cache` variable is passed by reference to the recursive calls of `recurse_dirsize()`.
https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/functions.php#L8300
Thus using the `pre_recurse_dirsize` filter renders it impossible to use the new, much more efficient dirsize cache based on single folders. I can only fill up the total for the top level folder.
If `pre_recurse_dirsize` is used the code would skip these recursive calls to `recurse_dirsize()`. And thus the reference passing of the `$dirsize_cache` and filling it with the subfolder sizes.
One would consider that the filter code could set the `$dirsize_cache` or the transient value on its own. This doesn't work as well, as the original code works on an in memory version of the `$dirsize_cache` and will overwrite any changes done within the filter at the end of its code.
https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-includes/functions.php#L8323-L8328
This state leads to the bad situation that using the `pre_recurse_dirsize` filter will always lead to worse performance. Although the idea behind introducing it was to open up for performance improvements.
I am currently unsure how to fix this in a smart way and am open for any thoughts and suggestions.
(Maybe bad) Ideas I had:
- Pass the `$dirsize_cache` by the reference to the filter (technically impossible as far as I know)
- Add another filter to disable the dirsize cache saving in `recurse_dirsize` to handle everything on our own (would allow full backward compat)
- Move the `pre_recurse_dirsize` to another position (don't really know where...)
- Make `recurse_dirsize` a pluggable function to replace it completely
Thanks a lot!
" janthiel
Untriaged tickets (that need a patch) 55488 Add a filter to array of allow ported number in multisite. Networks and Sites normal normal Awaiting Review enhancement new 2022-03-30T13:39:42Z 2022-03-30T13:39:42Z "The allowed port numbers to setup a multisite are fixed. See this line.
{{{#!php
if ( ( false !== $has_ports && ! in_array( $has_ports, array( ':80', ':443' ), true ) ) ) {
}}}
However, a site maintainer may want to change these values to help enable serving their multisite from a custom port.
This ticket is a breakout from #21077" spacedmonkey
Untriaged tickets (that need a patch) 41771 Global configuration table Networks and Sites 4.9 normal normal Awaiting Review enhancement new needs-unit-tests 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
Untriaged tickets (that need a patch) 38171 A site within a network has no more users when those users are deleted from the network Networks and Sites 3.0 normal normal Awaiting Review feature request new dev-feedback 2016-09-27T14:08:40Z 2020-01-06T17:33:20Z "In a multisite installation, if a site has only one user and you delete this user, the site has no more users.
That seams logical, but this is not what super admin expects when he deletes a user from the network. When deleting a user, the following question appears :
What should be done with content owned by XXX ?
But even if he chooses ""Attribute all content to:"" option, the site in question is left without any user. I don't think this is impacting the site functions, but perhaps we should add a note ?
We have several options :
* if a user is selected to attribute the content to, it should also be added as a site user
* OR, display a warning somewhere that a site will be left without any user before deleting the user
* OR, do nothing and be responsible of some heart attacks when a super admin discovers that a site has no more active user.
" Fab1en
Untriaged tickets (that need a patch) 54080 Dashboard > My Sites could use a list table for displaying the list of sites Networks and Sites 3.0 normal normal Awaiting Review feature request new dev-feedback 2021-09-07T07:59:55Z 2021-09-08T09:13:36Z "Dashboard > My Sites uses an unfamiliar display when listing a user's sites if compared with the rest of the pages in the administration area such as Posts > All Posts.
For consistency, could My Sites make use of a [https://developer.wordpress.org/reference/classes/wp_list_table/ list table]?" henry.wright
Future Releases 39158 Unify site deactivation process Networks and Sites normal normal Future Release defect (bug) new dev-feedback 2016-12-07T19:20:38Z 2017-08-14T17:16:24Z "Currently there are three cases of ""deleting"" a site on a multisite setup:
* deleting a site entirely (for example via Sites list table's ""Delete"" link)
* deactivating a site from the network admin (for example via Sites list table's ""Deactivate"" link)
* deactivating a site from the site admin (admin can click ""Delete Site"" in Tools menu)
Note that deactivating a site does not wipe out the site, but rather sets the ""Deleted"" flag for that site (strange legacy naming, can be ignored here).
What this ticket should solve is that the latter two processes work differently although they should be doing the same thing: While deactivating a site from the network admin simply sets the site to ""Deleted"", deactivating the current site from the site admin also removes all users from the site (via `wpmu_delete_blog()`). That means if an admin deactivates their site and later asks support (i.e. the network administrator) to restore it, all users will be gone.
I'm not sure why this happens, but I certainly don't think the two actions should have a different behavior. My proposal is to move the part of that function where users are removed into the `if ( $drop )` clause to make sure users are only removed when the site is actually being deleted." flixos90
Future Releases 36940 Break `manage_sites` capability up into more targeted caps johnjamesjacoby Networks and Sites 3.0 normal normal Future Release enhancement assigned 2016-05-25T12:56:16Z 2017-07-17T20:36:26Z "The `manage_sites` capability is currently used as a blanket, to cover all needs when it comes to editing a site in a multisite installation.
Started in #15800 (and having chatted with @jeremyfelt at length) we'd like to break `manage_sites` up into new capabilities that more acutely convey what part of a site someone is allowed to edit.
The goal is to allow users with `/network` admin access to have more fine-grained control over what parts of a site they can edit. For example: `manage_site_settings = false` so a user can modify site themes & users, but not have access to the raw option data.
We are imagining they would look something like:
* `manage_site_info` (`site-info.php`)
* `manage_site_settings` (`site-settings.php`)
* `manage_site_themes` (`site-themes.php`)
* `manage_site_users` (`site-users.php`)
In addition:
* We would pass the site ID through `current_user_can()` to provide additional context
* Switch to using `create_sites` in `site-new.php` (vs. `manage_sites` which was likely a copy-paste assumption that the capabilities across these similar files should match)
----
More paraphrasing of our past 4 months of chat in #core-multisite:
* Because only WordPress Super Admins can access any of these by default, renaming these capabilities should be considered a backwards compatible change
* We /could/ go as far as mapping all of these new caps to `manage_sites` to maintain compatibility, but for plugin authors wishing to take advantage of this, it would require an additional `map_meta_cap` override that we would like to try and avoid
* This should not result in much code churn, and will only change multisite files, and a handful of functions that special-case multisite using the `manage_sites` capability check
* We would still keep `manage_sites` in a few higher-level places (as a site equivalent to `edit_posts`) to ensure that a user has access to certain UI elements that allow them entry to more detailed site editing" johnjamesjacoby
Future Releases 27287 siteurl is missing WordPress path when creating a new site Networks and Sites normal normal defect (bug) new needs-unit-tests 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 14172 Implement $scheme in site info in ms-sites edit site Networks and Sites 3.0 normal normal enhancement assigned dev-feedback 2010-07-01T22:45:33Z 2021-01-05T16:40:51Z "In WordPress 3.0 with Network enabled, if you were to click:
Super Admin -> Sites -> Edit (next to any site) and then change any of the Site Options i.e. wp_2_options the changes don't save.
We're running a secure environment and need Siteurl to be HTTPS instead of HTTP. Changing all the parameters to https and clicking Update doesn't save the changes." firmdot
Untriaged tickets (that need a patch) 58044 Issue with wp_setup_nav_menu_item Menus 6.2 normal normal Awaiting Review defect (bug) new 2023-04-01T16:20:53Z 2023-04-08T14:55:59Z "`/wp-includes/nav-menu.php` has an issue handling bad `$menu_item`.
The problem is with trying to call `get_post_status()`. If a post with type `nav_menu_item` has a problem (I think not having a correct parent or something), the call to `get_post($menu_item->object_id)` returns NULL which then causes an error message from `get_post_states()`.
I had to search the site database to find the offending menu item on my theme development site and deleted the bad menu. I think I likely deleted a page or post that had been include in a menu definition, or perhaps it was because I typically use the Parent Page to define the default menu, which is still supported but seldom used.
This error only seems to appear when using the Customizer, I'm guessing while it is generating the ''Menus'' option. Didn't get error from Dashboard Menu, nor have I tried this on a block theme.
The problem is found around line 833 in `nav-menu.php`.
Here's a possible fix which worked with my bad menu definition, but the problem might be deeper.
{{{#!php
type_label = $object->labels->singular_name;
// Denote post states for special pages (only in the admin).
if ( function_exists( 'get_post_states' ) ) {
$menu_post = get_post( $menu_item->object_id );
/*
* Suggested fix for bad nav_menu_item post - likely caused by now missing parent
* which can result in $menu_post being NULL at this point
*
*/
if ($menu_post != NULL) { //*** add a NULL check
$post_states = get_post_states($menu_post);
if ($post_states) {
$menu_item->type_label = wp_strip_all_tags(implode(', ', $post_states));
}
} // end of added NULL check
}
} else {
$menu_item->type_label = $menu_item->object;
$menu_item->_invalid = true;
}
}}}
" wpweaver
Untriaged tickets (that need a patch) 37920 `the_title` filter called in 2 places inconsistently Menus normal normal Awaiting Review defect (bug) new dev-feedback 2016-09-02T14:20:21Z 2019-04-19T13:22:41Z "This is a follow-up to #35317.
When calling `wp_nav_menu()` to build a frontend nav menu, the filter `the_title` ends up being called 2 times on page links, due to the above ticket.
It is called here https://github.com/WordPress/WordPress/blob/master/wp-includes/nav-menu.php#L754
and then here https://github.com/WordPress/WordPress/blob/master/wp-includes/class-walker-nav-menu.php#L169.
So it is called once when getting the post object title and then again when actually outputting the nav menu.
I think this is negative for 2 reasons:
1) Anyone who wants to filter `the_title` for nav menu items will end up having it called 2 different times, which is odd and can provide inconsistency
2) In both cases, an object ID is included, but the first call the object ID is the Post that the menu item links to (where the title comes from) and the second call the object ID is the nav menu item ID. This means, if a developer anticipates the 2 calls, they cannot check against the supplied object ID to confirm operations only happen once." joelworsham
Untriaged tickets (that need a patch) 18842 wp_nav_menu confuses new developers when it falls through to page listing Menus 3.2 normal normal Awaiting Review defect (bug) reopened 2011-10-02T10:54:12Z 2017-09-20T19:42:00Z "It appears that when wp_nav_menu() falls through to a page listing, many menu-specific args are not passed to the page listing, which ultimately confuses new developers.
I seem to answer this at least weekly in #wordpress
One example is the 'container_class' arg, if it falls through to the fallback_cb, the container_class is not applied.
Ideally, template-related arguements should be passed to the fallback (And with pages as the default callback, it should handle these) or wp_nav_menu() should output any extra wrapping divs if appropriate." dd32
Untriaged tickets (that need a patch) 43176 Nav Menu Search - add filters for query args Menus normal normal Awaiting Review enhancement new 2018-01-29T16:01:00Z 2019-01-16T06:50:09Z "On sites that have lots of content with similar names, it can be almost impossible to find the correct page using the search tab. One way to fix this is described in #38224 (changing the number of posts returned, or providing a filter so developers can change it).
Another option would be to check if the search query is_numeric(), and if so, search for a page with that ID. This could either be implemented in core directly, or appropriate filters could be provided so a plugin could implement this functionality." billerickson
Untriaged tickets (that need a patch) 44803 Add a page to a menu by its ID or slug Menus 4.9.8 normal normal Awaiting Review feature request new 2018-08-15T15:07:48Z 2019-01-30T05:38:39Z "I'm ""porting"" a college's website from Joomla to WordPress.
Said website has +2000 pages, which span from ~2013 onwards. It's the biggest mess you can imagine. There are many repeated pages, repeated categories, empty categories and so on.
Building the main menu for this website has been a pain in the ass, too, because the ""adding pages to a menu"" in WordPress is meant for small websites:
For example, I was trying to add a page named ""Evaluación docente"". There are several pages called exactly the same, but typing ""Evaluación docente"", or ""Evaluacion docente"" (without accents), ""evaluacion docente"" or even """"Evaluación docente"""" (with the quotes, hoping them would help to do a exact match search) returned other pages that weren't the one I was looking for - nor even the other ""Evaluación docente"" pages! Seems like a very fuzzy search. Sometimes you're lucky and you get the page you're looking for, but sometimes you don't.
So I think it would be wonderful if there were some sort of way to add a page to a menu by typing its id or its slug." milerm
Future Releases 43494 Can't change/delete menu items in Customizer on mobile audrasjb* Menus normal normal Future Release defect (bug) accepted 2018-03-07T23:30:18Z 2023-01-06T12:25:28Z "On mobile/tablet browser (only Android, Chrome browser tested), menu items can be added and reorganized, but the drop-down toggle for further options doesn't work. As a result menu items cannot be removed.
To reproduce:
1. Log in to admin in mobile / tablet browser
2. Go to Customizer -> Menus
3. Add menu item to a menu
4. Attempt to edit / delete menu item
Originally reported by community user Sue Jenkins on Twitter: https://twitter.com/LuckychairNews/status/969682449176211456" mor10
Future Releases 38801 Terms with the same name indistinguishable in Menu section Menus normal normal Future Release defect (bug) new 2016-11-15T19:10:08Z 2017-08-18T12:52:07Z "== Problem ==
Let's say we have a WooCommerce site (although likely all taxonomies/terms are liable to this problem) with the following categories: Men, Women. Each of the categories has a subcategory called Shoes.
When in Appearance -> Menu and trying to add a link to Shoes (whichever), there's no way to distinguish the 2 Shoes categories, as the parents are not displayed and no indenting is applied. No matter if we use the Latest, All or Search filter.
== Solution ==
Keep in mind that ""All"" uses pagination, so indenting might not be the best solution. An idea is a hover with the parents listed, but this would be tricky on mobile. Maybe just make a ""Show parents"" switch above the field (or in the Screen Options) and if it's checked, show the parents after the taxonomy/term's name? Like: Shoes (Women -> Shoes).
Just getting rid of pagination in the ""All"" view could cause problems with a lot of values and would not help the Search function within the menu creator." eclare
Future Releases 44329 current-menu-item class not applied to home link with starter content audrasjb Menus low normal Future Release defect (bug) reviewing 2018-06-08T03:12:20Z 2019-07-09T05:43:31Z "When viewing starter content in the customizer the home link does not get the current-menu-item class applied when you view the home page. The menu-item-object-{$type} class is also missing $type, so it just has the class menu-item-object- applied.
When viewing a customizer changeset of the starter content before actually publishing - the home link is not given the current-menu-item class as well. The menu-item-object-{$type} class is still missing $type in this class too.
After publishing the starter content the front end appears to have .current-menu-item correctly applied to the menu when navigating. However, when viewing the site in the customizer - the home link now always has the current-menu-item class applied regardless of which page you visit. This results in two links having current-menu-item applied ( the home link and the currently viewed link ). At this point the menu-item-object-{$type} class now has $type === 'custom', so the class menu-item-object-custom is properly applied.
Additional notes:
- I was only testing with fresh wp installs.
- I was using default permalink structure.
- I noticed this issue with other themes that provide starter content, but it also happens with twentyseventeen
- #43401 does not seem to fix the issues outlined in the steps below.
Expected results:
I expected for menu items to have the current-menu-item classes properly applied when viewing changesets, the customizer preview would accurately reflect the frontend display, and that current-menu-item would not be applied to two different links when previewing pages in the customizer.
Steps to replicate:
1. Use latest trunk (this does also occur on 4.9.6).
2. Have fresh_site option set to 1 to get starter_content.
3. Activate twentyseventeen theme.
4. Go to customizer.
5. Starter content should be populated - inspect the ""Home"" link which doesn't appear to have current-menu-item added, and has the incomplete class menu-item-object- as well.
6. Click on one of the other pages - the link properly reflects the current-menu-item class.
7. Save draft and open the changeset url provided.
8. Click on one of the other pages other than home, and the same issue occurs.
9. Go back into customizer, publish the changeset, and view the site now on the frontend. The home page link is now properly given current-menu-item, and menu-item-object-custom is correct.
10. Click on one of the other links, and the home link no longer has current-menu-item applied, and is applied correctly to the new page you're on.
11. Click on customize - once the customizer loads, the home link AND the link your were looking at both have current-menu-item applied, only the previewed page should have this class." timph
Future Releases 46208 Improve Menu experience by making it easier to delete multiple menus at once audrasjb Menus 5.0.3 normal normal Future Release enhancement reviewing 2019-02-07T21:35:19Z 2019-05-03T22:03:30Z "If possible, please make it easier to delete multiple menus with a one click button (same as the plugin interface).
For example add an extra tab next to ""Manage Locations"".
- Right now, we've to select a menu (to edit) then remove it. If you have like 10 menus... then this task simply takes too much time.
The menus are saved all over different tables wp_terms, wp_posts, etc. inside the database. Wouldn't it be better to simple create a seperate db table for menus instead and have all data placed in there (with object cache)?
Mireille" mireillesan
Future Releases 60673 Indicate submenu item level in admin nav menu editor and customizer nav menu editor rcreators Menus normal normal 6.6 enhancement assigned 2024-03-02T03:31:57Z 2024-03-05T15:23:23Z "Follow up to #32728
Following the closure of #32728, both navigation menu interfaces indicate whether an item is in a submenu. It would improve the experience for screen reader users to indicate what level an item is at." joedolson
Future Releases 14331 Tweaks to menu setup page Menus 3.0 normal normal Future Release enhancement new 2010-07-16T21:30:45Z 2020-05-29T19:39:57Z "It would be great if you could select a parent Page and ""Automatically add children"" to the menu.
In a similar fashion, it would be great if the Menu could then automatically add any new children Pages created under that Parent." mrmist
Future Releases 51964 Add bulk moving to items in the menu screen azhiyadev Menus normal normal Future Release feature request assigned 2020-12-08T07:02:07Z 2021-01-24T09:43:14Z "Hello
I am blind and I use WordPress with screen reader software (JAWS and NVDA).
Using WordPress menu editor is too tedious and time-consuming for a blind user, although other features are quite accessible.
When I go to Appearance > Menus and I add many items to the menu, I cannot rearrange the menu items by drag&drop. I can use Move up / Move down / Move under options for moving the menu items, but this is too time-consuming. I need to press Move Up button 20 times if I want to move an item up to 20 steps higher. If I want to move 5 items up by 20 steps, I need to press ""Move up"" 100 times, over and over. If I want to create a hierarchical menu with an average of 30 menu items, I need to take about 3 hours on rearranging the items.
Bulk Action Feature Request:
I want to have checkboxes beside menu items, so I can select several menu items simultaneously and apply a bulk move / reposition action on all of them simultaneously. For example, I select 6 menu items at a time and I have two comboboxes: parent item, position. I select ""About Us"" as the parent item, and ""3"" as their position. This way, all 6 items go to position 3 under ""About Us"". This is much faster than pressing ""Move Up"" 120 times for reordering those 6 items.
Bulk actions are available in all WordPress taxonomies (Pages, posts, plugins, themes, etc.). I wonder why bulk actions are not available for menu items.
Thank you
" javad2000
Future Releases 21669 "Make ""Home"" option persistent in Pages box on Menus screen" Menus 3.4 normal normal defect (bug) new 2012-08-23T16:57:08Z 2019-06-04T20:03:36Z "If you have some pages, or even a page, then on nav-menus.php in the Pages box, View All, it will display Home as an option. However, if you do not have any pages at all (mostly Blog on front page scenarios), then it just says ""No items."" in the Pages box.
It should always be populated with at least the Home option. Oversight on our part that we didn't uncover this behavior before. " jane
Future Releases 20325 Menu item parent classes for page_for_posts (home.php) not properly set on single.php Menus normal normal defect (bug) new 2012-03-29T12:50:06Z 2019-06-04T20:03:21Z If one has set page_for_posts (Settings => Read), on single.php wp_nav_menu() will set current_page_parent for the accordant menu item, but it will not set any parent or ancestor classes for its parent menu items as expected. [tested with 3.3.1] ptietz
Future Releases 35640 No API to set a nav menu location Menus normal normal defect (bug) new 2016-01-28T05:21:19Z 2019-06-04T20:21:30Z "We've got an API to retrieve the nav menu locations - `get_nav_menu_locations()` however, there's nothing (as far as I can tell) to set a theme location, either singularly or for all menu's.
We should probably have a method that can be used to set a single theme locations menu, and one to bulk-set.
For reference, the admin pages currently all call `set_theme_mod( 'nav_menu_locations', $locations );` directly." dd32
Future Releases 23023 Touch UI Menu Code doesn't address flyout menus two-levels deep. Menus 3.5 normal normal defect (bug) new 2012-12-20T15:21:17Z 2019-06-04T20:04:37Z "The code we did in #20614 only addressed the single dropdowns you normally see in a single site install.
A multisite install will have flyouts coming out of the dropdowns that we need to account for as well.
Related: http://wordpress.org/support/topic/wp-admin-bar-doesnt-play-well-with-touch-device-in-wp-35" georgestephanis
Future Releases 18816 Add 'offset' parameter and 'ancestral' boolean to wp_nav_menu Menus normal normal enhancement new dev-feedback 2011-09-29T16:13:42Z 2019-06-04T20:02:57Z Since we can now call wp_nav_menu multiple times and there is the very useful 'depth' parameter, I believe adding an 'offset' parameter would be very beneficial in many situations. This would allow you to start at the children of the main pages for example and combined with depth it becomes very powerful. An 'ancestral' => 'true' option could output only menu items that the current page is a descendant of. Currently if you want to display a main menu in the header and then a submenu on page.php you either need a tricky custom walker or terrible CSS 'visibility:hidden' or 'display:none' situations. signyourbikeout
Future Releases 26935 Add empty submenu page to hide menu page title in list Menus 3.8 normal normal enhancement new 2014-01-25T07:46:30Z 2019-06-04T20:06:31Z "My question has to do with `add_menu_page()` and `add_submenu_page()`. If we add a menu page, and one sub_menu page.. we end up with the main menu page being duplicated in the sub pages list.
If we have ""Main"" as our main page, and ""Sub"" as our sub page...
{{{
add_menu_page('Main', 'Main', 'manage_options', 'main_options', array($this, 'main_do_page'));
add_submenu_page('main_options', 'Sub', 'Sub', 'manage_options', 'sub_options', null);
}}}
This will create a menu structure such as:
* Main
* Main
* Sub
The ""Main"" page is duplicated in the sub list.
Now, we can hide that duplication with a slight adjustment to the code:
{{{
add_menu_page('Main', 'Main', 'manage_options', 'main_options', array($this, 'main_do_page'));
add_submenu_page('main_options', 'Sub', 'Sub', 'manage_options', 'main_options', null);
}}}
By changing the fifth argument to match the ""Main"" page slug.. it will successfully hide the submenu; resulting in:
* Main
* Sub
However... the issue with this... is a menu item still gets created in the generated html. The inner html is blank.. so no title is actually displayed.. but the outer html is still there.
It appears in the submenu html output as such (with the second snippet above):
{{{
}}}
See how the top item has the html for a list item.. but has no inner html?
This creates a space, about 4 or 5 pixels.. in between the main item and the sub menu items.
Now, I know this is trivial when there is only one menu item. But, now that I know it exists.. it is driving me nuts.
1. It results in unnecessary html output.
2. It results in a space in the menu item list.. which is faint, but unattractive... and hinders the visual appeal of the new admin panel.
Could we perhaps first check if the `add_submenu_page()` fifth argument ($menu_slug) matches the `add_menu_page()` first argument ($page_title)... then the outer html wrapper doesn't get rendered?
With space example(http://joshlobe.com/testsite/images/trac1)
Without space example(http://joshlobe.com/testsite/images/trac2)
Thank you for reading." josh401
Future Releases 12934 Allow a menu to be added as a menuitem to be a submenu. Menus 3.0 normal normal enhancement assigned 2010-04-08T21:55:32Z 2019-06-04T20:02:03Z "Add capability to add a menu as a menuitem to be a submenu thus allowing multiple menu items to share the same submenus.
See reference in April 8 devchat:
https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2010-04-08&sort=asc#m106225" mikeschinkel
Future Releases 35132 UX improvements when creating/editing menus Menus 4.4 normal normal enhancement new 2015-12-17T10:32:28Z 2019-06-04T20:20:10Z "Using the menus component (accessible via Appearance -> Menus) is currently a bit of a pain! A few improvements would go a long way to making this feature more pleasant to use:
1. When editing a menu, the '''Pages/Posts/Custom Links/Categories''' panel on the left hand side does not show which pages have already been added to the menu; all items are unchecked, even if they've already been added to the menu. This makes it very hard to discover any new pages which need adding and also makes it easy to accidentally add duplicate pages.
2. There is currently no means to bulk edit existing menu items - two functions which would be very useful here are the deletion of all existing items and the alphabetical sorting of all existing items.
3. It should be possible to select all children of an existing parent page. For example, if creating a sub menu that lists 20 children of a parent page, we have to click on each child separately. If a new page is added a week later, then items 1 and 2 above become problematic - we need to either carefully check for the new page in the list on the left, cross referencing that list with the existing pages, or we have to delete everything in the menu and add each individual item again from scratch, which despite being quite lengthy is actually the quickest, least error-prone option here.
Hope this helps!" chris_dac
Future Releases 34235 Multi selection in menu Menus 4.3.1 normal normal feature request new 2015-10-09T18:39:44Z 2019-06-04T20:16:58Z Can we have multiple selection of pages/posts/categories/ which are added in menu? So that if we have more number of things are there we can change order easily instead of selecting one by one. vir2714
Future Releases 14969 "menu element ""all (direct) child pages""" Menus 3.0.1 normal normal feature request new dev-feedback 2010-09-26T20:16:39Z 2019-06-04T20:02:19Z One of the things I am missing in the current menu-system is the ability to assign parts of the page tree to, say, a sub-menu, so, say, all child pages of a parent will be listed instead of having to add them manually to the submenu once the menu has been created. youngmicroserf
Untriaged tickets (that need a patch) 60082 """Copied"" tooltip should be hidden when another attachment URL is copied (in list mode)" Media 6.0 normal normal Awaiting Review defect (bug) new 2023-12-15T13:05:00Z 2024-03-12T15:39:27Z "In the media list view, clicking the ""Copy URL"" action link displays previously clicked ""Copy URL"". The previously clicked row showing ""Copied!"" when hover the media again.
=== Environment
- WordPress: 6.4.2
- PHP: 8.2.0
- Server: Apache/2.4.54 (Unix) OpenSSL/1.0.2u PHP/8.2.0 mod_wsgi/3.5 Python/2.7.18 mod_fastcgi/mod_fastcgi-SNAP-0910052141 mod_perl/2.0.11 Perl/v5.30.1
- Database: mysqli (Server: 5.7.39 / Client: 8.2.0)
- Browser: Firefox 119.0 (macOS)
- Theme: Twenty Twenty-Four 1.0
- MU-Plugins: None activated
- Plugins:
* WordPress Beta Tester 3.5.5
=== Steps to Reproduce
1. Go to media library
2. Click ""Copy URL"" of one of the media.
3. Click ""Copy URL"" of another media.
4. The previously clicked row showing ""Copied!"" when hover the media again.
=== Expected Results
1. The previously ""Copied!"" tooltip should be close after clicking the next one.
=== Actual Results
1. The previously clicked row showing ""Copied!"" when hover the media again." jayadevankbh
Untriaged tickets (that need a patch) 35887 Adding multiple media to post - selecting image size Media 4.4.2 normal normal Awaiting Review defect (bug) new 2016-02-20T12:03:10Z 2023-10-25T04:35:24Z "When clicking ""Add Media"" to add images to a post, you can select multiple images. With all images selected, logic follows that if you change the ""ATTACHMENT DISPLAY SETTINGS"" size from default ""Medium"" to ""Full Size"", that all selected images would have the same setting changed, but when you add them, only the one image that was highlighted is actually ""Full Size"" and the rest which were selected, but not highlighted, are still ""Medium"".
I think when adding multiple media, all should be changed to size that is selected in ""ATTACHMENT DISPLAY SETTINGS""." myburgh.bernard@…
Untriaged tickets (that need a patch) 52509 Error generating Thumbnails of PDF-Files Media 5.6.1 normal normal Awaiting Review defect (bug) new 2021-02-12T12:46:26Z 2023-07-02T13:37:05Z "This is a follow-up to #48853.
This issue seems to be still present in Version 5.6.1
Some PDF-Files cause an internal server error, some do not. (The server's error log tells something about missing headers)
Here's what i did to isolate the error:
- I examined the PDF-Files. The affected files had a PDF-Version 1.7 an were created with non-Adobe-Tools (e.g. Office365). PDFs with Version 1.4 and 1.5 (created with Acrobat) worked well.
- tried it with a local copy of the site on XAMPP: No Problems
- used a little code-snippet to prevent thumbnail-generation in general: Upload works
This is the snippet:
{{{#!php
'ids' ) );
foreach ( $posts as $post_id ) :
$thumb = get_the_post_thumbnail( $post_id );
endforeach;
}}}
The **update_post_thumbnail_cache()** used in **get_the_post_thumbnail()** assumes **$wp_query->posts** always contains an array of **$posts objects**, while it can be an array of $posts IDs.
To prevent the warning it would be appropriate to check that $post is actually a post object.
The patched code:
{{{#!php
posts as $post ) {
$post = get_post( $post ); // Add this or check if is_integer( $post )
$id = get_post_thumbnail_id( $post->ID );
}}}
Thanks
Kind Regards" Xendo
Untriaged tickets (that need a patch) 23436 Media Gallery - Cropping Image and then Cropping a thumbnail from that crop doesn't work. joedolson* Media 3.5 normal normal Awaiting Review defect (bug) accepted close 2013-02-10T17:20:00Z 2022-12-07T16:05:48Z "'''A recipe for repeating the bug behavior:'''
Navigate to Library in the admin sidebar.
Click ""Add new"".
Drag the 800x480 copy of this or any image to the drag and drop area:
http://en.wikipedia.org/wiki/File:Cheese_platter.jpg
(I suggest this image for ease of recipe duplication and best explanation.)
After the blue status bar has completed, ""Edit"" to bring the media edit window up in a new tab.
Click ""Edit Image"" below the actual image.
Drag anywhere inside the image to create a cropping box.
In the ""Image crop"" pane, set the crop area to 500px width, 100px height.
Drag the cropping box so that the fancy toothpick is as far left as possible along the horizontal axis of the cropping box, but centered vertically.
Click the ""Crop"" icon. Click ""Save"". Click ""Update"".
Click ""Edit Image"" once again.
Drag inside the newly-cropped image again to create a new cropping box.
In the ""Image Crop"" pane, change the cropping dimensions to 150 x 100.
Drag the box so the fancy toothpick is somewhere in the left third within the crop boundary.
'''Important:''' In the thumbnail settings pane, set ""Apply Settings to:"" '''Thumbnail'''.
Click the ""Crop"" icon. Click ""Save"". Click ""Update"".
Click ""Library"" in the admin sidebar.
The newly preferred thumbnail for our previously-cropped image does not save. Thumbnail remains default, based on center of previously-cropped image. Instead, you will see a small wheel of cheese sliced into six wedges with garnishes for the thumbnail, even though we chose the part with the fancy toothpick." gr33nman
Untriaged tickets (that need a patch) 40129 Media deleting selected on mobile does not work Media normal normal Awaiting Review defect (bug) new 2017-03-12T12:47:13Z 2017-03-16T19:42:35Z "Steps to reproduce:
- Select a month in bulk select.
- Click image.
- Click delete selected.
- It doesn't delete.
[[Image(https://cldup.com/IHq3IPurbV.PNG, 50%)]]
Discovered on iPhone 7 Plus." karmatosed
Untriaged tickets (that need a patch) 37311 Site icon thumbnails are lost if wp_generate_attachment_metadata called again later Media 4.5 normal normal Awaiting Review defect (bug) reopened 2016-07-07T22:36:48Z 2021-04-14T16:36:05Z "If image sizes are regenerated with the Regenerate Thumbnails plugin, the custom Site Icon sizes (and possibly other images in the customiser?) are lost.
The question is whether this is something that needs changing in the plugin, or whether the logic for how these sizes work should change in core. (Virtually all core documentation tells people to use this plugin when changing image sizes, so it should be fixed in one of the other).
I'm of the opinion it should be changed in core, where custom sizes like the ones created by Site Icons should be somehow marked as special sizes, with wp_generate_attachment_metadata checking for any existing custom sizes and including them in the output." smerriman
Untriaged tickets (that need a patch) 58740 Slow load in media page of WordPress admin when having huge posts table Media 6.2.2 normal minor Awaiting Review defect (bug) new 2023-07-06T15:53:15Z 2023-07-06T15:53:15Z "Slow load can be traced to this function.
{{{
// get_available_post_mime_types
// wp-includes/post.php
}}}
From what I understand, this function tries to get all of the available mime type of attachment post type. When posts are over a hundred thousand, this is causing media page in admin to load in about half a minute (hosting performance relative).
I'd like to suggest a transient in this function. Will open a PR if this bug is approved.
" Twellve_Million
Untriaged tickets (that need a patch) 58733 The load more button appears even when there is only one image in the feature image selection window. joedolson* Media 6.3 normal normal Awaiting Review defect (bug) accepted 2023-07-06T13:22:35Z 2023-07-21T15:20:00Z "Load more button appears in the popup window for replacing the feature image, even when there is only one image available.
Steps to reproduce the issue:
1. Go to the post editor in WordPress.
2. Locate the section where you can edit the feature image for the post.
3. Click on the ""Replace"" button to select a new image.
4. The popup window will open, showing the available images.
Despite there being only one image in the selection, the ""Load More"" button is present in the popup window.
Video Link: https://www.loom.com/share/c0e9faa4cc86455eb30bdaf2149b5a60
=== Environment
- WordPress: 6.3-beta3-56143
- PHP: 7.4.21
- Server: Apache/2.4.46 (Unix) OpenSSL/1.0.2u PHP/7.4.21 mod_wsgi/3.5 Python/2.7.13 mod_fastcgi/mod_fastcgi-SNAP-0910052141 mod_perl/2.0.11 Perl/v5.30.1
- Database: mysqli (Server: 5.7.34 / Client: mysqlnd 7.4.21)
- Browser: Chrome 114.0.0.0 (macOS)
- Theme: Twenty Twenty-Three 1.1
- MU-Plugins: None activated
- Plugins:
* WordPress Beta Tester 3.5.0" aparnajl
Untriaged tickets (that need a patch) 58944 Upload to Media Library not replicating to all pod's 6.2.2 Media 6.2.2 normal normal Awaiting Review defect (bug) new reporter-feedback 2023-07-31T10:18:52Z 2023-10-04T15:34:54Z "Hello, after updating from WP 6.1.1 to 6.2.2 the new uploaded images start to apear ""broken"" on Media Library. If we refresh the page several time's we will see the image ok, but if we refresh it again it will be broken. We are running the WP in kubernetes, so we have several pod's. This behaviour means the uploaded image is no longer been replicated to all pod's. So it only exist's in one pod.
After reverting to 6.1.1 all is ok." vitorgandra
Untriaged tickets (that need a patch) 30402 WordPress does not respect the bit-depth of the original image when resizing Media 3.9.2 normal normal Awaiting Review defect (bug) new 2014-11-19T08:15:02Z 2021-03-04T15:09:12Z "i have uploaded 8 bit depth indexed color png, near 1400x1800 size image in wordpress and inserted it into post , and original image was near 500 kB and the smaller width-height version made by wp is near 1400 kB, because it is 24 or 32 bits per pixel png.
(this is useless. i have edited html code to use full version because it is smaller by weight and it is scaled by size so it is ok)." qdinar
Untriaged tickets (that need a patch) 53200 image quality reduction in smaller images Media 5.7.2 normal normal Awaiting Review defect (bug) new 2021-05-13T13:01:43Z 2021-05-13T13:01:43Z "So what happens is you upload a full size image to wordpress in my case project53.co.uk and I am using a goodlayers theme but I have repeated the same process on a stoc install on a different site and have the same issue.
On this site for example the easiest one to see it on is the woman and look at the cheeks as full size looks ok and has colour and smaller images looks toned down and grey and it is wordpress changing the image quality with the smaller images.
this is the details send from our dev guy
For now - I have removed the thumbnails that the site was trying to use (I had set it to 'full', which should have been used, but the theme didn't want to co-operate) and then regenerated the thumbnails - pretty much forcing the site to use the full-size image.
It may occur elsewhere in the site - hard to say until I've seen every possible variation of an image on the theme - but as long as we repeat the same steps to remove the thumbnail size and regenerate, it will be fine.
You could just remove all regenerated sizes and ensure that sizes are set by the container the image is in; that would definitely stop it.
So if you see another image (or multiple images) having the same problem:
Inspect that image and see what thumbnail size it is using. (You can generally tell by the suffix on the end of the image name, e.g. blahblah-800x600.jpg)
Go into Goodlayers Options > Miscellaneous > Thumbnail sizing Remove the thumbnail size that it's using
Go into Tools > Regenerate Thumbnails
Ensure that the thumbnail size that you remove is not there
Click Advanced Options, and check the box which says ""Delete unselected thumbnails"" - this will remove that size from the server and tell WordPress it doesn't exist
If it was me - I'd unregister all of the thumbnails and just limit the size of images which are being uploaded - and use that size globally throughout the theme (if the size doesn't exist it should fallback to the full size image as default).
That doesn't necessarily have to be the case - but you just don't want 5MB images on a page - because then you'll have all the page speed problems to deal with!
" digitalmountain
Untriaged tickets (that need a patch) 46390 image_default_link_type is not seen by Gutenberg Media 5.1.1 normal normal Awaiting Review defect (bug) reopened 2019-03-01T12:34:42Z 2022-04-05T02:26:53Z "I have in option.php the image_default_link_type set to file so that by default the ""link to "" for all media files is by default set to media.
Since upgrading to Gutenberg 5.1, this feature appears to be deactive." brianjcameron
Untriaged tickets (that need a patch) 54205 jqxhr is undefined inside of deferred.done() when using wp.media to add a custom image upload Media 5.8.1 normal major Awaiting Review defect (bug) new 2021-09-30T20:55:42Z 2022-05-31T14:33:33Z "I have done all the usual trouble shooting and found this is being cause by a new block of code added to wp-util.js in 5.8.1. Specifically lines 121-134.
The jqXHR property does not exist inside of the done() object and therefor always errors out. This is removing a key functionality of a clients admin that makes it where no new products can be added without a horrible workaround." metawebdevelopment
Untriaged tickets (that need a patch) 43070 srcset attribute can be overridden but not prevented Media 4.4 normal normal Awaiting Review defect (bug) new 2018-01-11T19:07:48Z 2019-04-11T13:48:00Z In `wp_get_attachment_image()`, a `srcset` attribute can be passed to the fourth parameter to override the attribute's contents. There is no way to prevent this attribute from showing, though. An empty `srcset` attribute throws a validation error. desrosj
Untriaged tickets (that need a patch) 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 needs-unit-tests 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
Untriaged tickets (that need a patch) 53187 wp_filter_content_tags added too early Media 5.5 normal normal Awaiting Review defect (bug) new 2021-05-11T19:15:40Z 2021-07-26T16:31:46Z "Currently wp_filter_content_tags filter is added to the_content filters with default priority, this means that if the iframe is outputted by shortcode it will not get the lazy loading attribute.
I think that it should be added after do_shortcode has run with priority of 12." maciejmackowiak
Untriaged tickets (that need a patch) 32117 wp_get_attachment_metadata sizes array file misses path if using year/month organizing Media 4.2 normal normal Awaiting Review defect (bug) new 2015-04-24T15:58:51Z 2017-08-14T13:15:29Z "wp_get_attachment_metadata returns array like this:
{{{
[""metadata""]=>
array(5) {
[""width""]=>
int(3072)
[""height""]=>
int(2304)
[""file""]=>
string(25) ""2015/03/GC702D01_high.jpg""
[""sizes""]=>
array(4) {
[""thumbnail""]=>
array(4) {
[""file""]=>
string(25) ""GC702D01_high-200x150.jpg""
[""width""]=>
int(200)
[""height""]=>
int(150)
[""mime-type""]=>
string(10) ""image/jpeg""
}
}}}
as you can see, ""file"" in the first level of the array contains year and month (as i do have turned on organizing in year/month structure for uploads), but ""file"" in the second level for (e.g. in this case) the thumbnail size is only the file name, without the path.
This is at least confusing, make it difficult to get the URL of the file - each size need to be then requested separately by wp_get_attachment_image_src function.
IMO optimal solution would be to use full path in both `$metadata['file']` and `$metadata['sizes'][$size]['file']` so the same name would have the same structure. But i do not know if it wouldn't have some compatibility issues.
Less optimal imo would be to add there also the path - it can be there only once in the top level, as all sizes are currently always in the same folder, but i think this could lock us from possible changes / plugin modifications etc. E.g. I think that it would be great, if it would be possible (and even default) to have size name, as a folder, so that we would have thumbnails in uploads/thumbnail, medium size in uploads/medium ... - this would highly reduce the number of images in one folder in default settings and would reduce the problems with displaying them on most systems. And also if we would want to delete some defined size, we could simply delete one folder and save space.
So the second optimal would be to show the path in `sizes[$size]` subarray, e.g.
{{{
[""metadata""]=>
array(5) {
[""sizes""]=>
array(4) {
[""thumbnail""]=>
array(4) {
[""file""]=>
string(25) ""GC702D01_high-200x150.jpg""
[""path""]=>
string(25) ""2015/03/""
}
}}}" thomask
Untriaged tickets (that need a patch) 51421 wp_get_missing_image_subsizes returns thumbnail sizes for animated GIFs Media 5.5.1 normal normal Awaiting Review defect (bug) new 2020-09-30T14:27:32Z 2020-10-01T14:36:20Z "While thumbnails are not created for animated GIFs to avoid the problem of users picking a thumbnail size to insert into their content and unexpectedly getting a static image instead of an animated GIF, they are generated for static GIFs.
The `wp_get_missing_image_subsizes` function however recognizes animated GIFs as an image format that can have subsizes generated, and so returns a list of missing thumbnail sizes that will never be created.
This causes problems for various plugins when checking whether all required thumbnails exist before commencing processing the GIF etc." ianmjones
Untriaged tickets (that need a patch) 60178 wp_video_shortcode() outputs invalid HTML Media normal normal Awaiting Review defect (bug) new 2024-01-02T22:09:17Z 2024-02-15T07:25:42Z "Did an audit of a website and found several invalid HTML for video tags that were output with `wp_video_shortcode()`. The errors:
* Bad value `1` for attribute `loop` on element `video`
* Bad value `1` for attribute `autoplay` on element `video`
* Bad value `1` for attribute `muted` on element `video`
Based on documentation from Mozilla, all 3 are boolean attributes. Here is an example of function usage that produced the HTML validation errors:
{{{#!php
wp_get_attachment_url(9999),
'class' => 'my-custom-video',
'poster' => '',
'loop' => 'true',
'autoplay' => 'true',
'muted' => 'true',
'height' => 1080,
'width' => 1920
] );
}}}
This part in `wp_video_shortcode()` is the culprit:
{{{#!php
$v ) {
$attr_strings[] = $k . '=""' . esc_attr( $v ) . '""';
}
}}}
Currently, we are using the filter to clean up these attributes like this:
{{{#!php
' .
/* translators: %s: Asterisk symbol (*). */
sprintf( __( 'Required fields are marked %s' ), '*' ) .
'
' .
'
' . $item . '
';
}
}}}
The foreach loop that goes through all fields could easily check if any field has the ""required"" attribute and rather use that as a condition to show the message instead of `$item`." webzunft
Untriaged tickets (that need a patch) 36270 Allow filtering of the final HTML output of media related shortcodes Media 4.7.2 normal normal Awaiting Review enhancement new 2016-03-18T02:33:02Z 2020-04-09T09:00:28Z "Sometimes it is required to further process the final HTML output of the media related shortcodes, eg {{{caption}}} or {{{gallery}}}, so as to add extra HTML code such as enclosing div or span elements or just modify the existing HTML code during run time.
For instance the final output of {{{img_caption_shortcode}}} could be filtered:
https://core.trac.wordpress.org/browser/tags/4.4.2/src/wp-includes/media.php#L1537
Passing all relevant image attachment data, like ID and size, would also be very useful.
I hope that I am not missing anything but right now the only way to insert code inside the {{{
}}}
Wow! Say hello to invalid markup and rendering problems! Auto-closing of tags turned off. No matter of the settings I still get this nice messed up html. WYSIWYG turned off also." retrib
Future Releases 29913 wptexturize should handle broken HTML consistently Formatting 1.5 normal minor defect (bug) new needs-unit-tests 2014-10-10T00:38:40Z 2019-06-04T19:46:35Z "Spunoff from ticket:29557#comment:93 because it's not that important.
When encountering broken HTML, `wptexturize()` should match web browser behavior, without getting too complicated. This bug is for:
1. unclosed comments: `
Lorem Ipsum quam quasi mollitia
}}}
" Giorgio25b
Untriaged tickets (that need a patch) 56429 Gutenberg author box missing Editor 6.0.1 normal normal Awaiting Review defect (bug) new 2022-08-24T14:03:31Z 2022-11-05T22:30:57Z "There is a bug related to the author box missing when all of the following conditions are true:
- When there are more than 70 users in a WP installation
- When an Editor creates a post and saves it as a draft. This must be the only post of that user
- If all the users are ordered alphabetically, that user must be above 60 in the order
When this is true, if another Editor opens that draft, the author box won't be visible. There is an additional request that should fetch that user and it's returning error 403
If Administrator opens it, the author box is present
The cause for the bug is the last condition that fails here - https://github.com/WordPress/WordPress/blob/master/wp-includes/rest-api/endpoints/class-wp-rest-users-controller.php#L445 because the function checks for the author of the post" lgadzhev
Untriaged tickets (that need a patch) 53085 Gutenberg editor and Chrome stopped working after 5.7 Editor 5.7 normal blocker Awaiting Review defect (bug) new 2021-04-25T18:48:28Z 2021-05-04T21:24:51Z "I have a problem with Gutenberg since upgrading to the version above `5.7`, including `5.7.1`, which seems like a bug to me. If I refresh, sometimes it works, but usually not.
All plugins have been deactivated, including `/mu-plugins/`, and a shipped theme activated. Same issue in Google Chrome and Chrome Canary. **Safari works, but it takes several seconds for the UI to be clickable.**
Downgrading to `5.6` works, too, but this can't be the right solution.
Here is [the error log](https://paste.ee/p/NRCuh) that was logged when Gutenberg didn't react." thaikolja
Untriaged tickets (that need a patch) 53863 Gutenberg fails with wp 5.8 Editor 5.8 normal critical Awaiting Review defect (bug) new 2021-08-03T01:40:57Z 2021-08-03T07:38:03Z "I had to rollback to fix this. The WP 5.8 Gutenberg crashed with this info:
TypeError: Cannot read property '$el' of undefined
at new m (https://bestredlighttherapy.com/wp-includes/js/dist/media-utils.min.js?ver=5e105975fcfe18922cd4f0163466f454:2:3795)
at Yg (https://bestredlighttherapy.com/wp-includes/js/dist/vendor/react-dom.min.js?ver=16.13.1:68:243)
at rh (https://bestredlighttherapy.com/wp-includes/js/dist/vendor/react-dom.min.js?ver=16.13.1:98:274)
at zj (https://bestredlighttherapy.com/wp-includes/js/dist/vendor/react-dom.min.js?ver=16.13.1:228:490)
at Th (https://bestredlighttherapy.com/wp-includes/js/dist/vendor/react-dom.min.js?ver=16.13.1:152:223)
at tj (https://bestredlighttherapy.com/wp-includes/js/dist/vendor/react-dom.min.js?ver=16.13.1:152:152)
at Te (https://bestredlighttherapy.com/wp-includes/js/dist/vendor/react-dom.min.js?ver=16.13.1:146:151)
at https://bestredlighttherapy.com/wp-includes/js/dist/vendor/react-dom.min.js?ver=16.13.1:61:68
at unstable_runWithPriority (https://bestredlighttherapy.com/wp-includes/js/dist/vendor/react.min.js?ver=16.13.1:25:260)
at Da (https://bestredlighttherapy.com/wp-includes/js/dist/vendor/react-dom.min.js?ver=16.13.1:60:280)
I did turn off all plugins and switched to the default theme. Only rolling back the main version allowed me to get into Gutenberg." dogrescuer
Untriaged tickets (that need a patch) 51449 Image caption missing after saving in multisite with non super administrator account Editor 5.5.1 normal major Awaiting Review defect (bug) new 2020-10-05T08:21:56Z 2021-05-04T05:40:40Z "I created a new multisite environment and create a new post with a plugin classic editor activated. Edit using the Editor account, adding media, and add caption then save the post. Switch to the HTML tab and back to Visual tab, the caption will be gone.
I can confirm this of not happening just to me but also to my client which originally reported the issue." gochisiyan
Untriaged tickets (that need a patch) 31375 Image caption with heading adds an empty paragraph at page edits Editor 4.1 normal normal Awaiting Review defect (bug) new 2015-02-19T11:22:17Z 2020-11-24T06:11:30Z "Hi,
I'm experiencing a problem when trying to use heading tags within image captions. Upon inserting (or editing) the image on a page, I wrote a heading before a block of text in the caption. The whole thing would look something like this:
{{{
Heading here
A block of text directly following the heading.
}}}
What happens is that every time I edit the page in any way (not even touching the image or image caption) there is an extra empty paragraph added to the caption text. That means that anything below the caption jumps one line further down at every edit.
Just to see if this is some plugin conflict, I created a clean WordPress install without plugins, and tried the same thing. The problem was reproduced. Looking at the html code generated, there is a new added at every page edit, and sometimes a couple of are inserted before the heading tags. Here is a link to my test site:
[http://dev.webbkoncept.se/themetest/]
I tried it using both themes twenty fourteen and twenty fifteen, experiencing the same bug." sweman
Untriaged tickets (that need a patch) 54995 Impossible to type apostrophe in WP 5.9 + Twenty Twenty One theme Editor 5.9 normal normal Awaiting Review defect (bug) new reporter-feedback 2022-01-30T09:02:25Z 2022-06-17T06:51:40Z "Working from a Chromebook with US international keyboard, the usual keys for typing single apostrophe ' and double apostrophe "" do not work in the Gutenberg editor." nmschaller
Untriaged tickets (that need a patch) 59149 Inconsistent Behaviour of Block Editor while Adding/Searching for Blocks Editor 6.3 normal normal Awaiting Review defect (bug) new dev-feedback 2023-08-19T05:56:17Z 2023-09-02T06:32:59Z "WP Version 6.3
I'm facing an strange issue while searching the fields from the block editor.
When I'm at the end of page or when scroll to end of page then I'm trying to search a custom block it suddenly jump from its position. for details refer the below video url for same.
https://www.awesomescreenshot.com/video/20061317?key=12384a49ae5e729e95556d9498c1a107
" dhruval04
Untriaged tickets (that need a patch) 56519 Inner blocks serialization bug in serialize_block function Editor 5.3.1 normal normal Awaiting Review defect (bug) new 2022-09-06T08:41:24Z 2022-09-13T05:53:18Z "Hi,
The serialize_block function https://developer.wordpress.org/reference/functions/serialize_block/ fails when the number of inner blocks increases.
The following custom function solved it for me.
{{{#!php
with > within
tag Editor 5.0.2 normal major Awaiting Review defect (bug) new dev-feedback 2019-01-04T13:09:07Z 2020-01-14T19:07:58Z "Hi,
I just updated to WordPress 5 and started using the new block editor.
I typeset source code in my posts using a
tag. This code contains a > comparison operator. Upon saving my draft, > gets replaced with >, and this entity is also displayed in the article preview.
This happens even if I disable the visual editor.
The old editor does not present this bug and installing the Classic Editor extension allowed me to work around this." yannsalmon
Untriaged tickets (that need a patch) 55390 Not able to choose Color picker in customizer when the blocks are added in widget Editor 5.9.2 normal major Awaiting Review defect (bug) new 2022-03-15T13:21:58Z 2022-03-16T09:17:28Z "Hi Team,
I hope you are doing well and safe!
I would like to highlight an issue with the color picker in the customizer when using the blocks in widgets.
1. For choosing the custom color, whenever you click on the color selection, it will trigger a click event where it will ask you to leave the site or not?
Here is the screenshot: https://share.bsf.io/YEur81BW
2. The color selection palette is not properly displayed.
Here is the screenshot: https://share.bsf.io/wbuzJ0zq
Furthermore, I have gone ahead and found that this issue is coming from WordPress version 5.9.2
Also, I have demonstrated a video that would help you check it on your end too.
This issue is occurring on default themes as well as other famous themes as well.
Here is the screencast: https://share.bsf.io/yAuKoy2J
I would suggest you please check this on priority and release a patch for this issue, as users are facing lots of issues due to this.
Looking forward to your response." nileshc
Untriaged tickets (that need a patch) 48311 "Page removal in wp clean install ""The response is not a valid JSON response""" Editor 5.2.4 normal normal Awaiting Review defect (bug) new 2019-10-15T15:50:28Z 2019-11-11T22:29:49Z "Question to hosting provider support
bug launch conditions: Clean wp install today, basic Theme, no plugins.
Created test site can not be removed from editor - ""The response is not a valid JSON response"" response.""
The page can only be removed from wp pages overview.
Sorry for my talk awkwardness (i have no idea what is it about just forwarding)
Vladimir
extasica.com
bug report cause from hosting provider:
we found a bug in WordPress itself, when pressing the ""Remove"" button is sending a POST request to the webserver with JSON data, but they do not have the correct end. The data includes an EOF character (the end of the file - this should end the data), followed by another character - n (new line). Therefore, the JSON parser crashes in our Modsecurity application firewall and the application receives a ""The response is not a valid JSON response"" response.
Original Czech hosting provider text
""nalezli jsme chybu v samotné aplikaci WordPress, kdy po stisknutí tlačítka ""Odstranit"" je odeslání POST požadavek do webserveru s JSON daty, která však nemají správný konec. Součástí dat je znak EOF (konec souboru - tímto by měla data končit), za kterým ale následuje ještě další znak - n (nový řádek). Z toho důvodu JSON parser v našem aplikačním firewallu Modsecurity zhavaruje a aplikace obdrží odpověď ""The response is not a valid JSON response""." motmat
Untriaged tickets (that need a patch) 49443 Safari Browser - Component Color Picker not getting closed on Custom Color Picker button click Editor 5.4 normal normal Awaiting Review defect (bug) new 2020-02-15T13:05:58Z 2020-02-18T16:12:48Z "When I am trying to close color picker on the `**Custom color picker**` button click. It's not getting closed. It's working properly on **Chrome** browser but somehow not working on the **Safari** browser.
Here is a screencast :
Safari - https://share.getcloudapp.com/8LuJ49lP (Version-13.0.5)
Chrome - https://share.getcloudapp.com/Qwu762od (Version 80.0.3987.106)" monikarao
Untriaged tickets (that need a patch) 57316 Twenty Twenty-Three: Alignment issue in Button block Editor 6.1.1 normal normal Awaiting Review defect (bug) new 2022-12-12T07:31:19Z 2022-12-12T11:33:57Z "In Twenty Twenty-Three Theme, when we add Button block on the editor side and change the alignment of Button then the ""Align right"" is not reflected in the backend as well as frontend side.
Steps to replicate:
1: Activate the Twenty Twenty-Three Theme
2: Add Button block
3: Choose ""Align right"" from Align option
4: View the page/post at editor side
5: Save Page/Post
6: View the page/post at front side
For better understanding, I provide a video attachment link.
Video link: https://share.cleanshot.com/9VyrSCgD5fUNDgxYSJ1u
Thanks" kajalgohel
Untriaged tickets (that need a patch) 31751 Using PgDn and PgUp keyboard keys in the editor scrolls both post edit box and the whole viewport Editor 4.1.1 normal normal Awaiting Review defect (bug) new 2015-03-24T16:42:26Z 2020-11-24T06:13:57Z "The editor in WordPress 4.1 is great, and the whole sticky sidebar is a great improvement, but editing using Page Down and Page Up keys as part of the workflow is some of the most frustrating experience one can have because they control both the cursor in the post edit box and the page itself.
For example, if I go into a short post, put the cursor at the beginning of the post, and press Page Down, I'm going to end up with this: [[Image(http://i.imgur.com/CZr3FXQ.png)]]
At this point, I can only see a tiny sliver of the post because the page has scrolled too.
This is similar to #30919, except I'm not talking about the distraction-free mode, which I almost never use.
Windows 8.1 on Chrome 42 beta, but this behavior has been the same for as long as I can remember." archon810
Untriaged tickets (that need a patch) 59104 duotone is not applied to videos in the cover block in safari Editor 6.3 normal normal Awaiting Review defect (bug) new 2023-08-14T16:01:43Z 2023-08-22T20:49:58Z "Dear Team,
duotone (svg filter) is not applied to videos in cover block in safari (screenshot safari). In edge for example it works (screenshot ms edge).
I would be very happy about a solution.
Many greetings
Kiril" kiandept
Untriaged tickets (that need a patch) 44470 meta property=“og:image” doesn't register if an image is executed via a shortcode in WP Post and Pages Editor 4.9.6 normal critical Awaiting Review defect (bug) reopened dev-feedback 2018-06-27T03:28:41Z 2018-06-30T00:34:20Z "I want to try and explain a WordPress core issue and bug, in which I dont feel there is an available solution, at least I dont think after exhaustive research. I ran many many tests on fresh WP installations and twenty17 themes. And some may suggest this is a 3rd party plugin issue, while I am suggesting that it is both a Core and 3rd Party Plugin issue with the most widely used plugin in the world perhaps WPSEO. Applying shortcodes to WP post and Pages, of course it renders fine in the front-end, the output code that is. However, many recent updates to social media platforms Open Graph Protocols. The WPSEO plugin cannot understand that an image is being executed via php through a shortcode, unless the image is hard-coded directly into the WP page editor then it works fine. Problem is, no image executed from literally any 3rd party plugin shortcode contained within a wordpress post or page will execute the meta property=""og:image"" in the .... In short WordPress Core does not support opengraph functions or plugins when shortcodes are being used.
one of the last tests to try to continue to prove this is a WP core issue from their last several updates, that I am certainly of course trying to gain some attention on, that even an out of the box wordpress stock short codes like [gallery ids=""21""] to display images, cool enough that it displays visually in the post editor, still impossible to hook into the main property=og:image meta. Of course the other primary issue, no rhyme or reason either that a static front page cannot display the meta in the either by any know third party plugin or hard coded functions in the theme directory. Being that exhaustive testing has been done, without the modification of stock wordpress core files, continues to lead me to believe that this is a core issue again.
And after a lot of I intelligent research I believe wordpress next core update should fix this. Please read some other additional testing I have done on this issue as well. I am certainly trying to gain some attention to this issue because developers need to be able to execute php via shortcodes into wp post editors therefore execute images in a dynamic way via short codes and still be in compliance with al know third party plugins like yoasts og: settings and the social media platform og protocols. https://wordpress.stackexchange.com/questions/306973/property-ogimage-doesnt-register-with-including-a-php-file-as-a-shortcode-in" nlstm
Untriaged tickets (that need a patch) 56522 Add filter for wp_get_layout_style Editor 5.9 normal normal Awaiting Review enhancement assigned 2022-09-06T15:56:00Z 2023-02-09T21:27:59Z "Currently, there is no filter for the output of this function, which contains the layout styles associated with a given block. Having this be filterable seems conducive to clean overrides versus having a specificity battle with inlined styles (which in many cases would require `!important` to override), while allowing this to be a very intentional, opt-in feature.
I will be working on a patch for this which I'll add to the ticket once created. " 10upiansvo
Untriaged tickets (that need a patch) 60393 Test with Gutenberg active Editor normal normal Awaiting Review enhancement new 2024-01-31T03:53:44Z 2024-01-31T07:21:37Z "On the back of #60315, an issue that keeps occurring on some sites ([https://wordpress.slack.com/archives/C02QB8GMM/p1706630823300079 For example, wordpressfoundation.org earlier today]) is that WordPress trunk ends up being incompatible with the latest stable release of Gutenberg. Usually this happens around PHP back-porting from Gutenberg to Core, but I guess could happen with some of the JS too (I just don't see it).
Generally, WordPress trunk has been treated in the past as ""it should be stable"", and as a result, is run on many WordPress.org properties as a way to [https://en.wikipedia.org/wiki/Eating_your_own_dog_food dogfood] and find out about bugs before it hits every other WordPress site in the world. Over the years, this has identified many issues that wouldn't have otherwise been noticed until after release. Often these sites consume the SVN/Git repo's directly, and as such [https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/update-core.php#L1844 the upgrade routines] don't protect those sites.
I'd like to propose two changes to the unit tests in Core, as a way to hopefully notice these incompatibilities before it happens.
1. Run a unit test run with Gutenberg stable active (Similar to how we run multisite vs not-multisite, but we can probably slim it down to Gutenberg stable + Trunk + Single PHP version, just to reduce action time)
2. If it's a packages update, run all the tests with Gutenberg active (in addition to without)
For PRs such as the one that lead to the most recent issue, it'd have flagged that the commit would make trunk incompatible with the stable release, and either a) the core commit could've been delayed 12 hours, or b) the release of an updated Gutenberg could've been done first.
For other PRs/commits, it would highlight when a change in Core has caused Gutenberg to fatal or act oddly - Something that should be highly unlikely, but is plausible, and given how close Gutenberg and Core are, it just makes sense to me. This wouldn't replace the Gutenberg unit tests, but would act as a separate double-check." dd32
Future Releases 42540 Don't move focus to the editor when switching editor mode Editor normal normal Future Release defect (bug) new 2017-11-14T10:38:33Z 2019-01-10T17:31:15Z "Splitting this out from #42530.
When switching the classic editor from ""Text"" mode to ""Visual"" mode, the editor area is focused. Worth noting this is a TinyMCE behavior, not something WordPress does. For a number of years it always worked this way, with a few exceptions. For example, in 4.8.3 the editor is not focused for me, not sure if something changed in TinyMCE.
Regardless of what happened to TinyMCE, I'd propose to finally discuss this behavior and evaluate if it's a good one for all users. It was discussed sometimes in the past, as part of other issues, see for example #30490 but never fully addressed.
This issue is even more relevant now that #41962 is going to move focus to the editor in both Visual and Text mode, when there is a selection.
Moving focus programmatically is often problematic because it generally assumes just one, specific, workflow.
From an usability perspective, moving focus to the editor assumes users want to start typing immediately. This may or may not be true. It's an assumption.
From an accessibility perspective, unexpectedly switching context is a huge concern. See also the discussion on #42530.
Any thoughts and discussione welcome!" afercia
Future Releases 39574 Editor patterns: add empty headings/quotes Editor 4.3 normal normal Future Release defect (bug) new 2017-01-13T14:49:16Z 2019-07-18T06:46:04Z "Currently some patterns normally only work if there's other text after the leading character(s). I you type `## Test` and press enter, a new h2 element will be created. If you type `##` followed by zero or more spaces, no heading is added and the `##` stays ""normal"" text. I think this is and should be the intended behaviour, so no empty elements are created.
But if yout enter `## Test`, then move the cursor between `##` and Test followed by pressing enter, an empty heading will be created and the resulting html looks like this:
{{{
Test
}}}
Until switching to the text editor and back, you are not able to add text to the heading because it doesn't show up in visual mode.
When doing the same with `>`, it doesn't create an empty blockquote, but removes the leading char. The visual editor is then adding an additional line of whitespace, where you can't put your cursor in. This line disappears also after switching to text mode and back.
I've tested with WP 4.3 and 4.7.1.
" mahu2401
Future Releases 47900 "Error on update MCE Views in gutenberg block ""Classic Editor""" Editor 5.2.2 normal major Future Release defect (bug) new 2019-08-19T13:49:45Z 2020-12-29T00:00:27Z "By steps:
• Install new site on WordPress 5.2.2.
• Create new page.
• Add editor block ""Classic"".
• Add media gallery into classic editor with 2+ images.
• Open edit gallery window.
• Switch to another tab in the browser.
• Little wait...
• Back to tab with WordPress.
• Any change in ""edit gallery window"" and click ""Update gallery"".
• Gallery do not update and error in browser console.
Error in browser console:
{{{
wp-tinymce.js?ver=4940-20190515:3 Uncaught TypeError: Failed to execute 'setStart' on 'Range': parameter 1 is not of type 'Node'.
at wp-tinymce.js?ver=4940-20190515:3
at Object.map (wp-tinymce.js?ver=4940-20190515:3)
at Object.select (wp-tinymce.js?ver=4940-20190515:3)
at mce-view.min.js?ver=5.2.2:1
at Function.s.findKey (underscore.min.js?ver=1.8.3:1)
at Function.s.find.s.detect (underscore.min.js?ver=1.8.3:1)
at N.d.update (mce-view.min.js?ver=5.2.2:1)
at mce-view.min.js?ver=5.2.2:1
at N.d. (mce-view.min.js?ver=5.2.2:1)
at s (backbone.min.js?ver=1.2.3:1)
}}}
----
I think reason of problem in the following: after open ""edit gallery window"" gutenberg block updated, and after click ""Update gallery"" node for update (use in ""update"" function in mce-views) no longer in the document.
The problem is also observed in other plugins that use MCE Views for pretty view shortcodes." vjik
Future Releases 59270 Excerpts Not Showing Bold Text ... Editor 6.3 normal normal 6.6 defect (bug) new 2023-09-02T01:47:36Z 2024-02-17T14:26:45Z The text itself shows, but it does not show the bold attributes as it did up until 6.2.2. hmnvtn
Future Releases 36159 Inserting Image on iOS Doesn't Respect Cursor Position Editor 4.2 normal normal Future Release defect (bug) new 2016-03-07T16:18:59Z 2019-06-05T07:07:40Z "When using Press This as a launch pad to edit a longer blog post, additional images added are inserted at the top of the post, rather than in the space in which the cursor has been placed.
Here's a quick video displaying the issue. http://www.screencast.com/t/NtdCWRoJsWI
" mrjarbenne
Future Releases 29838 Post editing area: keyboard accessibility, tab order and focus joedolson* Editor 4.0 normal normal 6.6 defect (bug) accepted 2014-10-02T16:27:31Z 2024-02-20T12:42:59Z "This ticket aims to focus on a specific area of the UI, let's call it ""Post editing area"", the one that starts with the ""Title"" field and ends with the editor area, both in ""Visual"" and ""Text"" mode.
Related: #27553 while researching we noticed:
> '''joedolson''': outstanding issues surrounding tab order, but this are long-standing and not relevant to this specific patch and issue; that needs to be raised separately.
There's room for accessibility improvements here, especially when it comes to tab order and focus management. To fully understand what's going on you should stop for a while being a ""nervous clicker"" :) and:
- apply the patch from #27553
- unplug your mouse and disable your trackpad :)
- use just your keyboard
- tab around, both forwards and backwards
It would be great to test also switching off your display and using a screen reader, I would recommend Firefox and NVDA.
Two main issues:
Focus.
When you're in the ""Title"" field and then you tab forwards, focus is moved directly inside the editor area skipping all what's in between.
While this *may* be useful for sighted keyboard users (they save a few key presses, say 1 second?), it's a very critical experience for screen reader users: when they tab forwards, they get that right after the title there's the editor. But when they tab backwards, they get many more elements that ""weren't there before"". [https://core.trac.wordpress.org/ticket/27553#comment:17 more details on 27553 comments].
Tab order.
The ""tabbing experience"" in Visual and Text mode should match as much as possible. Ideally, there should be a better [http://www.w3.org/WAI/GL/2014/WD-WCAG20-TECHS-20140902/G59 logical sequence in the markup]. When editing the title, the next logical step is editing the content, all the other controls (Add Media button, additional buttons provided by plugins and themes, etc.) should not be placed between the Title and the editor. The CEUX project proposed something similar at some point.
There is ongoing research and development on the editing experience, see for example Editor Focus/DFW in #29806 and the idea to review relevant parts of the UI, see [https://make.wordpress.org/core/2014/10/01/agenda-for-october-1st-dev-chat/#comment-19392 explore moving the Publish | Save | Preview buttons out of the metabox, etc.] so it would be a great opportunity to explore this ticket too." afercia
Future Releases 47554 Post history Editor 5.1.1 normal major Future Release defect (bug) new dev-feedback 2019-06-18T10:11:49Z 2020-11-24T04:07:38Z "Hello everybody.
This ""bug"" might be a timeout issue or might have something to do with the server times, but it could be fixed from software side, as far as I see it. It also might be a Gutenberg issue, but its look like it is from the core.
Classic:
- User A opens the post and write some content.
- User B also opens the same post an clicks on take over.
- User A gets pop up with info about the take over and can go to ""all posts""
Problem (Version 5.1.1):
1. Popup for user comes to late -> content not saved
2. Popup doesn't appear -> user saves post which will be override from user B's content.
Solution:
1. auto save e.g. every 10 seconds
2. History besides the post, e.g. on the very right column.
History contains lets say the last 5 or 10 (configurable) versions of the post.
Users can see a diff or can restore the whole last version of the entry.
- History doesn't contains versions of auto save (only last auto save)
--- User-Agent Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Iridium/2018.11 Safari/537.36 Chrome/71.0.0.0
" d3n15
Future Releases 50653 Remove the _doing_it_wrong from WP_Block_Patterns_Registry::unregister() Editor 5.5 normal normal Future Release defect (bug) new dev-feedback 2020-07-13T21:51:41Z 2020-07-26T01:50:07Z "There's a `_doing_it_wrong()` call inside `WP_Block_Patterns_Registry::unregister()` when you try to unregister a block pattern that doesn't exist.
IMO this is incorrect usage of `_doing_it_wrong()` because the function hasn't been incorrectly called, it's just been called with invalid data.
----
In addition, the `register()` and `unregister()` functions in this class ought to be returning a `WP_Error` instead of boolean `false`. Should we improve this for 5.5?" johnbillion
Future Releases 55803 Span is removed from title due page saving Editor 5.9.3 normal normal Future Release defect (bug) new 2022-05-24T12:31:54Z 2023-02-24T22:49:50Z "Hello,
since the update to wordpress 5.9 we detected some strange behavior, when editing existing posts, that contains HTML-Tags in their post title.
The problem is, when editing the post, the HTML-Tags in the post title, are not displayed in the editor. The tags are just cutted out from the title. This problem have only editor group, admin group is ok with saving span in title.
Steps to reproduce:
1. Create a new post with HTML-Tags in the title for example: ""This is my title""
2. Save and publish the post with this title
3. Go back to the ""All posts"" list
4. Post is correctly displayed with ""This is my title"" in the list
5. Edit the post
6. post title lost the -Tags
7. Change the post title to ""This is my title 2""
8. Save the post
9. -Tags are totally gone, even in the ""All posts"" list." joyster
Future Releases 43564 TinyMCE bookmark not removed Editor 4.9.4 normal normal Future Release defect (bug) new 2018-03-16T00:57:23Z 2020-02-07T15:40:05Z "If cursor is placed between in text mode each time I switch from Text to Visual mode what i guess (from editor.js code) is bookmark is added and not removed, it just keeps stacking with each change.
code that appears between tags is:
{{{
<span data-mce-type=""bookmark"" style=""display: inline-block; width: 0px; overflow: hidden; line-height: 0;"" class=""mce_SELRES_start""></span>
}}}
Here is example to replicate bug:
{{{
}}}
Note: If possible, please use valid key and query, i had to remove them for demonstration, but bug happens even with this code.
Paste that code in Text mode, click between >< of "">"" and switch to Visual mode, then switch back to Text mode (do not click anywhere in Visual mode). Every time this is repeated, it just keeps adding mentioned code.
My humble guess is that this is happening because Visual is generating map preview from iframe tag so it can not detect that same place in code when it is switched back to Text mode." waterlord93
Future Releases 49293 When trying to add an existing post category to a post - simply check the box of this category Editor 4.8 low minor Future Release defect (bug) new 2020-01-26T12:24:41Z 2020-01-28T16:50:55Z "What happens now:
When writing a new post and trying to add a new category for this post, if this category already exists - nothing really happens.
What should happen:
If this category already exists - simply check the box of this category. " shayatik
Future Releases 37577 "Allow users to ""petition"" for a post lock to be released" Editor normal normal Future Release enhancement new dev-feedback 2016-08-04T21:23:34Z 2020-05-25T17:12:05Z "Our post locking prevents two people from editing the same post, but introduces some awkwardness, in that your options are to wait and hope they exit the post (which slows you down), or boot them out (which could be rude or disruptive), or communicate with them through some other medium (which you might not have). It would be nice if there was a third option... to ""raise your hand"" about wanting to edit the post. If the editing user is actually working on the post, they could say ""not now,"" or they could ""save and release"". Or, if there is no response, that could be communicated to the petitioning user, as that could indicate that the editing user has left the post open and abandoned their computer. We could even communicate when the last mouse movement or on-page activity was." markjaquith
Future Releases 25471 Allow wp_link_dialogue to open in contexts outside of the editor Editor 3.6.1 normal normal Future Release enhancement new 2013-10-02T22:35:38Z 2019-06-05T07:08:55Z "I use wp_link_dialogue within metaboxes to provide a nicer way for users to enter URL's. Its handy for say slideshows, or profiles that point to external sites.
wp_link_dialogue works perfectly on pages where an editor instance exists, but on pages that don't have editor instances it fails due to wplink.js looking for the global wpActiveEditor var, which of course doesn't exist as there is no editor. Aside from the js error, invoking the dialogue on pages with no editor involves calling _WP_Editors::wp_link_dialog(); directly to output the required html which isn't ideal, or calling wp_editor and using css to hide it, which just seems lame.
Ideally wp_link_dialogue should function independently of the editor.
Approaches
1. Amend wplink.js to allow wpActiveEditor to be undefined and pass in a seperate value for textfield to the open method. Con is that wp_link_dialog() still has to be invoked with a call to _WP_Editors::wp_link_dialog()
2. Move wp_link_dialog into a seperate class, amend _WP_Editors to call this class and allow for a user defined textfield within wplink.js
" we_tell
Future Releases 40629 Change default template Editor 4.7.4 normal normal Future Release enhancement new 2017-05-02T06:17:50Z 2020-11-23T05:58:04Z "I recently required to change the default template of theme to another template. The site is already working since 3 months and now client wants to change the default template to the sidebar template while publishing new pages.
There is no such action or filter available for it.
I am trying to add filter for it but if anyone have other suggestions, please let me know." pratikgandhi
Future Releases 34681 "Consider removing the ""Disable the visual editor when writing"" option" Editor normal normal Future Release enhancement new 2015-11-14T14:41:57Z 2019-01-08T09:51:38Z Is anyone even uses it? considering the lack of love the text editor gets I truly hope that the answer is no. mark-k
Future Releases 59017 Duotone not working in 6.3 Editor 6.3 normal normal Future Release enhancement new 2023-08-09T07:35:24Z 2023-10-03T20:49:01Z "When the WordPress Accessibility Day website updated to 6.3 today the duotone filters we have set on images stopped working. Rolling core back to 6.2.2 solves this problem.
#58994 references changes to duotone in 6.3, however, bugs still exist.
Here's an example page on a site running 6.3 where duotone is no longer working: https://2023.wpaccessibility.day/about/organizers/. " alh0319
Future Releases 26988 Need a Button to Cancel/Revert Page/Post Edits in Progress Editor 3.8 normal normal Future Release enhancement new 2014-02-01T22:21:17Z 2021-02-10T14:29:28Z "Currently, if you start editing a page or a post and change your mind, there is no way to easily revert those changes and it leads to a lot of confusion as as if you leave the page and come back, it will tell you that there is an auto save version. Sending to Trash makes no sense because it trashes your whole page. This is VERY confusing and user unfriendly, especially for new users of WP.
There should be a ""revert"" or ""cancel"" button when editing that will get rid of current edits and take you back to the last, unedited version of the page/post." tomdryan
Future Releases 36778 Parent theme editor-style.css cannot be disabled Editor normal normal Future Release enhancement reopened 2016-05-06T16:58:34Z 2020-11-23T04:48:13Z "While it is possible to override the CSS in a parent theme's editor-style.css, it is not currently possible to completely disable or dequeue a parent theme's editor-style.css file.
This is a problem for a few reasons:
- Theme authors may not keep their editor-style.css files up to date with the HTML the editor produces, leading to formatting oddities.
- You may not just want the editor styles customized from the WP defaults at all." matthewmcvickar
Future Releases 50191 Propose https prefix, not http for external links Editor normal normal Future Release enhancement new 2020-05-17T10:28:11Z 2022-09-11T17:52:10Z "In https://build.trac.wordpress.org/browser/trunk/wp-includes/class-wp-editor.php?marks=1269#L1269
The text says: The URL you entered seems to be an external link. Do you want to add the required http:// prefix?
Might be better to propose to prefix 'https://' as default." casiepa
Future Releases 6619 permalink field misleading in page editor: it displays the erroneous values Editor 2.5 normal normal Future Release enhancement new 2008-04-06T14:48:15Z 2021-09-22T13:30:43Z "if you create a sub-page, the permalink field should display the proper permalink.
currently, if you have:
site.com/page/
and when you create:
site.com/page/subpage/
the permalink shows:
site.com/subpage/
until it gets saved
the expected behavior would be for it to show the correct permalink.
the same remark applies when you then change the permalink. if the parent is no longer page, but rather page-2, then the permalink should update accordingly." Denis-de-Bernardy
Future Releases 34188 Post lockdown Editor 4.3.1 normal normal defect (bug) new 2015-10-07T10:46:43Z 2019-06-04T19:32:44Z "Assume having two users.
First user clicks on edit post and then edits and updates the post (e.g: Test Post). After updating the post the first user straight away logs out from admin area.
Now, second user logs in to admin area and navigates to the post area. The post updated by the first user (Test post) shows ""First user is currently editing the post"" notification and is in a lockdown state.
" danish.iqbal
Future Releases 27148 comments in page code converted to displayed text upon submission Editor 3.8 normal normal defect (bug) new 2014-02-18T18:02:15Z 2019-06-04T19:25:09Z "When editing a WP page in code/text view,
comments inserted with """" display correctly (not shown) in the visual view,
but when posted (submit or preview) get parsed to ""<!-- comment -->"" and are displayed publicly." wchapin
Untriaged tickets (that need a patch) 52220 Weekly archives/week 53 incorrect crossing over a year change Rarst* Date/Time 5.6 normal normal Awaiting Review defect (bug) accepted needs-unit-tests 2021-01-04T19:50:24Z 2021-01-05T20:28:24Z "I run a site that publishes items every single day, and I regularly make use of its weekly archives.
The relevant dates here(via https://www.epochconverter.com/weeks/2020) are:
2020 week 52 is Dec 21 – Dec 27
2020 week 53 is Dec 28 – Jan 3
2021 week 1 is Jan 4 – Jan 10
Instead, my weekly archives come out as:
2020 week 52 is Dec 21 – Dec 27
2020 week 53 is Dec 28 – **Dec 31**
2021 week 1 is Jan 4 – [ongoing]
[I can provide live URLs for these, just wasn't sure if self-linking was frowned upon.]
There's three days in there that just…don't exist(in the archives; there ''are'' published entries).
It's kind of a pain to find much information on weekly archives in the first place since they're not all that common in actual use and the search terms are broad but I'm currently trying to find someplace else that publishes often enough I can try feeding it a query string to see what happens.
This replicates for previous year changes, ie. 2020 week 1 is Dec 30, 2019–Jan 5, 2020 but the archive just starts at Jan 1 instead.
Also replicates with all plugins disabled and using Twenty Twenty-One." sugeneris
Untriaged tickets (that need a patch) 48740 Add constant for database date format Date/Time normal normal Awaiting Review enhancement new dev-feedback 2019-11-20T13:08:57Z 2019-11-20T14:18:36Z "A lot of core Date/Time code is dealing with `Y-m-d H:i:s` format, as stored for posts and other objects in database.
This is effectively a so-called ""magic"" string, which is not self-explanatory and prone to user error if typed by hand (I messed up `i` with `m` for minutes more than once probably).
Since there is no upstream PHP constant for this format, I suggest we introduce one in core and use it in place of magic string:
{{{#!php
define( 'WP_DATE_MYSQL', 'Y-m-d H:i:s' );
}}}
Not absolutely sure about the name, I used `DATE_MYSQL` as class constant before, but `WP_DATE_DATABASE` might be more appropriately generic. To my knowledge there isn't a specific ISO or RFC designation for such format.
If there is agreement on the need and the name I'll work on a patch for replacement and switch from strings in core." Rarst
Untriaged tickets (that need a patch) 28988 Detect Time Zones automatically at installation Date/Time normal normal Awaiting Review enhancement new dev-feedback 2014-07-22T19:19:50Z 2021-05-05T19:04:34Z "Currently, upon installing WordPress, one of the steps I always take is to go to Settings > General > Timezone to manually set my time zone. I've been using Wordpress for eight years, so I know to do it and how to do it, and it's just a minor inconvenience. However, I have seen people new to this platform be confused and/or not know how to change this.
Is it technologically possible to use a geolocation service to query the IP address of the computer installing Wordpress and automatically set that service's best guess as to time zone, perhaps during the setup process?
I would envision the UI option remaining in settings, in case, for example, a developer in one time zone builds a site for a client in another. But automatic detection would be perfect for the average new user. It would be one more element that just works out of the box for those who aren't particularly tech savvy.
I did some searching in Trac to see if I could find a similar ticket and couldn't find any." danielmount
Untriaged tickets (that need a patch) 48935 Need to Remove strtotime() usage from core Date/Time 6.2 normal normal Awaiting Review enhancement new needs-unit-tests 2019-12-11T12:58:07Z 2023-04-06T10:38:43Z "`strtotime()` is routinely used in core for processing timezone-ambiguous input. Since it is affected by default PHP time zone setting (set by core to UTC on boot) it is also vulnerable to this setting being changed by third party code.
Related change of `date()` to `gmdate()` in 5.3 release caused some new issues, because in some places while changing default time zone broke things combination of `strtotime()` and `date()` meant things got broken ''by the same amount'' and outputs were ""correct"" (ignoring the fact they would be implied in absolutely different time zone from intended).
Dropping use of `strtotime()` in favor of date parsing with explicit time zone handling (such as `DateTimeImmutable` objects) is logical next step to make core insensitive to PHP time zone context." Rarst
Untriaged tickets (that need a patch) 48936 Remove mysql2date() usage from core Date/Time normal normal Awaiting Review enhancement new needs-unit-tests 2019-12-11T13:04:27Z 2023-02-24T15:20:34Z "`mysql2date()` was originally meant from processing times as stored by WP in database.
Unfortunately its design is very limited because both time zone of input and output is ambiguous. It is interchangeably used for local and UTC times.
As implementation detail that meant that it would produce incorrect output for formats including time zones for local time inputs. Time zone would happen be UTC from WP core setting PHP time zone to UTC on load.
In 5.3 release this behavior was flipped to produce correct local time output for local time input, as considerably more common. Accordingly now ''UTC'' input produces incorrect output for formats with time zone.
While the function is common and familiar, it is hardly irreplaceable and its design is so limited it seems to be unsalvageable.
I propose we move towards eliminating its use in core and eventually formally deprecating it." Rarst
Future Releases 34435 Creating a post might fail during fall's DST switch due to ambiguous time Date/Time normal normal Future Release defect (bug) new needs-docs 2015-10-25T00:53:55Z 2019-05-30T06:24:04Z "When I use `wp_insert_post()` to create a post when `timezone_tz` is `Europe/London` [https://github.com/danielbachhuber/year-ago-today/blob/master/year-ago-today.php#L25-L32 ref], the post gets scheduled for the future.
`$post_date` is established here: https://core.trac.wordpress.org/browser/tags/4.3/src/wp-includes/post.php#L3272
Because `$post_date_gmt` isn't supplied, it's set here: https://core.trac.wordpress.org/browser/tags/4.3/src/wp-includes/post.php#L3292
However, `get_gmt_from_date()` returns the same value as its supplied, when it should return an hour less (as Europe/London respects DST). `gmdate()` returns the proper GMT date (one hour less) so the post gets forced to `future` [https://core.trac.wordpress.org/browser/tags/4.3/src/wp-includes/post.php#L3310 ref]
Here's debug of `get_gmt_from_date()`:
{{{
format( $format ) . PHP_EOL;
// 2015-10-25 01:23:08
$datetime->setTimezone( new DateTimeZone( 'UTC' ) );
echo $datetime->format( $format ) . PHP_EOL;
// 2015-10-25 01:23:08, but should be 2015-10-25 00:23:08
}}}
Is this a bug in PHP, or how we're using `DateTime`? Tested on PHP 5.6.14, 5.5.9, and 5.5.27" danielbachhuber
Future Releases 41011 get_calendar generates query with invalid date formats Date/Time normal normal Future Release defect (bug) new 2017-06-12T13:51:12Z 2020-09-22T05:31:12Z "Given a parameter like `?w=1400`, which is obviously not a week number, `get_calendar` will try to compute the date 9799 days into the year. It would make sense to check that `$w` is in a valid range, such as not greater than 53.
At the same time, `get_calendar` does not check that `$m` is a valid date, resulting in `$thisyear == '0'` and a query of `SELECT DATE_FORMAT((DATE_ADD('00101', INTERVAL 9799 DAY) ), '%m')`." andy
Untriaged tickets (that need a patch) 60503 MySQL VALUES function deprecated in MySQL 8 Database normal normal Awaiting Review defect (bug) new 2024-02-12T12:19:23Z 2024-02-12T22:19:14Z "e.g. for add_option SQL query (but issue happens in other places too, but not many)
{{{#!php
""INSERT INTO `$wpdb->options` (`option_name`, `option_value`, `autoload`) VALUES (%s, %s, %s) ON DUPLICATE KEY UPDATE `option_name` = VALUES(`option_name`), `option_value` = VALUES(`option_value`), `autoload` = VALUES(`autoload`)""
}}}
we get the SQL logs spammed with:
>'VALUES function' is deprecated and will be removed in a future release. Please use an alias (INSERT INTO ... VALUES (...) AS alias) and replace VALUES(col) in the ON DUPLICATE KEY UPDATE clause with alias.col instead
Since WP 6.4 minimum SQL is 8+, so this deprecated syntax isn't necessary anymore, since the new syntax is supported in all supported SQL versions.
This should have been fixed in WP 6.4, but at least now with WP 6.5 release, as it's easy to fix and avoid having a performance penalty from the deprecation notice handling/reporting.
" kkmuffme
Untriaged tickets (that need a patch) 51486 The add_option function should not be able to update existing rows in the database. Database 2.9 normal normal Awaiting Review defect (bug) new needs-unit-tests 2020-10-09T01:12:29Z 2022-06-09T12:18:11Z "In certain edge cases, `add_option` is able to update existing option values. This should not be possible. If SQL is executed which instructs ""Insert XYZ"" into database, then the insert should fail if the key already exists in the database, unless the SQL specifies that an UPDATE should happen.
The `add_option` function does check first to see if an option exists before attempting to add it to the database. In the overwhelming majority of cases, this works fine because when the option exists the function will return early before attempting to insert into the database.
However, consider a scenario where an object cache is being used. And further consider that the object cache may report incorrectly. If the object cache tells `add_option` that the value doesn't exist in the database (but in reality it does!), then `add_option` continues on and attempts to insert the supposedly new option.
In that particular circumstance, the SQL query, shown below, is executed which will insert the new row. And in the event that the option already exists, it will be overwritten.
The issue here is that `add_option` shouldn't be able to update the existing value. The query should fail. Why is the `ON DUPLICATE KEY UPDATE` clause included here?
{{{#!php
query(
$wpdb->prepare(
""INSERT INTO `$wpdb->options` (`option_name`, `option_value`, `autoload`)
VALUES (%s, %s, %s)
ON DUPLICATE KEY UPDATE
`option_name` = VALUES(`option_name`),
`option_value` = VALUES(`option_value`),
`autoload` = VALUES(`autoload`)
"",
$option,
$serialized_value,
$autoload
)
);
}}}
I realize this is an edge case. If the object cache being used gives bad information to `add_option` then really its the object caching plugin at fault. However, I can't understand a possible circumstance where `add_option` should ever UPDATE an existing option. The SQL here should not include `ON DUPLICATE KEY UPDATE`. Am I missing something? Is there a good reason for that clause? What would happen if that clause were removed?" khag7
Untriaged tickets (that need a patch) 46565 Mixed engine in tables, could bring to major WP failure! Also there is a small fix that could avoid that. Database 4.9.8 normal normal Awaiting Review enhancement new 2019-03-19T18:49:44Z 2019-03-20T07:40:01Z "''First of all ... after MySQL decided to make InnoDB the default engine ... many of us have mixed database with both InnoDB and MyisAM labeled tables.
If a plugin add a new table now (it happened to us with both WPML and Woocommerce) the new table will be mostly InnoDB but old table could be MyIsAM.
That can bring to JOIN failures, that in our case made us lost primary key or foreign key links, but will definitely cause also tables **permanent locks** (due to plugin/software crash), and that took finally to the main problem:
**data (rows) inserted with ID = 0**
THAT alone should be advertised a lot around plugin developers, that should check if their plugin tables are equal to the current-default-engine and if they are not, they should:
""alter TABLENAME engine = current-default-engine"".''
**Straight to the point:**
Data with ID = 0 actually can make crash WordPress because of this:
wp-includes/post.php:4867
Please note that this code will make WordPress go into a recursive infinite loop (causing ""fatal error memory exhausted"") if the ID = 0.
I know that ID = 0 is an abnormal situation, but believe me, if having locked tables makes this happen, you want to add a handbreak to that.
**This is a small fix, but you surely can do better:**
{{{
// Start the search by looking at immediate children.
if ( isset( $children[ $page_id ] ) ) {
// Always start at the end of the stack in order to preserve original `$pages` order.
$to_look = array_reverse( $children[ $page_id ] );
while ( $to_look ) {
$p = array_pop( $to_look );
if (!array_key_exists($p->ID,$pidx)) {
$pidx[$p->ID]=true;
$page_list[] = $p;
if ( isset( $children[ $p->ID ] ) ) {
foreach ( array_reverse( $children[ $p->ID ] ) as $child ) {
// Append to the `$to_look` stack to descend the tree.
$to_look[] = $child;
}
}
}
}
}
}}}
" Nokao
Untriaged tickets (that need a patch) 54669 Remove ONLY_FULL_GROUP_BY from incompatible wpdb modes Database 3.9 normal normal Awaiting Review enhancement new needs-unit-tests 2021-12-20T12:56:22Z 2022-06-15T20:52:56Z "as GROUP BY is non-deterministic otherwise, ONLY_FULL_GROUP_BY ensures this is not the case.
which is why this is enabled by default since MySQL 8
I guess it was disabled originally, as some queries would have to be updated in WP core.
I think however, this should be done now, as otherwise we're accumulating more and more technical debt." malthert
Untriaged tickets (that need a patch) 41054 Use sargable date filtering where possible Database normal normal Awaiting Review enhancement new 2017-06-15T07:54:13Z 2017-06-15T12:13:22Z "Currently, many queries generated by WP use post_date in a non-sargable fashion, namely by filtering based on the output of a MySQL function taking post_date as a parameter.
These can be easily rewritten to use the index on post_date without, to my eyes, breaking anything to boost performance.
Here's an example:
{{{
MariaDB [blog]> EXPLAIN SELECT * FROM blog.wp_posts WHERE YEAR(post_date) = 2017;
+------+-------------+----------+------+---------------+------+---------+------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+----------+------+---------------+------+---------+------+------+-------------+
| 1 | SIMPLE | wp_posts | ALL | NULL | NULL | NULL | NULL | 2684 | Using where |
+------+-------------+----------+------+---------------+------+---------+------+------+-------------+
}}}
vs
{{{
MariaDB [blog]> EXPLAIN SELECT * FROM blog.wp_posts WHERE post_date >= ""2017-01-01"" AND post_date < ""2018-01-01"";
+------+-------------+----------+-------+---------------+-----------+---------+------+------+-----------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+------+-------------+----------+-------+---------------+-----------+---------+------+------+-----------------------+
| 1 | SIMPLE | wp_posts | range | post_date | post_date | 8 | NULL | 262 | Using index condition |
+------+-------------+----------+-------+---------------+-----------+---------+------+------+-----------------------+
}}}
This optimization can be applied to any comparison between post_date and an already known parameter (from query_var). The only time it wouldn't be possible would be when comparing a portion of the date of two different posts (e.g. WHERE MONTH(x.post_date) == MONTH(y.post_date))
It's not much, but it's something. " ComputerGuru
Future Releases 60037 Differentiate between minimum required MySQL and MariaDB versions Database normal normal Future Release defect (bug) new 2023-12-08T14:13:08Z 2024-02-16T23:23:14Z "Currently, there is only [https://core.trac.wordpress.org/browser/tags/6.4.1/src/wp-includes/version.php#L47 one minimum required version defined] and checked against for database software when determining if a server is capable of installing and running WordPress. It's currently set at `5.0`, though that will hopefully be updated to `5.5` in WordPress 6.5 (see #60036).
This has worked over the past 12+ years without issue, even though WordPress supports running either MySQL or MariaDB. This is due to the fact that MariaDB versions previously followed MySQL's numbering scheme with each release representing a fully-functional drop-in replacement.
However, in 2012 this changed when MariaDB jumped from version `5.5` to `10.0`, where they have continued to increment from (the current LTS version is `10.11`, and current short term support version is `11.2`).
In the near future when support for any version of MariaDB > 5.5 is dropped, this check will become useless, because MySQL 5.7, 8.0, 8.1, etc. will always be lower than 10.0, 10.11, 11.0, etc.
An additional angle to this problem is [https://make.wordpress.org/core/2023/04/19/status-update-on-the-sqlite-project/ a recent proposal to add support for SQLite]. The most recent version of that software is `3.44.2`. SQLite is not a drop-in replacement in the same way MariaDB is. But with that and other challenges to adding support aside, no versions of SQLite would work in WordPress today (even with the minimum currently set at `5.0`).
The relevant code should be updated to ensure that the correct minimum version for the current database type is used when checking a server is properly equipped to run WordPress.
Follow up to #60036." desrosj
Future Releases 52496 Improve MySQL 8.0 support Database 5.4 normal normal Future Release defect (bug) new 2021-02-11T07:11:12Z 2024-02-05T20:45:49Z "While setting up the GH Action for the WP Importer plugin which runs the plugin integration tests (using the WP Core test framework) against various PHP/MySQL/WP combinations, I noticed a number of PHP/MySQL 8.0 combinations which error out during the running of the WP Core test bootstrap with errors which seem to indicate underlying incompatibilities with MySQL 8.0.
Relevant files in the Importer plugin setting up the test environment:
* https://github.com/WordPress/wordpress-importer/blob/master/phpunit/install.sh
* https://github.com/WordPress/wordpress-importer/blob/master/phpunit/bootstrap.php
Test run showing the errors: https://github.com/WordPress/wordpress-importer/actions/runs/556887133
== Errors reported:
PHP 5.6 / MySQL 8.0 / WP 5.5 and latest (5.6)
(Error line numbers are based on latest)
{{{
PHP Warning: mysqli_real_connect(): Server sent charset (255) unknown to the client. Please, report to the developers in /tmp/wordpress/wp-includes/wp-db.php on line 1653
PHP Warning: mysqli_real_connect(): (HY000/2054): Server sent charset unknown to the client. Please, report to the developers in /tmp/wordpress/wp-includes/wp-db.php on line 1653
PHP Warning: mysql_connect(): Server sent charset (255) unknown to the client. Please, report to the developers in /tmp/wordpress/wp-includes/wp-db.php on line 1685
PHP Warning: mysql_connect(): Server sent charset unknown to the client. Please, report to the developers in /tmp/wordpress/wp-includes/wp-db.php on line 1685
}}}
PHP 7.0 - 7.3 / MySQL 8.0 / WP latest (5.6)
{{{
PHP Warning: mysqli_real_connect(): The server requested authentication method unknown to the client [caching_sha2_password] in /tmp/wordpress/wp-includes/wp-db.php on line 1653
PHP Warning: mysqli_real_connect(): (HY000/2054): The server requested authentication method unknown to the client in /tmp/wordpress/wp-includes/wp-db.php on line 1653
}}}
**Note:** ''**with the exact same setup, the PHP 7.4/8.0 - MySQL 8.0 - WP 5.6 test runs will pass.**''
== Investigating needed
I haven't dug into the code. Reporting it here for further investigation.
I imagine that either the PHP/MySQL version check could be adjusted to indicate that MySQL 8.0 is only supported when running on PHP 7.4 or higher.
Alternatively, the underlying issues will need to be solved.
I also wonder if the WP Core tests in CI are being run against enough PHP/MySQL combinations, as I would imagine that these issues could have been discovered earlier if the above problem combinations would haved been used in WP Core CI.
Related: #49344 #51740" jrf
Future Releases 46947 ‘❤’ in Comment Generates DB Error Database 5.1.1 normal normal Future Release defect (bug) new reporter-feedback 2019-04-16T13:02:03Z 2019-04-17T11:51:53Z "I got the following error message notice when a post comment included the ‘’ special character.
When I approved the comment, there was no further error message generated.
I have not seen this message before – but then again, we rarely get special character in comments.
I am using WordPress 5.1.1. The WP-config: ‘define(‘DB_CHARSET’, ‘utf8′);’
Can someone please advise how to fix this?
Regards and thanks,
Angus
Error message:
*** [Thu Mar 21 02:17:57.574584 2019] [php7:notice] [pid 24789] [client 68.40.22.245:41759] WordPress database error Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8mb4_unicode_ci,COERCIBLE) for operation ‘=’ for query SELECT comment_ID FROM xxxcomments WHERE comment_post_ID = 134978 AND comment_parent = ‘0’ AND comment_approved != ‘trash’ AND ( comment_author = ‘Rhonda Lott’ AND comment_author_email = ‘xxx@yahoo.com’ ) AND comment_content = ‘Amen And Amen! Thank you Rabbi!\xe2\x9d\xa4\xf0\x9f\x94\xa5\xf0\x9f\x92\xaf\xf0\x9f\x99\x8c’ LIMIT 1 made by wp_handle_comment_submission, wp_new_comment, wp_allow_comment, referer: https://www.hiskingdomprophecy.com/its-time-to-unearth-the-truth/ ***" HisKingdomProphecy
Future Releases 38760 Capture result size in bytes when SAVEQUERIES is true Database normal normal Future Release enhancement new 2016-11-11T19:49:44Z 2017-10-03T10:06:01Z Inside of `WP_DB::_do_query()`, it would be neat if `$this->result` was measured as size in bytes, so debugging tools had a better sense of how much data was running over the network. danielbachhuber
Future Releases 41424 "Use a better error message than ""Error establishing a database connection"" when site isn't found" Database 4.9 normal normal Future Release enhancement new needs-unit-tests 2017-07-24T14:24:44Z 2017-11-22T08:58:59Z "In multisite, if this query returns no results, the database connection error is triggered:
SELECT blog_id FROM wp_blogs WHERE domain IN ( 'example.com' ) AND path IN ( '/' ) ORDER BY blog_id ASC LIMIT 1
I think the error should not mention database connection but allude to the fact that the site was not found.
For my use case, I had migrated a production database into QA and didn't update the domain to be qa.example.com so the connection failed.
I hope this is helpful. I'm not sure I know what the exact solution is but I thought the connection attempt had failed, when in fact the connection had been made but the data was not as expected. Also, the failure was not found in debug.log." tthorp
Future Releases 32868 Consider running utf8mb4 conversion on each database update Database normal normal defect (bug) new 2015-07-03T03:27:55Z 2019-06-04T19:30:29Z "As mentioned in #32127 and elsewhere, we should run the utf8 -> utf8mb4 conversion on each db update.
The main reason is that the server environment could change between updates.
For example, if someone upgrades MySQL between 4.3 and 4.4's release, at present they'll update to 4.4 and still not have utf8mb4 support, even though WordPress will now be able to support it." dd32
Future Releases 28139 WP MU legacy problems: missing database tables Database 3.0 normal normal defect (bug) new 2014-05-05T19:15:30Z 2019-06-04T19:25:36Z "Helo there.
We have found that WordPress Multisite sites updated from former WordPress MU are not working as expected. There are some missing tables that give problems with some plugins. The lack of tables doesn't allow you to access to the network configuration either.
=== '''Steps to reproduce''' ===
1. Install WP MU 2.9.2 (last WP MU release - works as expected)
2. Update to WP 3.0 or directly to WP 3.9. (tested in 3.0, 3.0 and then 3.9, and 3.9 directly)
3. Try to access /wp-admin/network.php.
You will have the message `The Network creation panel is not for WordPress MU networks.`, which is odd in a WP 3.9 Multisite.
4. Look for the source of the message in wp-admin/network.php
{{{
if ( ! defined( 'MULTISITE' ) )
wp_die( __( 'The Network creation panel is not for WordPress MU networks.' ) );
}}}
5. Add `define ('MULTISITE', true);` to wp-config.php. You will need to repair the database.
6. Add `define('WP_ALLOW_REPAIR', true);` and proceed to repair the database. Assuming a `testing` database, you will get this message:
{{{
wp_posts: Table 'testing.wp_posts' doesn't exist
wp_comments: Table 'testing.wp_comments' doesn't exist
wp_links: Table 'testing.wp_links' doesn't exist
wp_options: Table 'testing.wp_options' doesn't exist
wp_postmeta: Table 'testing.wp_postmeta' doesn't exist
wp_terms: Table 'testing.wp_terms' doesn't exist
wp_term_taxonomy: Table 'testing.wp_term_taxonomy' doesn't exist
wp_term_relationships: Table 'testing.wp_term_relationships' doesn't exist
wp_commentmeta: Table 'testing.wp_commentmeta' doesn't exist
}}}
=== '''Problems found''' ===
1. The lack of the `wp_options` table is especially problematic with plugins (Jetpack is unable to work with its new multisite option - thanks kraftbj for the help)
2. The message assumes `wp_links` as a needed table
" bi0xid
Future Releases 28591 dbDelta Non-literal DEFAULT not working (CURRENT_TIMESTAMP) Database normal normal defect (bug) new 2014-06-19T19:38:03Z 2019-06-04T19:25:59Z "Using dbDelta and any internal SQL values like CURRENT_TIMESTAMP won't work because dbDelta matches based on this regex:
{{{
""| DEFAULT '(.*?)'|i""
}}}
The block current looks like this:
{{{
if (preg_match(""| DEFAULT '(.*?)'|i"", $cfields[strtolower($tablefield->Field)], $matches)) {
$default_value = $matches[1];
if ($tablefield->Default != $default_value) {
// Add a query to change the column's default value
$cqueries[] = ""ALTER TABLE {$table} ALTER COLUMN {$tablefield->Field} SET DEFAULT '{$default_value}'"";
$for_update[$table.'.'.$tablefield->Field] = ""Changed default value of {$table}.{$tablefield->Field} from {$tablefield->Default} to {$default_value}"";
}
}
}}}
I'm not sure what the best solution is for this, but perhaps it should be:
1. Check if there is a default to change, if there is -- store default alter query, don't add to $cqueries[] yet
2. Check if there is a field type change OR a default non-literal found, if there is -- use this CHANGE COLUMN query instead of the 'default' changing query in point 1
Does that sound like a good solution here?" sc0ttkclark
Future Releases 35109 Add Online DDL support to dbDelta Database normal normal enhancement new needs-unit-tests 2015-12-15T22:24:20Z 2019-06-04T19:33:19Z "Since MySQL 5.1, a bunch of table level operations can be done in an asynchronous manner.
We can add support for this by adding `ALGORITHM=INPLACE` to the `ALTER TABLE` query, but the fun part is that this algorithm isn't supported for all types of operations.
So, we have a couple of options:
* Keep an array of what operations can be done online in each MySQL and MariaDB version, which will need to be updated for each new version of MySQL.
* Try all `ALTER` queries with the algorithm flag, then catch any SQL errors and fall back to the old style if needed. This will need careful testing with old versions of MySQL, particularly.
https://dev.mysql.com/doc/refman/5.7/en/innodb-create-index-overview.html" pento
Future Releases 10883 db-error.php not used for all DB failures Database 2.8.4 normal normal enhancement assigned 2009-10-01T02:45:28Z 2023-12-07T13:19:54Z "db-error.php (the optional custom DB error message file to be placed in wp-content) does not get included all the time. Sometimes wp-db.php will use its {{{bail()}}} method to spit out its own message. This code needs to be there too:
{{{
if ( file_exists( WP_CONTENT_DIR . '/db-error.php' ) ) {
require_once( WP_CONTENT_DIR . '/db-error.php' );
die();
}
}}}" markjaquith
Future Releases 29938 mysqli_query and multiple resultsets Database 3.9 normal normal enhancement new needs-unit-tests 2014-10-12T10:24:20Z 2019-06-04T19:26:52Z "The WordPress Database API does not expose a way to work with multiple resultsets.
Multiple resultsets are returned by queries that have several sets of results available and this is often the case with stored procedures and the usual way is to call {{{next_result}}} and {{{use/store_result}}} on the mysqli connection, however the connection is abstracted away behind the undocumented {{{$wpdb->dbh}}} field.
{{{
-- Test procedure for out of sync mysqli commands
DROP PROCEDURE IF EXISTS `mysqli_procedure_test`;
DELIMITER ;;
CREATE PROCEDURE `mysqli_procedure_test`()
BEGIN
SELECT * FROM `wp_posts` LIMIT 1;
SELECT * FROM `wp_posts` LIMIT 1;
END;;
DELIMITER ;
}}}
When calling this procedure (apart from the issues outlined in ticket #28155) you can only access the first resultset using the documented APIs. To fetch the second one one would have to use the mysqli API directly.
Need to come up with additional public methods to work with these via the Database API instead. There must be a way for a user to fetch the next resultset if there's one, or make this transparent somehow, perhaps using a {{{$wpdb->call( $procedure, $arguments )}}} invocation in the case of procedures? And something like {{{$wpdb->next_results}}} for everything else?
Needs brainstorming." soulseekah
Untriaged tickets (that need a patch) 45669 Theme Default Suggested Header Image Not display Customize 5.0.1 normal normal Awaiting Review defect (bug) new reporter-feedback 2018-12-17T08:03:45Z 2019-11-09T09:15:31Z "
After Theme Setup, changes on default we select default image will not save after the publish of suggested image in customize section in every them i tested please resolve this bug." deepaksk45
Untriaged tickets (that need a patch) 43122 customize.php fails to load with default changeset_uuid bpayton Customize 4.7 normal normal Awaiting Review defect (bug) assigned reporter-feedback 2018-01-18T00:46:13Z 2021-05-30T17:26:42Z "I am seeing a rare condition where users are unable to load the Customizer with no specified changeset and see the message ""Cheatin, uh? This changeset cannot be further modified.""
In all cases, I am seeing two `customize_changeset` posts with the same GUID post name, one with draft status and the other with published status. When WP_Customize_Manager attempts to find a changeset to load by default, it finds the draft with the GUID, and when it attempts to load the post, it finds the published post with the same GUID and dies with the message mentioned above.
I read WP_Customizer and theorized how this could be happening but have no theory worth mentioning. Still, this seems like some kind of race condition." bpayton
Future Releases 53529 Block based widget admin screen causes a NS_ERROR_FAILURE error in Firefox Customize 5.8 normal major Future Release defect (bug) reopened 2021-06-27T16:30:56Z 2022-06-07T09:48:43Z "On the new widget screen the following error occurs in Firefox 89.0.2 in the console, when loading the page:
{{{
Uncaught
Exception { name: ""NS_ERROR_FAILURE"", message: """", result: 2147500037, filename: ""http://wpbeta.localhost/wp-admin/widgets.php?legacy-widget-p…gacy-widget-preview%5Binstance%5D%5Braw%5D%5Bnav_menu%5D=181"", lineNumber: 14, columnNumber: 0, data: null, stack: ""t.supports[o[r]]<@http://wpbeta.localhost/wp-admin/widgets.php?legacy-widget-preview%5BidBase%5D=nav_menu&legacy-widget-preview%5Binstance%5D%5Bencoded%5D=YToxOntzOjg6Im5hdl9tZW51IjtpOjE4MTt9&legacy-widget-preview%5Binstance%5D%5Bhash%5D=2421412fbc986f068f1a768eb85295f7&legacy-widget-preview%5Binstance%5D%5Braw%5D%5Bnav_menu%5D=181:14:628\n@http://wpbeta.localhost/wp-admin/widgets.php?legacy-widget-preview%5BidBase%5D=nav_menu&legacy-widget-preview%5Binstance%5D%5Bencoded%5D=YToxOntzOjg6Im5hdl9tZW51IjtpOjE4MTt9&legacy-widget-preview%5Binstance%5D%5Bhash%5D=2421412fbc986f068f1a768eb85295f7&legacy-widget-preview%5Binstance%5D%5Braw%5D%5Bnav_menu%5D=181:14:1102\n@http://wpbeta.localhost/wp-admin/widgets.php?legacy-widget-preview%5BidBase%5D=nav_menu&legacy-widget-preview%5Binstance%5D%5Bencoded%5D=YToxOntzOjg6Im5hdl9tZW51IjtpOjE4MTt9&legacy-widget-preview%5Binstance%5D%5Bhash%5D=2421412fbc986f068f1a768eb85295f7&legacy-widget-preview%5Binstance%5D%5Braw%5D%5Bnav_menu%5D=181:14:1779\n"" }
widgets.php:14
t.supports[o[r]]< http://wpbeta.localhost/wp-admin/widgets.php?legacy-widget-preview[idBase]=nav_menu&legacy-widget-preview[instance][encoded]=YToxOntzOjg6Im5hdl9tZW51IjtpOjE4MTt9&legacy-widget-preview[instance][hash]=2421412fbc986f068f1a768eb85295f7&legacy-widget-preview[instance][raw][nav_menu]=181:14
http://wpbeta.localhost/wp-admin/widgets.php?legacy-widget-preview[idBase]=nav_menu&legacy-widget-preview[instance][encoded]=YToxOntzOjg6Im5hdl9tZW51IjtpOjE4MTt9&legacy-widget-preview[instance][hash]=2421412fbc986f068f1a768eb85295f7&legacy-widget-preview[instance][raw][nav_menu]=181:14
http://wpbeta.localhost/wp-admin/widgets.php?legacy-widget-preview[idBase]=nav_menu&legacy-widget-preview[instance][encoded]=YToxOntzOjg6Im5hdl9tZW51IjtpOjE4MTt9&legacy-widget-preview[instance][hash]=2421412fbc986f068f1a768eb85295f7&legacy-widget-preview[instance][raw][nav_menu]=181:14
}}}
Tested this in WordPress 5.8-beta4-51244. It seems to be related to the use of a canvas element in an iframe. Also see https://bugzilla.mozilla.org/show_bug.cgi?id=941146.
This errors does not occur in other browsers.
" walterebert
Future Releases 49421 Cannot use conversion specifications in `theme mod` default values Customize 5.3 normal normal Future Release defect (bug) new 2020-02-12T17:50:26Z 2021-09-26T03:07:44Z "This is a follow-up to #34290.
With the fix [46395] it is no longer possible to have a `theme_mod` which is itself a format string and has a default value which includes a conversion specification, e.g.
{{{#!php
\printf(
\get_theme_mod('site_copyright', 'Copyright %%1$s; all rights reserved.'),
\get_bloginfo('name', 'display')
);
}}}
With a double `%%`, the default string is now unchanged, but with a single `%` it is replaced with the ‘template directory’ URL. It is now no longer possible to achieve the desired `%1$s` in the default string.
Also, where the default is something like `100%`, the code supplying the default value to `get_theme_mod` now needs to test the WordPress version to know whether it should pass `100%` or `100%%`.
A fix might be for the `sprintf` code path also to be followed if the string contains a double `%%`. Or revert the change (so that the behaviour of `get_theme_mod` is more clearly defined as it was before - i.e. the default value is a format string and literal `%` signs need escaping as `%%`) and find another solution to the initial problem.
" jqz
Future Releases 39891 Chrome rendering issue with Customizer, widgets, and checked radios Customize normal normal Future Release defect (bug) new dev-feedback 2017-02-16T16:38:59Z 2021-05-29T16:56:54Z "Steps to reproduce:
- Open up Chrome (at least on Mac, have not tested on PC)
- Open up the Customizer
- Edit any sidebar
- Add any widget '''that contains at least one radio field that is checked'''
- Reduce the height of the browser window until a vertical scrollbar appears in the pane
Once the vertical scrollbar appears, the entire pane vanishes.
Upon further investigation, it appears to be Chrome ""max-width paint"" type issue. Basically, the checked radio element sets a `text-indent` of `-9999px` on the `:before` item to hide the browser rendered checkmark. It seems that this expands the width of the painted area very very far to the left (outside the visible window). I say this because if you mess around with the indent by lowering it, eventually the bug disappears. You can even see the right side of the painted area vanish (screencast attached showing this below).
Here's some CSS changes I tried that fixed it:
- Lower the text-indent to something higher (as in smaller negative number) than about `-8000px`
- Set the `.widget` element position to `static`
(previously set to `relative`)
Here's some screencasts:
Detailing how to create the bug:
[[Image(http://d.pr/i/WEil+)]]
Example showing why I think it's some sort of ""max paint width"" rendering issue:
[[Image(http://d.pr/i/gLzq+)]]
Example showing how setting the `position` on the `.widget` item to `static` fixes things:
[[Image(http://d.pr/i/4P9a+)]]" joelworsham
Future Releases 51093 Custom CSS output runs through the wrong filter for custom user role Customize 5.4.1 normal normal Future Release defect (bug) new 2020-08-21T12:15:08Z 2020-10-26T21:14:31Z "I added a custom user role, which is able to see the Custom CSS in the Customizer. As soon as a user with such a role publishes the Customizer settings, the Custom CSS gets filtered through the wrong filter. This wasn’t the case in WordPress < 5.5 and is a new issue.
My created user role:
{{{#!php
false,
'update_plugins' => false,
'update_themes' => false,
'activate_plugins' => false,
'edit_plugins' => false,
'edit_themes' => false,
'delete_plugins' => false,
'delete_themes' => false,
'switch_themes' => false,
'create_users' => false,
'edit_users' => false,
'delete_users' => true,
'edit_files' => true,
'edit_theme_options' => true,
'export' => false,
'import' => true,
'list_users' => true,
'manage_options' => true,
'remove_users' => true,
'edit_dashboard' => true,
'customize' => true,
'unfiltered_html' => true,
'delete_others_pages' => true,
'delete_others_posts' => true,
'delete_pages' => true,
'delete_posts' => true,
'delete_private_pages' => true,
'delete_private_posts' => true,
'delete_published_pages' => true,
'delete_published_posts' => true,
'edit_others_pages' => true,
'edit_others_posts' => true,
'edit_pages' => true,
'edit_posts' => true,
'edit_private_pages' => true,
'edit_private_posts' => true,
'edit_published_pages' => true,
'edit_published_posts' => true,
'manage_categories' => true,
'moderate_comments' => true,
'publish_pages' => true,
'publish_posts' => true,
'read' => true,
'read_private_pages' => true,
'read_private_posts' => true,
'upload_files' => true,
'copy_posts' => true,
)
);
}
add_action( 'init', 'add_custom_role' );
}}}
Tested CSS:
{{{
body > a {
color: #fff;
}
}}}
Actually CSS output:
{{{
body <
a {
color: #fff;
}
}}}
The data is stored correctly in the database, so it doesn’t seem to be a problem during the save function but rather during the output.
Tested with WordPress 5.5 and Twenty Seventeen theme." kittmedia
Future Releases 39475 Customize doesn't consider the hash in the URL after change Customize 3.4 normal normal Future Release defect (bug) new 2017-01-05T03:42:15Z 2021-05-24T03:03:41Z "When I open a page that has a hash in the URL, in the Customize, the behavior wasn't the expected. At least for me. The preview Iframe is loaded in the first time with the hash. But after a setting update, using the refresh transport, the hash disappear.
Customizer URL
/wp-admin/customize.php?url=http%3A%2F%2Flocalhost%3A8080%2F%23hide-entry-screen
First preview Iframe href
/?customize_changeset_uuid=e041a773-41df-4fcb-a800-01fa3249233d&customize_theme=senplo&customize_messenger_channel=preview-0#hide-entry-screen
Second preview Iframe href (after a change)
/?customize_changeset_uuid=e041a773-41df-4fcb-a800-01fa3249233d&customize_theme=senplo&customize_messenger_channel=preview-1
I debugged the customize JS scripts and saw that in the line 796 of the wp-includes/js/customize-preview.js file is set the frame URL. It come from api.settings.url.self value. I cannot identify where this value is the.
In a quick test, I concatenated the hash with the URL and the second Iframe was loaded with it." edpittol
Future Releases 40272 Customize: Account for media queries in l10n.css Customize normal normal Future Release defect (bug) new 2017-03-27T07:48:03Z 2017-10-03T17:00:48Z "Noticed while working on #40271 / #40152.
`wp-admin/css/l10n.css` contains some locale-specific CSS adjustments, some of them for the customizer. For example:
{{{
.locale-de-de #customize-header-actions .button {
padding: 0 5px 1px; /* default 0 10px 1px */
}
}}}
Now, that default is correct — as long as you are not using the Customizer on a smaller device. There, the default padding is `6px 14px`, not `0 10px 1px`.
On an iPhone 6, that de_DE specific CSS looks like this:
[[Image(https://cldup.com/8Zl2SQwmIT.png)]]
As you can see, there's a clear lack of top and bottom padding." swissspidy
Future Releases 39913 Customize: Disable auto-trashing of published changesets in anticipation of revisions Customize 4.7 normal normal Future Release defect (bug) new 2017-02-18T22:29:08Z 2021-05-29T17:10:47Z "When changesets were introduced in 4.7 (via #30937), we decided by default to auto-trash a `customize_changeset` post upon publishing. The reason for this is that there was no UI for changesets and there would be no way to clean up old revisions from the UI, meaning the posts would just be added indefinitely. However, with revisions being planned for 4.8 being planned for in #31089 and #21666, it would perhaps be beneficial to disable the auto-trashing behavior so that once revisions support ''is'' added the revision history won't be empty.
Nevertheless, even with changesets not being auto-trashed, there would still be [https://core.trac.wordpress.org/ticket/21666#comment:33 challenges] with reverting to a previously-published changeset:
> == Challenges of Reverting to a Previously-published Changeset ==
>
> Reverting to a revision of a changeset is easier than reverting to a previously-published changeset. When reverting to a revision of the current changeset, all this means basically is to reset the settings to match the state of the changeset at that revision. However, reverting to a previously-published changeset is more complicated/interesting. Take this changelog:
>
> 1. January 1st: User changes site title to “Foo”.
> 2. January 2nd: User changes site tagline.
> 3. January 3rd: User changes site title to “Bar”.
>
> Now, if the user clicks the changeset revision for January 1st, my assumption is that this will restore the site title of “Foo”. However, will it also include a revert of the change made to the tagline on January 2nd? Each changeset only contains the settings that were modified, so as it stands right now we would not know what to revert the tagline to since it's previous value is not captured. Whenever a changeset is about to be published, we could capture the current value for each setting prior to saving. This would allow us to roll back all of the changes made to the site between two published changesets. The process would involve walking over the previous changesets to gather up a list of the previous values and merge them and apply them to the current changeset for previewing.
>
> Complication: What about when a user makes a change to the tagline ''outside'' of the customizer? In that case the tagline would not be referenced in any changeset, and reverting to the changeset on the 1st would only rollback the site title. Would this be expected behavior?" westonruter
Future Releases 29040 Customizer: Header Image not Updating when using static front page Customize 3.9 normal normal Future Release defect (bug) reopened 2014-07-27T15:56:39Z 2019-11-29T21:07:37Z "Using WordPress 4.0 Beta 2. Steps to reproduce:
only happens if theme has default header image
(with twenty fourteen)
- Open Customizer
- Open Header image section
- Click on previously uploaded, theme default, or new uploaded image
- current header updates in customizer controls and preview
- changing header image activates the save and publish button, but after pressing it and closing customizer the header image is not changed
- when returning to the customizer the newly uploaded image is not present, however it does appear in the media library
- after switching themes and the switching back all images do show up
(in another theme which has several default images and no header text)
- Open Customizer
- Open Header image section
- Click on previously uploaded, theme default, or new uploaded image
- current header updates in customizer controls
- customizer preview does not update image, even after triggering a preview refresh with another control
- changing header image activates the save and publish button, but after pressing it and closing customizer the header image is not changed
Tried on Google Chrome and Safari on both Windows and Mac
Is not always reproducible with every theme, inconsistent results." zhalsey
Future Releases 22037 Customizer: Live preview fetches page but does not display (show error message) Customize 3.4.2 normal normal Future Release defect (bug) new 2012-09-28T15:14:54Z 2021-05-22T18:03:28Z "I just set-up a plain installation of 3.4.2. Configured it for multisite use. Set-up two sites, both working fine.
When going into a sites Appearance settings to customize the theme (TwentyEleven), the Customizer shows the control panel on the left, but the preview remains blank.
Firebug shows no Javascript errors.
'''It also shows, that a POST request is sent to fetch the front page and that the page is actually returned in the response. It appears the response is just not added to the right-hand preview area.'''
----
Per duplicate #28227:
> When Customizer can't load due to an error, there's no indication as to what's going on. It would be nice if some information was presented instead of seeing a blank screen on the right side." marcoliverteschke
Future Releases 32667 Customizer: autofocus should load as soon as the panel/section/control is active Customize 4.3 normal normal Future Release defect (bug) new 2015-06-17T06:06:18Z 2020-11-29T16:34:19Z Currently, autofocusing waits until the preview loads fully, which can take quite a while on a lot of pages and themes. Widgets need to wait for this to determine whether they should be activated, but for most other sections, we should be able to autofocus as soon as the Customizer controls finish loading. For menus, this would shave seconds off of the percieved loading time of the Customizer. See https://make.wordpress.org/flow/2015/06/14/menus-in-the-admin-and-the-customizer-ux-flow-performance-comparisons/. celloexpressions
Future Releases 36442 Customizer: when setting header image and site logo, also create a 2x image if possible Customize 3.9 normal normal Future Release defect (bug) new 2016-04-07T15:46:44Z 2017-01-24T18:49:45Z Currently after cropping an image for a header image or site logo, we make only smaller sizes images with the same ratio. These sizes are used (automatically) in srcset. We also need to make a 2x size for use on high density displays, if the original image is large enough. azaozz
Future Releases 54443 "Database Error Breaks ""custom_css_post_id"" Theme Mod" Customize 4.7 normal normal Future Release defect (bug) new 2021-11-15T11:41:06Z 2023-05-18T09:27:08Z "We have now seen this issue on a couple of WordPress installations and it is rare but it happens.
When MySQL falls over during a page load (for RAM issues or whatever) the request on line 1863 of **/wp-includes/theme.php** ...
{{{#!php
ID : -1 );
}}}
... this results in the **custom_css_post_id** theme mod being set to -1 and all the Additional CSS is seemed to be wiped out from the Customizer.
At this point the content of the post with post_type set as custom_css in the database has to be copied back into ""Customizer - Additional CSS"".
Here is an example of a PHP error around the time that this happened ... please note that we have seen it happen on completely different themes and most recently on the latest version of WordPress (yesterday) ...
{{{
[24-Feb-2021 20:46:45 UTC] WordPress database error Server shutdown in progress for query SELECT * FROM wp_posts WHERE ID = 2213700 LIMIT 1 made by require('wp-blog-header.php'), require_once('wp-includes/template-loader.php'), include('/plugins/wp-property-feed/templates/archive-wppf_property.php'), get_header, locate_template, load_template, require_once('/themes/twentyseventeen/header.php'), wp_head, do_action('wp_head'), WP_Hook->do_action, WP_Hook->apply_filters, wp_custom_css_cb, wp_get_custom_css, wp_get_custom_css_post, get_post, WP_Post::get_instance
}}}
To fix this issue from re-occuring I think that **set_theme_mod** on line 1877 is replaced with ...
{{{#!php
ID );
}
}}}
... so that the theme mod cannot be broken and CSS cannot be lost when the database has a blip.
What do you think?
Oliver" domainsupport
Future Releases 57170 Fix invalid menu-item-parent Customize normal normal Future Release defect (bug) new reporter-feedback 2022-11-21T23:16:13Z 2024-02-05T20:37:38Z "Follow up to #56926.
There seems to be a bug in the Customizer that may set `$menu_item->menu_item_parent` to be the same as `$menu_item->ID`. Steps to reproduce: https://core.trac.wordpress.org/ticket/56926#comment:21. There also seems to be a related JS error:
{{{
Uncaught TypeError: parentControl is undefined
.../wp-admin/js/customize-nav-menus.js?ver=6.2-alpha-54642-src:2330
}}}
" azaozz
Future Releases 42533 New pages scheduled via Customizer viewable as admin, 404 as visitor Customize 4.9 normal normal Future Release defect (bug) new 2017-11-13T15:12:36Z 2021-05-29T18:38:36Z "'''I'm not 100% if this is a bug, but here's the issue I am seeing:'''
If I add a new page via the Customizer and schedule the changes for 5 minutes in the future:
* As an admin viewing the '''Share Preview Link''', I can view the new page.
* As a visitor viewing the '''Share Preview Link''', I get a 404 when trying to access the new page.
----
I posted a Google Doc with steps to reproduce and screenshots here:
https://docs.google.com/document/d/1tiTjWjlUnVGNDaUZjFWmyg1BFRz6nF7tCTO-jjaXXUs/edit?usp=sharing
'''If the document is unreachable, here are the steps from the doc:'''
1. Install a new WordPress site via Softaculous
1. Install WordPress Beta Tester plugin and upgrade to latest WordPress versions:
1. Access the Customizer
1. Menus > Top Menu > Add Items > ''Add New Page'' '''New Page 1''' > Add
1. Schedule the changes for the future, like 1 hour in the future.
1. Copy the Share Preview Link, you’ll need it in step 10.
1. Click the Share Preview Link
1. Click the link in the menu for '''New Page 1'''. You’re currently logged in as an admin, and you can see it.
1. Logout of WordPress.
1. As a visitor, access the '''Share Preview Link''' (the link you copied in step 6).
1. Click '''New Page 1''' in the menu. You’ll get a 404.
This 404 I believe is a bug. If I’ve been working on ''New Page 1'' and I want a client to preview my draft, I would expect them to be able to see it without logging in.
" bwmarkle
Future Releases 33589 Using the customizer on wp-login.php (and similar) Customize 4.3 normal normal Future Release defect (bug) new 2015-08-28T15:16:45Z 2021-05-23T17:58:43Z "See related: https://core.trac.wordpress.org/ticket/28650#comment:19
I've been attempting to write a plugin to customize the `wp-login.php` page using the native customizer controls. So far it seems to work fine except that `postMessage` settings/controls do not update. I'm not sure why it doesn't work, as it appears that all of the customizer code is loading (maybe it isn't?), but something is getting messed up at runtime. The `refresh` setting works fine however.
Any ideas as to what might be going on? Is this something that I can help get pushed into core? Since `wp-login.php` is sometimes a vital part of some sites, it makes sense that it should be available to edit in the customizer. I'm no expert but it seems that this may just be a missing hook that needs to be added to the `wp-login.php` file?" daronspence
Future Releases 55051 WP_Customize_Nav_Menu_Item_Setting class needs hooks/filters parity for preview and update Customize 4.3 normal normal Future Release defect (bug) new 2022-02-02T18:46:59Z 2022-04-27T05:07:00Z "the `WP_Customize_Nav_Menu_Item_Setting` class needs parity with the `WP_Customize_Setting` class.
The following actions exist in the `WP_Customize_Setting` class:
`do_action( ""customize_preview_{$this->id}"", $this );`
`do_action( ""customize_preview_{$this->type}"", $this );`
[see source](https://github.com/WordPress/WordPress/blob/234877c9c3d81b6341bef5539ef52b0745b2a660/wp-includes/class-wp-customize-setting.php#L389-L411)
and
`do_action( ""customize_update_{$this->type}"", $value, $this );`
[see source](https://github.com/WordPress/WordPress/blob/234877c9c3d81b6341bef5539ef52b0745b2a660/wp-includes/class-wp-customize-setting.php#L692-L703)
The `preview()` and `update()` methods are overriden in `WP_Customize_Nav_Menu_Item_Setting` and ''don't'' have those `do_action` hooks, so there's no straightforward way to filter nav menu meta values on preview/update.
For example, the Nav Menu Roles plugin adds meta fields to the Nav Menu Items in the customizer and am currently using a workaround to attach the preview/save routines since there's no direct way to do this with these hooks missing.
Potentially related, the `WP_Customize_Nav_Menu_Item_Setting` class has an unimplemented `@todo` in the `preview()` method: see [source](https://github.com/WordPress/WordPress/blob/071c322bf2211db37cb38b4ddf4d2ed660e745d6/wp-includes/customize/class-wp-customize-nav-menu-item-setting.php#L461)
I'm not 100% certain what is meant there and if it can be ignored if those hooks are implemented. (a quick test suggests that I can filter the metadata in a callback on `customize_preview_nav_menu_item` once it exists.
" helgatheviking
Future Releases 51947 When Customizer `setup_theme` action fails during wp-settings.php, WordPress crashes due to missing global $wp_locale Customize 4.6 normal major Future Release defect (bug) new 2020-12-06T12:48:49Z 2021-02-08T16:21:11Z "The `wp-settings.php` sets up the global `$wp_locale` (line 499 in WordPress 5.5.3) but before doing that it calls `do_action( 'setup_theme' );` (line 478).
The problem is that `WP_Customize_Manager::setup_theme()` has several failure actions that call the class's `wp_die()` ""wrapper"" which - depending on the value of the `messenger_channel` might try to call `wp_enqueue_scripts()`, which will eventually call `wp_localize_jquery_ui_datepicker()` that expects `$wp_locale` to be already set. The result is a crash.
Here is one such stack trace:
{{{
PHP Fatal error: Uncaught Error: Call to a member function is_rtl() on null in /var/www/html/wp-includes/script-loader.php:1684
Stack trace:
#0 /var/www/html/wp-includes/class-wp-hook.php(287): wp_localize_jquery_ui_datepicker('')
#1 /var/www/html/wp-includes/class-wp-hook.php(311): WP_Hook->apply_filters(NULL, Array)
#2 /var/www/html/wp-includes/plugin.php(478): WP_Hook->do_action(Array)
#3 /var/www/html/wp-includes/script-loader.php(2001): do_action('wp_enqueue_scri...')
#4 /var/www/html/wp-includes/class-wp-customize-manager.php(454): wp_enqueue_scripts()
#5 /var/www/html/wp-includes/class-wp-customize-manager.php(551): WP_Customize_Manager->wp_die(0, 'Non-existent ch...')
#6 /var/www/html/wp-includes/class-wp-hook.php(287): WP_Customize_Manager->setup_theme('')
#7 /var/www/html/wp-includes/class-wp-hook.php(311): WP_Hook->apply_filters(NULL, Array)
#8 /var/www/html/wp-includes/plugin.php(478): WP_Hook->do_action(Array)
#9 /var/www/html/wp-settings.php(478): do_action('setup_theme')
#10 /var/www/html/wp-config.php(97): req...
in /var/www/html/wp-includes/script-loader.php on line 1684, referer: https://somesite.com/
}}}
Moving the `do_action( 'setup_theme' );` line down a few lines until after the local has been setup, and just before loading the active theme's `function.php` file (which is arguably where it was supposed to be in the first place) solves the problem. " Guss77
Future Releases 39254 When in Customizer Preview, starter content posts are not displayed in the loop westonruter* Customize 4.7 normal normal Future Release defect (bug) accepted needs-unit-tests 2016-12-12T21:03:24Z 2020-05-27T04:33:56Z "As discussed in [https://wordpress.slack.com/archives/core-customize/p1481567934000409 Slack], posts in Starter Content aren't appearing in the posts list.
Being able to display the bundled content, specifically posts, is key for an improved user experience when configuring a new theme. Posts give structure to the theme, allowing users to see exactly how the theme will look with content.
This would also allow theme developers to completely match the content bundled with the theme to the content on the theme’s demo site. This helps address the popular complaint amongst WordPress users that a newly installed theme looks nothing like the demo." tiagonoronha
Future Releases 24844 get_theme_mods doesn't return the theme customizer preview's new values. Customize 3.5.2 normal normal Future Release defect (bug) new 2013-07-26T13:41:52Z 2017-02-14T18:44:32Z "Using the theme customizer API, you can call get_theme_mod($option) to return the value for a specific theme option.
In the case of the user interacting with the theme customizer, if they have changed an option, the theme customizer replaces the saved option with the previewed / new setting by hooking onto the {{{theme_mod_$name}}} filter applied in {{{get_theme_mod}}}.
However, should the user need or desire to retrieve all theme mods at once, the filter is not applied, and the new settings are never injected into the saved settings array.
There's a workaround to simply loop through the settings and manually apply the filter, but it would be better if {{{get_theme_mods}}} had an argument like {{{$use_filter}}} and could add the filter in the core functionality.
{{{get_theme_mods}}} is in [source:tags/3.5.2/wp-includes/theme.php#L746 wp-includes/theme.php] on line 746.
{{{get_theme_mod}}} is in [source:tags/3.5.2/wp-includes/theme.php#L776 wp-includes/theme.php] on line 776.
{{{theme_mod_$name}}} filter is applied in [source:tags/3.5.2/wp-includes/theme.php#L780 wp-includes/theme.php] on lines 780 and 785.
{{{ theme_mod_$name}}} filter is added in [source:tags/3.5.2/wp-includes/class-wp-customize-setting.php#L72 wp-includes/class-wp-customize-setting.php] on line 72." nessworthy
Future Releases 40243 Allow Manual Hue input for the HSL Color Picker Customize 4.7 normal normal Future Release enhancement new 2017-03-23T17:58:50Z 2021-05-29T17:23:19Z "The new HSL mode for the color picker is insanely useful! However, if someone has certain brand colors that they wish to incorporate, it might be helpful to allow a specific hue input via an integer value that will allow accurate matching.
Right now, with the hue slider, it's anyone's best guess if they near their brand colors." calvinkoepke
Future Releases 42806 Allow installing themes in the Customizer on multisite Customize normal normal Future Release enhancement new dev-feedback 2017-12-05T17:47:40Z 2018-07-08T17:44:55Z "Currently the ""Install Themes"" section in the Customizer isn't added when using multisite.
There is no technical problem with the installation process, as it still works correctly, simply by adding removing the restriction to only add the section (and enqueueing the related script) if `is_multisite()`, which I tested before opening this ticket.
However, what would need to be figured out is how to deal with enabling themes, because by default an installed themes isn't enabled anywhere. And of course it would only be possible for the network administrator, but I think that would still bring a huge benefit, because right now it isn't possible in multisite at all.
Here are two suggestions for possible approaches:
1. When in a multisite, there could be a notification like ""By installing a theme you also automatically enable it for this site."" Then, after the installation logic we would only need to handle that part automatically. If we go with that approach, we would need to make sure that the current user has both the `install_themes` and `manage_network_themes` capabilities.
2. When in a multisite, there could be a separate section ""Network Installed Themes"" that includes all themes installed, regardless of whether they're enabled for the site. Each themes would have a button to enable/disable it for the site. That section would require the user to have the `manage_network_themes` capability. We would furthermore need to ensure that themes are transitioned from the ""Network Installed Themes"" to the existing ""Installed Themes"" section and vice-versa when they are enabled/disabled for the site. Plus, when installing a theme through the ""WordPress.org Themes"" section, the user would need to be redirected to the ""Network Installed Themes"" section with that theme pre-seleted, to easily be able to enable and preview it.
There are benefits to both ways: While the first approach will be much simpler to implement, it somewhat mixes installing and enabling themes into one. The latter approach will allow more flexibility, but may be overly complex. Especially since installing themes without being able to enable them will make the process useless in multisite, I think I prefer the first approach. Maybe a mix of both could be the right way too, where we start with implementing the first approach as a first iteration (that could even be merged into core as that), but keeping it future-compatible to possibly add a dedicated ""Network Installed Themes"" section later." flixos90
Future Releases 37281 Allow non-error notifications to be set for Customizer settings from PHP Customize normal normal Future Release enhancement new 2016-07-04T22:46:29Z 2019-04-19T21:05:35Z "An API adding notifications to Customizer settings was added in #34893. In JS a notification can be added of type `error`, `warning`, `info`, and custom. In PHP, however, only `error` notifications can be added to a setting, and this is done by returning `WP_Error` from a validation routing (or sanitization routine). It may be useful to allow other kinds of notifications to be added via PHP as well. This would likely require adding a `WP_Customize_Setting::$notifications` collection with a `WP_Customize_Setting::add_notification()` and `WP_Customize_Setting::remove_notification()` to provide a similar API in PHP for the general notifications API in JS. It seems clear that non-error notifications shouldn't be added by returning `WP_Error` instances from validation routines, but that the notifications could be added inside of such routines, for example:
{{{#!php
20 ) {
$this->add_notification( array(
'type' => 'warning',
'code' => 'long_value',
'message' => __( 'This is a long value!' ),
) );
}
}
}
}}}
The non-error notifications could be sent back as part of full refresh and selective refresh responses in a similar way that error notifications are sent back and updated into the JS models." westonruter
Future Releases 38957 Customize Menus: Menu locations should be able to opt-out of menu item types that can be added to associated menus Customize 4.3 normal normal Future Release enhancement new 2016-11-26T22:24:31Z 2017-01-21T17:34:56Z "Certain menu locations are often designed to use a particular type of menu item - for example, social menus only make sense with custom links, or a custom nav menu walker may be used to display a deeper index of posts within taxonomy terms featured in a menu location.
If themes could specify what types of content a particular menu location is intended to contain, the menus UI could correspondingly show/hide or prioritize the types of menu items in the available menu items panel. This should be handled with the `object` and `object_type` menu item parameters.
As with #38956, this is difficult due to the current way the menu locations API works, and the fact that menus can be added to multiple locations. This should be considered a usability enhancement that is more conservative in hiding available menu items for items in multiple locations, and that adapts as menu locations are changed." celloexpressions
Future Releases 38956 Customize Menus: menus assigned to locations with limited depths should not allow deeper depths Customize 4.3 normal normal Future Release enhancement new 2016-11-26T22:16:54Z 2019-04-03T03:59:02Z "`wp_nav_menu()` allows themes to control how many levels of depth will be displayed in the menu hierarchy. However, the menus UI doesn't reflect this or explain why submenu items may not always be visible. There are often valid situations where menus can only accept one level of hierarchy (such as social menus), and the API allows this on the theme side but doesn't address the usability side of the issue.
This may be tricky because depth is defined here a menu is displayed, not where a location is registered. Menus can also be assigned to multiple locations. A better API for menu locations may facilitate this improvement." celloexpressions
Future Releases 22880 Customize Themes without activation Customize normal normal Future Release enhancement new 2012-12-12T11:34:51Z 2021-05-22T18:12:20Z "Add a posibility to customize deactivated themes with the Theme-Customizer without activating them by default.
Useful for Blogs running multiple Themes between which the frontend user can switch." kkkrys
Future Releases 42635 Customize: Add default value for customizeAction param for sections Customize 4.3 normal normal Future Release enhancement new 2017-11-20T05:30:21Z 2018-10-12T04:07:05Z "Currently the `customizeAction` has to be explicitly provided when dynamically adding sections via JS. If not, then the section header has broken layout. There should be a default value provided so that this doesn't have to be provided each time (see #42083). Adding a default value for `customizeAction` is complicated a bit by the fact that it [https://github.com/WordPress/wordpress-develop/blob/4af1237176c326e7840361fd580fdc3f97841e6a/src/wp-includes/class-wp-customize-section.php#L228-L233 varies based on whether the section has a parent panel]. The `getContainer` method of `wp.customize.Section` probably should check if `customizeAction` is empty and if so supply one: it could look to see if it has a `panel` parent, and if so, grab the title; otherwise, it can use the default “Customizing” value. A default value should have been originally provided in #30737.
Workaround for plugins to provide a default value in the mean time:
{{{#!php
unused - the theme is considerably more fundamental to the Customizer experience
However, since the `theme` is not just another `setting` then this means that the theme cannot currently be made part of a changeset, and as such a theme switch cannot be previewed on the frontend by non-authenticated users and also a theme switch cannot be scheduled in the customizer. Ideally there could be a `theme` setting with the `switch_themes` capability that could be added to a changeset, and when that changeset is published, the `switch_theme` call should then be made.
See also #22880." westonruter
Future Releases 42191 Customize: Selectively merge settings from autosave revisions Customize normal normal Future Release enhancement new 2017-10-12T04:06:54Z 2021-05-29T18:26:08Z "In follow-up on #42024, an autosave revision is created as part of changeset locking. When a user returns to the customizer after a lock has been lifted, they will be prompted to restore their revision. The restoration logic should only load settings from the changeset which are older than the settings in the `customize_changeset` post (see new setting prop `date_modified_gmt`), or the settings for which there is no existing setting in the changeset. This merge will more intelligently ensure that a user's restored autosave revision won't override the changes another user saved. There may be some cases, however, where selectively restoring parts of an autosave will have unexpected results (e.g. opting to include a newly-created widget, but not accepting the change to the sidebar), so more investigation will be needed.
The problem of conflict resolution in the Customizer is a large problem which is also being worked on in the [https://github.com/xwp/wp-customize-snapshots Customize Snapshots] plugin.
See also #31436 (Handle conflicts in concurrent Customizer sessions)" westonruter
Future Releases 42272 Customize: Use client-side templates for rendering base controls Customize 4.9 normal normal Future Release enhancement new 2017-10-19T03:05:59Z 2019-01-09T06:25:05Z "This is a follow-up on #30738. See patches on that ticket. Eliminating server-side rendering of the control content for server-side registered controls was not included as part of 4.9 due to it being a big change and it got too late in the release.
This will necessarily need to include support for `dropdown-pages` which we didn't implement in #30738, since we ran out of time and wanted to rely on REST API for fetching the pages." westonruter
Future Releases 37915 Customize: allow terms to be created in nav menus boonebgorges Customize 4.7 normal normal Future Release enhancement assigned dev-feedback 2016-09-01T20:51:39Z 2021-05-23T23:16:18Z "Follow up to #34923. When setting up initial site structure, in many cases it's as important to be able to create new terms to add to menus as the ability to create posts. For users, the distinction between terms and posts probably isn't immediately clear, so this functionality gap may be confusing.
There are several patches on #34923 that contain the needed framework here, but we need the ability to preview terms before we can add support for terms.
This depends on #37914. Milestoning for 4.7 now for tracking, but we're waiting for that ticket before we can proceed here." celloexpressions
Future Releases 36581 Customizer Header Image Control should extend the cropped image control Customize 3.9 normal normal Future Release enhancement new 2016-04-18T19:55:06Z 2019-05-29T17:36:05Z "`WP_Customize_Header_Image_Control` was written (in 3.9) before all of the other customizer media controls were refactored to use the media library (in 4.1) and additional controls were introduced (in 4.2 and 4.3). It uses an almost entirely separate codebase right now, and by merging it back in to use the newer functions, future enhancements can be made in fewer places to apply to more controls, and the cropped-image control will likely benefit with some new reusable features as well. Additionally, this cleanup will simplify the codebase and make it much easier to contribute to and understand the way the headers UI works, and why.
Ideally, we would be able to use `WP_Customize_Cropped_Image_Control` directly for header images by bringing more features that are currently specific to headers to all media controls. However, in practice we may end up needing it to remain a distinct control for various reasons. Regardless, it should extend WP_Customize_Cropped_Image_Control directly and make use of its functions in both PHP and JS where possible. Additionally, it should leverage the core API for JS-templated contols introduced in 4.1.
See #29211, and #32861, which would likely be fixed in the process of implementing this ticket." celloexpressions
Future Releases 38072 Eliminate placeholder nav menu items in favor of auto-drafts in Customizer Customize 4.3 normal normal Future Release enhancement new 2016-09-16T05:46:06Z 2017-06-07T00:21:05Z "When nav menus were added to the customizer in 4.3, newly-created nav menu items were assigned a random negative integer to represent the ID for that `nav_menu_item` post. (This was also true of `nav_menu` terms for newly-created nav menus.) Upon saving the customized state, any such `nav_menu_item[...]` settings with negative IDs would then get inserted and assigned actual IDs which would then get sent back in the `customize_save_response` and the UI then replaces the placeholder nav menu item's control with the newly-inserted nav menu item's control. The key motivation here was to ensure that changes made in the customizer would not have an impact any part of WP until hitting Save. (What happens in the customizer stays in the customizer… until you hit Save.)
Now, aside from a momentary flicker of placeholder nav menu item controls that get replaced with actual nav menu item controls, there is a key disadvantage to using such placeholder nav menu items (with negative post IDs): it is not possible to relate postmeta to them. There is a long-standing ticket #18584 for allowing nav menu items to be extensible to add custom fields in the customizer (and in the admin screen). In the call to `get_metadata` it has a behavior whereby it passes the supplied post ID through `absint` so if any postmeta are attempted to be related to placeholder `nav_menu_item` posts, they will fail to be accessed when calling `get_post_meta()`.
Now, in #34923 there was the introduction of being able to create stubs for posts and pages inside the customizer so that they can have nav menu items created for them. The stubs created here are `auto-draft` posts which ensures that they do not affect other parts of WordPress and they will be automatically garbage-collected if never published. Now, the original Menu Customizer plugin did make an Ajax request for each created new nav menu items but they were `nav_menu_item` posts that were not related to a `nav_menu` (they were orphaned) rather than being `auto-draft`. We could consider going back to making an Ajax request to create each `nav_menu_item` (now an `auto-draft`) in the same way that is being done for post/page stubs.
A downside of going to using Ajax to create new nav menu items (to reserve an auto-incremented post ID) is that adding a new nav menu item would no longer be instant. However, it would mean that upon save there wouldn't be any rebuild of nav menu item controls replacing placeholders with actuals, and as such it could mean a lot of code could be removed. But the most important benefit of switching to use `auto-draft` posts for nav menu items is that postmeta could then be created in the customizer and related to actual post IDs which could then be properly targeted in `get_post_metadata`filters.
Alternatively, `get_post_meta` could just replace the `absint` with a call to `intval` and then ensure that the `get_post_metadata` filters apply with that negative ID, but then short-circuit if the filter doesn't return with `null` (since it wouldn't be able to find entries with negative IDs in the database).
See feature plugin for adding custom fields to the customizer: https://github.com/xwp/wp-customize-nav-menu-item-custom-fields
Note how the plugin has to postpone the presentation of custom fields until a newly-added nav menu item is saved the first time: https://github.com/xwp/wp-customize-nav-menu-item-custom-fields/blob/2ad056634441a74ba91982ca88b089297f630971/customize-nav-menu-item-custom-fields.js#L279-L284
Dependency for: #18584" westonruter
Future Releases 36582 Export main query from Customizer preview Customize 4.0 low normal Future Release enhancement assigned 2016-04-18T20:45:09Z 2021-05-23T19:56:36Z "Controls, sections, and panels in the Customizer support the concept of an active state (#27993) which controls whether or not the control is contextual to the current query. Controls may want more information than whether to hide/show, but to show contextual information based on which kind of query is loaded in the Customizer preview, such as if it `is_singular` or which post specifically was queried. This information should be exposed from the Customizer preview to the pane as well.
An initial implementation of this has been implemented in the Customize Posts feature plugin: https://github.com/xwp/wp-customize-posts
When the preview syncs the `WP_Query` data from the preview to the pane, the data should get sent along with the `ready` message along with the `activeControls`, `activeSections`, and `activePanels` data. When the data is received by the pane, it should get populated into a model which can have events attached to it. For example, a `wp.customize.Values` instance could be used as a collection to represent the query_vars. Or there could be one single `wp.customize.Value` that stores the exported `WP_Query` data in like `wp.customize.previewedQuery` which plugins could then listen to changes on. For example:
{{{#!js
wp.customize.previewedQuery.bind( function( newQuery, oldQuery ) {
if ( newQuery.is_singular !== oldQuery.is_singular ) {
if ( newQuery.is_singular ) {
// We switched to a singular template!
} else {
// We switched to a non-singular template!
}
}
} );
}}}
Some thought will need to be given to how a JavaScript object is used to represent `WP_Query`.
See Slack: https://wordpress.slack.com/archives/core-customize/p1461011732000103" westonruter
Future Releases 37275 Facilitate creating controls that manipulate settings with object values Customize 3.4 low normal Future Release enhancement new 2016-07-04T20:39:26Z 2019-04-19T21:05:06Z "While #37274 addresses the difficulty to manipulate updating settings that have object values, the Customizer JS API also does not facilitate creating controls that have fields which manage a setting that has a object value.
The `MenuNameControl` provides a good example of a control that has a text field for managing a nav menu setting's `name` property:
{{{#!js
control.nameElement = new api.Element( control.container.find( '.menu-name-field' ) );
control.nameElement.bind(function( value ) {
var settingValue = control.setting();
if ( settingValue && settingValue.name !== value ) {
settingValue = _.clone( settingValue );
settingValue.name = value;
control.setting.set( settingValue );
}
});
control.setting.bind(function( object ) {
control.nameElement.set( object.name );
});
}}}
This works but it is tedious when scaling and makes it difficult to extend, as can be seen in the `MenuItemControl`. There should be a more declarative way to link a field to ''a property'' of a setting value object. One implementation of this can be seen in the [https://github.com/xwp/wp-customize-posts/blob/0.6.1/js/customize-dynamic-control.js Dynamic control] as seen in the Customize Posts plugin. While Core supports a `data-customize-setting-link` attribute in a control template to declaratively link an input field to a setting value, the Dynamic control Dynamic adds support for a `data-customize-setting-property-link` attribute which will link the input field to the a ''property'' of the (default) setting. This eliminates the need for custom JS logic to link the input elements.
See an example control which has fields which manipulate a setting value containing a street address: https://github.com/xwp/standalone-customizer-controls/blob/master/class-customize-address-control.php
This will facilitate extending nav menu items in the Customizer: #18584." westonruter
Future Releases 37274 Facilitate updating/extending Customizer setting values that are objects Customize 3.4 normal normal Future Release enhancement new 2016-07-04T20:22:46Z 2019-04-19T21:04:47Z "There is bit of a dance to work with setting values that are objects.
Consider a `mailing_address` setting that represents a street address:
{{{#!json
{
""street"": ""123 Fictional St."",
""city"": ""Portland"",
""state"": ""OR"",
""zip"": ""97201""
}
}}}
Getting the value is as simple as `wp.customize( 'mailing_address' ).get()`, but updating the value is not so simple. To change the `street` part of this setting, the following is required:
{{{#!js
var value = wp.customize( 'mailing_address' ).get();
value = _.clone( value );
value.street = '123 Imaginary Ave';
wp.customize( 'mailing_address' ).set( value );
}}}
The clone is required because objects are passed by reference, and if the `value` were to set directly, the subsequent `set` would not trigger a `change` event.
Widgets and nav menus use objects as values in Core. Widgets aren't manipulated directly in JS (until #33507) but nav menus and nav menu items are. Here's the code for managing how a nav menu's name gets changed when the nav menu's name field is updated:
{{{#!js
control.nameElement.bind(function( value ) {
var settingValue = control.setting();
if ( settingValue && settingValue.name !== value ) {
settingValue = _.clone( settingValue );
settingValue.name = value;
control.setting.set( settingValue );
}
});
}}}
To make it easier to work with setting values as objects, we could introduce a `wp.customize.Value#setExtend` method that allows an object value to be extended in the same way that `setState` works in React, take an object of key/value pairs that are merged on top of the existing value.
Here is an example implementation:
{{{#!js
wp.customize.Value.prototype.setExtend = function( props ) {
var value = _.clone( this.get() );
_.extend( value, props );
this.set( value );
};
}}}
With this, to update the `mailing_address` setting value property in the above example could be changed to simply:
{{{#!js
wp.customize( 'mailing_address' ).setExtend( { street: '123 Imaginary Ave' } )
}}}
See #26061.
Related #37275." westonruter
Future Releases 38077 Facilitating embedding customizer controls outside of sections westonruter* Customize normal normal Future Release enhancement accepted 2016-09-16T20:14:50Z 2017-05-07T02:46:53Z "Controls are currently assumed to be always contained within sections in the customizer. This makes it difficult to reuse the controls in other contexts, such as embedding multiple controls inside another control or embedding a control outside the context of the customizer entirely. This will facilitate embedding customize controls on the frontend for contextual editing without having to have the customizer sidebar open or even having to go into `customize.php` at all.
Some of the hacks required to get controls to appear outside of the customizer can be seen in https://github.com/xwp/standalone-customizer-controls
The Media control in particular needs to be updated to remove the logic resize the player controls when the section is expanded. The `embed` method (used by widgets) also needs to not wait generally for a contained section to expand.
Key dependency for #29071 (Make it easier to include an instance of the Customizer outside of customize.php)
Depends on or is closely related to #37964 (Allow customizer controls to be encapsulated by accepting pre-instantiated settings)" westonruter
Future Releases 31436 Handle conflicts in concurrent Customizer sessions Customize 3.4 normal normal Future Release enhancement assigned 2015-02-24T19:42:44Z 2021-05-22T20:00:44Z "If two users open the Customizer at the same time and modify the same settings, the user who saves their changes last will win out, and the person who saves first will have their changes lost. (The frequency of the problem was reduced in #29983 since now only dirty settings now get POSTed.) The Customizer needs Heartbeat integration to add the “Post Locking” functionality. We don't need to lock the entire Customizer, however, from concurrent users: we need to add locking for individual settings in the Customizer. When a setting becomes dirty, we need to broadcast via Heartbeat to other users that the setting has been changed and thus any controls for this setting should be marked as ""locked"", with any changes prevented. This will become increasingly important as more and more settings are added to the Customizer and users go there more often to make changes.
The locking UI could provide a button to copy the other user's change into the other Customizer session, and this could result in the control being editable again, with subsequent changes pushed out to other users as well, who would then also get the corresponding setting automatically updated if it was dirty, but if it was not dirty then it would remain in its clean state but with a locking notification added.
This also should apply when a setting is modified by some means other than the Customizer: if someone is in the Customizer and another user changes a setting via an admin page or via XML-RPC or REST API, then this setting update should also be illustrated in the Customizer to note that the settings are stale and should be refreshed. This refresh could be done inline, without having to reload the entire page.
For the issue of conflicting auto-incremented widget IDs across user sessions, see #32183.
For the previously-reported issue specific for handling conflicts between editing widgets on the widget admin page, see #12722.
For the introduction of concurrency locking for options pages (settings API), see #32202.
Some enhancements for a feature plugin: The Customizer UI would benefit from having a list of users currently in the Customizer appearing somewhere, with a list of the changes each user has made. If someone left their Customizer session open, this list would also allow an administrator to sign the user out, using something like the [https://wordpress.org/plugins/user-session-control/ User Session Control] plugin; or the Customizer UI could provide a way to boot a user from the Customizer.
For use of Heartbeat to keep nonces fresh, see #31897.
See also #42191 (Customize: Selectively merge settings from autosave revisions)" westonruter
Future Releases 38845 Implement HTML5 input validity constraints in customizer settings Customize 4.6 normal normal Future Release enhancement new 2016-11-17T23:58:38Z 2017-09-18T19:10:39Z "Ever since #28477 controls in the customizer have supported custom HTML5 input types along with new input attributes passed via the control's `input_attrs` param. The support, however, has been lacking because when a user supplies something that violates some of the constraints (such as `pattern` or `step`) there is nothing that blocks the setting from being saved (using setting validation model in #34893). So using the `input_attrs` along is in fact somewhat harmful if it is not accompanied by the same constraints being applied in the setting's `sanitize_callback` or `validate_callback`. The browser's built-in input validation error UI also does not show because no form actually gets submitted, and there are no calls to the poorly-supported `input.reportValidity()` method.
To address these issues, I suggest that the default `validity_callback` for `WP_Customize_Setting` could look for any associated controls and then check the type of the value against the control's `type` and also check the value against the validation constraints defined in the control's `input_attrs` param, such as `min`, `max`, `pattern`, `step`, `maxlength`, and so on. In this way, a setting's `sanitize_callback`/`validate_callback` wouldn't even need to be defined since the validation constraints would be defined declaratively and checked automatically.
It's not exactly the best pattern, however, for the setting's validation constraints to be defined on the control. So there could be a new `validation_constraints` param on `WP_Customize_Setting` where the validation input attributes could be defined instead of the on the control's `input_attrs`. A control could then automatically populate it's own `input_attrs` by copying from the setting's `validation_constraints`.
These changes will ensure that setting validation routines will apply and error notifications will be displayed when settings fail validation on the server with a full refresh, selective refresh, or changeset update. In order to get the browser's native validation error reporting to appear, the JS control logic can be updated to call `input.reportValidity()` if it is available (it's currently only implemented in Chrome).
See feature plugin: https://github.com/xwp/wp-customize-input-validity-constraints" westonruter
Future Releases 40200 Introduce WP_Customize_Embed_Control Customize 4.7 normal normal Future Release enhancement new 2017-03-18T22:28:29Z 2018-07-08T17:36:03Z Similar to the previously-introduced `WP_Customize_Media_Control`, `WP_Customize_Embed_Control` would offer a UI framework for options that store media information. For this control, associated settings would always store the embed URL, whereas the media control stores an associated local attachment ID. This control would be used to add and manage options that use externally-hosted media via oembed. The initial core usage would be for the external header video control, and this would facilitate showing the embed within the customize pane so that you can directly see what the embed is in the pane, similarly to how the media controls show small previews in the pane to complement the full previews in the customize preview. celloexpressions
Future Releases 37887 Make attachments atomic until a Customizer session is published Customize 4.7 normal normal Future Release enhancement new 2016-08-30T16:50:18Z 2017-10-16T06:45:09Z "== Current behavior ==
When you upload attachments via a Customizer session they are:
1. Added to the filesystem.
2. Saved to the database as a new post.
3. Immediately visible in the Media Library to all other logged in users.
== Desired behavior ==
Attachments that are uploaded during a Customizer session should not be published, or even visible by other logged in users, until the user decides to publish the changes.
== Possible idea
Until Customizer changed are published, all `attachment` posts that have been uploaded inside the Customizer could have their post status set to `auto-draft` rather than `inherit`. This will make them invisible inside the Media Library from other logged in users.
All `attachment` posts uploaded during the Customizer session could be stored inside the new Customizer transaction, and the Media Library query could be made to only show those uploads during the current unpublished session.
== Publish or Discard
If a transaction (customizer changes) is '''published''', then the post status on these `attachment` IDs can be set to `inherit`, making them visible inside in the Media Library like normal.
If a transaction (the customizer changes) is '''discarded''', then the `attachment` IDs can be force deleted via `wp_delete_attachment( $ID, true )` which will not only delete them from the database, but also from the filesystem." fjarrett
Future Releases 49876 Menu section improvement ryokuhi* Customize normal normal Future Release enhancement accepted 2020-04-11T10:23:39Z 2021-07-30T15:53:54Z I use wordpress for more than 15 years i still wondering why you dont make the menu section easier, for example if someone have more than 100 categories in a woocomerce he can be lost in the categories and subcategories. It should be good idea to show BOLD wich of items are in use in the current menu preview, so can be easy use the other items. also need more flexibility in menu items column Dblii
Future Releases 43464 Search Options in Customizer Customize normal normal Future Release enhancement new 2018-03-04T07:05:30Z 2021-05-30T17:34:24Z "If a theme has more than few settings, finding the setting gets frustrating at times. A search functionality in the customizer will be helpful.
Here is a plugin that we have developed as a POC:
https://wordpress.org/plugins/customizer-search/
But I believe, it will benefit if it is added in the core.
" brainstormforce
Future Releases 29288 Settings updated within the Customizer Preview are not synced up to main app Panel Customize 3.4 lowest normal Future Release enhancement new 2014-08-20T20:05:43Z 2021-05-22T19:32:28Z "The Customizer has two copies of models for the registered settings: one set in in the Customizer panel parent frame, and changes to these result in the settings getting copied over to the preview either via postMessage or via a refreshing the preview entirely. Updating a setting model from within preview directly, however, does not propagate up to the model. There is currently a one-way-sync from the panel to the preview.
As a workaround, the preview can send messages to the panel for which handlers can apply the updates to the settings, but it would be good if this was automatic.
By implementing a bi-directional syncing of settings between the panel and preview, there would be lots of opportunities for inline front-end editor controls to more easily be added into the preview directly.
See also https://twitter.com/bradyvercher/status/502163462990995456" westonruter
Future Releases 32861 Site Icon: Provide display for all existing site-icon cropped images Customize 4.3 normal normal Future Release enhancement reopened 2015-07-01T21:14:10Z 2019-06-04T19:30:23Z "Example:
I had a picture and tried to set it up as site icon. I cropped this image and now I have `cropped-image.png` variant of this image 512 x 512 px. Then I tried other images and in the end I wanted to go with the first one. But when I selected this cropped image, I had to crop it once again even if right dimensions. So, now there is another `cropped-cropped-image.png` image in media library and it does not make sense...
Also images for site icons should be somehow marked (as for header images in Customizer). How can I find my cropped images for site icon in media library when trying to set up site icon?" pavelevap
Future Releases 30277 Split up Customizer JS into separate files and remove self-booting jQuery.ready call Customize 3.4 normal normal Future Release enhancement new 2014-11-06T20:11:45Z 2018-06-13T16:28:06Z "The `customize-controls.js` file is huge and is named incorrectly now with #28709 and the fleshed-out models for Panels and Sections. The file should be broken up into `customize-sections.js`, `customize-panels.js`, and `customize-utils.js`. The last of which should include the private function exposed as public methods off of `wp.customize.utils`. This may also include the `wp.customize.init()` mentioned in #29071. We need to stop booting the Customizer inside of these JS libraries with a direct `jQuery.ready` call, and instead let the including page invoke that. This is critical for code reusability and for unit testing. For instance, the `customize.php` page could do in the footer:
{{{#!php
}}}
For `wp.customize.utils`, see existing patch at: https://github.com/xwp/wordpress-develop/pull/47" westonruter
Future Releases 29948 Use contextual controls (active_callback) API for conditionally-displayed core contextual controls Customize 4.0 lowest normal Future Release enhancement new 2014-10-13T18:18:28Z 2017-02-20T18:33:50Z See `wp-admin/js/customize-controls.js`, near the bottom. Rather than doing some unstructured JS to show/hide controls based on the values of other settings, this should use custom callbacks for the active_callback argument when adding the control (in php). celloexpressions
Future Releases 39681 Add RGBA to Customizer color picker Customize normal normal Future Release feature request new 2017-01-24T18:39:25Z 2019-02-08T17:15:54Z "It would be helpful to provide a UI for changing color opacity in the Customizer's color picker.
Some prior discussion about supporting RGBA in Iris here: https://github.com/Automattic/Iris/issues/13
See #21059" melchoyce
Future Releases 46629 Allow replacing placeholders in starter content posts/pages content Customize 4.7 normal normal Future Release feature request new 2019-03-24T21:43:51Z 2019-06-12T18:32:59Z The ability to create posts/pages doesn't really offer a whole lot of use out the gate unless a theme uses hardcoded urls for images in the content. It would be a great improvement if the same handling for placeholders in menus/theme_mods/options could be applied in context of posts/pages content. timph
Future Releases 38900 Customize: Add REST API endpoints for changesets Customize normal normal Future Release feature request assigned 2016-11-22T04:54:47Z 2020-11-06T13:51:48Z "In WordPress 4.7, the `customize_changeset` post type was introduce to persistently store the `customized` state until the staged changes are published (see #30937). In 4.7 the changesets were managed using the same `customzie_save` Admin Ajax request that has always been used to send customizer changes to WordPress. However, changesets are designed so that they needn't be used in the current “Customizer” app at all. A `customize_changeset` post can be created by any means (such as via WP-CLI) and as long as the HTTP request includes the `customize_changeset_uuid` query parameter, the changes stored within the changeset will be applied to preview in the response. As such, changesets for headless sites and apps consuming the REST API to also make use of WordPress's framework for previewing changes.
In addition to an app being able to preview changes in read requests to the REST API, changesets must also be able to be written via the REST API. This is also relevant to creating new changesets for previewing changes on a site's frontend (frontend editing).
The Customize Snapshots has some initial read-only endpoints for the REST API: https://github.com/xwp/wp-customize-snapshots/pull/63
It did not yet implement support for writing changes: https://github.com/xwp/wp-customize-snapshots/issues/64
A few points about what how the changeset endpoints could behave:
- Allow changesets posts to be created and updated, ensuring that `content` is in the proper format as an object mapping setting IDs to setting params. The `content` could be the decoded contents of the `post_content`.
- Prevent editing of `slug`, since the UUID should never change.
- Allow making changes to the `content` via `PATCH` method updates.
- Use the UUID (`post_name`) of the `customize_changeset` posts as the resource IDs as opposed to the underlying post ID. We really don't need regular post IDs since snapshots have UUIDs. Really a random `PUT` request could be made to create a snapshot if it just supplies a proper UUID.
- Let the endpoint be `/changesets` as opposed to `/customize-changesets`.
Ideally the `customize_save` Ajax requests initiated by `wp.customize.previewer.save()` and `wp.customize.requestChangesetUpdate()` could both make use of the changesets endpoints, replacing the use of the `customize_save` Admin Ajax request.
Updates to a changeset should be invoking `WP_Customize_Manager::save_changeset_post()` to apply the changes to the post.
Feature plugin repo: https://github.com/WP-API/wp-api-customize-endpoints" westonruter
Future Releases 40451 Customizer: Introduce plugin management Customize 4.7.3 normal normal Future Release feature request new dev-feedback 2017-04-14T18:23:53Z 2019-01-15T21:13:52Z "There is currently not a way to discover or upload plugins in the customizer, the only way is in WP Admin.
https://codex.wordpress.org/Managing_Plugins#Automatic_Plugin_Installation
https://codex.wordpress.org/Managing_Plugins#Manual_Plugin_Installation
Themes already have #37661 and #40278." lukecavanagh
Future Releases 35857 Add QUnit tests for Customizer preview, including Selective Refresh Customize 3.4 normal normal Future Release task (blessed) assigned needs-unit-tests 2016-02-18T08:26:15Z 2023-03-17T17:06:23Z "Initial Customizer unit tests for PHP and JS were added in #28579. The QUnit tests were done specifically for the Customizer controls (pane) and not the Customizer preview. This was understandable since he preview was devoid of much unique JS functionality. With the introduction of the Selective Refresh component (#27355), this has changed. There needs to be a new QUnit test suite specifically for the Customizer preview.
See @valendesigns initial foundation work here: https://github.com/xwp/wp-customize-partial-refresh/pull/32/files#diff-6fcbfd120899db12c05cdb1f6142cd87 " westonruter
Future Releases 47590 Add unit tests for requests to wp-cron.php Cron API normal normal Future Release defect (bug) new needs-unit-tests 2019-06-22T13:51:07Z 2019-06-30T22:07:49Z "1. Ensure scheduled events are rescheduled correctly
1. Ensure single events are removed from the cron array
1. Ensure future events are not changed.
1. Ensure `doing_cron` transient is deleted." peterwilsoncc
Future Releases 11800 doubled execution of cron jobs westi Cron API 2.9.1 normal normal Future Release defect (bug) new dev-feedback 2010-01-07T11:17:53Z 2021-04-04T10:34:28Z "Hi,
as I've already mentioned in ticket #11505 , cron-jobs occasionally get executed twice (e.g. daily backup arrives two times).
I've changed the code according to the patch attachment:ticket:11505:ticket-11505-stop-gap.patch (which derives from [http://wpengineer.com/ping-problem/]) after my comment:ticket:11505:49 and had no doubles within this time period. This week I've upgraded to WP 2.9.1 and since then backups arrive two, sometimes three times, again.
Looking at the changes from 2.9 to 2.9.1, I have no other explanation for this behavior. - Maybe we should consider having a closer look again on this patch attachment:ticket:11505:ticket-11505-stop-gap.patch .
Greetz,
Berny" neoxx
Untriaged tickets (that need a patch) 48519 Comment reply form in admin incompatible with most custom fields plugins Comments 5.2.4 normal normal Awaiting Review defect (bug) new 2019-11-06T22:17:16Z 2019-11-06T22:17:16Z "If you are using any plugin that adds custom (meta) fields to comments the admin interface for replying isn't compatible.
The front-end comment template includes various hooks for plugins to use.
The admin however does not (at all).
See:
Front-end: `wp-invludes/comment-template` function: `wp_comment_reply()` from around line 2393
Admin: `wp-admin/includes/template.php` function `comment_form()` from around line 437
In my case it's a compatibility bug with required fields created by Pods.
Within WP Admin it won't show the custom fields and this doesn't save any comments because required fields are not filled.
Some missing hooks:
Filters:
- `comment_form_default_fields`
- `comment_form_fields`
- `comment_form_logged_in` (Not needed as it's in WP admin)
- `comment_form_field_comment`
- `comment_form_field_{$name}`
- `comment_form_submit_button` (Not sure if this is desirable in WP admin)
- `comment_form_submit_field` (Not sure if this is desirable in WP admin)
Actions:
- `comment_form_before`
- `comment_form_must_log_in_after` (Not needed as it's in WP admin)
- `comment_form_top`
- `comment_form_logged_in_after`
- `comment_form_before_fields`
- `comment_form_after_fields`
- `comment_form`
" keraweb
Untriaged tickets (that need a patch) 57432 Edit comments capability issue Comments normal normal Awaiting Review defect (bug) new 2023-01-09T08:46:16Z 2023-03-31T14:14:20Z If the user does not have capability to edit comments, the checkbox for Discussion - Allow comments disappears. This will store the null value into database and cause comments form as not visible. AitThemes
Untriaged tickets (that need a patch) 58375 Turn comments off by default for attachment pages (or make is easier to do so without code) Comments normal normal Awaiting Review enhancement new dev-feedback 2023-05-22T14:49:42Z 2023-05-25T07:09:59Z "If a new user is installing WordPress the first time, it lasts some time until the first spam comment appears. Typically, they now disable comments on **Settings -> Discussion**.
First problem: this is just disabling the comments for ''future'' posts.
Now they learn about bulk editing posts, which works fine.
But the website is now online for some time and more media is uploaded, and now the spam comes to the next open comment form: **on attachment pages**.
Not sure if attachment pages follow the setting from the discussion page, but there will be many media items with open comments.
Now we have the second problem: On the grid view, there is no way to disable the comments at all (you need to follow a link to get to the single media edit page).
On this page you need to customize the screen options to enable the meta box, and now you can disable the comments for ''this'' media item. This has to done manually for every media item with open comments (but there is no way to see if the comments are open - so you need to edit every media item).
This could be a real pain for websites with many media items.
**I would recommend changing the behavior and have comments on attachment pages turned off by default.**
I think it will be easier to educate theme developers to turn them on again if the theme uses them (e.g. photography themes) as documented here:
https://make.wordpress.org/core/2015/07/06/comments-are-now-turned-off-on-pages-by-default/
This is already discussed in the comments on this post.
Related tickets: #12991 and #21391
Another way could be to use the idea of this comment:
https://core.trac.wordpress.org/ticket/12991#comment:22
If turning the default to off is not possible, we could use the bulk edit to enable/disable the comment/pingback/trackback feature.
The need for such a feature could be seen in the plugin directory, as there are more than one plugin for disabling comments on attachment pages (and more):
https://wordpress.org/plugins/disable-comments/
https://wordpress.org/plugins/smart-attachment-page-remove/
https://wordpress.org/plugins/disable-comments-rb/
https://wordpress.org/plugins/comments-plus/
https://wordpress.org/plugins/disable-comments-on-attachments/
https://wordpress.org/plugins/disable-comments-by-click5/
https://wordpress.org/plugins/no-page-comment/
https://wordpress.org/plugins/stop-media-comment-spamming/
https://wordpress.org/plugins/disable-comments-wpz/
https://wordpress.org/plugins/disable-post-comments/
https://wordpress.org/plugins/close-comments-on-media-attachment/
These add up to more than a million active installations." zodiac1978
Untriaged tickets (that need a patch) 55922 Update wp_list_comments type parameter to allow array or string Comments 2.7 normal normal Awaiting Review enhancement new 2022-06-05T06:27:24Z 2022-06-05T06:27:24Z "Right now, the options here are all, or a specific comment type. This should allow for multiple comment types as allowed in WP_Comment_Query
" dshanske
Future Releases 6342 "Rapidly spamming/deleting comments can break ""infinite river"" feature on comment moderation pages" Comments 2.5 low minor Future Release defect (bug) assigned 2008-03-21T22:05:16Z 2019-03-15T00:41:30Z "Comment moderation pages have an ""infinite river"" feature whereby when you remove one comment (spam/delete), it'll load a new one at the bottom. Unfortunately, it doesn't seem to catch up if you click more rapidly than about once every 2 or 3 seconds, and you'll ""lose"" comments. At the end, you may just have one comment that, when dealt with, will be replaced by only one comment. This may have to do with doubleclicking the ""spam"" link, or maybe clicking the ""spam"" link of the next comment before the river action has finished." markjaquith
Future Releases 29462 comment pagination in reverse order should display a full number of the latest comments Comments 3.9 normal normal Future Release defect (bug) reopened dev-feedback 2014-09-02T07:12:47Z 2021-03-16T16:01:41Z "set the following discussion setting:
break comment into pages with 5 top level comments per page and the last page displayed by default
Comments should be displayed with the newer comments at the top of each page
have a post with 6 comments
only the last comment made is displayed by default instead of the expected 5 last comments." mark-k
Future Releases 40901 get_comments_number_text() third argument not used in certain situations Comments normal normal Future Release defect (bug) new needs-docs 2017-06-01T13:43:43Z 2019-06-21T13:02:54Z "`comments_number()` is a wrapper for echoing `get_comments_number_text()`.
Reference: https://codex.wordpress.org/Function_Reference/comments_number
The 3rd parameter's description: Text to display when there is more than one comment. % is replaced by the number of comments, so '% so far' is displayed as ""5 so far"" when there are five comments.
This doesn't seem to work as expected. In particular, the parser doesn't look just for '%' but also for strings with spaces in front or behind this sign, after which it processes it in a illogical way.
For example, this code
{{{
_e('Read on', 'anytextdomain');
comments_number(' and add the first comment', ' and see the first comment', ' % so far'); ?>
...
}}}
results in: `Read on 2 komentarze...` (""komentarze is a Polish translation of ""comments"", which is ok). Where's the ""so far"" string?
Now another example with text before the % sign:
{{{
_e('Read on', 'anytextdomain');
comments_number(' and add the first comment', ' and see the first comment', ' and view % comments'); ?>
...
}}}
The result is bizarre: `Read on2 komentarze...`
With some testing it seems that some strings passed as the 3rd argument are being kept, but it's totally illogical and requires review. If this is somehow intended, it should be explained in the Codex. So far, even the Codex example doesn't work as intended. I also checked that I'm not using any `comments_num*` filters.
Workaround: use `get_comments_number()` with conditional code." eclare
Future Releases 20977 Add Dynamic Comment Statuses Comments 3.4 normal normal Future Release enhancement new dev-feedback 2012-06-15T17:12:07Z 2020-01-14T02:35:50Z It would be great to add some filters/actions that would allow plugin developers to add additional statuses to comments. supercleanse
Future Releases 48088 Anonymous Avatar should be served locally Comments low normal Future Release enhancement new 2019-09-20T17:12:35Z 2019-11-01T17:09:20Z "Right now, even the mystery man is retrieved by querying gravatar.
We should have a local copy of the anonymous avatar that is served.
At the least, if there is no requirement for an email, which is what is used to provide the gravatar requests, why make requests to gravatar?
We could say caching gravatar responses is plugin territory, and while I would like to do with with gravatar for performance, this is about not making a call in the first place." dshanske
Future Releases 33627 In-Context Comment Moderation Comments normal normal Future Release enhancement new 2015-08-31T17:24:33Z 2021-01-27T19:20:14Z "One of the more painful points in the comment moderation UX revolves around knowing whether or not a comment is in context. Right now, WordPress says who a person was replying to and offers a link to the frontend of that comment on replies to a comment. However, it can be quite tedious to go view the original comments a bunch of people were replying to to see if the reply was in-context.
An easy fix for this would be to offer a ""Show context"" link next to the ""replying to {name} link on replies, that when clicked, would ajax show the comment the pending comment was originally replying to. " chriscct7
Future Releases 39084 Introduce singular capabilities for managing individual comments Comments normal normal Future Release enhancement new needs-unit-tests 2016-12-04T22:14:50Z 2017-07-14T19:41:15Z "As we did in #35614 for taxonomy terms, singular capabilities should be introduced for approving, unapproving, spamming, unspamming, editing, and deleting individual comments.
This would allow fine-grained cap checks such as current_user_can( 'edit_comment', $comment_id ) and current_user_can( 'approve_comment', $comment_id )." johnbillion
Future Releases 41731 Make it Easier to Locate Restored Comments SergeyBiryukov Comments 4.8.1 normal normal Future Release enhancement assigned 2017-08-25T19:30:34Z 2019-06-21T17:56:20Z "When a comment is in the trash, WordPress does not allow you to edit its details without restoring it first. After restoring the comment, it disappears from the Trash and the user is then required to locate it either by memorizing the post it's on or searching for it in the backend. It doesn't show up on the approved comments page because of its original published date.
I suggest that if a single comment is restored, it takes users to the post it's on. Even better would be taking the user straight to where the comment is in the Discussions meta box. However, since users can hide this meta box via the screen options, I'm unsure how to account for that.
Perhaps redirecting users to the post where the comment is displayed is enough?" jeffr0
Future Releases 56261 Normalize comment function parameters with mixed case names SergeyBiryukov* Comments normal normal Future Release enhancement accepted 2022-07-20T16:30:32Z 2023-02-08T14:39:53Z "Background: #56244
As of WordPress 2.9, core normalizes the `user_ID` parameter to `user_id` when passing data to comment functions, see [12267], [12300], and [28915].
We should consider normalizing other parameters in the same way as it was done for `user_ID` → `user_id`:
* `comment_ID` → `comment_id`
* `comment_post_ID` → `comment_post_id`
* `comment_author_IP` → `comment_author_ip`
Then any combination of these parameters would work regardless of the case.
This would allow extenders to name variables in accordance with the WordPress coding standards:
* `$comment_id`
* `$comment_post_id`
* `$comment_author_ip`
and use them subsequently in a `compact()` call without having to worry about a case mismatch.
This would also allow us to revert some of `compact()` rearrangements made in [53719] and [53723]:
{{{
$compacted = array(
'comment_post_ID' => $comment_post_id,
'comment_author_IP' => $comment_author_ip,
);
$compacted += compact(
'comment_author',
'comment_author_email',
'comment_author_url',
...
'user_id'
);
}}}
which could then be:
{{{
$compacted = compact(
'comment_post_id',
'comment_author',
'comment_author_email',
'comment_author_url',
'comment_author_ip',
...
'user_id'
);
}}}
The list of functions this may affect:
* `wp_insert_comment()`
* `wp_new_comment()`
* `wp_update_comment()`
* `wp_filter_comment()`
* `wp_handle_comment_submission()`" SergeyBiryukov
Future Releases 35650 title_reply_to should work when javascript is enabled Comments normal normal Future Release enhancement new 2016-01-28T21:51:05Z 2019-06-21T01:16:40Z "`title_reply_to` is a parameter in the `comment_form` function, and has even been around since 2.7 in the `comment_form_title` function, allowing you to display a different heading when replying to a comment, including who you are replying to. While a cancel comment reply link does appear, having a different heading is a very useful concept for making it clear to users exactly what they are doing.
Except, nobody ever sees it because it only applies when javascript is disabled. Everybody* has javascript enabled.
The javascript for replying to comments should be updated to change the heading based on this parameter.
" smerriman
Future Releases 35214 Custom Comment Types Comments normal normal Future Release task (blessed) assigned 2015-12-24T00:28:11Z 2021-07-13T16:02:18Z "It's time to take another look at Custom Comment Types. We have a nice stable example in post types, but there's a '''lot''' to do here, so we'll use this as a centralized tracking ticket for everything. As such, I'm sure the description here will be fluid for a while as we figure out how much there is to do.
Here's a rough list of things that need to be looked at and addressed:
* UI/UX - In order for custom comment types to be really useful, we need to put some serious thought into the UI/UX surrounding comments in the admin.
* The `comment_type` field needs to start using `'comment'` instead of `''` for comments. This will mean an upgrade routine as well as some back-compat work.
* We need to decide what to do about non-default comment types in various admin areas (comments table, recent comments, etc). The thing that makes most sense is for `WP_Comment_Query` to be adjusted to only show default comment types (comments, pingbacks, and trackbacks) by default. Additional comment types would then be handled by whatever plugin or theme adds them. Unfortunately, this is a breaking change (comment:58:ticket:12668) because right now those areas show all comment types. Maybe we can create new management areas to be able to pull these out of the default one? Lets put our heads together.
* A lot of existing functions, like `comment_type()`, will need to be fixed to make room for newly registered comment types and their registered strings.
Previous tickets for history:
#25674
#12668
" aaroncampbell
Future Releases 12363 Comment permalink wrong when only listing one comment type wonderboymusic Comments 3.0 normal normal defect (bug) assigned dev-feedback 2010-02-24T14:31:51Z 2019-06-04T19:21:46Z "If you pass the `type` parameter to `wp_list_comments()` (for example, to show comments only and no pings), then comment permalinks can easily use the wrong page number as they expect there to be pings included. This is apparent after leaving a comment and WordPress attempts to redirect back to your new comment.
At first I was thinking you could tell WordPress that you're filtering to a type and it could compensate when determining the page number, but then I realized perhaps it'd just be better for `wp_list_comments()` to check if there were 0 comments returned for the query and if so, see if there are any of that type of comment available. If so, then we know we're on too high of a page number and can instead display the highest existing page. Then again this introduces SEO issues.
Ideas on what to do are welcome." Viper007Bond
Future Releases 35862 Comments screen: audit all the background color animations Comments 3.8 normal normal defect (bug) new 2016-02-18T17:26:13Z 2019-06-04T19:34:53Z "Noticed some weird behavior, to reproduce: go in the Comments screen (in the ""All"" view), and mark as spam or move to the trash an '''approved''' comment. The comment row background will quickly ""flash"" to red and then the comment row will disappear.
Do the same on an '''unapproved''' comment: no red flash.
There are also other cases where this happens, seems all related to pending comments. By the way, the JavaScript animations still run and the background is animated behind the scenes. It just can't be seen because the pending comment row background color is now set on the `th` and `td` elements that hide the change on the `tr` background. Looks like this JavaScript part wasn't updated after the CSS changes in WordPress 3.8.
There are also other old things that missed to be updated, for example at some point JavaScript still uses `#FFFFE0`. This was the background color used for unapproved comments in WordPress 3.7 but they use `#FEF7F1` since 3.8.
I'd propose two options:
1. Fix the animations :)
2. Get rid of them. Apparently, not so many users have complained about the (partial) lack of color animations in the last 2 years
I'd lean toward the second option. There are several lines of JavaScript in `edit-comments.js` and `wp-lists.js` that could be removed, they are hard to maintain and being a bit old code they also violate the separation of structure, presentation and behavior principle. Yes, the JS could be refactored and maybe use a more modern approach but for, I'd say, a very little benefit.
So before any patch attempt, this would need a decision. Any thoughts more than welcome.
In the screenshot below, the red flash on pending comments, how it used to be on WordPress 3.7
[[Image(https://cldup.com/Ml9laEw1jQ.png)]]" afercia
Future Releases 34106 Comments should have real permalinks Comments normal normal defect (bug) new 2015-10-01T04:41:21Z 2019-06-04T19:32:37Z "The closest think we have to comment permalinks are links like this:
`example.com/my-post/comment-page-3/#comment-123`
This is very fragile:
* comment-page-x is sometimes optional, as when oldest comments are displayed first, and `my-post/comments-page-1/` is the same as `my-post/`
* If you change the number of comments per page, the link is no longer correct
* URL fragments (the stuff after `#`) are client-side only. Remember hashbangs? https://www.w3.org/blog/2011/05/hash-uris/
* Pagination URLs are ugly and should not be used for canonical purposes
I propose something along the following lines:
* `example.com/comment/123` rewrites to `example.com/?comment_id=123`
* `WP_Query` will translate `comment_id` into the proper values for `p` and `cpage`
* `redirect_canonical()` will send you to `example.com/my-post/comment-page-3/#comment-123`
Comment pagination settings can change at any time, and permalinks will continue to work." boonebgorges
Future Releases 22261 Recent comments widget makes additional queries when pagination is enabled Comments normal normal defect (bug) new 2012-10-23T14:19:59Z 2019-06-04T19:23:35Z A continuation of #15400. nacin
Future Releases 35805 Reverse page order in wp_list_comments() with newest comments first boonebgorges Comments 4.4.2 normal normal defect (bug) reviewing needs-unit-tests 2016-02-12T00:21:26Z 2019-06-04T19:34:45Z "Hey there,
since wp 4.4 there were lots of bugs in the wp_list_comments()-function. Some of them are already fixed, now I found another one.
If you change the comments order from default (oldest first) to newest first, the page order is wrong (reverse page order).
== Example ==
You have 4 pages by sending following param you get these pages:
{{{
page=1 -> 4
page=2 -> 3
page=3 -> 2
page=4 -> 1
}}}
== How I call this function ==
Inside the post-loop I'm calling:
{{{#!php