text:
Very Popular,12706,Custom post status bugs,,"Posts, Post Types",3.0,normal,normal,160,Future Release,task (blessed),reopened,needs-unit-tests,2010-03-25T14:41:39Z,2016-10-11T18:29:11Z,"A developer should be able to register a custom post status using `register_post_status()`. The admin UI (including post submit box and quick edit) should reflect this new custom post status. Furthermore, there are many hard-coded references to 'draft' and 'pending' statuses in core that should properly use the post status API.
All existing arguments to `register_post_status()` should be fully implemented, should also support per-post-type arguments. As things get implemented across core, there will likely be a need for supporting capabilities and bits of API.
Related: #23169 (register_post_status_for_object_type), #23168 (unregister_post_status).",ptahdunbar
Very Popular,36335,Next generation: core autoloader proposal,,General,,normal,normal,92,Future Release,feature request,new,has-patch,2016-03-25T19:21:43Z,2016-10-03T23:07:59Z,"Hello WordPress community. With this ticket I would like to get the debate of the last days about how to attract WordPress to developers (or the other way around?) to a concrete discussion on how a class autoloader could look like in WordPress core.
So when we start to think about some major improvements like in #36292, we should also take some time and talking about autoloading.
== Abstract ==
A class autoloader is a basic tool to separate code writing form code organization. It takes care about providing class declaration at the point they are needed. The fact that WordPress lacks of a core autoloader was one point mentioned in the debate on what developers [https://www.alainschlesser.com/attracting-developers-wordpress/ missing most with WordPress].
== Why we need an autoloader ==
Plugin authors using autoloaders these days. They even use composer for dependency management and ship their plugins with this dependencies. This practice [https://github.com/composer/composer/issues/3852 leads to trouble right now]. I'm convinced that in a long-range plan we even have to talk about how to deal with proper dependency management to overcome collisions. Having an autoloader in core is a precondition for this.
== How an implementation could look like ==
The following proposal follows a concept of separating the file locating and file loading process to avoid a violation of the single responsibility principle and to gain flexibility. All classes and interfaces are prefixed with `WP_Autoload_` to apply a pseudo namespace.
The main instance of this concept is the interface `WP_Autoload_Rule`. An autoload rule is against the client responsible for locating and loading a given class. The class is provided by its full qualified name. This leads to this interface signature:
base_directory = (string) $base_directory;
$this->base_namespace = (string) $base_namespace;
$this->file_loader = $file_loader && is_a( $file_loader, 'WP_Autoload_Fileloader' )
? $file_loader
: new WP_Autoload_IsReadableFileLoader;
* @param string $class (A full qualified class name)
* @return bool
public function load_class( $class ) {
// performing the psr4 mapping here to get a $file
$file = '/whatever';
return $this->file_loader->load_file( $file );
Autoloading rules should depend on a file loader. The file loader receives a file name and loads it, if it is present.
rules, TRUE ) )
$this->rules[] = $autoload_rule;
* @param string $fqcn (full qualified class name)
public function load_class( $fqcn ) {
foreach ( $this->rules as $rule ) {
if ( $rule->load_class( $fqcn ) )
== Instantiate and propagate the autoloader ==
new WP_Autoload_Psr4Rule(
__DIR__ . '/src'
} );
== Things to discuss ==
* The proposal uses [http://verraes.net/2013/09/sensible-interfaces/ sensible interface names] which I prefer over naming interfaces like `WhateverInterfaces`. As WordPress does not provide interfaces right now, this is just a suggestion.
* PHP class identifiers are case insensitive. That means `new MySql` and `new MySQL` will both work, if a class `mysql` is declared. The autoloader should respect this. Now, Psr4 is very wide-spread and encourage developers to use case sensitive autoloaders and [https://r.je/php-autoloaders-should-not-be-case-sensitive.html this is a problem]. How can we deal with this in a performant way?
* How should the WordPress core files be organized to work with the autoloader? Is it realistic to rearrange them, if not how could a corresponding `WP_Autoload_Rule` look like?
* What about compatibility with PHP 5.2.? The proposal uses `spl_autoload_register`. But before PHP 5.3.0 it is theoretically possible to deactivate the spl extension. In this case another implementation of `WP_Autolad_Autoload` would be necessary and maybe some adaptions to the other interfaces. But is this really the intention?
== Finally ==
Thanks for reading. Feel free to add your concerns, your opinions or even if I'm on a completely wrong train. In fact
I'm really interested in critic. To be clear, I don't want to push this proposal but I would like to see a proper
autoloader in core some day :)",dnaber-de
Very Popular,15311,dynamic image resize (on the fly) using already available functions,,Media,3.1,normal,normal,77,Future Release,enhancement,new,dev-feedback,2010-11-03T20:18:44Z,2016-09-09T19:15:27Z,"The lack of a dynamic resize function in WordPress forces theme developers to register lots of image sizes for their themes to use.
One of the problems with this approach is that the server becomes full of image files that will be never used.
Another problem is that when someone changes their theme the image sizes simply doesn't match, forcing people to use a plugin to regenerate all image files, and once again lots of those files will never be used.
So theme developers right now are using some sort of image resizing script like timthumb that works outside of wp. I think it has many drawbacks comparing to a native implementation.
So I made a function that uses WordPress native image handling capabilities to resize and save those resized images for future use.
I use this for attached images as well as standalone files such as custom fields and other images.
What I want here is just to share my solution, and maybe we can someday put something like this into core (actually something better then this):
* Resize images dynamically using wp built in functions
* Victor Teixeira
* php 5.2+
* Exemple use:
* "" width="""" height="""" />
* @param int $attach_id
* @param string $img_url
* @param int $width
* @param int $height
* @param bool $crop
* @return array
function vt_resize( $attach_id = null, $img_url = null, $width, $height, $crop = false ) {
// this is an attachment, so we have the ID
if ( $attach_id ) {
$image_src = wp_get_attachment_image_src( $attach_id, 'full' );
$file_path = get_attached_file( $attach_id );
// this is not an attachment, let's use the image url
} else if ( $img_url ) {
$file_path = parse_url( $img_url );
$file_path = ltrim( $file_path['path'], '/' );
//$file_path = rtrim( ABSPATH, '/' ).$file_path['path'];
$orig_size = getimagesize( $file_path );
$image_src[0] = $img_url;
$image_src[1] = $orig_size[0];
$image_src[2] = $orig_size[1];
$file_info = pathinfo( $file_path );
$extension = '.'. $file_info['extension'];
// the image path without the extension
$no_ext_path = $file_info['dirname'].'/'.$file_info['filename'];
$cropped_img_path = $no_ext_path.'-'.$width.'x'.$height.$extension;
// checking if the file size is larger than the target size
// if it is smaller or the same size, stop right here and return
if ( $image_src[1] > $width || $image_src[2] > $height ) {
// the file is larger, check if the resized version already exists (for crop = true but will also work for crop = false if the sizes match)
if ( file_exists( $cropped_img_path ) ) {
$cropped_img_url = str_replace( basename( $image_src[0] ), basename( $cropped_img_path ), $image_src[0] );
$vt_image = array (
'url' => $cropped_img_url,
'width' => $width,
'height' => $height
return $vt_image;
// crop = false
if ( $crop == false ) {
// calculate the size proportionaly
$proportional_size = wp_constrain_dimensions( $image_src[1], $image_src[2], $width, $height );
$resized_img_path = $no_ext_path.'-'.$proportional_size[0].'x'.$proportional_size[1].$extension;
// checking if the file already exists
if ( file_exists( $resized_img_path ) ) {
$resized_img_url = str_replace( basename( $image_src[0] ), basename( $resized_img_path ), $image_src[0] );
$vt_image = array (
'url' => $resized_img_url,
'width' => $new_img_size[0],
'height' => $new_img_size[1]
return $vt_image;
// no cached files - let's finally resize it
$new_img_path = image_resize( $file_path, $width, $height, $crop );
$new_img_size = getimagesize( $new_img_path );
$new_img = str_replace( basename( $image_src[0] ), basename( $new_img_path ), $image_src[0] );
// resized output
$vt_image = array (
'url' => $new_img,
'width' => $new_img_size[0],
'height' => $new_img_size[1]
return $vt_image;
// default output - without resizing
$vt_image = array (
'url' => $image_src[0],
'width' => $image_src[1],
'height' => $image_src[2]
return $vt_image;
Very Popular,21170,JavaScript actions and filters,adamsilverstein,General,3.4,normal,normal,74,Future Release,feature request,assigned,dev-feedback,2012-07-05T21:34:03Z,2015-12-10T15:57:48Z,"The concept of adding JavaScript actions and filters has been tossed around for some time. We've experimented with various configurations of actions in both the fullscreen and customizer APIs, and they've proven their utility enough to graduate them to a core feature in their own right.
I think that a good events API should satisfy these parameters:
1. '''Support jQuery-style dot namespacing''' to allow functions to be easily removed.
2. '''Should (likely) support priorities.''' While seemingly random numbers aren't fun to use, it allows plugins to cooperate without having to know of each other's existence. We can't expect plugin authors to rearrange the array of callbacks.
3. '''Should ''not'' force functions to have unique IDs.''' Anonymous functions are extremely common in JavaScript — forcing them to be named is contrary to the nature of the language.
4. '''Should be structured as a mixin.''' The global event loop should be an instance of the core Events object. Using a mixin will allow developers to easily create event loops for their own plugins (to prevent polluting the global namespace — think about large plugins, like bbPress). An events mixin will also enable developers to create more powerful abstractions, such as observable values, collections, and pretty much any structural JS object you can dream up.
5. '''Should allow the looping process to be overwritten.''' This will result in less code and added flexibility. The only difference between actions and filters is how they handle the callbacks object. There are other types of looping processes that could be beneficial in JS. One example would be returning false if any callback returns false, which could be used to stop a process, much like the native event.stopPropagation method.
'''Why not use custom jQuery events?'''
Custom jQuery events are great when we need to trigger actions on a DOM element. Triggering plain events on the body element (or any other hidden element) is not performant — every jQuery event normalizes an DOM Event object, which we then completely ignore.
'''Should we require jQuery to use the API?'''
I'm not sure. jQuery.Callbacks may be a helpful solution here, provided we can properly integrate priorities and namespacing. jQuery.Callbacks also only requires jQuery.each and jQuery.extend, so writing a shim that doesn't use the rest of jQuery would not be exceptionally difficult. Either way, switching between one and the other as we develop should not be exceptionally difficult.",koopersmith
Very Popular,37699,"Death to Globals Episode #1: A Registry, A Pattern",,General,,normal,normal,70,Awaiting Review,enhancement,new,,2016-08-17T20:49:29Z,2016-10-15T20:01:00Z,"Storing application state in globals is ... bad.
Using global state to store objects is ... bad.
Using globals to avoid writing classes is ... bad.
Using globals to pass data between functions is ... bad.
Training people to assume that globals will always be set to the value they expect is ... bad.
Globals are an artifact of a #dark-er time, think PHP 3. It would be nice if we didn't use globals. We have a backward compatibility strait jacket, but that shouldn't stop us from exploring ways to eradicate them.
We can start with class instances, because variables hold a reference to the actual instance when set. We can also start with a simple registry that allows us to create a data that can get / set globals for us (or not!). We can also add a few static methods onto `WP` to hide all of this away.
Attached is a POC that removes (every instance of?) `$wpdb` as a global, and instead uses the registry. Take a glance. All unit tests (seem to) pass.
This will evolve before it becomes a reality, but I encourage you to unleash your imagination unto a world where WordPress' codecase resembles something globallessly lovely.
Very Popular,20564,Framework for storing revisions of Post Meta,adamsilverstein,Revisions,3.4,normal,normal,69,Future Release,enhancement,assigned,dev-feedback,2012-04-28T08:51:36Z,2016-04-27T21:09:42Z,"There are a couple of tickets that would seem to benefit from storing revisions of post meta (#11049, #20299). We had a need for this feature in our Carrington Build and RAMP products and built it a few years back.
It handles the storing of post meta along with revisions, as well as restoring those revisions when someone restores an older version of a post(/page/etc.). There is an API for registering the post meta keys you want to track revisions of, it does not track all post meta keys by default.
There are two versions of the code. The bare-bones revisions framework code is here:
https://github.com/crowdfavorite/wp-revision-manager [[BR]]
while I started adding features to a version that would be more user-friendly plugin, allowing the users to select which post meta keys they want to track revisions for:
http://plugins.svn.wordpress.org/revision-manager/ [[BR]]
If this would be a valuable addition to core, I'd be happy to help polish this up in whatever manner is most helpful. I'd recommend breaking out the code I started on for the admin form and having that be the extent of the ""revision manager"" plugin - basically it becomes a nicer UI for selecting additional post meta keys to track revisions for.",alexkingorg
Very Popular,19627,Themes should be able to opt-in to a static front page,,Themes,,normal,normal,67,Future Release,feature request,assigned,,2011-12-21T01:42:05Z,2016-10-04T17:57:10Z,"A theme should be able to register that they are designed to have a static front page by default. Core should then pick up on this as part of the activation process and allow them to pick or create a page, or ignore it and show posts on the front.
Twenty Twelve will most likely need this (http://wpdevel.wordpress.com/2011/12/20/default-theme-twenty-twelve/).",nacin
Very Popular,22355,Template stack - Beyond parent/child theme relationships,,Themes,,normal,normal,58,Awaiting Review,enhancement,new,has-patch,2012-11-03T21:45:25Z,2015-10-21T21:32:47Z,"'''Problem'''
Robust plugins (!BuddyPress, bbPress, et all) are unable to break out of the parent/child restrictions that !WordPress imposes on template output. For these plugins to include their own template parts, elaborate code must be written to hook into several different execution points, requiring an intimate knowledge of the inner workings of !WordPress's template loading system.
Create a stack of template locations, and allow !WordPress to transverse this array following the same STYLESHEETPATH/TEMPLATEPATH order it always has, while also enabling additional paths to be added with a priority (similar to the filters API.)
The attached patch includes two new functions in wp-includes/template.php:
* register_template_stack()
* get_template_stack()
Register template stack is a wrapper for the 'template_stack' filter. get_template_stack() is a variation of apply_filters() that returns the array of filtered template locations.
A modification to wp-settings.php calls register_template_stack() two times, passing get_stylesheet_directory() and get_template_directory() as callbacks, to initialize the core parent/child relationship, ensuring complete backwards compatibility.
This allows for plugins to register additional paths in the template loader hierarchy, and enables plugins that may come with their own default template parts the option of registering a fallback template location.
This works with both locate_template() and get_template_part(), and has the added benefit removing duplicate items inside of get_template_stack(), resulting in avoiding an additional file system check should the parent and child themes be the same.",johnjamesjacoby
Very Popular,22316,Plugin Dependencies (Yet Another Plugin Dependencies Ticket),,Plugins,3.4.2,normal,normal,55,Awaiting Review,enhancement,new,dev-feedback,2012-10-30T16:30:46Z,2015-10-16T09:25:25Z,"''Previously: #10190 #11308 #13296 and I'm sure many more''
It's been a few years since we looked at plugin dependencies and this still seems to be a feature people really, really want, especially for shared functionality that isn't a plugin in itself. For example a PHP library that isn't popular enough to be in core but is popular enough to be bundled in multiple plugins.
A bunch of us sat down and talked about this at this year's WordPress Community Summit and there was a lot of enthusiasm for this type of functionality.
We didn't know about the existing tickets at the time but the general summary of what we came up with was this:
* Plugins list WP.org slugs of their dependencies in their `readme.txt`, or perhaps better their plugin's header.
* When you go to install a plugin via the plugin directory UI in the admin area, the WP.org API returns a list of dependencies along with the data about the plugin being installed. WP would say like ""these following dependencies will also be installed"". This means it's seamless to the user -- they install a plugin and the other plugin(s) that are needed get installed too.
* No versioning support. It's too complicated and what if one plugin wants an older version of a dependency than another plugin does? If your plugin is listing another as a dependency, then it's your job to make sure it stays compatible with the latest version of the dependency. On the flip side, hopefully plugins that get listed as dependencies are made to be forwards and backwards compatible.
* Probably not allowing the disabling of plugins that are dependencies while their dependents are active. This seems better than disabling the dependents when the dependency is disabled (""why did Foo get disabled? I only disabled Bar!"").
* On plugin re-activation or on activation of a plugin uploaded via FTP, make sure it's dependencies are already installed. If not, offer to install them. If installed but disabled, just enable them for the user.
So while the previous tickets were closed as `wontfix` in the past, I think this is worth taking another look at. A lot of planning and thought will be required though to get this right.",Viper007Bond
Very Popular,36292,Rewrites: Next Generation,rmccue,Rewrite Rules,,normal,normal,53,Future Release,feature request,assigned,,2016-03-22T06:38:33Z,2016-06-06T05:34:43Z,"Let's start improving rewrites. The current rewrite system is outdated and clunky for modern development, and was one of the most complained about pieces of WordPress when I [https://twitter.com/rmccue/status/710460165879898114 enquired on Twitter]. Here's what I'd like to change.
== Part 1: Separate rules from WP Query ==
This has two parts. Firstly, we need to ensure any rule can be mapped to any set of arbitrary query parameters. Right now, this is quite hard to do for the more complex query parameters, such as [https://roots.io/routing-wp-requests/ date query]. Doing this will eliminate the need for temporary/intermediate query vars; these are typically used temporarily during the rewrite process, then changed into actual query vars in `pre_get_posts`.
The second part of this is breaking the interdependency between rewrites and the main query. Currently, it's not possible to have a page that doesn't generate a main query. #10886 has attempted to tackle this in the past, however has run up against problems. This is important for things like user profile pages, and can immediately be used in core for the REST API. The current solution for these is to hook in at `parse_request`, but this causes some hooks not to be run, and changes the overall flow of a WordPress request.
Part 1 will introduce a Rewrite Rule Interface that will allow better customisability of rules as well.
== Part 2: Ensure the rewrite process is DRY and testable ==
This part will decouple the rewrite process from the global state to ensure testability. @ericlewis has made a fantastic start on this in #18877, which works well with some of the refactoring from part 1.
In separating from the global state, we may be able to reuse `WP_REST_Request` as a more generic `WP_HTTP_Request` (it was designed for this from the start).
This should also start cleaning up the `WP` and `WP_Rewrite` classes as concerns get a cleaner separation. Currently the boundary between the two is pretty unclear.
== Part 3: Rework flushing ==
The `rewrite_rules` option and the flushing process are one of the toughest bits of the rewrite process. The fact with these is that they're a caching process that significantly predates transients and object caching. The reason flushing exists is to avoid regenerating expensive rules (like one-rule-per-tag) on every request, but we can create a better system using the newer tools available in core. An opt-in system for rewrite caching could potentially work well once we have a solid Rewrite Rule Interface that allows us to identify and group rules. (For example, a `WP_Rewrite_CachedRuleInterface`.)
#29118 digs into some past work on this front; automatically flushing rewrites is already possible.
== Other Changes ==
Note that these parts are in a rough order, and get more vague as they go on. We need to incorporate feedback after changes are made, and these changes might need to be reworked or rethought with previous feedback in mind. There are also other changes we may want to make based on feedback from the community.
Very Popular,32417,Add new core media widget,wonderboymusic,Widgets,4.3,normal,normal,53,Future Release,feature request,assigned,needs-unit-tests,2015-05-16T03:14:25Z,2016-10-14T17:14:08Z,"Adding images to your widget areas is a common, yet currently incredibly tedious task -- you need to upload it in your media library, find the url, copy the url, and then manually add an image tag inside of a text widget. That's a lot to ask for a beginner user to do. We should include a default image widget in core to make this task easier.",melchoyce
Very Popular,8592,Private Pages not listed in the Parent dropdown,SergeyBiryukov,"Posts, Post Types",2.7,normal,major,51,Future Release,enhancement,assigned,has-patch,2008-12-12T16:22:24Z,2016-09-28T12:47:21Z,"Private pages are not available as a choice in the Parent dropdown of the Attributes module.
You should be able to create a hierarchy of private pages if you want to.
Tested with r10194.",mtdewvirus
Popular,16379,"Better UI for doing ""Page on Front""",,"Posts, Post Types",3.1,normal,normal,49,Future Release,task (blessed),new,,2011-01-26T19:47:25Z,2016-10-20T17:06:56Z,"[[Image(http://grab.by/grabs/132427e6c1166ed3e4d8214959b9568a.png)]]
This is the existing ""Page on Front"" UI. The process is as follows:
1. Create a ""Front"" Page
2. Create a ""Blog"" Page
3. Select the ""Front"" Page in the ""Front Page"" dropdown
4. Select the ""Blog"" Page in the ""Blog Page"" dropdown.
1 and 3 make sense. If you want a page on front, then you obviously need to create a page to live there, along with its content, and then designate it. But the ""Blog"" page is just a dummy. It's sole purpose is to create and maintain a URL for your blog. So why not just have something like this?
Blog URL: http://example.com/ {input box}
If a page exists in the URL they type, it gets used. If not, we create one on the fly as a dummy. This seems a more natural way of doing it. You don't care about the dummy page — you just want to choose an appropriate URL for your blog.",markjaquith
Popular,32101,Ability to mark plugin as unmanaged,DrewAPicture,Plugins,4.1.2,normal,normal,48,WordPress.org,task (blessed),assigned,has-patch,2015-04-24T07:48:54Z,2016-09-19T20:20:59Z,"We've had a rather unpleasent incident where we used a certain plugin name for a private plugin, but then another plugin appeared under the same name in the theme directory, marking our plugin for an update. Rest assured ''someone'' clicked on the update button, replacing our plugin with some other.
Such conflicts may seem rare, but they do happen. Adding an optional, defaults to false, `private` field to the theme header (like npm/Bower) to disable update checking for such a plugin would be an easy fix. ",damonganto
Popular,37974,Add multi-panel feature to pages through add_theme_support,,Themes,,normal,normal,48,Future Release,task (blessed),new,,2016-09-07T19:59:29Z,2016-10-20T16:40:48Z,"Making a multi-panel page and giving users the ability to chose what content is in those sections this is something people really want. There are a lot of methods to do this, from plugins to within themes. As a result, there's a lot of confusion for users.
At Automattic, we've now done this in several themes through a 'Theme Options' section. In this ticket, I am suggesting a way that this comes back to core.
Before I dive into this suggestion, I will say that I think there are absolutely other ways. In the long run I would also love to see content blocks make this feature obselete. But, this option is user tested. This is the best, proven method for users to get this. It also should be a lot less difficult and more time efficient to achieve. I'd love to see this be part of this release.
How would this happen? Lets look at a flow suggestion.
1. There is a new section under the Customizer called 'Multi Panel' - we totally should come up with a better name.
2. You can click in and see each panel here.
3. You then from those panels can click in and add content to the panels.
Stepping through that this in code would appear something like this:
1. add_theme_support(multipanel-page, 4);
`// 4 being number of panels and unlimited being the default.`
For simplicity I am just suggesting it's a simple add_theme_support. We have past precedence for this. Then you'd get the new section in Customizer appear. I also suggest this gets made as a feature plugin porting pretty much all of the existing code. At least this makes sense as a first step.
Template wise, we probably want a consistent naming for this or to have people able to declare a template page. It could then have that page used as a static page, or just be used. You could either use one wrapping content for all or call each panel (if set numbers) and style each differently. This opens up to some flexibility with layout.
This type of multi-panel page can be seen already live in themes like Pique: https://en-gb.wordpress.org/themes/pique/. There's good evidence from user testing that currently this is the best option too.",karmatosed
Popular,18909,Bundled jQuery UI should have CSS,,External Libraries,3.3,normal,normal,45,Future Release,enhancement,assigned,,2011-10-11T18:53:57Z,2016-02-22T21:29:23Z,"Now that all of jQuery UI is in core, matching CSS should also be included for use in the admin in both color schemes.
Related: #17952",helen
Popular,35669,Store widgets in a custom post type instead of options,,Widgets,2.8,normal,normal,45,Awaiting Review,enhancement,new,dev-feedback,2016-01-30T20:00:34Z,2016-08-19T06:46:27Z,"Widget instances are stored in options. For a multi-widget (`WP_Widget`) the widget instances of a given type (`id_base`) are stored in a serialized array of instance arrays. A widget ID is comprised of a widget's `id_base` followed by a number which is the array index for that widget instance. For example, the third-created Text widget would have the ID `text-4` (note that multi-widget numbering starts at 2). Old single widgets do not include the numeric index after the `id_base`, and technically they could be stored anywhere (see #35656 for suggestion to deprecate old single widgets).
== Issues
There are several problems with how widgets are currently stored as options.
'''Scalability:''' For sites with a large number of widget instances, the entire collection of widgets must be unserialized with each request to access only one widget of a given type. (Note #23909 for how all widget instances get registered with every request.) For sites that use Memcached as an external object cache where cache buckets have a 1MB limit, since all widget instances of a given type are stored in a single option, sites with a huge number of widgets will overrun this limit. What's more is that widget options get registered as autoloaded, so all widget options will get combined together in the `alloptions` key, making widgets even more liable to overrun the 1MB cache bucket limit in Memcached.
'''Concurrency:''' Since all widget instances of a given type are stored in a single option, if two users attempt to update two separate widgets at the same time, it is possible that one of the updates will get lost (see #31245). Additionally, the widgets admin page and widgets in the Customizer both get loaded with the max number (array index) for each widget type. When a new widget instance is created, this maximum number is incremented in memory and used in the new widget ID which is then passed to the server for saving. If two users have loaded the UI at the same time, when they both create a widget of a given type and save their widget changes, the one who saves last will overwrite the other user's widget since the two widgets would have the same ID. (See #32183 for more about the widget ID collisions, and see [https://wordpress.org/plugins/customize-widgets-plus/ Customize Widgets Plus] for a "Widget Number Incrementing" component which uses Ajax to generate new widget IDs in a more concurrency-safe manner.)
'''Addressability:''' As noted above, widget instance IDs are comprised of the widget type's `id_base` followed by the array index `number`. Two different widget instances can have the same `number`, such as `search-3` and `text-3`, since the `number` is incremented in the scope of the instances of the given type. No other objects in WordPress are identified by strings in this way, that is as of now: taxonomy terms actually used to have to be addressed by a numeric term ID and taxonomy name until term splitting happened in 4.2 (see #5809). Now, however, a term can be uniquely identified by a single integer ID.
All of the above issues would be resolved by switching to store widget instances in a custom post type, where each widget instance has a single unique auto-incremented post ID.
== Advantages
Storing widgets in custom post type has several benefits beyond fixing the above issues, including:
* widget authorship attribution
* revision history
* import/export
* querying
* widget drafts
* scheduled widgets
== Data Migration
Migrating widgets from options to a custom post type would involve some tedious data migration to update all references to current `id_base-number` widget IDs to their new integer IDs. The old widget ID could actually be copied directly into the `post_name` field for the `widget_instance` posts. Backwards compatibility for the `sidebars_widgets` option containing the old-style IDs may be necessary. Newly created widget IDs could have `post_name` fields populated with the `id_base` followed by the post ID. This switch would also necessitate discontinuing to register all widget instances with every request (#23909).
== Sidebars and Widget Groups
Perhaps out of scope for this ticket, but the way that widgets get associated with sidebars should also perhaps be changed to follow the pattern of how nav menu items are associated with a nav menu via a taxonomy term. The implementing of widget groups (#19912) could be the right opportunity to do this, where a `widget_grouping` taxonomy could be introduced, and when a grouping is assigned to a sidebar, the backwards-compatible widget IDs could be copied into the existing `sidebars_widgets` option. Otherwise, backwards compatibility might entail adding `pre_option_sidebars_widgets` filter.
== REST API Impacts
For more on widgets and now they relate to nav menu items in the context of a harmonized interface via the REST API, see https://github.com/WP-API/wp-api-menus-widgets-endpoints/issues/10
== Feature Plugin
See the [https://github.com/xwp/wp-customize-widgets-plus Customize Widgets Plus] feature plugin's "Widget Posts" module for an initial implementation of storing widgets in a `widget_instance` custom post type. This plugin depends on #32474 which facilitated plugins to store widgets in posts instead of options.",westonruter
Popular,23912,Add Composer package description,,Build/Test Tools,3.5,normal,trivial,42,Future Release,enhancement,new,,2013-03-30T20:44:16Z,2016-08-28T14:52:16Z,"WordPress, as software download, lacks machine-readable source of meta information about it. For PHP projects de-facto standard for such is Composer via `composer.json` file in project root.
While WP currently doesn't use or need Composer dependency functionality, it will help provide information to developers and improve WP usage ''as'' dependency in projects that make use of Composer.
Suggested `composer.json` draft:
""name"" : ""wordpress/wordpress"",
""description"" : ""WordPress is web software you can use to create a beautiful website or blog."",
""keywords"" : [""blog"", ""cms""],
""homepage"" : ""http://wordpress.org/"",
""license"" : ""GPL-2.0+"",
""authors"" : [
""name"" : ""WordPress Community"",
""homepage"": ""http://wordpress.org/about/""
""support"" : {
""issues"": ""http://core.trac.wordpress.org/"",
""forum"" : ""http://wordpress.org/support/"",
""wiki"" : ""http://codex.wordpress.org/"",
""irc"" : ""irc://irc.freenode.net/wordpress"",
""source"": ""http://core.trac.wordpress.org/browser""
""require"" : {
""php"": "">=5.2.4""
Popular,18584,Nav menus need more hooks for extensibility (on admin page & in customizer),,Customize,3.3,normal,normal,42,Future Release,enhancement,new,has-patch,2011-09-04T02:38:16Z,2016-09-16T05:56:38Z,"I'm trying to add some additional fields to the nav menu blocks but sadly there are no hooks for doing so. Zero.
We should add some and get in a better habit of just doing so when the code is written.
My specific suggestions are before the Remove/Cancel links (i.e. for adding standard stuff), one above the ""original"" field, and one after those action links (to add more actions).
We need to account for both extending the menus admin page and menus in the customizer.",Viper007Bond
Popular,21256,"New theme feature - add_theme_support( 'content-width', $defaults )",chriscct7,Themes,3.4.1,normal,normal,42,Awaiting Review,feature request,assigned,dev-feedback,2012-07-13T10:08:34Z,2015-12-03T06:23:21Z,"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
Popular,24251,Reconsider SVG inclusion to get_allowed_mime_types,,Upload,,normal,normal,41,Awaiting Review,enhancement,reopened,early,2013-05-02T19:36:57Z,2016-09-22T09:38:57Z,"There are some who think SVG should be included in core as an allowed mime type. Makes fine enough sense to me, since there is a good argument for it, and we have support for WordPerfect documents...so there's that.
Related: #20990",JustinSainton
Popular,14877,Ability to create exclusive custom taxonomies,helen*,Taxonomy,,normal,minor,39,Future Release,feature request,accepted,,2010-09-15T14:08:25Z,2016-08-31T22:00:22Z,"Custom taxonomies should have the option of toggling exclusivity, meaning the user should only be able to select one term at a time.
Currently, developers wishing to implement an exclusive custom taxonomy (and thus would prefer radio buttons rather than check boxes on the add/edit post pages) must remove the existing taxonomy meta box completely and build their own, simply to change the input type. This not only duplicates code and development effort, but has the potential to create security vulnerabilities when plugin developers stray from best practices, for example, when recreating the AJAX add term functionality.
Exclusive taxonomies are not uncommon in every day life and are even more common when one thinks about typical custom post type implementations (e.g., students->school year, employee->department, car->color, ice cream->flavor).
While the best implementation is uncertain, I propose the function register_taxonomy accept an optional 'exclusive' argument (similar to 'hierarchical') that would change the check boxes within the taxonomy meta box to radio buttons and would handle the POST accordingly.",benbalter
Popular,16031,Bulk actions: Reactivate bulk actions hook + add hander hook for all admin screens,ericlewis,Administration,3.1,normal,normal,38,4.7,enhancement,assigned,,2010-12-29T20:31:04Z,2016-10-24T20:41:03Z,"The new bulk actions filter allows you to modify the bulk-actions arrays, but neglects to add the ability to handle the new custom actions.
The fix is to simply add one new do_action() hook to the default case of each affected page (similar to the way 'wp_ajax_' handles custom ajax requests).
For example, the following might be added to users.php at line 285, immediately after default:
do_action( 'bulk_action-'. $wp_list_table->current_action() );",Veraxus
Popular,16413,Settings page needs HTML refactoring and UI improvements,helen,Administration,3.1,normal,normal,37,Future Release,enhancement,assigned,,2011-01-30T20:22:09Z,2016-09-12T17:32:55Z,"The settings pages haven't had much attention or improvement in a while.
We need to refactor the HTML on the settings pages, as they are still using tables instead of divs.
We also want to make some minor UI improvements including:
- clearer differentiation between option groupings
- using consistent text styles for descriptions and links (including the time zone/date format comment)
- restructure for better readability
Comment if you have any other",chexee
Popular,17268,Use native gettext library when available,,I18N,,normal,normal,37,Future Release,enhancement,new,has-patch,2011-04-28T11:32:30Z,2016-08-17T14:57:59Z,"[http://codex.wordpress.org/Translating_WordPress Here] you say that the GNU gettext-Framework is used. Exactly, ""pomo"" (file: wp-includes/l10n.php) is a complete own php-implementation of the gettext-program.
I've added a patch to solve this problem. Maybe it is not very good, but it works. On my wordpress-sites, the used php-memory returns from about 65% to about 12% and the site is running much faster when patching wp-includes/l10n.php.
I know that gettext is not available on every wordpress-installation, but when it's available, it should be used.
Sorry for my bad english, I'm german.",linushoppe
Popular,13239,Filter locate_template template_names variable,,Themes,3.0,normal,normal,37,Future Release,enhancement,reopened,has-patch,2010-05-03T21:43:05Z,2016-10-11T08:25:26Z,"I recently encountered a situation where it would be very helpful to supply alternate template file locations; however, this cannot be accomplished as the locate_template function is being used and that function's arguments are not filterable. So, I created a patch that adds the filter.
This patch adds two filters: locate_template and locate_template-TEMPLATENAME. This allows for both general and specific filtering.
The following example shows how this could be used to modify the location of a BuddyPress template file.
function filter_member_header_template( $template ) {
return dirname( __FILE__ ) . '/buddypress/members/single/member-header.php';
add_filter( 'locate_template-members/single/member-header.php', 'filter_member_header_template' );
While the value of this example is debatable as BuddyPress could be updated to support alternate template locations, the value of the patch itself is high. This opens up a new ability for plugins to modify template file locations, giving plugins a hook into the content rendering process without requiring themes to be modified.",chrisjean
Popular,19867,wp_dropdown_users() still not scalable,,Users,3.3.1,normal,normal,36,Future Release,enhancement,new,has-patch,2012-01-20T22:04:27Z,2016-09-22T20:03:00Z,"#14572 made huge improvements to the performance of wp_dropdown_users(), however, on certain sites that have an unusually large set of authors, wp_dropdown_users() still isn't usable. It either causes a memory error on the server, or potentially crashes the client browser due to content size.",prettyboymp
Popular,12702,Enable sticky post checkbox for custom post type Publish metabox,,"Posts, Post Types",,normal,normal,34,Awaiting Review,feature request,reopened,close,2010-03-25T05:27:30Z,2016-03-10T18:42:39Z,"When a custom post type is created, there is no checkbox to mark it as a ""Sticky"" post.
In meta-boxes.php there is a check:
if ($post_type == 'post'): ` and never closing that tag, on the oembed returned markup, right before `
I did some tracing and found out that it was `wpautop` fault. Even though `WP_oEmbed::_strip_newlines()` was successfully stripping the new lines from the returned oEmbed HTML, something was adding an extra newline before the `\s*|', '', $pee );
Now the oembed is fully functional and doesn't have that unclosed ` ` tag:
Lisbon with #WordPressVIP @ Terreiro do Paço http://instagram.com/p/vGw5IchocB/ — Henrique Mouta (@vaurdan) November 7, 2014 tags are generated when shortcodes are followed by HTML tags and wpautop is enabled,,Formatting,3.4.1,normal,normal,4,Future Release,defect (bug),new,needs-unit-tests,2012-08-26T06:58:21Z,2015-10-13T04:33:17Z,"This bug was encountered in separate plugins, but it seems that its source is in the core:
Noteworthy,18136,WordPress Adding Spurious
foreach ( $wp_roles->role_names as $role => $name ) :
echo '
'; echo '
Role displayed in Admin as ' . $name ;
echo ' Database entry: ' . $role . '';
echo '
Capabilities assigned to the role of ' . $name. '';
// print_r( $caps);
echo '
$rolename = get_role($role);
$caps = $rolename->capabilities;
foreach ($caps as $capability => $value):
echo $capability . ' '. $value . ""\n"" ;
echo '';
the default wp roles return the following capability value pairings
delete_published_posts 1
roles created with Justin Tadlock's members plugin return the following
delete_published_posts delete_published_posts
roles created manually in functions.php utilizing
add_role( 'test_role', 'Test Role' );
//saved and then removed before running the code below ...
$role = get_role('test_role');
return the following ...
delete_published_posts 1
but lack the user levels as mentioned above.
Let me know if there is any further info I can provide to help sort this out~
Popular,17924,Make Integrating Multiple Roles Per User Easier for Plugin Authors,,Role/Capability,2.0,normal,major,31,Awaiting Review,enhancement,new,dev-feedback,2011-06-28T23:40:48Z,2016-08-12T14:59:59Z,"WordPress supports multiple role per user, however to use this feature is very difficult for plugin authors to integrate well, and often requires adding plugin admin pages instead of integrating with the pre-existing user-edit.php. Due to the difficulty of this, and the fact that most plugins that allow this aren't very user-friendly, I believe users are staying away from multiple roles.
This ticket aims to change how easy it is to work with the current role management system, as well as to add a couple role-based filters and actions, while still keeping the front-end of the administrative interface single-role only. (Because it seems to be the prevailing opinion the multiple roles per user is plugin territory.) In addition, I completely agree that the vast majority of sites can best function with one role per user, however in some cases (such as the site I'm working on now) you simply need to be able to choose multiple roles.
= Changes =
== First Patch File ==
The first patch file moves the code for the role dropdown off of /wp-admin/user-edit.php, /wp-admin/includesclass-wp-users-list-table.php, /wp-admin/users-new.php, /wp-admin/options-general.php and into /wp-admin/includes/template.php where two new functions are created:
=== {{{wp_get_dropdown_roles()}}} ===
This function does what {{{wp_dropdown_roles}}} used to do, but it returns the value instead of echoing it. (Note that {{{wp_dropdown_roles()}}} now acts as a wrapper for {{{wp_get_dropdown_roles()}}}. (The old function is still in place for backwards compatibility.)
=== {{{wp_user_role_selector()}}} ===
This function creates the full dropdown and applies a new {{{'user_role_selector'}}} filter to the markup before echoing it out. This way the default dropdown can be overridden by something else (perhaps checkboxes).
== Second Patch File ==
The second patch file changes the functions that handle user creation and updating so they can be hooked into and a developer could make this work with multiple roles. This file affects /wp-admin/includes/users.php and /wp-includes/user.php.
=== {{{wp_sanitize_user_role()}}} ===
A new {{{sanitize_user_role}}} filter was created and sanitation of {{{$_POST['role']}}} in /wp-admin/includes/user.php when user-edit.php is submitted was moved there. The new function is called {{{wp_sanitize_user_role()}}}. (This is so that if user-edit.php is submitted and {{{$_POST['role']}}} were to contain a value other than a string (perhaps an array of roles) it can be sanitized and worked with accordingly.
=== {{{pre_user_role}}} ===
A new {{{pre_user_role}}} filter was added to {{{wp_insert_user()}}} in /wp-includes/user.php. This was mainly done because almost every other field that this function processes has a matching filter like this, and I thought maybe {{{$roles}}} felt left out as it did not. :(
I supposed somebody could also use it for something useful as well.
=== {{{apply_user_role}}} ===
A new {{{apply_user_role}}} action was added to {{{wp_insert_user()}}}. The function itself no longer uses {{{$user->set_role()}}}, instead saving user role changes is now handled by this new action. A matching function {{{wp_apply_user_role()}}} was added to set the user role like {{{wp_insert_user()}}} used to do. This way however, a plugin author could simply hook into {{{apply_user_role}}} to apply multiple roles to a user.
= Conclusion =
All in all, this patch was designed so that the average user would never even notice that a change has been made to user management, however a plugin author looking to add an easy way for people to select multiple roles for a user can quickly hook into this and have a nice, easy, well integrated and WordPress-like plugin.
I have done a few tests adding users and changing roles around with these patches applied on a fresh installation with no plugins and the only changes to WordPress being those that are in the attached patches, and everything seems to work seamlessly.
By the way, I am quite new to WordPress, so I added the needs-testing tag, because it does, but I also want to make sure I've done everything the 'WordPress' way and I want to make sure I havn't missed anything that is broken because of these small changes.",mobius5150
Popular,20299,"Preview changes on a published post makes all post meta ""live""",adamsilverstein,Revisions,3.3.1,normal,major,30,Future Release,defect (bug),assigned,dev-feedback,2012-03-25T02:02:16Z,2016-07-04T21:05:42Z,"Here's the use case. Client wants to preview an update to a published post (as the Preview Changes button correctly implies they can). This post has some important post meta that impacts that preview.
Here's the problem - because post meta is not saved to a revision (it looks for the ""real"" post), when the preview button is pressed, save_post runs, and saves the meta data to the real, published post, even though the user only intends to preview the change.
Without realizing it, the user has updated the published version. That can be prevented by not saving post meta to revisions (when using custom save_post hooks), but then there's no non-hacky way to actually preview the full changes.
I believe this bug has been present for a while, we just rarely use the Preview function on published posts, and when we do, probably never tested it with critical post meta.",jakemgold
Popular,32678,Audit toolbar links and content,helen,Toolbar,,normal,normal,30,Future Release,enhancement,assigned,has-patch,2015-06-17T19:56:43Z,2016-08-26T14:27:38Z,"We've done some tweaks here and there in the toolbar, such as changing where links go or adding/removing some, but I don't think we've really taken a wider view of its general contents since 3.2 in #17705. Right now, some links take you into the customizer context without warning (as do a couple in the admin menu), which is quite jarring. We need context for each link to be clearer, and a good hard look at how the toolbar actually gets used and if it's really working to help get users to where they need to go more quickly.
At the very least, for 4.3, we need to resolve the issue of mixing customizer links in with dashboard links.",helen
Popular,20491,Introduce some JavaScript i18n functions,swissspidy,I18N,,normal,normal,29,Future Release,enhancement,assigned,has-patch,2012-04-19T18:50:24Z,2016-10-17T09:17:23Z,"There's JavaScript code dotted around core that handles i18n in JavaScript (for example, localised thousands separators in the pending comment count). We should bring this together into a wpL10n JavaScript library that can be reused by plugins.
I've done some work on this and I'll get a patch up in the next day or so.",johnbillion
Popular,12718,Better structure for admin menu,,Plugins,,normal,normal,29,Future Release,enhancement,reopened,dev-feedback,2010-03-26T01:05:37Z,2016-09-13T16:54:31Z,"Currently, the global $menu variable is one big linear array:
$menu = array(
[2] => array('Dashboard', ...
[4] => array('', 'read', 'separator1', ...),
[5] => array('Posts', ...)
To allow plugins to add a menu item at the end of a group, we use a bunch of additional global variables that remember the last element in each group.
Also, we use arbitrary numeric indexes to specify the order of the items, instead of being able to position items relative to one another.
It's all very low level. Things would be a lot easier if we had an actual API for manipulating the menu items.",scribu
Popular,27177,Child themes should inherit parent theme customizer settings on activation / switching,,Themes,3.8,normal,normal,29,Awaiting Review,enhancement,new,has-patch,2014-02-21T20:37:01Z,2016-09-28T16:38:41Z,"Currently, if you install a parent theme and utilize the theme customizer, and then create a child theme and live preview or activate it, it does not inherit any of the settings previously set for the parent theme.
If a child theme doesn't have any existing values from the customizer setting, then it should look for and import those from the parent theme if they exist (perhaps on the switch_theme hook).
The current setup is a discouragement to using a child theme if the user has already invested time using the customizer with their parent theme.",krogsgard
Popular,7756,AJAX saving method instead of reloading the page,,Editor,,normal,normal,28,Future Release,enhancement,new,,2008-09-16T17:36:44Z,2016-02-08T11:14:52Z,"Instead of using a traditional page refresh after saving a post, utilize AJAX, similar to how auto-saving already functions, to save the post.
this would help decrease the load on the server and enhance the user experience.",jdingman
Popular,33381,Strategize the updating of minimum PHP version.,jorbin,General,,normal,normal,28,Awaiting Review,enhancement,assigned,dev-feedback,2015-08-14T23:50:16Z,2016-04-20T04:28:12Z,"I'd like to formally petition for the drafting of a strategy and timeline of when WordPress might be updated to a supported minimum PHP version.
This is something that's been discussed to death in the community, but little concrete information or answers seem to be available. I couldn't find a trac ticket, so my apologies if this is a duplicate.
It is my view that:
1. PHP EOL should not be open to interpretation.
2. While other parties may continue to provide LTS for EOL PHP versions, this does not make it the responsibility of WordPress. We depend on PHP itself, not a hybrid or undead version of it.
3. WordPress should move towards an official statement that a supported version of PHP is a requirement. (As in it must be on this page: http://php.net/supported-versions.php)
4. Failing to comply with PHP EOL is a disrespect to the fine folks making PHP who are working hard to release updates in a manner that is sustainable longterm for everyone.
Hopefully, we can all agree that this is just a matter of ""when"" and not ""if"". I'd really like to see that ""when"" put on the calendar. I'd imagine it would be years down the road, but at least we can have that to look forward to.
I know that we're still waiting for version numbers to decrease. By now I'd argue that no change will happen until WordPress necessitates it. Considering how far past EOL we've become, is that not reasonable?
Popular,23314,Allow published posts to be revised without being updated immediately,,Revisions,,normal,normal,28,Future Release,enhancement,new,has-patch,2013-01-29T19:39:01Z,2016-01-29T18:48:20Z,"Two things. Let's allow contributors to submit changes for review to their published posts. Let's also allow users to make changes to their posts and pages and save those changes, without updating the published post or page.",kovshenin
Popular,31696,"Better select, multi-select, and autocomplete/suggestion inputs in the admin",,Administration,,normal,normal,27,Future Release,enhancement,new,dev-feedback,2015-03-19T16:47:15Z,2016-07-17T17:59:45Z,"I know this has been brought up before, but can't find the original ticket. That said, a few months ago Helen brought up a potential integration of the Select2 library but, due to licensing issues, we were unable to proceed with it at the time ([https://github.com/select2/select2/issues/2468 GH issue]). The licensing issue has now been resolved and, since I've been unable to find the original ticket, I'm opening a new one along with a preliminary patch to add Select2 to core.
At the moment, this patch is based on a new CSS class (select2) being added to any select field that should implement the Select2 library. I've added it to the select fields on the Settings->General page as an example, but didn't want to implement it system-wide until the community had a chance to speak up RE: where does/doesn't Select2 belong, or should it actually be implemented everywhere. The language and timezone fields seemed an obvious choice given their inherent size, but things like the emoji field under Settings->Reading that have a finite number of options seem less obvious.
Popular,22435,Export API,,Export,,normal,normal,27,Future Release,enhancement,new,dev-feedback,2012-11-13T16:41:55Z,2016-08-19T03:40:55Z,"From experience and from tickets (#19864, #19307, #17379) it's evident that we need to update the export API.
High level goals:
* To be usable from different parts of the code. From the web backend, from a CLI script, from an async job.
* To allow more control of the output format – serve over HTTP, write a single XML file to disk, split it and write many smaller XML files, write a big zip with many XML files, etc.
* To allow exporting the data without querying all the posts at once, so that we can fit the exports to memory.
* Keep {{{export_wp()}}} for backwards compatibility without the need to keep all (even any) of its code.
Here's my idea for the part of the API 99% of the developers touching export would use and be happy:
'2011-10-10', 'post_type' => 'event', … ) );
backup( $export->get_xml() ); // string
$export->export_to_xml_file( 'mom.xml' );
send_to_mom_to_import( 'mom.xml');
$export->serve_xml(); // with all the headers and stuff
$export->export_to_xml_files( '/files/exports-for-my-awesome-website/', 'export-%02d.wxr.xml', 5 * MB_IN_BYTES );
Before I dive into implementation details (in the comments, not to pollute the ticket), I'd like to hear what use cases for extending this code you have in mind and where should we draw the line. Adding more output writers? Adding custom export data? Adding formats different from WXR?
Popular,26511,Introduce a locale-switching function,swissspidy*,I18N,,high,normal,27,4.7,feature request,accepted,has-patch,2013-12-09T17:20:30Z,2016-10-24T21:47:27Z,"When a site's content is displayed in a language that's different to that used in the admin area ![1] by using the `locale` filter in `get_locale()`, the admin toolbar is shown in the language of the content, not the language of the admin area.
For example, if your content is in French (using `fr_FR` in the `locale` filter) but your admin area is in English (using `en_US` in the `locale` filter) then the admin toolbar on the front end will display in French rather than English.
The value of `get_locale()` is used when the translation files are loaded at the beginning of the page load, but there's no easy way to subsequently switch locale and load a different set of translation files later in the page load (ie. when we output the admin toolbar in the footer).
We should introduce a means of changing the locale at any point during the page load and automatically loading in the relevant translation files, overriding existing ones. This could then be used to switch the language before admin-related output on the front end (primarily the admin toolbar, but potentially any admin-related item).
Leaving this as a feature request for now because I don't have a solution in mind.
![1] Several plugins support this, such as [http://wpml.org/ WPML], [http://babbleplugin.com/ Babble] and [http://wordpress.org/plugins/admin-in-english/ Admin in English].",johnbillion
Popular,22363,Accents in attachment filenames should be sanitized,mikeschroder,Media,3.4,normal,critical,27,4.7,defect (bug),assigned,has-patch,2012-11-05T15:51:12Z,2016-10-22T02:40:12Z,"There is an inconsistency in the way WP is sanitizing post slugs and attachment filenames.
Sanitizing the post slugs is a Good Thing(tm) for non-english users who use diacritics in their post titles.
Example: If I write a post with the title ""Moiré patterns"", the actual page slug will be: ""moire-patterns"". The space is replaced with a hyphen, the ""é"" becomes ""e"". Even if I try to change the slug manually into ""moiré"", WP won't let me (for my own good, since that URL would break in lesser capable browsers).
For some reason, WP doesn't apply that error-correction to attachment filenames.
Example: If I attach a file named ""moiré pattern.png"", it gets renamed into ""moiré-pattern.png"".
We can see that the space (and some other forbidden characters) are corrected by `sanitize_file_name()`, but diacritics such as ""é"" or ""ä"" are left as they are.
Currently, most modern browsers are capable of displaying files with diacritics, but some of them still fail (most prominently, Safari).
For the sake of cross-browser compatibility, attachment filenames should benefit from the same safety measures that we apply for the post slugs (I guess that's the `remove_accents()` function).",tar.gz
Popular,20578,Allow users to delete a plugin without uninstalling,swissspidy,Plugins,,normal,normal,26,Future Release,enhancement,reviewing,,2012-05-01T01:18:35Z,2016-09-14T06:17:03Z,"Sometimes, a user may need to delete plugin files without deleting all the plugin data.",scribu
Popular,21022,Allow bcrypt to be enabled via filter for pass hashing,,Security,3.4,normal,normal,26,Awaiting Review,enhancement,new,dev-feedback,2012-06-20T01:34:26Z,2016-09-27T19:23:41Z,"Hi,
following recent discussions on password security and how to best prevent any hackers can leverage password table they might have got I looked into the phpass used for WordPress.
While I in principle understand why WordPress uses the compatibility mode of it, I would like to see some flexibility for those who don't need the compatibility.
Thus I would propose to change in wp-includes/pluggable.php all occurances of
$wp_hasher = new PasswordHash(8, true);
$wp_hasher = new PasswordHash(8, apply_filters('phpass_compatibility_mode', true));
This would allow users to easily change via plugin from the ""not so secure"" compatibility mode (only salted MD5) of phpass to a more secure setting (bcrypt) in case no compatibility with other applications is required.
The plugin changing the encryption methog could then as easy as
function phpass_bcrypt() {
return false;
add_filter('phpass_compatibility_mode', 'phpass_bcrypt');",th23
Popular,12877,Modular themes: Apply template hierarchy to folders within a theme,,Themes,,normal,normal,26,Future Release,feature request,new,dev-feedback,2010-04-06T16:26:15Z,2015-10-04T03:50:37Z,"Applying template heirarchy to folders within a theme will allow themes to be broken into modules, allowing theme developers to substantially reduce repeated code. This is an automated, complete version of the use of get_template_part() in Twenty Ten.
I've written posts on the [http://wp.me/pS0xt-1f justification for modular themes] and [http://wp.me/pS0xt-30 their potential to transform theme organization].
Based on [http://wp.me/pS0xt-3O my tests], these functions should cause no noticeable difference in performance.
The patch has the added benefit of creating an accurate global $wp_template_hierarchy object (and a getter method), so any plugin/theme can access the template hierarchy for $wp_query.
The patch introduces several new functions: get_template_module($folder), get_template_hierarchy(), update_template_hierarchy(), and 2 private functions.
Finally, the patch also add a 'locate_template' filter on $template_names at the beginning of locate_template(), and turns the large conditional in template-loader.php into a function: template_loader().",koopersmith
Popular,33472,Templating Engine,,Themes,4.4,normal,normal,26,Awaiting Review,feature request,new,,2015-08-20T21:01:36Z,2016-04-21T07:01:56Z,"Templating engines are being used everywhere, not just in other languages, but nearly all other PHP frameworks and CMS's that are actively maintained. Even Drupal 8 will be rolling out [https://www.drupal.org/theme-guide/8/twig Twig integration].
I wasn't able to find an actual discussion about this on Trac, so I definitely wanted to open the discussion. Should WordPress integrate a templating engine?
The benefits are obvious:
* Automatic escaping. No more escaping all the things every single time.
* Easier to read. This is sometimes down to personal opinion, but I and many others do find templating engines much easier to read than PHP templates
* Better separation of logic from templates. This isn't a guarantee, and depends on how strict the templating engine is, but it does help reinforce this.
* More to learn. I don't know '''how much''' more, but it is something to take into account
* Speed? I haven't looked up benchmarks lately, but another thing to potentially keep in mind
* Backwards compatibility. However this could be mitigated if plugins/themes had the option to use straight PHP or the templating engine.
There are many options available, Smarty isn't widely used anymore, but there is (http://twig.sensiolabs.org/ Twig) which is probably the most adopted, and (http://laravel.com/docs/5.1/blade Blade) has become rather popular.",KalenJohnson
Popular,18322,The Road to Magic Quotes Sanity,,Bootstrap/Load,3.2.1,normal,normal,24,Future Release,defect (bug),new,dev-feedback,2011-08-03T20:26:25Z,2016-04-07T07:51:14Z,"For back compat reasons, wp_magic_quotes() performs addslashes() on GPCS data. This is a pain, especially given that some core API expects slashes and some doesn't. In hopes of someday losing the automatic GPCS slashing, let's introduce a flag to turn off the slashing as well as slash and unslash functions that consult the flag. If slashing is on, these functions add and strip slashes. If slashing is off, they return data unchanged. Plugin authors can start using these functions and testing their code with GPCS slashing turned off and on. Eventually, GPCS slashing would default to off and all calls to the slash and unslash functions could be removed from core.",ryan
Popular,33717,Send Notification Email When a Comment is Approved From Moderation,swissspidy,Comments,,normal,normal,24,Future Release,feature request,assigned,has-patch,2015-09-04T00:43:09Z,2016-08-21T19:45:22Z,"Currently in WordPress, commenters have no idea their comment is approved unless they visit the page often. When a comment is held for moderation, WordPress should send the commenter an email notification when their comment is approved. I'm using the [http://wptavern.com/an-easy-way-to-notify-users-when-their-comment-is-approved Comment Approved] plugin to add this functionality to WordPress but I really think it should be a core feature. ",jeffr0
Popular,35214,Custom Comment Types,aaroncampbell*,Comments,,normal,normal,24,Future Release,task (blessed),accepted,,2015-12-24T00:28:11Z,2016-09-30T20:25:40Z,"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:
Popular,36534,Media Upload Issue Since 4.5 Upgrade,joemcgill,Media,4.5,normal,major,24,Future Release,defect (bug),reopened,,2016-04-15T06:11:32Z,2016-09-24T02:28:25Z,"Here is my problem: Since I updated to 4.5 yesterday, I can't upload certain image files. Every time I try, I get an error stating:
Fatal error: Maximum execution time of 30 seconds exceeded in /home2/scarlett/public_html/germany/wp-includes/class-wp-image-editor-imagick.php on line 358
I finally figured out that the problem is with the photograph's dimensions. All of the photos that won't upload were rotated from landscape to portrait on import. Their dimensions are 3000x4000 rather than 4000x3000 like the photos that I can still upload. After trying to save the photos without their metadata, turning off all plugins, and various other edits and experiments, it turns out that for some reason I only get the ""imagick"""" error on the photos that have a dimension of 3000x4000. Changing it to 2250x3000 (or anything less than 4000 for the height) allows me to upload them. I had no problem uploading files with this designation before I updated to 4.5. Everything else about the files is identical, and the file sizes do not conform to any kind of pattern and are not particularly large or small. As test, I tried to re-upload a photo that had this exact same ratio that I had uploaded successfully yesterday, and it would not upload today. This leads me to believe that there is something going on WP's end, since nothing has changed on the server side in the last 24 hours (and sadly my auto-backup was turned off somehow so now I am stuck with this).",unicornbacon
Popular,14459,Rotate Full Size Images on Upload,mikeschroder,Media,3.0,normal,normal,24,Future Release,enhancement,reviewing,has-patch,2010-07-29T23:16:17Z,2016-10-19T20:54:38Z,"It may be worth a revisit to #7042. Some mobile devices that use WordPress for Android are not capturing images in the correct orientation, instead they are writing the EXIF orientation to the image instead (which is a standard method these days). In wp-android and other external clients that offer full size image upload, these images will not be rotated correctly upon upload.
Since most mobile users are on the go with no access to the wp-admin area to rotate the images themselves, it would work best if the image was rotated for them automatically.
Hopefully there's a solution that wouldn't strip the EXIF data, some way to copy the EXIF data before rotating, then save it back again?",mrroundhill
Popular,24044,Add index to wp_options to aid/improve performance,,"Options, Meta APIs",,normal,major,24,Awaiting Review,enhancement,reopened,has-patch,2013-04-11T11:26:54Z,2016-08-24T23:59:40Z,"I work for a hosting company and we manage many '000s of WP sites for people. In order to improve the performance of all of these instances I find myself adding an index onto wp_options autoload many times daily.
I'm aware this is a small gain, but any gain is good.
This index will be hit on every single page load.",DanBUK
Popular,33885,meta_form performs a potentially expensive query,,Administration,4.3.1,normal,critical,23,Future Release,defect (bug),new,has-patch,2015-09-15T18:23:11Z,2016-08-18T00:50:20Z,"This is a follow-up to #24498 and the research that @tollmanz did on the query used in meta_form. To summarize:
The query in meta_form can be incredibly slow on sites with a lot of post meta.
The solution to me seems to be to cache the query and update the cache of meta to use every time a new piece of post_meta is saved. This will prevent the query from needing to be run on sites with a persistent cache. ",jorbin
Popular,21488,Add Default Callback Functions for add_settings_field(),,Plugins,,normal,normal,23,Future Release,enhancement,reopened,dev-feedback,2012-08-05T23:22:00Z,2015-10-01T03:37:00Z,"By default, when creating options in plugins and themes, every developer is required to create custom callback functions for rendering their option's HTML. The HTML for most options is nothing more than a standard INPUT field, a SELECT field, TEXTAREA field, etc, so there's really no reason there shouldn't be default callback options in place.
For example, if I have a plugin that registers one text field option in the General settings page, it really doesn't make sense that I should be forced to create a callback function, especially not when probably 99% of all text fields are outputted in exactly the same way:
` blocks is inconsistent in when it wants to trigger, some times it doesn't convert at all, other times it'll randomly convert it a while after you've stopped typing and I've been unable to lock down why this happens.
Currently tested on Chrome 49.0.2623.112 and reported in https://wordpress.org/support/topic/text-pattern-for-code-not-working-in-latest-trunk-version (which also includes a preview gif of the issues)..
I've tried with the code block being the only text on a line, as well as it being inline with other content, both ways seem to kick in when they feel like it with no observable pattern.
I've attached a screenshot showing the current random behavior as well.",Clorith
Noteworthy,29838,"Post editing area: keyboard accessibility, tab order and focus",,Editor,4.0,normal,normal,4,Future Release,defect (bug),new,,2014-10-02T16:27:31Z,2016-10-03T17:31:35Z,"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:
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
Noteworthy,38049,Rename Headings in TinyMCE,,Editor,,normal,normal,4,Awaiting Review,enhancement,new,,2016-09-14T00:33:15Z,2016-09-15T17:40:30Z,"Forking a proposal from #27159 where Heading 1 will be removed from TinyMCE in WordPress 4.7:
Multiple people have suggested renaming the Headings in the editor '''to encourage correct usage''' (that is the goal of this ticket). I would add that this might be combined with actually removing Headings 5 and 6 which I imagine are barely [properly] ever used. (Theme and plugin authors will always be able to add Headings back via filters.) Only having to name three levels of headings also makes this much more feasible.
A few ideas just to get things started.
'''Concept 1'''
- Heading (H2)
- Subheading (H3)
- Subsubheading (H4)
'''Concept 2'''
- Section Title (H2)
- Subsection Title (H3)
- Subsubsection Title (H4)
'''Concept 3 (use indentation to imply hierarchy)'''
- Heading 2
- – Heading 3
- –– Heading 4
At least at first, I think it would make sense to retain the HTML heading level in parentheses as shown above to help technical editors understand what's going on.
To encourage correct heading usage, the new labels must communicate to all editors that the heading levels are hierarchical and not selected based on perceived importance or (obviously) visual appearance.
One primary problem is ""what comes after sub? subsub?"" Most rich text editors editors I've looked at while writing this ticket either using ""Heading #"" OR give only two levels of Heading (which avoids the ""subsubsub"" problems).
- Medium [https://blog.medium.com/introducing-improvements-to-titles-subtitles-and-headings-97978206d8f9#.n4ygmct3p just changed their formatting toolbar to focus users on appearance over heading levels] because they were apparently being abused. I think this is pretty obviously the opposite direction this ticket intends to go (giving into visual over hierarchy).
- I honestly can't find other examples of editors doing this beyond the exceptions mentioned above, so examples are highly appreciated.
cc: @hugobaeta",mrwweb
Noteworthy,6619,permalink field misleading in page editor: it displays the erroneous values,,Editor,2.5,normal,normal,4,Future Release,enhancement,new,,2008-04-06T14:48:15Z,2016-10-16T00:25:41Z,"if you create a sub-page, the permalink field should display the proper permalink.
currently, if you have:
and when you create:
the permalink shows:
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
Noteworthy,38181,Add oEmbed support for Amazon Kindle Instant Previews,swissspidy,Embeds,trunk,normal,normal,4,Future Release,enhancement,assigned,has-patch,2016-09-28T16:43:05Z,2016-10-20T15:40:26Z,"[https://www.amazon.com/b?ie=UTF8&node=13489836011 Kindle Instant Previews] is a service that allows authors, media outlets and bloggers to embed a fully functional preview of a Kindle book into their site.
On September 10th, we launched our oEmbed endpoint. This patch allows Wordpress users to embed book previews from existing Kindle Instant Previews URLs as well as amazon.com URLs.",jsepia
Noteworthy,31502,Replace embed URL with error message if oEmbed provider returns an error,deremohan,Embeds,2.9,normal,normal,4,Awaiting Review,enhancement,assigned,has-patch,2015-03-02T11:13:28Z,2016-06-07T16:17:58Z,"If a youtube url in a post does not work when video is removed, or any other error occurs, the url of the video is shown. I tink it's better for UX to show an error message.",mbootsman
Noteworthy,31920,oEmbed: Support YouTube timestamps as hashes,peterwilsoncc,Embeds,,normal,normal,4,Future Release,enhancement,assigned,needs-unit-tests,2015-04-07T15:24:26Z,2016-06-19T23:01:10Z,"YouTube can provide timestamps as a hash, which doesn't get properly processed by the oEmbed endpoint: `https://www.youtube.com/watch?v=8A6q6eGM_Aw#t=8m30s`
Converting the hash to a proper query argument produces the expected behavior: `https://www.youtube.com/watch?v=8A6q6eGM_Aw&t=8m30s`
Although it's a pain to maintain compatibility shims, including in core would reduce user confusion around oEmbed.
* Support YouTube timestamp as hash (e.g. https://www.youtube.com/watch?v=8A6q6eGM_Aw#t=8m30s)
* by converting the hash to a query arg
add_filter( 'oembed_fetch_url', function( $provider, $url, $args ) {
if ( false === stripos( $provider, 'www.youtube.com/oembed' ) || false === stripos( $url, '#t=' ) ) {
return $provider;
$url = str_replace( '#t=', '&t=', $url );
$provider = add_query_arg( 'url', rawurlencode( $url ), $provider );
return $provider;
}, 10, 3 );
Noteworthy,36374,Audio playback fails on iOS 9.x,,External Libraries,4.4.2,normal,normal,4,Future Release,defect (bug),new,,2016-03-30T12:24:44Z,2016-07-06T18:26:12Z,"When using using audio files on an iOS device with version 9.x the file will buffer in its entirety, and then try to play the first half a second of the file before resetting the playback position and stopping.
This does not happen on iOS versions on the 8.x branch or earlier it would appear.
I've only tested with 4.5-RC and 4.4.2 for now, but both are behaving in the same manner.
Now the question is, is this an iOS bug causing it, or are we doing something in wp-mediaelements.js that iOS does not like any more?
PCs, Macs and Android devices still play the files as expected.
This comes from tracking https://wordpress.org/support/topic/my-mp3-audio-files-get-cut-off-on-mobile-devices-but-work-on-pcs which also includes example media URLs that can be used (and are the ones I used in testing)",Clorith
Noteworthy,38147,Add sprintf.js library to WordPress,,External Libraries,,normal,normal,4,Awaiting Review,enhancement,new,has-patch,2016-09-23T15:50:22Z,2016-10-02T11:54:11Z,"Working on #20491 revealed a need for a `sprintf()` function in JavaScript.
Although ES6 supports some basic string formatting, it's not something core could use in its various JS files. Thus, I suggest adding the very popular [https://github.com/alexei/sprintf.js sprintf.js] library to WordPress.
The minified script is only 3.7 KB in size, the source file is 9.4 KB large. Adding it to core with the `sprintf` handle would not only benefit core but also various plugins and themes in need of such a functionality, especially with translations.",swissspidy
Noteworthy,19998,Feeds can contain characters that are not valid XML,,Feeds,3.3.1,normal,normal,4,Awaiting Review,defect (bug),new,needs-unit-tests,2012-02-09T16:28:47Z,2016-02-11T00:07:02Z,"It is possible for any of the feeds to contain control characters which are not valid in XML e.g. http://www.fileformat.info/info/unicode/char/1c/index.htm
When outputting user supplied content in an XML context we should strip these control characters - they are unprintable and just break feed parsers.
http://en.wikipedia.org/wiki/Valid_characters_in_XML has a good list of what is and isn't valid.
I guess we need a {{{strip_for_xml()}}} function or something.",westi
Noteworthy,9993,Rss and atom feeds are dropping some characters,stevenkword,Feeds,2.7.1,normal,normal,4,Future Release,defect (bug),assigned,has-patch,2009-05-31T23:54:40Z,2016-07-17T17:29:51Z,"Blog post with title:
& > test <
has the less than ( < ) is stripped from the atom and rss feed.
Noteworthy,31935,is_page() erroneously set to true when loading /feed/ associated with 404,,Feeds,4.0,normal,normal,4,Future Release,defect (bug),new,has-patch,2015-04-08T21:51:00Z,2016-03-05T19:34:07Z,"r29216 changed feeds to never send a 404 status header. This had the unintended consequence of changing the behavior of some internals.
A request to the feed associated with a missing page (e.g. `/missing-page/feed/`) will match the rewrite rule for a page and set `is_page == true`. I'd expect WordPress internals to still understand this request as `is_404`",danielbachhuber
Noteworthy,31066,wp_upload_dir calls wp_mkdir_p on each invocation,,Filesystem API,,normal,normal,4,Future Release,defect (bug),new,needs-unit-tests,2015-01-20T06:27:02Z,2016-02-18T13:33:36Z,"Every time `wp_upload_dir` is called, `wp_mkdir_p` is also called. For normal filesystems, this is not a huge issue, but using external filesystems (S3, etc) potentially means an external request on every call.
Ideally, I'd actually like to avoid calling `wp_mkdir_p` at all there. S3 (along with a few other external FSes) doesn't actually have a concept of directories; rather they're just part of the filename. Adding a `upload_dir_requires_creation` filter to `wp_upload_dir` would help with this, as plugins could then switch this off if they know the underlying FS doesn't need it, or they already handle it themselves.",rmccue
Noteworthy,31695,Enclosing oEmbed using `embed_oembed_html` is generating invalid HTML,,Formatting,,normal,normal,4,Awaiting Review,defect (bug),new,needs-unit-tests,2015-03-19T16:26:12Z,2016-01-05T19:00:19Z,"This bug was detected when trying to preview a post that had a Twitter oembed URL. There was no error on the log, and the previewed content was empty ( `the_content()` was printing an empty string ).
After some debugging, I found that something was adding an extra `
` and never closing that tag, on the oembed returned markup, right before ` }}} I did some tracing and found out that it was `wpautop` fault. Even though `WP_oEmbed::_strip_newlines()` was successfully stripping the new lines from the returned oEmbed HTML, something was adding an extra newline before the `\s*|', '', $pee ); } }}} Now the oembed is fully functional and doesn't have that unclosed `
` tag: {{{
Lisbon with #WordPressVIP @ Terreiro do Paço http://instagram.com/p/vGw5IchocB/
— Henrique Mouta (@vaurdan) November 7, 2014
tags are generated when shortcodes are followed by HTML tags and wpautop is enabled,,Formatting,3.4.1,normal,normal,4,Future Release,defect (bug),new,needs-unit-tests,2012-08-26T06:58:21Z,2015-10-13T04:33:17Z,"This bug was encountered in separate plugins, but it seems that its source is in the core: http://wordpress.stackexchange.com/questions/21414/wordpress-wpautop-shortcode-generating-invalid-markup https://github.com/pods-framework/pods/issues/271",dandv Noteworthy,18136,WordPress Adding Spurious,,Formatting,,normal,normal,4,Future Release,defect (bug),reopened,has-patch,2011-07-15T22:03:38Z,2015-12-03T20:18:50Z,If you look at this page: https://singpolyma.net/2011/06/dystoparx-part-12/ WordPress seems to be adding extra
Hello worldWordPress
Hello world
before the .
I expected wpautop would find no newlines and return the original string.
The same string placed inside a HTML5 or XHTML 1 Strict document is parsed as valid by W3C Validator.
Plugins acting on the_content with a priority less than 10 may have their single-line markup reinterpreted by wpautop.",niallkennedy
Noteworthy,30421,Add ARIA attributes to globally permitted HTML attributes in kses,jorbin,Formatting,,normal,normal,4,Future Release,enhancement,assigned,has-patch,2014-11-20T17:17:14Z,2016-02-16T15:51:23Z,"Core currently supports the role attribute as globally permitted. It would be helpful if ARIA attributes were permitted here. This would be helpful so that users without the unfiltered_html capability could use ARIA within their content.
I can do this with a plugin, but currently run into issues making TinyMCE not strip away the ARIA attributes when toggling between the text and visual mode.
Noteworthy,19100,Introduce esc_color(),,Formatting,,normal,normal,4,Future Release,enhancement,new,dev-feedback,2011-11-01T12:16:14Z,2015-04-30T22:41:51Z,"Currently there is no way to escape a color in hexadecimal notation before printing it to a block of css or saving to the database. Many themes like to introduce functionality, whether it be core-supported or completely custom, to change the color of various parts of the templates. I believe that a function such as `esc_color()` would promote best practices while ensuring that unintended values do not get stored as colors and thus echoed in css blocks potentially breaking display.",mfields
Noteworthy,28607,Make wpautop()'s $allblocks variable filterable,,Formatting,,normal,normal,4,Awaiting Review,enhancement,new,has-patch,2014-06-21T04:51:59Z,2016-06-03T06:25:41Z,"'''The problem''': I'd like tags to ''not'' be wrapped by in the_content().
I used to use a regex filter on the_content to achieve this, but looking at the source for wpautop(), I think it would be much cleaner to ''prevent'' s from being wrapped in the first place by making $allblocks filterable.
The issue commonly causes formatting issues, and making the block list filterable would let theme/plugin authors change this without and other blocks without breaking stylesheets configured for images in paragraphs.
Additionally, I think it's semantically cleaner for a standalone image, since ""The HTML element (or HTML Paragraph Element) represents a paragraph of text."" https://developer.mozilla.org/en-US/docs/Web/HTML/Element/p",walkinonwat3r
Noteworthy,32257,Patch: add support for multi-line textarea sanitization,chriscct7*,Formatting,,normal,normal,4,4.7,enhancement,accepted,commit,2015-05-05T15:03:01Z,2016-10-24T22:05:07Z,"New function: sanitize_textarea_field
Add new function that can be used to sanitize textarea inputs (or outputs) which unlike the regular sanitize_text_field does not strip line breaks.
This kind of sanitization is demanded by users and WP should definately provide such basic functions in the name of security. Otherwise users will use other less thorough sanitization solutions, like only wp_kses(). See examples at
Also removed trailing spaces from file.
Development done at https://github.com/WordPress/WordPress/compare/master...ottok:feature-sanitize-textarea-field",ottok
Noteworthy,20771,esc_url() instead of esc_html() in wp_nonce_url(),johnbillion*,Formatting,3.4,normal,normal,4,Future Release,enhancement,accepted,needs-unit-tests,2012-05-29T06:21:37Z,2016-04-01T13:46:09Z,"The `wp_nonce_url()` function currently uses `esc_html()` in its output, which doesn't really seem to be the appropriate escaping function since it's generating a URL.
Attached patch changes the output to use `esc_url()`",jkudish
Noteworthy,21082,"The Gallery shortcode relies on #gallery-instance to hook the CSS, but the id sometimes isn't specific enough",obenland*,Gallery,,normal,normal,4,Future Release,defect (bug),accepted,has-patch,2012-06-26T18:43:28Z,2016-03-07T21:13:26Z,"The Gallery CSS selector uses the id attribute, which is of the form #gallery-{instance}. On some scenarios (like infinite scroll) a follow up gallery on a another post can have the same #gallery-x selector, thus over-writing the previous gallery style.
Proposed solution: make the #id more unique by including the postid number. (Attached patch.)
(It could potentially impact some themes that used #gallery-1 to style galleries, but theme's shouldn't be using that in the first place, I believe.)
Furthermore, it may be good to change the whole style block to use classes instead of the id so that it's easier for themes to deal with CSS specificity—and helps them not fall back to the #id.",matveb
Noteworthy,35654,Make Gallery size default configurable,,Gallery,4.4,normal,normal,4,Awaiting Review,enhancement,new,,2016-01-29T07:01:12Z,2016-08-02T21:55:37Z,"Currently it's not possible to set the default size in the Gallery Sizes pulldown when adding a gallery—it's always `thumbnail`.
[[Size pulldown(http://oli.jp/temp/2016-01-29-wp4.4-gallery-size-setting.png)]]
For example, this code will set `columns` but not `size`
function my_gallery_defaults( $settings ) {
$settings['galleryDefaults']['columns'] = 2;
$settings['galleryDefaults']['size'] = 'medium';
return $settings;
add_filter( 'media_view_settings', 'my_gallery_defaults' );
This has been mentioned in previous tickets:
- #18143 Adds Sizes pulldown to UI (but no `$settings['galleryDefaults']['size']`)
- #27515 Request for `$settings['galleryDefaults']['size']` but marked as dupe of #18143
- #28693 Adds `$settings['galleryDefaults']` support for `columns` and `link`
- #29032 Request for setting a custom default gallery size but marked as dupe of #18143
While this can be overridden via the UI, it would be nice to set the initial Gallery default size for a theme.",boblet
Noteworthy,11725,Add start and count attributes to gallery shortcode,,Gallery,2.9.1,normal,normal,4,Future Release,feature request,new,has-patch,2010-01-05T15:00:27Z,2015-04-28T17:36:35Z,"Add shotcodes COUNT for views full gallery after click on MORE. Home
Modify files ./wp-includes/media.php
Lines 699 (add COUNT => '-1')
Lines 767-798 (add ForEach ... )
Use in WP:
[gallery] ... show standard gallery
[gallery count=3] ... show images 1-3
- more -
[gallery count=3+] ... show images 4-n",frymi
Noteworthy,29652,Dashicons conflict with text-rendering: optimizeLegibility,,General,4.0,normal,normal,4,Awaiting Review,defect (bug),new,,2014-09-12T23:36:23Z,2015-02-19T21:36:22Z,"There is a little known problem using Dashicons with Android 4.2 and 4.3, and perhaps the later versions.
If any plugin or theme includes this CSS rule:
''text-rendering: optimizeLegibility;''
then Dashicons (and other icon fonts like genericons) do not display at all on those Android devices.
Twenty Twelve has this, and it should be removed. There should be a comment about this problem in at least the core dashicons.css file.
This is not a well-known problem, and is obviously very embarrassing. It is next to impossible for any WP developer to test, but there are still a huge number of Android 4.2+ devices.",wpweaver
Noteworthy,35154,The admin_url filter might break ajaxurl usage,,General,,normal,normal,4,Awaiting Review,defect (bug),new,reporter-feedback,2015-12-18T12:46:04Z,2016-03-23T20:10:48Z,"`ajaxurl` is a javascript global generated basically as
var ajaxurl = '';
`admin_url()` results get filtered by `admin_url`, which might add query arguments into `ajaxurl`, or at least modify it on a substantial way.
We have several instances where we assume that `ajaxurl` will be an URL without query arguments, like this one:
// wp-admin\js\tags-box.js 179
ajaxurl + '?action=ajax-tag-search&tax=' + tax,
That assumption might be completely wrong.
I am attaching a list of places where we define `ajax_url` and a list of places where we assume it is a clean, query-arguments-free URL. Note that those lists might not be complete, although I greped against WordPress trunk.
As a solution idea, we might want to create a javascript version of `add_query_arg()` and use it extensively.",jadpm
Noteworthy,34487,"Add a new conditional tag for the ""Posts Page""",,General,4.4,normal,normal,4,Awaiting Review,enhancement,new,has-patch,2015-10-29T19:22:45Z,2015-10-31T14:56:23Z,"Currently, there's no conditional tag to determine whether the current page is the ""Posts Page"", set under Settings->Reading. The codex (https://codex.wordpress.org/Conditional_Tags#The_Blog_Page) describes a way to combine is_home() and is_front_page(), but I propose that we instead add a new conditional tag to deal with this.
Naming the function is a little tricky. Unfortunately, the name ""is_posts_page"" is taken in query.php, so I created a patch that adds ""is_blog_page"". It returns true on the ""posts page"", and false everywhere else.
I've run across this issue in real world projects a couple of times and though it would be a good addition to WordPress. The patch adds this to query.php because is_home() and is_front_page also live there.",roytanck
Noteworthy,38073,Goodbye wp_reset_vars(),,General,,normal,normal,4,Awaiting Review,enhancement,new,,2016-09-16T12:34:35Z,2016-09-18T20:17:58Z,"`wp_reset_vars()` sets global variables based on `$_POST` and `$_GET` values. The function is used around 20 times in core and in my opinion this should be zero. Even better, the function should be deprecated.
First of all, it's easy to shoot yourself in the foot if you forget to properly sanitize the input value. Second, globals set by `wp_reset_vars()` aren't explicitly globalized in the files / functions using it. You might stumble upon code like this:
' . ""\n"";
call_user_func($box['callback'], $object, $box);
echo ""\n"";
echo '
in the_content(). I used to use a regex filter on the_content to achieve this, but looking at the source for wpautop(), I think it would be much cleaner to ''prevent'' s from being wrapped in the first place by making $allblocks filterable. The
issue commonly causes formatting issues, and making the block list filterable would let theme/plugin authors change this without and other blocks without breaking stylesheets configured for images in paragraphs. Additionally, I think it's semantically cleaner for a standalone image, since ""The HTML
element (or HTML Paragraph Element) represents a paragraph of text."" https://developer.mozilla.org/en-US/docs/Web/HTML/Element/p",walkinonwat3r Noteworthy,32257,Patch: add support for multi-line textarea sanitization,chriscct7*,Formatting,,normal,normal,4,4.7,enhancement,accepted,commit,2015-05-05T15:03:01Z,2016-10-24T22:05:07Z,"New function: sanitize_textarea_field Add new function that can be used to sanitize textarea inputs (or outputs) which unlike the regular sanitize_text_field does not strip line breaks. This kind of sanitization is demanded by users and WP should definately provide such basic functions in the name of security. Otherwise users will use other less thorough sanitization solutions, like only wp_kses(). See examples at https://wordpress.org/support/topic/sanitizing-a-text-field-form-but-keep-line-breaks Also removed trailing spaces from file. Development done at https://github.com/WordPress/WordPress/compare/master...ottok:feature-sanitize-textarea-field",ottok Noteworthy,20771,esc_url() instead of esc_html() in wp_nonce_url(),johnbillion*,Formatting,3.4,normal,normal,4,Future Release,enhancement,accepted,needs-unit-tests,2012-05-29T06:21:37Z,2016-04-01T13:46:09Z,"The `wp_nonce_url()` function currently uses `esc_html()` in its output, which doesn't really seem to be the appropriate escaping function since it's generating a URL. Attached patch changes the output to use `esc_url()`",jkudish Noteworthy,21082,"The Gallery shortcode relies on #gallery-instance to hook the CSS, but the id sometimes isn't specific enough",obenland*,Gallery,,normal,normal,4,Future Release,defect (bug),accepted,has-patch,2012-06-26T18:43:28Z,2016-03-07T21:13:26Z,"The Gallery CSS selector uses the id attribute, which is of the form #gallery-{instance}. On some scenarios (like infinite scroll) a follow up gallery on a another post can have the same #gallery-x selector, thus over-writing the previous gallery style. Proposed solution: make the #id more unique by including the postid number. (Attached patch.) (It could potentially impact some themes that used #gallery-1 to style galleries, but theme's shouldn't be using that in the first place, I believe.) Furthermore, it may be good to change the whole style block to use classes instead of the id so that it's easier for themes to deal with CSS specificity—and helps them not fall back to the #id.",matveb Noteworthy,35654,Make Gallery size default configurable,,Gallery,4.4,normal,normal,4,Awaiting Review,enhancement,new,,2016-01-29T07:01:12Z,2016-08-02T21:55:37Z,"Currently it's not possible to set the default size in the Gallery Sizes pulldown when adding a gallery—it's always `thumbnail`. [[Size pulldown(http://oli.jp/temp/2016-01-29-wp4.4-gallery-size-setting.png)]] For example, this code will set `columns` but not `size` {{{ function my_gallery_defaults( $settings ) { $settings['galleryDefaults']['columns'] = 2; $settings['galleryDefaults']['size'] = 'medium'; return $settings; } add_filter( 'media_view_settings', 'my_gallery_defaults' ); }}} This has been mentioned in previous tickets: - #18143 Adds Sizes pulldown to UI (but no `$settings['galleryDefaults']['size']`) - #27515 Request for `$settings['galleryDefaults']['size']` but marked as dupe of #18143 - #28693 Adds `$settings['galleryDefaults']` support for `columns` and `link` - #29032 Request for setting a custom default gallery size but marked as dupe of #18143 While this can be overridden via the UI, it would be nice to set the initial Gallery default size for a theme.",boblet Noteworthy,11725,Add start and count attributes to gallery shortcode,,Gallery,2.9.1,normal,normal,4,Future Release,feature request,new,has-patch,2010-01-05T15:00:27Z,2015-04-28T17:36:35Z,"Add shotcodes COUNT for views full gallery after click on MORE. Home Modify files ./wp-includes/media.php Lines 699 (add COUNT => '-1') Lines 767-798 (add ForEach ... ) Use in WP: [gallery] ... show standard gallery OR [gallery count=3] ... show images 1-3 - more - [gallery count=3+] ... show images 4-n",frymi Noteworthy,29652,Dashicons conflict with text-rendering: optimizeLegibility,,General,4.0,normal,normal,4,Awaiting Review,defect (bug),new,,2014-09-12T23:36:23Z,2015-02-19T21:36:22Z,"There is a little known problem using Dashicons with Android 4.2 and 4.3, and perhaps the later versions. If any plugin or theme includes this CSS rule: ''text-rendering: optimizeLegibility;'' then Dashicons (and other icon fonts like genericons) do not display at all on those Android devices. Twenty Twelve has this, and it should be removed. There should be a comment about this problem in at least the core dashicons.css file. This is not a well-known problem, and is obviously very embarrassing. It is next to impossible for any WP developer to test, but there are still a huge number of Android 4.2+ devices.",wpweaver Noteworthy,35154,The admin_url filter might break ajaxurl usage,,General,,normal,normal,4,Awaiting Review,defect (bug),new,reporter-feedback,2015-12-18T12:46:04Z,2016-03-23T20:10:48Z,"`ajaxurl` is a javascript global generated basically as {{{ var ajaxurl = ''; }}} `admin_url()` results get filtered by `admin_url`, which might add query arguments into `ajaxurl`, or at least modify it on a substantial way. We have several instances where we assume that `ajaxurl` will be an URL without query arguments, like this one: {{{ // wp-admin\js\tags-box.js 179 ajaxurl + '?action=ajax-tag-search&tax=' + tax, }}} That assumption might be completely wrong. I am attaching a list of places where we define `ajax_url` and a list of places where we assume it is a clean, query-arguments-free URL. Note that those lists might not be complete, although I greped against WordPress trunk. As a solution idea, we might want to create a javascript version of `add_query_arg()` and use it extensively.",jadpm Noteworthy,34487,"Add a new conditional tag for the ""Posts Page""",,General,4.4,normal,normal,4,Awaiting Review,enhancement,new,has-patch,2015-10-29T19:22:45Z,2015-10-31T14:56:23Z,"Currently, there's no conditional tag to determine whether the current page is the ""Posts Page"", set under Settings->Reading. The codex (https://codex.wordpress.org/Conditional_Tags#The_Blog_Page) describes a way to combine is_home() and is_front_page(), but I propose that we instead add a new conditional tag to deal with this. Naming the function is a little tricky. Unfortunately, the name ""is_posts_page"" is taken in query.php, so I created a patch that adds ""is_blog_page"". It returns true on the ""posts page"", and false everywhere else. I've run across this issue in real world projects a couple of times and though it would be a good addition to WordPress. The patch adds this to query.php because is_home() and is_front_page also live there.",roytanck Noteworthy,38073,Goodbye wp_reset_vars(),,General,,normal,normal,4,Awaiting Review,enhancement,new,,2016-09-16T12:34:35Z,2016-09-18T20:17:58Z,"`wp_reset_vars()` sets global variables based on `$_POST` and `$_GET` values. The function is used around 20 times in core and in my opinion this should be zero. Even better, the function should be deprecated. Why? First of all, it's easy to shoot yourself in the foot if you forget to properly sanitize the input value. Second, globals set by `wp_reset_vars()` aren't explicitly globalized in the files / functions using it. You might stumble upon code like this: {{{#!php ' . ""\n""; call_user_func($box['callback'], $object, $box); echo ""\n""; }}} with: {{{ echo '