, and as a result cannot be styled using the theme's CSS file to differentiate it from the blogger's comments.
I've posted on my own blog [http://aldred.org/blog/blog/2013/01/24/improving-press-this-in-wordpress/ this post] describing how I've made a fairly simple change to insert div tags round the quoted content.
Ideally the div would also wrap the image, but that was beyond me!
Can this be looked at as an enhancement?",daldred
Future Releases,23278,Spin PressThis off into a plugin,,Press This,3.5,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2013-01-23T21:43:23Z,2013-01-24T12:25:15Z,"PressThis has really been the ignored stepchild of WordPress for quite a while now. I'd like to propose that we spin it out of core and into a plugin (either installable via the plugin repo or bundled with wp, whatever)
Several things to consider:
* Backwards Compatability: What happens when someone upgrades then uses an old bookmarklet? I'd suggest either autoinstalling, or prompting them immediately to install the plugin through a special catch in core.
* Press This doesn't have an includes file in wp-admin/includes that other plugins could pull in, so extracting it is very unlikely to break plugins that could be manually pulling that in.
* This will make it easier to upgrade in plugin form, and let other people have an easier time hijacking it to use their own implementations.
In today's IRC chat, as sabreuse pointed out, everyone seemed to either favor spinning it out into a plugin, or didn't have much of an opinion. If you really want it in core, please speak up! I'd love to hear your reasons.
I'm willing to throw a massive chunk of time at this to make it work, if that's the decision that we decide to move forward with.",georgestephanis
Future Releases,19471,Automatically support custom post types in category and tag archives,,Query,3.0,normal,normal,Awaiting Review,defect (bug),new,reporter-feedback,2011-12-07T20:56:03Z,2012-11-22T03:12:48Z,"I dealt with a plugin recently that had the following code in it:
{{{
#!php
set('post_type',$post_type);
return $query;
}
}
?>
}}}
The goal was simply to allow their custom post type that was connected to category and tag taxonomies to have its entries rendered on category and tag archive pages. Digging around, it seems that [http://wordpress.org/support/topic/custom-post-type-tagscategories-archive-page/ many people] are using a solution like this.
Of course, the code has problems in that it misses home pages and will mess with all other queries on the affected page (such as menus). Looking further in the thread, it seems people tried fixing up these limitations with code such as the following:
{{{
#!php
query_vars['suppress_filters'] ) ) {
$post_type = get_query_var('post_type');
if($post_type)
$post_type = $post_type;
else
$post_type = array('post','articles','nav_menu_item');
$query->set('post_type',$post_type);
return $query;
}
}
?>
}}}
While this may address the known issues, I don't see it as a solid solution in any way. Here are just couple of the primary issues I see with such a solution:
* Things are very likely to change in the future (such as the possibility of adding additional core taxonomies or query modifications), causing the ever-increasing number of plugins that use custom post types to constantly have bugs.
* Since the WP_Query->set function replaces values rather than merging them, even the ""fixed"" version of the code will cause plugin conflicts as multiple instances of this solution will systematically undo the modification done by each previous instance. Sure, the code could be improved to cover this, but the odds of getting everyone to fix their code are not good.
To me, this is something that was an oversight in the development of custom post types. I can think of no reason why this should not be automatically handled. The dashboard properly shows post counts for categories and tags that include the custom post types, but the query simply fails to handle this. It needs to be fixed.
Testing things out, I noticed that custom taxonomies did not have this problem at all. Looking at wp-includes/query.php, I saw the following:
{{{
#!php
is_tax ) {
if ( empty($post_type) ) {
$post_type = 'any';
$post_status_join = true;
} elseif ( in_array('attachment', (array) $post_type) ) {
$post_status_join = true;
}
}
?>
}}}
This is what allows custom taxonomy archives to work properly without having to filter the query. I've always felt that is_tax should cover categories and tags as well, but what is done is done. So, I propose that this section is modified to include a check for is_category and is_tag. Example:
{{{
#!php
is_tax || $this->is_category || $this->is_tag ) {
if ( empty($post_type) ) {
$post_type = 'any';
$post_status_join = true;
} elseif ( in_array('attachment', (array) $post_type) ) {
$post_status_join = true;
}
}
?>
}}}
This allows for things to ""just work"" as people would expect. Of course, plugins would have to remove their filter in order to avoid plugin conflicts as the post_type query arg would still be set and will not be changed automatically to ""any"". This is as it should be though, so people will just have to be convinced over time to remove the modification from their plugins.
Attached is the proposed patch.",chrisbliss18
Future Releases,15551,Custom post type pagination redirect,,Query,3.1,normal,normal,Awaiting Review,defect (bug),reopened,reporter-feedback,2010-11-23T21:50:06Z,2012-02-25T11:23:57Z,"We seem to be having a problem with a redirect on a custom post page (e.g., http://www.example.com/show/slug/).
Everything on the page shows correctly. The template pulls in posts with the following query:
{{{
'show', 'meta_value' => $show->ID, 'paged' => get_query_var('paged'), 'caller_get_posts' => true)); ?>
}}}
After the posts we display pagination links (e.g., http://www.example.com/show/slug/page/2/). In our rewrite rules, we include the following rule which should handle these URLs:
{{{
'show/([^/]+)/page/([0-9]{1,})/?$' => 'index.php?show=$matches[1]&paged=$matches[2]',
}}}
Instead of the page displaying and allowing us to pull in the second page of posts, the browser is being redirected back to the original page (http://www.example.com/show/slug/) with a 301. I see that this is happening inside the redirect_canonical function. The following code in wp-includes/canonical.php replaces /page/2/ with / causing the redirect:
{{{
// paging and feeds
if ( get_query_var('paged') || is_feed() || get_query_var('cpage') ) {
if ( !$redirect_url )
$redirect_url = $requested_url;
$paged_redirect = @parse_url($redirect_url);
while ( preg_match( ""#/$wp_rewrite->pagination_base/?[0-9]+?(/+)?$#"", $paged_redirect['path'] ) || preg_match( '#/(comments/?)?(feed|rss|rdf|atom|rss2)(/+)?$#', $paged_redirect['path'] ) || preg_match( '#/comment-page-[0-9]+(/+)?$#', $paged_redirect['path'] ) ) {
// Strip off paging and feed
$paged_redirect['path'] = preg_replace(""#/$wp_rewrite->pagination_base/?[0-9]+?(/+)?$#"", '/', $paged_redirect['path']); // strip off any existing paging
$paged_redirect['path'] = preg_replace('#/(comments/?)?(feed|rss2?|rdf|atom)(/+|$)#', '/', $paged_redirect['path']); // strip off feed endings
$paged_redirect['path'] = preg_replace('#/comment-page-[0-9]+?(/+)?$#', '/', $paged_redirect['path']); // strip off any existing comment paging
}
}}}",cbsad
Future Releases,23475,Feed querystring not limiting returned posts by post type when also using category,,Query,3.5.1,normal,normal,Awaiting Review,defect (bug),new,,2013-02-14T20:15:44Z,2013-02-14T20:15:44Z,"I set up an example to demonstrate what's happening: http://demo.jarrodpyper.com/feed/?post_type=syndicated&category_name=craft
This feed *should* only return the one post on my site, ""test syndicate"" that is in the ""Syndicated"" post type and also in the ""craft"" category. Instead the post titled ""post"" of the default ""post"" post_type is being returned in the feed as well because it is also in the ""craft"" category.
This works correctly within a normal page using query_posts, which I thought would be similar if not the same as the way the querystring was handled when put into the URL.
Not sure if ""Query"" or ""Feed"" is the more relevant component keyword to use here.",jpyper
Future Releases,20011,Filtering posts for plugins that do not call posts to be filtered,,Query,3.3.1,normal,normal,Awaiting Review,defect (bug),new,reporter-feedback,2012-02-10T15:35:02Z,2012-02-10T15:43:59Z,"In Query.php Line: 2745
Multisite Installation (3.3.1) While using Google XML Sitemaps Version 4.0beta4
Change:
{{{
// Always sanitize
foreach ( $this->posts as $i => $post ) {
$this->posts[$i] = sanitize_post( $post, 'raw' );
}
}}}
To:
{{{
// Always sanitize
if ($this->post_count > 0) {
foreach ( $this->posts as $i => $post ) {
$this->posts[$i] = sanitize_post( $post, 'raw' );
}
}}}
",jroakes
Future Releases,23826,Funky conditional tags for posts archive,,Query,trunk,normal,normal,Awaiting Review,defect (bug),new,,2013-03-20T13:51:22Z,2013-04-04T04:14:12Z,"If a WordPress install is set to ""Front page displays ... Your latest post"", then some funky conditional tags are set. Of interest here are:
{{{ [""is_home""]=> bool(true) }}}
Sure, makes sense.
{{{ [""is_post_type_archive""]=> bool(false) }}}
Erm, what? Isn't this the post type archive for the posts post type?
{{{ [""is_archive""]=> bool(false) }}}
Isn't this also an archive?
This means is_post_type_archive( 'post' ); doesn't work anywhere.
I also attempted creating a ""posts page"" for blog posts, and got the same results.",ericlewis
Future Releases,23309,Not all WP_Query::query_vars get updated during WP_Query::get_posts(),,Query,,normal,normal,Awaiting Review,defect (bug),new,,2013-01-28T15:40:56Z,2013-01-28T19:51:54Z,"There is a lot of logic within the WP_Query::get_posts() method that fills in missing query vars with defaults and manipulates others based on the rest of the query. However, some of the final states for many of the variables aren't updated in the WP_Query::query_vars array. For example, the post type is lost as a local variable and post_status is used for building compiling mysql expressions, but never directly updated.
The result is that any plugins that want to recreate the query for another system, (ie, an external search provider) must directly copy much of the business logic that WP_Query::get_posts() has embedded in it in order to fill in for the incomplete query_var array.
",prettyboymp
Future Releases,22043,Undocumented default of post_type parameter to WP_Query with taxonomy queries,,Query,,normal,normal,Awaiting Review,defect (bug),new,,2012-09-28T19:24:35Z,2012-11-01T11:53:41Z,"post_type parameter default depends on the is_tax attribute. This is not documented here: http://codex.wordpress.org/Class_Reference/WP_Query#Type_.26_Status_Parameters
If is_tax is true, and post_type is not provided, the default of 'any' kicks in, and if is_tax is not set, the default of 'post' kicks in.
Either it is a bug, or perhaps just the documentation needs to be updated.
Please let me know what you think.
Thank you for sharing your software.",dbernar1
Future Releases,23849,Unexpected results when running WP_User_Query with role and meta_query,,Query,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2013-03-22T19:48:50Z,2013-04-24T00:42:11Z,"There appears to be a couple of bugs in WP_User_Query when doing a role query and adding additional meta_query options (especially when relation is set to ""OR"").
This code:
{{{
$args = array(
'role' => 'Author',
'number' => 100,
'offset' => 0,
'meta_query' => array(
'relation' => 'OR',
array(
'key' => '_my_key',
'compare' => 'NOT EXISTS',
),
array(
'key' => '_my_key',
'value' => 'off',
'compare' => 'NOT LIKE',
),
),
);
$users = new WP_User_Query( $args );
}}}
Expected results:
Any author where _my_key either does not exist or if it does exists is set to ""off""
Returned results:
All authors and/or all users with _my_key set.
The above generates this SQL:
{{{
SELECT DISTINCT SQL_CALC_FOUND_ROWS wp_users.*
FROM wp_users
INNER JOIN wp_usermeta ON wp_users.ID = wp_usermeta.user_id
INNER JOIN wp_usermeta AS mt1 ON (wp_users.ID = mt1.user_id)
INNER JOIN wp_usermeta AS mt2 ON (wp_users.ID = mt2.user_id)
WHERE 1=1
AND (wp_usermeta.meta_key = '_pigeonpack_subscription'
OR (mt1.meta_key = '_pigeonpack_subscription' AND CAST(mt1.meta_value AS CHAR) NOT LIKE '%off%')
OR (mt2.meta_key = 'wp_capabilities' AND CAST(mt2.meta_value AS CHAR) LIKE '%\""Author\""%') )
ORDER BY user_login ASC LIMIT 100
}}}
This seems like a bug to me, the ""Author"" meta should not be modified by the relation => 'OR' argument and thus should not be included in the other meta query statement. Further, the NOT EXISTS isn't a true NOT EXISTS statement. In fact, I'm not even sure why the NOT EXISTS statement looks the way it does. I haven't had too much time to look into this any more in depth.
I tested this in WP3.5 and Trunk
",layotte
Future Releases,22995,WP_Query Category stuff blank page,,Query,3.5,normal,normal,Awaiting Review,defect (bug),new,,2012-12-18T18:59:18Z,2012-12-19T23:48:54Z,"hey there,
maybe I have found a bug. Sending following parameter to the WP Query (with my theme via ''?s=test%cat=1234'') you should get a blank page. At first I thought it was a bug of mine, but deleting following line in /wp-includes/query.php:1746 fixes the problem.
{{{
$q['category__in'][] = $cat;
}}}
So I think there's a bug in the query function...
Thanks,
Ninos",Ninos Ego
Future Releases,13365,"WP_Query, author_name, and sticky posts",ryan,Query,2.9.2,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2010-05-12T06:09:42Z,2012-08-30T00:17:35Z,"I have a template which is being used as my front page on WP 2.9.2. In this template I setup my loop with the following code:
{{{
$postresults = new WP_Query();
$postresults->query(""author_name=frontpage&post_types=post&post_status=publish"");
while($postresults->have_posts()) { $postresults->the_post(); ?>
// etc...
}}}
I am not using the ""caller_get_posts=1"" option, but my sticky posts are still showing up in order with other posts rather than at the beginning. If I remove the ""author_name=frontpage"" the sticky posts will move back to the first items, however I am stuck with posts by authors I do not want. Using ""author=2"" results in the same behavior as using ""author_name"".",eryanv
Future Releases,21790,When set a static front page WP main query isn't set correctly,,Query,3.4.1,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2012-09-04T13:50:26Z,2012-09-05T16:00:06Z,"In my project I use on several places pre_get_posts filter. When setting a static frontpage and blog page I get several notices on my screen. When I var_dump the main query the only value that is set it the page_id.
Even the post_type isn't set.",markoheijnen
Future Releases,24142,Zero value for posts_per_page value in wp_query custom instance and for 'Blog pages show at most' option,,Query,,normal,normal,Awaiting Review,defect (bug),new,needs-docs,2013-04-20T09:04:16Z,2013-04-20T12:55:34Z,"To show no posts if the posts_per_page value is 0.
Currently for custom instances of wp_query, if the value is 0 then this is changed with the value from posts_per_page option from the database. ""get_options( 'posts_per_page' )""
For home page if we set value 0 on the settings page, in wp-admin/options-reading.php, after the saves are changed, this value is changed to 1.
I think for both cases if the posts per page value is 0 then no posts should not display.
",alexvorn2
Future Releases,17200,[Search] Posts containing search terms missing from Search Results,,Query,3.1,normal,major,Awaiting Review,defect (bug),new,reporter-feedback,2011-04-20T21:59:08Z,2011-04-21T08:27:25Z,"I tried to perform a search based on some text within [http://www.webfoundation.org/2010/03/web-foundation-tim-steve-featured-on-cnn-segment/ this article] on my site, specifically “Jason Sanchez”, but got no results.
Furthermore, when I [http://www.webfoundation.org/?s=cnn search for ""CNN""] (for example), only two entries come back:
* [http://www.webfoundation.org/2010/01/importance-of-web-in-haiti-earthquake-relief/ The Importance of the Web to Help Disaster Relief in Haiti]
* [http://www.webfoundation.org/about/boards/switzerland/iqbal-z-quadir/ Iqbal Z. Quadir]
…but not [http://www.webfoundation.org/2010/03/web-foundation-tim-steve-featured-on-cnn-segment/ this one], even though it should.
Other searches had similar problems (e.g., searching for ""video"", etc.). !WordPress' built-in search seems to have some serious flaws in its search algorithm. I'm hoping you can resolve this in an upcoming release.",newmediarts
Future Releases,20323,update_post_caches causes time-out on large queries if cache_results flag not set,,Query,3.3.1,normal,normal,Awaiting Review,defect (bug),new,reporter-feedback,2012-03-29T12:25:56Z,2012-10-31T23:18:05Z,"I ran into this problem when debugging why the Advanced Custom Fields plugin's option screen was timing out on my site. I have over 8000 items in my wp_posts table, and the plugin pulls back every post to populate a dropdown (I plan on bringing up this issue with the plugin author)
I was relieved to find out that it wasn't actually the query that was choking, (for a moment I thought mysql was horribly misconfigured) but actually the update_post_caches function.
I realize that the cache_results flag was added to avoid this issue, but it occurs to me that many plugin developers will not foresee sites with as much content as mine.
My suggestion is this: Place a ""cache_threshold"" option in the Wordpress settings... make the default something reasonable like 20 (or maybe even ignore this option all together and grab the value from the posts_per_page option, as set on the admin screen.. it's important it come from the admin screen and not the query options because in the case I encountered it, the posts per page option in the query was set to -1). If the cache_results flag is not set, check after the initial database query is completed to grab the number of returned posts... if it's more than the cache_threshold, then don't call update_post_caches.
This will increase the stability of the core, and prevent plugins from accidentally breaking things with unreasonable queries on large sites.
Sorry if anything in this ticket doesn't make sense... it's early and I haven't had my coffee yet.
",bytesmasher
Future Releases,21660,'p' arg should work with custom post types,,Query,,normal,normal,Awaiting Review,enhancement,reopened,,2012-08-22T15:27:49Z,2012-11-01T18:20:10Z,"Doing a query like following, where 42 is a custom post_type, will fail:
{{{
$query = new WP_Query( array( 'p' => 42 ) );
}}}
The resulting query looks like:
{{{
SELECT wp_posts.* FROM wp_posts WHERE 1=1 AND wp_posts.ID = 42 AND wp_posts.post_type = 'post' ORDER BY wp_posts.post_date DESC
}}}
This is because WP_Query forces the {{{post_type}}} arg to 'post' when it's not set. We should not force it when the {{{p}}} arg is set.",batmoo
Future Releases,20092,Add Exclude by Tag to Queries,,Query,,normal,normal,Awaiting Review,enhancement,new,,2012-02-21T23:36:35Z,2012-02-22T06:28:52Z,"Per scribu's instruction:
Category exclusion is already possible for feeds using a query string, tags should be the same.
'''Example:'''
http://domain.com?cat=news&tag=-featured&feed=rss2
Would equate to a feed of posts in the ""news"" category, not tagged ""featured"" and outputted via the RSS2 template.",iridox
Future Releases,23833,Add a unique ID or NAME to target queries .,,Query,,normal,normal,Awaiting Review,enhancement,new,,2013-03-21T03:03:43Z,2013-05-08T21:48:03Z,"I am not sure if this is enhancement or feature request .[[BR]]
wordpress allows us to change / filter queries with various methods , for example the pre_get_posts(). ( e.g. $query->set ($args) ).
But in today´s wp ecosystem, there are so many themes, plugins, widgets etc. that modify the query or add custom queries, that it had become very difficult to target a specific query, where The available conditions might not be enough. (is_admin, is_main_query etc.. )
The suggestion here is to add an identifier (ID or specific NAME) to a query , much like with textdomains or actions.
In this manner, targeting a query becomes a breeze something along the lines of
{{{
#!php
$query->set($query_id_or_name,$args)
}}}
Each developer has struggled one time or another with custom queries and with targeting 3rd party queries .
This feature / enhancement could potentially change all that by allowing a simple way to address custom queries .",krembo99
Future Releases,19802,Allow DECIMAL Precision in WP_Query Meta Queries,,Query,3.3.1,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2012-01-11T06:50:05Z,2012-01-11T11:42:34Z,"As of now, if we specify a precision for the DECIMAL type in WP_Query meta queries [e.g. DECIMAL(4,2)], the type is changed to CHAR. This transformation seems to happen here:
http://core.trac.wordpress.org/browser/tags/3.3.1/wp-includes/meta.php#L716
As a work around, we can add a filter to the `get_meta_sql` hook and manually change DECIMAL to DECIMAL(X,X) with a `str_replace`, but that seems pretty clumsy and it forces us to pick one level of precision for all meta queries.
As a solution, right above the line I have linked above, we could add a conditional that checks if the type starts with DECIMAL, and then uses a regex to check if the format for the precision is correct. Of course, another option would be to add a precision key to the meta query array like so:
{{{
array(
'key' => 'meta_key',
'value' => $value,
'type' => 'DECIMAL',
'compare' => '>',
'precision' => array( 4, 2 )
),
}}}
I apologize if this question has already been asked, or if I'm missing something obvious. But, to me it seems like the current system is a bit limiting. Thanks.",dominicp
Future Releases,19866,Allow specifications of any wp_posts field(s) in WP_Query,,Query,,normal,normal,Awaiting Review,enhancement,new,,2012-01-20T19:58:43Z,2013-04-30T18:04:13Z,"Hi guys, I'm considering writing a patch to be able to pull specific fields from a WP_Query but wanted to see if there was already something in the works on another ticket. I searched trac and hackers list (via its Google Group) and surprisingly didn't see anything.
Here's the current implementation which limits people to only querying for certain fields: wp-includes/query.php:2033
{{{
switch ( $q['fields'] ) {
case 'ids':
$fields = ""$wpdb->posts.ID"";
break;
case 'id=>parent':
$fields = ""$wpdb->posts.ID, $wpdb->posts.post_parent"";
break;
default:
$fields = ""$wpdb->posts.*"";
}
}}}
Stems from a situation where we needed all posts of a certain type -- potentially thousands -- but really only required post_title and ID fields, so didn't want all that memory overhead.
",bigdawggi
Future Releases,19631,Consider a doing_it_wrong call for query_posts(),,Query,,normal,minor,Awaiting Review,enhancement,new,,2011-12-21T11:58:14Z,2011-12-21T13:00:49Z,"The `query_posts()` function affects the main query, so things (like template conditionals) can break if plugins or themes use it without calling `wp_reset_query()` immediately afterwards.
Unless there is a situation I haven't considered, `query_posts()` shouldn't be used at all on requests where the main query is run (`query_posts()` of course has a use in situations like AJAX calls when the main query isn't run).
* For secondary loops, `get_posts()` or the `WP_Query()` class should be used.
* To modify the main query, there are hooks all over the place, such as 'request', 'parse_request', 'parse_query', and 'pre_get_posts', in addition to the SQL filters such as 'posts_where', 'posts_join', etc.
Maybe `doing_it_wrong()` should be called if `query_posts()` is used after the main query is run, with pointers toward a relevant Codex article on secondary loops or filtering the main loop.
",johnbillion
Future Releases,24245,Convert category__and query into category__in when only one category passed in,,Query,,normal,normal,Awaiting Review,enhancement,new,,2013-05-02T07:03:30Z,2013-05-02T07:03:30Z,"If a {{{category__and}}} query gets only one term passed in, it still builds out the complex query required for the {{{AND}}} lookup, which can be pretty expensive (#16706).
We should be smarter and automatically convert the query into a {{{category__in}}} when {{{category__and}}} only gets passed in one category.",batmoo
Future Releases,19243,"Introduce WP_Query::exists(), or have WP_Query::get() return false for non-existence",,Query,,normal,normal,Awaiting Review,enhancement,new,,2011-11-14T21:18:09Z,2012-03-28T18:17:23Z,"See [ticket:15178#comment:8].
A query variable for an an endpoint with no value (/blah/, rather than /feed/rss2/) is set, but it is empty. WP_Query::get() returns an empty string when no QV is set, though, so you need to dig into WP_Query::query_vars directly. This is annoying. It should return false when the QV is not existence.
This should be rather backwards compatible, but WP_Query::exists() may be desired (also, or instead of). In this case, it won't work for core query vars, as _fill_query_vars() clears these, rather than unsets them. We should either change how _fill_query_vars() works, or something.",nacin
Future Releases,17551,Need a post_id query that works regardless of post_type.,,Query,3.2,normal,normal,Awaiting Review,enhancement,new,,2011-05-24T20:25:46Z,2011-05-25T13:27:37Z,"The query parameter `p` works for posts and pages but not attachments. When the ID in question refers to an attachment, the result is a 404. Why?
When generating a stats report for a remote blog, the WordPress.com Stats/Jetpack system at first only knows the post_id of a new post. Eventually it learns the correct permalink by querying the blog, but until then its best guess at a working link is `?p=$post_id`.
This problem (and possibly others) would be most easily solved by a core query parameter that can find any post_type by its ID alone. Unless there is a reason to limit `p`, I propose we make `p` work for all post_types. If there is a reason, how about a new public query parameter `post_id`?",andy
Future Releases,21687,Need to be able to float sticky posts to top in custom queries,,Query,3.4,normal,normal,Awaiting Review,enhancement,new,,2012-08-25T16:12:08Z,2012-08-25T16:12:08Z,"Currently sticky posts are only floated to the top of the loop when on an index page (blog/home). When making a new WP_Query for posts as a secondary loop on a ""page"" page (whilst developing shortcode) sticky posts only appear in the natural date order because my query does not have the is_home flag.
My proposal would be to add a new parameter/argument to the WP_Query class, either connected to 'orderby' or 'ignore_sticky' parameters, stating whether sticky posts should have order 'float', 'natural', 'exclude' (it seems that the mechanism for excluding sticky posts from the loop is a bit clunky, although well documented; this would simplify it). Default behaviour can be retained, the query on the index page can use the 'float' option and themes/plugins can call it in custom queries if required.
Alternatively, the sticky sorting could be moved to a separate function and called via an action, so developers can use the same function (or build their own) in their custom queries. This is how I have my current workaround, running a filter on 'posts_results' having copied code for floating stickies from core. It seems a shame to be be duplicating code though, especially when it should be an option available in custom queries.",ChemicalSailor
Future Releases,19653,Order by meta field forces ignore of null records,,Query,,normal,normal,Awaiting Review,enhancement,new,,2011-12-23T15:11:45Z,2012-11-20T19:06:53Z,"When doing a sort on posts with a meta value, the way the SQL is currently generated in meta.php creates a condition where records that DO NOT have the queried meta value are excluded from the results. This may or may not be the desired behaviour, but we don't give developers the choice without resorting to custom queries or manual rewrites of large swathes of the $clauses array.
The issue: the way WP_Meta_Query->get_sql() creates the join on the meta key is by setting an inner join on wp_postmeta and then adding the key test to the where clause.
I would suggest writing an outer (left) join on wp_postmeta, with the key condition in the join. This would also eliminate any potential future ambiguity if, for example, you are sorting on one meta key but filtering on another, since the key condition would be within the join clause, not the where clause:
{{{
LEFT JOIN wp_postmeta ON wp_posts.ID = wp_postmeta.post_id AND wp_postmeta.meta_key = 'my_custom_field_name'
}}}
Related to ticket 18158 [http://core.trac.wordpress.org/ticket/18158] is the question of how we expose this to the developer in the query API.
{{{
'meta_key' => self::get_meta_key( 'my_custom_field_name' ),
'orderby' => 'meta_value',
'exclude_empty_meta' => false
}}}
If this gets any traction I would be happy to submit a patch.",tomauger
Future Releases,11950,Sticky Posts are too aggressive,,Query,2.9.1,normal,normal,Awaiting Review,enhancement,reopened,dev-feedback,2010-01-19T15:43:50Z,2011-12-19T03:19:07Z,"I don't think the default behavior should be to have sticky posts included every time a query_posts() is used. I realize you can set the 'caller_get_posts' argument to avoid sticky posts from being added, however having to do this everywhere becomes a burden.
What are your thoughts on having the WP class add 'include_sticky' var to the_query if it isn't already set and then not include the sticky posts by default?",prettyboymp
Future Releases,17199,Unintuitive tax query 'operator' values,,Query,,normal,normal,Awaiting Review,enhancement,new,,2011-04-20T21:52:00Z,2012-10-31T01:24:43Z,"Currently, the accepted values for the tax_query 'operator' arg are:
{{{AND}}}, {{{IN}}} and {{{NOT IN}}}.
It would be better if they were instead:
{{{AND}}}, {{{OR}}} and {{{NOT}}}.
which would be more intuitive and consistent with wp_list_filter().
Obviously, we would still have to keep backwards compatibility with the old values.",scribu
Future Releases,19728,WP_Query should constrict 'paged' to be within bounds of found_posts,,Query,,normal,normal,Awaiting Review,enhancement,new,,2012-01-03T20:16:45Z,2012-01-07T23:12:37Z,"I apologize in advanced if this has been reported before. My Trac search did not find anything pressingly relevant.
WP_Query allows the user to pass in a discrete value to use for the 'paged' parameter; however, often times this value will be dynamic rather than static (as in the programmer will have paged be the value of $_GET[ 'paged' ] or something similar).
The problem is, if you enter an absurdly large or small value for the paged parameter and it's out of bounds, it will just throw a 404 (or otherwise show that there are no posts matching the parameters). I propose that WP_Query automatically changes the paged value to be within the bounds of the returned number of pages.
For example, constrict paged to the following rules:
1 <= $paged <= $wp_query->max_num_pages (where $wp_query is whatever custom query is being used). If the user types in a page larger than the max, it uses the max instead. Conversely, if they type a page less than 1, it uses 1.
The only potential problem I see with this is if a user actually (for whatever reason) wanted a 404 to display when an invalid page was visisted. In this case, perhaps we can introduce a new option to WP_Query such as 'limit_to_bounds' => true?",Master Jake
Future Releases,19738,meta_query should check for wildcards when using LIKE operator,,Query,3.2,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2012-01-04T18:35:04Z,2013-04-16T00:24:10Z,"This seems intentional, but when using the LIKE operator in a meta query, the % wildcards are automatically added to the start and end of the value when generating the SQL.
I think a more robust way of doing this would be to only add said wildcards if one cannot be found within the value itself. ",ejdanderson
Future Releases,19859,"""Bulk Edit"" Missing The Ability To Edit Tags",gavinwye*,Quick/Bulk Edit,,normal,normal,Awaiting Review,enhancement,accepted,,2012-01-20T02:56:24Z,2012-12-20T00:41:06Z,"Though I can add, remove and edit ""categories,"" I cannot do such actions to ""tags"" inside of /wp-admin/edit.php
So basically, I'm interested in a ""bulk tag editing"" GUI for the WordPress admin.
===
I was hoping to find out the status of this feature (planned, not planned, etc) but it appears that no one has spoken about this feature on the WordPress Trac.
Is there any interest in adding this feature? And could the respondent please provide any details on why or why not?
Thank you for your time.",ademos
Future Releases,19392,Add auto-suggest support for all flat taxonomies in Bulk Edit.,,Quick/Bulk Edit,3.0,normal,normal,Awaiting Review,enhancement,new,early,2011-11-29T18:37:18Z,2011-11-29T18:58:48Z,"Auto-suggest in the Bulk Edit area for post_tag's was fixed in 3.3. Let's add support for all other non-hierarchy tax's in 3.4.
See [http://core.trac.wordpress.org/ticket/19176#comment:11 #19176] for more info.",scottbasgaard
Future Releases,21840,Add filter for taxonomies shown in quick edit,,Quick/Bulk Edit,,normal,normal,Awaiting Review,enhancement,new,,2012-09-08T02:02:36Z,2012-09-08T17:08:36Z,"I'd like to propose that there be more options to adjust the default quick edits. For instance, my Radio Buttons for Taxonomies plugin removes the default metabox for taxonomies and replaces it with one that uses radio inputs, which limits the user to a single term choice.
However in the quick edit, this is easily circumvented, because I have no way to remove the taxonomy inputs from being displayed in their default ways.
At the minimum, just adding a filter to the taxonomies would let me disable the default taxonomy inputs and then add my own. More hooks/filters would be ideal, but I think this is the minimum I can get away with.
Sorry it isn't a patch or diff... I'll try to get WordPress set up as a repo on my computer. But in the mean time I'm proposing a change to :
/wp-admin/includes/class-wp-posts-list-table.php file
in the '''inline_edit()''' method, for instance, i'd like to change
{{{
$taxonomy_names = get_object_taxonomies( $screen->post_type );
}}}
to:
{{{
$taxonomy_names = apply_filters( 'inline_edit_taxonomies', get_object_taxonomies( $screen->post_type ), $screen->post_type );
}}}
",helgatheviking
Future Releases,19343,Allow Quick Edit to be Disabled for Custom Post Types,,Quick/Bulk Edit,3.3,normal,trivial,Awaiting Review,feature request,new,,2011-11-23T19:41:02Z,2012-11-22T03:17:16Z,"For some custom post types, quick edit doesn't make sense, and it's not easy to disable the quick edit code. You can use CSS to hide it but that still requires the code to be sent to the browser when it's not even needed.
The only other solution is to extend the ''WP_Posts_List_Table'' class and set the ''inline_edit()'' function to return nothing. Something like this:
{{{
if(!class_exists('WP_List_Table')) {
require_once(ABSPATH . 'wp-admin/includes/class-wp-list-table.php');
}
if(!class_exists('WP_Posts_List_Table')) {
require_once(ABSPATH . 'wp-admin/includes/class-wp-posts-list-table.php');
}
class My_Posts_List_Table extends WP_Posts_List_Table {
function inline_edit(){}
}
function my_admin_head() {
$wp_list_table = new My_Posts_List_Table();
$wp_list_table->prepare_items();
}
add_action('admin_head-edit.php', 'my_admin_head');
}}}
Clearly, that is a lot of code to accomplish something so simple.
So, it would be nice if there was some way to disable quick edit. Maybe it could be a feature you could disable via the ""''supports''"" option when you register the custom post type?",Jick
Future Releases,18496,Quick edit loses custom colums and custom order - looks bad,,Quick/Bulk Edit,3.2.1,normal,minor,Awaiting Review,feature request,reopened,reporter-feedback,2011-08-23T01:56:37Z,2012-06-18T22:31:42Z,"Using manage_posts_custom_column, 'manage_posts_columns', 'manage_edit-'.$post_type.'_columns' etc
to add custom columns to the manage edit lists and to change the order of the fields.
If Quick edit is used on a post, the custom columns disappear (visually - a refresh displays them again) and the custom column order is reset just for that post.
This results in a rather buggy looking display. (See attached screenshots). All is okay on a refresh of the page.
I think this is related to http://core.trac.wordpress.org/ticket/17935. (explained differently, but possibly similar cause?)
",anmari
Future Releases,23923,wp_get_post_revisions returns incorrect order,,Revisions,,normal,minor,Awaiting Review,defect (bug),new,,2013-04-03T12:07:19Z,2013-04-08T00:27:47Z,"When a post has multiple revisions and each revision has the exact same timestamp, `wp_get_post_revisions` returns revisions in reversed order, causing `wp_save_post_revision` to [http://core.trac.wordpress.org/browser/trunk/wp-includes/revision.php#L116 make a bad choice] for `$last_revision` (which is actually the first revision) and produce an extra revision, even if it has not been changed.
In a normal environment this doesn't happen, unless you run `wp_update_post` several times in a row in under one second, so this is an edge case. This edge case causes our [http://core.trac.wordpress.org/browser/tests/trunk/tests/post/revisions.php#L55 revisions.php tests] to fail randomly, depending on whether the updates happened with the same timestamp or not.
To reproduce, try running the revisions unit tests several times in a row.",kovshenin
Future Releases,20520,Author Page Pagination Broken,,Rewrite Rules,3.3.1,normal,normal,Awaiting Review,defect (bug),new,,2012-04-23T04:16:03Z,2012-04-23T04:37:44Z,"WP 3.3.1 Multisite
Permalink setup: /author/post-name
- If the request is ""domain.com/authorname"" the authors page pagination link is broken.
- If the request is ""domain.com/author/authorname"" the authors page pagination link works fine.",rbaccaro
Future Releases,20688,Forward slash in custom taxonomy rewrite causes 404s because of (unnecessary?) attachment rule,,Rewrite Rules,3.3.2,normal,normal,Awaiting Review,defect (bug),new,,2012-05-16T09:07:57Z,2012-05-16T11:54:34Z,"I implement a custom taxonomy with a rewrite that is designed to create urls like:
""/apps/about/sometag""
{{{
$name = 'apps';
register_taxonomy($name.'-tag', $name.'-post', array(
'label' => ucfirst($name) . ' Tags',
'public' => true,
'has_archive' => true,
'hierarchical' => false,
'update_count_callback' => '_update_post_term_count',
'rewrite' => array('slug' => ""$name/about"", with_front=>true)
));
}}}
However I was getting a 404 (yes I was flushing the rules) unless I changed the '/' to say a '-'. Upon inspection of the rules, I found this one whose precedence was causing the problem:
{{{
'apps/[^/]+/([^/]+)/?$' => 'index.php?attachment=$matches[1]'
}}}
Upon removing it inside the ""rewrite_rules_array"" hook, the problem was solved.
It seems odd to me that this generic rule exists and rewrites to an attachment of all things...",harikaram
Future Releases,19633,Multilingual Permalinks - Broken Pagination,,Rewrite Rules,3.3,normal,critical,Awaiting Review,defect (bug),new,,2011-12-21T13:23:32Z,2011-12-21T22:37:10Z,"With the new rewrite engine in WP3.3 the pagination for pages with multilingual URLs got broken.
See example:
[http://garage-eden.co.il/%D7%97%D7%95%D7%95%D7%AA-%D7%93%D7%A2%D7%AA-%D7%94%D7%9C%D7%A7%D7%95%D7%97%D7%95%D7%AA Live Example of Broken Pagination]
The permalink structure used for this:
%postname%
The Code Used for the Page:
{{{
'testimonials',
'paged' => ""$paged"",
'posts_per_page' => 3
);
query_posts( $args );
// The Loop
if (have_posts()) : while (have_posts()) : the_post();
?>
הבא »') ?>
« הקודם') ?>
}}}
",aternus
Future Releases,19896,Non-WP rewrites not saved on a multisite install,,Rewrite Rules,3.0,normal,normal,Awaiting Review,defect (bug),new,,2012-01-25T16:14:20Z,2012-01-25T16:14:20Z,"The following code adds a rewrite rule which is classed as a non-WP rewrite rule because its redirect doesn't begin with `index.php`, and is stored in the `non_wp_rules` member variable of the `WP_Rewrite` class.
{{{
function my_rewrite() {
add_rewrite_rule( 'login/?$', 'wp-login.php', 'top' );
}
add_action( 'init', 'my_rewrite' );
}}}
On a single site install, this rewrite rule gets saved directly to the .htaccess file rather than being added to WordPress' internal rewrite array.
On a multisite install, this doesn't happen and the rewrite rule has no effect (probably because once a site is multisite-d WordPress no longer writes to .htaccess). The rule has to be manually added to .htaccess.
Likely introduced in 3.0, reproduced in 3.3 and trunk.",johnbillion
Future Releases,21645,Rewrite API logic and flush_rules,,Rewrite Rules,3.4.1,normal,normal,Awaiting Review,defect (bug),new,,2012-08-21T00:24:05Z,2012-08-21T08:24:19Z,"
It is not clear if or how visiting the Settings -> Permalinks calls flush_rules. It is referenced occasionally as an apparent alternative to $wp_rewrite->flush_rules() in Documentation. This should be explicitly confirmed in the admin interface and/or a button based action.
Documentation for the Rewrite API functions do not point at $wp_rewrite->flush_rules() effectively. (Updated some codex links, but seems worth including a pointer inline in function definitions.)
I was confused while editing an existing theme why duplicating existing add_feed() structures in functions.php did not produce duplicated behaviour in the permalinks. ?feed=atom1 worked , but /feed/atom1/ didn't, until calling flush_rules()
Logic seems broken between these functions. Why call Rewrite API add_feed() every init, but still require a flush_rules reset to activate? They should be more explicitly linked / combined / triggered. See prior conversation in #21335
http://codex.wordpress.org/Rewrite_API",here
Future Releases,16832,Trouble if the slug of a custom taxonomy is the same as the url of page/post,,Rewrite Rules,3.1,normal,normal,Awaiting Review,defect (bug),new,,2011-03-11T11:50:43Z,2011-09-29T23:26:24Z,"I got some troubles with the 3.1 version of WordPress concerning the slug of custom taxonomy.
'''An example that work in 3.0.5'''[[BR]]
www.example.com/agency (url of a page)[[BR]]
www.example.com/agency/john-smith (url of a custom type's detail)
Apparently having the same ""folder"" 'agency' only works for one or the other url but not both.
Hope I made myself clear.",LucasHantz
Future Releases,20109,Valid htaccess rule causes 404 after upgrade to 3.3.1,,Rewrite Rules,3.3.1,normal,critical,Awaiting Review,defect (bug),new,,2012-02-24T06:26:42Z,2012-02-27T19:42:29Z,"On 2/18/2012, I upgraded WP from 3.2.1 to 3.3.1. on www.denverhomevalue.com. I later noticed that Google webmaster tools started reporting 404 errors on lots of pages that were fine before. WP was still returning the proper pages and content, not my custom 404 page, so the issue was not readily apparent except in WMT reports. Running http header response checkers confirmed 404 responses, despite good contents being returned.
Deleting sections of the htaccess file until the problem went away, the issue was isolated to two rules meant to escape following rewrite rules on certain urls:
{{{
RewriteRule ^city(.*) - [L]
RewriteRule ^areas(.*) - [L]
}}}
These were the same family of urls that started returning 404s after 3.3.1 upgrade. These rules were in place since 12/5/2011, with WP 3.2.1 and never caused a problem.
I was able to revert a backup of the site to 3.2.1, on the same exact server environment, and confirm that these same valid htaccess rewrite rules were not a problem in that release.",ronnieg
Future Releases,23867,add_rewrite_endpoint causes front-page.php template to be ignored,,Rewrite Rules,3.5.1,normal,normal,Awaiting Review,defect (bug),new,reporter-feedback,2013-03-26T21:49:18Z,2013-04-16T00:50:35Z,"I have a front-page.php template in my theme folder, as per the template hierarchy this is used regardless of whether I am showing posts or a page as the front page.
However, when I add a rewrite endpoint (on the init hook), index.php is used for the front page template when I add my query var to the URL. It makes no difference if I set the front page to show posts or a page. If I do not add the query var, front-page.php is correctly used.
i.e. http://domain.com correctly uses front-page.php, http://domain.com/nl wrongly uses index.php
This happens whether I use EP_ALL or EP_ROOT as the places parameter.
All other template files are fine, it's only the homepage with the problem as far as I can see.",lumpysimon
Future Releases,22619,add_rewrite_endpoint generates incorrect attachment rules,,Rewrite Rules,,normal,normal,Awaiting Review,defect (bug),new,,2012-11-28T08:47:43Z,2013-05-15T17:31:34Z,"{{{add_rewrite_endpoint}}} with {{{EP_ALL}}} or {{{EP_ATTACHMENT}}} results in incorrect endpoint matches. The index set for the endpoint value is {{{2}}} which ends up returning the slash as well. The index should actually be {{{3}}} since we only care about the inner match.
Example:
{{{add_rewrite_endpoint( 'my-endpoint', EP_ALL )}}}
Results in rules like (dump from {{{$wp_rewrite->generate_rules}}}:
{{{
'.?.+?/([^/]+)/my-endpoint(/(.*))?/?$' =>
string(35) ""index.php?attachment=$1&my-endpoint=$2""
'.?.+?/attachment/([^/]+)/my-endpoint(/(.*))?/?$' =>
string(35) ""index.php?attachment=$1&my-endpoint=$2""
}}}
Visiting a {{{my-endpoint}}} URL for an attachment like {{{/2012/01/01/post-name/attachment/my-endpoint/foo/}}} will return the value of {{{get_query_var( 'my-endpoint' )}}} as {{{/foo}}} instead of {{{foo}}}.",batmoo
Future Releases,19493,post and archive pagination don't work with custom endpoints,,Rewrite Rules,2.1,normal,normal,Awaiting Review,defect (bug),new,,2011-12-09T23:55:09Z,2012-04-02T20:54:52Z,"Archive pagination and post pagination are not endpoint-aware, so they break when endpoints are added to them.
The following example code creates an endpoint, and then uses a filter to add that endpoint to various links on the rendered page:
{{{
add_action( 'init', function() {
global $wp_rewrite;
add_rewrite_endpoint( 'foo', EP_ALL );
$wp_rewrite->flush_rules(false);
} );
add_filter( 'post_link', 'gist_add_endpoint_to_url', 99 );
add_filter( 'get_pagenum_link', 'gist_add_endpoint_to_url', 99 );
function gist_add_endpoint_to_url( $url_base ) {
$endpoint = 'foo';
$url_parts = parse_url( $url_base );
$url = ( isset($url_parts['scheme']) && isset($url_parts['host']) ) ? $url_parts['scheme'] . '://' . $url_parts['host'] : '';
$url .= isset($url_parts['path']) ? $url_parts['path'] : '';
$url = user_trailingslashit( $url );
if ( '' === get_option('permalink_structure') ) {
$url .= isset($url_parts['query']) ? '?' . $url_parts['query'] : '';
$url = add_query_arg( $endpoint, 'true', $url );
} else {
$url .= $endpoint . '/true';
$url = user_trailingslashit( $url );
$url .= isset($url_parts['query']) ? '?' . $url_parts['query'] : '';
}
$url .= isset($url_parts['fragment']) ? '#' . $url_parts['fragment'] : '';
return $url;
}
}}}
You'll see that it works perfectly using the theme unit test, except that paginated posts produce URLs like this:
http://example.com/2008/09/layout-test/foo/true/2/
...which doesn't work. The inverse -- http://example.com/2008/09/layout-test/2/foo/true/ -- also doesn't work, and produces a 404 on top of it.
Also, the older posts / newer posts produce this format of link:
http://example.com/page/2/foo/true/
.. .which also doesn't work.
If you change gist_add_endpoint_to_url() to add a querystring param, older posts/newer posts links work fine, but post pagination still breaks:
{{{
function gist_add_endpoint_to_url( $url_base ) {
$endpoint = 'foo';
$url_base = add_query_arg( $endpoint, 'true', $url_base );
return $url_base;
}
}}}
If you don't use a permalink structure at all, it works fine, since the pagination params are passed directly in the URL.
I'm not sure if the fix lies in modifying add_rewrite_endpoint() so that it creates pagination urls in wp_rewrite, or modifying the way _wp_link_page() and get_next_posts_link() work. ",mintindeed
Future Releases,16830,url_to_postid() doesn't resolve attachments when rewrite rules are disabled,,Rewrite Rules,3.1,normal,normal,Awaiting Review,defect (bug),new,,2011-03-11T01:09:14Z,2011-04-03T04:11:21Z,"The code of {{{url_to_postid()}}} is pretty clear in the case of disabled rewrite rules: all URLs not using the {{{p=N}}}, {{{page_id=N}}} or {{{attachment_id=N}}} forms are not parsed and the function return 0. That make sense.
Now there is a special case for attachments. Attachments can be saved under a the {{{/wp-content/uploads/year/month/}}} folder structure while rewrite rules are disabled at the same time.
This means there is a missed opportunity for {{{url_to_postid()}}} to resolve attachment's URLs of the long-form when rewrite rules are disabled.
This was tested and reproduced on WordPress 3.1.",Coolkevman
Future Releases,21374,Add core support for letting custom permalink structure for different post types,,Rewrite Rules,3.4.1,normal,normal,Awaiting Review,enhancement,new,,2012-07-25T14:42:15Z,2012-09-19T09:56:07Z,"By default, custom post types uses only the'' %postname%'' permalink structure (if using pretty links and not default query variables).
Currently there is no native way to easily have different permastructs for different CPT.
This features should be added to the '''register_post_type()''' function, letting different permalink structure be defined to each post_type being registered.
I sugget adding another new key to the '''rewrite''' array that can be passed to the '''register_post_type()''' function.
i.e. -
{{{
register_post_type('event',array(
......
'rewrite' => array('slug' => 'events',
'permastruct' => '%year%/%monthnum%/%event%'
),
.....
));
}}}
The register_post_type function should be changed, a suggestion for such a change may be that instead of this line in the function - (post.php line#1075)
{{{
add_permastruct( $post_type, ""{$args->rewrite['slug']}/%$post_type%"", $args->rewrite );
}}}
This example could be used -
{{{
if ( $args->rewrite['permastruct'] ) {
$perma_structure = $args->rewrite['permastruct'];
$wp_rewrite->add_rewrite_tag(""%{$post_type}%"", '([^/]+)', ""{$post_type}="");
$wp_rewrite->add_permastruct($post_type, $archive_slug.'/'.$perma_structure, false);
}
else {
add_permastruct( $post_type, ""{$args->rewrite['slug']}/%$post_type%"", $args->rewrite );
}
}}}
In order that the structure can interpret the permastruct tags, I added also this function to filter post_type_link, it is adapted from '''get_permalink''' function in ''wp-includes/link-template.php'' -
{{{
add_filter('post_type_link', 'tc_permalink', 10, 3);
function tc_permalink($permalink, $post_id, $leavename) {
$post = get_post($post_id);
$rewritecode = array(
'%year%',
'%monthnum%',
'%day%',
'%hour%',
'%minute%',
'%second%',
$leavename? '' : '%postname%',
'%post_id%',
'%category%',
'%author%',
$leavename? '' : '%pagename%',
);
if ( '' != $permalink && !in_array($post->post_status, array('draft', 'pending', 'auto-draft')) ) {
$unixtime = strtotime($post->post_date);
$category = '';
if ( strpos($permalink, '%category%') !== false ) {
$cats = get_the_category($post->ID);
if ( $cats ) {
usort($cats, '_usort_terms_by_ID'); // order by ID
$category = $cats[0]->slug;
if ( $parent = $cats[0]->parent )
$category = get_category_parents($parent, false, '/', true) . $category;
}
// show default category in permalinks, without
// having to assign it explicitly
if ( empty($category) ) {
$default_category = get_category( get_option( 'default_category' ) );
$category = is_wp_error( $default_category ) ? '' : $default_category->slug;
}
}
$author = '';
if ( strpos($permalink, '%author%') !== false ) {
$authordata = get_userdata($post->post_author);
$author = $authordata->user_nicename;
}
$date = explode("" "",date('Y m d H i s', $unixtime));
$rewritereplace =
array(
$date[0],
$date[1],
$date[2],
$date[3],
$date[4],
$date[5],
$post->post_name,
$post->ID,
$category,
$author,
$post->post_name,
);
$permalink = str_replace($rewritecode, $rewritereplace, $permalink);
} else { // if they're not using the fancy permalink option
}
return $permalink;
}
}}}
On a basic check this seems to be working, but ofcourse needed to be more deubgged.. I will be happy to here if you think such a feature should be added to core.",maorb
Future Releases,23491,Add hook to insert_with_markers() so theme/plugin authors can prevent writing to .htaccess,,Rewrite Rules,,normal,normal,Awaiting Review,enhancement,new,,2013-02-17T17:09:18Z,2013-02-17T17:09:18Z,"If not using .htaccess to rewrite, but instead keeping those settings in an Apache config file, it would be nice if writing the .htaccess file could be prevented by hooking into the function that does that (e.g. returning false or something like that).
Why? If the Apache option AllowOverride is turned off (which it should be for performance reasons, if not using any .htaccess files) the file won't ever be read. But still having it around (except cluttering) can possibly confuse someone having access to the server, seeing the file and thinking it actually controls anything. Especially since most WordPress support threads on the Internet assumes that an .htaccess file is used for rewrite rules.
One solution is to keep an empty, non-writable .htaccess file, optionally having a comment in it saying it's unused, but getting rid of the file altogether would be much cleaner. Also, it can still happen that someone accidentally changes the file permission, and someone else (or the same person) saves permalink options, saving a new .htaccess file, having created the possibility of confusion once again.",alimony
Future Releases,22798,"Invalid URLs not giving 404 with ""Default"" permalink settings",,Rewrite Rules,3.4.2,normal,normal,Awaiting Review,enhancement,new,,2012-12-06T23:39:35Z,2012-12-07T03:25:50Z,"'''Steps to reproduce:'''
- Set up Wordpress with the default .htaccess
- Select the ""Default"" option under Permalink Settings
- Enter an invalid URL eg 'http://blogroot.com/garlbeflax.abc'
'''Expected Behaviour:'''
- 404 page is displayed
'''Observed Behaviour:'''
- No 404 page is ever shown, no matter what the request string is
- Instead, Wordpress behaves as if no path was requested, eg displaying the homepage/posts lists.
- If requested url has any of the standard params in it, those params ARE executed, eg http://blogroot.com/foo?paged=2 would properly show the 2nd page of the posts.
'''Suspected cause:'''
In line 620 of wp-includes/class-wp.php (in WP->parse_request), there is a conditional which means the only time the request can be marked as a 404 error is if the array of rewrite rules is NOT empty:
{{{
$rewrite = $wp_rewrite->wp_rewrite_rules();
if ( ! empty($rewrite) ) {
...
}}}
If the ""Default"" permalink is selected, and no other rewrite rules are set up elsewhere (for reasons I didn't investigate, adding a add_rewrite_rule to the theme didn't affect anything), then the $rewrite array IS empty and the request can not be checked to see if it's a 404. Therefore, execution of the request continues as if no path info were submitted.
This prevents the showing of the theme's 404 page, and can get a website flagged as spam/exploitative in Google's index.
'''Workaround:'''
Define a permalink redirect (eg pick one of the options other than Default).
Server info:
{{{
Apache/2.2.16 (Debian) (w/ mod_rewrite)
PHP Version 5.3.3-7+squeeze3 (mod_php5)
}}}
.htaccess contents:
{{{
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
}}}",vanchuck
Future Releases,18502,Show ID on Custom Post Types Permalinks,,Rewrite Rules,,normal,normal,Awaiting Review,enhancement,new,,2011-08-23T18:43:19Z,2011-08-23T18:50:35Z,"Hi...
I have been using now lots of custom post types for different portals, and found that it's something no one ever knew, thought would be a cool feature if possible.
Now i have one custom post type for dvds, when the user publishes, it gets to
/dvd/name-of-dvd
The other settings for permalinks is set to show /%post_id%/ so in the blog it gets
/1/name-of-post
Just on custom post types it's imposible to make that.
For some things, like jobs, dvd, books, maybe there are things with same name, and an ID would be better to identify...
",kaiserlino
Future Releases,16808,Insufficient permissions for custom post type management and custom role/caps,,Role/Capability,3.1,normal,normal,Awaiting Review,defect (bug),new,,2011-03-09T19:54:04Z,2011-03-09T22:04:02Z,"I asked a question over at [http://wordpress.stackexchange.com/questions/11508/permission-error-on-custom-post-type-add-new-action StackExchange] about this. Went into their chat room to talk to a few people and came to the conclusion I need to post this ticket.
---
When accessing an admin page located at post-new.php with a custom post type on a user that's in a custom role that has the available permission to ""Add New"", you get ""You do not have sufficient permissions to access this page.""
{{{
$post_caps = array( 'delete_post' => 'argus_admin', );
$visitor_caps = $post_caps;
$visitor_caps = array_merge( $visitor_caps, array(
'edit_post' => 'argus_visitors',
'read_post' => 'argus_visitors',
'edit_posts' => 'argus_visitors',
'edit_others_posts' => 'argus_visitors',
'publish_posts' => 'argus_visitors',
'read_private_posts' => 'argus_visitors',
));
$v_args = array(
'labels' => array (
'name' => 'Visitors',
'singular_name' => 'Visitor',
'add_new_item' => 'Register New Visitor',
),
'public' => true,
'publicly_queryable' => false,
'exclude_from_search' => true,
'show_ui' => true,
'show_in_menu' => 'argus',
//'show_in_menu' => false,
'hiearchical' => false,
'supports' => array( '' ),
'capabilities' => $visitor_caps,
'register_meta_box_cb' => array ( &$this, '_wp_visitor_meta_box_cb' ),
);
register_post_type( 'visitor', $v_args );
}}}
I've tested it with 3.0.4 and it worked flawlessly. However, when in 3.1, it doesn't want to work.",Genesis2001
Future Releases,21788,Relocate revoke_super_admin() and grant_super_admin() to capabilities.php,,Role/Capability,,normal,normal,Awaiting Review,defect (bug),new,,2012-09-04T11:09:57Z,2012-09-16T21:32:38Z,"Would be nice to move revoke_super_admin() and grant_super_admin() out of /wp-admin/includes/ms.php and into to /wp-includes/capabilities.php, where the rest of the _super_admin() functions are.
This allows theme-side user profile plugins (see: the bb's) to use these functions without needing to pull in a wp-admin file directly.",johnjamesjacoby
Future Releases,19747,Roles add_cap should call update_user_level_from_caps(),,Role/Capability,3.3.1,normal,normal,Awaiting Review,defect (bug),new,,2012-01-05T11:17:32Z,2012-12-12T20:39:22Z,"Hey guys,
I've created a new user role, which didn't appear in the Author drop down list due to #16841. The workaround is to add a level_1 capability to that user, but because wordpress doesn't call update_user_level_from_caps() function when you add_cap, that isn't actually applied to existing users on the role, and you have to move them to a different role and back again if you want to apply the changed user role.
I'd suggest adding a call to update_user_level_from_caps() to add_cap (and remove_cap) to fix this in wp-includes/capabilities.php",lgladdy
Future Releases,24153,Sticky flag gets unset if author doesn't have publish_posts permission,,Role/Capability,3.5.1,normal,major,Awaiting Review,defect (bug),new,,2013-04-22T05:03:20Z,2013-04-23T04:58:05Z,"I'm observing a bug with the sticky flag. I set up a special user with a role of ""Grammar Nazi"" who should only have access to editing of other people's posts, but not publishing his own.
The permissions given to this role are:
- edit_published_posts
- edit_others_posts
- edit_posts
- read
- read_private_posts
This user works out great - he's limited to only editing errors in other authors' posts.
However, there is a bug with sticky posts. If a grammar nazi edits a stickied post, '''the sticky flag gets unset'''. As a possibly related observation, there's no Edit button on the post edit page next to the Visibility area.
This bug is worked around by adding the ''publish_posts'' permission. However, this permission is unwanted in this case as grammar nazis shouldn't be able to post their own posts. Adding ''publish_posts'' enables the Edit button next to Visibility, and saves retain the sticky bit correctly.
So, in short: the sticky bit should be retained even when users without the ''publish_posts'' permission update a post.",archon810
Future Releases,16451,WP_Roles and capabilities,,Role/Capability,3.0.4,normal,normal,Awaiting Review,defect (bug),new,,2011-02-03T19:06:28Z,2011-02-03T19:56:45Z,"I began to complain about this in the support forum: http://wordpress.org/support/topic/bug-report-wp_roles?replies=3#post-1922100 . You can read the longer version there.
The WP_Roles-Class lacks some consistency (immo). I am not aware of the reasons why WP_Roles multiple class-varibles containing the roles and capabilities, but in this case your logic is producing some errors:
I wrote my Plugins as classes. While Wordpress loads them, I add the roles and capabilities this plugin needs. It would have been far more complicated to do this only while activating.
Creating a WP_User-Object, it will set it's ""all_caps"" from $wp_roles->get_caps($role) which is looking into the $wp_roles->role_objects[$role]. There it will only find those capability of the $role, which were assigned while creating the role [ $wp_roles->add_role($identifier, $readable, $caps) ] but NONE of the caps added by [ $wp_roles->add_cap($role, $cap, $grant) ] because this function applies the capability to $wp_roles->roles but not to $wp_roles->role_objects, where WP_User will look into with the method [ $wp_roles->get_caps($role) ]
I use this as an example cause I faced this problem the last three days. The fact is, if you need those multiple variables in WP_Roles, please, keep them all up-to-date. Do not force the user to set all capabilities in the activation and do not rely on the thought that roles and capabilities will be set correctly if read from the database.
As the changes are minor and the effect major, it would be great to change it soon.",IM_natascha
Future Releases,21526,get_post_type_capabilities() assumes $args->capabilities is an array,,Role/Capability,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2012-08-09T12:29:01Z,2012-08-09T12:46:39Z,"get_post_type_capabilities() assumes $args->capabilities is an array and should check and confirm it. Otherwise a warning appears: Warning: array_merge() [function.array-merge]: Argument # 2 is not an array in /home/username/public_html/wp-includes/post.php on line 1183. I discovered this when I accidentally set this to null instead of array().
Type setting it seems to clear the warning, if we want to clear the warning.
{{{
$capabilities = array_merge( $default_capabilities, (array)$args->capabilities );
}}}
",wpsmith
Future Releases,16841,manually created user roles not showing in author dropdown irregardless of assigned capabilities,,Role/Capability,3.1,normal,normal,Awaiting Review,defect (bug),new,,2011-03-12T23:39:39Z,2012-12-12T20:32:08Z,"I posted the below on wp-testers hoping to verify or gain experiences from others in order to confirm this prior to reporting it as a bug, but, haven't received any further input, and it's just becoming more evident to me that perhaps it should be posted here, so, I hope I'm not creating a false report here. Please excuse me if I am.
I'm posting this as a link so that it will translate more clearly rather than just cluttering up this message with more text than necessary.
http://lists.automattic.com/pipermail/wp-testers/2011-March/014130.html
Upon further investigation I have also come across the following:
http://core.trac.wordpress.org/ticket/16451
I'm not an expert at debugging this sort of thing, but, I have attempted all within my knowledge thus far, and in looking at all of the returned objects and entries, the only difference I can spot between how the default user roles ( which show up properly in the dropdown ) and the custom created roles ( which do not ) are being returned is that the default user roles, editor for instance, correctly show the deprecated level_7 entry, and the custom user role ( with more assigned privileges than the editor ) does not show user levels in the capabilities array at all, and shows level_0 in the object.
This is leading me to think that perhaps there is something happening with those user levels in creating the author dropdown on the post editor that is blocking the custom user roles from showing up as expected.
When running the following code:
{{{
echo '
Roles
';
foreach ( $wp_roles->role_names as $role => $name ) :
echo '
';
echo '
Role displayed in Admin as ' . $name ;
echo ' Database entry: ' . $role . '
';
echo '
Capabilities assigned to the role of ' . $name. '
';
// print_r( $caps);
echo '
';
$rolename = get_role($role);
$caps = $rolename->capabilities;
foreach ($caps as $capability => $value):
echo $capability . ' '. $value . ""\n"" ;
endforeach;
echo '
';
endforeach;
}}}
the default wp roles return the following capability value pairings
{{{
delete_published_posts 1
}}}
roles created with Justin Tadlock's members plugin return the following
{{{
delete_published_posts delete_published_posts
}}}
roles created manually in functions.php utilizing
{{{
add_role( 'test_role', 'Test Role' );
//saved and then removed before running the code below ...
$role = get_role('test_role');
$role->add_cap('read');
$role->add_cap('edit_posts);
$role->add_cap('edit_others_posts');
$role->add_cap('publish_posts');
$role->add_cap('read_private_posts');
$role->add_cap('delete_posts');
$role->add_cap('delete_private_posts');
$role->add_cap('delete_published_posts');
$role->add_cap('delete_others_posts');
$role->add_cap('edit_private_posts');
$role->add_cap('edit_published_posts');
}}}
return the following ...
{{{
delete_published_posts 1
}}}
but lack the user levels as mentioned above.
Let me know if there is any further info I can provide to help sort this out~
",10sexyapples
Future Releases,21425,the 'edit_users' capability also allows 'promote_users',,Role/Capability,3.4.1,normal,major,Awaiting Review,defect (bug),new,dev-feedback,2012-07-30T17:07:52Z,2012-09-22T10:11:33Z,"Hello all,
I have found an issue where I have created a Support role in order to have a user make changes to basic user information. What I noticed was that the capability 'edit_users' allows said User (role) to promote users to any role - including admin! I tried removing the cap 'promote_users' and it does nothing.
add_role(
'support',
'Support',
array(
'read' => true,
'edit_feedback' => true,
'edit_others_feedback' => true,
'list_users' => true,
'edit_users' => true
)
);",ew_holmes
Future Releases,22968,No way to view_others_posts without being forced to have edit_others_posts enabled,,Role/Capability,3.5,normal,normal,Awaiting Review,enhancement,new,,2012-12-17T02:02:42Z,2012-12-18T06:48:22Z,"I'm using the Roles plugin to tweak default roles, and I'm looking to add the capability for Authors to read unpublished posts (drafts by other users, so that they can give feedback before they're published).
Unfortunately, it seems that while there's an edit_others_posts perm, there's no equivalent read_others_posts, so doing this is impossible unless you enable editing as well (that's not something I want to do). Read_private_posts doesn't do the trick either, in case you were going to suggest trying it.
The right solution, IMO, is to introduce read_others_posts (and same for pages).
Thank you.",archon810
Future Releases,23391,User in contributor role can add images to post only via the text editor,,Role/Capability,,normal,normal,Awaiting Review,enhancement,new,,2013-02-05T07:34:26Z,2013-02-05T10:15:34Z,"1. Create a user with contributor role
2. start new post with it
3. notice there is no ""add media"" button anywhere
4. switch to text editing
5. use the img button to insert a URL to a valid img on the web
6. request approval for the post
7. let admin/editor approve it
8. go the the post's URL and notice that the image is shown
So, it is not that contributors are not allowed to use images, it is just that WP makes it hard to do so.
Either HTML needs to be sanitized and have all img tags removes for contributors, or access to the media library should be allowed for contributors denying only access to uploading. I vote for the second option.",mark-k
Future Releases,17254,Contributors should be able to upload,,Role/Capability,3.1,normal,normal,Awaiting Review,feature request,new,,2011-04-27T11:42:24Z,2011-09-10T03:10:26Z,"Workflows and typical post content have evolved since the roles were defined. Posts frequently contain images, video, etc. As it is now, for someone to be able to put an uploaded image or video in a post, they have to be an Author, because contributors have no upload rights. This means that if a post contains any media, the person writing it has the ability to publish. There's a big gap now for use cases where a site owner wants to curate/edit contributor submissions before publication but wants those contributor posts to not be limited to text-only creations.
Proposal: allow contributors to upload media files (kept as draft, not published until approved by higher role). ",jane
Future Releases,16822,FORCE_SSL_LOGIN causes wp-login.php to have an incorrect https link,jakub.tyrcha*,Security,3.1,normal,normal,Awaiting Review,defect (bug),accepted,,2011-03-10T16:21:25Z,2011-09-10T01:20:12Z,"In this bug, the WordPress logo on the login screen incorrectly links to an https URL. It is easy to reproduce.
First, define('FORCE_SSL_LOGIN', true) in wp-config.php. Then make sure you are logged out of WordPress. (Note: I am running multisite - I don't know if this matters or not.)
1. Visit /wp-login.php. Fill in WRONG credentials (misspell your password) and click the Submit button.
2. wp-login.php redisplays as expected, this time with an https URL.
3. The WordPress logo on the form now links to https://your.site.com. If you click it, you are visiting your site over SSL.
This should not happen. The WordPress logo (and any other links on the login page) should render http URLs.",dbvista
Future Releases,4137,Pingback Denial of Service possibility,,Security,1.5,low,normal,Awaiting Review,defect (bug),reviewing,,2007-04-11T19:41:51Z,2013-02-01T02:37:17Z,"The pingback feature of Wordpress (2.1.3) allows DDOS attacks either against the server hosting wordpress or against a third one.
When a client sends a pingback, wordpress calls ""wp_remote_fopen"" to download the referring URL. On servers having ""allow_url_fopen"" activated, this function will try to download the /whole/ URL without any timeout or size limit. (except those set in php.ini, which will usually lead to a ~8MB download)
So if you post ~100 xmlrpc requests referring to a /huge/ file, every server meeting those prerequisites should effectively be down (for a while). You should at least be able to generate lots of traffic.
On the other hand, if you google for blogs and post the same URL to each of 'em, the target server should be DDOSed.
I suggest allowing pingbacks only if the connection was opened from the host mentioned in the source URL.
I'll attach a demo exploit (I didn't test it for the entered URL; it worked for a local installation.)",foobarwp12
Future Releases,19415,wp_nav_menu showing private/conctepts posts without rights,,Security,3.0,normal,major,Awaiting Review,defect (bug),new,,2011-12-02T18:11:06Z,2012-11-01T16:52:23Z,"when you are using wordpress menus and you got your post/page in a menu (e.g. using Automatically add new top-level pages) and then change the post/page to concept or set it private, the link to post/page stays in the menu for all users, what may have some negative security concerns
this error in all versions, including todays nightly
IMO it should show only visible posts (if someone disagrees and need it for some backward compatibility, there may be some parameter, but imo hidding private/concept should be default)",thomask
Future Releases,21022,Allow bcrypt to be enabled via filter for pass hashing,,Security,3.4,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2012-06-20T01:34:26Z,2013-03-05T19:26:57Z,"Hi,
following recent discussions on password security and how to best prevent any hackers can leverage password table they might have got I looked into the phpass used for WordPress.
While I in principle understand why WordPress uses the compatibility mode of it, I would like to see some flexibility for those who don't need the compatibility.
Thus I would propose to change in wp-includes/pluggable.php all occurances of
$wp_hasher = new PasswordHash(8, true);
to
$wp_hasher = new PasswordHash(8, apply_filters('phpass_compatibility_mode', true));
This would allow users to easily change via plugin from the ""not so secure"" compatibility mode (only salted MD5) of phpass to a more secure setting (bcrypt) in case no compatibility with other applications is required.
The plugin changing the encryption methog could then as easy as
function phpass_bcrypt() {
return false;
}
add_filter('phpass_compatibility_mode', 'phpass_bcrypt');",th23
Future Releases,21737,"Users should have to jump through hoops to set passwords of their choosing, and we should guard better against weak passwords",westi*,Security,,normal,normal,Awaiting Review,feature request,accepted,,2012-08-30T04:07:17Z,2013-04-18T02:44:43Z,"People are terrible at choosing secure, unique, complex, unguessable passwords. Unless someone is using a password storage system, the chances are good that the passwords they're choosing are really weak.
We can mitigate this problem.
1. Let's make the default to always be that WordPress picks a password for you. When installing WordPress, or when creating a new user account, or when changing your password on your profile. The default should be that we generate a secure password for the user. They can remember it, write it down (not ideal, but generally more secure than choosing a weak password), or copy and use it once, check the ""remember me"" box, and not worry about it until their cookie expires on that computer.
2. If they do opt to manually create a password, we need to do better than our current password strength meter. And the lowest level should actually nag them with an AYS before they proceed. I suggest the following, to start, which would trigger the lowest level, and cause them to have to dismiss a warning (or check a checkbox... UI TBD) before continuing:
* compare the strtolower'd version of their password to strtolower'd versions of all their info (username, first/last name, part of e-mail address before the @, etc).
* any password that is shorter than 8 characters
* a blacklist of popular passwords (these lists are available... even grabbing the top 100 would give use good coverage)
* 3 or more consecutive digits (""123456"" and company are very popular)
* anything that looks like a date",markjaquith
Future Releases,21924,add action / filter to wp-login.php so we can replace WordPress login and force using 3rd party login,,Security,,normal,normal,Awaiting Review,feature request,new,,2012-09-19T11:59:58Z,2012-09-19T11:59:58Z,"I want to turn off WordPress login because I don't have an SSL certificate. I want to replace (not just hide with CSS or something) the WordPress wp-login.php login form so that a plugin can hook into that and be called within themes that use the hook to display the WordPress login form. Then, if the plugin is disabled, the generic WordPress login will display by default/fallback.
Worst concern about this is the plugin failing, especially upon an update or theme change or something and this can be fixed by logging in and disabling the plugin via FTP or via database or something.
(Of course, applies to both ""login"" and ""register"", not just ""login"".)
What I tried before posting here:
http://premium.wpmudev.org/forums/topic/is-there-a-plugin-to-disable-wordpress-default-login?replies=9#post-276574
and
http://www.wpquestions.com/question/show/id/7065
Might be related to:
http://core.trac.wordpress.org/ticket/19097
Thank you very much.",cliffpaulick
Future Releases,17227,wp should work around bug in move_uploaded_file for tighter security,,Security,3.2.1,normal,normal,Awaiting Review,feature request,new,,2011-04-24T00:28:50Z,2011-11-17T18:52:45Z,"Andrew Nacin said I should put this in a new ticket so others can weigh in. Here's the email with the description:
Hey guys, so I'm trying to harden up (!) my wordpress installation, and the whole world-writable wp-content/uploads thing is avoidable by creating a group that includes me and apache (call it ""checkersites""), and making wp-content/uploads et al group writable, group checkersites, and the directories group sticky. So, any new directories and files created are group checkersites so I can toast them, even though apache is the owner.
However, there's a bug in php's move_uploaded_file that it doesn't obey the directory group sticky bit, so any files uploaded and run through move_uploaded_file are apache:apache, which then breaks everything with this scheme (meaning, the files still work, but now I can't modify the them without su'ing, etc.). This has been recorded on the php docs for move_uploaded_files since 2008 ([http://www.php.net/manual/en/function.move-uploaded-file.php#85149 note here]), so it looks like they just don't care. I was thinking about patching wordpress to work around this by checking if the destination directory's group sticky bit is set and changing the group to that if so. Would you guys be interested in the patch?
As far as I can tell, this is the only thing that forces non-root users to make directories world writable (or even readable, assuming the admin will set up the shared group for them). Seems like it's worth fixing.",chrishecker
Future Releases,19639,"Enhancement: request: filter support before shortcodes are parsed or convert " into """,,Shortcodes,3.3,normal,normal,Awaiting Review,defect (bug),new,,2011-12-21T17:01:41Z,2011-12-22T00:39:34Z,"My team uses Windows Live Writer to do all posting, but we constantly have trouble using shortcodes because WLW, being as awesome as it is in other aspects, keeps converting the double quotes in shortcodes to
{{{
"
}}}
This breaks shortcode attributes, and while we're working around it using single quotes, we can't use shortcode attribute data that contains single quotes then.
So, is there a good fix for this?
One workaround would be to have a filter that runs before shortcodes are parsed that converts " back to "". However, in the shortcode API, I found no filters in use at all, so that's out without modifying WP source.
Alternatively, the API could just pre-process the data and take care of this case, which should be solved in WP core yet again.
Is there some way to resolve this without the above modifications to core?
Thanks.",archon810
Future Releases,23694,Shortcode attributes mess up html strings,,Shortcodes,3.5.1,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2013-03-05T15:15:48Z,2013-03-07T03:42:37Z,"{{{
[shortcode attribute=""
some HTML""/]
}}}
produces:
{{{
some HTML
}}}",prometh
Future Releases,21158,different result when shortcode atribute without value,,Shortcodes,3.4,normal,normal,Awaiting Review,defect (bug),new,,2012-07-04T19:11:44Z,2012-07-04T19:11:44Z,"imagine those two shortcodes
{{{
[shortcode attribute]
[shortcode attribute=value]
}}}
IMO they should have the same result, just the second should have some value to the attribute and the first should have NULL or false
But if you do
{{{
add_shortcode( 'shortcode', 'my_shortcode' );
function my_shortcode( $atts ) { print_r ($atts); }
}}}
the first shortcode results in
{{{
array (
0 => 'attribute',
)
}}}
while the second in
{{{
array (
'attribute' => 'value',
)
}}}
I'm not sure, maybe it is intentional, i have not found any description, what should shortcode attribute without value do. But imo it should work as i have described as it is the only way how it could clear some predefined value (the only other way is to set it to empty string, which may not always be the same as NULL or FALSE).",thomask
Future Releases,22272,shortcode_unautop() Doesn't Account for Opening/Closing Shortcode tags each Being on Their Own Line,,Shortcodes,3.4.2,normal,normal,Awaiting Review,defect (bug),new,,2012-10-24T17:54:22Z,2012-10-24T17:54:22Z,"The shortcode_unautop function does not appear to account for when the opening and closing shortcode tags are put on separate lines from the paragraph they are surrounding.
For example: the following is after wpautop() adds the paragraph tags.
{{{
[cool_shortcode]
A paragraph about something you should know.
[/cool_shortcode]
}}}
I would expect that shortcode_unautop would remove the paragraph tags from around both the opening and the closing shortcode tags. Instead it treats it all as if the entire thing were in one paragraph. Resulting in the following code being output.
{{{
[cool_shortcode]
A paragraph about something you should know.
[/cool_shortcode]
}}}
",bonnerl
Future Releases,22127,strange behaviour with shortcode with the_content filter,,Shortcodes,3.4.2,normal,normal,Awaiting Review,defect (bug),new,,2012-10-08T11:04:01Z,2012-10-08T12:03:34Z,"let's say i have installed any lightbox/thickbox/... plugin (same behaviour with 'auto thickbox plus', 'lightview plus', 'jquery lightbox', 'fancybox plus', 'wp jquery lightbox' ...) and i have a shortcode, which uses the_content filter, e.g.
{{{
function test_shortcode( $atts, $content = null ) {
return apply_filters('the_content', $content);
}
add_shortcode( 'test', 'test_shortcode' );
}}}
then if i use [test] shortcode anywhere in the post, the lightbox does not work. e.g.
{{{
[test]test[/test]
[caption ... /] // this is standard image
}}}
if the shortcode do not have the_content filter, or the shortcode is not use anywhere in the post, or i put the 'lightbox' etc. class to [a] directly than it works as a charm.
There may be a bug in the lightbox plugins, but it is strange, that it is in ALL lightbox plugins.
But even in that case for me it is very strange, that something what is INSIDE the shortcode affects OUTSIDE of the shortcode. That's why i think it is a bug of core.",thomask
Future Releases,24085,wpautop filter and shortcodes,,Shortcodes,trunk,normal,normal,Awaiting Review,defect (bug),new,,2013-04-15T06:41:15Z,2013-05-17T05:12:47Z,"I've been told here that this has been fixed in WP3.6 but it wasn't. I just installed WP3.6 Beta 1 and still doing this:
{{{
[shortcode]
![]()
![]()
![]()
[/shortcode]
}}}
produces this:
{{{
}}}
which is highly unwanted because I have to strip
tags manually in order to make carousel of images work.",Looimaster
Future Releases,23786,Shortcodes working inside HTML and PHP comments,,Shortcodes,,normal,minor,Awaiting Review,enhancement,new,,2013-03-15T11:59:25Z,2013-03-15T14:06:02Z,"I think that shortcodes should not work inside html or php comments. The following comment inserted in the Wordpress editor shows the images gallery, breaks the layout of the theme and shows after the gallery these characters -->
If I use do_shortcode() in a plugin with a shortcode inside a php comments, it's the same as it is with html comments.",javitxu123
Future Releases,19968,Use named regular expression groups to simplify shortcodes code,,Shortcodes,3.3.1,normal,minor,Awaiting Review,enhancement,new,,2012-02-04T18:03:28Z,2012-02-06T08:21:33Z,"Currently in {{{get_shortcode_regex()}}} in [source:trunk/wp-includes/shortcodes.php] you are welcomed by:
{{{
// WARNING! Do not change this regex without changing do_shortcode_tag() and strip_shortcode_tag()
}}}
because these functions use the regular expression match from the shortcode parser.
Instead, we could use named regex groups: {{{(?P\d\d\d\d)}}} or {{{(?'year')\d\d\d\d}}} which appear indexed by name in the matches array: {{{$matches['year']}}} instead of {{{matches[1]}}}.
Benefits:
0. Future-proof code. Won't rely on indices, but on names, which we can control. Now, if we want to add a group we will have to offset all the indices, scattered all over the place.
1. Less ugly and unreadable code like:
{{{
if (!empty($m[1]))
$atts[strtolower($m[1])] = stripcslashes($m[2]);
elseif (!empty($m[3]))
$atts[strtolower($m[3])] = stripcslashes($m[4]);
}}}",nbachiyski
Future Releases,20659,Document available shortcodes in eg. new post page,,Shortcodes,,normal,normal,Awaiting Review,feature request,new,,2012-05-11T14:40:28Z,2012-05-22T12:40:35Z,"It would be useful if a plugin defining shortcodes also could describe the usecase for the shortcode and the available attributes and the usecases for those attributes in a way that could be exposed in the interface on eg. the new post page.
One could take inspiration from eg. the Drupal Token module which has a token_list() hook that a Drupal module uses to describe every token it describes so that they can be presented to the user in the interface.
Something like:
{{{
add_shortcode_description('shortcodename')
}}}
That returns something like this would be nice:
{{{
array(
'description' => 'This is used to do foo',
'attr' => array(
'bar' => 'A text that will be presented as bar'
),
);
}}}",voxpelli
Future Releases,19044,$depth in start_el Walker_Category has null value,,Taxonomy,,normal,normal,Awaiting Review,defect (bug),new,reporter-feedback,2011-10-25T10:17:55Z,2011-10-28T08:46:10Z,"{{{
File wp-includes/category-template.php
Line: 829
}}}
Issue:
{{{
The variable $depth is not returning value.
start_el() - $depth not showing. (Always return zero)
start_lvl() - $depth works fine.
end_lvl() - $depth works fine.
}}}
{{{
/**
* @see Walker::start_el()
* @since 2.1.0
*
* @param string $output Passed by reference. Used to append additional content.
* @param object $category Category data object.
* @param int $depth Depth of category in reference to parents.
* @param array $args
*/
function start_el(&$output, $category, $depth, $args) {
.....
}}}
",nukecpower
Future Releases,24385,Adding and Deleting Custom Taxonomies not Working,,Taxonomy,3.5.1,normal,normal,Awaiting Review,defect (bug),new,,2013-05-22T16:52:35Z,2013-05-22T16:52:35Z,"I created a new post type and a new taxonomy as follows
{{{
/* Code to add new custom post type */
function aaa_register_post_type() {
$post_type_labels = array(
'name' => __('News'),
'singular_name' => __('News Item'),
'all_items' => __('All News'),
'add_new' => __('Add New'),
'add_new_item' => __('Add New News Item'),
'edit_item' => __('Edit News Item'),
'new_item' => __('New News Item'),
'view_item' => __('View News Item'),
'search_items' => __('Search News'),
'not_found' => __('Nothing found'),
'not_found_in_trash' => __('Nothing found in Trash'),
'parent_item_colon' => ''
);
$post_type_args = array(
'labels' => $post_type_labels,
'description' => 'This post type is used for news posts from the RSS feeds.',
'public' => true,
'menu_position' => 5,
'capability_type' => 'post',
'hierarchical' => true,
'supports' => array('title','editor', 'author', 'comments'),
'rewrite' => array('slug')
);
register_post_type ('news', $post_type_args);
}
add_action('init', 'aaa_register_post_type', 0);
/* Register custom news category taxonomy */
function aaa_register_taxonomy_site () {
$taxonomy_lables = array(
'name' => __('Sites'),
'singular_name' => __('Site'),
'all_items' => __('All Sites'),
'edit_item' => __('Edit Site'),
'view_item' => __('View Site'),
'update_item' => __('Update Site'),
'add_new_item' => __('Add New Site'),
'new_item_name' => __('New Site Name'),
'parent_item' => __('Parent Site'),
'parent_item_colon' => __('Parent Site:'),
'search_items' => __('Search Sites'),
'popular_items' => __('Popular Sites'),
'not_found' => __('Nothing found'),
'hierarchical' => true,
'query_var' => true
);
$taxonomy_args = array(
'labels' => $taxonomy_lables,
'show_admin_column' => true,
'hierarchical' => true
);
register_taxonomy(""site"", 'news', $taxonomy_args);
}
add_action('init', 'aaa_register_taxonomy_site');
}}}
Now to cause the error
1. Click on the new custom post ""News"" menu in WordPress admin
2. Click on the new custom taxonomy ""Sites"" submenu
3. Create a new site, then click on the add site button, nothing happens. The list of sites is not updated and the site info is still in the text boxes. However, if you refresh the page, the new site is in the list.
Now, if you want to delete the site after refeshing the page: On the same list of sites page, hover over the site, and click on delete, and you get an undefined error.
",greeso
Future Releases,18553,Counting of categories doesn't work without refreshing?,,Taxonomy,3.2.1,normal,minor,Awaiting Review,defect (bug),new,,2011-08-31T11:39:03Z,2011-09-03T09:17:55Z,"If you add a new category or delete one the number of total categories stays on the original number. For exemple, when you have 7 categories then in the corner it says '7 items'. When you delete one, you have 6 items but '7 items' is still displayed.
(Chrome 15.0.816)
1) Go to your categories
2) Add one and look to the number of items, IT WILL NOT CHANGE!
So this count for adding normal categories and child ones...",jonezjea
Future Releases,14370,Custom Taxonomies tagging Attachments,,Taxonomy,3.0,normal,normal,Awaiting Review,defect (bug),reopened,dev-feedback,2010-07-21T02:28:52Z,2012-08-30T08:56:17Z,"There appears to be an issue where if the custom taxonomy has only attachment:image, attachment:audio, and attachment:video The attachments return nothing found. Only 'post' post types are returned.
adding to a query 'post_status' => publish, allows it to display the images but does not allow pagination.
WordPress should return all post_types that the Taxonomy is defined for. Somehow ma.tt found a way around this issue. refer to:
http://osdir.com/ml/wp-testers/2010-06/msg00317.html
http://wordpress.org/support/topic/383096?replies=29
Does not affect pre 3.0
",thee17
Future Releases,21842,Diffrerent Custom Taxonomy Unable to Have Same Term Name in Version 3.4.2,oneTarek,Taxonomy,3.4.2,normal,major,Awaiting Review,defect (bug),new,reporter-feedback,2012-09-08T09:27:28Z,2012-09-14T23:47:16Z,"Before WordPress version 3.4.2 We know that WordPress does not support same word as category and tags. Assume you have a category named ""iPhone"" and it's slug is 'iphone' and now you want to add a new tag named ""iPhone"" , in this case tag slug will be 'iphone-2'. But if you have a custom taxonomy ""Device"" then the slug will be 'iphone' same as category ""iphone"". It means WordPress did not support same category and tag but can be same with any custom taxonomy. I tested many times this case.
But today after updating My WordPress Blog to version 3.4.2 I found a mistake on it. I have 3 custom taxonomy. 'Type', 'Brand' and 'OS' . Before WP 3.4.2 I was able to use same word as Category and Type and also same slug for those. But now in version 3.4.2 when I am adding new terms It is getting slug with extra number 2. Example: I have a Category 'Apple' it's slug 'apple'. Now I am trying to add a 'Brand' taxonomy term 'Apple', the slug is being created 'apple-2'. But this problem was not in before WP 3.4.2",onetarek
Future Releases,16797,Edit Tags admin + custom post type + custom taxonomy,,Taxonomy,3.1,normal,normal,Awaiting Review,defect (bug),new,,2011-03-08T17:20:30Z,2011-03-08T19:10:16Z,"I've registered the custom post type `fp_toy`, and the custom taxonomy `fp_milestone`. Both have `show_ui` set to `true`. I have the `fp_milestone` taxonomy associated with both `fp_toy` and `post`.
If I click Toys > Milestones in the admin, the URL is `edit-tags.php?taxonomy=fp_milestone&post_type=fp_toy`; but in the navigation menu, it appears that I'm in Posts > Milestones. (This is minor, but may help with diagnosis.)
Worse, in the list of Milestones, I see an automatically populated column named ""Toy,"" which would be correct if it were indicating the number of Toys per Milestone; but it is counting `all` posts associated with a Milestone, not just those with a `post_type` of `fp_toy`.
Worst of all, clicking this (incorrect) post count should take me to `edit.php?fp_milestone=create&post_type=fp_toy`; instead it's taking me to `edit.php?fp_milestone=create&post_type=post`. The result is that I have no way (without URL manipulation) to see all Toys for a given Milestone.",kanuck54
Future Releases,23069,"For plugins that create custom taxonomies, wp_delete_term does not work during plugin uninstall.",,Taxonomy,3.5,normal,trivial,Awaiting Review,defect (bug),new,,2012-12-28T15:10:51Z,2013-01-02T19:37:39Z,"I ran into this problem while writing a plugin uninstall class to clean up any options, custom post types, taxonomies & terms related to the plugin.
The problem is, if a plugin creates a custom taxonomy and the plugin user creates terms for that taxonomy, the plugin cannot delete those terms during uninstall.
How to reproduce:
1. Create a plugin that creates a custom taxonomy.
2. Create some terms for that taxonomy.
3. In uninstall.php, try using wp_delete_term to remove those terms.
Because the plugin is already deactivated by the time uninstall.php fires, $wp_taxonomies no longer contains the custom taxonomy that the plugin created. Since wp_delete_term requires a valid taxonomy as its second parameter, it does not work.
The issue is also being discussed here: http://bit.ly/RUDYOv",sscovil
Future Releases,19205,Orphaned categories can be created by accident,,Taxonomy,,normal,minor,Awaiting Review,defect (bug),new,,2011-11-08T14:12:39Z,2011-11-19T06:07:17Z,"There are two ways to do that.
1. You can work on category tree from two browser windows.
- In window one, delete a category
- In window two, add a child to the category that has been deleted.
wp_insert_term needs to check if the parent exists.
2. If you delete a couple of categories with bulk-delete, a third level child node can become orphan.
wp_delete_term uses get_term to find the parent node and can retrieve cached data.",dzver
Future Releases,19492,Problems with using wp_insert_term together with switch_to_blog,,Taxonomy,3.2,normal,normal,Awaiting Review,defect (bug),new,,2011-12-09T23:38:33Z,2011-12-09T23:38:33Z,"I'm running a network of about 80 sites using WP multisite 3.2. I'm experiencing irregularities using switch_to_blog whith wp_insert_term.
To test this I have disabled all plugins, and am testing on a blank page so nothing else interferes. This is the sample code:
switch_to_blog(75);
wp_insert_term( 'New Term','category');
restore_current_blog();
When run from most blogs it adds the new term to the desired blog and the permalink to the new term page works.
But for a few of the blogs, when it runs it adds the term, but the link to the new term page throws a 404 error. Opening wp-admin and adding any new term through wp-admin fixes it.
Is this related to the other term_cache bugs?
",ErikStromme
Future Releases,24376,Sharing Custom Taxonomies with built-in Post Types,,Taxonomy,3.5.1,normal,normal,Awaiting Review,defect (bug),new,,2013-05-20T22:57:58Z,2013-05-21T12:36:51Z,"If you register a custom taxonomy for built-in post types the admin pages containing the table and count for the custom taxonomy have the wrong count for each term.
Use case, I've register a custom taxonomy and assigned to the Post and Page post types like the following:
{{{
register_taxonomy(
'cat',
array('post','page'),
array(
'labels' => array(
'name' => _x( 'Cat', 'taxonomy general name' ),
'singular_name' => _x( 'Cat', 'taxonomy singular name' ),
'search_items' => __( 'Search Cats', 'some_plugin' ),
'all_items' => __( 'All Cats', 'some_plugin' ),
'parent_item' => __( 'Parent Cat', 'some_plugin' ),
'parent_item_colon' => __( 'Parent Cat:', 'some_plugin' ),
'edit_item' => __( 'Edit Cat', 'some_plugin' ),
'update_item' => __( 'Update Cat', 'some_plugin' ),
'add_new_item' => __( 'Add New Cat', 'some_plugin' ),
'new_item_name' => __( 'New Cat Name', 'some_plugin' ),
'menu_name' => __( 'Cat', 'some_plugin' )
),
'hierarchical' => true,
'show_admin_column' => true,
'show_ui' => true
)
);
}}}
If you add a post and create different cats, you'll see the same count shows in both admin taxonomy UIs
/wp-admin/edit-tags.php?taxonomy=cat
/wp-admin/edit-tags.php?taxonomy=cat&post_type=page
",ZaneMatthew
Future Releases,22511,"Taxonomy manage screen checks for manage_terms and edit_terms, instead of just manage_terms.",,Taxonomy,3.0,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2012-11-19T23:13:56Z,2012-11-20T03:14:40Z,"I'm trying to set up permissions so the Contributor role can add terms but not edit or delete terms. I setup my taxonomy so it looks like this:
{{{
register_taxonomy( 'custom_taxonomy', array( 'post' ), array(
...
'capabilities' => array (
'manage_terms' => 'edit_posts',
'edit_terms' => 'manage_options',
'delete_terms' => 'manage_options',
'assign_terms' => 'edit_posts'
)
) );
}}}
However, when logged in as a contributor I get the error ""You are not allowed to edit this item."" In edit-tags.php there are two checks for caps, one is for manage_terms and one is for edit_terms. I don't believe the second one should be there, because looking at the other code it should be like this:
* User with manage_terms can access the main taxonomy page
* They can also add terms
* There are checks in WP_Terms_List_Table to restrict showing the Edit/Quick Edit/Delete links for users without those capabilities (edit_terms/delete_terms).
* There is even plenty of other checks on edit_terms in edit-tags.php to include/change the content shown to the user.. if the entire page is restricted for users without edit_terms, why are any of those necessary?
Even if I'm wrong on the fact that roles with edit_terms can't add new terms (it's not completely clear anywhere, it seems like manage_terms should be enough), I still think that this page should be viewable at the very least considering the other code in that page and the list table.
Recommended solution: move the edit_terms check back into case 'edit' (line 121 of edit-tags.php in trunk, currently) as it was before [15491].
This was introduced in: [15441] and [15491]. Related: #14343.",andrewryno
Future Releases,15741,Taxonomy: Duplicate term slug error message refers to the name,,Taxonomy,3.0.2,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2010-12-09T01:03:10Z,2011-02-25T15:52:39Z,"You can't create a term if there is another existing term with the same slug. The error message indicates this warning incorrectly, referring to the term ""name"" instead of ""slug"":
A term with the name provided already exists with this parent.
Problem in action:
1. Create a category name ""Example"" with slug ""example"" without any parent category.
2. Once that is saved, try creating the exact same category again.
3. ""A term with the name provided already exists with this parent."" error shows up.
4. Create a category name ""Example"" with slug ""example-2"".
5. No error. Category with the same '''name''' can be created, contrary to the error message in step 3.
The error message should refer to the slug not name if this is an intended behavior. If the same term name should not exist under one level, step 4 should not be allowed either (especially with Tags).",Nao
Future Releases,21200,get_all_category_ids() only used by a deprecated function,,Taxonomy,3.4.1,normal,minor,Awaiting Review,defect (bug),new,,2012-07-09T11:35:01Z,2012-09-08T21:02:55Z,"The function ""get_all_category_ids()"" (category.php) is only used by the deprecated function ""get_category_children"". I got two ideas for the future of the function:
a) also deprecate it
b) create a function ""get_all_taxonomy_ids($taxonomy)"". Since it seems to be a common problem for programmers to get e.g. all tag ids I would prefer this.
",Latz
Future Releases,24354,get_cat_id() fails with category names containing ampersand,,Taxonomy,3.5.1,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2013-05-17T08:25:08Z,2013-05-17T10:07:10Z,"{{{
echo get_cat_id('News');
results in 3 (as expected);
echo get_cat_id('Test OtherName');
results in 8 (as expected);
echo get_cat_id('Test&OtherName');
Results in 0
echo get_cat_id('News & Media');
Results in 0
}}}
All the category names were created in the Category Edit page, category names were copied from the text box directly into the code to allow no formatting issues.
I tracked the code to get_term_by and I think the ampersand in category name screws up possibly after being added into the prepared SQL statement.
",Kenshino
Future Releases,17652,get_term_link doesn't accept $term->term_id without explicit casting as numeric,,Taxonomy,3.1.3,normal,minor,Awaiting Review,defect (bug),new,,2011-06-02T00:42:09Z,2013-05-01T18:20:53Z,"global $wp_query;
$term = $wp_query->get_queried_object();
get_term_link($term, $term->taxonomy); // ok
get_term_link($term->slug, $term->taxonomy); // ok
get_term_link($term->term_id, $term->taxonomy); // WP_Error ('Empty Term')
echo ($term->term_id); // ok (echoes correct ID)",tomauger
Future Releases,17365,get_terms doesn't return terms with no posts if you specify a parent,,Taxonomy,3.1.2,normal,normal,Awaiting Review,defect (bug),new,,2011-05-10T11:52:19Z,2011-05-10T11:52:19Z,"get_terms doesn't return terms with no posts if you specify a parent (see also #15626 for a related bug). Let's imagine the following term structure:
{{{
---parent_term (0 count)
|---child_term (10 count)
}}}
Calling `get_terms('category', array('parent' => 0))` should return both terms according to the documentation, but it doesn't. The documentation says that `hierarchical` defaults to true, which should '''""include terms that have non-empty descendants""'''. It's broken because the following code runs if a parent argument is present (lines 1139-3 of taxonomies.php).
{{{
if ( !$single_taxonomy || !is_taxonomy_hierarchical($taxonomies[0]) ||
'' !== $args['parent'] ) {
$args['child_of'] = 0;
$args['hierarchical'] = false;
$args['pad_counts'] = false;
}}}
But nothing in the parent section of the documentation suggests that adding a parent will change the other defaults. The consequence of the above code comes in lines 1266-7:
{{{
if ( $hide_empty && !$hierarchical )
$where .= ' AND tt.count > 0';
}}}
which means the parent_term is not being returned because it has a count of zero, and I can't walk down the tree to get the other terms.
At the very least, set this paramenter as default in $defaults, before `$args = wp_parse_args( $args, $defaults )` (rather than in `$args` afterwards) which would at least allow us to override this behaviour through explicit `$atts`. But it would be more logical simply to remove the test for `'' !== args['parent']` altogther, inline with the existing documentation.",mark8barnes
Future Releases,18625,term_exists() doesn't make a difference between z and ẓ,,Taxonomy,3.2.1,normal,normal,Awaiting Review,defect (bug),new,,2011-09-09T12:23:25Z,2011-09-09T15:31:21Z,"I spent hours before discouvering why wp_insert_term doesn't want to create some of my categories list;
{{{
$alphabet = array (
array( 's', 'sth' ),
array( 'ṣ', 'sth' ),
array( 'h', 'sth' ),
array( 'ḥ', 'sth' ),
array( 'd', 'sth' ),
array( 'ḍ', 'sth' )
);
foreach ($categories as $category )
{
if( term_exists( mb_strtolower($category[0]), 'category' ))
continue;
else
wp_insert_term( $category[0], 'category', array( 'slug' => $category[0] ) );
}
}}}
term_exists() doesn't make a difference between ""normal characters"" and diacritic characters.
",abdessamad idrissi
Future Releases,18609,term_id collisions possible with InnoDB tables and global_terms_enabled,,Taxonomy,3.2.1,normal,major,Awaiting Review,defect (bug),new,,2011-09-07T02:41:41Z,2011-10-19T01:05:47Z,"This bug relates to the ""global terms"" feature that uses the wp_sitecategories table to store all terms used across the multi-site install. This feature is enabled by setting global_terms_enabled to ""1"" in the wp_sitemeta table.
I have found that when global_terms_enabled is on, and you are using InnoDB tables, it is possible for a new term insertion in the local terms table (wp_x_terms) to fail due to an ID collision. This happens because InnoDB does not handle auto_increment in the same way as MyISAM, and the code for the global terms feature does not account for this difference.
In MyISAM, any change to a value in an auto-incremented column causes the table's AUTO_INCREMENT value (next value to be used, as seen via ""show table status"") to change. For example, if I have a MyISAM table, and I use an update statement to change the value of an auto incremented column to a value larger than the current AUTO_INCREMENT, the AUTO_INCREMENT is automatically increased as needed, so the next insertion cannot collide.
However, InnoDB does not do this. It only changes AUTO_INCREMENT on an insert. It does not change it when a column value is increased via an update statement. You can see this in the MySQL docs, or you can see it by creating a test case, like this:
- Create an InnoDB table with 2 columns: ID (auto_increment, primary key) and data.
- Insert a row using an insert statement, without specifying an ID.
- Observe that ID = 1 for that row, as expected.
- Use an update statement to set ID = 2 on that row.
- Insert another row without specifying an ID.
- Observe that the insertion fails. MySQL has attempted to insert a row with ID = 2, but there is already such a row.
If you do the same steps with a MyISAM table, the insertion does not fail, because AUTO_INCREMENT was automatically changed from 2 to 3 when your update statement was executed.
Going back into the context of the global terms feature: This problem happens when a new term is created in a site. The new term is initially inserted into the local terms table for the current site (wp_x_terms). After this, the function global_terms (in ms-functions.php) is called. This function finds or creates a matching entry in the wp_sitecategories global terms table, and uses an update statement to change the term_id of the row we just inserted in wp_x_terms. When wp_x_terms is an InnoDB table, the AUTO_INCREMENT value for the table does not change.
Suppose the AUTO_INCREMENT value was 58 after the original insertion, and further suppose that 58 was (coincidentally) the ID found in wp_sitecategories and written into our new row by the update statement described above. Now suppose we are ready to insert another new term into wp_x_terms. AUTO_INCREMENT is still 58, so we attempt to insert a term with term_id = 58, but it fails because there is already a row in the table with that ID.
Fix for this would be to reorder the operations so that no row is inserted into wp_x_terms until after wp_sitecategories has been queried and updated. That way, we know the ID we need to use when inserting into wp_x_terms before that insertion takes place, so we can specify it in the insert statement rather than depending on AUTO_INCREMENT.
I have marked this as severity major, because these unpredictable term_id collisions can cause weird errors, and the only workaround I have at this time is to disable global terms and restart MySQL (to regenerate AUTO_INCREMENT values on all tables).",andrew_l
Future Releases,24073,wp_ajax_ajax_tag_search,,Taxonomy,3.5.1,normal,normal,Awaiting Review,defect (bug),new,reporter-feedback,2013-04-13T09:59:25Z,2013-04-14T04:39:03Z,"For some of custom taxonomies the tag autocomplete doesn't work I tried to solve this issue and changing t.name to name in
$results = $wpdb->get_col( $wpdb->prepare( ""SELECT name FROM ..... "");
in wp-admin/includes/ajax-actions.php -> wp_ajax_ajax_tag_search() helped me to solve this problem.
now everything looks ok for me .
",samnajian
Future Releases,21881,wp_list_categories show_option_all does not work for custom taxonomy,,Taxonomy,,normal,normal,Awaiting Review,defect (bug),new,,2012-09-13T12:46:59Z,2012-09-13T13:41:09Z,I am using wp_list_categories on a custom post type page to list the taxonomy values (categories). However if I include an All link it links by default to /blog/ and not /taxonomy/.,arkinex
Future Releases,23422,Add query filter argument to register_taxonomy,,Taxonomy,,normal,normal,Awaiting Review,enhancement,new,,2013-02-08T12:38:35Z,2013-02-08T12:50:58Z,"Following on from the #21240 ticket which introduced the show_admin_column functionality I would like to suggest an additional argument to easily add the select list query filter for a taxonomy to the post-type list.
Currently a taxonomy query can be added via the 'restrict_manage_posts' action and 'parse_query' filter.
It would be useful to add an additional register_taxonomy argument of 'show_column_filter' to define a standard select option list of the taxonomy terms. Things like default option and hierarchy could be optional settings is an array is passed instead of boolean.
",tifosi
Future Releases,23421,Add sortable to taxonomy column,,Taxonomy,,normal,normal,Awaiting Review,enhancement,new,,2013-02-08T12:34:20Z,2013-02-09T10:57:33Z,"Following on from the #21240 ticket which introduced the show_admin_column functionality one limitation is the 'as easy' way to make that column sortable.
It's possible to do it through the 'manage_edit-{$post_type}_sortable_columns' filter but the column_key is different for 3.5+. A standardisation as for adding the column may be advantageous: a register_taxonomy argument and / or new filter.
argument: show_column_sortable, boolean default false, requires show_admin_column to be set and true.
In the same way that the get_columns function uses the new ""manage_taxonomies_for_{$post_type}_columns"", filter to add a taxonomy column there could be a ""manage_taxonomies_for_{$post_type}_sortable_columns"" filter in the get_sortable_columns function of the post-list class:
i.e.
{{{
function get_sortable_columns() {
$default = array(
'title' => 'title',
'parent' => 'parent',
'comments' => 'comment_count',
'date' => array( 'date', true )
);
return apply_filters( ""manage_taxonomies_for_{$post_type}_sortable_columns"", $default );
}
}}}
The developer could then set the filter as normal
{{{
add_filter( ""manage_taxonomies_for_{$post_type}_columns"", 'add_sortable_column' );
function add_sortable_column ( $columns ) {
$columns[ taxonomy-tax_name ] = 'Taxonomy Label';
return $columns;
}
}}}",tifosi
Future Releases,22875,Additional custom taxonomy object types,,Taxonomy,3.5,normal,major,Awaiting Review,enhancement,new,,2012-12-12T09:59:37Z,2012-12-12T19:53:43Z,"At the moment, a taxonomy can be registered for one of the following objects (ref http://codex.wordpress.org/Function_Reference/register_taxonomy ):
- post
- page
- attachment
- revision
- nav_menu_item
- a particular cpt
Taxonomies would become much more powerful and flexible, if:
- They accept additional objects, e.g. users, taxonomies
- They accept multiple objects, e.g. a single custom taxonomy could group together posts, pages and attachments",sooskriszta
Future Releases,23966,Allow to use order_by in addition to orderby,,Taxonomy,3.5,normal,minor,Awaiting Review,enhancement,new,close,2013-04-06T19:36:45Z,2013-04-09T18:44:56Z,"http://codex.wordpress.org/Function_Reference/get_categories
The above link and the same for wp_list_categories suggests that you can order categories by count. In practice it seems to ignore the parameter. It doesn't seem to work with a few other parameters either -- the only things that seem to work are ID, name, and slug, but these might merely be incidental to the fact that I created my test categories in alphabetical order.",Denis-de-Bernardy
Future Releases,22296,Better internationalization support for tags,,Taxonomy,3.4.2,normal,minor,Awaiting Review,enhancement,new,,2012-10-27T11:25:41Z,2012-10-28T13:52:01Z,"When playing around with tags I've found a couple of things that doesn't work as expected when dealing with names that have non-english characters.
The two problems I've found are that single non a-z chars doesn't seem to work at all, and when two tags are the same except for one character which is non a-z, they seem to collide. One example of this is that you're unable to use the tags ""for"" and ""för"" together.
I'm not sure if this is something that WordPress is supposed to support but I've got a use case for it and would like to raise the question.
Here's some tests which shows the problem: https://gist.github.com/3964335
Oddly enough you seem to be able to add the single non a-z tags from the dedicated tags page, but you're still unable to use them in any post. ",exz
Future Releases,16621,Check term cache in _transform_terms(),,Taxonomy,3.1,normal,normal,Awaiting Review,enhancement,new,,2011-02-23T19:21:49Z,2011-02-24T00:17:06Z,"WP3.1's awesome new taxonomy query stuff rocks, but WP_Tax_Query->_transform_terms() seems to be executing multiple identical queries on each page load. The front page of one of my sites gives me five of the following query:
{{{
SELECT wp_1_term_taxonomy.term_taxonomy_id
FROM wp_1_term_taxonomy
INNER JOIN wp_1_terms USING (term_id)
WHERE taxonomy = 'channel'
AND wp_1_terms.slug IN ('tech')
}}}
I understand the function can do a lot more than map a single term+taxonomy to a term_taxonomy_id, but it also looks like there'd be some performance benefit from checking the term cache rather than the DB in those situations.
Or, perhaps it'd be enough to simply cache the result for the duration of the page load.
Or, maybe I'm focusing on the wrong problem, as the query takes just 1-2ms to execute.",misterbisson
Future Releases,21950,Don't create shared terms,,Taxonomy,,normal,normal,Awaiting Review,enhancement,new,,2012-09-20T22:52:48Z,2013-01-15T17:04:02Z,"Step 1: Split shared terms: #5809
Step 2: Don't create new shared terms: this ticket.
Step 3: Profit.",scribu
Future Releases,21862,Don't display show_option_none in wp_dropdown_categories when categories exist,,Taxonomy,,normal,normal,Awaiting Review,enhancement,new,,2012-09-10T15:14:04Z,2012-09-10T15:16:48Z,"I can't find an application of having an extra entry for '''show_option_none''' select option if we have category listing. Is there any reason to keep it there, like for external filters? If so, that still conflicts with the second example below.
First off, it is invalid since there are some categories available. Second, having both '''show_option_none''' and '''show_option_all''' displays both entries.
Related to #21856 trying to list only visible terms.",nofearinc
Future Releases,18050,Label Most used taxonomies is impossible to customize on a new taxonomy,,Taxonomy,3.2,normal,normal,Awaiting Review,enhancement,new,,2011-07-09T13:37:01Z,2011-09-13T03:01:09Z,"The label in wp-admin/includes/meta-boxes.php doesn't allow to translate it in different languages when you create a new taxonomy. The attached patch resolve it adding the new label 'most_used'
",SGr33n
Future Releases,24386,Make _pad_term_counts work for non-post type objects and attachments,,Taxonomy,,normal,normal,Awaiting Review,enhancement,new,,2013-05-22T18:23:31Z,2013-05-23T08:34:49Z,"If you register a hierarchical taxonomy against a non-post object (such as users), or attachments that aren't associated with another post, _{{{pad_term_counts}}} does bubkus, due to the INNER JOIN on {{{$wpdb->posts}}}, and the check for 'publish' status (which is relevant for attachment post types).
I'm suggesting an alternative approach would be to use $term->count, and eschew going back to the database altogether.",TomAuger
Future Releases,17848,"Not possible to add a file field to the ""add term"" form",,Taxonomy,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2011-06-19T23:35:22Z,2011-09-19T13:51:45Z,"The ""add term"" form now uses ajax. The downside is that it is not anymore possible to add an additional file field using a plug-in as it won't be sent over ajax.
The easy way to fix this is to use the already included jquery.form script for that form. That plugin will make the form submit into a hidden iframe if a file field is found inside the form.",DreadLox
Future Releases,23635,get_objects_in_term - identify matching terms,,Taxonomy,3.5.1,normal,minor,Awaiting Review,enhancement,new,,2013-02-26T21:29:54Z,2013-02-26T21:29:54Z,"`get_objects_in_term` is great for viewing taxonomy relationships for non-posts. However the return value is too limited for certain use cases. For When fetching object_ids for multiple terms the return value doesn't inform as to the matching term.
For instance this query:
{{{
#!php
$object_ids = get_objects_in_term(array(55, 66, 77, 88, 99), ""my_custom_taxonomy"");
}}}
Might return an array of object_ids as follows:
{{{
#!php
array(101, 202, 303, 404);
}}}
However there's no way to tell '''which''' term a particular object_id matched. Did object 101 match term 77? Or maybe it was term 99? Or both?
I've created a modified version of `get_objects_in_term` which will addresses this issue. I'll submit a patch, but am wondering if there's another way to achieve this functionality. ",leepowers
Future Releases,20735,Adding tags to form element of categories.,,Taxonomy,3.3.2,normal,normal,Awaiting Review,feature request,new,,2012-05-23T13:15:59Z,2012-05-23T13:15:59Z,"Just like the post form in posts you can use the hook of ""post_edit_form_tag"" to add new tags to the form element of creating or editing new post.
but there is no hook for categories form to do that I think adding new element will be helpful feature.
Note: after some debugging I found that the hook can be add in:
#File: your wordpress directory/wp-admin/edit-tag-form.php
#Line: 33
# Find :