﻿__group__,ticket,summary,owner,component,_version,priority,severity,milestone,type,_status,workflow,_created,modified,_description,_reporter Future Releases,20564,Framework for storing revisions of Post Meta,,Revisions,3.4,normal,normal,Future Release,enhancement,reopened,needs-codex,2012-04-28T08:51:36Z,2014-03-08T14:33:38Z,"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 Next Release,26697,HTML5 Galleries,nacin,Gallery,3.8,normal,normal,3.9,enhancement,closed,needs-codex,2013-12-21T00:42:55Z,2014-03-06T04:44:18Z,"In 3.6 we made great strides with the introduction of HTML5 versions of the search form, the comment form, and the comment list. Let's add to this list by giving theme authors the option to add HTML5 support for image galleries!",obenland Next Release,19796,Multisite installs should work with WordPress in a subdirectory,markjaquith,Multisite,,high,normal,3.5,task (blessed),closed,needs-codex,2012-01-10T21:46:53Z,2014-03-06T00:07:02Z,"Currently, Multisite cannot be enabled if WordPress is installed within a subdirectory. This prevents you from using WordPress as an SVN or Git external. We should have parity. Resolved: find a way to make Multisite work if WordPress is in a subdirectory.",markjaquith Next Release,20905,Allow rewrite endpoints to specify a different query variable name,johnbillion,Rewrite Rules,,normal,normal,3.9,enhancement,closed,needs-codex,2012-06-11T13:53:40Z,2014-03-04T20:21:02Z,"Using `add_rewrite_endpoint()` we can add an endpoint such as `/foo/bar/` which maps to `foo=bar`. I'd like to be able to map an endpoint to a query variable of a different name. Currently the query variable name always matches the endpoint name. Example: I'd like to use `/p/{number}` as a nice short endpoint for some custom functionality, but the 'p' query variable is used by core. I'd like to be able to map `/p/3/` to `my_query_var=3`.",johnbillion Future Releases,15719,Connection Information dialog does not explain root problem,,Filesystem API,3.0.2,normal,normal,Future Release,enhancement,new,needs-codex,2010-12-07T17:27:06Z,2014-02-28T21:03:33Z,"On a brand new install of WordPress on a fresh Ubuntu 10.10 LAMP server, after trying to update a plugin, I got the '''Connection Information''' page that requested FTP information. (""To perform the requested action, WordPress needs to access to your web server. Please enter your FTP credentials to proceed. If you do not remember your credentials, you should contact your web host."") This message should have explained the root cause: my filesystem permissions did not allow WordPress to write. I think this error message is defective (a bug) because it doesn't explain the problem. Therefore, admins are forced to go on a wild goose chase to find the root cause and proposed an alternative (FTP) that I didn't even want to use.",novasource Future Releases,23165,Admin validation errors on form nonce element IDs (_wpnonce),,Security,,normal,normal,Awaiting Review,enhancement,new,needs-codex,2013-01-10T02:25:17Z,2014-02-22T04:37:52Z,"The `wp_nonce_field()` method has a design flaw in that the `name` parameter is optional, but its default value (""_wpnonce"") is used for the field element `id`. This wouldn't be bad if only one form is used on each page, but that is rarely the case in the admin panel. Currently, this only results in harmless HTML validation errors in admin, and in very rare situations (depending on plugins installed), can result in javascript scope-related issues breaking forms. This is an issue that keeps being reported and fixed several times (see #5962, #6564, r14737 from #13383, and the latest [http://core.trac.wordpress.org/ticket/22712#comment:11 #22712]) by simply specifying the name in all locations that don't at the time in core. There's at least three different approaches that I can see where we could prevent this from popping back up in the future and encourage better coding habits. == A: Require the Name Parameter == The most obvious approach is to simply adds a `_doing_it_wrong()` call (though it could just be `_deprecated_argument()` instead) for any calls to `wp_nonce_field()` that don't specify the `name` parameter, forcing everyone to give nonce fields unique IDs (and names). A side-effect of this change is that it will also warn developers they are doing it wrong if they use `wp_nonce_field()` without the (also currently optional) `action` parameter, which is actually a good thing since the docs already warn that this is a security hole. There are 46 locations in core that would need updated with this change that make this mistake, and the fix for each of them with this change is exactly the same as what every other commit to fix this problem has always done: just specify the `name` to give a unique ID. The downside to this approach is that this pushes for an immediate change not only to all calls to `wp_nonce_field()`, but also their corresponding `check_admin_referer()` calls (to update the changed field name) in a single WP release, and considering how frequently it's called this way in core, I don't even have to look at plugins to see how often it happens there (it's going to be too many to count). This approach still results in an explicitly named ID that really doesn't need to be on the field in the first place in most locations. I gave this approach a shot anyway, and started on a patch just to see how much work it would be at least in core, but I started to find a few locations that could benefit from unique IDs, but similar field names. I also found myself already spending hours updating and testing just 9 of the 46 locations (unit tests don't cover this stuff) where I was forced to make changes to IDs that would be best left alone for now. I have attached this unfinished patch anyway if anyone is curious to see how it works, what it does, and to see what kinds of changes it ends up requiring. It's still possible to just pass ""_wpnonce"" as the `name` with this change, so the rest of the locations could simply use that to progressively work towards unique IDs, but I just don't see this as a good solution overall, and it seems like a lot of work for very little gain on a minor issue. == B: Use Action for ID or Remove ID Entirely == Another option might be to remove ID entirely, or use (and require) the action parameter as the ID. This would improve results with unique IDs fixing most locations where `wp_nonce_field()` is used without requiring a change to each one individually for most uses (except for nonces used with ajax calls). All locations in core at least use `action` already, so the case for using `action` as ID instead seems better than using `name`. Unfortunately, either removing or using the action parameter for ID (changing the ID) would obviously break a few plugins that made the mistake of relying on the default `_wpnonce` (or the current `name` value) value for `id` from within JavaScript code for existing form endpoints. In the WP.org plugin repo, this appears to happen in the following plugins (searching up through plugins starting with 'r') for forms using the default value: {{{ automatic-youtube-video-posts buddypress buddypress-backwards-compatibility canalblog-importer community-submitted-news eyes-only-plus facepress-ii globalfeed lazyest-gallery lazyest-maps maven-member pagely-reseller-management pluginbuddy-yourls post-event2 qtranslate-separate-comments repostus ... }}} There's likely way more plugins that post to core forms using a non-default `name` that would break though as well, and even though I think ID should have never been added to the nonce field attributes and was never necessary in the first place, compatibility rules would need to be broken if this approach was used. This of course means this option is most likely not really an option at all. == C: Use an Option Array Parameter in Place of Name == To keep this concise, this last approach basically involves changing `wp_nonce_field()` to: {{{ function wp_nonce_field( $options = array() ) { ... } }}} The `options` parameter is a standard arguments array used with `wp_parse_args()`. This accomplishes not just one, but two different goals. First, if `$options` is not an array or the method was called with anything other than 1 parameter, we know this is an older call that needs to use the `name` parameter for both `name` and `id`, using `func_get_args()` for the original arguments, and can do so for full 100% backwards compatibility. Second, unrelated to this issue, the function has been refactored to adhere to coding standards in regards to [http://codex.wordpress.org/WordPress_Coding_Standards#Self-Explanatory_Flag_Values_for_Function_Arguments self-explanatory flag values] as far as the `referrer` and `echo` options are concerned. The `options` array can then be made to accept the following settings: - action: The same unique name included in the nonce hash as is the case now. - name: The field name (and *only* used for the name attribute). (Default: ""_wpnonce"") - id: The field ID if this really is still desired, and can even be different than the name, but by default, the field won't have an ID at all. - referrer: Whether to set the referer field for validation. (Default: true) - echo: Whether to display or return hidden form field. (Default: true) The only downside here is that each `wp_nonce_field()` call will be more verbose in most cases, especially if they do need to use an ID. For example, this: {{{ wp_nonce_field('add-tag', '_wpnonce_add-tag'); }}} Will now become this: {{{ wp_nonce_field( array( 'action' => 'add-tag', 'name' => '_wpnonce_add-tag' ) ); }}} I see plenty of benefits to this last solution though, and it requires very few changes up front, so I think it comes down to this approach ultimately. Please see attached patch.",bpetty Next Release,17807,get_adjacent_post() doesn't work with custom taxonomies,nacin,Taxonomy,3.1.3,normal,normal,3.8,defect (bug),closed,needs-codex,2011-06-15T09:51:46Z,2014-02-18T20:46:03Z,"If you use `next_post_link('%link', '%title', true)` or `previous_post_link('%link', '%title', true)` to get the adjacent post for a custom post type which has a taxonomy assigned to it, it doesn't work as intended. The bug traces back to `get_adjacent_post()`. If the $in_same_cat parameter is true, then the SQL query built to get the posts are hardcoded using the default 'category' taxonomy. Instead it should allow a custom taxonomy as a parameter and use it in the queries. Example: Custom Post Type: `product` Custom Taxonomy: `color` SQL produced by `get_adjacent_post()` when calling `next_post_link('%link', '%title', true)`: `SELECT p.* FROM wp_posts AS p INNER JOIN wp_term_relationships AS tr ON p.ID = tr.object_id INNER JOIN wp_term_taxonomy tt ON tr.term_taxonomy_id = tt.term_taxonomy_id AND tt.taxonomy = 'category' AND tt.term_id IN () WHERE p.post_date > '2011-06-14 19:37:08' AND p.post_type = 'product' AND p.post_status = 'publish' AND tt.taxonomy = 'category' ORDER BY p.post_date ASC LIMIT 1` ",avaly Future Releases,26570,wp_set_object_terms - bug,,Taxonomy,2.3,normal,normal,Awaiting Review,defect (bug),new,needs-codex,2013-12-12T16:37:30Z,2014-02-10T03:57:12Z,"wp_set_object_terms claims to be able to use a taxonomies ID or slug when in fact it will only use slug, trying to use a category ID will create a new numerical category and assign that. http://codex.wordpress.org/Function_Reference/wp_set_object_terms",stiofansisland Future Releases,19958,"Allow custom post types as ""home"" and get_posts() to return results for more than one post type",,"Posts, Post Types",3.3.1,normal,normal,Awaiting Review,enhancement,new,needs-codex,2012-02-04T00:59:13Z,2014-02-02T07:58:59Z,"In {{{ Wordpress admin > Settings > Reading }}} there is an option to define what the home page or the front page should be {{{ Front page displays }}} Radio button {{{ A static page (select below) }}} is followed by a dropdown containing a list of all pages. I would request that custom page types be allowed in this dropdown. This way, I could make my bbPress forums or my All-in-one event calendar, etc my homepage. ",sooskriszta Future Releases,22314,Add singular.php to template hierarchy,,Themes,3.4.2,normal,normal,Awaiting Review,enhancement,new,needs-codex,2012-10-30T15:04:24Z,2014-02-01T07:55:30Z,"Currently, the template hierarchy includes a fallback template (archive.php) for all archive-index type pages (date, tag, category, taxonomy, author, blog posts index, custom post type index), but does not include an analogous fallback template for single-post type pages (blog post, page, attachment, custom post type). This patch adds `singular.php` to act as such fallback. This change also ensures that all template context conditionals have associated template files. AFAIK, `is_singular()` is currently the only template context conditional that does not have such a corresponding template file.",chipbennett Future Releases,25160,Unnecessarily passing $this by reference in core,,General,,normal,normal,Future Release,defect (bug),new,needs-codex,2013-08-27T21:58:59Z,2014-01-24T05:29:46Z,`WP_Widget::form_callback()` passes `$this` by reference to an action. This is no longer necessary as of PHP5.,jdgrimes Future Releases,20359,wp_list_categories - Diff to make use_desc_for_title parameter more flexible,,Taxonomy,2.2.1,normal,normal,Awaiting Review,enhancement,new,needs-codex,2012-04-04T22:57:44Z,2014-01-19T08:53:08Z,"Right now, the @use_desc_for_title is defined as a boolean parameter which outputs category link title attributes containing either: - Category descriptions by default (''bool '''1''''');[[BR]] - 'View all posts filed under [category-name]'.[[BR]] Now, since the title attribute is not required for '''''' tags in any HTML spec, I made a patch to turn this parameter into a string, with the following supported values:[[BR]] - 'desc' => (default) Outputs category descriptions;[[BR]] - 'viewall' => Same output as ''bool '''0''''' (''false'') before: 'View all posts filed under [category-name]';[[BR]] - 'none' => Does not output any title attributes.[[BR]] I have tested this thoroughly, but additional testing would not hurt.",Marventus Future Releases,18897,query_posts / WP_query parameter 'offset' should play nicely with 'paged',wonderboymusic,Query,3.2.1,normal,normal,Future Release,enhancement,reopened,needs-codex,2011-10-10T22:18:29Z,2013-12-02T17:19:22Z," Setting the offset parameter with WP_query ignores the paged parameter. Thus offset can only be used as if on page 1. This is unfortunate and seems worth fixing. See prior #2558 ""query_posts() should support offset""",here Future Releases,17957,wp_reschedule_event & daylight saving,,Cron API,3.2,normal,normal,Awaiting Review,enhancement,reopened,needs-codex,2011-07-01T09:03:28Z,2013-11-18T22:42:19Z,"When a recurring event is established using the WP cron functions the function takes a Unix timestamp and a recurrence interval. In the situation where daylight saving changes the local time, the timing of an event can change by an hour. So, if a database backup is set to run at midnight when the clocks change this can start to happen at 11pm or 1am instead since the timing of the event is based on an initial static time (Unix timestamps reference point is January 1, 1970) and a static interval period. An enhancement to the cron functions would be to account for an obey daylight saving changes so that events schedule for midnight actually occur at midnight irrespective of the time of year.",MattyRob Next Release,26067,title problems when defining menu name same as one of my category,,Taxonomy,3.0,normal,normal,,defect (bug),closed,needs-codex,2013-11-16T15:27:44Z,2013-11-16T15:41:22Z,"When i define my primary menu name for eg: '''SOCIAL''' and by chance had to define the same name ie '''SOCIAL''' for one of my category in the same menu,it creates problem in displaying title for that particular category name,moreover when i tried to change the name of the primary menu it changed the name of the category itself resulting in page not found errors. For eg: if i visit the other categories the title in browser window displays '''CATEGORY NAME(SEPARATOR)SITENAME''' that is '''""Category|Sitename""''' But when i visit the category which is by chance similar in name to that of the primary menu which it falls under, it does not follows the same order to display titles as defined rather it just shows only the category name that is '''""CATEGORY""''' instead of '''""Category|Sitename""''' Does that means we cant have a ""category name"" similar to that of the ""primary menu name"" which it falls under.Plus it changes the category permalink as well on changing the primary menu name.",shivam kumar Next Release,17460,WP Updates througth SSH Script,bugdev,Administration,3.2,normal,normal,,feature request,closed,needs-codex,2011-05-16T19:57:14Z,2013-10-07T14:52:53Z,"The current WP Update engine is very unsecure, because if there is a webserver issue or a connection timeout, memory overflow, connection issue than the wordpress update is corruptes. More secure the update will be if we can do/execute a php script or ssh script througth the terminal, what also gives advanced informations about update errors ect.",bugdev Next Release,18746,Make WP_Query::is_tag() accept a term-name and term-id,wonderboymusic,Taxonomy,3.3,normal,normal,3.7,enhancement,closed,needs-codex,2011-09-22T13:05:15Z,2013-09-06T17:26:04Z,"The ''is_category()'' function recieves as a parameter Category ID, Category Name or Category Slug. So is the ''is_tax()'' function, it recieves as a parameter Term ID, Term Name or Term Slug. But the ''is_tag()'' function can recieve only Tag Slug.",ramiy Next Release,24932,HTML5 support for specific features doesn't work.,nacin,Themes,3.6,normal,normal,3.6.1,defect (bug),closed,needs-codex,2013-08-02T20:21:20Z,2013-09-04T17:46:09Z,"The check for the second parameter in `current_theme_supports()` in [24417] is irrelevant. Unit test here: https://gist.github.com/nathanrice/6143003 There is no exception in the switch statement for html5 support, so the function just returns true (early) if `html5` is supported at all. The second parameter is essentially ignored. So, if you intend to turn on html5 output for just 1 of the 3 options, it doesn't matter. All 3 will output in html5. Which is, perhaps, intentional. I'm really not sure. If not, I'm prepping a patch to correct it.",nathanrice Next Release,24549,"Follow the WP Handbook Standard, and change The Loop of Core Themes to Use Brackets",,Bundled Theme,3.6,normal,normal,,enhancement,closed,needs-codex,2013-06-10T04:32:26Z,2013-08-27T12:13:26Z,"This started as a discussion over a pull request to change the if-endif statements to brackets in the template files for Easy Digital Downloads. After lengthy discussion on that [https://github.com/easydigitaldownloads/Easy-Digital-Downloads/pull/1194 Github issue], and even more discussion in our dev chat, @pippinsplugins published [http://pippinsplugins.com/please-do-not-use-curly-brackets-in-template-files/ a post] about his beliefs on the matter.http://techcrunch.com/ The reason for this Trac ticket is to request the core's themes, which (to date) are 2010, 2011, 2012, and in 3.6 trunk, 2013, to use braces instead of if-endifs in The Loop. At the very beginning, this may seem like a trivial matter. Instead it's far from it. This is actually a pretty deep rooted issue, caused by the ambiguity of the presence of endifs in Core, when combined with the discouragement from using them in the Codex. The problem lies in that, (as Pippin's belief is) that most new WordPress devs first learn coding by studying their theme's loops files. For most users of WordPress, either their theme is one of the aforementioned core themes, or contains a loop based on one of them. A plugin author, such as the EDD devs, then make template files for our plugins, which are intended to be edited by said users. A good place to start, would be advantages to using braces over if-endif. * Braces are fully supported by most IDEs. Most IDE's can find the corresponding open or close brace based on the highlighting of another one. Importantly, this includes IDE's that said new developers, might be more inclined to use, such as Dreamweaver, or similar. However, if-endifs are not supported in this manner, but in only a handful of IDE's. * New developers will understand braces better than if-endif. Whether from their background in CSS (where braces contain rules), mathematics, or otherwise, braces are a symbol of a containing element. From Pippin's post, it also seems the vast majority of developers also prefer braces. * It's shorter. Trivial maybe, but still slightly shorter. * It's standard. The [http://make.wordpress.org/core/handbook/coding-standards/php/#brace-style WordPress Code Handbook] states to use braces. If braces are the standard, they should be used throughout core, and particularly not in important, more prominent areas like The Loop of core themes. Several other prominent open source projects follow the same guidelines (ex [https://drupal.org/node/318 Drupal] etc etc). * Save users time learning both systems. Currently, if a user looks at The Loop, they learn endif. If they then proceed to other template files of core themes, or to plugin files, they then need to learn brackets. Making one way the Core's preferred method would cut the amount of time down for a new developer to learn the control logic (eliminate the need to learn endif). The attached patch/diff replaces all if-endif usages with braces in 2010, 2011, 2012, and 2013. ",chriscct7 Next Release,24478,The `theme_action_links` filter passes different arguments in different places.,ryan,Themes,3.1,normal,normal,3.7,defect (bug),closed,needs-codex,2013-06-01T16:45:54Z,2013-08-16T15:46:08Z,"Since r20029 at least, there has been an inconsistency in how core uses the `theme_action_links` filter. Ordinarily, it's used like this: http://core.trac.wordpress.org/browser/trunk/wp-admin/includes/class-wp-themes-list-table.php#L151 `$actions = apply_filters( 'theme_action_links', $actions, $theme );` with $theme being a WP_Theme object. However, in the Multi Site theme admin panel, it's used like this: http://core.trac.wordpress.org/browser/trunk/wp-admin/includes/class-wp-ms-themes-list-table.php#L287 `$actions = apply_filters( 'theme_action_links', array_filter( $actions ), $stylesheet, $theme, $context );` which means that for any module to successfully function in both contexts, it needs to do the following: {{{ function theme_action_links_filter( $actions, $theme, $ms_theme = null ) { if ( is_a( $ms_theme, 'WP_Theme' ) ) { $theme = $ms_theme; } // stuff with $theme return $actions; } }}} as can be seen in this changeset for a practical implementation: http://plugins.trac.wordpress.org/changeset/721178 If we're using a filter in core, I feel that we should be consistent with what sequence parameters are being passed to it, or at least leave a comment to devs giving them a heads up that they need to account for the other sequence.",georgestephanis Next Release,19906,Quicktags docs recommend code causing JS error: Uncaught ReferenceError: QTags is not defined,,Inline Docs,3.3.1,normal,trivial,,enhancement,closed,needs-codex,2012-01-27T01:05:44Z,2013-08-15T23:57:57Z," Right now the docs for qt.addbutton in quicktags.dev.js have the following text: {{{ * If you are echoing JS directly from PHP, * use add_action( 'admin_print_footer_scripts', 'output_my_js', 100 ) or add_action( 'wp_footer', 'output_my_js', 100 ) }}} This works, but if you add the QTags.addButton() calls on those hooks then they will cause JS errors on any screen without an editor: {{{Uncaught ReferenceError: QTags is not defined}}} The issue is avoided if you use the other option, enqueuing a script dependent on 'quicktags', but that is a lot more work and forces all pages in the admin to load the quicktags script unnecessarily. Maybe there is some way to magically make calling QTags.addbutton() safe no matter what, but I think at minimum we need to add a note to the PHPdoc about checking QTags before using it, as that solves the problem pretty simply: {{{ if ( typeof QTags != 'undefined' ) { QTags.addButton( 'gv_translation', 'translation', '
', '