__group__,ticket,summary,owner,component,_version,priority,severity,milestone,type,_status,workflow,_created,modified,_description,_reporter
Future Releases,15760,"LiveJournal Importer mishandles some and expressions",westi,Import,,normal,normal,WordPress.org,defect (bug),assigned,dev-feedback,2010-12-10T04:45:17Z,2017-05-23T15:16:47Z,"There is a note on plugins.trac ticket 1231 that says this should be handled in core.trac instead, so I'm cross-posting it here. The patch and ticket were originally added by a-bishop:
http://plugins.trac.wordpress.org/ticket/1231
Reproduction steps: 1. Create a LiveJournal? entry that has in it. Note that this is XML-ish 2. Try to use the livejournal-importer on this post.
Bug The gets ignored because the regular expression is too strict.
I've attached a patch that makes LiveJournal? Importer recognize the XML-ish version.
Patch:[[BR]]
http://plugins.trac.wordpress.org/attachment/ticket/1231/livejournal-importer.patch",designsimply
Future Releases,6269,RSS Import Doesn't Properly Strip CDATA Tags,,Import,2.3.3,normal,normal,WordPress.org,defect (bug),new,dev-feedback,2008-03-18T00:58:13Z,2015-09-01T23:59:35Z,"When importing an RSS feed that uses the tag as opposed to , I noticed that WP's RSS import doesn't strip the CDATA tags as it does for the .
=========Code Lines (83-87)===============
{{{
if (!$post_content) {
// This is for feeds that put content in description
preg_match('|(.*?)|is', $post, $post_content);
$post_content = $wpdb->escape($this->unhtmlentities(trim($post_content[1])));
}
}}}
=====================================
I tweaked the code to solve the problem (see below)
==========Tweaked Code===============
{{{
if (!$post_content) {
// This is for feeds that put content in description
preg_match('|(.*?)|is', $post, $post_content);
$post_content = str_replace(array (''), '',$wpdb->escape($this->unhtmlentities(trim($post_content[1]))));
}
}}}
======================================
I'd be happy to submit a patch, except I'm not quite that savvy yet. It would be great it someone could incorporate it. Thanks.",sweetdeal
Future Releases,21913,Detecting MIME Types in WXR Files,,Import,3.4.2,normal,normal,WordPress.org,enhancement,new,dev-feedback,2012-09-17T21:09:07Z,2015-05-12T08:23:00Z,"In the process of creating a service to convert TypePad data to WXR formatted files, we've encountered some unique problems with TypePad data. Namely, many TypePad files are saved without file extensions, which prevents the existing importer from importing those files into the wp-content/uploads folder.
In order to import and rename these otherwise ignored files, we've created a patch for the WordPress importer that does the following:
1. If there is an attachment in the WXR and the importer is not able to determine the file type from the file name (ie missing extension), the patched version will make a light (body-less) request to the web server where the file is hosted for information we can use about the file. The things we're interested in are file type, size, and filename.
2. If the importer is processing an attachment under the above situation, and it is able to determine the file type, then it will rewrite the local version of the file to have the appropriate file extension.
This is a simple bit of code, but it makes a huge difference as TypePad saves without file extensions quite regularly.
We've attached our patch and a sample WXR file from ragsgupta.com, the Brightcove co-founder's blog.",ReadyMadeWeb
Future Releases,7543,Import TypePad data using AtomPub.,westi*,Import,,normal,normal,WordPress.org,enhancement,accepted,needs-review,2008-08-19T02:44:26Z,2015-12-03T15:36:00Z,"First off, I want to mention that TypePad updated their AtomPub server a few days ago, and their server does not seem to be sending comments. With a little luck, my current code should work fine once that server starts functioning again, but for the time being I would highly recommend not committing this into core.
Instead, I'm hoping people can look over the code and offer suggestions for improvement, test results, etc. While the Summer of Code is officially over today, I will be working on this until the job is done.
Alright, now to what this is. As some of you may know, I've been working on an Atom Publishing Protocol ([http://www.rfc-editor.org/rfc/rfc5023.txt RFC 5023]) based importer this summer for the Google Summer of Code. The diff attached is the latest version of my work.
The advantages of using the Atom Publishing Protocol are as follows:
* Nothing has to be done in the old blogging software to prepare for import (no export files, etc). Users just enter their blog URL, username, and password and the importer grabs all of the data using AtomPub.
* More data is imported compared to the old importers, especially with TypePad. Post slugs, comments, trackbacks, tags, categories, excerpts, etc are all imported. Everything used for posts in MT/TypePad is imported using AtomPub.
* The Atom Publishing Protocol is an established standard. With the exceptions of tag additions (which don't necessarily need updates), the importer should not have to be changed and should continue working well into the future.
I should mention there is one drawback to using the Atom Publishing Protocol. For the time being, it appears pages can not be retrieved using AtomPub. They were retrievable a few weeks ago, and I'm currently talking with Six Apart to see what happened.
I would greatly appreciate any and all feedback. Let me know your suggestions, and I'll be happy to incorporate them.",cavemonkey50
Future Releases,23950,Company recognition,,WordPress.org site,,normal,normal,WordPress.org,feature request,new,dev-feedback,2013-04-05T15:13:24Z,2015-09-02T00:32:42Z,"My company, and many others, have a policy of sponsoring WordPress community contribution, core and otherwise, by strongly encouraging employees to participate during paid company hours. I want to open a discussion on how this company contribution could be recognised, while not allowing ""corporates"" to take over the credits page on each release.
* Would greater recognition encourage your company to foster contribution?
* Should companies contributing employee time to WordPress, particularly core contributions, be recognised?
* How should companies be recognised?
* What are the pros and cons for the WordPress project in allowing this kind of recognition?
This follows a [https://twitter.com/jenmylo/status/320144575266160640 Twitter conversation] re showing company names in the WordPress credits page, and Nacin's suggestion to open this discussion.",simonwheatley
Future Releases,36081,Activity dashboard widget is not using word-wrap: break-word,mrahmadawais,Administration,4.4.2,normal,normal,Future Release,defect (bug),assigned,dev-feedback,2016-03-03T07:40:11Z,2017-01-16T02:07:05Z,"Long word's without spaces goes out of the container.
I think that this class `#dashboard-widgets a` needs `word-wrap: break-word`;
Screenshot: http://www.awesomescreenshot.com/image/1048253/7b7bc297dd3c3bd1f3c9532dd9f1138e",Prelc
Future Releases,36201,Admin Pagination URLs Use Wrong Hostname,,Administration,,normal,normal,Future Release,defect (bug),reopened,close,2016-03-10T21:18:06Z,2018-05-10T09:03:34Z,"The pagination links on the posts/pages screen uses the wrong host in some cases. Particularly for my case I have a Wordpress blog installed on a separate server from my main website, but it's hosted as a subdirectory `/blog` on the main site using the `mod_proxy` Apache module. So the pagination links are coming through using the wrong host like this:
http://1647760595.us-east-1.elb.amazonaws.com/wp-admin/edit.php?paged=2
It seems like these pagination links are the only ones with this issue, and I believe it's because of how they are being constructed.
I've attached a patch that solves the issue for me.
-Garrett",grimmdude
Future Releases,28821,Admin page registered with add_menu_page() allows access through wrong URls and hightlights wrong top level menu item,,Administration,3.9.1,normal,normal,Future Release,defect (bug),new,dev-feedback,2014-07-10T21:05:19Z,2016-02-08T14:02:09Z,"'''Steps to reproduce:'''
* Add a top level admin menu page (with the plugin provided below).
* Access the new top level admin menu via the menu item (bottom of menu)
* Try to access it via one of the following URLs
{{{
http://example.com/wp-admin/options-general.php?page=trac
http://example.com/wp-admin/tools.php?page=trac
http://example.com/wp-admin/admin.php?page=trac
http://example.com/wp-admin/edit-comments.php?page=trac
http://example.com/wp-admin/edit.php?post_type=page&page=trac
http://example.com/wp-admin/upload.php?page=trac
http://example.com/wp-admin/edit.php?page=trac
http://example.com/wp-admin/index.php?page=trac
... etc ...
// Sub menu items that have the same behavior
http://vagrant.local/wp/wp-admin/plugin-install.php?page=trac
http://vagrant.local/wp/wp-admin/themes.php?page=custom-header&page=trac
http://vagrant.local/wp/wp-admin/themes.php?post-new.php?post_type=page&page=trac
... etc ...
}}}
'''Bug description:''' Every of the above links will (falsely) work and bring you to the registered page. The top level menu item will be hightlighted while the sub menu item does not exist.
The following URls will work (with above bug) as well, but ''not'' highlight any menu item:
{{{
http://example.com/wp-admin/edit-tags.php?taxonomy=post_tag&page=trac
http://example.com/wp-admin/edit-tags.php?taxonomy=category&page=trac
}}}
I would not really consider this a ''""feature""''.
----
'''Test Plugin'''
{{{

Hello Trac!

Enter Trac IDGeneral 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.
Discuss!",section214
Future Releases,37593,"Replace ""Super Admin"" with ""Network Administrator""",Mista-Flo,Administration,,normal,normal,Future Release,enhancement,assigned,dev-feedback,2016-08-07T19:17:59Z,2017-11-06T17:11:05Z,"After a note by @ocean90 (https://wordpress.slack.com/archives/core-multisite/p1470482829000310) and a following discussion (see particularly https://wordpress.slack.com/archives/core-multisite/p1470579794000339), it was cleared that the term ""Super Admin"" is used inconsistently in Core at the moment.
Given that there is no Multinetwork UI in Core at the moment, all usages of the term ""Super Admin"" should probably be replaced by ""Network Administrator"". The term ""super admin"" should rather denote the user level where a user has control over all networks in an entire setup. While for a basic Multisite with one network ""super admin"" and ""network administrator"" denote a similar user level, the terms are different for a Multinetwork - and the way Core works currently, it should probably only use ""Network Administrator"".",flixos90
Future Releases,32396,Settings Reduction,chriscct7,Administration,,normal,normal,Future Release,enhancement,assigned,dev-feedback,2015-05-14T15:20:29Z,2016-11-09T17:56:04Z,"One of WordPress's many core philosphies is decisions instead of options based on the majority. In recent years, WordPress has worked on simplifying the administration and new-to-WordPress experience. As a result of these talks, and my ongoing work on the ancient ticket report, we're proposing the removal of some of the lesser used options in WordPress core.
This ticket is strongly related to (#22942), where we're removing email to post for all installs from WordPress core, as it is inherently broken.
As part of the work into this ticket, several hosting providers have provided usage data for core options, specifically the % of installs where the value of the core setting is not on the default.
Here is an overview of the proposed movement of options:
Settings Removed:
- mailserver_url (post to email leaving core)
- mailserver_login (post to email leaving core)
- mailserver_pass (post to email leaving core)
- mailserver_port (post to email leaving core)
- default_email_category (post to email leaving core)
- default_category (moving to the post category page in #31483)
Possibly removed based on usage under 1% (from WordPress.com data, normalized) :
- avatar_default
- show_avatars
- avatar_rating
- default_post_format
- ping_sites
- posts_per_rss
Settings Under Consideration for Removal pending media numbers from GoDaddy + Page.ly:
- thumbnail_size_w
- thumbnail_size_h
- thumbnail_crop
- medium_size_w
- medium_size_h
- large_size_w
- large_size_h
- uploads_use_yearmonth_folders
- rss_use_excerpt
Settings Moved to General:
- posts_per_page
- page_on_front
- page_for_posts
- blog_public
The two options we have for each setting is to:
- Remove the setting (hide it) just for new installs (continue showing for existing installs)
- Remove the setting for all installs
For each setting, existing hooks can be utilized (as well as just a simple update_option call) to continue using the setting after it's been removed or hidden.
As it stands right now, the following option pages would not show for new installs (or if we decide to remove the settings existing ones as well):
- Writing
- Reading
- Media (pending data)
All settings pages would be mapped as was done previously for the privacy page in 3.5.
Thus any plugin currently hooking into any of the removed tabs would not be affected.
From a UX standpoint, the second most commonly used WordPress setting (behind site URL) is the posts_on_front/page_for_posts selector, currently on the reading page. Under this proposal, the option would be relocated to new installs (or existing if removal of tab for existing installs) to right underneath the site url field on the general tab which makes sense as one of the more used WordPress settings should be on the default settings page.
The goal is to finish getting usage data for the remaining settings this week, and to have a patch ready within the next 2 weeks. Decisions on whether to remove settings on existing installs will need to be made on an option by option basis and should be done as soon as possible to expedite the patch process. ",chriscct7
Future Releases,11049,Page Preview does not autosave page template,nacin*,Autosave,2.8.4,normal,normal,Future Release,defect (bug),accepted,dev-feedback,2009-10-30T21:19:34Z,2015-10-01T03:55:23Z,"When editing a published page, if you change the page template and then click Preview, the preview does not show the new template choice. ",janeforshort
Future Releases,42085,Still getting ini_get_all warning message,,Bootstrap/Load,,normal,normal,Future Release,defect (bug),new,dev-feedback,2017-10-04T13:18:36Z,2017-10-04T22:44:05Z,"For some PHP configurations, the check function_exists does not suffice.
{{{
Warning: ini_get_all() has been disabled for security reasons in /home/mysite/public_html/wp-includes/load.php on line 1027
}}}
Suggested fix in wp_is_ini_value_changeable()
{{{
if ( ! isset( $ini_all ) ) {
$ini_all = false;
// Sometimes `ini_get_all()` is disabled via the `disable_functions` option for ""security purposes"".
if ( function_exists( 'ini_get_all' ) ) {
$disabled_functions_raw = explode( ',', ini_get( 'disable_functions' ) );
$disabled_functions = array_map( 'trim', $disabled_functions_raw );
if (!array_search( 'ini_get_all', $disabled_functions ) ) {
$ini_all = ini_get_all();
}
}
}
}}}",scottcwilson
Future Releases,18322,The Road to Magic Quotes Sanity,,Bootstrap/Load,3.2.1,normal,normal,Future Release,defect (bug),new,dev-feedback,2011-08-03T20:26:25Z,2018-01-28T16:20:20Z,"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
Future Releases,22325,Abstract GPCS away from the superglobals,,Bootstrap/Load,,normal,normal,Future Release,enhancement,new,dev-feedback,2012-10-30T21:15:41Z,2016-04-07T07:50:13Z,"As discussed at #wpcs, it looks like we want to move away from directly using the GPCS superglobals. This gives us a way to handle slashing backwards compatibility moving forward.
This is still a heap of versions away, but this is a way to keep any notes central.",rmccue
Future Releases,21521,Audit use of set_time_limit(),,Bootstrap/Load,3.4.1,normal,normal,Future Release,enhancement,new,dev-feedback,2012-08-08T17:28:21Z,2015-10-04T01:14:11Z,Core calls this half a dozen times. The call in wp_get_http() interferes with unit tests. Unit tests will terminate 60 seconds after wp_get_http() is called. Let's justify each use of set_time_limit() and remove what we can.,ryan
Future Releases,22251,Helper function to simplify checking for constants,,Bootstrap/Load,,normal,normal,Future Release,enhancement,new,dev-feedback,2012-10-22T00:32:27Z,2017-10-05T13:03:45Z,"Love 'em or hate 'em, WordPress uses lots of constants. As a result, this pattern is all over core and plugins, and occasionally themes:
`if ( defined( 'CONSTANT_NAME' ) && CONSTANT_NAME )`
Right now on trunk, it's used 57 times (excluding 2 in Akismet).
{{{
~/code/wptrunk $ ack ""defined\( ?('|\"")([^'\""]+)\1 ?\) \&\& \2"" -h --ignore-dir=wp-content/plugins/ | wc -l
57
}}}
How about a new function to make that verbose logic a little bit less repetitive.
{{{
function wp_constant( $constant ) {
return defined( $constant ) && constant( $constant );
}
}}}",evansolomon
Future Releases,31839,Setting error reporting level for wp_debug_mode,,Bootstrap/Load,4.1.1,normal,normal,Future Release,enhancement,new,dev-feedback,2015-04-01T16:25:34Z,2015-05-08T16:58:04Z,"Since PHP 5.4.0 `E_STRICT` errors appear as part of `E_ALL` and headers cannot be sent sometimes - stuff that can lead to a whole set of problems. For me, they are useless and annoying - but for others they can be useful.
I just want the possibility to set the `error_reporting` level used in `wp_debug_mode()`. I have applied a small patch to `load.php` as shown below.
I have defined a `WP_DEBUG_LEVEL` constant in `wp-config.php` like so: `define( 'WP_DEBUG_LEVEL', E_ALL & ~E_STRICT );` because I do not want to see the `E_STRICT` warnings.
Afterwards I modified the `wp_debug_mode` function like so:
{{{
#!php
function wp_debug_mode() {
if ( WP_DEBUG ) {
if( !defined( WP_DEBUG_LEVEL ) )
define( 'WP_DEBUG_LEVEL' , E_ALL) ;
error_reporting( WP_DEBUG_LEVEL );
if ( WP_DEBUG_DISPLAY )
ini_set( 'display_errors', 1 );
elseif ( null !== WP_DEBUG_DISPLAY )
ini_set( 'display_errors', 0 );
if ( WP_DEBUG_LOG ) {
ini_set( 'log_errors', 1 );
ini_set( 'error_log', WP_CONTENT_DIR . '/debug.log' );
}
} else {
error_reporting( E_CORE_ERROR | E_CORE_WARNING | E_COMPILE_ERROR | E_ERROR | E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING | E_RECOVERABLE_ERROR );
}
if ( defined( 'XMLRPC_REQUEST' ) )
ini_set( 'display_errors', 0 );
}
}}}
Here's the [https://gist.github.com/AlexandruIfrim/8e3626f27344f8f28a87 gist] of it.",aifrim
Future Releases,28236,JSHint `onevar` and `trailing` args are deprecated and dropped,,Build/Test Tools,3.8,normal,normal,Future Release,defect (bug),new,dev-feedback,2014-05-13T15:48:47Z,2018-01-21T02:32:22Z,"As per http://www.jshint.com/docs/options/#onevar
> These options are deprecated and will be removed soon. DO NOT use them.
This was brought up by rase- on GitHub to Jetpack here: https://github.com/Automattic/jetpack/pull/432#issuecomment-42783894
Unsure of the best route forward.",georgestephanis
Future Releases,39237,PHPunit coverage reports fail if the is out to the stdout or header,,Build/Test Tools,,normal,normal,Future Release,defect (bug),new,dev-feedback,2016-12-11T18:03:15Z,2018-02-07T22:23:16Z,"trying to get the coverage report to work :-)
https://phpunit.de/manual/current/en/textui.html
and their error due to the ech statements in the phpunit `install.php` and `bootstrap.php`
i.e.
{{{#!php
screen options",,Comments,,normal,normal,Future Release,enhancement,new,dev-feedback,2012-10-11T14:14:23Z,2015-07-29T04:17:26Z,"Seems like it would make more sense to move the comment ""keyboard shortcuts"" setting from ""Your Profile"" to the screen options pane of edit-comments.php. Something like:
[[Image(http://f.cl.ly/items/1k210Z2V1o0b350I1n0V/keyboard-shortcuts.jpg)]]",lessbloat
Future Releases,19901,Speeding up Dashboard and Comment moderation SQL load,markjaquith*,Comments,3.3,normal,major,Future Release,enhancement,accepted,dev-feedback,2012-01-26T21:32:43Z,2017-06-16T13:53:13Z,"The standard Wordpress function for counting the comments for Admin Bar and Dashboard named wp_count_comments is using a single SQL query with GROUP BY clause. That makes it slow on a large site with hundreds of thousands of comments.
{{{
SELECT comment_approved, COUNT(*) AS num_comments FROM wp_comments GROUP BY comment_approved;
}}}
This takes 0.3 seconds on our site with 400,000 comments. When there are 10 editors logged in, we can see increasing server load.
Our solution is to run 5 faster queries instead:
{{{
SELECT COUNT( comment_ID ) FROM wp_comments WHERE comment_approved = 'trash'
SELECT COUNT( comment_ID ) FROM wp_comments WHERE comment_approved = 'spam'
SELECT COUNT( comment_ID ) FROM wp_comments WHERE comment_approved = '0'
SELECT COUNT( comment_ID ) FROM wp_comments WHERE comment_approved = 'post-trash'
SELECT COUNT( comment_ID ) FROM wp_comments
}}}
Takes 0.042144 on the same site. The last query gets the number of all the comments, then we subtract the previous query totals to get number of approved comments.
On a database of 4 million comments the difference is 1.52 seconds for the original wp_count_comments and 0.01 seconds for our alternative count with 5 queries.
Here is a link to our quick piece of code which hooks to the required filter hook and replaces the original slow function wp_count_comments: http://foliovision.com/downloads/fv_wp_count_comments.php.txt
But this is a hack - it would be much better to fix this in core by replacing the existing slow queries with 5 fast ones and subtraction to get total approved comments.
This speedup can be very important on large sites, as often there are 10 or more writers and moderators working at the same time. What can happen with the existing code is that the slow count comments query can back up MySQL and then writers can no longer save or open posts to edit. They get very, very frustrated and even angry.
This fix will allow Wordpress to scale much larger on relatively modest hardware (no separate MySQL dual quad server).
Thanks for listening.
Martin",FolioVision
Future Releases,10653,Update comment_author when display_name changes,SergeyBiryukov,Comments,trunk,normal,normal,Future Release,enhancement,reviewing,dev-feedback,2009-08-19T19:43:29Z,2018-04-11T21:01:52Z,One thing that has bothered me recently is the fact that your previous comments doesn't get updated when your display_name is being updated. Which could cause some confusion. I wrote a function (see attached file for further reference) that takes care of this but I would love to see a similiar feature in the WordPress core.,mptre
Future Releases,16612,WordPress should return nocache headers for requests with comment cookies,,Comments,,normal,normal,Future Release,enhancement,new,dev-feedback,2011-02-21T22:45:21Z,2016-10-07T22:55:56Z,"Most themes, when displaying the comment form, change the HTML to pre-fill username, email address, and website when comment cookies are received in the HTTP request. Since the response does not have explicit nocache headers, per RFC2616 (http://www.ietf.org/rfc/rfc2616.txt) intermediate caches can use heuristics to determine the cache TTL for the response. Since there is 0 freshness data in the response, it is not really possible to perform good heuristics, but in practice, caches will assign a default TTL to this type of response. The result is that private information input by user A when submitting a comment can be returned to user B when making a request for the same URL.
To protect ourselves against this, we should call nocache_headers() when comment cookies are sent and the comment form is being displayed. Alternatively, we can send nocache headers for all requests with comment cookies regardless of the comment form being displayed or not (probably easier and maybe safer).
http://humboldtherald.wordpress.com/2011/01/27/gremlins/ is a story likely caused by an aggressive cache and the lack of nocache headers.",barry
Future Releases,8923,cron timeout is too short,,Cron API,,normal,normal,Future Release,defect (bug),reopened,dev-feedback,2009-01-22T23:50:57Z,2016-06-14T05:29:59Z,"Many users have reported that 2.7 cron sometimes fails to publish future post.
And it is further reported that it depends on the number of jobs on the cron queue - when the queue is too long, it will miss some.
I believe this is because we set the timeout value too short:
wp_remote_post($cron_url, array('timeout' => 0.01, 'blocking' => false));
When making a request to wp-cron.php, it won't return until all cron jobs are executed. And 0.01 is just too short time span. It doesn't hurt to give it sufficent time, such as 10 minutes. It will return as long as the mature crons are fired up and executed (in most cases, it's going to be at most a few seconds ).
",hailin
Future Releases,11800,doubled execution of cron jobs,westi,Cron API,2.9.1,normal,normal,Future Release,defect (bug),new,dev-feedback,2010-01-07T11:17:53Z,2015-12-03T19:42:41Z,"Hi,
as I've already mentioned in ticket #11505 , cron-jobs occasionally get executed twice (e.g. daily backup arrives two times).
I've changed the code according to the patch attachment:ticket:11505:ticket-11505-stop-gap.patch (which derives from [http://wpengineer.com/ping-problem/]) after my comment:ticket:11505:49 and had no doubles within this time period. This week I've upgraded to WP 2.9.1 and since then backups arrive two, sometimes three times, again.
Looking at the changes from 2.9 to 2.9.1, I have no other explanation for this behavior. - Maybe we should consider having a closer look again on this patch attachment:ticket:11505:ticket-11505-stop-gap.patch .
Greetz,
Berny",neoxx
Future Releases,15148,Cron Storage Abstraction,,Cron API,,normal,normal,Future Release,enhancement,new,dev-feedback,2010-10-19T04:04:00Z,2017-04-07T05:51:55Z,Abstract cron storage to allow pluggable storage schemes.,ryan
Future Releases,23133,Display a warning in the admin if cron tasks fail due to blocked HTTP requests,,Cron API,3.5,normal,major,Future Release,enhancement,new,dev-feedback,2013-01-07T08:33:05Z,2017-11-22T21:35:07Z,"I recently upgraded my very simple WP site to 3.5 where the following was in use:
Theme: Twenty Eleven
Plugins: None Activated
I have been completely unable to submit a post for publishing in a future date, when the time occurs, I get a ""missed schedule"" message.
The schedule entry in cron is as follows:
{{{
Next due (GMT/UTC): Jan 4, 2013 @ 11:28 (1357298880)
Schedule: One-off event
Hook: publish_future_post
Arguments: [0]: 358
}}}
Increasing the timeout value in cron.php has made no difference.
I will need to remain on a lower release until this is fixed or a diagnosis ""kit"" is made available.
I am not using any software other that WP produced at this point and feel that the lack of wp-cron documentation and support in the public domain leaves alot of people clocking many hours googling in desperation...
Make a difference in 2013 and get 3.5 development priorities to de-mystify the methods of fixing wp-cron please :o)",prb22public@…
Future Releases,37586,Menu customizer: search results not properly filtered,,Customize,4.3,normal,normal,Future Release,defect (bug),new,dev-feedback,2016-08-05T16:36:50Z,2016-12-11T18:33:41Z,"{{{customize_nav_menu_available_item_types}}} is a filter located in {{{class-wp-customize-nav-menus.php}}}.
The purpouse of this filter is to restrict item types available in the Menu Customizer.
This filter should be applied even if I perform a research using the search field in Menu Customizer.
But this does not happens.
While in Menu Customizer, doing a research, in search results shows up even items of specific types excluded with {{{customize_nav_menu_available_item_types}}} filter.
We can resolve this issue using another filter always located in the same class: the {{{customize_nav_menu_searched_items}}} filter.
With this filter we can restrict the selections of items received from the search result just before sending them to the frontend (ajax response).
But this could be considered only a workaround and not a solution, because items should be filtered/excluded by type BEFORE wordpress performs the query to the database.
We should suppose that, if we uses the {{{customize_nav_menu_available_item_types}}} to filter item types available on Menu Customizer, most likely we do not want search for elements of theese item types. ",virgodesign
Future Releases,42806,Allow installing themes in the Customizer on multisite,,Customize,,normal,normal,Future Release,enhancement,new,dev-feedback,2017-12-05T17:47:40Z,2018-01-08T18:49:40Z,"Currently the ""Install Themes"" section in the Customizer isn't added when using multisite.
There is no technical problem with the installation process, as it still works correctly, simply by adding removing the restriction to only add the section (and enqueueing the related script) if `is_multisite()`, which I tested before opening this ticket.
However, what would need to be figured out is how to deal with enabling themes, because by default an installed themes isn't enabled anywhere. And of course it would only be possible for the network administrator, but I think that would still bring a huge benefit, because right now it isn't possible in multisite at all.
Here are two suggestions for possible approaches:
1. When in a multisite, there could be a notification like ""By installing a theme you also automatically enable it for this site."" Then, after the installation logic we would only need to handle that part automatically. If we go with that approach, we would need to make sure that the current user has both the `install_themes` and `manage_network_themes` capabilities.
2. When in a multisite, there could be a separate section ""Network Installed Themes"" that includes all themes installed, regardless of whether they're enabled for the site. Each themes would have a button to enable/disable it for the site. That section would require the user to have the `manage_network_themes` capability. We would furthermore need to ensure that themes are transitioned from the ""Network Installed Themes"" to the existing ""Installed Themes"" section and vice-versa when they are enabled/disabled for the site. Plus, when installing a theme through the ""WordPress.org Themes"" section, the user would need to be redirected to the ""Network Installed Themes"" section with that theme pre-seleted, to easily be able to enable and preview it.
There are benefits to both ways: While the first approach will be much simpler to implement, it somewhat mixes installing and enabling themes into one. The latter approach will allow more flexibility, but may be overly complex. Especially since installing themes without being able to enable them will make the process useless in multisite, I think I prefer the first approach. Maybe a mix of both could be the right way too, where we start with implementing the first approach as a first iteration (that could even be merged into core as that), but keeping it future-compatible to possibly add a dedicated ""Network Installed Themes"" section later.",flixos90
Future Releases,37915,Customize: allow terms to be created in nav menus,boonebgorges,Customize,4.7,normal,normal,Future Release,enhancement,assigned,dev-feedback,2016-09-01T20:51:39Z,2018-01-03T02:52:53Z,"Follow up to #34923. When setting up initial site structure, in many cases it's as important to be able to create new terms to add to menus as the ability to create posts. For users, the distinction between terms and posts probably isn't immediately clear, so this functionality gap may be confusing.
There are several patches on #34923 that contain the needed framework here, but we need the ability to preview terms before we can add support for terms.
This depends on #37914. Milestoning for 4.7 now for tracking, but we're waiting for that ticket before we can proceed here.",celloexpressions
Future Releases,40451,Customizer: Introduce plugin management,,Customize,4.7.3,normal,normal,Future Release,feature request,new,dev-feedback,2017-04-14T18:23:53Z,2017-11-16T17:26:54Z,"There is currently not a way to discover or upload plugins in the customizer, the only way is in WP Admin.
https://codex.wordpress.org/Managing_Plugins#Automatic_Plugin_Installation
https://codex.wordpress.org/Managing_Plugins#Manual_Plugin_Installation
Themes already have #37661 and #40278.",lukecavanagh
Future Releases,43578,Unexpected MYSQL data format,,Database,4.9.4,normal,normal,Future Release,defect (bug),new,dev-feedback,2018-03-19T19:36:00Z,2018-03-24T18:58:08Z,"When I use field `user_id` in `$wpdb->insert` it set value to Integer, but the table I add data into has `user_id` text field.
It works normally only if `format` parameter specified.
Example:
{{{#!php
query(""CREATE TABLE {$wpdb->prefix}_test (`id` INT, `user_id` VARCHAR(16))"");
$wpdb->insert(""{$wpdb->prefix}_test"", ['id' => 1, 'user_id' => 'stringKey']);
print_r($wpdb->get_row(""SELECT * FROM {$wpdb->prefix}_test WHERE id = 1""));
}}}
Result: `stdClass Object ( [id] => 1 [user_id] => 0 )`",loranrendel
Future Releases,12257,wpdb Scales Badly Due to Unnecessary Copies of All Query Results,,Database,,normal,critical,Future Release,defect (bug),assigned,dev-feedback,2010-02-17T03:08:06Z,2015-02-19T07:43:55Z,"While working on #11726, I encountered a reproducible crash in wpdb::query()
The following code causes memory exhaustion on large result sets:
{{{
while ( $row = @mysql_fetch_object($this->result) ) {
$this->last_result[$num_rows] = $row;
$num_rows++;
}
}}}
The memory exhaustion message is error-controlled, causing a white screen of death even in debug mode.
I searched wp-db.php for references to $this->last_result, and I found no justification for these object reference copies. $this->last_result '''should''' be maintained as a MySQL resource and properly optimized using the MySQL client layer instead of this PHP nonsense.
Tagging for dev-feedback to discuss which Milestone is appropriate.",miqrogroove
Future Releases,15499,Add an index for get_lastpostmodified query,,Database,3.0.1,normal,normal,Future Release,enhancement,new,dev-feedback,2010-11-19T18:20:31Z,2015-02-15T15:07:40Z,"I had a friend (Jools Wills) look over a WordPress site recently, to get a fresh view on what might be optimised, and he noticed a query which might benefit from an additional index on ```WP_Posts```. The query ```SELECT post_modified_gmt FROM $wpdb->posts WHERE post_status = 'publish' AND post_type = 'post' ORDER BY post_modified_gmt DESC LIMIT 1``` in ```get_lastpostmodified``` is run for last modified date in GMT, and currently doesn't use an index. This SQL is run whenever certain types of feed are requested as far as I can see.
We added ```CREATE INDEX type_status_modified ON wp_posts (post_type, post_status, post_modified_gmt);``` and ```CREATE INDEX type_status_modified_no_id ON wp_posts (post_type, post_status, post_date_gmt);``` and the query runs a lot faster now. The following timings were taken running the first query (```post_modified_gmt```) on a 36,362 row posts table. Note that it doesn't use filesort after the index has been added.
''Before:''
{{{
mysql> EXPLAIN SELECT post_modified_gmt FROM slgr_posts WHERE post_status = 'publish' AND post_type = 'post' ORDER BY post_modified_gmt DESC LIMIT 1;
+----+-------------+------------+------+------------------+------------------+---------+-------------+-------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------+------+------------------+------------------+---------+-------------+-------+-----------------------------+
| 1 | SIMPLE | slgr_posts | ref | type_status_date | type_status_date | 124 | const,const | 24718 | Using where; Using filesort |
+----+-------------+------------+------+------------------+------------------+---------+-------------+-------+-----------------------------+
1 row in set (0.03 sec)
}}}
* 0.21290683746338ms
* 0.25690102577209ms
* 0.230553150177ms
* 0.2274341583252ms
* 0.23083996772766ms
''After:''
{{{
mysql> EXPLAIN SELECT post_modified_gmt FROM slgr_posts WHERE post_status = 'publish' AND post_type = 'post' ORDER BY post_modified_gmt DESC LIMIT 1;
+----+-------------+------------+------+---------------------------------------+----------------------+---------+-------------+-------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+------------+------+---------------------------------------+----------------------+---------+-------------+-------+-------------+
| 1 | SIMPLE | slgr_posts | ref | type_status_date,type_status_modified | type_status_modified | 124 | const,const | 24718 | Using where |
+----+-------------+------------+------+---------------------------------------+----------------------+---------+-------------+-------+-------------+
1 row in set (0.00 sec)
}}}
* 0.00082707405090332ms
* 0.00072288513183594ms
* 0.00074386596679688ms
* 0.00066494941711426ms
* 0.00066208839416504ms
In ```get_lastpostmodified``` both these queries are run, so the total savings in my case on a quiet server are nearly 0.5 seconds... worth having, I reckon.
I've not created a patch for schema changes before, but I think the only place the change would need to go would be ```scheme.php```? Suggested patch attached.",simonwheatley
Future Releases,18315,Add an index to the GUID column in the posts table,,Database,3.2.1,normal,normal,Future Release,enhancement,reopened,dev-feedback,2011-08-02T04:31:01Z,2015-12-03T20:00:00Z,"Running queries on the GUID column in the posts table is slow because the column is not indexed. The attached patch adds an index.
Note, this affects ticket #18286 - I will update that ticket with appropriate patches to reflect this request.",alexkingorg
Future Releases,25768,"date_i18n() is wrong for certain formats, escapes sequences and daylight saving time",,Date/Time,3.7.1,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2013-10-30T11:08:20Z,2015-12-03T15:31:34Z,"{{{date_i18n()}}} returns wrong values in the following cases:
* If time zone is not GMT {{{date_i18n( 'c', time() )}}} does not return the correct difference to GMT part, e.g., 2013-10-30T14:00:00+00:00 instead of 2013-10-30T14:00:00+01:00.
* The time zone offset is sometimes wrong:
{{{
/*
* Test is called in time zone Europe/Berlin at a date where daylight saving time is off!
* (Daylight saving time in Europe/Berlin was switched off at 2013-10-27)
*/
// results 2013-10-29T22:15:03+01:00 while daylight saving time (Europe/Berlin) is off; result is correct
echo(date_i18n('Y-m-d\TH:i:sP', 1383084903));
// results 2013-10-11T19:37:20+01:00 while daylight saving time (Europe/Berlin) is on; result is wrong! should be +02:00!
echo(date_i18n('Y-m-d\TH:i:sP', 1381520240));
}}}
* {{{date_i18n( 'D | \D | \\D | \\\D | \\\\D | \\\\\D | \\\\\\D' )}}} does not escaping properly.
The implementation of {{{date_i18n()}}} is not very well at all. Therefore it was completely rewritten solving the issues above. Performance should be better too. I added some tests too.
This ticket is a result of the discussion in ticket #20973. You can find a more detailed discussion there.",raubvogel
Future Releases,28992,mysql2date() return empty string not false sometimes added doing it wrong message,,Date/Time,3.8,normal,normal,Future Release,defect (bug),new,dev-feedback,2014-07-23T00:14:34Z,2015-10-13T11:38:38Z,"If you pass a empty date string or bad date to mysql2date() we get a empty string back
e.g.
mysql2date( 'Y-m-d', """" )
mysql2date( 'Y-m-d', 'i am not a date' )
see the unit tests for more examples
I have created patch to return false if it not going to return a date as this is safer i belive",pbearne
Future Releases,28636,Add functions for working with local dates and times,,Date/Time,2.9,normal,normal,Future Release,enhancement,new,dev-feedback,2014-06-25T18:53:31Z,2016-09-14T21:20:21Z,"Since WordPress sets `date_default_timezone_set( 'UTC' )`, working with local dates and times can sometimes be a bit of a nuisance. I'd like to propose adding a couple of functions to replace at least `date()` and `strtotime()`. We can add replacements for others too, like `mktime()` if the interest is there.
I've put together two proposals for accomplishing this, one using `date_default_timezone_set()` to temporarily change the timezone, and another (far more complicated version) using `DateTime`/`DateTimeZone`. I think the former is preferable, unless anyone has any reasons, performance or otherwise, why resetting the default timezone might be a bad thing?
I'm not married to the function names I chose (`wp_date()` and `wp_strtotime()`), so if it would be preferable to name them e.g. `wp_local_date()` and `wp_local_strtotime()`, I'm open to it.",mboynes
Future Releases,10660,Time zone suggester based on nascent WordPress.org API call,rmccue,Date/Time,2.8.4,normal,normal,Future Release,feature request,assigned,dev-feedback,2009-08-20T05:59:42Z,2017-01-03T10:13:12Z,"The attached patch uses a new API call to http://api.wordpress.org/core/ip-to-zoneinfo/1.0/ to retrieve a suggested time zone based on client (not server) IP address.
A button is added next to the existing dropdown list of time zones providing the option to ""Suggest a time zone"". This calls the API using an AJAX/JSONP request which then auto-selects a time zone for the user from the dropdown.
Visual feedback is via a spinner when fetching and then a text response.
Additionally the Date and Time settings have been split out to a new settings page.
Related ticket: #10324",sambauers
Future Releases,31661,Quicktags: Can't add them using just a keyboard in IE,,Editor,4.1,normal,normal,Future Release,defect (bug),new,dev-feedback,2015-03-17T01:49:00Z,2016-11-28T18:00:42Z,"When using just a keyboard, I seem to be unable to make use of the quick tags.
This seems to be an issue just with Internet Explorer. Firefox and Chrome seem to be functioning as intended.
Steps to reproduce:
1. Find a comment in the admin and toggle ""Quick Edit""
2. Select part of the text (this step doesn't necessarily have to be done with the keyboard)
3. Use Shift+Tab to shift focus from the text area to a button (for example, b or i)
4. Hit Enter to trigger the button
In IE, it seems to place the opening tag on either end of the selection. In Chrome and Firefox, it properly wraps the selection in the selected tag.
For illustration, here's some GIFs I've made:
Internet Explorer:
[[Image(http://i.imgur.com/XVgpu8A.gif)]]
Chrome:
[[Image(http://i.imgur.com/4TcajEu.gif)]]
",Cheffheid
Future Releases,14356,Better string for onbeforeunload event dialog,adamsilverstein,Editor,,low,normal,Future Release,enhancement,assigned,dev-feedback,2010-07-19T18:53:15Z,2017-08-07T16:04:43Z,"The WP string for this now is:
''The changes you made will be lost if you navigate away from this page.''
The resulting dialog is:
''Are you sure you want to navigate away from this page?
''The changes you made will be lost if you navigate away from this page.
''Press OK to continue, or Cancel to stay on the current page.
''[OK] [Cancel]
Which is repetitive and, it seems to me, confusing.
I was thinking we could change our string to something not repetitive that complements better the default strings. E.g.:
''You have unsaved changes that will be lost!
Patch available upon request.",demetris
Future Releases,29923,Improve the writing experience on mobile,,Editor,,normal,normal,Future Release,enhancement,new,dev-feedback,2014-10-11T01:01:50Z,2017-08-07T16:18:12Z,"Maybe something like the screenshot attached.
Problems:
* In iOS, position fixed doesn't work when the keyboard is open. And that's exactly when we need it. But there are workarounds. We can absolute position everything and make only the iframe scrollable. Oh wait...
* `overflow: hidden;` doesn't work on `html` and `body`. Can be worked around by using `#wpwrap` instead. We can also block scrolling completely with JS since the content we want to scroll is in an iframe. But...
* For some reason Apple decided to automatically adjust the height of iframes to its content. So for this we'll need to force a specific height on the iframe, `html` and `body` tags, and make the `body` scrollable. Seems to work.
* There are no events fired when the keyboard shows or hides. Also no resize event. The keyboard kind of floats over the window. This means that the window height doesn't change and that we can't detect the height of the visible area and keyboard. But it's possible to work around that too. :)
The screenshot is from a working prototype.
Ideally there should be a left and right arrow on the toolbar so you can browse the tools.
The post.php screen stays mostly the same, with a preview of the content. When you click on it, it goes ""fullscreen"". When you hide the keyboard or tab away, it goes back to the original screen.
The alternative is to leave things as they are, with the toolbar unpinned on top of the editor, but we could still move all the buttons to one row with arrows to browse them.",iseulde
Future Releases,22435,Export API,,Export,,normal,normal,Future Release,enhancement,new,dev-feedback,2012-11-13T16:41:55Z,2017-12-13T21:26:06Z,"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:
{{{
#!php
'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?
",nbachiyski
Future Releases,34414,Add extra item fields to exported WXR file,,Export,4.4,normal,normal,Future Release,feature request,new,dev-feedback,2015-10-23T12:01:43Z,2016-11-11T08:16:47Z,"Hello
I am one of WPML developers. WPML is plugin which allows user to make multilingual sites, set language information to posts etc.
Straight to the point: we want to make it available to add to exported posts/pages an information about their language. Language information is stored in our own tables, so we cannot use existing WXR elements like those for taxonomies or custom fields.
It would be perfect if before closing tag would be executed hookable action which will echo those additional elements, coming from plugins such our.
I am attaching proposed patch.
Example of usage:
{{{
add_action('wxr_export_item_extra_fields', 'here_wxr_export_item_extra_fields');
function here_wxr_export_item_extra_fields($post) {
echo """";
}
}}}
",kkarpieszuk
Future Releases,13066,Last-Modified headers for individual comment feeds are incorrect,jgci*,Feeds,3.0,low,normal,Future Release,defect (bug),accepted,dev-feedback,2010-04-21T07:32:34Z,2017-11-14T20:43:03Z,"The WP::send_headers function currently uses get_lastcommentmodified() to set the Last-Modified header for all comment feeds. This is a problem when used for individual post comment feeds. The function gets the last modified comment across all blog posts. That means that every time a comment is posted anywhere, the Last-Modified header for ALL comment feeds is refreshed. Issues:
1. This is technically incorrect, since only the global comment feed and one specific post's comment feed have changed with the last comment (not all possible comment feeds); and
2. It means that If-Modified-Since requests for other post comment feeds will not receive a 304 response when they should do (since their content hasn't changed). On blogs with many posts and many comment feeds, this will have a large impact on bandwidth because lots of requests will receive 200 responses where 304's would have done, just because a comment was posted on some other post.
If I've understood the flow correctly, $wp_query hasn't been fully set up at the time this function is called, so changing this behaviour would require some change in the flow of things (e.g., the handling of last modified headers for feeds moves into the do_feed() function). But doing so would mean that Last-Modified headers are correct/meaningful and that many more 304 responses can be served.
Any thoughts?",solarissmoke
Future Releases,34083,Feed for post type should link to post type archive if available,stevenkword,Feeds,,normal,normal,Future Release,enhancement,assigned,dev-feedback,2015-09-29T20:50:33Z,2017-03-17T19:16:03Z,"This post type feed: https://yoast.com/dev-blog/feed/
has
{{{
https://yoast.com
}}}
Even though that particular post type has a post type archive. IMHO, it should link to the post type archive `https://yoast.com/dev-blog/`. ",joostdevalk
Future Releases,9611,Make comment feeds fail with an error code when comments are closed,,Feeds,2.8,normal,normal,Future Release,enhancement,new,dev-feedback,2009-04-21T14:12:42Z,2015-09-02T00:24:59Z,"This is mostly a suggestion as an enhancement.
When you close a post's comments and pings, it should no longer output an rss feed. Instead, it should return a not found (404) or gone (410) error and die.
Likewise, if all posts and pages on a site disallow comments and pings, the comments feeds should not be broadcast, and should return the same error code.
Thoughts?",Denis-de-Bernardy
Future Releases,9510,Multiple feed fixes and enhancements,,Feeds,2.7.1,normal,major,Future Release,enhancement,new,dev-feedback,2009-04-11T09:36:47Z,2015-08-10T19:39:16Z,"Currently, the feed always returns the same subtitle, self link, alternate link and replies link no matter what the page type is. I think they should be different for each page type.",peaceablewhale
Future Releases,8994,Incorporate MediaRSS Plugin into core,technosailor,Feeds,,normal,normal,Future Release,feature request,new,dev-feedback,2009-01-29T18:00:20Z,2018-05-11T15:54:30Z,"Per conversation on the hackers list, this ticket is a working area for incorporation of the MediaRSS plugin (http://wordpress.org/extend/plugins/mrss) into core for WP 2.8.",technosailor
Future Releases,36710,Symlinked directories should not be deleted recursively,,Filesystem API,,normal,major,Future Release,defect (bug),new,dev-feedback,2016-04-28T21:51:47Z,2017-10-10T21:57:03Z,"When deleting a symlinked plugin, the current behavior is to recursively delete everything in the plugin's real directory and then fail to unlink the symlink because rmdir won't work on a symlink. This is probably not what the site admin intended when they installed the plugin via a symlink. The desired behavior is to unlink only the symlink, leaving the external directory intact so that other symlinks remain intact.
My patch fixes this in WP_Filesystem rather than in the plugin deletion logic because it seems generally applicable to the use cases for symlinks.
What makes this hard is that trailing slashes are significant when dealing with symlinked directories. The trailing slash causes the link to be followed:
{{{
is_link('/link/') => false
is_link('/link') => true
}}}
The patch fixes deletion of symlinked plugins: it unlinks the symlink and leaves the real files intact. It should be carefully checked against other uses of delete because they might not include the trailing slash. In such cases, adding a trailing slash to the new `is_dir()` check might help. Could be a minefield, could be fine.
Related to #29408 but not a duplicate.",andy
Future Releases,19879,Better caching for get_dirsize,,Filesystem API,3.3.1,normal,normal,Future Release,enhancement,new,needs-unit-tests,2012-01-23T15:42:59Z,2016-10-25T16:15:36Z,"In a multisite install, when trying to determine whether a site has exceeded its storage quota, WordPress will scan through a blog's upload directory and sum up the file sizes, by running {{{filesize}}} against each one. With a large number of files, this can significantly slow down the upload process or certain portions of the Dashboard.
{{{get_dirsize}}} has transient caching in place but this is a single cache entry for all folders. It might be better if WordPress has a separate cache entry for each folder and was invalidated based on context so that get_dirsize does not need to be run constantly on older, unchanged directories as frequently.",batmoo
Future Releases,17491,Make is_email() compliant with RFC2822,,Formatting,3.1.2,normal,minor,Future Release,defect (bug),reopened,dev-feedback,2011-05-18T14:48:52Z,2015-07-20T18:12:45Z,is_email('toto.@toto.com') returns true,arena
Future Releases,22951,Performance enhancements for esc_url(),schlessera,Formatting,2.8,normal,normal,Future Release,defect (bug),assigned,dev-feedback,2012-12-15T04:36:03Z,2017-08-28T09:37:45Z,"`esc_url()` gets used a lot on WordPress admin pages. Sometimes 100 times or more. Nacin did some KcacheGrind measurements that had it as 7% of some pages. We can speed it up.
Most of the grind comes from `wp_kses_bad_protocol()`.
I had a thought that we're sort of going about things backwards. We're being very careful to exclude anything harmful — bad characters, bad protocols, duplicate fake-out protocols, etc. But almost 100% of the time, the URL going through it is a http/https URL that has completely normal characters in it. We can detect that really early, and bail.
I did some tests with this approach that showed a good time savings.
Quite obviously, there's no room to compromise on security, so we'll need to be watching unit test, and maybe even writing some new ones for good measure.",markjaquith
Future Releases,36934,Use of get_the_excerpt($post) is broken if post has no excerpt and you are inside a loop,swissspidy,Formatting,4.5,normal,normal,Future Release,defect (bug),reviewing,dev-feedback,2016-05-24T16:00:12Z,2018-02-15T22:39:59Z,"In changeset [36319] (and [36321]), a `$post` parameter was added to `get_the_excerpt()` in `post-template.php`. I was really excited when I discovered this but:
a) It's behaviour is inconsistent
b) It doesn't quite do what I'd hoped
c) It's broken in some circumstances
There are a few things wrong:
1) The behaviour is inconsistent depending on usage.
If you call `get_the_excerpt()` within the loop and if the post has no excerpt, then the post content will be stripped and truncated.
If you call it with the `$post` parameter and the post has no excerpt then nothing is returned.
Well...sometimes...
2) If you are inside a loop - say you're using `get_the_excerpt($post)` in a shortcode in a post - then you will actually get back the truncated content of the post from the loop that you are in.
This is because `wp_trim_excerpt( $text )` does `get_the_content('')` if `$text` is empty.
I think that the fix for this is to add an optional `$post` parameter to `wp_trim_excerpt()` and process it accordingly.
We'll also need to update `default-filters.php` to pass the extra parameter on the `get_the_excerpt` filter hook.
This change has the added benefit that `get_the_excerpt($post)` works consistently, fetching and trimming the post content if the post has no defined excerpt. Hooray!! (Been wanting this for YEARS!)
I'm working on a patch. It would be good to write a test for this too but I have no idea how. Happy to take feedback.",magicroundabout
Future Releases,11699,adjacent_post_link fails to strip anchor tags from post titles,,Formatting,2.9,normal,normal,Future Release,defect (bug),new,dev-feedback,2010-01-03T01:01:00Z,2015-10-01T03:26:33Z,"If you create a post with a title of ""Started using WordPress"", adjacent_post_link() emits a link that has that entire string (including the anchor tags) inside its own link.
The expected behaviour would be to strip the anchor tag to leave the link generated to the WordPress post.
This would then match being able to put links in post titles and using template code such as

which results in a heading with the appropriate title including the link that is part of the title. (If you see what I mean.)
A (but possibly the wrong) fix is to strip the anchor tags using:
{{{
1265a1266,1268
$allowed_html_in_titles = $allowedtags;
unset($allowed_html_in_titles['a']);
$title = wp_kses($title, $allowed_html_in_titles);
}}}
applied to wp-includes/link-template.php
",jaylett
Future Releases,23308,"make_clickable problem with multiple ""Punctuation URL character""",,Formatting,3.5.1,normal,normal,Future Release,defect (bug),new,dev-feedback,2013-01-28T15:09:59Z,2015-12-03T07:43:48Z,"make_clickable problem with multiple ""Punctuation URL character""
E.g.
{{{
http://www.wordpress.org/some-(parentheses).html
}}}
Results in this html code:
{{{
http://www.wordpress.org/some-(parentheses).html
}}}
But obvious should be:
{{{
http://www.wordpress.org/some-(parentheses).html
}}}
I suggest to replace:
wp-includes/formatting.php:1603
{{{
[\'.,;:!?)] # Punctuation URL character
}}}
with
{{{
[\'.,;:!?)]{1,} # Punctuation URL character
}}}",DrPepper75
Future Releases,33924,sanitize_html_class valid characters,,Formatting,4.4,normal,normal,Future Release,defect (bug),new,dev-feedback,2015-09-18T16:39:10Z,2017-01-06T13:10:43Z,"`sanitize_html_class` excludes some increasingly common valid html characters.
In particular the `@` character.
The use of `@` may not be extremely common for class names but it is being encouraged by some pretty renowned folks in the area of class naming conventions. http://csswizardry.com/2015/08/bemit-taking-the-bem-naming-convention-a-step-further/#responsive-suffixes
Actually pretty much anything is now valid for html classes except for spaces or tabs. I also use the `/` quite a bit in my classes but I thought I'd start with the `@` .",m-e-h
Future Releases,2833,wpautop breaks style and script tags,,Formatting,2.0.3,low,normal,Future Release,defect (bug),reopened,dev-feedback,2006-06-17T20:36:00Z,2017-12-19T14:36:31Z,"When I create a post in which I want to include Javascript or some styles, WordPress 'breaks'when showing those posts, because all newlines in the SCRIPT and STYLE tag are converted into BR tags.
Example:
{{{
}}}
Becomes:
{{{
}}}
And:
{{{
}}}
Becomes
{{{
}}}
This happens because wpautop adds those BR tags to the post. (As it should, just not within STYLE or SCRIPT tags.)
I've made a (temporary?) workaround for this by creating a pre and post event for wpautop, which substitute the necessary newlines by a temporary value in the pre event and placing them back in the post event. Although I think this should be incorporated in wpautop itself.
See also: http://wordpress.org/support/topic/76433 and http://wordpress.org/support/topic/76297
While searching trac I also found ticket #2346, which is about the same problem, but which was for 2.0 and self-closed by the submitter?
P.S. I have TinyMCE turned of.",Nazgul
Future Releases,11678,wpautop() fails on uppercase closing tags,,Formatting,2.9,normal,normal,Future Release,defect (bug),new,dev-feedback,2009-12-31T11:26:11Z,2015-10-01T03:34:19Z,"To reproduce, in a post enter:
{{{

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!

}}}
View the post (source) and you get:
{{{

Welcome to WordPress. This is your first post. Edit or delete it, then start blogging!

}}}
Because I (incorrectly) entered an uppercase closing tag, wpautop() thinks there is no closing tag so adds a , which then often renders as a double

tag. Close if this is not a bug, though I thought it may be good to do some sanitizing or something on uppercase tags.
",joehoyle
Future Releases,26868,"Function 'make_clickable()' doesn't make hyperlinks from explicit URLs using the `mailto:`, `tel:` and other schemes that do not start with `//`",,Formatting,3.8,normal,normal,Future Release,enhancement,new,needs-unit-tests,2014-01-18T16:00:14Z,2015-10-01T04:01:37Z,"Function `make_clickable()` tries to recognise URLs and convert these into clickable hyperlinks. The function is by default configured as a filter for comment text.
Unfortunately, the function assumes that all explicitly declared URLs begin with the string `//` after the scheme and colon parts which is not the case for the `mailto:`, `tel:` and many other schemes. Such URLs could usefully be made clickable, especially for use on smartphones and tablets.
This also leads to inconsistencies between explicitly and implicitly declared URLs. For example, the string `myemail@mydomain.com` is converted into a clickable hyperlink whilst the string `mailto:myemail@mydomain.com` is not.
By contrast, the TinyMCE post editor correctly and automatically makes both implicit and explicit `mailto:` links clickable but does nothing with `tel:`.
For reference, the syntax of URLs is defined by http://tools.ietf.org/html/std66, the `mailto:` scheme by http://tools.ietf.org/html/rfc6068 and that for `tel:` by http://tools.ietf.org/html/rfc3966.
As #16892 has illustrated, parsing URLs can be hard. The use of `wp_allowed_protocols()` may help in detecting which strings we wish to make clickable.
Found whilst testing #22946.",mdgl
Future Releases,19100,Introduce esc_color(),,Formatting,,normal,normal,Future Release,enhancement,new,dev-feedback,2011-11-01T12:16:14Z,2017-02-06T23:24:13Z,"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
Future Releases,30130,Normalize characters with combining marks to precomposed characters,,Formatting,,normal,normal,Future Release,enhancement,new,dev-feedback,2014-10-27T22:36:30Z,2018-03-16T21:04:57Z,"I ran into a little weird problem which I wanted to solve. And here it is:
I have a PDF file with German Umlauts (üöäÜÖÄ) and if I copy & paste them into WordPress I get the vowel (uoaUOA) which followed by a diaeresis (http://www.fileformat.info/info/unicode/char/0308/index.htm) instead of just one precomposed character.
This results in some problems:
- Search for words with umlauts doesn't work
- Proofreading fails
- W3C validation fails with warning ""Text run is not in Unicode Normalization Form C."" because precomposed characters are prefered (See: http://www.w3.org/International/docs/charmod-norm/#choice-of-normalization-form)
Solution: I made a proof-of-concept with the ""content_save_pre"" filter and it works. In this proof-of-concept I just replaced the two characters with the precomposed character:
'''$content = str_replace( ""a\xCC\x88"", ""ä"", $content );
$content = str_replace( ""o\xCC\x88"", ""ö"", $content );
$content = str_replace( ""u\xCC\x88"", ""ü"", $content );
$content = str_replace( ""A\xCC\x88"", ""Ä"", $content );
$content = str_replace( ""O\xCC\x88"", ""Ö"", $content );
$content = str_replace( ""U\xCC\x88"", ""Ü"", $content );'''
If we could (I know we can't, because WP is still supporting PHP 5.2) rely on PHP 5.3+ we could use a function for that:
http://php.net/manual/de/normalizer.normalize.php
So the above code (also used in the upcoming patch) would be just one line and much more general:
'''$content = normalizer_normalize($content, Normalizer::FORM_C );'''
Fun facts:
The problem is just on Mac OS X (Lion, 10.7.5) for me (on Ubuntu 14.04 or Win 7 I couldn't reproduce the problem).
Maybe this is an edge case and/or plugin territory.",zodiac1978
Future Releases,24106,Simplify wp_slash(),,Formatting,3.6,normal,normal,Future Release,enhancement,new,needs-unit-tests,2013-04-16T19:37:12Z,2018-01-11T03:35:00Z,"[23416] added the function {{{wp_slash()}}} for the slashing sanitization in #21767.
[https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-04-16&sort=asc#m595515 According to ryan], it has been modelled after {{{$wpdb->prepare()}}}, and therefore uses a custom {{{foreach}}} loop with an {{{if}}}-check in it.
I suggest to instead model it after {{{stripslashes_deep()}}} and {{{urlencode_deep()}}} to simplify the function and make it better readable.
The attached patch also makes it clearer that this function works in a recursive manner.",TobiasBg
Future Releases,22402,Stripping non-alphanumeric multi-byte characters from slugs,,Formatting,,normal,normal,Future Release,enhancement,new,dev-feedback,2012-11-10T05:07:10Z,2015-10-03T23:52:07Z,"`sanitize_title_with_dashes()` strips non-alphanumeric characters from a title to create a slug. Unfortunately it only strips ASCII non-alphanumeric characters. Apart from a few exceptions, all multi-byte characters are preserved. This means all non-Western (and plenty of Western) non-alphanumeric characters end up in the slug as they're treated just like any other multi-byte character.
As an example, here are some common non-alphanumeric Chinese characters which would ideally be stripped from slugs, but are not:
* 。 (U+3002, Ideographic Full Stop, %E3%80%82)
* ， (U+FF0C, Fullwidth Comma, %EF%BC%8C)
* ！ (U+FF01, Fullwidth Exclamation Mark, %EF%BC%81)
* ： (U+FF1A, Fullwidth Colon, %EF%BC%9A)
* 《 (U+300A, Left Double Angle Bracket, %E3%80%8A)
* 》 (U+300B, Right Double Angle Bracket, %E3%80%8B)
Obviously it would be impractical to make a list of ''all'' the non-ASCII characters we want to strip from slugs. The list would be gigantic.
So the question is, would it be possible to use Unicode ranges to blacklist (or whitelist) whole ranges of characters to be stripped from (or preserved in) slugs? Is this practical or even desirable?
Or would it make more sense to continue using a list of just the most common multi-byte characters to be stripped?
The latter makes a whole lot more sense, but the former is a more complete solution.
Thoughts?",johnbillion
Future Releases,11023,Gallery Category Doesn't change with article,,Gallery,,normal,normal,Future Release,defect (bug),new,dev-feedback,2009-10-24T01:49:09Z,2015-09-02T21:41:10Z,"Lets say I have a default category setup called Drafts that all articles go into at first by default. Then on completing the article before posting it live, I movie it to another category called News (no longer having the draft category ticked also). If I've added an image with that article that I click to view a bigger picture of in the gallery page (image.php). It still shows it as being listed under the Drafts category, while the article itself is listed under just News category.",mrgtb
Future Releases,39824,Gallery doesn't show images being uploaded,adamsilverstein,Gallery,4.0,normal,normal,Future Release,defect (bug),assigned,dev-feedback,2017-02-09T16:18:43Z,2018-02-18T16:27:36Z,"When you insert a gallery with images being uploaded in Edit Post page, the gallery doesn't show the images.
'''How to Reproduce'''
1. Open Edit Post page.
2. Insert a gallery with one uploaded image.
3. Select the gallery in tinyMCE then click on Edit.
4. Upload a big image file and/or slow down the internet to buy time for the following actions.
5. Choose Edit Gallery tab then click on Update Gallery button while the big image is uploading.
6. The gallery shows an empty element instead of the image.
7. If you edit the gallery and open Edit Gallery tab after the image uploaded, you'll see it has gone.",gonom9
Future Releases,13425,Image Gallery of Private Post is publicly displayed,,Gallery,3.0,normal,normal,Future Release,defect (bug),reopened,dev-feedback,2010-05-17T20:12:20Z,2016-05-10T18:49:38Z,"Might have been forgotten only, I just ran over this inconsistency while beta-testing:
'''Description:'''
The Image Gallery of a Private Post is displayed (in another post via the Shorttag with id parameter) whereas, when clicking on the images to go to the attachment page, you get a 404 not found.
'''Example:'''
[http://hakre.wordpress.com/2010/05/17/cui-utils-rev2/#more-1184 Post with Gallery][[BR]]
[http://hakre.wordpress.com/2010/05/17/cui-utils-gnu-tools-fur-windows-32-with-a-simple-setup/gnu-win-cui-util-00-setup/ Attachment of that Gallery]
'''Steps to reproduce'''
Create a new Post, set a title and the Status to private.
Save as Draft.
Preview it, to get the ID easily from URL.
Upload a Bunch of Images.
Insert the Gallery Shorttag inside that Post Body.
Publish the Post.
Create a second new Post
Give it a Title and Insert the Gallery Shortcode with the ID from the last Post.
Publish.
View.
Copy the URL.
Open another Browser so to have a new User-Session.
Visit that URL.
'''Expected Behaviour'''
You should not see a gallery.
'''Behaviour'''
You see a gallery.
When clicking on a gallery link you get a 404 page.
'''Feedback'''
I see an inconsitency here but have no Idea how to deal with it.
So either the gallery should not be found as well (not found as in 404 but in this case: not output) or the attachment pages should be able to call as well.
Related: #11697",hakre
Future Releases,13429,Updating Link URL on image within Admin with Gallery,,Gallery,2.9.2,normal,normal,Future Release,defect (bug),new,dev-feedback,2010-05-18T01:43:42Z,2017-03-01T07:59:05Z,"Image insertion no longer allows url to off site resource within Gallery.
When inserting a gallery you are unable to specify the Link URL. It keep reverting back to the default.",vshoward
Future Releases,12799,Allow gallery shortcode to accept a maximum number of items,,Gallery,2.9,normal,normal,Future Release,enhancement,new,dev-feedback,2010-04-01T17:55:55Z,2015-10-22T19:34:46Z,"A ""would be nice"" feature of the gallery would be to allow for a maximum number of items to be displayed.
The main use of this feature would be to allow a page to show a ""preview"" of some of the images contained within one or more subpages, eg:
* Some event
[gallery link=""file"" columns=""4"" orderby=""rand"" maximum=""4"" id=""164""]
* Some other event
[gallery link=""file"" columns=""4"" orderby=""rand"" maximum=""4"" id=""200""]
",dtorbert
Future Releases,9930,is_serialized() returns false on serialized doubles,westi,General,,normal,minor,Future Release,defect (bug),reopened,needs-unit-tests,2009-05-24T17:23:43Z,2015-10-30T20:16:15Z,"Test case:
{{{
}}}
Expected: true
Got: false
serialize(1.2E+150) returns something like 'd:1.200000000000000013344651621705194036153934411236609269391465806550823148718924258603522328009361549E+150;', the plus sign after 'E' is not taken into account by the regexp",vladimir_kolesnikov
Future Releases,27799,json_last_error is not provided by JSON compatibility layer,rmccue,General,,normal,normal,Future Release,defect (bug),assigned,dev-feedback,2014-04-14T14:39:56Z,2017-02-12T10:14:40Z,"The [http://php.net/json_last_error json_last_error] function isn't provided in `wp-includes/compat.php` with the rest of the JSON compatibility functions, despite being available in PHP's JSON since 5.3.
Looking into this, it *should* be trivial to add error handling, but possibly non-trivial for exact compatibility with PHP.",rmccue
Future Releases,36561,Deprecated notices should be classified as such.,,General,,normal,normal,Future Release,enhancement,new,dev-feedback,2016-04-17T11:16:42Z,2017-10-02T19:14:29Z,"All errors triggers should be classified with the appropriate error level.
Most notably, the `_deprecated_function()`/`_deprecated_constructor()`/`_deprecated_file()`/`_deprecated_argument()`/`_doing_it_wrong()` function do not pass an appropriate error level to `trigger_error()`.
For the deprecated function group, the most appropriate level seems to be `E_USER_DEPRECATED` which was introduced in PHP 5.3.0.
For `_doing_it_wrong()` an `E_USER_NOTICE` (or `E_USER_WARNING`) seems more appropriate.
Fixed in the accompanying patch.
For backward compatibility with PHP 5.2, a define for `E_USER_DEPRECATED` has been added to `wp-includes/compat.php` which follows the same logic as used in SimplePie for consistency:
https://core.trac.wordpress.org/browser/trunk/src/wp-includes/class-simplepie.php#L699
",jrf
Future Releases,34699,New function: `get_query_arg()`,,General,,normal,normal,Future Release,enhancement,new,dev-feedback,2015-11-16T12:51:31Z,2018-02-23T09:29:04Z,"For example i have url $url = 'http://example.com/?param=1&param2=2&param3=3' and I want get `param2` so I use function: get_query_arg('param2', $url);
Second argument: exists function add_query_arg and remove_query_arg",sebastian.pisula
Future Releases,27122,Optimization for PHP FPM,,General,3.8,normal,normal,Future Release,enhancement,new,dev-feedback,2014-02-13T22:59:21Z,2015-12-19T21:29:46Z,"This patch make {{{ wp_ob_end_flush_all }}} calling {{{ fastcgi_finish_request }}} instead of {{{ ob_end_flush }}} when php-fpm is used.
{{{ fastcgi_finish_request }}} flush the buffers '''and''' close the connection. This tweak increases page speed.
It also allows to run heavy tasks such as sending mail, writing logs or making complex calculations after the end of the request without slowing down the whole page load.
Symfony uses this tweak too, see this PR FOR further details: https://github.com/symfony/symfony/issues/1180",dunglas
Future Releases,38517,Remove references to 'articles' instead of 'posts',,General,,normal,normal,Future Release,enhancement,new,dev-feedback,2016-10-26T17:51:29Z,2016-10-26T18:33:34Z,"On the `Settings -> Discussion` screen, posts are referred to as ""articles"". The reason for this phrasing is to avoid ""post"" being used as a verb and a noun within the same sentence:
`Allow people to post comments on new articles`
Ref: https://core.trac.wordpress.org/ticket/22961#comment:9
This problem can be avoided by referring to submitting comments instead of posting comments:
`Allow people to submit comments on new posts`
There are a few related places where the phrase ""article"" is used instead of posts. These should all be replaced with ""posts"" for consistency.",johnbillion
Future Releases,33837,We should avoid Superglobals when possible,wonderboymusic,General,,normal,normal,Future Release,enhancement,assigned,dev-feedback,2015-09-11T19:53:44Z,2015-09-17T20:57:09Z,"We can probably add some helper functions that complete common tasks around Superglobal access
Examples of accessing here:
https://codeclimate.com/github/WordPress/WordPress/wp-admin/edit-comments.php
Something like `wp_verify_action( $action )` could replace the many instances of things like:
`isset( $_REQUEST['action'] ) && 'upload-attachment' == $_REQUEST['action']`
Without having to architect something like `Symfony/HttpFoundation`, we can make accessing them more rare.",wonderboymusic
Future Releases,37402,Standardise documentation for variadic functions,,General,,normal,minor,Future Release,task (blessed),new,needs-docs,2016-07-18T20:05:04Z,2017-11-30T13:17:02Z,"The functions listed below are variadic, meaning they accept an indefinite number of arguments. The inline documentation for such functions in WordPress is varied, and generally unclear.
A standardised format for variadic functions should be agreed upon and applied to these functions.
The following functions technically accept unlimited parameters, but in practice only accept up to two because they all ultimately call `WP_User::has_cap()`. A custom cap check could use more than two parameters, though.
* `author_can()`
* `current_user_can()`
* `current_user_can_for_blog()`
* `map_meta_cap()`
* `user_can()`
* `WP_User::has_cap()`
The following functions are actually variadic:
* `add_post_type_support()`
* `add_theme_support()`
* `apply_filters()`
* `array_replace_recursive()`
* `current_theme_supports()`
* `do_action()`
* `get_theme_support()`
* `_register_widget_form_callback()`
* `_register_widget_update_callback()`
* `walk_category_dropdown_tree()`
* `walk_category_tree()`
* `walk_page_dropdown_tree()`
* `Walker::paged_walk()`
* `Walker::walk()`
* `wp_dashboard_cached_rss_widget()`
* `WP_HTTP_IXR_Client::query()`
* `wp_iframe()`
* `wp_register_sidebar_widget()`
* `wp_register_widget_control()`
* `wp_sprintf()`
* `WP_Upgrader_Skin::feedback()` (plus the same in classes which extend it)
* `wpdb::prepare()`
Note that `do_action()` is irregular because its first variadic parameter is defined in the parameter list. This means its documentation is also irregular.
Finally, this method looks variadic, but it isn't, and it needs refactoring and docs:
* `WP_Dependencies::__construct()`",johnbillion
Future Releases,39043,HTTP API :: Its Not Possible To Send Data In Body For GET Requests,rmccue,HTTP API,4.7,normal,normal,Future Release,enhancement,assigned,dev-feedback,2016-12-04T03:59:27Z,2017-10-02T11:28:09Z,"Currently there is no way to send data in the body of GET requests using the HTTP API (it gets sent as query args instead). While it may not be a very common use-case, its a valid one nevertheless. I've stumbled upon this while writing an integration for a [https://apidocs.sendinblue.com/list/#1 3rd-party API] which does not accept data as query args like most APIs typically do.
#37456 is relevant to this issue.
Patch incoming...",lots.0.logs
Future Releases,21273,Automatically open help panel,,Help/About,,normal,trivial,Future Release,enhancement,new,dev-feedback,2012-07-14T19:04:20Z,2015-10-13T03:23:11Z,"The help screen is highly inaccessible. Developers are not able to link to content in the help panels if you need to point users to specific directions for your plugin.
This patch is a quick stab at it to see if it's worth while.
What it does it allow direct links to the help panel. Upon pageload, it'll automagically open up to the correct panel.
Usage:
1. Install the patch
2. Click http://wordpress.dev/wp-admin/index.php#tab-panel-help-layout
Again, this is a quick stab. The concept could definitely be improve/abstracted and DRYed up.
Let me know your thoughts :-)",ptahdunbar
Future Releases,14432,Role-based help text,garyc40,Help/About,3.0,normal,normal,Future Release,enhancement,assigned,dev-feedback,2010-07-27T18:53:00Z,2015-05-12T16:56:39Z,The text in the Help tab is based on the screen seen by an admin. We should make it so the role of the logged in user determines the text. ,jane
Future Releases,14981,Provide a context for post statuses,rockwell15,I18N,3.1,normal,normal,Future Release,defect (bug),assigned,dev-feedback,2010-09-27T23:21:29Z,2017-05-18T14:13:45Z,"1) /wp-admin/nav-menus.php: the ""Most Recent"" string (/wp-admin/includes/nav-menu.php:645) should be separated between the Pages context and the Articles context, since they can take different forms according to the language (i.e.: in French, ""Articles"" is masculine, ""Pages"" is feminine.
2) /wp-admin/edit.php: Same contextual need for ""All"", ""Published"", ""Scheduled"" and the rest of the per-status selector, for posts and articles (and others...). ",xibe
Future Releases,11740,Sorting tags and towns does not work well for utf-8,nbachiyski,I18N,2.9,normal,normal,Future Release,defect (bug),new,dev-feedback,2010-01-06T12:42:24Z,2015-12-03T07:21:37Z,"There are problems with sorting special Czech characters:
1) Options - General - Timezone selection.
Evropa (Europe)
First item should be Amsterdam, but instead of it there is ""Řím"" (Rome in Czech). And this is not right, character Ř should be between R and S.
2) Editing posts - Select from most used tags.
You can create tags ""Rome"", ""Amsterdam"" and ""Řím"".
Tags are also sorted in a bad way, first is ""Řím"".
It is very problematic for Czech users when there are many tags, because it does not help them...",pavelevap
Future Releases,39210,switch_to_locale() unloads all plugin and theme translations,,I18N,4.7,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2016-12-09T16:07:08Z,2018-04-13T16:17:44Z,"When using switch_to_locale() in the backend, all translations loaded into the `$l10n` global will be unloaded, except for the default one. This makes plugin and theme translations unavailable after using switch_to_locale().
In the `load_translations` method of `WP_Locale_Switcher` there are two functions called right after each other for each of the currently loaded domains:
{{{#!php
unload_textdomain( $domain );
get_translations_for_domain( $domain );
}}}
`unload_textdomain` loads all unloaded functions into the `$l10n_unloaded` global. Later when `_load_textdomain_just_in_time()` is called in `get_translations_for_domain()`, all domains set in `$10n_unloaded` will be short-circuited in the following statement
{{{#!php
// Short-circuit if domain is 'default' which is reserved for core.
if ( 'default' === $domain || isset( $l10n_unloaded[ $domain ] ) ) {
return false;
}
}}}
This results in only the new translations for the domain `default` being loaded. All plugin and theme translations will be lost. But even when `|| isset( $l10n_unloaded[ $domain ]` is commented out, it doesn’t work, because WordPress then tries to load a language file from the `WP_LANG` folder, and not from either a theme or plugin directory.
In #26511 it was already mentioned by @rmccue that this might affect emails to be sent in the wrong language: https://core.trac.wordpress.org/ticket/26511#trac-change-8-1430202811399151.
I run into this problem when I want to send notification emails to subscribed email adresses whenever I publish a post.
= Test case =
I created a minimal theme with a translations for `en_EN` and `de_DE` that displays some debug output in the backend and the frontend.
Preparatory steps:
1. Set site language to German (de_DE).
2. Set admin user language to English (en_EN). If the language dropdown does not appear, temporarily set the site language to German so the translation is downloaded and then select the users language again.
3. Install the test theme.
Now an admin notice should appear in the backend that shows debug output. There are string translations saved before and after `switch_to_locale`. Whenever `Untranslated default string` shows up, then a translation couldn’t be loaded.
---
Now if this is not intended behavior, I don’t really know how I would approach fixing this.",gchtr
Future Releases,7098,Multiple entity codes in POT file for the same character,chriscct7,I18N,2.5.1,normal,normal,Future Release,enhancement,reviewing,dev-feedback,2008-06-05T11:33:12Z,2015-12-03T19:34:42Z,"In the wordpress.pot file, two characters are represented by both their numbered and lettered HTML entities. These are:
'''Em-dash:''' the POT file contains both — and —
'''Right angle quote:''' the POT file contains both » and »
I'm not sure if it matters but it certainly is a little inconsistent.
",leuce
Future Releases,26638,Performance Increase in l10n (9-12%),,I18N,2.9,normal,normal,Future Release,enhancement,new,dev-feedback,2013-12-16T09:41:22Z,2017-02-05T13:59:16Z,"While doing some writing on profiling I choose Wordpress as my example application and wrote a small patch that in my testing boosts performance of index.php by 9-12% (with the dataset from my 6 year old blog, ~250 posts, lots of plugins and extra stuff).
This performance increase is found by making a small change to the way `translate()` works, effectively cutting out the use of the `NOOP_Translates` class.
Patch is attached.",dshafik
Future Releases,37539,translate_user_role only working in admin,,I18N,4.0,normal,normal,Future Release,enhancement,new,dev-feedback,2016-08-01T14:35:28Z,2016-08-06T12:27:55Z,"The user role translations are only available in the admin.
I'd like to see them available in the front-end aswell.
This is not working:
{{{#!php
if ( ! is_admin() ) {
load_textdomain( 'default', WP_LANG_DIR . '/admin-' . get_locale() . '.mo' );
}
}}}
",keraweb
Future Releases,12477,Search with special characters and similar terms,nbachiyski,I18N,,normal,normal,Future Release,feature request,new,dev-feedback,2010-03-02T17:42:46Z,2015-12-03T19:46:17Z,"I did:Tried searching for terms Metis and Métis
I saw:Those two searches turned up different sets of results.
I expected:The same set of search results, or at least everything when
I searched for Metis.
Can search be smarter when special characters are involved?",mrroundhill
Future Releases,17904,Multisite has more restrictions on user login character set,jeremyfelt,Login and Registration,3.0,normal,normal,Future Release,defect (bug),assigned,dev-feedback,2011-06-27T11:09:12Z,2018-03-09T22:49:01Z,"Multisite has more restrictions on the characters allowed in a user's login name compared to single site. This seems unnecessary and confusing. It was also the root of a recent bug in the importer, see [http://wordpress.org/support/topic/invalid-author-importing-single-wordpress-to-mulitsite-wordpress?replies=21#post-2186667 this forum thread] and the [http://plugins.trac.wordpress.org/changeset/401649 workaround].
I haven't worked up a patch yet since there seem to be a few locations where these restrictions are enforced and I don't know if I have found them all yet:
- wpmu_validate_user_signup() uses the regex `/[a-z0-9]+/`
- ms-default-filters.php adds `strtolower` to `sanitize_user`
Relevant: http://mu.trac.wordpress.org/changeset/1689 [12948]",duck_
Future Releases,16482,Visibility: password-protected breaks with redirected domains,,Login and Registration,3.0.4,normal,normal,Future Release,defect (bug),new,dev-feedback,2011-02-07T18:58:45Z,2015-10-01T01:14:11Z,"Pre-requisite to reproduce: domain.com must redirect to www.domain.com (haven't tested with other subdomains than www, but I'm sure it would be the same).
1. password protect a page
2. visit domain.com/protected (which redirects to www.domain.com/protected)
3. enter password
4. something about the redirect OR the way the password is stored/checked is broken; you are redirected to the wp-admin (WordPress login) page.
Sanity check:
1. password protect a page
2. visit www.domain.com/protected (requiring no subdomain redirect)
3. enter password
4. successful log-in
",monkeyhouse
Future Releases,35449,Add ability to filter back to blog link on login page,adamsilverstein,Login and Registration,,normal,normal,Future Release,enhancement,assigned,dev-feedback,2016-01-13T20:38:13Z,2016-04-05T06:21:39Z,"There is currently not a way to filter the ""Back to {site_name_here}"" link at the bottom of the `/wp-login.php` page.
Depending on context, a user may want to change the text that is displayed in that link as well as the link itself. One example would be that on WordPress.com, we use this wording: ""Return to {site_name_here}"".
I propose that we add a filter that will allow developers to customize that link depending on context.",ebinnion
Future Releases,31821,Make interim login URL filterable,johnbillion,Login and Registration,4.2,normal,normal,Future Release,enhancement,reviewing,dev-feedback,2015-03-31T14:36:20Z,2017-08-22T14:40:51Z,"Currently, there is no clean way to detect and filter the interim login URL, short of using the ''clean_url'' filter. Obviously, this is not ideal. Plugins that modify the login URL, like my plugin, Theme My Login, would definitely benefit from a direct filter on this.",jfarthing84
Future Releases,20019,wpmu_validate_blog_signup(): Allow '.' and '-' in blog names,,Login and Registration,3.0,normal,normal,Future Release,enhancement,reopened,dev-feedback,2012-02-10T23:04:29Z,2015-10-04T18:35:55Z,"Canonical uses Wordpress 3.x multisite as part of voices.canonical.com, for employees who do not have or wish to list their personal blog. The code is stock, except for one patch we maintain, which allows blog names (currently in WP as lowercase alphanumeric only) to also include '.' and '-'. This matches our global username format.
Attached is a patch extending wpmu_validate_blog_signup() to allow '.' and '-', with a tweak for the error text. We have been running the patch for awhile, and have not run across any problems with the rest of the code accepting this.",fo0bar
Future Releases,25239,$_SERVER['SERVER_NAME'] not a reliable when generating email host names,SergeyBiryukov,Mail,3.8,normal,normal,Future Release,defect (bug),reviewing,dev-feedback,2013-09-06T14:05:28Z,2018-02-18T14:06:50Z,"For quite some time I have been having an issue with my comment notifications. The From address has been wordpress@_. I haven't paid much attention to this, but I had some spare time and decided to pursue the issue. Here it is...
I am running WPMS w/ domains (latest stable) with Nginx and PHP5-FPM. In WordPress the comment notifications from email addresses are being generated using `$_SERVER['SERVER_NAME']` to get the current site's domain name.
e.g.
{{{
$wp_email = 'wordpress@' . preg_replace('#^www\.#', '', strtolower($_SERVER['SERVER_NAME']));
}}}
However, because of my environment my Nginx config for my site has the server_name set to ""_"" (underscore). Which is a catchall -- http://nginx.org/en/docs/http/server_names.html.
Site config in Nginx:
{{{
# Redirect everything to the main site.
server {
listen [::]:80 default_server;
listen [::]:443 ssl;
ssl_certificate /etc/nginx/ssl.crt/xxx.com.2012.crt;
ssl_certificate_key /etc/nginx/ssl.key/xxx.com.2012.key;
server_name _;
root /var/www/xxx.com;
access_log /var/log/nginx/xxx.com.access.log;
error_log /var/log/nginx/xxx.com.error.log;
client_max_body_size 100m;
if ($http_host = ""www.xxx.com"") {
rewrite ^ http://xxx.com$request_uri permanent;
}
include global/restrictions.conf;
# Additional rules go here.
include global/wordpress-ms.conf;
}
}}}
The default fastcgi_params has this set:
{{{
fastcgi_param SERVER_NAME $server_name;
}}}
Thus, `$_SERVER['SERVER_NAME']` is outputting ""_"" (underscore).
I propose we move away from `$_SERVER['SERVER_NAME']` when generating the from email addresses and use the available $current_site global object which stores the domain variable ($current_site->domain). I have implemented this change on my own site and have included the patch here.
In the meantime, anyone else facing this problem can change their fastcgi_param to $host instead of $server_name. In my opinion, not the best solution, but it works for now.",layotte
Future Releases,19847,wp_mail $from_name field is removing an extra character from the name,,Mail,3.3,normal,normal,Future Release,defect (bug),new,dev-feedback,2012-01-17T05:13:18Z,2015-09-02T00:14:35Z,"If the headers are sent as a string to wp_mail, parsing of $from_name field removes one required character at the end of the name. Hence causing a name field of ""Hakan"" to show up as ""Haka"" in the received email.
Line 257 of pluggable.php is causing this error.
$from_name = substr( $content, 0, strpos( $content, 'Send();
} catch ( phpmailerException $e ) {
return false;
}
}}}
or worse (not failing at all).
Yesterday had to hack core files to find out that an email address did not have a valid email format. Exceptions should either propagate in some way, or be reported to an error log.
",mark-k
Future Releases,23779,Can't insert large image if it's smaller than media setting but larger than theme setting,,Media,3.0,normal,normal,Future Release,defect (bug),new,dev-feedback,2013-03-15T00:47:08Z,2015-10-03T20:52:18Z,"If you upload an image that is larger than $content_width but not larger than the ""large"" setting in settings->media, the option to insert a ""large"" image into the post isn't available even though the image is large enough.
It looks like it must use $content_width as the actual width of the large image that's inserted, and the large_size_w setting to decide whether to show that option or not.",aaroncampbell
Future Releases,39883,Code hooking on `image_downsize` can no longer assume the file is an image,joemcgill,Media,4.7,normal,normal,Future Release,defect (bug),assigned,dev-feedback,2017-02-15T19:52:34Z,2017-05-23T20:29:02Z,"In r38949, Core pretty drastically changed the expectations that any code hooking onto the `image_downsize` filter could make until then, potentially leading to issues for integrators.
We went from having the `image_downsize()` function immediately return `false` if a file wasn't an image, not getting to that filter application at all, to only setting a variable with the result of the `wp_attachment_is_image( $id )` test and now applying the filter (not even passing said result, for that matter).
This was a pretty big safe assumption to take away from under integrators' feet.
Coupled to this, a wise integrator that might have picked up on this change could have wanted to have its own code have `image_downsize()` still returning `false` if it does not want to have the file further processed by the function, but there is no opportunity to, since returning `false` will cause `image_downsize()` to keep on with its processing instead of proceeding with `return $out`.
Returning anything but false or null will cause `image_downsize()` to return, but that might not always be desirable to preserve the way WP worked prior to 4.7.
What's better here for general use isn't as clear cut as what r38949 made it to be. I've discussed the case with @mikeschroder, and we've agreed to open this ticket so we can further discuss what should be done, if anything.",stephdau
Future Releases,23374,Custom photo title is overwritten upon completion of upload,,Media,3.5.1,normal,normal,Future Release,defect (bug),new,dev-feedback,2013-02-03T03:37:30Z,2015-06-28T03:02:55Z,"Version: 3.5.1 (latest)
Environment: Chrome 24.0.1312.57 on Mac OSX 10.8.2
Steps to reproduce:
1. Create a new post and click the Add Media button.
2. Add several large photos (>4MB). This is necessary to give you time to perform step 3.
3. Add new titles to the photos that are in the process of uploading.
Output: after a photo finishes uploading, its newly-added title get overwritten by a default title (taken from the filename)
Expected output: on the completion of a photo upload, the title field should be checked and preserved if necessary, not overwritten
(not related to plugins or theme)",franksvalli
Future Releases,32378,"Image Uploads automatically puts ""Olympus Digital Camera"" as caption",,Media,4.2,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2015-05-13T17:24:26Z,2017-02-22T19:36:41Z,"Images from Olympus cameras are automatically given the caption ""Olympus Digital Camera.""
Steps to reproduce:
1) Upload image that came from Olympus camera
2) Alternative text and caption are automatically filled in with OLYMPUS DIGITAL CAMERA
[[Image(automaticcaption.png,100%)]]
3) Published image displays grey border with caption OLYMPUS DIGITAL CAMERA
WordPress isn't alone in this issue; [https://www.flickr.com/groups/om-d_user/discuss/72157631054933782/ Flickr], [https://productforums.google.com/forum/?hl=en#!category-topic/picasa/picasa-web-albums/17rjmoBCR8c/ Picasa], [http://answers.microsoft.com/en-us/windowslive/forum/moviemaker-av/all-of-my-frames-show-sanyo-digital-camera-on-them/ccbe0d65-fb6c-4f2e-a44a-06af36f4d1bd/ Windows Live Movie Maker] users have also reported the same thing happening when they upload images.
This may be due to #22768, there appears to be code for media to “Use image exif/iptc data for title and caption defaults if possible.”
This is an image that was uploaded May 5th:
[[Image(nocaption.png,100%)]]
And this was uploaded May 7th, after the update:
[[Image(caption.png,100%)]]
A similar ticket where EXIF/IPTC captions populate description/post_content: #22768",vparkhere
Future Releases,31570,Infinite loop when filtering Media Library images by size in a modal (using wp_prepare_attachment_for_js),fuhton,Media,4.1.1,normal,normal,Future Release,defect (bug),assigned,dev-feedback,2015-03-09T13:48:25Z,2015-12-07T15:57:03Z,"In an attempt to restrict a post's Featured Image dimensions to imagers wider than 100px I implement the following code in `functions.php`:
{{{
function restrict_media_library_by_width($response, $attachment, $meta) {
if(isset($response['width']) && isset($response['height']) && $response['width'] > 100) {
return $response;
}
return false;
}
add_filter('wp_prepare_attachment_for_js', 'restrict_media_library_by_width', 10, 3);
}}}
I then click ""Set featured image"" and the Media Library modal that appears only loads one empty thumbnail and my Network panel in Chrome Dev Tools reveals it makes continued, repeated, infinite AJAX requests.
The only viable alternative I've found was to run a separate query within `ajax_query_attachments_args`, which is needed because the `_wp_attachment_metadata` key contains serialized data and that leaves no way to compare dimensions within a `meta_query`.
Obviously running this additional query is inefficient and more resource intensive than it should be. More details here: http://wordpress.stackexchange.com/questions/180500/filter-media-library-items-by-size/.",silb3r
Future Releases,23398,"Media Gallery - Clicking ""Restore Original Image"" in ""Scale Image"" pane loses 'Thumbnail Settings' pane.",,Media,3.4,normal,normal,Future Release,defect (bug),new,dev-feedback,2013-02-05T21:11:36Z,2016-02-21T20:57:20Z,"Reproduce the problem thusly:
Click ""Edit image"" in the ""Edit Media"" interface for any image.
`/wp-admin/post.php?post=1119&action=edit`
Scale the image a couple times in the 'Scale Image' pane. Update.
Click ""Restore Original Image"" in the 'Scale Image' pane.
Try to crop just the thumbnail.
The 'Thumbnail Settings' Pane is '''''gone'''''.
The image has to be deleted and re-uploaded to gain thumbnail control once again.",gr33nman
Future Releases,31352,Media icons are not retina friendly,joemcgill*,Media,3.9,normal,normal,Future Release,defect (bug),accepted,dev-feedback,2015-02-16T20:28:20Z,2018-05-23T08:37:31Z,See screenshot and [27726].,iseulde
Future Releases,13461,Preserve GIF transparency/alpha during thumbnail creation,,Media,2.9,normal,normal,Future Release,defect (bug),new,dev-feedback,2010-05-20T13:23:30Z,2016-09-20T14:17:56Z,"GIF images with transparent backgrounds get thumbnails with black backgrounds.
It was a similar ticket for PNG images in: http://core.trac.wordpress.org/ticket/2805",javitxu123
Future Releases,36477,Responsive images (srcset) can include images larger than the full size,joemcgill*,Media,4.4.2,normal,normal,Future Release,defect (bug),accepted,dev-feedback,2016-04-11T13:27:58Z,2016-12-17T22:58:04Z,"In many cases, I saw the resized and smaller images are much larger than the origin image, especially for the optimized images, it will make no sense to do that resize in this case, the worst case I've seen is about 13x larger than the origin and bigger image.
If an example can help to explain the problem, please take this picture:
https://cdn2.peterdavehello.org/wp-content/uploads/2016/04/status.png
Many thanks!",peterdavehello
Future Releases,38195,Adding more mime_types filter to Media Library,,Media,,normal,normal,Future Release,enhancement,new,dev-feedback,2016-09-29T21:49:35Z,2018-04-19T19:52:23Z,"In https://github.com/WordPress/WordPress/blob/e0a0be9579bf00c673f6fa9c68e87d4546271b37/wp-includes/post.php#L2191-L2206 WordPress is defining some default mime_types for filtering purpose in the media library.
At the moment this is everything starting with image, audio and video.
But there are more mime_types possible:
https://codex.wordpress.org/Function_Reference/get_allowed_mime_types#Default_allowed_mime_types
What about adding these mime_types in the way shown in #30788 ?
I suggest the following groups:
{{{
Documents:
-----------
application/pdf
application/rtf
application/msword
application/onenote
application/wordperfect
application/vnd (should handle MS, LO/OOo and iWorks)
text/plain
text/csv
text/calendar
text/tab-separated-values
text/richtext
}}}
{{{
Web-Documents
--------------
text/css
text/html
application/javascript
application/x-shockwave-flash
application/java
}}}
{{{
Archives:
---------
application/x-tar
application/zip
application/x-gzip
application/rar
application/x-7z-compressed
}}}
{{{
Misc:
------
application/x-msdownload (exe)
}}}
I'm just concerned about a possible performance problem.
See: #31071",zodiac1978
Future Releases,22075,Allow custom attributes to be set in `wp_get_attachment_link`,,Media,3.4,normal,normal,Future Release,enhancement,new,needs-unit-tests,2012-10-02T04:29:05Z,2015-12-03T19:54:47Z,"I answered a [http://wordpress.stackexchange.com/questions/65982 question] not so long ago on [http://wordpress.stackexchange.com/ WordPress StackExchange].
There I saw the need on a filter for `wp_get_attachment_link()` to allow the developer to add or remove attributes to the HTML without having to use a regex on it or creating the `a` tag again.
So I've done this small patch with changes to apply this enhancement to the function.",webord
Future Releases,28185,Expose image attachment title and/or filename in the image details modal,,Media,3.9,normal,normal,Future Release,enhancement,new,dev-feedback,2014-05-08T23:46:33Z,2015-03-12T23:48:07Z,"I ran into a case where I had a post with an image I wanted to set as the featured thumbnail. My Media library is very large and I didn't know the file name so I clicked the edit icon on the image to view the Image Details. Nowhere within the image details does it show either the image title, or file name. My suggestion would be to place it next to the words ""Image Details"", but i'm not married to the idea.
The search field in the media library looks for these attributes to filter the library list, it would be convenient if it were clearly labelled within the ""Image Details"" modal.
Additionally, once you do find the image in the media library, both the file name and image title are clearly visible.
I created an annotated video to clearly explain the issue:
https://www.youtube.com/watch?v=lS55abTV7qc",drrobotnik
Future Releases,21221,Image title and alt attribute content should be texturized.,,Media,3.4.1,normal,normal,Future Release,enhancement,new,dev-feedback,2012-07-11T19:49:18Z,2016-04-16T15:11:09Z,"
gallery_shortcode() texturizes the caption shown underneath images in galleries.
For consistency, alt and title tags content should also be texturized.
This is also valuable for developers extending the gallery shortcode or output, such as with the WordPress.com (and Jetpack) [http://en.blog.wordpress.com/2011/11/08/new-photo-carousel/ Gallery Carousel feature], as it provides i18n'd texturization, for EG.
See attached patch, which:
* uses wptexturize() in wp_get_attachment_image() directly (/wp-includes/media.php), which makes it work with gallries, attachment pages, etc.
* also uses wptexturize() in get_image_tag() (/wp-includes/media.php), for consistency.
* uses wptexturize() in wp_get_attachment_link() (/wp-includespost-template.php), for consistency",stephdau
Future Releases,41332,Introduce dedicated capabilities for managing attachments,,Media,,normal,normal,Future Release,enhancement,new,dev-feedback,2017-07-14T19:01:53Z,2017-08-19T12:15:49Z,"The capabilities for attachments currently use the regular post capabilities, so it is impossible to grant users specific attachment capabilities without giving them the same post capabilities. While this is fine for WordPress itself, it can be a pain for custom setups which need specific users to have access to their attachments without them being able to write a post.
It is rather easy to change that by setting the `capability_type` argument for the `attachment` post type to `attachment` instead of `post`. To make this change compatible we could do two things:
* For new setups, we could simply add the necessary capabilities to the respective roles. Note that this won't work retroactively as it would require a heavy migration none of us wants to invest their time for. :)
* For existing setups, the necessary capabilities could be granted to users through a default filter for `'user_has_cap'`, so that it would basically map back to posts. Custom setups could remove that filter to invent their own handling of the attachment capabilities.
It might be a bit of a tough idea to have two different ways for this to work, so if we are too wary of doing it, we could of course only do what I described in the second point everywhere.
An alternative to the whole thing would be to not change anything but introduce a filter for the attachment post type's `capability_type` argument. Otherwise the value would need to be hacked on the already-registered post object. This solution would clearly lay the responsibility more on the plugin authors, which might make sense given the benefits do not really matter for core itself.",flixos90
Future Releases,16165,Media Library Bulk Delete: Error in deleting...,nacin,Media,3.1,normal,normal,Future Release,enhancement,assigned,dev-feedback,2011-01-09T14:20:39Z,2015-10-01T04:10:56Z,"While Bulk Deletion, when a user gets the ""Error in deleting..."" message, there is no information given of how many elements have been deleted so far.
Let's say there was a bulk of N deletions, getting this error can mean up to N-1 items have been deleted already.
Same is the case if for some item, no permissions are granted to delete it. The number of successfully deleted items is missing as well.",hakre
Future Releases,24380,Missing Compression Parameter in WP_Image_Editor_GD,wonderboymusic,Media,3.5.1,normal,normal,Future Release,enhancement,reopened,dev-feedback,2013-05-21T02:37:06Z,2016-04-25T16:41:38Z,"Setting the image quality parameter has no effect on png files.
Going through the wp-includes/class-wp-image-editor-gd.php
I noticed that the compression parameter for the imagepng function call is missing.
the current quality parameter only affects jpeg files.
for jpeg, quality goes from 0->100 from bad to good
for png, from 0->9 from good to bad.
in the elseif block starting at line 337 i have added a variable called compression and changed the code as follow:
{{{
elseif ( 'image/png' == $mime_type ) {
// convert from full colors to index colors, like original PNG.
if ( function_exists('imageistruecolor') && ! imageistruecolor( $image ) )
imagetruecolortopalette( $image, false, imagecolorstotal( $image ) );
$compression = -((9/100*$this->quality)-9);
if ( ! $this->make_image( $filename, 'imagepng', array( $image, $filename, $compression ) ) )
return new WP_Error( 'image_save_error', __('Image Editor Save Failed') );
}
}}}
This convert the scale 0->100 into a 0->9 scale that matches the parameters from imaging.
This gives back control to the user on image quality for png files...",MuViMoTV
Future Releases,23205,New Media Uploader slow for sites with many images,,Media,3.5,normal,normal,Future Release,enhancement,new,dev-feedback,2013-01-15T17:17:02Z,2015-09-07T21:48:16Z,"The new media uploader added in 3.5 looks very nice. Unfortunately, its functionality is worse for sites with thousands of images. I think this can be combated by allowing us to select the ""Upload Files"" page as our default after clicking ""Add Media,"" and rather than ""All Media Items"" be the page it jumps to after the image is uploaded, instead have it jump to ""Uploaded to this Post."" Is there any way the WordPress team can make this default? Or add the option to make it default? It's made posting on my site 10 times more annoying, especially for those posts with 40-50 images. And I'm sure there are others who feel the same.",salromano
Future Releases,31419,Vimeo and YouTube video cannot be inserted into a playlist,,Media,,normal,normal,Future Release,enhancement,new,dev-feedback,2015-02-23T09:22:58Z,2015-12-12T23:01:50Z,"Now that the video playlist feature is working well in core, it could be great to think about supporting Vimeo and YouTube videos inside playlist.
For the record, YouTube videos can be played with the MediaElementJS player with this shortcode :
{{{
[video src=""http://youtu.be/_YbVJoMYwJ0""]
}}}
I would like to introduce the possibility to play this video inside a playlist:
{{{
[playlist type=""video"" srcs=""http://youtu.be/_YbVJoMYwJ0,http://youtu.be/Fn1iMmSvvhQ""]
}}}
Now, there are some challenges :
1. Playlist are managed by selecting attachment form the Media library, along with their meta data (title, poster, ...). How to provide meta data for external videos ?
2. MediaElementJS does not build the player in the same way when a YouTube video is embeded, so switching between videos does not rely on the same API, and switching between YouTube and mp4 videos is not possible
The first concern could be addressed by registering an attachment post in the database that links to a YouTube URL instead of a video located in the uploads folder.",Fab1en
Future Releases,23424,WP_Image class for handling images from the media library,,Media,3.5,normal,normal,Future Release,enhancement,new,dev-feedback,2013-02-08T15:41:24Z,2016-08-26T19:24:53Z,"Since 3.5 we have the class WP_Image_Editor. This needs a file path to be able to manipulate an image. Currently you would have to use something like wp_get_image_editor( _load_image_to_edit_path( $post_id ) ). What is wrong since you are using a ""private"" function.
Currently I'm working on this idea and you can find the code here https://github.com/markoheijnen/WP_Image/blob/master/wp-image.php. What it does now is getting the filepath, be able to get the image editor, add an image size on the fly and getting/updating the metadata.
We really miss something like a WP_Image class in WordPress. However I'm not sure what kind of functionality is needed for it. I like the current class mainly because it gives you the power to create an image size for a specific media image and stores it in the sizes array. When a user removes the media image then also the custom sizes will be removed.",markoheijnen
Future Releases,10390,attachments should store the WP uploads path that was configured when they were uploaded,,Media,2.8.1,normal,normal,Future Release,enhancement,reopened,dev-feedback,2009-07-12T10:34:51Z,2015-12-03T06:34:11Z,"When you upload an image, currently, the uploads path (defaults to wp-content/uploads) is not stored.
If you change this later on to something else, previously inserted galleries no longer work, among multitudes of other problems.",Denis-de-Bernardy
Future Releases,15311,dynamic image resize (on the fly) using already available functions,,Media,3.1,normal,normal,Future Release,enhancement,new,dev-feedback,2010-11-03T20:18:44Z,2018-01-25T20:03:49Z,"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;
}
}}}
",vteixeira
Future Releases,11895,Allow more specific image size editing,,Media,,normal,normal,Future Release,feature request,new,dev-feedback,2010-01-14T15:12:28Z,2016-10-09T18:35:32Z,"Instead of allowing only some combinations of 'thumbnail', 'medium', 'large', 'full' I would like to have the ability to select which of these I would like to crop. So for example, only 'thumbnail' and 'medium'. With the current trunk this is not possible. I created a patch that adds this ability by changing the radio boxes of ""apply changes to"" in the image-edit page to checkboxes for each of the 4 possible sizes.",frankgroeneveld
Future Releases,12945,Constrain wp_page_menu(),technosailor*,Menus,,normal,normal,Future Release,defect (bug),accepted,dev-feedback,2010-04-09T19:39:51Z,2015-09-01T23:54:14Z,"The wp_page_menu() function is the default callback for wp_nav_menu(). IOW, when a user is not using the new menu system, it defaults to this function. While that is good, any number of pages over, say 10, will make a theme puke in many cases.
As a workaround, I suggest we make a default of wp_page_menu() to exclude all pages() except home. It's a stupid idea, I think, but something needs to be done to make this manageable so I'm looking for feedback.
The Pro of taking this approach is that it encourages customization of menus via the WP menu system. It also does not lock theme devs into a particular approach because this stuff can be overidden via arguments and filters.
The con is that the default callback becomes pretty benign and useless. Almost pointless.
Ideas?",technosailor
Future Releases,24146,Menu items with blank labels are removed on saving,SergeyBiryukov*,Menus,3.5.1,normal,normal,Future Release,defect (bug),accepted,dev-feedback,2013-04-20T22:10:09Z,2017-05-15T12:18:54Z,"Hello,
When edit an item of menu leaving the label in blank, the item is auto deleted.
There are two problems in that:
1. I could need an item with blank title to add some class with an background image
2. When this item has subitems with two or more depth, all subitems are moved to first depth loosing submenus hierarchy. Moreover if i try to drag the subitems to make the hierarchy again, after save, all subitems come back to first depth. While i not change the depth of first item this issue occurs again.
Best regards",rodrigo@…
Future Releases,31703,Trying to get property of non-object in nav-menu.php,,Menus,4.2,normal,major,Future Release,defect (bug),new,dev-feedback,2015-03-20T07:12:15Z,2017-08-11T16:24:56Z,"Every time when I refresh my site, I have this PHP error : ""Trying to get property of non-object"" in wp-includes/nav-menu.php in line no:665. If I have something in menu that has no post titles set for that nav object then the code should check that it is set or not. ",mehulkaklotar
Future Releases,19272,Add Filter to Nav Menu Support Themes Text,bhargavbhandari90,Menus,,normal,trivial,Future Release,enhancement,assigned,needs-docs,2011-11-16T22:47:52Z,2017-06-26T18:00:29Z,"Frameworks could use a filter here to customize the message: _n('Your theme supports %s menu. Select which menu you would like to use.', 'Your theme supports %s menus. Select which menu appears in each location.', $num_locations ). For example, it may be the child theme that doesn't support the menus. Also, if none are supported (say via add_theme_support), then when it's zero, it says: ""Your theme supports 0 menus. Select which menu appears in each location."" (which doesn't make much sense). So adding a filter can enable theme developers to further customize.
An example use case:
add_filter( 'nav_menu_theme_support_text' , 'wps_nav_menu_theme_support_text' );
function wps_nav_menu_theme_support_text ( $num_locations ) {
if ( $num_locations == 0 )
$text = 'Your child theme does not support custom menus.';
else
$text = _n('Your theme supports %s menu. Select which menu you would like to use.', 'Your theme supports %s menus. Select which menu appears in each location.', $num_locations );
return $text;
}",wpsmith
Future Releases,13273,"Allow ""'non-clickable"" menu items",,Menus,3.0,normal,normal,Future Release,enhancement,new,dev-feedback,2010-05-06T10:58:50Z,2015-12-03T06:52:51Z,"In the new menu generator I'm missing the option to create ""non-clickable"" menu items.
What I'm after is that I want to create for example a main menu item with the title ""Links"" which is non-clickable (no url attached to it) and basically only acts as an umbrella item for the actual links I want to locate as subitems of the item ""Links"".
- Home
- Something else
- Links (this one should be non-clickable)
- external link 1
- external link 2
- etc
I think that an optional tickbox in the add link section will do the trick. Basically, all it has to do is to ""disable"" the check whether or not a valid URL format has been submitted and, of course, it has to trigger some modified html output.
Hope you guys can add this in the 3.0 release because this would basically complete the menu generator :)
Keep up the good work and I'm really looking forward to the 3.0 release!",stgoos
Future Releases,29213,Introduce capability for access to nav-menus.php,johnbillion,Menus,3.0,normal,normal,Future Release,enhancement,assigned,needs-unit-tests,2014-08-14T16:22:16Z,2017-07-14T19:41:15Z,"Management of the nav menus currently requires `edit_theme_options` capability, a capability associated with administrators which grants the power to make many wide sweeping changes. There should be a discrete capability `edit_nav_menus` just for managing menus, one that is inherited for anyone who has `edit_theme_options` by default. This was done for Customizer access in #28605 with the introduction of a `customize` capability.
Originally brought up in #14386.
For introducing a `manage_widgets` capability, see #31020.",westonruter
Future Releases,14969,"menu element ""all (direct) child pages""",,Menus,3.0.1,normal,normal,Future Release,feature request,new,dev-feedback,2010-09-26T20:16:39Z,2015-12-03T19:45:22Z,"One of the things I am missing in the current menu-system is the ability to assign parts of the page tree to, say, a sub-menu, so, say, all child pages of a parent will be listed instead of having to add them manually to the submenu once the menu has been created.",youngmicroserf
Future Releases,40736,Ensure that `get_blog_count()` and `get_user_count()` return an integer,,Networks and Sites,,normal,normal,Future Release,defect (bug),new,dev-feedback,2017-05-11T18:59:30Z,2017-08-14T18:26:09Z,"The documentation for the functions `get_blog_count()` and `get_user_count()` states that the return type is an integer, however the functions only call `get_network_option()` without any typecast.
The functions should be adjusted to actually reflect their documentation. While this might theoretically be problematic in terms of backward-compatibility, in #40724 some initial thoughts of this being a viable change were expressed, so let's think about it on this ticket.",flixos90
Future Releases,17397,Inconsistency in allowed site addresses,,Networks and Sites,3.0,normal,normal,Future Release,defect (bug),reopened,dev-feedback,2011-05-12T14:40:09Z,2016-08-02T16:46:40Z,"The rules for allowed characters in a site address differ between when you add a new site and when you edit an existing site.
Steps to reproduce:
1. Go to Network Admin -> Sites -> Add New
2. Enter `foo.bar` as the site address and hit save. The address will be rejected as containing invalid characters.
3. Edit an existing site instead, and enter `foo.bar.yourdomain.com` as the domain. The address will be accepted just fine.
Having written that out, maybe this isn't a valid bug because when adding a site you're entering the site address, but when you're editing a site you're editing the complete domain name. Hmm. I'll open it anyway and see what people think.
My core issue is that I'd like to be able to add sites that use fourth-level subdomains (eg `foo.bar.baz.com` when the main site is at `baz.com`). Currently I have to enter a different site address then go in and edit it to the desired domain.",johnbillion
Future Releases,15801,Network Admin: Deactivated / Deleted inconsistency,,Networks and Sites,3.1,normal,normal,Future Release,defect (bug),assigned,dev-feedback,2010-12-13T18:12:54Z,2017-08-14T17:18:32Z,"Under the Sites screen, there are distinct inline links for Deactivate and Delete. However, when a site is deactivated, it is referred to as deleted in:
* Sites screen inline status
* Edit Site screen attributes section
* Error page for non-admins visiting the site",kawauso
Future Releases,25293,Switch_to_blog not switching the siteid,,Networks and Sites,3.0,normal,minor,Future Release,defect (bug),new,dev-feedback,2013-09-12T09:11:20Z,2017-06-08T20:17:36Z,"When having multiple network on multisite making the following:
{{{
switch_to_blog(1);
$options = get_site_option( 'my_option' );
restore_current_blog();
}}}
The options retrieved are the options of the current siteid and not the siteid of the switched blog.
One of the options is to make something like this :
{{{
global $wpdb;
// Get the previous siteid
$previous_site_id = $wpdb->siteid;
$previous_blog_id = $wpdb->blogid;
// Go to site 1
switch_to_blog(1);
// Set the blog siteid to 1
$wpdb->set_blog_id( 1, 1 );
// Get the options
$options = get_site_option( 'my_option' );
restore_current_blog();
$wpdb->set_blog_id( $previous_blog_id , $previous_site_id );
}}}
Or
{{{
// Get the previous siteid
$site_id = $wpdb->siteid;
// Set the blog siteid to 1
$wpdb->set_blog_id( $wpdb->blogid, 1 );
// Get the options
$options = get_site_option( 'my_options' );
$wpdb->set_blog_id( $wpdb->blogid , $site_id );
}}}
The thing is that the switch_to_blog function does not specify the switched siteid on the method $wpdb->set_blog_id if the network is not the same as the current blog.",Rahe
Future Releases,39158,Unify site deactivation process,,Networks and Sites,,normal,normal,Future Release,defect (bug),new,dev-feedback,2016-12-07T19:20:38Z,2017-08-14T17:16:24Z,"Currently there are three cases of ""deleting"" a site on a multisite setup:
* deleting a site entirely (for example via Sites list table's ""Delete"" link)
* deactivating a site from the network admin (for example via Sites list table's ""Deactivate"" link)
* deactivating a site from the site admin (admin can click ""Delete Site"" in Tools menu)
Note that deactivating a site does not wipe out the site, but rather sets the ""Deleted"" flag for that site (strange legacy naming, can be ignored here).
What this ticket should solve is that the latter two processes work differently although they should be doing the same thing: While deactivating a site from the network admin simply sets the site to ""Deleted"", deactivating the current site from the site admin also removes all users from the site (via `wpmu_delete_blog()`). That means if an admin deactivates their site and later asks support (i.e. the network administrator) to restore it, all users will be gone.
I'm not sure why this happens, but I certainly don't think the two actions should have a different behavior. My proposal is to move the part of that function where users are removed into the `if ( $drop )` clause to make sure users are only removed when the site is actually being deleted.",flixos90
Future Releases,13743,Ability to choose a network default theme,,Networks and Sites,3.0,normal,normal,Future Release,enhancement,reopened,dev-feedback,2010-06-06T05:44:12Z,2018-03-28T09:11:24Z,"As stated in summary. I use WP 3.0 RC and I've found out that there is no way to set up a theme which should be used by default for newly created sites in network. Even then I disable all the themes except the one I want to be used, WP still set thentyten as theme for newly registered site. The only solution I was able to find is to change theme description and name to twentyten and delete all other themes. It's so simple to let administrator choose default network theme, and this option is present in many other CMS.",fuwaneko
Future Releases,38630,Discourage usage of legacy properties in WP_Site,,Networks and Sites,4.5,low,normal,Future Release,enhancement,new,dev-feedback,2016-11-02T21:21:20Z,2017-05-08T17:29:24Z,"Working on #38597, it was figured out that the best solution for handling problems with IDE handling of `WP_Network`s magic ID property is to rename the actual properties to reflect our current naming conventions. This enhancement will encourage to use the new conventions while still supporting the old ones for legacy code.
Let's do the same for `WP_Site`:
* `$blog_id` (string) is replaced with `$id` (int)
* `$site_id` (string) is replaced with `$network_id` (int)
* both legacy names will continue to work through magic methods",flixos90
Future Releases,16853,Error 500 when a user has too many sites,,Networks and Sites,3.0.1,normal,minor,Future Release,enhancement,assigned,dev-feedback,2011-03-14T11:15:57Z,2018-05-24T03:57:36Z,"'''My installation'''
[[BR]]
3.0.1 multi-site installation with more than 7500 blogs, with one user each. I also have one moderation user that can administer each of the blogs.
[[BR]]
[[BR]]
'''The issue'''
[[BR]]
In the admin interface, when I go to Super-Admin -> Users, and when I display the page that contains my moderation user, I get ""''An error (500 Internal Server Error) has occured in response to this request''"". The page tries to display all the sites administered by him (around 7500 of them), hence the error.
[[BR]]
[[BR]]
Updating to 3.1 didn't resolve the problem.
[[BR]]
[[BR]]
'''Recommended enhancement'''
[[BR]]
For each user in the list, display only a certain number of sites, with a possibility to see all of that user's sites, if needed.",luuzan@…
Future Releases,14172,Implement $scheme in site info in ms-sites edit site,,Networks and Sites,3.0,normal,normal,Future Release,enhancement,assigned,dev-feedback,2010-07-01T22:45:33Z,2016-12-20T17:42:50Z,"In WordPress 3.0 with Network enabled, if you were to click:
Super Admin -> Sites -> Edit (next to any site) and then change any of the Site Options i.e. wp_2_options the changes don't save.
We're running a secure environment and need Siteurl to be HTTPS instead of HTTP. Changing all the parameters to https and clicking Update doesn't save the changes.",firmdot
Future Releases,39156,Introduce singular capabilities for managing individual sites on a network,,Networks and Sites,3.0,normal,normal,Future Release,enhancement,new,dev-feedback,2016-12-07T18:50:16Z,2017-07-14T19:41:15Z,"As we did in #35614 for taxonomy terms, singular capabilities should be introduced for editing and deleting individual sites on a network.
This would allow fine-grained cap checks such as `current_user_can( 'edit_site', $site_id )`.
Bear in mind there's a potential clash here with the existing `delete_site` capability which is intended as a cap check for site admins to delete their own site. Needs some thought.",johnbillion
Future Releases,33967,"MS Sites: content of the users column should be by choice, number is not too informative",,Networks and Sites,4.3,normal,normal,Future Release,enhancement,assigned,dev-feedback,2015-09-22T13:43:11Z,2016-10-06T20:49:09Z,"I sadly noticed, that on network admin -> sites, the users column only shows numbers now.
It looks nicer with the less data, but on the other hand we used that information.
I ask, it is possible to make it choosable, or at least, list the users in the excerpt listing mode?
Why I ask this:
We have a multisite install with many blogs and open registration. Because of that we sometimes have spam blogs.
We frequently delete those spam blogs with its user(s), but now it's more complicated, because we don't see the email (user) at first. We have to open it on a new window (by clicking on the number of users).
That slows down the process.
And in some cases, just from the registered user (email) we saw if it was a spam blog or not.",katazina
Future Releases,27224,Multisite upload settings are inconsistent,jeremyfelt*,Networks and Sites,,normal,normal,Future Release,enhancement,accepted,dev-feedback,2014-02-27T19:22:04Z,2015-12-03T19:37:34Z,"""Site upload space"" is indicated in MB whilst ""Max upload file size"" is indicated in KB.
It would be useful to standardize on MB.",danielbachhuber
Future Releases,34293,Network Admin Email description doesn't really explain what it is.,,Networks and Sites,,normal,normal,Future Release,enhancement,new,dev-feedback,2015-10-13T21:18:49Z,2016-12-08T00:01:34Z,"On /wp-admin/network/settings.php the field for **Network Admin Email** has this as the description:
> This email address will receive notifications. Registration and support emails will also come from this address.
By contrast, the per-site has this:
> This address is used for admin purposes, like new user notification.
I propose we change the Network Admin one to this:
> This address is used for admin purposes, like site notifications. Registration and support emails will be sent from this address.
That makes for a little more parity, and explains more clearly that emails are sent FROM this address (which has been unclear to some).
The attached patch comes in two versions.
1) As I originally proposed
2) Without the 'and support' phrase since I have no idea what we are referring to with that one.",Ipstenu
Future Releases,30233,Replace or rewrite domain_exists() for more accurate usage,,Networks and Sites,3.0,normal,normal,Future Release,enhancement,new,dev-feedback,2014-11-02T01:47:25Z,2016-08-02T16:39:16Z,"`domain_exists()` was added in [https://mu.trac.wordpress.org/changeset/543 MU:543] in almost its current form. The enforcement of trailing slashes on paths was added in #20589 and a filter was added in #21442.
A few notes:
* The lookup for a domain and path combination is restricted to one network. This allows the same domain and path combination to be used on multiple networks, which should not be default behavior.
* The name, `domain_exists()`, implies a check for domain. It is really checking for a full site URL.
* While it is entirely possible to ignore the result by providing your own in the filter, it would be nice to not always require this for multi-network configurations.
My **guess** is that the original intent was to ensure a subdomain or path was not present when creating a site on an open network.
In thinking of how to address this, these two possibilities came to mind.
* Deprecate `domain_exists()` and wrap a new function that does a larger check. `wp_get_site()` could work alongside `wp_get_sites()` and support domain/path lookup.
* Allow the current `$site_id` argument to be `null` (for all), or an array (for many), in addition to the current `int` expectation.
",jeremyfelt
Future Releases,15691,Network admin should have its own settings API,,Networks and Sites,3.0,normal,normal,Future Release,feature request,new,needs-unit-tests,2010-12-05T19:31:17Z,2017-09-07T10:27:33Z,"preferably using options.php and the same API as normal admin, this way making a plugin multisite compatible (ie. adding a Network admin screen to it) would be much easier.",joostdevalk
Future Releases,21432,Deprecate *_blog_option(),,"Options, Meta APIs",3.4.1,normal,normal,Future Release,defect (bug),assigned,dev-feedback,2012-07-31T21:53:06Z,2017-06-26T17:58:41Z,"Deprecate get_blog_option(), add_blog_option(), update_blog_option(), and delete_blog_option(). The regular *_option() functions wrapped with switch_to_blog() and restore_current_blog() should be used instead.
Previous discussion:
http://core.trac.wordpress.org/ticket/21270#comment:11",ryan
Future Releases,22192,update_metadata() and update_option() strict checks can cause false negatives,,"Options, Meta APIs",,normal,normal,Future Release,defect (bug),new,dev-feedback,2012-10-15T03:19:23Z,2016-09-14T16:03:36Z,"Given this:
{{{
add_post_meta( $post_id, 'key', 1 );
update_post_meta( $post_id, 'key', 1 );
}}}
The update should not work, because they are the same. However, the meta cache will have ""1"" as a string, and then it will strict compare it to 1 as an integer. Thus, an unnecessary update will run.
Best I can tell, this could also affect update_option().
It is quite common to use integers and booleans directly into these functions. They should be smart enough to recognize that ""1"" == 1 == true and ""0"" == 0 == false, and that any numeric string is also equal to a properly cast integer.
Unit tests needed.
Ticket from which this was spun: #22189, saving navigation menus is slow.",nacin
Future Releases,21989,update_option() calls sanitize_option() twice when option does not exist,,"Options, Meta APIs",,normal,normal,Future Release,defect (bug),new,dev-feedback,2012-09-25T05:04:34Z,2018-02-15T06:44:23Z,"
I just spent several hours tracking down an issue when using the Settings API where `sanitize_option()` is called twice which is unnecessary execution especially if sanitization includes calling an external API for username/password authorization ''(this was how another developer set it up for a plugin I was debugging.)''
What happens is that a call to `update_option()` will call `sanitize_option()` and then if the option wasn't previously in the options table `update_option()` will delegate to `add_option()` which calls `santize_option()` a second time. This would normally be easy to workaround by first calling `get_option()` and testing for `false` and calling `add_option()` instead of `update_option()` if `false`, but not when the Settings API chooses how to call it.
I've looked at the problem and can envision several different ways to solve it such but don't know which the core developers would choose ''(or if they'd choose yet another option I haven't envisioned)'' so I didn't submit a patch:
- Adding a 3rd parameter `$mode` to `sanitize_option()` that identifies the mode ''('add', 'edit', default = 'unknown')'' and thus allow the hook to ignore one of the options ''(this would be more backward compatible but would put the onus on the developer to know to do this)'',
- Adding a 5th parameter `$bypass_sanitize` to `add_option()` defaulted to `false` that is only passed as `true` in `update_option()` allowing `update_option()` to disable the call to `sanitize_option()` found in `add_option()` ''(this would be less backward compatible and hacky, but seemless to the developer)''
- Adding a 3rd parameter `$bypass_sanitize` to `update_option()` defaulted to `false` that is only passed as `true` from `/wp-admin/options.php` allowing `update_option()` to bypass the call to `sanitize_option()` if an `add_option()` will happen ''(this would be less backward compatible and hacky, but seemless to the developer)''
- Have `/wp-admin/options.php` test for no pre-existing option and then call `add_option()` or `update_option()`, respectively ''(this would be seemless to the developer but less backward compatible and not hacky, and it wouldn't handle the general case.)''
So is this worth fixing to save other users and developers debugging time, and to reduce the chance of subtle errors in new code? If yes, how best to approach?",MikeSchinkel
Future Releases,24266,update_post_meta doesn't change post modified date,,"Options, Meta APIs",3.5.1,normal,normal,Future Release,defect (bug),new,close,2013-05-05T05:10:14Z,2017-02-12T23:49:47Z,"In building an application I wanted to query for posts that were modified since a specific date/time.
The only issue is the majority of our changes are to post meta and not to post content, this means these changes don't show up in the query.
To solve this I'm tying into the action, but I feel like this is something that should be done by default.",DennisSmolek
Future Releases,36655,Enhancement: Add datetime column to options table.,,"Options, Meta APIs",,normal,normal,Future Release,enhancement,new,needs-unit-tests,2016-04-24T15:04:51Z,2016-06-10T17:48:03Z,"== Proposal ==
The options table in WordPress is a great key/value storage option for a wide variety of different data used by core and plugins. One improvement that would increase its utility for faster time based queries on data stored there is to add a DATETIME column.
== Some examples where this benefit could be realized: ==
=== Example 1: Transient storage. ===
Currently, when there is no object-cache in use, transients are stored to the wp_options table. However, for each transient there are two records. One for the actual key/value pair and then one for any timestamp set as the transient expiry. Having a datetime column would allow the transient to always only consist of one record and thus make any queries interacting with transients much simpler.
=== Example 2: Arbitrary plugin data using the options table for its own scheduled tasks. ===
A lot of plugins are using the transient system wrong because it's not intended for indicating minimum age. Having a datetime column would provide the database schema in WordPress core that allows for plugins to implement their own ""minimum/maximum age"" apis.
=== Example 3: Tracking creation/modification times. ===
Having a datetime column would allow for indicating when a key/value pair was created and/or modified which could be useful for plugins that have need to do so.
=== Example 4: Scheduled settings/options. ===
Having a datetime column could allow for scheduled changes with a sites configuration and thus more advanced previews/site preparation, (think adding scheduled changes to site title, or site description via the customizer). Having a datetime column makes such schedules simpler to implement.
== Implementation ==
=== Schema ===
{{{
option_date datetime NOT NULL default '0000-00-00 00:00:00'
}}}
=== Iterations: ===
1. Add the column and modify options api to expose the new column to queries (get_option, update_option, site option functions etc).
2. Convert transient API to implement new option_date column for setting expiries when object-cache is not in use.
== Who and When ==
I'd be willing to spearhead putting some patches together and getting the initial code going but before I invest some time in this I'm just testing the waters to see if this is even something that would be considered/welcomed for core. I'm not aware of any potential conflicts this may pose with the purpose for the option table but if there are any I'm sure I'll find out!
I definitely don't see this as going in 4.6 but it might have potential for 4.7 if work begins fairly soon.
",nerrad
Future Releases,44042,Hook for ‘delete_option’ behaviour required,,"Options, Meta APIs",1.2,normal,normal,Future Release,enhancement,new,dev-feedback,2018-05-11T07:45:45Z,2018-05-17T15:16:31Z,"Hi, I posted this about one month ago in the wordpress support forum: [https://wordpress.org/support/topic/hook-for-delete_option-behaviour-required/]
I did not receive any answers there but referred to this forum, so I post it here again:\\
Hi, I would need to prevent and change the deletion of certain options by the WP core function ‘delete_option’.
There is a hook
{{{
do_action( 'delete_option', $option );
}}}
available here: [https://core.trac.wordpress.org/browser/tags/4.9.4/src/wp-includes/option.php#L532]\\
But this does neither provide a way to exit the delete_option function before the option is deleted nor to change the option name to be deleted. In fact this existing hook seems to be pretty useless.
Therefore I would need a filter in the first line of the delete_option core function like
{{{
$option = apply_filters( 'delete_option_name', $option );
}}}
.
Or change the line 535 from
{{{
$option = trim( $option );
}}}
to
{{{
$option = trim( apply_filters( 'delete_option_name', $option ));
}}}
Any chances to get this into core immediately?\\
Thx, Robert
",RobertoDonPedro
Future Releases,14125,Seperate out non-editable options in edit site,sorich87*,"Options, Meta APIs",,normal,normal,Future Release,enhancement,accepted,dev-feedback,2010-06-28T04:11:36Z,2015-10-01T02:28:51Z,"In the edit site screen, blog options which are arrays are shown as SERIALIZED and the textbox is disabled. The attached patch pulls those options out of the options metabox and displays the option name in another metabox below.
Related: #14120",wpmuguru
Future Releases,10786,Implementation of %my_taxonomy% in permastructs is incomplete,,Permalinks,2.9,normal,minor,Future Release,defect (bug),assigned,dev-feedback,2009-09-15T03:30:56Z,2015-12-03T19:58:11Z,"The `register_taxonomy()` function includes a call to `add_rewrite_tag()` which should allow for a site's permastruct to include a %my_taxonomy% tag just like you can include a %category% tag or a %tag% tag, however this implementation is incomplete and doesn't work.
Example:
`register_taxonomy('genre','post');`
should allow you to create a permastruct (from the Settings->Permalinks screen) which includes %genre% in it.
The problem is that `get_permalink()` doesn't check for custom taxonomies and the replacement of %genre% with your post's genre in the permalink doesn't happen.
Patch upcoming.",johnbillion
Future Releases,32705,`includes_url` shouldn't use `site_url()` on the frontend,,Permalinks,,normal,normal,Future Release,defect (bug),new,dev-feedback,2015-06-18T15:18:09Z,2015-07-06T17:02:31Z,"Multisite / Domain Mapping
1. `site_url()` is your admin, `home_url()` is your frontend
1. The site url is blocked behind a firewall
1. You call `includes_url()` for a script on the frontend: your script is blocked, because it loads your admin domain on the frontend
I noticed this because we are trying to upgrade the NYT to 4.2.* and emoji scripts are showing up everywhere.
I can remove the action for now.",wonderboymusic
Future Releases,17183,previous_comments_link and next_comments_link return wrong url with PATHINFO permalinks,,Permalinks,1.5,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2011-04-19T20:13:15Z,2015-10-03T22:38:36Z,"When using PATHINFO permalinks, previous_comments_link() and next_comments_link() return a wrong link, which renders paged comments useless.
Steps to reproduce:
Set permalinks to: /index.php/%post_id%/%postname%/
The functions return URLs similar to: /comments-page-1/#comments
This URL results in a file not found (if no rewrite rules are available, which should not be necessary if the PATHINFO permalink structure is used).
Expected URL: /index.php/comments-page-1/#comments
Manual opening the URL results in the expected/correct paged comments page.",FireMotion
Future Releases,6778,Detect when the config will cause infinite loop,,Permalinks,2.5,normal,normal,Future Release,enhancement,reopened,dev-feedback,2008-04-19T13:46:14Z,2015-12-03T19:47:31Z,"Behavior:
If you put in http://www.domain.com in the ""Wordpress Address"" setting, then Wordpress will automatically do a redirect from http://domain.com to http://www.domain.com. Many hosting packages allow the user to deal with www and non-www versions of their domain. This will cause an infinite redirect loop if, for example, the ""Wordpress Address"" is set to http://www.domain.com and the hosting setting is set remove the www from the domain address-- to redirect http://www.domain.com to http://domain.com.
Expected behavior:
When setting the ""Wordpress Address"" setting, it should detect if the canocical code will cause an infinite redirect loop and warn/correct the mistake",Analogpoint
Future Releases,9825,"Enforce permalink history, outright",,Permalinks,2.8,normal,normal,Future Release,enhancement,assigned,needs-unit-tests,2009-05-15T01:06:37Z,2015-12-03T20:01:29Z,"currently, we enforce old slugs and www pref (not even sure that works, since I ended up fixing it in a plugin). canonical doesn't work for pages, or hardly.
we should enforce permalink history, outright. store it in a a db field, and query against it to optimize url2post().",Denis-de-Bernardy
Future Releases,15936,IPv6 literal support in multisite broken,,Permalinks,3.0,normal,major,Future Release,enhancement,new,dev-feedback,2010-12-21T16:00:25Z,2018-03-20T17:54:32Z,"The logic for handling explicit port numbers in wp-includes/ms-settings.php is confused by IPv6 literal addresses in URLs as defined by RFC 2732.
It tries to handle the URL as it as if there were a port appended, but then fails to strip it off. Incidentally the error message here: 'Multisite only works without the port number in the URL.' is untrue, since ports are handled (but for only two particular cases, port 80 and 443).
The attached patch, against Wordpress 3.0.3, fixes both these issues, and allows ports other than 80 and 443 to be used with Wordpress, by just stripping off the trailing port rather than special-casing the two well-known ports, and not incorrectly detecting IPv6 literals as URLs with ports in. It also has the advantage of being much more compact.
It may be worth someone thinking through whether the substitution is strictly correct with reference to the URL standards, but I'm pretty sure that this is an improvement on the current code.
Thanks,
Dominic.",jmdh
Future Releases,10425,Improvements to IIS7 Rewriting Code,,Permalinks,2.8.1,low,normal,Future Release,enhancement,assigned,dev-feedback,2009-07-16T14:12:09Z,2015-12-03T19:58:33Z,"#8974 introduced a set of functions and changes which allow to automatically generate Rewrite Rules for Wordpress installs running on IIS7.
There are some issues with that implementation that I think are worth being written down and discussed somewhere so here we go:
1) There's no '''""Verbose"" option''' for IIS rules; while I can't say when it would make sense to have a verbose listing of all WordPress rewrite rules in `.htaccess`/`web.config` it might be something that should be available for both systems?
2) IIS does not add '''non wordpress rules''' (`$non_wp_rules`) to the `web.config` file (`iis7_url_rewrite_rules()`) which means that any custom rewriting which plugins/users can do on apache don't work on IIS.
3) At the moment it's assumed that there is only ONE single rule needed for IIS. Especially when looking at the merge with WPMU this is going to become a problem because WPMU uses '''multiple rules'''. Every rule has to have a unique name and functions like `iis7_rewrite_rule_exists()` and `iis7_delete_rewrite_rule()` only look for one rule with name ""wordpress"". Custom Rules (see 2) also won't work without a change here. For a partial fix see misc.php in [http://trac.mu.wordpress.org/attachment/ticket/991/991-webconfig.patch Patch on MU #991])
Any comments?",bforchhammer
Future Releases,36765,Remove Legacy Code from pingback_ping,,Pings/Trackbacks,4.1,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2016-05-05T14:59:53Z,2016-07-18T20:32:48Z,"Proposing we remove the legacy conditional url_to_postid and //$way debugging line leftover from [30139].
{{{
/ let's find which post is linked to
// FIXME: does url_to_postid() cover all these cases already?
// if so, then let's use it and drop the old code.
}}}
Related: #34419
",dshanske
Future Releases,29539,Plugin viewer not displaying video tutorials.,,Plugins,4.0,normal,normal,Future Release,defect (bug),new,dev-feedback,2014-09-05T16:19:32Z,2017-05-05T20:25:17Z,"In the WordPress 4.0 plugin page viewer, my video tutorials for my plugins are not displaying.
[[Image(http://www.redeemerdanceacademy.ca/wp-content/uploads/2014/09/Ticket.png)]]",kidsguide
Future Releases,33330,Undefined property: stdClass::$slug,,Plugins,4.0,normal,normal,Future Release,defect (bug),reopened,dev-feedback,2015-08-10T20:51:18Z,2017-05-17T19:50:11Z,"When logged in and going to the Add Plugins page: /wp-admin/plugin-install.php, i get two identical php notices:
[10-Aug-2015 20:44:59 UTC] PHP Notice: Undefined property: stdClass::$slug in /wp-admin/includes/class-wp-plugin-install-list-table.php on line 38
I can reproduce with all plugins enabled and disabled, so I'm posting here as a potential issue with 4.2.4? ",mattfiocca
Future Releases,39338,class-wp-hook.php - apply_filters() infinite loop,,Plugins,4.7,normal,normal,Future Release,defect (bug),new,dev-feedback,2016-12-20T08:16:25Z,2018-04-09T07:40:42Z,"I just saw nearly 60 million error log entries (17 GB) due to this bug.
In line 303 of class-wp-hook.php, there is a piece of code that will cause an infinite loop:
{{{#!php
} while ( false !== next( $this->iterations[ $nesting_level ] ) );
}}}
The problem is that
{{{#!php
$this->iterations[ $nesting_level ]
}}}
can be null.
Suggested fix:
{{{#!php
} while ( ! is_null( $this->iterations[ $nesting_level ] ) && false !== next( $this->iterations[ $nesting_level ] ) );
}}}
I also urge developers to look for similar ""false !== next()"" constructs in code, as they '''will''' lead to infinite loops.",frettled
Future Releases,27188,deactivated_plugin behaves improperly,,Plugins,2.9,normal,normal,Future Release,defect (bug),new,dev-feedback,2014-02-23T05:36:00Z,2015-12-03T19:35:55Z,"Currently, if someone were to hook into `deactivated_plugin`, one should expect that the `$plugin` actually be deactivated.
So if, for example, I hook into it with the following code, deactivating Addthis, I don't get the expected behavior.
{{{
add_action( 'deactivated_plugin', 'dtat_deactivate_self', 10, 2 );
/**
* Deactivate ourself if Premise is deactivated.
*/
function dtat_deactivate_self( $plugin, $network_deactivating ) {
if ( 'addthis/addthis_social_widget.php' == $plugin ) {
die( 'Addthis: ' . print_r( is_plugin_active( $plugin ), 1 ) );
}
}
}}}
The plugin still shows that it is active. So if I hook in here to check if plugin has been deactivated, then it fails. Instead, the `deactivated_plugin` hook should appear after the `update_option` call, which is where the plugin is actually deactivated.
OR, the docs are wrong and should be updated.
Attached is a sample addthis plugin extension that deactivates after Addthis is deactivated by being forced to use `update_option_active_plugins` and `update_option_active_sitewide_plugins`.
See [https://gist.github.com/wpsmith/26c2e07370ee8b4c3e3f Github Gist sample plugin] for [http://wordpress.org/plugins/addthis/ Addthis].",wpsmith
Future Releases,28226,menu_page_url does not return correct URL on network admin,,Plugins,3.0,normal,normal,Future Release,defect (bug),new,dev-feedback,2014-05-12T18:54:57Z,2015-03-30T11:22:54Z,the `menu_page_url` function calls `admin_url` to build the URL returned. it should check for network admin first and use `network_admin_url` if present,norcross
Future Releases,38183,Add hooks to be run before and after each callback,,Plugins,,normal,normal,Future Release,enhancement,new,needs-unit-tests,2016-09-28T23:41:23Z,2017-08-25T21:15:07Z,"Since before the dawn of time, debugging tools have relied on the `all` hook to collect information about how long hooks take to run, and which callbacks are registered to that hook.
This has a few drawbacks. Primarily, it's not possible to collect timing information about individual callbacks, and it's quite difficult to manage recursive hook behaviour.
With that in mind, hooks that run before and after each callback would be quite valuable, but they do need to be considered carefully.
* What kind of performance impact would they have? If there are no callbacks registered to these hooks, there should ideally be no performance impact.
* Should they be `WP_DEBUG` only? This would discourage plugins from abusing them on production systems - they would only be used if the site admin explicitly sets the site to debugging mode.
* Dealing with recursion is fun, should they provide any helpers for indicating recursion level, or is it up to the code hooking into them to handle that?",pento
Future Releases,31136,Allow plugin authors to register an additional 'Uninstall Notification' plugin header and to display back to the user during plugin uninstall flow,,Plugins,,normal,normal,Future Release,enhancement,new,needs-unit-tests,2015-01-26T06:14:19Z,2017-02-05T09:58:14Z,"In wp-admin/plugins.php wordpress displays to the user information about the plugins you are attempting to uninstall. Currently it only displays the name of the plugin name ($plugin[ 'Name' ]) and the plugin author ($plugin[ 'AuthorName' ]). In V4.1 this output is generated around lines 289-304.
Is it possible to add another field that contains a short piece of information from the plugin author, that can be presented to the user for each plugin? The plugin would need to register this information with wordpress when it was installed or updated.
Specifically, I envisage this being used for details that the user might need to follow to preserve any data that they might have before they actually delete the plugin.
An example string that I can see being used by a plugin:
If you wish to uninstall without losing your data, see the details at http://example.com/plugin-uninstall.
Notes:
- Such a string should of course be optional to preserve backward compatibility.
- Appropriate filtering and length checks should be done on the string to ensure that the uninstall plugin UI isn't easily broken or disturbed. This avoids the plugin author filling the field with a string that stops the user from being unable to uninstall the plugin.",cefiar
Future Releases,12718,Better structure for admin menu,,Plugins,,normal,normal,Future Release,enhancement,reopened,dev-feedback,2010-03-26T01:05:37Z,2018-02-07T09:17:16Z,"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
Future Releases,39441,Improve the Settings API for accessibility and ease of use.,,Plugins,,normal,normal,Future Release,enhancement,new,dev-feedback,2017-01-02T21:58:14Z,2018-02-12T16:39:37Z,"Today a kickoff meeting for the Settings API took place on Slack (Archive: https://wordpress.slack.com/archives/accessibility/p1483376507000492) where we discussed ways to improve it, both in terms of accessibility and ease of use.
After a good discussion we came to the conclusion that we would like to focus on the existing Settings API for now and do what we can to improve it. The Fields API project will eventually make the process of registering settings and having them automatically rendered even easier and complete, but we should not wait until it is ready for a core-merge, as some issues in the existing Settings API should be solved sooner than later.
We figured out two main goals:
* Add some basic support to automatically render fields so that plugin developers no longer need to write their own callback functions for basic fields.
* Get rid of the table structure to improve accessibility. Furthermore the accessibility team should also ensure that the markup generated as the core field output is accessible.
For the technical improvements, we would like to do the following:
* Adjust `add_settings_field()` to support a predefined set of identifiers for a field type instead of a callback function. In that case a default callback function that we would introduce in core would take care of rendering the field. The requirement to write custom callbacks for even the most basic fields is one major issue with the current Settings API and why most people rely on external libraries for that.
* Enhance the `$args` parameter of `add_settings_field()`. It should become more significant and probably go through some validation, filling it with default values. This is especially important for the new default callbacks.
* Possibly support providing one `$args` array as sole parameter to `add_settings_field()` that contains the other parameters as well. This would of course need to work in a backward-compatible way.
For the accessibility part, we would like to do the following:
* Scaffold an HTML prototype for what a settings page should look like. This will give a good overview of the accessibility approach we should take without having to deal with the PHP implementation.
* Get rid of the current table structure. Whatever the above prototype looks like, it will not have tables anymore. We can generally remove the table structure and change it to something else easily, since all the table output is generated by core (in particular by `do_settings_sections()` and `do_settings_fields()`). For everyone who uses the API as recommended, this will not bring any BC issues unless they are using specific table-related selectors (like `td`) in CSS or JS code. It is unclear whether these should be considered edge-cases and whether a dev-note reflecting the changes is sufficient, or whether we should only support the new markup through an additional parameter which would default to the current `table` way. The latter is backward-compatible, but on the other hand it would decrease the amount of sites that become more accessible out-of-the-box.
* Do not deal with people who completely write the table markup manually. We simply cannot do this, other than recommending them to switch to using the Settings API or at least changing their markup. The only thing to keep in mind here is that we should never remove any CSS related to these tables, in order to keep their code working.
All of these enhancements would also benefit #38734 as it would become a lot easier to change core's own settings pages to actually use the Settings API.
We will from now on have meetings on Slack to continue discussion in detail every 2 weeks on Monday at 17:00 UTC. However, general opinions and discussion can and should also be placed in this ticket.",flixos90
Future Releases,21321,"Remove is_null() checks in apply_filters(), do_action(), et al.",nacin,Plugins,,normal,normal,Future Release,enhancement,reopened,dev-feedback,2012-07-20T04:55:29Z,2015-10-01T02:01:11Z,"In apply_filters(), do_action(), and friends, there is a check for `! is_null( $the['function'] )`. As these functions get called collectively thousands of times per page, a tiny check like this can add up.
A few months ago, I decided to track it down. They were shuffled around a bit in [4955], but they actually had roots in [1394]. The link there (http://www.kackreiz.net/wordpress.php) is dead, but I found it at http://www.kackreiz.net/wordpress/apply_filters.html#fixed, via http://wordpress.org/support/topic/bug-in-remove_filterapply_filters?replies=3.
The original bug was that remove_filter() left NULL's in the $wp_filter array, rather than properly unsetting it as it was modified to do long ago. Now that we no longer leave NULL scattered about, this check is safe to remove.",nacin
Future Releases,23863,Post Formats: allow filtering content_width per format in wp-admin,,Post Formats,,normal,normal,Future Release,defect (bug),new,dev-feedback,2013-03-25T20:55:33Z,2015-09-01T23:58:36Z,"On front-end a theme can filter {{{$content_width}}} like so:
{{{
function twentythirteen_content_width() {
if ( has_post_format( 'image' ) || has_post_format( 'video' ) ) {
global $content_width;
$content_width = 724;
}
}
add_action( 'init', 'twentythirteen_content_width' );
}}}
But ... functions called in wp-admin that use the global {{{$content_width}}} variable won't be changed.
For example, using trunk and Twenty Thirteen theme:
1. Create a new post, set to Image post format
2. Click Add Media to insert an image
3. Upload an image at least 800 px wide
4. You'll see in ""Attachment Display Settings"" that width for the ""large"" size to insert to the post is 604 pixels and not 724.
Also, even if detecting a Post Format this way worked correctly on edit, it wouldn't work on first post creation because of how the UI uses JS to switch between the formats.",lancewillett
Future Releases,21941,Deprecate get_post_format_slugs(),@…,Post Formats,,normal,minor,Future Release,enhancement,assigned,close,2012-09-20T14:40:52Z,2016-06-10T18:48:03Z,"I just encountered the `get_post_format_slugs()` function, which is basically just wrapping `get_post_format_strings()` and setting the strings as keys too. So its output is an assoc array where the keys equal the values.
The three times core calls it, it does it the following:
{{{
// ~/wp-includes/posts.php -> set_post_format()
if ( 'standard' == $format || !in_array( $format, array_keys( get_post_format_slugs() ) ) )
// ~/wp-includes/posts.php -> _post_format_request()
$slugs = get_post_format_slugs();
if ( isset( $slugs[ $qvs['post_format'] ] ) )
$qvs['post_format'] = 'post-format-' . $slugs[ $qvs['post_format'] ];
// ~/wp-includes/theme.php -> add_theme_support()
switch ( $feature ) {
case 'post-formats' :
if ( is_array( $args[0] ) )
$args[0] = array_intersect( $args[0], array_keys( get_post_format_slugs() ) );
break;
}}}
So in every case it would've been enough to simply call `get_post_format_strings()`.
Do we really need this function?",F J Kaiser
Future Releases,19949,Make update_post_thumbnail_cache() work for any instance,,Post Thumbnails,,normal,normal,Future Release,enhancement,new,dev-feedback,2012-02-02T22:40:03Z,2016-04-18T10:33:37Z,"It would be useful if update_post_thumbnail_cache() [17883] would accept an optional $wp_query parameter, so that users aren't forced to use query_posts() in order to benefit from it.",scribu
Future Releases,14106,Post-processing of post thumbnails,,Post Thumbnails,3.0,normal,normal,Future Release,enhancement,assigned,dev-feedback,2010-06-26T20:45:24Z,2015-12-03T20:02:44Z,"I'm not sure if I'm missing something, but it looks like there is no hook to post-process post thumbnails. I want to add rounded corners to all thumbnails for a theme.
It looks to me like an action at the end of image_make_intermediate_size() in media.php with $file as parameter might do the trick. I'm not sure if that's the right place or when that function is called precisely though. So it might be necessary to add additional parameters to the function call to identify where the call came from.",nkuttler
Future Releases,30775,Delete empty post problem,wonderboymusic,"Posts, Post Types",3.3,normal,normal,Future Release,defect (bug),reopened,dev-feedback,2014-12-19T02:20:16Z,2016-06-04T13:39:20Z,"If empty post was created it cannot be deleted
Details are here http://arul.ru/pages/writings/delete_post_problem.htm",axdr
Future Releases,11235,"Pages whose ancestors are not all ""published"" cannot be used as parents for other pages.",,"Posts, Post Types",2.9,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2009-11-23T01:04:01Z,2016-10-03T12:39:36Z,Pages with trashed parents cannot be used as parents for other pages (they do not appear on the list).,caesarsgrunt
Future Releases,9864,Performance issues with large number of pages,,"Posts, Post Types",2.7.1,normal,normal,Future Release,defect (bug),assigned,dev-feedback,2009-05-18T19:20:59Z,2018-03-07T15:28:22Z,"'''Environment:'''
- Default install, default theme, no plugins, reasonable server configuration (typical execution, memory limits). In my particular case, that was set to 30 seconds, 384 MB.
'''To reproduce:'''
- Create a large number of pages (5,000+)[[BR]]
- Try to edit a page
'''What happens:'''
- Maximum execution time error
{{{
Fatal error: Maximum execution time of 30 seconds exceeded in \wp-includes\post.php on line 1998
}}}
'''Workaround to prevent error:'''
- set_time_limit to 0 as server admin
'''My diagnosis:'''
Suspect that the immediate problem is that get_pages() inside wp-admin/post.php, line 2173, performs a query that selects EVERYTHING:
{{{
$query = ""SELECT * FROM $wpdb->posts $join WHERE (post_type = 'page' AND post_status = 'publish') $where "";
}}}
Now, in this case this query (AFAIK) is just supposed to pull up the page list (with IDs, titles and parents). What it actually does is it pulls up ALL of the post data. This works fine for low number of pages, but on a larger data set this causes a chokepoint. After all, the end result is just supposed to be a dropdown with a list of pages.
'''Workaround to improve performance:'''
- comment out line 273 in wp-admin\edit-page-form.php and skip displaying the page parent in the edit screen
'''The bigger picture:'''
Well, the ENTIRE list of pages is queried in this 'edit page' screen (see screenshot # 2 - with a dropdown that contains 5,000+ entries.) I think this is a design limitation and it looks clumsy once the list gets larger. Rather than patch the display routines, I think this thing needs to be replaced with something that can search / paginate piecemeal server-side.
",pp19dd
Future Releases,31977,"Ping status of pages changes to ""closed"" in quick edit",pareshradadiya,"Posts, Post Types",4.2,normal,normal,Future Release,defect (bug),assigned,dev-feedback,2015-04-15T11:14:50Z,2015-06-08T09:48:03Z,"WP version: 4.2-beta4
Every page is created with ping_status set to ""open"". If the page is edited in the ""full"" edit form, the ping_status remains untouched. However, if the page is edited in the quick edit form, the ping_status field is changed to ""closed"" since WP 4.2.
Since pages don't support the ping functionality, I suppose it shouldn't change the field. Maybe ""closed"" is the propper one, but it should be set on the creation.
It makes testing of our plugin a little bit tricky.
Thanks.
Jan",JanVoracek
Future Releases,30991,Post type object capability 'delete_posts' is referenced in the posts list table but does not exist unless 'map_meta_cap' is set to true for post type,SergeyBiryukov,"Posts, Post Types",4.1,normal,normal,Future Release,defect (bug),reviewing,dev-feedback,2015-01-12T15:31:48Z,2018-02-21T21:55:08Z,"I'm getting the following error when viewing the main edit screen of a custom post type:
Undefined property: stdClass::$delete_posts at wp-admin/includes/class-wp-posts-list-table.php:209
When I looked up the line, the following code is run:
{{{
if ( current_user_can( $post_type_obj->cap->delete_posts ) ) {
}}}
The problem is that the capability, 'delete_posts', is only applied to a post type (via get_post_type_capabilities()) if the 'map_meta_cap' argument is set to true when you're registering the post type (via register_post_type()).
",bamadesigner
Future Releases,27494,Posts page appears into search results,,"Posts, Post Types",3.8.1,normal,normal,Future Release,defect (bug),new,dev-feedback,2014-03-23T14:27:23Z,2017-02-19T10:40:15Z,"Hi,
if you set a static home page, so then a page for posts, this page is just a virtual page, because it doesn't have any content, just the title. But, if you search on the site for this title, the virtual page will be shown as search result. In my opinion this should be hidden.",SGr33n
Future Releases,37366,Restoring a scheduled post can cause it to be published,,"Posts, Post Types",,normal,normal,Future Release,defect (bug),new,dev-feedback,2016-07-14T14:53:10Z,2016-07-20T16:28:43Z,"If you restore a scheduled post, the post will be published if the scheduled date has already passed.
As a user, I'd expect a scheduled post to remain a draft when restored from the trash.
Steps to reproduce:
1. Create a new post.
2. Schedule the post to be published two minutes in the future.
3. Trash the post.
4. Wait three minutes.
5. Restore the post from the trash.
6. Look at the post to see that it's been published.
There are a few existing related tickets #23022, #19907, #22350, #18362 that haven't seen much movement. However, I think this particular issue is more egregious than the others because the user ''accidentally publishes content they didn't mean to publish''. On higher profile sites, particularly where there are distribution mechanisms hooked into the publishing process, this bug can have a severely negative impact (for instance, accidentally publishing an embargoed post that still wasn't safe to publish).
The solution will be to clear the post date value, but I'm undecided as to whether we should do that when a scheduled post is trashed, or when it's restored from the trash. ",danielbachhuber
Future Releases,36462,Updating or publishing a (custom) post that hasn't loaded completely closes comments,,"Posts, Post Types",4.4.2,normal,normal,Future Release,defect (bug),new,dev-feedback,2016-04-10T14:44:28Z,2017-02-20T22:19:57Z,"I am using a custom post type, but I assume this happens to the default post type as well. On the edit post screen (post.php?post=1&action=edit) I have several custom meta boxes. Some of these have content that is quite slow to load. You can reproduce this behavior by adding a sleep(5) statement somewhere in the code that loads the content for a custom meta box. Now in the document's DOM, the sidebar is loaded before the custom meta boxes. This introduces a situation where it is possible to update or publish a post before all the meta boxes have completely loaded. In most cases this isn't a huge problem - I myself check to see if the $_POST fields are there and if they are not then I don't act upon them.
Unfortunately this does not happen for the included ""Discussion"" meta box. This box has a checkbox named ""Allow Comments"" which gets switched off when you update the post before this meta box has loaded into the DOM.
The culprit is the code in wp-admin/includes/post.php on line 133 in the _wp_translate_postdata() function:
{{{#!php
if (!isset( $post_data['comment_status'] ))
$post_data['comment_status'] = 'closed';
}}}
Since the comment_status field is not in the post data, it is automatically assumed it needs to be closed.
Of course there are two ""workarounds"" I can think of that would improve my current situation. One is for me to optimize the meta boxes so the page loads quicker, the other is to move the Discussion metabox to the top of the page, so it loads first.
Is this expected behavior? I would much rather see the current comment_status be preserved - don't touch it if I didn't intend to modify it. Of course there might be a reason for this implementation that I don't know about.
This post data is then finally presented to wp_insert_post in wp-includes/post.php which actually updates the post's comment_status to become closed, which finally answers my boss' question why comments kept getting disabled automatically.",SeBsZ
Future Releases,30452,_wp_translate_postdata() redundantly+destructively checks current_user_can( $ptype->cap->edit_others_posts ) on update,,"Posts, Post Types",,normal,normal,Future Release,defect (bug),new,dev-feedback,2014-11-21T23:13:46Z,2015-05-04T20:33:13Z,"The product use-case is that the creator of a post should always be able to edit the post, even when they've assigned someone else as a byline. To do so, I'm storing their user ID to post meta:
{{{
public function action_wp_insert_post_persist_author( $post_id, $post, $update ) {
$post_obj = Post::get_by_post_id( $post_id );
if ( $update
|| ! in_array( $post->post_type, Fusion()->get_post_types() )
|| ! $post_obj
|| ! $post->post_author ) {
return;
}
$post_obj->set_first_author_id( $post->post_author );
}
}}}
And then filtering `map_meta_cap`:
{{{
/**
* Filter map meta cap to do whatever custom caps we need
*/
public function filter_map_meta_cap( $caps, $cap, $user_id, $args ) {
switch ( $cap ) {
case 'edit_post':
$post_obj = Post::get_by_post_id( $args[0] );
if ( ! $post_obj ) {
break;
}
$post_type = get_post_type_object( $post_obj->get_post_type() );
// Allow first authors to always edit the post
if ( $post_obj->get_first_author_id() && $user_id == $post_obj->get_first_author_id() ) {
// Don't require editing others' posts
if ( false !== ( $key = array_search( $post_type->cap->edit_others_posts, $caps ) ) ) {
unset( $caps[ $key ] );
}
// If the post is published...
if ( 'publish' == $post_obj->get_status() ) {
$caps[] = $post_type->cap->edit_published_posts;
} elseif ( 'trash' == $post_obj->get_status() ) {
if ( 'publish' == get_post_meta( $post_obj->get_id(), '_wp_trash_meta_status', true ) ) {
$caps[] = $post_type->cap->edit_published_posts;
}
} else {
// If the post is draft...
$caps[] = $post_type->cap->edit_posts;
}
}
break;
}
return $caps;
}
}}}
This approach generally works — except the original author isn't able to save an update to a post because `_wp_translate_postdata()` aggressively checks `current_user_can( $ptype->cap->edit_others_posts )` ([https://core.trac.wordpress.org/browser/tags/4.0.1/src/wp-admin/includes/post.php#L67 ref]).
A check for `current_user_can( $ptype->cap->edit_post, $post_data['ID'] )` was added to `_wp_translate_postdata()` in r22950, but the changeset also leaves in the `edit_others_posts` check.
Given `current_user_can( 'edit_post' )` falls back to `edit_others_posts` behind the scenes ([https://core.trac.wordpress.org/browser/tags/4.0.1/src/wp-includes/capabilities.php#L1114 ref]), I'd expect we could remove the second check.",danielbachhuber
Future Releases,8107,"get_next_post, get_previous_post do not work for posts posted within same second",,"Posts, Post Types",2.7,normal,normal,Future Release,defect (bug),new,dev-feedback,2008-11-08T12:34:22Z,2015-10-01T03:29:54Z,"if you have posts that are published shortly one after the other (e.g. through a script or plugin that posts several posts at once) several of them may end up having the same post_date in the wordpress database table. this is due to the fact that mysql datetime seems to only maintain a precision of one second (see also this discussion: http://bugs.mysql.com/bug.php?id=8523).
the problem now is that wordpress functions like get_next_post/get_previous_post (get_adjacent_post resp.) will no longer work correctly if something like this happens as they solely rely on a comparison of the post_date field and they don't treat the case where these timestamps are the same for several posts. the result is that e.g. get_next_post will pick one of the posts having the same timestamp and ""jump"" over the others, so the user will never see them.
i see two possibilities around this 1.) treat cases with the same post_date by e.g. looking also at the post id (assuming it is always strictly increasing) or probably preferably 2.) make sure that no two posts have the same post_date timestamp by e.g. increasing post_date artificially when publishing the post and if another post already has the same timestamp.
",whoismanu
Future Releases,17374,get_pages() with child_of forgets sort,DrewAPicture,"Posts, Post Types",3.1.2,normal,normal,Future Release,defect (bug),assigned,dev-feedback,2011-05-11T10:06:17Z,2015-10-01T03:46:57Z,"If you call {{{get_pages()}}} with both the {{{child_of}}} and {{{sort_column}}}, the sorting is not applied.
{{{child_of}}} makes it select all pages (sorted) and later applies a subselect via {{{get_page_children()}}}. This subselect can mess up the sort order.
An example was reported on http://wordpress.stackexchange.com/questions/16921/get-pages-not-ordering-as-it-should
Related: #12821",janfabry
Future Releases,32991,wp_delete_post() does not return a WP_Post object,,"Posts, Post Types",,normal,normal,Future Release,defect (bug),new,needs-docs,2015-07-14T09:55:21Z,2017-09-30T02:01:48Z,"The inline doc for `wp_delete_post()` states that it returns a `WP_Post` object, but it actually returns a `stdClass` object (the result of `$wpdb->get_row()`).
There's most likely a reason that a raw SQL query is performed here rather than using `get_post()`. It would be interesting to know what that reason is, and to update the code or the docs accordingly.
Anyone want to investigate?",johnbillion
Future Releases,15230,Action hook before the inserting post into the database,,"Posts, Post Types",3.1,normal,normal,Future Release,enhancement,new,dev-feedback,2010-10-27T09:18:46Z,2017-07-05T08:26:53Z,"Something like
{{{
do_action( 'pre_post_insert', $data, $postarr );
}}}
added to ''wp_insert_post'' function right after the ""else"" statement on line 2501 in .../wp-includes/post.php
",johnnypea
Future Releases,12726,Add get_post_by_*() functions,,"Posts, Post Types",3.0,normal,normal,Future Release,enhancement,assigned,dev-feedback,2010-03-27T05:57:13Z,2015-10-13T00:57:20Z,"Current there are get_page_by_path() and get_page_by_title() function but they hardcode the post_type of 'page'. With support for new custom post types I'm finding a need for functionality to look up posts of custom post types:
{{{
$args = array('post_type','my_custom_post_type');
$path = 'foo-bar';
$post = get_post_by_path($path,$args);
$title = 'Foo Bar'
$post = get_post_by_title($title,$args);
}}}
Another option would be a simple get_post_by():
{{{
$args = array('post_type','my_custom_post_type');
$path = 'foo-bar';
$post = get_post_by('path',$path,$args);
$title = 'Foo Bar'
$post = get_post_by('title',$title,$args);
}}}
This code is not hard to write but looking at the functions in post.php there's not one consistent style so I'm not sure what the best approach would be to write it. Further, I don't completely understand the significance of all the code in get_page_by_path() so wouldn't want to start with it (although I could see it being modified to use the more generic functions that I propose.)
I can make these updates if I get enough direction from the core team, or I'd happily just see them get done. :)
",mikeschinkel
Future Releases,14077,Add support for removal of multiple features from a post type in remove_post_type_support,,"Posts, Post Types",3.0,normal,minor,Future Release,enhancement,new,dev-feedback,2010-06-24T18:10:59Z,2015-10-08T21:42:44Z,"From [http://groups.google.com/group/wp-hackers/browse_thread/thread/1843101eba1f29fc this thread]
add_post_type_support allows an array to be passed as the 2nd parameter, but remove_post_type_support doesn't.
The patch attached adds the functionality.",Utkarsh
Future Releases,35537,AllPosts page: sorting is not remembered,,"Posts, Post Types",4.4.1,normal,minor,Future Release,enhancement,new,dev-feedback,2016-01-19T22:43:43Z,2017-02-06T09:13:22Z,"STEPS TO REPRODUCE
1) Log in (administrator).
2) Remove all posts.
3) Create 3 new posts with titles accordingly ""1"", ""2"", ""3""
4) Go to AllPosts page.
5) Click on ""Title"" column header to sort posts by title (as a result: posts is sorted in order 1,2,3).
6) Click ""Published (3)"".
7) Click ""All (3)""
EXPECTED RESULT: posts is sorted in order 1,2,3
ACTUAL RESULT: posts is sorted in order 3,2,1",antonrinas
Future Releases,37667,Handle post type support in `WP_Post_Type`,,"Posts, Post Types",4.6,normal,normal,Future Release,enhancement,new,dev-feedback,2016-08-15T11:29:21Z,2016-10-25T16:03:05Z,"Currently post type features are stored in a global variable `$_wp_post_type_features`. Now that we have `WP_Post_Type`, I think it would make sense to let the class handle this functionality. Post type features are part of a post type, so they should also be part of it in the implementation. This would also allow us to get rid of the global variable we currently use (note that it's private, so it's not intended to be used directly by other developers).
There's a single possible caveat I would see with this implementation: That would be if post type support is added before the post type is even registered. However, I would think we might be able to change this (with a dev note) since it should be best practices to add post type support either directly (via the `supports` argument in `register_post_type()`) or after registering the post type. Adding a post type feature without the post type being registered is not logical in my opinion.",flixos90
Future Releases,14017,"New template ""tag"": get_custom_field()",obenland,"Posts, Post Types",3.0,normal,normal,Future Release,enhancement,assigned,needs-unit-tests,2010-06-21T04:13:03Z,2017-02-05T14:03:48Z,"It would be helpful to have a way to retrieve a custom field value that is somewhat agnostic of current context.
'''Current way to do this'''
In the header (i.e., before the Loop), one has to access the currently-queried object to get a custom value, with something like this:
`$value = get_post_meta($GLOBALS['wp_query']->get_queried_object_id(), 'field', true);`
In the Loop:
`$value = get_post_meta(get_the_ID(), 'field', true);`
And, lots of tutorials out there tell people to do things like the following, with varying degrees of success (depending on variable scope):
`$value = get_post_meta($id, 'field', true);`
or
`$value = get_post_meta($post->ID, 'field', true);`
'''My proposed function (or ""template tag"")'''
mixed '''get_custom_field''' ( string ''$fieldname'' [, int ''$post_id'' ] )
`$value = get_custom_field('field');`
It picks the current object like so:
{{{
Passed post object ID?
/ \
yes no
| |
use it |
|
within Loop?
/ \
yes no
| |
use current |
Loop ID |
|
currently queried
object is singular?
/ \
yes no
| |
use its ID ID = 0
}}}",filosofo
Future Releases,39666,"Put front page on top of ""All pages"" list",,"Posts, Post Types",,normal,normal,Future Release,enhancement,new,dev-feedback,2017-01-23T03:33:36Z,2018-04-15T15:26:14Z,"I'd like to see the front page and blog page as first elements in the pages list (if such are set of course), no matter what priority they may have.
What do you think?
Screenshot follows.",Presskopp
Future Releases,24572,Should be able to unlock a post outside of ajax handler,,"Posts, Post Types",,normal,normal,Future Release,enhancement,new,dev-feedback,2013-06-12T20:28:37Z,2015-10-03T23:54:14Z,"Right now you can programmatically lock a post for editing using wp_set_post_lock, but you can't unlock it in a similar fashion. The only unlocking code is found in the ajax handler wp_ajax_wp_remove_post_lock.
I've created a function wp_unset_post_lock in the style of wp_set_post_lock that unlocks a post with a given ID. I've also refactored wp_ajax_wp_remove_post_lock to use this function.
The only resulting difference is that we use the current user's ID instead of the one supplied in the ajax call, but since we're unlocking the post instead of locking it, it doesn't really matter who's ID is in the meta.
This change was requested by Joey Kudish of the VIP team.",bbrooks
Future Releases,12955,Add get_post filter,,"Posts, Post Types",,normal,normal,Future Release,feature request,new,dev-feedback,2010-04-10T13:50:07Z,2018-05-16T07:22:11Z,This patch filters the return value of the get_post() function. I would find this very helpful for a plugin I'm developing.,JohnLamansky
Future Releases,43880,Add functionality to add an anonymous user an get its ID for anonymization of data related to a WordPress user.,tz-media,Privacy,,normal,normal,Future Release,enhancement,assigned,needs-unit-tests,2018-04-27T14:05:28Z,2018-05-16T21:32:44Z,"When we need to anonymize data that is (or can be) associated with a WordPress user, we anonymize it by changing the user ID of that data to a user that represents anonymized content. But currently no such user exists, so we set the ID to 0.
In order to display an actual user name (at least for posts), we would need an actual user 'Anonymous' that we can re-assign the content to.
This might be created on WordPress install by default (maybe even with a User ID of `0` that we can then hardcode into the anonymized functions), or by calling a function like `_wp_privacy_get_anonymous_user_id()` that creates the user if not already created and returns the user ID (that might be stored in a site_option).",TZ Media
Future Releases,43879,Add tools for anonymizing of post authors,tz-media,Privacy,,normal,normal,Future Release,enhancement,assigned,needs-unit-tests,2018-04-27T13:46:24Z,2018-05-16T21:32:44Z,"Logged-in users that post content can request the removal of their personal data.
So we should add functionality to add the posts to the erasure infrastructure that is already committed to trunk.
See #43442 for reference (anonymize commenters).",TZ Media
Future Releases,43921,Include community-events-location user meta value in Personal Data Export,,Privacy,trunk,normal,normal,Future Release,enhancement,assigned,dev-feedback,2018-05-01T22:44:58Z,2018-05-16T21:32:44Z,"Any user who visits the Dashboard screen will have a row in the `usermeta` table with location information, which is used by the WordPress Events and News widget to show relevant WP community events. The location information may include an IP address, location description, and/or lat/lon coordinates. This seems like personally identifiable information that should be included in a Personal Data Export.",coreymckrill
Future Releases,29660,Functions in wp_includes/query.php assume non-null return value from get_queried_object,,Query,4.0,normal,normal,Future Release,defect (bug),new,dev-feedback,2014-09-13T13:49:49Z,2017-02-17T22:01:26Z,"There are several functions in wp_includes/query.php that use get_quried_object and assume non-null return values, namely:
* is_attachment
* is_author
* is_category
* is_tag
* is_tax
* is_page
* is_single
* is_singular
This oversight can result in frequent ""Trying to get property of non-object"" errors.",yellyc
Future Releases,18513,Searching with explicit post types unsets page post type,,Query,3.2.1,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2011-08-24T22:13:08Z,2015-10-03T22:03:05Z,"Tested on WP 3.2.1, Twenty Eleven with no plugins, multisite.
If I explicitly limit a search query via a GET request using an array of post_type values, the post_type for page is automatically excluded.
To reproduce:
* Do a search on a WP install (perhaps through a modified search form), such that the URL is like:
http://example.com/?post_type[]=post&post_type[]=page&post_type[]=attachment&s=Test
or
http://example.com/?post_type[]=post&post_type[]=page&post_type[]=book&s=Test
That's searching for ""Test"" on post, page and attachment/book post types.
* Adding the following to a theme's functions.php:
{{{
add_filter( 'pre_get_posts', 'wpcpt_search' );
/**
*
* @param array $query
*/
function wpcpt_search( $query ) {
if ( ! $query->is_search )
return $query;
print_r( $query->query_vars );
return $query;
}
}}}
That spits out (and seemingly confirmed via the values shown in the Debug Bar plugin) the following at the beginning:
{{{
Array ( [s] => Test [post_type] => Array ( [0] => post [2] => attachment )
}}}
and only returns results for posts and attachments (or books). The fact that key 1 is missing makes me think that page was in the array at some point, but it's been unset, but I can't see where, or why, this might be done.
(When no post_type is set, giving a post_type of 'any', which in turn gives all of the non-excluded_from_search post types, then page is one of the array values, and the search results correctly include pages.)
",GaryJ
Future Releases,35913,`is_()` conditional methods should share their logic,,Query,,normal,normal,Future Release,defect (bug),new,dev-feedback,2016-02-23T02:54:55Z,2017-02-06T08:52:07Z,"Many of the `is_()` methods in `WP_Query` share the nearly the exact same logic. As such, they share the exact same bugs, and fixing those bugs requires many parallel changes and huge numbers of tests. See #35902 and #24674 for some recent examples.
It's possible to move all the shared logic to a single `protected` utility method. It's a bit more abstract, but is much easier to maintain and test.",boonebgorges
Future Releases,20899,is_home() should be able to be true when is_feed(),,Query,,normal,normal,Future Release,defect (bug),reviewing,dev-feedback,2012-06-10T19:28:36Z,2017-05-19T15:04:27Z,"is_feed() is a special query flag that can be combined with other query flags — for example, `is_author() && is_feed()` for /author/admin/feed/.
But it can't be combined with is_home(), because is_home() is the fallback that is only set to true when a lot of other things are true — including is_feed(). This appears to be incorrect — is_home() should still be able to be true despite is_feed().
I tracked this down to [1449]. What kind of breakage could occur with this?",nacin
Future Releases,22176,Cache the results of the posts_request_ids query,,Query,3.4.2,normal,normal,Future Release,enhancement,new,dev-feedback,2012-10-12T14:59:37Z,2017-08-20T14:46:54Z,"We are to the point where we could replace the advanced post cache plugin with something in core that is far simpler. We're most of the way there since introducing the split query. And with #22024 we have a good way of doing per-blog cache invalidation for classes of objects, which would be needed by this. Leveraging wp_cache_get_multi() as suggested in #22174 would provide a complete replacement for the adv post cache plugin. http://plugins.svn.wordpress.org/advanced-caching/trunk/advanced-caching.php",ryan
Future Releases,41819,Support the paged argument in WP_Site_Query and WP_Network_Query,spacedmonkey,Query,4.6,normal,normal,Future Release,enhancement,assigned,dev-feedback,2017-09-06T18:21:04Z,2017-11-01T17:47:07Z,"The {{{WP_Site_Query}}} and {{{WP_Network_Query}}} both support the {{{offset}}} and {{{number}}} arguments.
It would be handy to be able to use the {{{paged}}} argument, to make the pagination easier.
",birgire
Future Releases,36652,Use meta_value in a meta query to decide type format in SQL clause,ericlewis,Query,,normal,normal,Future Release,enhancement,reviewing,dev-feedback,2016-04-23T19:27:08Z,2016-06-28T21:37:22Z,"The SQL clause generated for a meta query [https://github.com/WordPress/WordPress/blob/4.5/wp-includes/class-wp-meta-query.php#L628 quotes the `meta_value` in a string].
This means that if there's a post with a postmeta field for likes set to 2 and you run the query looking for posts with 10 or more likes
{{{
#!php
array(
array(
'key' => 'likes',
'value' => 10,
'compare' => '>='
)
)
) );
}}}
the query will return the post with 2 likes. This is because the SQL is doing a string comparison, as both the column value and the compared-to value are strings.
The fix for the developer is to supply a `type` parameter like `NUMERIC` in the meta query clause which coerces a numeric MySQL comparison.
We could use the meta_value's type to decide the type format the value takes in the SQL clause, so that a query like this works as expected without the `type` parameter.
This was [https://core.trac.wordpress.org/ticket/27272#comment:13 suggested] by @boone in #27272.",ericlewis
Future Releases,42883,Use sargable queries for date-based lookups for posts,,Query,3.7,normal,normal,Future Release,enhancement,new,dev-feedback,2017-12-12T16:17:14Z,2018-03-14T20:23:11Z,"Related to #41054 but a very specific and actionable, high-impact instance is the fact that the WordPress lookup for permalinks involving dates is not sargable.
For a bog-standard permalink structure %year%/%slug%/, WP generates the following query:
{{{
SELECT wp_posts.*
FROM wp_posts
WHERE 1=1
AND ( YEAR( wp_posts.post_date ) = 2017 )
AND wp_posts.post_name = 'tahoma-vs-verdana'
AND wp_posts.post_type = 'post'
ORDER BY wp_posts.post_date DESC
}}}
This runs (as a cold query) in ~0.075 seconds on a dedicated (and overpowered) MariaDB 10 instance on a pretty small WordPress DB. While indexes exist for all the fields matched against in the query, the use of {{{AND ( YEAR( wp_posts.post_date ) = 2017 )}}} cannot be matched against the database because MySQL/MariaDB is not intelligent enough to optimize that constraint.
The ""same"" query adjusted to make the match against {{{post_date}}} sargable does the same in ~0.034 seconds (half the time):
{{{
SELECT wp_posts.*
FROM wp_posts
WHERE 1=1
AND wp_posts.post_date >= DATE(""2017-01-01"")
AND wp_posts.post_date < DATE(""2018-01-01"")
AND wp_posts.post_name = 'tahoma-vs-verdana'
AND wp_posts.post_type = 'post'
ORDER BY wp_posts.post_date DESC
}}}
The same would apply for permalinks that reference the month and day, of course.",ComputerGuru
Future Releases,18035,ignore_sticky_posts fails to remove sticky class,johneckman,Query,3.2,normal,normal,Future Release,enhancement,reopened,dev-feedback,2011-07-08T10:03:44Z,2015-12-12T23:35:32Z,"When setting the query_posts parameter:
ignore_sticky_posts = 1
all sticky posts are returned as normal posts and placed accordingly in the flow. However the sticky posts keep their sticky class, which means that an additional filtering of post_class is necessary to avoid any css rules defined for the .sticky selector taking effect.
is this intended, or could it be considered an enhancement if it was patched?
",mikkelbreum
Future Releases,38878,REST API: Default query for users endpoint doesn't scale,,REST API,4.7,normal,normal,Future Release,defect (bug),new,dev-feedback,2016-11-20T11:55:53Z,2017-01-16T16:21:01Z,"The user query is performed with the `has_published_posts` argument which generates the following query
> SELECT SQL_CALC_FOUND_ROWS wp_users.* FROM wp_users INNER JOIN wp_usermeta ON ( wp_users.ID = wp_usermeta.user_id ) WHERE 1=1 AND wp_users.ID IN ( SELECT DISTINCT wp_posts.post_author FROM wp_posts WHERE wp_posts.post_status = 'publish' AND wp_posts.post_type IN ( 'post', 'page', 'attachment', 'forum', 'topic', 'reply' ) ) AND ( wp_usermeta.meta_key = 'wp_2_capabilities') ORDER BY display_name ASC LIMIT 0, 10
'forum', 'topic', and 'reply' are bbPress' post types. We use bbPress on wordpress.org/support/ where I noticed in the logs that the server/database can't handle the request.
I'm currently not sure how and if this needs to be fixed but having at least a ticket for it might help others.",ocean90
Future Releases,41549,REST API: Use `wp.apiRequest` helper in `wp.api` Backbone client,adamsilverstein,REST API,,normal,normal,Future Release,enhancement,assigned,needs-unit-tests,2017-08-03T14:50:13Z,2018-02-01T22:26:54Z,"Follow-up to #40919. The `wp-api.js` Backbone client should use `wp.apiRequest` to do its API calls. This may be accomplished through overriding `Backbone.ajax` or through a change in the `wp-api.js` code.
This will allow client-side code to override or modify all WP REST API calls in a single, centralized place.
cc @adamsilverstein for your thoughts on the best way to achieve this.",jnylen0
Future Releases,40748,Use REST API for Community Events,,REST API,4.8,normal,normal,Future Release,enhancement,new,needs-unit-tests,2017-05-12T17:39:23Z,2017-05-30T02:49:10Z,"#40702 introduced new Community Events to the News widget on the Dashboard screen, but it uses admin-AJAX.
Converting to the REST API is a good opportunity to lay some groundwork for migration the rest of wp-admin in the future.
The work for this was started in #40702, but it'll be easier to keep track of with a new ticket.
I'm working on an updated version of `40702.11.diff` and will upload it soon.",iandunn
Future Releases,40365,Introduce a REST API endpoint for sites,,REST API,,normal,normal,Future Release,task (blessed),new,needs-unit-tests,2017-04-05T00:18:18Z,2018-05-15T16:23:41Z,"It should be possible to manage sites in a multisite configuration through the REST API.
* List sites: `GET wp/v2/sites/`
* Retrieve a site: `GET wp/v2/sites/`
* Create a site: `POST wp/v2/sites/`
* Update a site: `PUT wp/v2/sites/`
* Delete a site: `DELETE wp/v2/sites/`
Data included in a site object should at least mirror the data available for the site in `wp_blogs`. Additional ideal pieces of data for a site include `blogname`, `blogdescription`, `home`, and `siteurl`. It's possible that creating a new meta table for sites can help developers register meta for inclusion with a site object (See #37923).
Sites should be accessible by default for authenticated users only. Network (global) admins should have access to all sites. Site users should have access to the sites they are members of. The ""My Sites"" list is a great candidate for exploring how this will work. See #15317.
As of the introduction of `get_sites()` in 4.6.0, retrieving sites is a much better experience. The methods used to create, update, and delete sites in multisite are not as pleasant right now. We should investigate each of these and determine what can be done to streamline the process. The first improvement is probably in creating a site. See #40364.",jeremyfelt
Future Releases,34560,High memory usage ( and possible server error) editing post with many/large revisions,adamsilverstein,Revisions,3.6,normal,major,Future Release,defect (bug),assigned,needs-unit-tests,2015-11-02T23:42:27Z,2017-11-14T15:02:39Z,"**Version:** This issue was seen under WordPress 4.3.1, but it likely applies to any modern version of WordPress, even as far back as [https://github.com/WordPress/WordPress/blob/2.9-branch/wp-admin/edit-form-advanced.php 2.9] or maybe earlier.
**Expected Behavior:** A WordPress user should be able to happily create thousands of revisions of pages (or blog posts) containing megabytes of HTML text, limited only by the amount of server memory needed to contain the specific edited revision of the page or post (minus baseline memory needs). So, for example, if you have a 256MB PHP memory limit, you should be able in theory to edit pages of 100MB or more for thousands of revisions (ignoring non-memory constraints like CPU usage, database configuration, communication timeouts, or browser-side limitations). Certainly you should be able to edit a page or post of under 1MB for hundreds of revisions given 256MB of allowed PHP memory (or even just with a 32MB memory limit given few plugins). While editing in WordPress will have limits based on available memory or CPU use or communications timeouts and the memory demand of the current revision being edited, those editing limits should not be substantially affected by the number of revisions of a post previously saved or the sizes of previously saved revisions.
**Exhibited Behavior:** Right now, you will unhappily see ""500 server error"" and ""white screen of death"" results eventually if you, say, edit a 400K page for hundreds of revisions, even with a 256MB server memory limit. Here is an example error from a server with 256MB memory limit resulting from trying to edit a page after saving about 350 revisions of a page that grew to be 437,042 bytes in size:
{{{
[02-Nov-2015 14:40:42 UTC] PHP Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 437043 bytes) in /usr/home/narrafirma/public_html/narrafirma.com/wp-includes/wp-db.php on line 1389
}}}
**Steps to reproduce:** Create a new WordPress page. Put 500K or so of text in it (or any other large amount, the smaller the amount, the more revisions needed to be saved). Save the page for hundreds of revisions. Failure will occur when the number of revisions times the post size exceeds the PHP available memory minus the core memory need of WordPress+plugins. To speed this failure process, reduce the memory available to PHP.
**Likely cause:** The file edit-form-advanced.php has the following section of code which retrieves all revisions for a post using wp_get_post_revisions and then counts the result (twice) to display a count of revisions on the page. While the current approach has a certain elegant simplicity and is easy to understand, the approach is unfortunately computationally inefficient because retrieving all the revisions of a post just to count them potentially consumes a lot of memory, a lot of CPU time, and a lot of database bandwidth when there are many revisions of a post if some are of significant size.
From [https://github.com/WordPress/WordPress/blob/4.3.1/wp-admin/edit-form-advanced.php edit-form-advanced.php (4.3.1)]:
{{{
$publish_callback_args = null;
if ( post_type_supports($post_type, 'revisions') && 'auto-draft' != $post->post_status ) {
$revisions = wp_get_post_revisions( $post_ID );
// We should aim to show the revisions metabox only when there are revisions.
if ( count( $revisions ) > 1 ) {
reset( $revisions ); // Reset pointer for key()
$publish_callback_args = array( 'revisions_count' => count( $revisions ), 'revision_id' => key( $revisions ) );
add_meta_box('revisionsdiv', __('Revisions'), 'post_revisions_meta_box', null, 'normal', 'core');
}
}
}}}
**Suggested fix:** Retrieve the count of revisions in some other way with custom SQL. Alternatively, add an option in when retrieving revisions via ""wp_get_post_revisions"" (in ""wp-includes/revision.php"") to only retrieve the metadata for the revision (like size, timestamp, user, and so on) and use that option in this code. Incidentally, another minor optimization for this code fragment may be to store the count of revisions in the code above so the counting process is not done twice (depending perhaps on how count is implemented versus variable allocation costs in PHP).
**Caveats:** I have only tested this error condition for a page, but I am assuming this issue will apply to blog posts as well (or any kind of posts with revisions). I am not sure what other implications there would be from such a change, like if the revisions' contents were needed elsewhere later for comparisons -- although such a situation could potentially be dealt with by selectively loading specific revision's contents as needed for diff comparisons, even if all the metadata might be needed up front.
**Other potential benefits of the proposed fix:** Beyond avoiding server errors and white screens, making the proposed change may speed up opening long posts and pages for editing by reducing server load substantially. When editing even small posts with a few revisions, this change will still likely speed up the initial opening of the editor at least slightly.
**Use cases:** An example situations of a large page with multiple revisions is where a team uses a WordPress page to track component version deployment status of a large system. Another use case is when a WordPress page grows into a book-length document through repeated editing by someone :-) who is also used to saving a lot to avoid losing work from browser crashes.
**Additional suggestion for further code review:** All uses of ""wp_get_post_revisions"" and any similar functions, as well as all uses of ""count"", could be reviewed in the WordPress codebase looking for similar computational inefficiencies.
",pdfernhout
Future Releases,24958,Large number of revisions cause memory exhaustion,adamsilverstein,Revisions,3.6,low,normal,Future Release,defect (bug),assigned,dev-feedback,2013-08-05T17:17:59Z,2018-03-22T18:54:42Z,"This may be a edge case, but if you have a a large number of revisions, a number of things can break.
Right now the post in question has about 1,055 revisions.
Noticeably, two things are happening:
Calling wp_update_post from a plugin fails with the following error:
{{{PHP Fatal error: Allowed memory size of 41943040 bytes exhausted (tried to allocate 16384 bytes) in /path/wp-includes/wp-db.php on line 1228}}}
Using the new revisions API to view earlier revisions returns
""Sorry, something went wrong. The requested comparison could not be loaded.""
and the error log contains the same memory exhaustion error.
I can seem to update from the post edit screen.
This is happening with the latest stable of 3.6 and only began happening after an update, so I suspect it's something in the new revision core/api. I haven't had a huge amount of time to investigate but my guess is it's trying to load too much revision data at one time? Maybe it should only try to load X amount of revisions at once?",jshreve
Future Releases,20299,"Preview changes on a published post makes all post meta ""live""",adamsilverstein,Revisions,3.3.1,normal,major,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
Future Releases,20564,Framework for storing revisions of Post Meta,adamsilverstein,Revisions,3.4,normal,normal,Future Release,enhancement,assigned,dev-feedback,2012-04-28T08:51:36Z,2017-07-12T02:31:32Z,"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]]
https://github.com/crowdfavorite/wp-revision-manager/blob/master/cf-revision-manager.php
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]]
http://plugins.svn.wordpress.org/revision-manager/trunk/cf-revision-manager.php
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
Future Releases,36188,"After WordPress installation, the default category archive page is showing a 404 page",,Rewrite Rules,4.2,normal,normal,Future Release,defect (bug),new,dev-feedback,2016-03-09T19:17:14Z,2017-12-06T22:20:49Z,"Steps to reproduce the issue:
1. Install WordPress
2. Log to the back-end
3. Go to Post -> Categories and click on the ""view"" link of the default category.
=> You get a 404 page
Now, if you visit Settings -> Permalinks, the default category archive page is showing correctly.
This issue might be related to #20171",strategio
Future Releases,28517,Logic error in WP_Rewrite flush_rules,,Rewrite Rules,3.7,normal,normal,Future Release,defect (bug),new,dev-feedback,2014-06-12T20:42:02Z,2017-05-18T15:06:04Z,"The current logic in flush_rules of WP_Rewrite is flawed:
{{{
if ( ! $hard || ! apply_filters( 'flush_rewrite_rules_hard', true ) ) {
return;
}
}}}
Given the four possible scenarios:
$hard has two unique values:
* true (by default)
* false
Casting apply_filters( 'flush_rewrite_rules_hard', true ) to a boolean also has two unique values:
* true (by default)
* true (a filter returns a value that evaluates to true)
* false (a filter returns a value that evaluates to false)
=============================================
If $hard is true and either no filters are added, or a filter is added that returns true:
{{{
! true || ! true = false || false = false
}}}
{{{
#!html
UNINTENTIONAL FAILURE
}}}
=============================================
If $hard is true and a filter is added that returns false:
{{{
! true || ! false = false || true = true
}}}
{{{
#!html
UNINTENTIONAL SUCCESS
}}}
=============================================
If $hard is false and either no filters are added, or a filter is added that returns true:
{{{
! false || ! true = true || false = true
}}}
{{{
#!html
UNINTENTIONAL SUCCESS
}}}
=============================================
If $hard is false and a filter is added that returns false:
{{{
! false || ! false = true || true = true
}}}
{{{
#!html
UNINTENTIONAL FAILURE
}}}
=============================================
As seen above, 50% of the unique scenarios give an unexpected response. While the other 50% of the scenarios give the expected response, but for the wrong reason.",numis
Future Releases,21682,Rewrite endpoints are lost if a custom category or tag base is defined,DrewAPicture,Rewrite Rules,3.4,normal,normal,Future Release,defect (bug),reviewing,dev-feedback,2012-08-24T15:57:04Z,2015-11-13T02:20:15Z,"== Problem ==
So this little bug was winding me up for a while.
The standard approach according to the codex for adding rewrite endpoints is to call the `add_rewrite_endpoint()` function within the init hook. So far so good.
The problem occurs whenever `WP_Rewrite::init()` is called ''after'' the init hook. It resets the endpoints array and so when rewrite rules are subsequently generated through the options-permalink.php admin page the rewrite rules are unknown to the system and hence don't work.
`WP_Rewrite::init()` is called within `WP_Rewrite::set_category_base()`, `WP_Rewrite::set_tag_base()` and `WP_Rewrite::set_permalink_structure()`.
In the latter it is only called if the permalink structure has changed so on first save of a change endpoints are lost. In the other 2 it is called every time if the slug doesn't match the default so rewrites are always lost.
== Solutions: ==
1. add an action hook to the start of `WP_Rewrite::rewrite_rules()` where endpoints should be added
2. store the endpoints at the start of `WP_Rewrite::init()` and restore them at the end
3. don't reset them at all
I think solution 3 would make sense, the endpoints could be defaulted to an empty array and I can't see any reason to want to reset them anyway.
I've attached a simple patch that works (for me at least).
'''NB.''' this problem may also affect the `$extra_rules` and `$non_wp_rules` but I haven't tested that theory yet.",sanchothefat
Future Releases,14991,extra_rules_top should take priority over extra_permastructs,,Rewrite Rules,3.1,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2010-09-29T18:00:08Z,2015-12-03T20:01:51Z,"Since extra_rules_top are specifically added instead of generated like the those from the extra_permastructs which runs through generate_rewrite_ruls(), shouldn't the extra_rules_top take priority in conflicts?",prettyboymp
Future Releases,22895,user_can_admin_menu() is Type-Insensitive for Users who Can't Create Pages,johnbillion*,Role/Capability,3.5,normal,normal,Future Release,defect (bug),accepted,dev-feedback,2012-12-12T18:32:53Z,2018-04-17T19:08:26Z,"Utilization of the new separation edit_posts /create_posts capability separation reveals a flaw in admin menu privilege checking.
The issue occurs when:
1. For any post type other the ""post"", the user has $type->cap->edit_posts but not $type->cap->create_posts
2. User also does not have a manage_terms capability for any associated taxonomies
In that situation, access to ""edit.php?post_type=whatever"" fails unless the user has the ""edit_posts"" cap for the ""post"" type.
This occurs because:
1. '''wp-admin/includes/menu.php''' removes solitary submenus that have the same destination as the parent
2. '''get_admin_page_parent()''' returns nullstring if there is no $submenu item
3. '''user_can_access_admin_page()''' performs a type-sensitive capability check only if get_admin_page_parent() returns an existing $submenu key.
For now, my plugin workaround is to hook into 'admin_menu' and add a dummy submenu with nullstring caption. ",kevinB
Future Releases,10201,Remove user-specific caps,,Role/Capability,2.8,normal,normal,Future Release,enhancement,assigned,close,2009-06-17T23:02:36Z,2015-12-03T20:04:43Z,"See IRC discussions from June 18th 2009
* The current role system is rather complicated, But has a lot of flexibility
* A lot of the flexibility isn't even used by most (ie. the ability to have a user with a Roll + a single capability)
* The role system starts having trouble with a high number of users
* To look up every user with a certain cap. it requires loading all the users, and then checking individually.
The proposed changes are:
* That we reduce the complex system to something much more simple:
* Roles are retained: 1 role per meta entry, and since the meta API allows for multiple values for the same key, this would have the benefit of multiple roles, and direct lookups.
* However:
* Remove the ability for a user to be part of a Role, and have an extra capability added on top of that.
* This has the ability to significantly increase performance, As now:
* Looking up users with a specific cap is easy:
* Filter the role list for roles with that cap
* SQL the usermeta table for users in those roles
* Select those users (if needed, else return the ID's)
* An upgrade path is available which doesnt require extra tables, and reduces the ammount of serialization
* The other option is a whole new set of tables.. which.. those who are sane (And there are some insane people in WP Dev..) realise that its not really needed.
* Fine grain control has never been possible from WP without a plugin, Nothing would change here, If a user wants fine grained control over permissions, They'd still have to run a plugin, Its just that that plugin may have to do more heavy lifting now -- since wordpress's API/role system would be simpler and not support the extra fangledangles.",Denis-de-Bernardy
Future Releases,17916,Enqueued styles are only printed on login_footer in wp-login.php,,Script Loader,3.2,normal,normal,Future Release,defect (bug),reopened,dev-feedback,2011-06-28T00:29:48Z,2016-02-21T18:54:43Z,"In my plugin I have this include:
wp_register_style(""cimy_uef_register"", $cuef_css_webpath.""/cimy_uef_register.css"", false, false);
now independently where and when I use the above css, even if I never enqueue or print it... it basically forces the admin panel to be always left instead of the right.
In particular it changes the admin panel menu #adminmenu to stick to the left, also other little things.
The question is:
why this happens even if the CSS is not included at all? Browsing the documentation quickly on that function I didn't find anything useful, please help me.",Cimmo
Future Releases,16118,Support for wp_enqueue_style with negative conditional comments,,Script Loader,3.0.4,normal,normal,Future Release,enhancement,new,dev-feedback,2011-01-06T06:18:40Z,2016-11-10T01:10:15Z,"Please refer to #10891. It refers to the support for conditional comments using the global variable, wp_styles.
I have noticed that if you pass a negative conditional comment, however, this breaks. E.g. Let's say you have a lot of CSS3 rules, which don't apply to IE. You would not include that CSS:
{{{
}}}
I know that IE9 supports CSS3, but I am using the above for illustrative purposes. One would expect that to include the conditional comment above you would do this between the register and the enqueue commands:
{{{
$GLOBALS['wp_styles']->add_data('my-handle', 'conditional', '!IE');
}}}
If you add a conditional tag to wp_styles, however, the generated markup is incorrect:
{{{
}}}
Note the missing --> after [if !IE]>, and