__group__,ticket,summary,owner,component,_version,priority,severity,milestone,type,_status,workflow,_created,modified,_description,_reporter
Future Releases,32802,Update Masonry (v3.3.0) & imagesLoaded (v3.1.8) package,,External Libraries,trunk,normal,normal,Awaiting Review,enhancement,new,needs-codex,2015-06-27T00:34:12Z,2015-06-29T23:12:36Z,"Masonry should be updated to version 3.3.0. The current version in use is v3.1.2.
Also I removed the deprecated package jquery.masonry.js. If you still want to support ''jquery-masonry'' as handler, you could also link to the version v3.3.0. This version supports both native & jquery style. See also:
http://masonry.desandro.com/#initialize-with-jquery
Additionally I splitted imagesLoaded from masonry package & updated from v3.1.4 to v3.1.8. Isotope and masonry don't ship it by default. There are also theme/plugin-developers, which want to use imagesLoaded with isotope or other scripts/libraries or may just masonry withouth imagesLoaded (e.g. because it's buggy with the src-set attr & ff). They should have the opinion to load that lib without initializing masonry or the other way.
PS: jQuery should also be updated to v2.1.4. If you want I can create another patch :-)
PS²: With the attached patch it seems I cannot remove following file: /wp-includes/js/jquery/jquery.masonry.min.js",Ninos Ego
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,2015-06-22T21:01:54Z,"
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
Next Release,22314,Add singular.php to template hierarchy,jorbin,Themes,3.4.2,normal,normal,4.3,enhancement,closed,needs-codex,2012-10-30T15:04:24Z,2015-06-18T19:00:10Z,"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,23165,Admin validation errors on form nonce element IDs (_wpnonce),,Security,,normal,normal,Awaiting Review,enhancement,new,needs-codex,2013-01-10T02:25:17Z,2015-05-27T19:37:10Z,"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
Future Releases,30128,Allow to use associative arrays beside indexed arrays in wp_mail $headers,,Mail,2.3,normal,normal,Awaiting Review,enhancement,new,needs-codex,2014-10-27T21:15:12Z,2015-04-30T21:57:55Z,"eg:
{{{
$headers = [
'From' => 'Me Myself ',
'Cc' => 'John Q Codex ',
];
}}}
beside:
{{{
$headers = [
'From: Me Myself ',
'Cc: John Q Codex ',
];
}}}
and also (because why not):
{{{
$headers = [
'From' => 'Me Myself ',
'Cc' => [
'John Q Codex ',
'iluvwp@wordpress.org',
],
];
}}}",marsjaninzmarsa
Next Release,31174,"The get_terms() argument ""fields"" renders ""get_terms_fields"" & ""terms_clauses"" filter callbacks useless",DrewAPicture,Taxonomy,4.1,normal,normal,4.2,defect (bug),closed,needs-codex,2015-01-29T10:58:24Z,2015-03-20T20:10:22Z,"The `get_terms( $tax, [ args ] );` function accepts an argument named `fields`. This allows to chose which columns should be fetched from either the `wp_terms` or `wp_term_taxonomy` table. Example:
{{{
$terms = get_terms( 'example_tax', [ 'fields' => 'names', ] );
var_dump( $names );
/* Result:
array (size=1)
0 => string 'Code Review' (length=11)
*/
}}}
In this case, the resulting query inside the function would be the following:
{{{
SELECT t.term_id, tt.parent, tt.count, t.name
FROM wp_terms AS t
INNER JOIN wp_term_taxonomy AS tt
ON t.term_id = tt.term_id
WHERE tt.taxonomy IN ('project_type')
ORDER BY t.name ASC
}}}
In fact, `fields` does not really any combination of fields, but allows to chose from a list:
* `all` : `$selects = array( 't.*', 'tt.*' )`
* `ids` : `$selects = array( 't.term_id', 'tt.parent', 'tt.count' )`
* `id=>parent` : `$selects = array( 't.term_id', 'tt.parent', 'tt.count' )` (the same as above)
* `names` : `$selects = array( 't.term_id', 'tt.parent', 'tt.count', 't.name' )`
* `count` : `$selects = array( 'COUNT(*)' )`
* `id=>name` : `$selects = array( 't.term_id', 't.name', 'tt.count' )`
* `id=>slug` : `$selects = array( 't.term_id', 't.slug', 'tt.count' )`
After this preselection ran, there are two filters available to alter the list:
{{{
$fields = implode( ', ', apply_filters( 'get_terms_fields', $selects, $args, $taxonomies ) );
$pieces = array( 'fields', 'join', 'where', 'orderby', 'order', 'limits' );
}}}
But no matter if you attached an filter to either of those or not: The result stays the same. This is due to the following filtering done in a final loop through all results:
* `ids` : `$_terms[] = $term->term_id`
* `id=>parent` : `$_terms[$term->term_id] = $term->parent`
* `names` : `$_terms[] = $term->name`
* `id=>name` : `$_terms[$term->term_id] = $term->name`
* `id=>slug` : `$_terms[$term->term_id] = $term->slug`
And that renders callbacks to both attached filters useless. The only cases where this does not happen are the argument values `all` and `count`.
I'm not sure if this should be called an ""undocumented feature"" or if this actually needs a patch. I'm in for later if there is support for changing this awkward behavior as this is not clear until one jumps and dumps in core.
Proposed fix: Only run the final filter-loop if ...
{{{
if ( ! (
has_filter( 'get_terms_fields' ) or has_filter( 'terms_clauses' )
) )
// do final filtering
}}}",F J Kaiser
Future Releases,14254,update_meta_cache fails; query too large?,,Cache API,2.9.2,normal,normal,Future Release,defect (bug),reopened,needs-codex,2010-07-09T19:49:22Z,2015-01-22T20:33:13Z,"In the file meta.php, around line 183 in the 'update_meta_cache()' function, it tries to do a query but I noticed this can fail (ie. crash wordpress) if there are too many post id's in the query.
The function is being called from query_posts(), with 'posts_per_page' set to -1.
An example query that crashed it:
{{{
SELECT post_id, meta_key, meta_value FROM wp_postmeta WHERE post_id IN (1009,1006,989,933,902,860,859,858,857,793,838,837,836,827,825,310,780,777,776,775,774,773,770,763,760,759,758,757,728,756,755,754,753,752,751,750,748,746,
732,736,729,726,725,724,723,722,720,719,717,716,715,710,709,503,692,289,625,268,593,583,582,332,32,30,28,26,24,22)
}}}
Maybe there is some limit associated with queries of this type internal to wordpress, as this query works fine in phpMySql.
Apologies if this is already reported or irrelevant in 3.0!
",newpixel
Next Release,22400,"Remove all, or at least most, uses of extract() within WordPress",,General,3.4.2,normal,normal,4.0,enhancement,closed,needs-codex,2012-11-09T22:47:37Z,2015-01-22T04:48:24Z,"`extract()` is a terrible function that makes code harder to debug and harder to understand. We should discourage it's use and remove all of our uses of it.
Joseph Scott has [http://josephscott.org/archives/2009/02/i-dont-like-phps-extract-function/ a good write-up of why it's bad].",Viper007Bond
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-11-06T13:09:42Z,"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,29069,"Proposal: wp-pluggable.php patch to send email through SMTP, not mail()",,Mail,3.9.1,normal,normal,Awaiting Review,enhancement,new,needs-codex,2014-07-30T10:21:00Z,2014-10-22T17:38:31Z,"Hereby I provide you with a patch to WordPress 3.9.1's wp-includes/pluggable.php file, to enable the use of SMTP as email option. This patch provides several advantages:
* it allows website owners to send email thought their ISP's SMTP server, instead of using the mail() function and localhost.
* TLS and SSL encrypted connections are supported, as are alternative SMTP ports
And all this makes it even possible to mail though Gmail's SMTP server.
I dediced to put the email configuration in wp-config.php, so there is a patch for that file too.
The story beind the patches is: I found it kinda strange the WordPress core lacks this functionality out-of-the-box, now more and more hosting providers require to use SMTP and TLS for sending mail from websites. Not to mention beter privacy protection due to the SMTP pipe being encrypted. The in WordPress included PHPMailer version supports these options by default.
The patches are open for improvement.
Regards,
Jan,",JanR
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,2014-10-20T17:40:06Z,"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,28092,Ability to filter or remove error codes from WP_Error class,kovshenin,General,2.1,normal,normal,4.1,enhancement,closed,needs-codex,2014-05-01T14:23:47Z,2014-10-08T07:11:10Z,"It would be very helpful if the [https://github.com/WordPress/WordPress/blob/master/wp-includes/class-wp-error.php WP_Error class] would have a `remove` or adjusted `add` function. There is currently no way to filter or overwrite the error messages that come up. Specific messages can't even be targeted via CSS to hide them.
Here is an example of what could be added to the class:
{{{
function remove($code) {
if ( array_key_exists( $code, $this->errors ) )
unset($this->errors[$code]);
}
}}}
Alternatively (and preferentially), the `add` function could omit the ability to add multiple errors with the same ""error code"" so then they could simply be overwritten. (What is the reasoning for allowing multiple errors with the same error code anyway?)
{{{
function add($code, $message, $data = '') {
$this->errors[$code] = $message;
if ( ! empty($data) )
$this->error_data[$code] = $data;
}
}}}
Finally, one other option would be to add maybe `` around the error messages. The messages could then be hidden by CSS if needed. This is probably the lesser of these ideas, though.",AdamCapriola
Next Release,24861,edit_form_before_title,helen,General,,normal,trivial,3.7,enhancement,closed,needs-codex,2013-07-28T21:59:49Z,2014-10-02T22:42:37Z,"Add in a hook before the edit form title similar to edit_form_after_title, except before.
'''USE CASE'''
Custom post formats UI used the post format options above the title since certain formats do not use the title. For example, an aside is typically styled without a title.
There is no current hook to address this situation.",yurivictor
Future Releases,19012,get_ID and the_ID should accept $id as a parameter,,"Posts, Post Types",3.3,normal,normal,Future Release,enhancement,reviewing,needs-codex,2011-10-20T04:56:28Z,2014-07-11T13:25:05Z,"I see throughout the WordPress code as well as throughout many plugins and themes that {{{get_ID()}}} is often accompanied by a test to see if an ID had been passed. It would be a harmless but extremely useful update to simply allow {{{get_ID()}}} and {{{the_ID()}}} to accept an optional $id and pass it through if it's numerical.
I've already gone ahead and created the patch (attached)",peterchester
Future Releases,24815,get_the_post_thumbnail() fetches full sized image if 'post-thumbnail' custom size not defined in theme,,Media,2.9,normal,normal,Awaiting Review,defect (bug),new,needs-codex,2013-07-22T09:43:42Z,2014-06-23T16:20:31Z,"In wp-includes/post-thumbnail-template.php the $size default value is set as 'post-thumbnail' in the following function:
- get_the_post_thumbnail()
'''Expected behaviour'''
Expected behaviour would be to return the image at 'post-thumbnail' dimensions - however, if this is not set in the theme via:
- set_post_thumbnail_size() function
- add_image_size() function
it returns the full sized sized image begin displayed. I'd expect this to return the image at standard 'thumbnail' size, as some people will just add add_theme_support( 'post-thumbnails' ) and not set (or even need) custom dimensions.
'''Proposal and patch'''
$size default value should default back to 'thumbnail' for normal expected function behaviour if 'post-thumbnail' specific dimensions have not been set.
I'm not sure if it would be more efficient to test against the global variable that holds these values, or use get_intermediate_image_sizes() as I've used in the patch attached - 2nd opinion please?",Jonnyauk
Next Release,17657,Shortcode regex doesn't allow for hyphens in shortcode name,koopersmith,Shortcodes,2.9.2,normal,normal,3.5,defect (bug),closed,needs-codex,2011-06-02T04:55:21Z,2014-05-02T10:15:10Z,"I found an issue where I wanted to use a string in a post for specifying a lightbox style ""album"" that looked like a shortcode.
The code I was using looked something like:
{{{
Image
}}}
Another plugin was installed that had registered a shortcode for ""album"". due to the '\b' in the regex the '-' is seen as the ending delimiter in the shortcode name, and the callback for 'album' was processed at this point.
I of course corrected the issue by prefixing the ""album"" name with a unique string, however I am thinking that we should perhaps update the regex so that some common characters often seen in strings for readability without spaces.
Plugin code to test:
{{{
add_shortcode('broken', 'broken');
function broken() {
return 'Running the broken shortcode';
}
}}}
and then in a post:
{{{
[broken-shortcode]
}}}",sivel
Next Release,26697,HTML5 Galleries,nacin,Gallery,3.8,normal,normal,3.9,enhancement,closed,needs-codex,2013-12-21T00:42:55Z,2014-04-15T20:19: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,23792,Disallow moving of locked posts to the trash,,Administration,3.6,normal,normal,3.6,defect (bug),closed,needs-codex,2013-03-15T22:29:01Z,2014-04-04T05:24:01Z,"Currently we don't check post locks when bulk moving posts to the trash on the All Posts screen and in wp_ajax_trash_post(). A post locked check was added when moving to the trash from the New/Edit Post screen in http://core.trac.wordpress.org/changeset/23661#file5.
The new UI on the All Posts screen prevents selecting a locked post for bulk actions, but we still should make sure a post is not locked right before moving it to the trash.",azaozz
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
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,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,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', '